Archivo de la categoría: Electronic Signature

Recibir facturas electrónicas


A veces, los interesados en recibir facturas electrónicas se encuentran con el problema de comunicar a sus proveedores este interés, a ser posible sin necesidad de tener que hacerlo uno por uno. Por otro lado los proveedores deben verificar la conformidad de sus clientes respecto a la recepción de la factura electrónica.

Ambos intereses se concilian gracias a los directorios de facturación electrónica. En estos directorios, el receptor se da de alta autorizando la recepción de facturas electrónicas y comunicando los sistemas de facturación preferidos señalando sus requisitos técnicos. El emisor, consulta por el CIF verificando esos datos y obteniendo la dirección de envío, adaptándose al mecanismo preferido por el emisor.

La siguiente pantalla muestra el aspecto del directorio de ASIMELEC cuando se consulta por el CIF de Albalia Interactiva.

Guia eFactura

Guia eFactura

La siguiente información es la pantalla equivalente en el Directorio de Facturae (del Ministerio de Industria, Turismo y Comercio).

Directorio facturae

Lo que queda claro es que Albalia Interactiva acepta facturas electrónicas XML en las diferentes versiones de UBL y facturae, y también en PDF (firmadas electrónicamente), y que acepta firmas electrónicas XAdES EPES y XL según diferentes versiones de la norma. Y que en estos momentos preferimos recibir las facturas en formato facturae 3.1 y firma XAdES-XL.

Para que estos directorios sean útiles, es importante que las empresas receptoras se den de alta, y que las empresas emisoras integren los webservices de los directorios en sus aplicaciones de facturación.

En estos momentos ya existen 2 plataformas que integran los servicios de directorio de ASIMELEC: la desarrollada por FENITEL y de la que se benefician los instaladores de infraestructuras de telecomunicaciones y la desarrollada por la propia Albalia Interactiva: Faccil.

Publicacion fehaciente en el «Perfil del Contratante»


En los foros de el Economista se inicia un diálogo entre «aibapas» y «Experto Derecho Editores» que centra los aspectos principales del problema a que da lugar la aplicación de la Ley 30/2007 de Contratos del sector público.

En el artículo 42 de la Ley de Contratos del Sector Público se habla del Perfil de Contratante, a través del cual los organismos públicos deberán publicar en Internet la información contractual del órgano de contratación.

En el propio artículo se hace referencia a la necesidad de «acreditar fehacientemente el momento de inicio de la difusión pública de la información que se incluya en el mismo».

Dispone el art. 42.3 de la Ley 30/2007, de 30 de octubre, de Contratos del Sector Público (EDL 2007/175022):

“3.- El sistema informático que soporte el perfil del contratante deberá contar con un dispositivo que permita acreditar fehacientemente el momento de inicio de la difusión pública de la información que se incluya en el mismo”.

Este párrafo se incardina dentro del art. 42: “Perfil del contratante” y, como indica expresamente el párrafo 1º del artículo, hace referencia los requisitos que se imponen a la Administración o entes del Sector Público contratantes para informar de su actividad contractual vía las páginas Web institucionales.

Por su naturaleza, estamos ante un supuesto en el que el término fehaciente se especializa por el carácter electrónico del medio de comunicación, y tiene como objeto el garantizar a los licitadores y ciudadanos en general los plazos que disponen para el ejercicio de determinados derechos; así, el artículo 37.6 de la Ley prevé un plazo de diez días hábiles contados a partir del siguiente al que se notifique o publique el acto impugnado para interponer el recurso especial en materia de contratación, o el 135.4, respecto de la adjudicación provisional de los contratos, que impone un plazo de quince días hábiles mínimo para elevar las adjudicaciones provisionales a definitivas contados desde el siguiente a aquél en que se publique aquélla en un diario oficial o en el perfil del contratante del órgano de contratación.

Tratándose de la acreditación de la fehaciencia de anuncios efectuados por medios telemáticos, habrá que acudir para interpretar qué se entiende por fehaciente a la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos (EDL 2007/41808):

La Ley 11/2007, en su art. 6.2, letra i), eleva al rango de derecho el de los ciudadanos “a la garantía de la seguridad y confidencialidad de los datos que figuren en los ficheros, sistemas y aplicaciones de las Administraciones Públicas”. Desde esta perspectiva, fehaciencia es el derecho, que no debe quedar al arbitrio de la Administración o Ente Público, de que la información, en este caso fecha de publicación la Web, en el perfil del contratante, es veraz e inmodificable por el contratante. Para el desarrollo de este derecho, la Ley 11/2007 prevé las siguientes obligaciones por la Administración o Ente contratante:

1º .- El establecimiento de una Sede Electrónica, con los requisitos del art. 10 de la Ley , especialmente en su párrafo 2º que obliga al titular de la sede electrónica sobre la integridad, veracidad y actualización de la información.

2º .- El uso por la Administración o Ente contratante de sistemas de firma electrónica para la actuación administrativa automatizada , con los requisitos exigidos por el artículo 18 que, a su vez, remite a la legislación específica sobre firma electrónica avanzada.

3º.- El equivalente, aunque sea referido de las comunicaciones bilaterales de la Administración o Ente con el particular, del art. 27. 3 de la Ley 11/2007 cuando señala, sobre las comunicaciones electrónicas, que Las comunicaciones a través de medios electrónicos serán válidas siempre que exista constancia de la transmisión y recepción, de sus fechas, del contenido íntegro de las comunicaciones y se identifique fidedignamente al remitente y al destinatario de las mismas.

En resumen, a los efectos del art. 42.3, la acreditación fehaciente le corresponde a la Administración o Ente Público contratante, siendo la fehaciencia a estos efectos que se haga por medios de firma electrónica avanzada, dónde consta fecha, hora y huella digital de la notificación en el perfil del contratante dentro de la Web, de acuerdo con las obligaciones que se impone a la Administración o Ente del Sector Público por la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos.

Sin embargo hay algunos aspectos que, en mi opinión siguen sin estar claros en la respuesta, y que deben ser resueltos en las implementaciones.

En primer lugar la fehaciencia implica la existencia de un mecanismo creible, fidedigno, incuestionable. Algo que como terceros de confianza se atribuye a la actuación de notarios, jueces, secretarios judiciales y funcionarios en el ejercicio de sus atribuciones. Por regla general determina un mecanismo probatorio independiente del ente que precisa la fehaciencia (para evitar que se produzca la colisión de suponer ser «juez y parte» en el procedimiento de que se trate).

La firma electrónica, por sí misma, solo aporta fehaciencia (elevada pero no incuestionable) respecto a la identidad del firmante (al menos sobre la atribuibilidad de la firma al firmante) y presupone su «voluntad de firmar», pero no garantiza aspectos como la efectiva publicación o su fecha.

Si a la firma electrónica le añadimos un timestamping (en la modalidad de firma ES-T) añadimos la fehaciencia de que el documento firmado electrónicamente existía con anteriodad a la fecha y hora indicada en el fechado electrónico, pero no su publicación.

El mecanismo fehaciente de publicación en el perfil del contratante de más valor es un servicio de terceros que obtenga el documento de la sede electrónica del organismo contratante (en la correspondiente sección del perfil del contratante) y genere sobre el un sello de tiempo. El sello de tiempo debería estar disponible junto al documento publicado en el perfil del contratante, y junto a ellos un enlace al tercero de confianza electrónico en el que sea posible obtener el documento original junto con los detalles (metadatos) de su publicación.

Si el servicio es de alta calidad, comprobará además que el documento referenciado no se ha retirado de la sede electrónica y ha permanecido disponible durante el tiempo marcado hasta su prescripción, y reflejará cualquier incidencia al respecto en el ámbito de los metadatos asociados al documento.

Una via alternativa con un alto grado de presunción (aunque capacidad probatoria inferior) es la publicación en un Boletin Oficial o en un periódico de tirada adecuada en el ámbito en el que sea precisa la fehaciencia (nacional, local o autonómica).

Algunos de los servicios de terceros son los de Contratación del Estado, en el ámbito público o los de Albalia Interactiva (a través de su plataforma EADTrust) en el ámbito privado.

Firma electrónica en UBL


En el marco de OASIS se está trabajando para definir la recomendación de uso de la firma electrónica que se utilizará en los mensajes UBL.

El uso más obvio es el del mensaje «Order» (pedido) ya que habitualmente tiene carácter contractual, pero en el caso europeo, es importante también la firma de la factura electrónica (Invoice), por lo que este es el uso más inmediato de esta recomendación.

No se trata de definir una norma. De hecho la recomendación se alinea con la norma de ETSI TS 101 903.

Sin embargo, dada la amplitud de posibilidades en la generación de modelos de firma electrónica que se prevé en la norma y las dificultades que puede tener la adopción de sistemas de firma electrónica en un contexto internacional, definir una recomendación simplificará la interoperabilidad de los sistemas de facturación electrónica.

En mi posición, como miembro del grupo de trabajo que redactará la recomendación, me inclino por proponer firmas electrónicas desarrolladas en la modalidad «enveloped» de forma que al ser la firma un nodo XML del mensaje UBL no se dificulta el entendimiento del mensaje, incluso si el receptor no es capaz de gestionar firmas electrónicas.

Además el tipo de firma debería ser de tipo ES-X-L adjuntando la información de timestamping y validación en origen, de forma que el receptor no tenga que lidiar con un complejo sistema de prestadores de servicios de certificación, como el que existe en Europa, con diferentes lenguas que habría que entender.

Este tipo de firmas ya están contempladas en la actual norma facturae 3.1, por lo que, en cierto modo, ya estaría dado un pequeño paso en la convergencia de facturae 4.0 con UBL 3.0 (o UN/CEFACT Cross Industry Invoice 1.0, si es que finalmente se llama así la norma de CEFACT que parte de la UBL 2.1 de OASIS).

De momento ya hay una propuesta respecto a la forma de incluir firmas electrónica en los mensajes UBL 2.0. que ha desarrollado Oriol Bausà de Invinet.

Generación de facturae para SAP desde iDoc con Biztalk


Aunque generar ficheros facturae a partir de los ficheros iDoc obtenidos en SAP no es muy complicado cuando contamos con herramientas como Biztalk, surge la necesidad de firmar electrónicamente los ficheros resultantes.

Biztalk es un entorno de interoperabilidad creado por Microsoft que lleva varios años de evolución y que ya usan más de 9.000 empresas en todo el mundo. Permite convertir entre diferentes formatos (gestionando las reglas de conversión que puedencrearse con las herramientas incluidas en la plataforma), así como lidiar con diferentes protocolos de comunicaciones. Se suele usar en proyectos EDI, algunos tan específicos como los financieros de SWIFT, y también en entornos multifabricante porque permite resolver muchos retos de conectividad. Gestiona colas y cuenta con procedimientos de recuperación lo que lo hace adecuado para convivir con entornos Host Mainframe y aplicaciones de misión crítica.

En los proyectos en los que convive con SAP, Biztalk concentra los diferentes mecanismos de comunicación con bancos, clientes proveedores, …gestionando las conversiones iDoc. Por supuesto, no se limita solo a gestionar facturas, pero en este caso interesa precisamente por su adecuación a esta tarea. Nos permite enviar y recibir mensajes INVOIC típicos de EDI (probado en nuestros proyectos con versiones D93A y D96A de EDIFACT), y tratar con mensajes de factura UBL (versiones 1 y 2) y los específicos destinados a las administraciones públicas españolas: facturae 3.0 y 3.1.

Para las conversiones es frecuente que tengamos que personalizar las estructuras de conversión, en función de los criterios de implementación de SAP en el cliente, pero gracias a las herramientas disponibles, es un trabajo que se puede hacer muy rápidamente.

Pero nuestro punto fuerte viene cuando tenemos que aplicar firmas electrónicas (obligatorias en las facturas y recomendables en los pedidos). Por eso hemos desarrollado una personalización de nuestra Suite Backtrust, específicamente para que pueda ser invocada desde Biztalk, como uno más de los servicios que se orquestan desde la plataforma. Backtrust for Biztalk permite generar diferentes tipos de firmas electrónicas XML (XAdES) y específicamente los tipos ES-EPES y ES-X-L especificados por ETSI (TS 101 903) y de uso prescrito a partir de la Orden PRE 2971/2007, por lo que es adecuado para generar las facturas electrónicas que se exigen cuando el destinatario es una administración pública.

De igual forma si el usuario del sistema es una administración pública o un organismo dependiente, es posible tratar las firmas electrónicas y validarlas contra los servicios OCSP y CRL de los propios prestadores de certificación, o servicios de centralización de la validación como @firma del MAP o EADTrust.

Interlocución telemática


El 29 de diciembre de 2007 se publicó en el BOE la LMISI, Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. Una de las características de esta norma es que impone a las empresas privadas ciertas obligaciones coherentes con el derecho de los ciudadanos a usar la vía telemática que se consagra en la  LAECSP, Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos .

En el artículo 2 de la LMISI se establece la obligación de ciertas empresa de disponer de un medio de interlocución telemática para la prestación de servicios al público de especial trascendencia económica. Y en la disposición final cuarta se indica que esta obligación entrará en vigor a los doce meses de la publicación de la Ley en el Boletín Oficial del Estado.

Todo el artículo tiene su interés, pero conviene destacar que sin perjuicio de la utilización de otros medios de comunicación a distancia con los clientes, las empresas que presten servicios al público en general de especial trascendencia económica deberán facilitar a sus usuarios un medio de interlocución telemática que, mediante el uso de certificados reconocidos de firma electrónica, les permita la realización de ciertos trámites como la contratación electrónica, modificación de condiciones contractuales, altas, bajas, quejas, histórico de facturación, sustitución de informaciones y datos en general, así como el ejercicio de los derechos de acceso, rectificación, oposición y cancelación en materia de protección de datos

Las empresas obligadas por esta normativa son aquellas con más de 100 empleados o un volumen de operaciones superior a los 6 millones de euros que presten servicios al público considerados como de especial trascendencia económica, como banca, electricidad, agua y gas, y telecomunicaciones, entre otros.

Para facilitar a todo tipo de empresas el cumplimiento de esta norma, Albalia Interactiva ha desarrollado en el marco de su gama de servicios EADTrust la funcionalidad de Interlocución Telemática que se integra con facilidad en el entorno web  de la empresa. De esta manera, en un tiempo record, es posible contar con este tipo de servicios y cumplir los plazos marcados por la ley. Los formularios firmados electrónicamente se guardan en formato XAdES-X-L (según se define por la norma TS 101 903) por lo que incluyen todas las evidencias electrónicas que afectan a la validez del certificado en el momento de la firma.

El sistema es personalizable con la imagen del web de la entidad y permite definir todo tipo de trámites y formularios. Además, es posible diseñar entornos mixtos en los que el formulario se completa y se prevalida en la entidad y se firma electrónicamente en la plataforma EADTrust.

Trámites que debe permitir la interlocución telemática

Mediante el uso de certificados reconocidos de firma electrónica, la interlocución telemática debe permitir a los clientes y usuarios la realización de, al menos, los siguientes trámites:

  • Contratación electrónica de servicios, suministros de bienes, la modificación y finalización o rescisión de los contratos, así como cualquier acto o negocio jurídico entre las partes.
  • Consulta de los datos de cliente, que incluirán información sobre su historial de facturación de, al menos, los tres últimos años y el contrato suscrito.
  • Presentación de quejas, incidencias, sugerencias y reclamaciones, garantizando la constancia de su presentación para el consumidor y asegurando una atención personal directa.
  • Ejercicio de los derechos de acceso, rectificación, cancelación y oposición en los términos previstos en la normativa reguladora de protección de datos de carácter personal.

Empresas afectadas por la normativa

Las empresas obligadas por esta normativa son aquellas que agrupen a más de cien trabajadores o cuenten con un volumen anual de operaciones superior a los 6.010.121 euros y que, en ambos casos, operen en los siguientes sectores:

  • Servicios de comunicaciones electrónicas a consumidores.
  • Servicios financieros destinados a consumidores, que incluyen los servicios bancarios, de crédito o de pago, los servicios de inversión, las operaciones de seguros privados, los planes de pensiones y la actividad de intermediación de seguros.
  • Servicios de suministro de agua a consumidores.
  • Servicios de suministro de gas al por menor.
  • Servicios de suministro eléctrico a consumidores finales.
  • Servicios de agencia de viajes.
  • Servicios de transporte de viajeros por carretera, ferrocarril, vía marítima o aérea.
  • Actividades de comercio al por menor.

Además, el Gobierno y las Comunidades Autónomas, podrán ampliar el ámbito de aplicación de esta obligación a otras empresas distintas de las previstas en la Ley, en aquellos casos en los que se considere que en el desarrollo de su actividad normal deban tener una interlocución telemática con sus clientes o usuarios.

Hito en EADTrust. Ceremonia de generación de claves root


Ayer tuvo lugar un hecho histórico en el desarrollo de EADTrust, Prestador de servicios de confianza digital, lo que supone un motivo de orgullo para todos los integrantes del equipo.

Llevamos a cabo la ceremonia de generación de claves de la autoridad de certificación root de la PKI en sede notarial. En la foto adjunta estamos los presentes en el acto.

De izquierda a derecha, yo mismo, Julián Inza, y seguidamente Fernando Pino, Maria Luisa Blasco, Luis Osses y Santi Casas.

Julian Inza - Fernando Pino - Maria Luisa Blasco - Luis Osses - Santi Casas

Julian Inza – Fernando Pino – Maria Luisa Blasco – Luis Osses – Santi Casas

No está en la foto, pero tuvo una contribución esencial, Mar de las Heras que ha aportado buena parte de los documentos legales del evento.

La fecha del 24 de septiembre de 2008, dia de la Virgen de la Merced, adquiere un nuevo significado para nosotros.

Colaboración en epractice.eu


La posibilidad de colaborar con epractice.eu está abierta a quienes estén interesados en la temática del impulso de la administración electrónica. Aunque yo llevo cierto tiempo como miembro de la comunidad, hoy he enviado mi primer artículo en el Blog conjunto.

Future trends in electronic invoicing

About one month ago, it was distributed a draft of the conclusions of the EC electronic invoice experts group regarding future regulation needs to push development and disemination of electronic invoices.

I was disappointed to find that one of the conclusions implies that electronic signature is seen as a barrier for further development of the electronic invoice, and a feature that some of the members of the expert group see as superfluous feature.

In my opinion, electronic documents need ways to reinforce security to allow to tell apart fake documents from authentic documents. Ths is generally true even for informative documents with less impact on companies results.

It is also true that electronic signature is not the only way to reinforce security regarding autenticity of documents. For example, a document can be assumed to be authentic if it is retrieved from a trusted source, even if it is not completed with an electronic signature. But then we must define what are the requirements of such «trusted sources» to keep that assumption.

On the other hand, both approaches, electronic signatures and reference or trusted sources (which in turn frecuently are based in electronic signature derived schemes) need more precise definition to avoid lack of interoperability, which, in my opinion is the real barrier for electronic invoice wide deployment.

Some common authenticity mechanisms are required both for electronic invoices (those that are born electronically from the beginning) and for invoices certified scanning (invoices digital copies that become equivalente to an original, after a security mechanism has been added to a common scanning).

This approach, «certified scanning», has been initiated in Spain with high success.

Certified scanning is a process in which an electronic signature is applied to a image file while it is scanned from a document paper. This image is stored in a secured database and the main concepts and terms of the paper document are added as metadata to the contextual fields of the image file in the database.

Once a paper document is «certifiedly scanned» the digital copy becomes equivalente to an original, and the paper source can be destroyed. The new «electronic original» can then be used for auditing purposes.

For the companies that receive thousands of invoices, «certified scanning» adoption imply benefiting from most of the advantages of the electronic invoice without dealing with the slow adoption pace that their suppliers could show.

If we want to support «certified scanning» we need a common definition of the requirements for that conversion. And they should not be very different form the requirements for «electronic invoices» .

If we accept authenticity mechanisms not based in electronic signature, they should be common for both approaches. And if electronic signature is still to be used in the future as the authenticity mechanism of the electronic invoice, the broad options in variants should be reduced and clearly defined (in my opinion, the XL definition of CAdES -TS 101 733- or XAdES -TS 101 903- should be used, including both validation and timestamping, from the signer side).

PEPPOL. Simplificación de gestiones transfronterizas


Una solución  electrónica integrada que eliminará las barreras para la contratación pública a través de las fronteras nacionales.

Ese es el objetivo de una completa propuesta de proyecto que se remitió recientemente a la Comisión de la Unión Europea desde un consorcio internacional con participantes de nueve países.

El Secretariado Noruego de eProcurement (contratación pública electrónica) es el órgano de coordinación para la propuesta y el posible proyecto piloto.

La aplicación de la solución a través de las fronteras va a sacar partido de las fortalezas y ventajas de cada nación en los sistemas nacionales existentes y facilitará de forma conjunta el despliegue  de una solución interoperable de contratación pública electrónica extendida a toda la UE. Si la solución tiene éxito, puede ser extendida a una mayor utilización por toda Europa.

El proyecto se titula “Pan-European Public Procurement On-Line” (Contratación pública pan-europea on-line), abreviado PEPPOL, y ha sido organizada como un consorcio.

El objetivo del proyecto PEPPOL es facilitar a los operadores económicos europeos, en particular las PYMEs de un país, la respuesta a las oportunidades de contratación pública ante poderes adjudicadores de otro pais a través del uso de soluciones de eProcurement (contratación pública electrónica) interoperables que actuan a nivel de toda la Unión Europea.

La solución interoperable de servicios del Proyecto PEPPOL se basa en especificaciones funcionales y consiste en una serie de Bloques constitutivos que cubren los diferentes requisitos de negocio identificados relativos a la utilización transfronteriza de las soluciones existentes para la Firma Electrónica (eSignature), Dossier Virtual de Empresa (Virtual Company Dossier), Catálogos Electrónicos (eCatalogues), Pedido Electrónico (eOrdering) y Factura Electrónica (eInvoicing). Los Bloques relativos a un aspecto pueden ser modificado sin que ello necesariamente tenga un impacto en los demás.

El consorcio PEPPOL consta de 14 participantes y un número de sub-contratistas de nueve naciones que representan a siete administraciones públicas. Los participantes tienen una amplia experiencia y profundo conocimiento de la contratación pública electrónica, sobre la base de sus soluciones nacionales o regionales en fases operacionales o de piloto avanzado que abarcan toda la cadena de valor de la contratación pública.

Para garantizar la difusión por toda la UE y la selección de resultados del proyecto, se ha establecido un grupo de referencia para los Estados miembros ajenos del consorcio. Asimismo se asignarán recursos pata futuras ampliaciones del consorcio.

Pan-European Public Procurement On-Line (Contratación pública pan-europea on-line)

Pan-European Public Procurement On-Line (Contratación pública pan-europea on-line)

El proyecto PEPPOL está organizado en cinco Paquetes de Trabajo (Work packages) funcionales, del WP1 al  WP5 y tres horizontales, del WP6 al WP8:

  • WP1 – eSignature, coordinado por la ciudad de Bremen, Alemania, que fue una de las primeras administraciones que ofreció aplicaciones que utilizan firma electrónica a gran escala.  El Documento «Directrices para las especificaciones comunes de Utilización transfronteriza pública de e-procurement» dice lo siguiente: «La falta de interoperabilidad entre los diferentes esquemas nacionales para firmar electrónicamente los documentos de concursos y ofertas es el más importante factor de bloqueo a las transacciones electrónicas transnacionales».
  • WP2 – Virtual Company Dossier (VCD), coordinado por la Universidad de Koblenz, Alemania. Este coordinador tiene un papel principal en BRITE (Business Register Interoperability Throughout Europe, Interoperabilidad de Registro Mercantiles  en toda Europa), y por lo tanto tiene la experiencia pertinente para la creación del VCD.
  • WP3 – eCatalogues, coordinado por Consip SpA, Italia, que contribuirá con su conocimiento en eCatalogues y con su consolidada experiencia internacional al consorcio.
  • WP4 – eOrdering, coordinado por ScotGov, Reino Unido. El coordinador de este Paquete aportará conocimientos específicos para el proyecto de eOrdering sobre la base de sus 5 años de experiencia que hasta la fecha han dado lugar a la manipulación electrónica de pedidos por valor de más de 2 millones de libras esterlinas.
  • WP5 – eInvoicing, coordinado por la Agencia Nacional de TI y Telecomunicaciones (NITA, National IT and Telecom Agency), Dinamarca. La NITA contribuirá con la experiencia danesa sobre Factura Electrónica.

Además, hay tres Paquetes horizontales: WP6 – Administración del Proyecto, coordinado por Ehandel.no, Noruega; WP7 – Sensibilización, difusión, creación de consenso y formación, coordinado por Peppol.at, Austria, y WP8 – Arquitectura de la solución, diseño y validación, coordinado por NITA, Dinamarca.

Además de los países mencionados, Finlandia, Hungría e Islandia son miembros del consorcio. André Hoddevik, Responsable del Secretariado noruego de e-Procurement actuará como coordinador de la propuesta y del proyecto piloto.

Extensiones recomendadas en ficheros de firma electrónica y factura electrónica


A la hora de promover la interoperabilidad de aplicaciones, uno de los elementos que influyen en alguna medida son las letras que identifican la extensión.

Tratándose de facturas electrónicas, los formatos más empleados son los que tienen que ver con el EDI (Electronic Data Interchange, Intercambio Electrónico de Datos) y el lenguaje XML (Extensible Markup Language, Lenguaje de Etiquetado Extensible), de modo que las extensiones .edi y .xml ya suponen una primera aproximación a la resolución del problema.

En general estas extensiones ya son de por sí suficientes cuando los ficheros llegan a aplicaciones especializadas que pueden determinar el tipo de mensaje concreto (factura, pedido, albarán,…) y su formato (facturae, UBL, EDIFACT, …) sin más que leer las cabeceras, los primeros caracteres,  del fichero.

Sin embargo, en muchas ocasiones, de lo que se trata es de que el sistema operativo sea capaz de abrir el programa adecuado cuando hacemos «doble click» sobre un fichero con una determinada extensión.

Por ese motivo me he permitido recomendar las siguientes extensiones:

  • .fir Fichero PKCS#7 que contiene una firma electrónica y del que se puede extraer el fichero firmado. Esta extensión se utiliza ya por Albalia, Camerfirma y CatCert.
  • .xes Fichero XML que incluye una firma XAdES.
  • .fre Fichero que contiene una factura electrónica en formato facturae con una firma XAdES ES-X-L
  • .ubl Fichero que contiene un mensaje UBL (pedido, albarán, factura,..)

Campaña “Queremos ordenadores con chipetera“


He creado una página fija para la Campaña «Ordenadores con chipetera». Por favor difundidla entre vuestras amistades y comunicadme las páginas que hagan referencia a la campaña, para que pueda incluir la reseña.

Igualmente, si conoceis modelos de ordenador que tengan lector de tarjeta chip (especialmente portátiles, porque los de sobremesa lo resuelven fácilmente con un teclado que lo incluya) hacédmelo saber para que los incluya en la lista.