Archivo de la categoría: Factura Electrónica

La factura electrónica es uno de los usos más extendidos de la firma electrónica en el mundo empresarial, pero todavía genera dudas. Espero aclarar algunas aquí

Interoperabilidad de la factura electrónica


Hace unos meses redacté un artículo reflexionando sobre la necesidad de que las diferentes soluciones de eFactura fueran interoperables. Ese artículo acabó en «Computerworld» con el título «La factura electrónica como métrica»

Transcribo el texto:

La factura electrónica está “de moda”. No por su novedad, pues en el sector de la automoción y la distribución comercial se emplea el mensaje EDI de factura desde hace 20 años con interesantes efectos en la gestión de compras, donde se han conseguido grandes eficiencias.

Sin embargo, sólo recientemente el desarrollo legislativo ha permitido que el envío de los mensajes electrónicos elimine la necesidad de enviar, además, las facturas en papel. Es una iniciativa internacional que se produce desde la publicación de la Directiva 2001/115, y que en España alcanza el desarrollo legislativo a partir de la publicación del RD 1496/2003 y el 87/2005, que lo modifica simplificando los aspectos de más difícil cumplimiento.

En un contexto en el que la norma legal es flexible, el problema surge de la necesidad de hacer interoperables los sistemas y equipos de quienes emiten factura y quienes la reciben. Desde el punto de vista legal, el requisito de que la factura electrónica sea un documento con firma también electrónica puede cubrirse con un simple fichero PDF firmado con el aspecto de la factura en papel. Pero, cuando lo reciba, el receptor acabará tecleando los datos de la factura en el programa de gestión de facturas recibidas y en el de contabilidad, y no se habrán logrado los ahorros previstos. En cambio, si el mensaje se codifica en XML, el PC del receptor puede procesar de forma automática muchos pasos relacionados con la gestión de facturas.

Varias iniciativas internacionales trabajan para unificar formatos: en Naciones Unidas, el Grupo de Trabajo Cross Industry Invoice, y en el Comité Europeo de Normalización, eInvoice Focus Group. El último tiene en cuenta entre sus documentos las especificaciones de firma electrónica a utilizar. Un elemento común a estas iniciativas es el uso de un conjunto de especificaciones denominado “Core Components” de UN/CEFACT, cuya implementación más relevante se da en el formato Invoice de la especificación UBL, que en la v. 2.0 está siendo liberado por la organización de estandarización OASIS. La futura v. 3.0 será posiblemente el texto que recogerá los requisitos de todas las iniciativas, bajo la bandera de UN/CEFACT. En España, la especificación CCI, codificada en XML y diseñada para la banca, está recibiendo apoyo de la Agencia Tributaria, lo que lleva a prever un amplio uso. La traducción entre formatos XML no es complicada, así que la convivencia entre ellos se dará probablemente durante un tiempo.

La firma electrónica es otro ámbito en el que hay que intentar la compatibilidad. Como cada entidad firmante puede elegir cualquier PSC (Prestador de Servicios de Certificación) para sus certificados, la entidad que acepta facturas se enfrenta a la complejidad de validar certificados de los que tiene poca información. Una solución que facilitaría la aceptación de facturas es que éstas llegaran firmadas con la modalidad ES-XL prevista en la norma TS 101 903, incluyendo un sello de tiempo y la información de validez del certificado expedido por su emisor: lo que se denomina “firma completa”, y significa que la firma y el certificado están validados en origen. Así, el receptor se ve exonerado de las obligaciones que impone aceptar firmas electrónicas.

Aunque parece complicado, las pymes realizarán sus facturas electrónicas con plataformas como “Faccil” o las desarrollarán las entidades financieras, así que no tendrán que preocuparse de estos detalles.

La factura electrónica tiene otras ventajas: mejor aprovechamiento de la habilidad de los empleados, reducción de controversias, mejoras en la resolución de incidencias, reducción de plazos de cobro, mejoras en la negociación de los plazos de pago, posibilidad de acudir a servicios financieros como el confirming y el factoring, mejora de la relación comercial y de la imagen de la empresa, y el cumplimiento de obligaciones cuando la facturación electrónica sea impuesta por una norma legal.

Curiosamente, el título «La efactura como métrica» estaba destinado a una reflexión en torno a la importancia del dato de penetración de la factura electrónica en las empresas como indicador de otras acciones de adopción empresarial de nuevas tecnologías, tema por el que me dió por pensar tras la presentación de Domingo Laborda, Director del Observatorio de las Telecomunicaciones y la Sociedad de la Información de Red.es en el Congreso de Factura Electrónica y Digitalización Certificada que ASIMELEC organizó el pasado 18 de octubre de 2006. Este tema ya lo traté en este post.

DNI-e. Centro de Tecnología del DNI electrónico dirigido al sector empresarial, en especial a las Pymes y Micropymes


Por su interés, reproduzco el artículo  que Miguel Azorín-Albiñana (Subdirector General de Tecnologías de la Información y las Comunicaciones, del Ministerio de Industria, Turismo y Comercio) ha publicado en la Revista de ASTIC, (Asociación Profesional del Cuerpo Superior de Sistemas y Tecnologías de la Información de la Administración del Estado) y que define un conjunto de iniciativas del Ministerio de Industria, Turismo y Comercio para impulsar la adopción del DNI electrónico que aplaudo desde este humilde Blog.

La verdad es que me he sentido muy identificado por todo lo que se indica en el artículo.

Entre los puntos clave, cabe destacar:

  • El Centro deTecnología para el DNI-e tiene por objetivo potenciar el uso de la identidad digital, de la firma electrónica, de los documentos electrónicos y de la factura electrónica en el sector empresarial
  • Se está creando un sitio web para soporte y divulgación del uso del DNI-e basado en el gestor de contenidos MS CMS dirigido a los sectores industriales, y en particular a la pyme y micropyme
  • Las diez actuaciones que se están llevand oa cabo estarán terminadas a finales de marzo de 2007 y van a permitir a la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información disponer de un centro avanzado de tecnología sobre el uso del DNI electrónico

El Ministerio de Industria Turismo y Comercio, de acuerdo con lo establecido en el Real Decreto 1554/2004,de 25 de junio, por el que se desarrolla la estructura orgánica básica del Ministerio de Industria Turismo y Comercio, tiene entre sus competencias el diseño y ejecución de proyectos que favorezcan la integración de las tecnologías de la información en todos los ámbitos de la actividad económica y social, y el impulso y la coordinación de los planes, proyectos tecnológicos y programas de actuaciones para el desarrollo e implantación de la sociedad de la información; en especial, lo referente al acceso, la identificación digital y desarrollo en servicios y contenidos, en colaboración con los departamentos, Administraciones y entidades públicas implicados, así como con los sectores económicos y sociales públicos y privados afectados.

Por una parte, el Plan Avanza, aprobado por el Consejo de Ministros del 4 de noviembre de 2005, se orienta a conseguir la adecuada utilización de las TIC para contribuir al éxito de un modelo de crecimiento económico basado en el incremento de la competitividad y la productividad, la promoción de la igualdad social y regional y la mejora del bienestar y la calidad de vida de los ciudadanos.

Por otra, el 7 de julio de 2005, se firmó un acuerdo de colaboración entre el Ministerio del Interior y el Ministerio de Industria, Turismo y Comercio para el desarrollo del proyecto técnico del Documento Nacional de Identidad electrónico.

Mediante el citado Acuerdo, el MITYC adquirió obligaciones relativas a la financiación de una parte del proyecto por un importe de 11.642.000, así como a la colaboración en la definición y extensión de uso del DNI-e, a la difusión y patrocinio en el ámbito de la Sociedad de la información, al asesoramiento en las funcionalidades y capacidades tecnológicas y su adecuación a estándares y normas europeas e internacionales, a la puesta en marcha de un proyecto piloto que permitiese probar los certificados electrónicos incluidos en elDNI-e en los procedimientos internos y externos del Ministerio y a la puesta a disposición de ciudadanos y empresas de la primera ventanilla virtual que aceptase el DNI-e para tramitar los procedimientos externos.

Este acuerdo finaliza el 31 de diciembre de 2006, y si bien está prevista su prórroga de común acuerdo por ambas partes, el desarrollo actual del proyecto aconseja elaborar un nuevo acuerdo, que permita impulsar el proyecto del DNI-e para que sea una realidad para la mayor parte de los ciudadanos.

Fruto de estos acuerdos, el Ministerio de Industria, Turismo y Comercio ha puesto en marcha la creación de un centro de tecnología para el DNI-e dirigido al sector empresarial, en especial a las PYMES y MICROPYMES. El Centro de Tecnología para el DNI-e tiene por objetivo potenciar el uso de la identidad digital, de la firma electrónica, de los documentos electrónicos y de la factura electrónica en el sector empresarial aprovechando la oportunidad que proporcionan los certificados electrónicos contenidos en el DNI-e así como loscertificados de personas jurídicas y de representación que se están expidiendo por los diferentes prestadoresde servicios de certificación reconocidos por el Ministerio de Industria,Turismo y Comercio.

La necesidad de este Centro se ve reforzada por la toma en consideración en el Consejo de Ministros el pasado 17 de noviembre, del anteproyecto de Ley de Medidas de impulso de la Sociedad de la Información, en el que se introducen preceptos dirigidos al empleo de la factura electrónica y el uso de los medios electrónicos en todas las fases del proceso de la contratación, estableciéndose la obligatoriedad de la factura electrónica en el marco de la contratación pública estatal.

El citado anteproyecto de Ley prevé que el Ministerio de Industria, Turismo y Comercio impulsará el empleo de la factura electrónica entre los diversos agentes del mercado, en particular en las pequeñas y medianas empresas y en las denominadas microempresas, con el fin de fomentar el desarrollo del comercio electrónico. En esta línea de actuación, se enmarca el proyecto de creación del Centro de Tecnología para el DNI-e, cuya finalidad es la de dar soporte y asistencia a las pequeñas y medianas empresas en el uso de la identidad digital, en especial en la utilizacióndel DNI-e, así como en los procesosde relación con la Administración; en la celebración de contratos entre empresas, en la firma de documentos electrónicos y facturas electrónicas y en el establecimiento de medios de pago basados en el uso del nuevo DNI-e.

Para la consecución de estos objetivos se han definido las siguientes diez actuaciones:

Desarrollo y optimización de componentes para la firma electrónica basada en el uso del DNI-e

Tomando como base y evolucionando el software desarrollado en la Subdirección General de Tecnologíasde la Información y las Comunicaciones del MITYC se procederán a realizar los siguientes desarrollos:

Componente de firma

El componente actualmente disponible en el Ministerio se basa en tecnología activeX y el estándar de firma XAdES-BES. Deberá modificarse para utilizar otro estándar de firma que permita la inclusión de información adicional de firma (como por ejemplo el sellado de tiempo), utilizando alguno de los estándares definidos por la ETSI (XAdES-T, XAdES-C, …).

Por otra parte su desarrollo como componente activeX limita su utilización al entorno Microsoft. Dado que este tipo de componentes deben de ser multiplataforma se deberá recodificar mediante el uso de JAVA. La especificación ETSI TS 101 903 v1.3.2 define cuatro formatos de firma electrónica avanzada XML (XAdES): Firma básica (XAdES-BES), Firma basada en política explícita (XAdES-EPES), y Firma con tiempo de validación (XAdES-T) y Firma con datos completos de validación (XAdES-C). Estos formatos pueden extenderse dando lugar a Firmas extendida con formato de tiempo (XAdES-X), Firmas largas extendidas con tiempo(XAdES-X-L) y Firmas con archivo (XAdES-A).

Componente de verificación de firma

El componente actual permite la verificación de firmas XML-Signature y XAdES-BES.

Deberá modificarse para que se permita, al menos, la verificación de otros estándares de firma ampliamente utilizados como PKCS#7 o XML-Signature.

Componente de sellado de tiempo

Dada la importancia en las relaciones contractuales de que una tercera parte de confianza pueda dar fe de lafecha en que una transacción entre dos particulares fue realizada, se desarrollará un nuevo componente que permita el sellado de tiempo o «time-stamping».

El estándar de firma utilizado deberá permitir la inclusión de este tipo de información.

Componente de validación de certificados

La Dirección General de la Policía (en adelante DGP) ha llegado a un acuerdo para proporcionar al MITYC acceso a la lista de certificados revocados(CRL) del DNI-e. El Sistema de Gestión de Certificados (SGC) que actualmente existe en el MITYC, realiza la validación de certificados X.509 v3 de laFNMT y de otros prestadores de servicios de certificación mediante el acceso remoto a listas de CRLs (vía LDAP o interfaces normalizados)

Portal de soporte y divulgación

Se está creando un sitio web para soporte y divulgación del uso del DNI-e basado en el gestor de contenidos MS CMS dirigido a los sectores industriales, y en particular a la pyme y micropyme que al menos dispondrá de las siguientes áreas:

  • Área de formación, que reúna todo el material formativo disponible, incluyendo guías, casos de éxito, recomendaciones, manuales así como material multimedia expresamente desarrollado sobre el uso del DNI-e.
  • Área de servicios, que permita el acceso a servicios de valor añadido basados en el uso del DNI-e
  • Área de información, que proporcione información divulgativa sobre la existencia y actividades llevadas a cabo en el Demostrador del Centro de Soporte para el DNI-e

Servicios de Valor Añadido

Se desarrollarán servicios de valor añadido basados en los componentes de firma generados y accesibles a través del portal creado.

Entre ellos se facilitarán las siguientes utilidades relacionadas a continuación.

Servicio de firma de documentos electrónicos

A partir de los componentes de firma desarrollados (ya mencionados) se implementará un servicio de firma de documentos electrónicos accesible vía web.

Servicio de verificación de firma y formato de documentos electrónicos

A partir de los componentes de firma desarrollados se implementará un servicio de verificación de firma y formato de documentos electrónicos accesible vía web.

Servicio de visualización de documentos firmados

A partir de los componentes de firma desarrollados se implementará un servicio de visualización de documentos firmados accesible vía web.

Servicio de sellado de tiempo

A partir de los componentes de firma desarrollados se implementará un servicio de sellado de tiempo accesible vía web.

Servicio de validación de certificados

Incluyendo la validación de certificados de PSC publicados en la web del MITYC y el servicio de validación de los certificados del DNI-e.

Sistema de CRM

En la actualidad el MITYC dispone de una herramienta de CRM desarrollada a partir del producto de software libre OpenCRX que da servicio a las siguientes aplicaciones:

  • Usuarios de Telecomunicaciones
  • Televisión Digital Terrestre
  • Oficina Virtual
  • Servicio de Información Administrativa
  • Ayudas

Se realizará la adaptación de esta herramienta para dar servicio de atención telefónica a las dudas planteadas por los usuarios de los sectores empresariales, pymes y micropymes, en lo relativo a la implantación y utilización práctica de la firma electrónica y la factura electrónica basadas en el DNI-e.

El sistema estará integrado por, al menos, dos niveles técnicos desoporte:

  • Nivel 1, formado por los operadores, que dará respuesta a cuestiones básicas
  • Nivel 2, formado por un grupo de técnicos, que dará respuesta a las preguntas que les sean remitidas por los operadores.

Una vez resueltas serán comunicadas al operador para que remita las respuesta al usuario.

Contenidos divulgativos sobre el uso empresarial del DNI-e

Utilizando como soporte el portal creado para la divulgación del uso del DNI-e por parte del mundo empresarial, se generará documentación que contribuya a su difusión y formación.

Se realizará un estudio previo que permita determinar la justificación o no del uso de una solución de eLearning o blended-eLearning basada en plataforma CMS, LMS o LCMS.

La documentación generada, públicamente disponible, estará integrada por: material multimedia, guías, casos de éxito, recomendaciones y manuales.

Deberá ser de alta calidad tanto técnica como didáctica. Se prestará especial atención a difundir las tareas a realizar por parte de las unidades de informática de las empresas del sector industrial para implantar soluciones basadasen el DNI-e, entre las que destacan:

  • Instalación de certificados raíz y subordinados de la Autoridad de Certificación para el DNI-e en los servidores.Se detallarán las particularidades para los entornos operativos más extendidos en la actualidad (Windows Server 2003, Unix – Solaris, HP-UX- y GNU/Linux – Debian, RedHat, SuSE) y los servidores web más utilizados (Apache y Microsoft IIS).
  • Instalación de certificados raíz y subordinados de la Autoridad de Certificación para el DNI-e en los clientes. Se detallarán las particularidades para los navegadores más extendidos en la actualidad (MS Internet Explorer, Firefox, Opera, Mozilla)
  • Verificación y configuración de los propósitos de los certificados raíz instalados
  • Instalación en los clientes de los módulos criptográficos necesarios para el acceso a los certificados contenidos en el soporte físico del DNI-e para los diferentes. Se detallarán las particularidades para los sistemas operativos y navegadores más extendidos en la actualidad
  • Verificación y configuración de la configuración de seguridad del sistema operativo para permitir la descarga de los componentes necesarios.

Acciones formativas sobre el uso del DNI-e

Se elaborará documentación multimedia en soporte CD/DVD que sirva para realizar acciones formativas dirigidas a empresas y representantes de los diferentes sectores implicados mediante la organización de jornadas sectoriales y seminarios. En particular se dirigirán a:

  • Sectores con relación directa con los consumidores: Financiero, Energético, Telecomunicaciones, Seguros, Grandes superficies, Transporte (aéreo, ferrocarril y autobús), Agencias de viajes
  • Microempresas y PYMES de los siguientes sectores: Eléctrico, Telecomunicaciones, Seguros, Pequeño y mediano comercio, Minero, I+D, Químico, Industrial, Farmacéutico, Agencias de viajes.

Estudio y desarrollo del pago electrónico basado en el DNI-e

Se elaborará un estudio sobre normalización y especificaciones del pago electrónico basado en el DNI-e que garantice la interoperabilidad y estandarización de los sistemas a implementar, sin necesidad de utilizar un nodo intermedio, a través de un mecanismo bilateral entre el ordenante del pago y la entidad financiera que origine un movimiento de fondos a favor de una Administración Pública.

Tratándose de un elemento esencial para el desarrollo del comercio electrónico, cobra especial importancia el papel a desempeñar por operadores de telecomunicaciones, entidades financieras y legisladores.

Entre la normativa jurídica a considerar se encuentra la Ley 44/2002,de 22 de Noviembre, de Medidas de Reforma del Sistema Financiero (transposición de la Directiva 2000/46/CE) y la Ley 19/1985, de 16 de Julio, Cambiaria y del Cheque. El sistema que se desarrolle permitirá realizar operaciones telemáticas de pago basándose en la utilización de la firma electrónica reconocida.

Constará de dos subsistemas, uno a implementar en cualquier Organismo Público que recaude por vía telemática tasas y precios públicos (en adelante ORC, Organismo Responsable de Cobro), y otro en la Entidad Financiera de que se trate.

Estudio y desarrollo del documento y la factura electrónicos basados en el DNI-e

Se elaborará un estudio orientado a la definición del formato normalizado para el documento electrónico y la factura electrónica basados en el DNI-e, a partir del formato definido por la AEAT.

El núcleo jurídico actual para lafactura electrónica está integrado por la Orden HAC/3134/2002, de 5 dediciembre, sobre un nuevo desarrollo del régimen de facturación telemática, y la Resolución 2/2003 de 14 defebrero del Director General de la AEAT. Con la entrada en vigor del Real Decreto 1496/2003, de 28 de noviembre, por el que se aprueba el Reglamento por el que se regulan las obligaciones de facturación, y se modifica el Reglamento del Impuestos obre el Valor Añadido, se consolida la posibilidad de remitir las facturas por medios electrónicos, con el consiguiente ahorro de costes para las empresas.

Las obligaciones de las empresas que emiten facturas electrónicas son las siguientes:

  • Conservar los datos de las facturas. No es necesario conservar lasfacturas emitidas sino la «matriz» o Base de datos que permite generarlas
  • Asegurar su legibilidad en el formato original
  • Garantizar el acceso completo alas facturas: visualización, búsqueda selectiva, copia o descarga en línea e impresión
  • Firmar electrónicamente la factura o delegar esta acción en un tercero (subfacturación) o en el Receptor (autofacturación)
  • Contar con la aceptación por parte del receptor respecto al uso de esta modalidad de facturación

Las obligaciones de las empresas que reciben facturas electrónicas se resumen en:

  • Conservar las facturas recibidas en su formato original (electrónico) incluso aunque hayan sido necesarias transformaciones de datos internas. O delegar esta función en un tercero
  • Conservar la factura impresa con marcas gráficas PDF-417 (formato poco recomendable), o almacenada en otros tipos de soporte
  • Asegurar legibilidad en formato original
  • Garantizar acceso completo a las facturas: visualización, búsqueda selectiva, copia o descarga en línea e impresión
  •  Disponer de software que permita verificar la firma y la identidad del emisor, así como la vigencia del certificado

La e-factura deberá incorporar firma electrónica reconocida.

El sector financiero, de común acuerdo con la AEAT, propone un formato estándar de factura electrónica dirigido a las entidades de depósito y, en general, a quienes estén interesados en adoptarlo y que reúne las siguientes características:

  • Cumplimiento de los requisitos legales establecidos y de las condiciones establecidas por la AEAT para la facturación telemática
  • Universal: pueden utilizarlo todas las entidades de depósito y sus clientes
  • De libre uso: su utilización y posterior modificación no está sujeta al pago de cánones o a la autorización previa de una organización ajena al sector
  • Gratuito: se puede distribuir gratuitamente a las entidades de depósito y a sus clientes
  • Datos específicos de otros sectores económicos: preparado para admitir información consensuada y relativa a otros sectores económicos
  • Información Factoring: Permite registrar, opcionalmente, datos específicos de Factoring
  • Formato flexible, de fácil implementación e interoperabilidad, por lo cual, se ha seleccionado el lenguaje XML.

Sistema de verificación de la compatibilidad de los lectores de tarjetascon el DNI-e

Se desarrollará un sistema para la verificación de la compatibilidad de los lectores de tarjetas criptográficas con el DNI-e.

El laboratorio de pruebas del MITYC, a petición de empresas importadoras, fabricantes o distribuidoras, emitirá un distintivo que acredite la compatibilidad de lectores de tarjetas criptográficas con el DNI-e.

Estudio sobre el impacto y posible utilización del DNI-e en cajeros y terminales de puntos de venta

A partir del análisis del parque de cajeros automáticos de entidades financieras y TPVs existentes actualmente en el mercado español, se realizará un estudio sobre las posibilidades y servicios a ofrecer a través de estos dispositivos mediante el uso del DNI-e.

Las diez actuaciones que se estánllevando a cabo estarán terminadas a finales de marzo de 2007 y van a permitir a la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información disponerde un centro avanzado de tecnología sobre el uso del DNI electrónico que será responsable de ofrecer al sector empresarial, PYMES y MICROPYMES asesoramiento, formación especializada, soluciones, componentes, servicios y programas para utilizar la firma electrónica, los documentos electrónicos y la factura electrónica, actuaciones que serán decisivas para incorporar las TIC en estos sectores, para el desarrollo del comercio electrónico y con ello el impulso y desarrollo de la Sociedad de la Información.

Rescate de proyectos de Factura Electrónica


Gracias a los múltiples cursos y seminarios que impartimos en Albalia Interactiva sobre Factura Electrónica, vamos siendo bastantes conocidos en esta especialidad (supongo que en los últimos meses ha influido también el que yo sea el coordinador del Grupo de Trabajo de eFactura de ASIMELEC).

Hace unos días echábamos cuentas y llegamos a la conclusión de que desde el año 2004 hemos impartido más de 50 seminarios de factura electrónica y hemos formado en este tema a más de 2.000 personas .

En ocasiones nos llaman para impartir formación «in-company» en una empresa que «ya tiene hecho el proyecto» y requiere que el personal implicado reciba una cierta capacitación.

Y es entonces cuando vemos que muchos proyectos se han quedado «a medias». Por formatos de factura, por modalidades de firma, por la correcta cumplimentación de los campos obligatorios de la factura, por la consideración equivocada de las notas de abono (que no existen, en su lugar se deben utilizar las facturas rectificativas) ,…

Es cierto que hay bastantes empresas técnicas y consultoras que se han subido al carro de la «factura electrónica» y prometen la «solución completa» a sus  clientes, pero como en el chiste del infierno español, cuando no falta la escalera, falta la brocha, y si no el bote de pintura.

La correcta implementación de un proyecto requiere analizar las necesidades y el rol principal de la empresa frente a sus interlocutores (de emisión o de recepción de facturas), conocer el impacto que la normativa tiene en su operativa actual y en la que se implantará tras el proyecto, definir el formato de firma y de factura de la forma que más sencillo sea el uso para el receptor de factura, seleccionar el Prestador de servicios de certificación, redactar cláusulas en los «trading partner agreements», definir si se usará un Dispositivo Seguro de Creación de Firma en la forma de un HSM (hardware security module), resolver el sistema de timestamping y de validación OCSP,…

La solución completa, si se quiere hacer bien, requiere de ciertos conocimientos de estándares de firma y factura electrónicas, cuya ignorancia es  asumible en una PYME, pero no en quienes les proporcionan las soluciones técnicas. Y desde luego, en las grandes empresas que dedican recursos técnicos y económicos de cierta envergadura, son inaceptables las «chapuzas» que estamos descubriendo, en algunos casos, tras proyectos llevados a cabo por consultoras y empresas tecnológicas «grandes».

En este contexto me preocupa el papel de las entidades financieras. Se espera de ellas que proporcionen un interfaz a sus clientes que diluya la aparente complejidad de un buen sistema de factura electrónica en un entorno de uso sencillo. Y con probabilidad van a ser la palanca arquimediana que dispare la adopción de la factura electrónica en las PYMES. Por eso, su responsabilidad es mayor. Afortunadamente, unas pocas iniciativas que conozco bastante bien van bien orientadas y espero que sirvan de modelo para sus competidores. Pero la información indirecta que recibo de otras me provoca cierta inquietud.

Cuando nos avisan con cierto margen podemos dar en las empresas ciertas indicaciones que ayuden a sus responsables a tomar las decisiones correctas en el proyecto, y lo esencial de nuestra asesoría se puede desarrollar en un par de días. Pero si el proyecto está avanzado, explicar qué es lo que se está haciendo mal es un poco frustrante para quienes ya llevan invertido tiempo y dinero. Por eso prefiero que nos convoquen para el «rescate de proyectos» de factura electrónica en las etapas más tempranas que sea posible.

Exposec 2007 visita Málaga


El próximo 15 marzo tendrá lugar en Málaga el Evento Exposec 2007, Jornada sobre Seguridad Informática enmarcada en una serie con la que ASIMELEC está recorriendo media España.

En esta ocasión la Organización cuenta con la colaboración de Unicaja, por lo que el evento tendrá lugar en el Salón de Actos de Unicaja, sito en la Plaza de la Marina, 1 .- 29015 Málaga y dará comienzo a la 9:00 de la mañana.

Hay más información sobre este evento  en el web de Exposec 2007.

Yo impartiré una conferencia sobre «Factura Electrónica» contando las últimas novedades que se han producido en la estandarización de formatos de factura y firma eletrónica y explicando un poco la actividad del Grupo de Trabajo de eFactura de ASIMELEC.

En España se emiten 4.800 millones de facturas al año


A pesar de que es un dato que no figura en las estadísticas del INE, en Albalia Interactiva hemos podido estimar que en España se emiten cada año 4.800 millones de facturas.

Considerando que el número de empresas activas se cifra en 3.174.393, según la última actualización del Directorio Central de Empresas (DIRCE) a 1 de enero de 2006, la cifra indicada supondría que cada empresa expide o recibe 1.500 facturas al año en promedio.

Aunque la cifra parece elevada, hay que considerar que empresas como Telefónica emiten cada año más de 80 millones de facturas, y un número elevado de empresas supera el millón de facturas expedidas al año.

Entre las empresas del club del millón de facturas, cabe señalar a las siguientes:

  • Vodafone emite más de 50 millones de facturas al año
  • Orange emite en su división de teefonía móvil 15 millones de facturas al año
  • Carrefour España gestiona más de 6 millones de facturas por año
  • Caprabo  maneja unas 4, 8 millones de facturas al año
  • Consorcio de Aguas Bilbao Bizkaia supera los 1,8 millones de facturas anuales
  • Bimbo emite aproximadamante 1,8 millones de facturas anuales

Desde el punto de vista del tamaño, las empresas españolas se siguen caracterizando por su pequeño tamaño. Más de 1,6 millones de empresas (el 50,9% del total) no emplea a ningún asalariado y otras 881.000 (el 27,8% del total) tienen entre uno y dos empleados. Si se suman estos dos grupos, resulta que casi ocho de cada 10 empresas tienen dos o menos asalariados. Por su parte, si se considera sólo a las empresas con asalariados, las que emplean a 20 o más trabajadores apenas representan el 5,6% del total. Este segmento, que es el más amplio,  intercambia del orden de 200 facturas anuales.

Por otro lado, en el sector del comercio, los tickets, «documentos sustitutivos de factura» consituyen una herramienta de amplia difusión.

Con que el 30 % de las facturas se gestionaran electrónicamente las empresas españolas se ahorrarían más de 2.000 millones de euros al año.

Próximo Congreso de Factura Electrónica y Digitalización Certificada


El próximo dia 24 de abril de 2007 tendrá lugar en el Palacio de Congresos de Madrid el II Congreso Nacional de Factura Electrónica y Digitalización Certificada promovido por ASIMELEC.

Este evento pretende refrendar el éxito del I Congreso Nacional de Factura Electrónica y Digitalización Certificada que tuvo lugar el 18 de Octubre del 2006.

Ya están confirmados los patrocinadores del año pasado, que repiten en esta ocasión. En estos momentos estamos abriendo la posibilidad de patrocinio a otras entidades. Para tratar este tema, hay que llamar al 902 365 612.

El precio de asistencia al evento es de 300 euros+ IVA (16%), para el primer inscrito y 225+ IVA (16%) para los siguientes inscritos de la misma empresa. Las empresas asociadas a ASIMELEC, podrán enviar gratuitamente una persona. Si desean inscribir a más de un asistente abonarán 100 euros+ IVA (16%) por cada inscrito a partir del segundo.

Va a ser, con certeza, el evento más importante del año en relación con la Factura Electrónica.

Exposec 2007 en Reus


Anteayer tuvo lugar en Reus la primera jornada del año 2007 del Programa Exposec 2007 organizado por ASIMELEC.

El evento, que tuvo lugar en las magníficas instalaciones del recinto ferial de Reus, contó con la inauguración oficial por parte de D. Félix Oliva, vicepresidente de la Cámara de Comercio de Reus, y la clausura de D. Jordi Masias, Director General de CatCert-AGENCIA CATALANA DE CERTIFICACION.

En las Jornadas, D. Santi Casas, Asesor de ASIMELEC llevó a cabo la introducción «Análisis de la seguridad como concepto global«, yo hablé sobre «Factura electrónica«, D. Enric Hernández Responsable del área de Seguridad y PKI de ANCERT-Agencia Notarial de Certificación, aclaró aspectos sobre formatos de firma electrónica a largo plazo, José Helguero Director General de HELAS CONSULTORES introdujo las exigencias que impone la LOPD y la LSSI a las empresas y los cambios que se esperan en relación con dichas normas y D. Emilio Castellote Director de Marketing de Producto de PANDA SOFTWARE disertó sobre la evolución del MALWARE y las técnicas de defensa más actuales.

Los aspectos más relacionados con la identidad digital se trataron en la parte final de la jornada, D. Ignacio Alamillo Responsable de la Asesoria Jurídica de CATCERT-Agencia Catalana de Certificación los trató especialmente desde el punto de vista de la Administración Pública, haciendo referencia, entre otros elementos al DNI electrónico. En el mismo contexto, Jorge Gómez Director General deC3PO hizo una introducción a los elementos constitutivos de la firma electrónica y a su uso con trajetas chip y la clausura de Jordi Masias hizo un repaso histórico a los 13 años de firma electrónica en España en los que él mismo ha tenido un papel relevante, junto con otros pioneros.

El nivel de asistencia fue muy considerable tanto en número como en interés de los asistentes, lo que quedó de manifiesto por las preguntas formuladas en el evento.

Al finalizar, en torno a las 15:00 horas, se produjo todavía cierto debate en los pasillos, lo que siempre es un ánimo para los ponentes que vamos a estos eventos y que así obtenemos cierta realimentación sobre el interés de los temas abordados.

Las próximas fechas son:

  • 15-Marzo-2007 Málaga
  • 19-abril-2007 Vigo
  • 17-Mayo-2007 Fuerteventura – Puerto del Rosario
  • 18-Mayo-2007 La Gomera – San Sebastián
  • 14-Junio-2007 Ciudad Real

Os animo a los que seais de la zona a avisar a vuestros conocidos, ya que es una mañana dedicada a tratar temas de gran actualidad que nos pueden ahorrar muchos quebraderos de cabeza sabiendo como enfocar determinados problemas. Y gratis.

Preguntas frecuentes sobre UBL


En el sitio web de OASIS está disponible un resumen (FAQ) sobre las preguntas que se formulan con más frecuencia sobre este estándar y que me he permitido traducir :

  1. ¿Qué es UBL?UBL, Universal Business Language, la lengua de negocios universal, es el producto de un esfuerzo internacional de definir una biblioteca de uso libre (libre de derechos) de los documentos de negocio electrónicos estándares en XML tales como pedidos y facturas de compra. Desarrollado en un comité técnico del OASIS abierto y responsable con la participación de una variedad de organizaciones que desarrollan, UBL se diseña para dar cobertura a las prácticas de negocio en diferentes ámbitos: legal, auditoría, gestión de procesos, y expedientes, eliminando la reintroducción de datos en lprocesos de gestión de la cadena de suministro como los habituales basados en fax o papel y proporcionando un punto de entrada al comercio electrónico para las pequeñas y medianas empresas.
  2. ¿De dónde sale UBL?La iniciativa de UBL se originó en los esfuerzos que a mediados de 1999 pretendían crear un sistema de XML estándar para “documentación de oficina y gestión” dentro de OASIS. El trabajo del Comité Técnico «OASIS OfficeDoc» bajo la dirección de Murray Altheim de Sun Microsystems fue la base de trabajo cuando OASIS y UN/CEFACT comenzaron la colaboración en ebXML en diciembre de 1999. El interés en la creación de una sintaxis estándar de XML para los documentos comerciales básicos se restableció otra vez en mayo de 2000 con la decisión en ebXML de omitir una sintaxis estándar del “payload” (contenido semántico de los mensajes) de XML del sistema inicial de entregables de ebXML. El grupo de trabajo que pasó a ser conocido como UBL comenzó en abril de 2001 como grupo de discusión patrocinado por CommerceNet y fue establecido como comité técnico de OASIS en noviembre de 2001.
  3. ¿Cómo está UBL ahora?UBL 1.0 se lanzó como estándar de OASIS el 8 de noviembre de 2004 tras tres años de desarrollo y de revisión pública.UBL 2.0, que amplía ampliamente el alcance de UBL, se aprobó como especificación del comité del OASIS en octubre de 2006 y se ha sometido a OASIS para su ratificación como estándar de OASIS, lo que se ha producido en diciembre de 2006.
  4. ¿Cómo puedo conseguir el paquete de UBL 2.0, y qué hay dentro?UBL 2.0 se puede descargar como solo archivo zip de:

    http://docs.oasis-open.org/ubl/cs-UBL-2.0.zip

    El paquete del lanzamiento de UBL contiene

    • Una introducción explicativa
    • Esquemas de XML para 31 documentos de negocio básicos:
      • ApplicationResponse
      • AttachedDocument
      • BillOfLading
      • Catálogo
      • CatalogueDeletion
      • CatalogueItemSpecificationUpdate
      • CataloguePricingUpdate
      • CatalogueRequest
      • CertificateOfOrigin
      • CreditNote
      • DebitNote
      • DespatchAdvice
      • ForwardingInstructions
      • FreightInvoice
      • Factura
      • Pedido
      • OrderCancellation
      • OrderChange
      • OrderResponse
      • OrderResponseSimple
      • PackingList
      • Cita
      • ReceiptAdvice
      • Recordatorio
      • RemittanceAdvice
      • RequestForQuotation
      • SelfBilledCreditNote
      • SelfBilledInvoice
      • Declaración
      • TransportationStatus
      • Hoja de ruta
    • Una descripción detallada de los procesos genéricos de contratación y transporte dentro de los cuales los tipos UBL funcionan.
    • Una biblioteca de casi dos mil elementos de datos de XML basados en la especificación técnica de los «Core Components» (ISO 15000-5)
    • Una breve descripción de la metodología del desarrollo de UBL
    • Los diagramas de UML del modelo de datos completo de UBL
    • Hojas de cálculo de Excel y de OpenOffice que demuestran los modelos de los datos de cada uno de los documentos de UBL y de la biblioteca del componente de UBL
    • Reglas de denominación y diseño de UBL que especifican la generación de esquemas de UBL desde los modelos de datos de UBL
    • Especificaciones legibles por máquina de los valores prefijados para todas las listas de código usadas en UBL
    • Una especificación ASN.1 para documentos UBL en forma binaria

    El paquete de la ayuda de UBL 2.0, aun preparación, proporcionará otros materiales de ayuda en el desarrollo de aplicaciones UBL.

  5. ¿Dónde puedo discutir de UBL con otros usuarios?
  6. La lista pública de desarrolladores ubl-dev de OASIS proporciona un foro para preguntas y comentarios con respecto a UBL. El archivo ubl-dev se localiza en

    http://lists.oasis-open.org/archives/ubl-dev/

    Las suscripciones a ubl-dev se pueden hacer a través del encargado de la lista de OASIS en

    http://www.oasis-open.org/mlmanage/index.php

  7. UBL 2.0 es asombrosamente avanzado para ser el trabajo de un comité técnico de voluntarios. ¿Cómo es posible?Una decisión temprana importante y polémica del UBL TC fue basar su trabajo en un sistema pre-existente de esquemas de negocio de XML. En vez de empezar desde cero, el UBL TC aceptó la contribución de CommerceOne y SAP de un vocabulario XML comercial de negocios ya extensamente desplegado, xCBL 3.0.La decisión a comenzar con el xCBL se basó en cuatro consideraciones dominantes.Primero, el xCBL 3.0 era una especificación madura de XML usada ya en un número de mercados de comercio electrónico.En segundo lugar, el xCBL se basaba en un modelo de librería de componentes, lo que aseguraba una alineación mucho mejor entre los tipos del documento derivados de la librería que había sucedido con anteriores estándares de mensajes, en los cuales los diversos tipos de documentos se desarrollaron independientemente.Tercero, el xCBL se publicó bajo términos que permitieron la creación libre de trabajos derivados.Y en cuarto lugar, CommerceOne y SAP estaban dispuestos a sostener su contribución con los recursos técnicos que apoyaron significativamente el desarrollo inicial de UBL.UBL se ha desarrollado desde entonces independientemente hasta el punto en el que apenas quedan vestigios del  xCBL original, pero la decisión de comenzar con una especificación ya acertada dio a UBL una ventaja de tres años de la que continúa gozando hoy. En estos momentos, UBL 2.0 representa más de ocho años de desarrollo continuo en la creación de una sintaxis estándar del negocio en  XML.
  8. ¿Quién es dueño de UBL?UBL es propiedad de OASIS, una organización sin ánimo de lucro dedicada al desarrollo abierto de  estándares públicos de XML. UBL se mantiene por un comité técnico de OASIS compuesto de expertos  en XML y en procesos de negocio.
  9. ¿Cuánto cuesta el uso UBL?La respuesta simple es que UBL se puede usar de forma libre de derechos («royalty-free» RF). Puede ser utilizada sin coste por cualquier persona. Más exactamente, el Comité Técnico de UBL funciona en el modo de «derechos de propiedad intelectual » de OASIS (IPR: Intellectual Property Rights) conocido como “RF en términos limitados,” que “requiere todos los participantes están obligados licenciar sus reivindicaciones esenciales usando los elementos de licenciar Royalty Free descritos en las secciones 10.2.1 y 10.2.3” de la política de IPR de OASIS, de la que se puede obtener una copia en:

    http://www.oasis-open.org/who/intellectualproperty.php

  10. UBL proclama que es  “universal,” pero todas sus definiciones de términos de negocio están en inglés. ¿Cómo se pueden entenderlos  documentos UBL sin saber inglés?La mayoría de la gente utilizará los documentos UBL a través de un software que presenta automáticamente la información relevante a través de un interfaz adaptado al pais, así que la pregunta importante aquí es cómo se puede hacer UBL para que se pueda utilizar de la forma más sencilla por los diseñadores del software y los analistas de negocio. Para resolver estas necesidades, los subcomités de localización de UBL (adaptación idiomática y de usos de negocio de ciertos lugares)  han traducido las definiciones de UBL 1.0 y los términos del negocio al chino (simplificado y tradicional), japonés, coreano, y español; los resultados están disponibles como el diccionario internacional de datos de UBL 1.0 (IDD, Internatonal Data Dictionary) en

    http://www.oasis-open.org/committees/download.php/15631/cd-UBL-1.0-IDD-1.ods
    http://www.oasis-open.org/committees/download.php/12243/cd-UBL-1.0-IDD-1.sxc
    http://www.oasis-open.org/committees/download.php/12242/cd-UBL-1.0-IDD-1.xls

    Se espera que el trabajo de preparación de IDD para UBL 2.0, que ya ha comenzado, tarde más o menos un año.

  11. ¿De qué maneras UBL da soporte a una transición gradual del comercio sobre papel al comercio electrónico?UBL supone un enfoque claramente centrado en el documento del comercio electrónico que se focaliza en  estandardizar los datos de negocio de forma que encajen en los documentos en papel tradicionales.  El estándar internacional principal para los formularios en papel de los documentos tradicionales es el UN Layout Key de la O.N.U, que durante más de 40 años ha servido como modelo para los documentos de papel usados en comercio internacional. La equivalencia de todos los documentos de UBL a sus equivalentes UN Layout Keys es parte de la norma  UBL 1.0. Están disponibles de forma gratuita tanto hojas de estilo de UBL 1.0 XSL-FO  como  un procesador de hojas de estilo UBL 1.0 XSL-FO  de Crane Softwrights (http://www.CraneSoftwrights.com/links/res-ublo.htm) para convertir documentos de UBL 1.0 a sus equivalentes  de Layout Keys en HTML y pdf, y también hay software libre de Java basado en la biblioteca de Crane Softwrights ofrecido por Ambrosoft (http://ambrosoft.com/) para transformar directamente cualquier documento de UBL en el HTML en conformidad con los Layout Keys de  la O.N.U. Actualmente se está llevando a cabo el trabajo de adecuar estas herramientas a la versión UBL 2.0
  12. ¿Cómo trata UBL los aspectos legales del comercio sin papeles?

    Desde el principio, un objetivo clave de UBL ha sido proporcionar al mundo los estándares para las versiones electrónicas de los documentos de negocio tradicionales diseñados de forma que se reconocen las prácticas comerciales y legales establecidas. El verdadero desarrollo  del comercio internacional «sin papel» requiere de la cooperación entre naciones instituir códigos legales uniformes que rijan la substitución por documentos electrónicos de sus equivalentes en papel. La contribución de UBL a este esfuerzo descansa en la definición de un sistema estándar de formatos XML y en la intensa cooperación con las organizaciones que trabajan en el establecimiento de una infraestructura internacional de ecommerce (commercio electrónico).Desde  diciembre de 2001, UBL ha estado de forma destacada en la agenda del grupo de gestión de ISO IEC ITU UN/ECE eBusiness MoU , del que OASIS es miembro sin voto. Este grupo maneja relaciones con respecto a estándares electrónicos de negocio entre las organizaciones señaladas en el GATT (General Agreement on Tariffs and Trade, Acuerdo General de Tarifas y Comercio). OASIS es también un enlace de Clase A con el comité de la ISO TC 154, que es responsable de la estandardización internacional de la sintaxis de documentos electrónicos tales como EDIFACT. Siempre ha sido un propósito del Comité Técnico UBL TC solicitar la remisión de UBL a la ISO tras su aprobación como estándar de OASIS.
  13. ¿Cuál es la relación de UBL con ebXML?El impulso para comenzar el UBL TC provino del deseo de varios participantes del ebXML de definir un formato estándar de payload XML (contenido expreso del mensaje) para el ebXML . Es decir, el equivalente en XML a los estándares tradicionales de EDI tales como X12 y EDIFACT. Según se describe en ebxml.org, el conjunto de especificaciones ebXML,  muchas de las cuales forman parte en la actualidad del estándar ISO 15000, proporciona una infraestructura basada en XML completa, de nueva generación que da soporte a la funcionalidad de EDI sobre redes Internet. UBL proporciona un formato de datos estándar para los mensajes que se intercambiarán en este tipo de infraestructura. Sin embargo, UBL se diseña para ser “agnóstico” con respecto a la infraestructura, y los mensajes de UBL se pueden utilizar en una gama muy amplia de contextos funcionales, desde las arquitecturas orientadas a servicio (SOA, service-oriented architecture) complejas al intercambio simple de documentos vía el email.
  14. ¿Cuál es la relación de UBL con los Core Components (componentes de base) de ebXML?UBL es la primera puesta en práctica verdadera del cuerpo de  estándares de la especificación técnica de los componentes de base del ebXML (Core Components Technical Specification, CCTS 2.01, también conocidos como ISO 15000-5). La biblioteca de UBL consiste en entidades de la información del negocio CCTS de ebXML (Business Information Entities , BIE). Los esquemas de UBL XML se definen con el uso de las reglas de denominación y diseño (Naming and Design Rules, NDR) de UBL  a un modelo de datos subyacente que encaja en los tipos de Core Components. UBL está trabajando actualmente de forma conjunta con el grupo de trabajo  de UN/CEFACT TBG17 para asociar UBL a la biblioteca de componente de base (core components) estándar y con el UN/CEFACT ATG y OAGI para desarrollar un solo estándar internacional para la representación en XML de los tipos de Core Components de ebXML y de Unqualified Datatypes.
  15. ¿Cuál es la relación entre UBL y UN/CEFACT?UN/CEFACT es la agencia internacional responsable de la facilitación comercial y de los estándares de EDI. UN/CEFACT y OASIS desarrollaron bXML conjuntamente.En agosto de 2003, UN/CEFACT indicó que “UN/CEFACT apoyará solamente una aproximación centrada en el documento para contenido XML, y su deseo es que UBL será la fundación para ese acercamiento.”

    Según  el acuerdo de la cooperación entre el OASIS y UN/CEFACT de junio de 2005,  OASIS y UN/CEFACT han publicado una declaración de la colaboración que establece que:

    1. UN/CEFACT reconoce la especificación UBL 2 como la base XML  adecuada para eBusiness desde la perspectiva de constituir la primera generación.
    2. Para OASIS y UN/CEFACT:
      • los entregables futuros de UN/CEFACT constituyen la via de evolución de UBL, y
      • el mantenimiento de UBL 2 se llevará a cabo en el marco del comité técnico OASIS UBL TC.
    3. En la expectativa que UN/CEFACT producirá su propio sistema integrado de esquemas XML en un período de tres años, OASIS no producirá ninguna otra versión importante de UBL más allá de la UBL 2.
    4. OASIS concederá a UN/CEFACT una licencia perpetua e irrevocable para crear trabajos derivados basados en UBL.

    Este reconocimiento de la O.N.U significa que cualquier persona que necesite documentos de XML para eBusiness puede adoptar con seguridad UBL como base adecuada en la actualidad y pensando en el futuro.

  16. ¿Qué distingue UBL de esfuerzos al parecer similares tales como RosettaNet y OAGIS?Hay algunas semejanzas entre UBL y otras iniciativas de estandarización de datos XML empresariales, pero en conjunto, las cualidades de UBL lo hacen único.
    • UBL se desarrolló en un proceso de estandarización totalmente abierto, públicamente visible, independientemente del proveedor de tecnologías, libre de derechos que permite lopinar a toda la comunidad de usuarios, no solo las grandes corporaciones que pueden permitirse pagar las fuertes tarifas de los consorcios. ¡No tienes que firmar un acuerdo de confidencialidad para trabajar con UBL o de hablar de el!
    • Muchos de los vocabularios empresariales XML  actualmente disponibles  se optimizan para apoyar los requisitos de negocio de industrias verticales específicas. UBL se diseña para trabajar horizontalmente en todos dominios, lo que lo hace ideal para cubrir las necesidades de usuarios tales como los gobiernos que deban imponer un formato estándar a interlocutores que intercambian mensajes en diferentes industrias.
    • UBL es el primer estándar que se basa  en la especificación técnica de los componentes de base de ebXML (ebXML Core Components Technical Specification) es decir ISO 15000-5.
    • UBL está también totalmente actualizado con respecto a tecnología de esquemas y a diseño de bibliotecas. El esquema UBL de Reglas de Denominación y Diseño (Naming and Design Rules), desarrollado por un grupo de destacados  expertos en esquemas XML, está siendo adoptado y copiado ampliamente por otras iniciativas de definición de XML. Y la aproximación a biblioteca de componentes de la definición de documentos situa a UBL muy por delante de otras iniciativas más veteranas en las que  los varios tipos de documentos se definieron aisladamente.
    • Para reducir el trabajo de la estandardización del ecommerce a proporciones manejables, UBL distingue claramente entre el problema de la estandardización de datos y el problema de estandardización de procesos. UBL se centra en la estandarización de los datos empresariales como el primer paso hacia la integración global del ecommerce, dejando la estandardización de los procesos de negocio a las comunidades de usuarios y asumiendo que la definición de procesos se tratará en una capa separada del conjunto. Una ventaja subsidiaria de este enfoque es que hace UBL apropiado en  la gama más amplia de tecnologías de definición de procesos.
    • Para proporcionar un puente entre los flujos de trabajo tradicionales basados en papel y el comercio electrónico, UBL está muy centrado en el documento, preservando la transparencia para los usuarios humanos y encajando de forma muy fluida en  los procesos basados en el intercambio de instrumentos legalmente vinculantes. Dicho de otra forma, UBL se centra en el “espacio público” entre las empresas más que en el “espacio privado” dentro de ellas,  y por lo tanto se ajusta mejor a los intercambios B2B que las bibliotecas de esquema diseñadas para la integración interna de aplicaciones.

    Para resumir, UBL no intenta competir con los vocabularios empresariales XML existentes sino pero resolver las necesidades que no están siendo resueltas adecuadamente por cualesquiera de ellos.

  17. ¿Cómo hace frente UBL a las necesidades de adaptación para cumplir diferentes requisitos empresariales?En muchos entornos de PYMES, los formularios normalizados pueden satisfacer sus requisitos lo suficientemente bien como para ser utilizados sin modificación. La existencia de formularios de papel normalizados tales como el UN Layout Key   de la O.N.U lo demuestra. En estos ambientes, UBL puede utilizarse tal como está.Es verdad, sin embargo, que diversas industrias tienen diversos requisitos para sus datos, y que esto ha llevado en el pasado a la proliferación de variantes incluso en los estándares tan rigurosamente controlados como X12, EDIFACT, y RosettaNet.

    UBL no pretende ser una solución completa a este problema sino que por el contrario supone un acercamiento extremadamente pragmático que debería llevar a soluciones satisfactorias en la gran mayoría de los casos que se presentan en el mundo real. Cada esquema  UBL 2.0 contiene un área opcional de extensión en la que los interlocutores puedan, según acuerden, incluir cualquier dato no cubierto por la estructura de datos predefinida en UBL que ya es de por sí  muy extensa. El mantenimiento de esta área de la extensión y la coordinación de su uso es, por supuesto, la responsabilidad de los interlocutores. Pero esta estrategia tan simple permite una flexibilidad casi ilimitada en relaciones de intercambio sin requerir la modificación de los esquemas estándares de UBL.

  18. ¿Qué hay de nuevo en UBL 2.0?Aparte de la nueva área de la extensión, el mayor cambio de UBL 2.0 es la incorporación de 23 nuevos tipos de documento para permitir la adaptación a escenarios ampliados de contratación consecución y procesos básicos de transporte. El desarrollo de estos nuevos esquemas fue financiado directa e indirectamente por los gobiernos de Dinamarca, Noruega, Suecia, Inglaterra, Finlandia, Islandia, Singapur, Hong Kong, y  Estados Unidos. La información práctica aportada hace que UBL 2.0 satisfaga las necesidades de contratación pública y del comercio internacional, al menos en sus requerimientos más básicos.UBL 2.0 también ofrece una respuesta al problema de la gestión de listas de códigos. En vez de asignar valores por defecto de listas de códigos vinculados directamente a los esquemas de documentoa, lo que hace el muy difícil el encaje de códigos entre interlocutores, UBL 2.0 expresa los valores de las listas de códigos en archivos separados usando el nuevo formato «genericode». Los valores prefijados se utilizan así para generar scripts de XSLT que validen los valores de códigos independientemente de los esquemas del estándar. Este acercamiento en dos fases no sólo soluciona la mayoría de los problemas de la gestión de listas de códigos sino que también permite que diversos subconjuntos de listas de códigos se asocien a diversos contextos en el uso del mismo documento, proporcionando una gran flexibilidad al especificar los valores de códigos aceptados en cada relación entre interlocutores, y establece una plataforma para la puesta en práctica de sofisticadas reglas de negocio sin necesidad de modificar los esquemas estándares de UBL 2.0. El lanzamiento de UBL 2.0 incluye un completo juego de módulos del software libre como muestra de la nueva estrategia de validación en dos fases.
  19. ¿Con qué exito se ha implantado UBL en el mundo real?Desde febrero de 2005, la factura UBL se ha impuesto por ley para todo el sector público  en Dinamarca. Cada mes, se intercambian en Dinamarca  1.2 millones de facturas UBL. El ministerio danés de finanzas estima unos ahorros para el estado de 100 millones de euros anuales por el uso de este tipo de documento. Cuando se implemente el pedido UBL en 2007, se estima que este ahorro se duplique. La adopción de UBL afecta 440 mil empresas en Dinamarca y ahora está en el proceso de imponer a las empresas suministradoras de software empresarial del norte de Europa  la capacidad de dar soporte técnico a la implantaciuón de este estándar.

    Desde octubre de 2005, la “Swed-invoice” (un subconjunto del mensaje de factura UBL adaptado al mercado sueco) se ha recomendad para cualquier uso en las administracione públicas por la Autoridad de Gestión Financiera Nacional Sueca (Swedish National Financial Management Authority). La NFMA estima que la estandardización de factura  UBL ahorrará el gobierno sueco 4 mil millones de SEK, coronas suecas (más de 500 millones de dólares) en los primeros cinco años del despliegue.

    En el Reino Unido, el sistema de gestión de mercado (marketplace) “Zanzibar”, creado por la oficina británica de soluciones de contratación pública (UK Office of Government Buying Solutions), se lanzó en febrero de 2006 con 14 documentos UBL 2.0.

    El proyecto de Gestión Electrónica de Carga (Electronic Freight Management, EFM) del Departamento de Transporte de E.E.U.U. (U.S. Department of Transportation) está experimentando actualmente con los mensajes UBL Despatch Advice (Aviso de Expedición) and Bill of Lading (Conocimiento de Embarque). Este proyecto experimental enlaza dos fabricantes chinos de ropa, dos transitarios, un operador de terminal de fletes aéreos, dos transportistas aéreos, un comprador norteamericano de ropa, un intermediario logístico (3PL, third-party logistics) y un corredor de importación en una demostración compleja de comercio electrónico avanzado ajustado al mundo real.

    Puesto que UBL está públicamente disponible y libre de derechos, no es posible hacer un seguimiento general de sus implementaciones más allá de las iniciativas estatales. Sin embargo, existe una gran expectativa de que la normativa actual y la que está en curso imponga a través de las administraciones públicas una adopción generalizada del estándar.

  20. ¿Es posible colaborar todavía con UBL?¡Sí! Cualquier persona interesada en el futuro desarrollo de UBL puede afiliarse a OASIS e incorporarse al comité técnico  UBL TC. Para hacerse miembro de OASIS acceda a la URL siguiente:

    http://www.oasis-open.org/join/

Entorno de pruebas para enviar facturas electrónicas a la AEAT


Como ya he comentado hace unos días, entre las novedades recientes de la eFactura de la AEAT está la posibilidad de utilizar el entorno de pruebas que permite probar el sistema a las empresas proveedoras de la AEAT.

En este POST recojo las principales características del entorno.

La comunicación se lleva a cabo con protocolo SOAP. El cliente se genera a partir del WSDL publicado a continuación.

En la página de la AEAT hay  un ejemplo válido de e-factura así como un modelo de hoja de estilo para una visualización del xml más amigable  los tags (etiquetas XML)  obligatorios y el esquema de la respuesta de la AEAT. Están todos empaquetados en un fichero zip para facilitar su descarga.

También se indica la descripción de campos y una política de firma simplificada.

La AEAT solo admite una factura por petición. Si se quieren incluir varias facturas en un mismo Lote no hay más que indicar el mismo número del Lote en cada petición, correspondiendo a cada número de factura.

Cada esquema en sus distintas versiones se tomará de la página de CCI dedicada a la eFactura.

Aunque ya se ha publicado la versión 2.0 del formato XML-CCI,  para las pruebas con la AEAT se utiliza en esta fase la Versión 1.2.

El tag <Emisor> se rellena con

<Emisor>
    <IdentificacionFiscal>
           <TipoPersona>F</TipoPersona>
            <TipoResidencia>R</TipoResidencia>
            <NumeroDocumento>99999999R</NumeroDocumento>
     </IdentificacionFiscal>
    <PersonaFisica>
         <Nombre>Juan Español Español</Nombre>
         <PrimerApellido />
         <DireccionNacional>
               <Direccion>La que sea</Direccion>
               <CP>El que sea</CP>
               <Poblacion>La que sea</Poblacion>
               <Provincia>La que sea</Provincia>
              <CodigoPais>ESP</CodigoPais>
          </DireccionNacional>
   </PersonaFisica>
</Emisor>

El tag <Receptor> se rellena con

<Receptor>
     <IdentificacionFiscal>
         <TipoPersona>J</TipoPersona>
         <TipoResidencia>R</TipoResidencia>
         <NumeroDocumento>Q2826000H</NumeroDocumento>
     </IdentificacionFiscal>
     <Centros>
        <Centro>
            <Numero>Si se pone habrá que poner uno válido como por ejemplo 19054</Numero>
            <DireccionNacional>
               <Direccion>Calle Sta María Magdalena 16</Direccion>
               <CP>28018</CP>
               <Poblacion>Madrid</Poblacion>
               <Provincia>Madrid</Provincia>
               <CodigoPais>ESP</CodigoPais>
            </DireccionNacional>
        </Centro>
     </Centros>
     <PersonaJuridica>
        <RazonSocial>AEAT</RazonSocial>
        <DireccionNacional>
           <Direccion>Calle Sta Maria Magdalena 16</Direccion>
           <CP>28016</CP>
           <Poblacion>Madrid</Poblacion>
           <Provincia>Madrid</Provincia>
           <CodigoPais>ESP</CodigoPais>
        </DireccionNacional>
     </PersonaJuridica>
</Receptor>

Se firma con cualquier certificado de persona física o jurídica perteneciente a alguna de los prestadores de servicios de certificación validados por la AEAT.  Los datos del certificado utilizado que identifican al firmante (NIF/CIF, nombre…), cuando no sea el propio obligado tributario emisor se incluyen en la etiqueta (tag) XML opcional «<Tercero>».

El envío de la petición de pruebas se lleva a cabo hacerse mediante un POST http a la URL de la AEAT  https://www5.aeat.es/L/WI00WID4P0D6/

Respuesta:

1) Una respuesta correcta aparecería como

<?xml version=»1.0″ encoding=»UTF-8″ ?>
   <env:Envelope xmlns:env=»http://schemas.xmlsoap.org/soap/envelope/«>
      <env:Header>
         <ds:Signature xmlns:ds=»http://www.w3.org/2000/09/xmldsig#»>
            <ds:SignedInfo>
               <ds:CanonicalizationMethod Algorithm=»http://www.w3.org/TR/2001/RECxml-c14n-20010315» />
               <ds:SignatureMethod Algorithm=»http://www.w3.org/2000/09/xmldsig#rsa-sha1» />
               <ds:Reference URI=»#AEATWID4P0D420061212094104159″>
                  <ds:Transforms>
                     <ds:Transform Algorithm=»http://www.w3.org/2000/09/xmldsig#enveloped-signature» />
                     <ds:Transform Algorithm=»http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments» />
                  </ds:Transforms>
                  <ds:DigestMethod Algorithm=»http://www.w3.org/2000/09/xmldsig#sha1» />
                     <ds:DigestValue>W9Ho8XV15BlcfjL+S6nk+8MCKFk=</ds:DigestValue>
               </ds:Reference>
            </ds:SignedInfo>
         <ds:SignatureValue>WHsu8zBunrxl84LBfLBOblPHxbGHvFP0qbuc8/p/K1mAOCuYgMZFYA6W0dflVaR6zVaH7RwciIBg
            tZ0XymrIMlYMVNOhVYz1x6HJpFkV15+Y3Po8eMToyIYK4xwTB444zzevRRj7qdHjsKZkYxivR7RxPgWCaBMYe0BHM2mu4/I=</ds:SignatureValue>
         <ds:KeyInfo>
            <ds:X509Data>
               <ds:X509Certificate>
                  MIIFHjCCBIegAwIBAgIEPHms0DANBgkqhkiG9w0BAQUFADA2MQswCQYDVQQGEwJFUzENMAsGA1UE
                  ChMERk5NVDEYMBYGA1UECxMPRk5NVCBDbGFzZSAyIENBMB4XDTA0MDQwNjE0MDQwN1oXDTA3MDQw
                  NjE0MDQwN1owgYAxCzAJBgNVBAYTAkVTMQ0wCwYDVQQKEwRGTk1UMRgwFgYDVQQLEw9GTk1UIENs
                  YXNlIDIgQ0ExEjAQBgNVBAsTCTUwMDA1MzA3NTE0MDIGA1UEAxQrTk9NQlJFIEVTUEHxT0wgRVNQ
                  QfFPTCBKVUFOIC0gTklGIDk5OTk5OTk5UjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAo5Jv
                  M9KS6FIAOanyikv6cJXK8FLzp7HDMimyl3PXvWBIcw7L7O6uET9Fj7lMFVMPUmvJ1ytGNQ/X5GM/  
                  ZmUTsp3wvAY8GPLhqV3efe/5NhRHNTmiqN32mqowy/99AT3Pxf7xRdDtCcc0gC19il0k4eCm8IkX
                  BsQGdh/HATis1LECAwEAAaOCAuwwggLoMGwGA1UdEQRlMGOkYTBfMRgwFgYJKwYBBAGsZgEEEwk5
                  OTk5OTk5OVIxFjAUBgkrBgEEAaxmAQMUB0VTUEHxT0wxFjAUBgkrBgEEAaxmAQIUB0VTUEHxT0wx
                  EzARBgkrBgEEAaxmAQETBEpVQU4wCQYDVR0TBAIwADArBgNVHRAEJDAigA8yMDA0MDQwNjE0MDQw
                  N1qBDzIwMDcwNDA2MTQwNDA3WjALBgNVHQ8EBAMCBaAwEQYJYIZIAYb4QgEBBAQDAgWgMB0GA1Ud
                  DgQWBBRuqaIGgbzAGisYYmNwwcYRbm+mlDAfBgNVHSMEGDAWgBRAmnZEl3QHxKwUyx6NTzpFfDDX
                  YTCCATEGA1UdIASCASgwggEkMIIBIAYJKwYBBAGsZgMFMIIBETA0BggrBgEFBQcCARYoaHR0cDov
                  L3d3dy5jZXJ0LmZubXQuZXMvY29udmVuaW8vZHBjLnBkZjCB2AYIKwYBBQUHAgIwgcsagchDZXJ0
                  aWZpY2FkbyBSZWNvbm9jaWRvIGV4cGVkaWRvIHNlZ/puIGxlZ2lzbGFjafNuIHZpZ2VudGUuVXNv
                  IGxpbWl0YWRvIGEgbGEgQ29tdW5pZGFkIEVsZWN0cvNuaWNhIHBvciB2YWxvciBt4XhpbW8gZGUg
                  MTAwIGUgc2Fsdm8gZXhjZXBjaW9uZXMgZW4gRFBDLkNvbnRhY3RvIEZOTVQ6Qy9Kb3JnZSBKdWFu
                  IDEwNi0yODAwOS1NYWRyaWQtRXNwYfFhLjAdBgkrBgEEAaxmASEEEBYOUEVSU09OQSBGSVNJQ0Ew
                  LwYIKwYBBQUHAQMEIzAhMAgGBgQAjkYBATAVBgYEAI5GAQIwCxMDRVVSAgFkAgEAMFsGA1UdHwRU
                  MFIwUKBOoEykSjBIMQswCQYDVQQGEwJFUzENMAsGA1UEChMERk5NVDEYMBYGA1UECxMPRk5NVCBD
                  bGFzZSAyIENBMRAwDgYDVQQDEwdDUkwxMjUyMA0GCSqGSIb3DQEBBQUAA4GBABJ9cQScVFdSF6ph
                  13bZO9cqIcPFxOllMnBgJyR2UlZ8o9vzlFkhLkgX3GcGVM19NVd6f9JUCnngI6GfWDBSDAYxeN3W
                  mXJIbOeLg2kxbXsq6/POg++ul8w1KHrbDqqGWC7IYBO88e/b63DvtpkbbCgIVJ6UcHc1x9WbI1b6hC9C
               </ds:X509Certificate>
            </ds:X509Data>
         </ds:KeyInfo>
      </ds:Signature>
   </env:Header>
 <env:Body Id=»AEATWID4P0D420061212094104159″>
    <RespFacturas>
       <Lote>LoteDioni001</Lote>
    <Emisor>
       <TipoDocumento>F</TipoDocumento>
       <Documento>A81069197</Documento>
    </Emisor>
    <FechaRecepcion>2006-12-12</FechaRecepcion>
    <NumeroFacturas>1</NumeroFacturas>
    <Retorno>
       <CodigoRetorno>0000</CodigoRetorno>
       <Descripcion>Correcto</Descripcion>
       <NumeroFactura>001</NumeroFactura>
    </Retorno>
    <CodigoElectronico>257262242DA9759D</CodigoElectronico>
    <RegistroAEAT />
  </RespFacturas>
 </env:Body>
</env:Envelope>

2) Una respuesta con error se generaría con el estándar SOAP FAULT como por ejemplo:

<?xml version=»1.0″ encoding=»UTF-8″ ?>
   <env:Envelope xmlns:env=»http://schemas.xmlsoap.org/soap/envelope/«>
      <env:Body>
         <env:Fault>
            <faultcode>env:Server</faultcode>
            <faultstring>[0305] Firma no válida</faultstring>
            <faultactor>WID4P0D4</faultactor>
            <detail>
               <IdPeticion />
               <NumElementos>1</NumElementos>
               <TimeStamp>2006-12-05-11.22.06.590229</TimeStamp>
            <Estado>
               <CodigoEstado>0305</CodigoEstado>
               <LiteralError>R-INSERT-WIGE03MEN. :Firma no válida</LiteralError>
               <TiempoEstimadoRespuesta />
            </Estado>
            <CodCertificado />
         </detail>
         </env:Fault>
      </env:Body>
   </env:Envelope>