Barrapunto

Facturae [facturae.es]
Esquema de formato [facturae.es]
Especificaciones Técnicas sobre Facturación Telemática disponible en la web de la AEAT [aeat.es]
SDK de firma electrónica [csi.map.es]
Firma electrónica - Software Libre [uvigo.tv]

Lo jodido es que desarrollen una aplicación de Gestión de Facturación Electrónica que permite la generación de facturas electrónicas con formato Facturae (ORDEN PRE/2971/2007) [facturae.es], lo hagan en Java y no liberen el código para el beneficio de los ciudadanos. De traca.

fijate que durante un buen rayo lo anduve buscando, pero un dia me enoje y deje de hacerlo. hoy que vi tu post me puse a buscar otro rato y encontre algunas cosas que pueden servirnos. la primera (aparte de ver que somos muchos con el problema) es: http://www.setasign.de/products/pdf-php-solutions/ setapdf-signer/sign-pdf.php [setasign.de] la cual es no libre, pero ya es una buena contendiente. luego encontre esta otra, que tampoco es libre http://www.sybrex.com/products/development/versypd f/versypdf_php/ [sybrex.com] pero si nos vamos por algo se me hace mas tentadora que la anterior. luego pues esta la idea de mejor dejar el pdf y usar xml (en mexico estan ambas opciones, pero alomejor y no se la opcion en la madre patria) podrias usar xmlsec (http://www.aleksey.com/xmlsec/) o siendo un poco mas espesificos esta la opcion de este cuate que usa xml http://www.lacorona.com.mx/fortiz/sat/codigo.php [lacorona.com.mx] al final de todo esto, solo llego a la conclusion de que no hay nada libre que firme pdfs, claro desde php, pero seria cosa de poder ver codigo de aplicaciones que lo hacen y sospecho que no es tan dificil implementarlo, aunque la pregunta es, que voy a implementar?

Hola,
Si no existe un producto ya hecho, quizás lo mejor sería basándote en los links que han dado sobre el formato de las facturas, utilizar el soporte OpenSSL de PHP para crear/validar las firmas.

Echale un ojo a esto:
http://nl3.php.net/manual/es/book.openssl.php [php.net]

Puedes llevar a cabo la firma de PDF desde una aplicación Web en el lado del cliente con el applet del proyecto cryptoapplet http://cryptoapplet.nisu.org/ [nisu.org] Un applet en java que corre en el lado del cliente y que únicamente requiere que el mismo tenga instalado el plugin en Firefox o Explorer.
También con respecto al PDF te permite aplicar el sellado de tiempo ofrecido por alguna TSA. http://es.wikipedia.org/wiki/Sellado_de_tiempo [wikipedia.org]
Este applet es GPLv2, el código fuente está disponible y existe una lista y un wiki de documentación, el applet no solo permite firmar un PDF sino que, además permite representar la firma en formatos como

• XMLDsig
• XAdES v1.1.1 (Implementación DigiDoc de openxades)
• CMS/PKCS#7
• PKCS#1

En la página del proyecto también hay ejemplos para cada caso y en algunos casos, como integrarlo con PHP.

El formato pdf permite incluir una firma digital. Las versiones más nuevas de Acrobat Reader incluyen una opción para verificar esa firma, sin embargo no conozco bibliotecas para php que puedan generarla. Yo suelo usar fpdf y no estaría mal hacer una clase que la extendiera para agregar firmas digitales.

Ya hice algunos intentos y por no redundar en el asunto: Facturae=pesadilla [barrapunto.com]. Te recomiendo el enlace Why XML Security is Broken [auckland.ac.nz], leelo, no es muy largo y no tiene desperdicio.

Destaco el punto donde explica que los formatos S/MIME y PGP usan la estructura.:
-Algoritmo cifrado
-Datos Cifrado
No porque se copien unos a otros (de hecho tienen cierto antagonismo), sino porque es la forma sensata de hacerlo. En cambio la seguridad XML-Dsig y similares usan
-Datos Cifrados
-Algoritmo cifrado
Lo que es una chaladura, implica tener que almacenar el mensaje previamente para su posterior tratamiento cuando se tengan los datos de cifrado. Pero creo que aún es peor, si no he entendido mal (no pongo la mano en el fuego, admito que ando algo perdido ante semejante caos) la cosa es más bien así:
-Datos Cifrados mezclados con no cifrados
-Algoritmo cifrado con indicadores (por ID o XPATH) del elemento cifrado.
Con lo sencillo que hubiera sido cifrar el bloque XML entero

Si buscas herramientas para cifrar XML no las encontrarás, prácticamente hay que hacer una Ad Hoc para cada XML en combinación con Algoritmos de cifrado etc.

Esto son las consideraciones técnicas, ahora vamos a las consideraciones políticas, que son las que de verdad cuentan.

Este formato se ha definido consultando a (léase "a conveniencia de") algunas constructoras fuertes y otras empresas gigantescas. El hecho de que llames al servicio técnico y sepan aún menos de lo habitual (quién hubiera dicho que eso era posible!!) indica que es un sistema que no está uso, unas cuantas empresas han llegado a acuerdos y le han hecho los programas a la administración para trabajar más cómodamente, y ésta se ha curado en saludo sacando un formato unas herramientas que ni siquiera ella misma comprende.

Creo que de momento aún le queda mucho terreno para que este formato sea algo más que una rareza para empresas de alto nivel. De hecho, estoy convencido que las facturas electrónicas terminarán teniendo otro formato. Así que he decidido dejar de calentarme la cabeza.

De todas maneras, si consigues algo avísame. Yo aún no me he recuperado del trauma y estoy haciendo terapia con cosas más sencillas, como mecánica cuántica y ecuaciones diferenciales ;-).

Existen varias maneras de generar una factura electrónica que expondré:

1) Generando un archivo BASE64 firmado con el algoritmo PKCS#7 a partir del documento original de la factura(ver facturación electrónica de la AEAT [www.aeat.es])

2) Imprimir un código de barras PDF-417 en un documento PDF, debiendo el código de barras contener la información de la factura en BASE64 y firmado con el algoritmo PKCS#7, como indican en la página de facturae [facturae.es]

3) Generar un archivo XML según las especificaciones de la factura electrónica [facturae.es]

¿Cuales son las ventajas de utilizar uno u otro método?

- La primera forma (Punto 1), tiene la ventaja de que es la mas segura y de que pueden enviarse las facturas en formatos mas amigables compatibles con PDF, ODT u DOC por ejemplo, pero la desventaja de que solo tiene validez si conservas el fichero .F64 original (cuidate de que no se te borre el disco duro y no tengas backups de las facturas), ya que si imprimes la factura deja de ser oficial. Para generar este tipo de documento, puedes hacerlo desde la misma oficina virtual de la AEAT con un certificado digital o bien currandote un programa que utilice la librería AEATFACT.dll, que solo esta disponible por supuesto para windows y que te puedes descargar de una pagina de la AEAT que ya no recuerdo (yo llevo trabajando un par semanas en su desensamblado y os podéis encontrar cosas interesantes).

- La segunda forma (Punto 2), tiene la ventaja de que si se decide imprimir la factura, esta sigue teniendo valor oficial (Por el código de barras PDF-417), pero la desventaja de que es mas posible realizar un fraude con ellas, ya que los seres humanos no entendemos estos códigos de barras, y es probable que nos cuelen facturas oficiales con codigos de barras sin sentido o simplemente ilegibles, a no ser que tengamos de un lector de código de barras especial y el software para comprobarlo; otra desventaja es que si almacenamos el papel en un sitio sucio o húmedo es posible que el código de barras se dañe un poco y eso tiene la consecuencia nefasta de convertir la factura en inservible, y obligandonos al igual que el punto 1 a conservar el archivo original.

- La tercera forma (Punto 3), es insegura (fácil de manipular un XML), requiere de un programa especial para leerlos (Que existe en linux y MacOs), y tiene la ventaja que al estar basado en XML es ideal para el intercambio de facturas por parte de grandes empresas.

¿Cual es la solución ideal?

Sin duda combinar el punto 2 y el 1. Que es que desde cualquiera de tus programas (OpenOffice, Abiword, Office, etc) conviertas la factura a PDF, añadirle un código de barras PDF-417 (Punto 2) para a continuación convertir el documento a .F64 (Punto 1).

De esta manera el documento tendrá validez tanto en formato archivo como impreso en papel ademas de ser prácticamente imposible su alteración. Adicionalmente cuando se compruebe la firma del archivo .F64, este se convertirá en un maravilloso archivo PDF, pudiendo ser legible desde cualquier plataforma que tenga un software lector PDF (Prácticamente todas la plataformas tiene uno), y conservando la estructura visual de la factura, tales como estilos, logotipo de la empresa, estructura, etc.

¿Que problemas trae esto en linux?

No existe versión de la AEATFACT.dll para linux (AEATFACT.so) y ademas no se indica como funciona (Por si a alguien se le ocurre portarlo).

¿Cual es la solución?
1) Bien currarte un servicio web en una plataforma windows que r

El proyecto PK7 lo creé principalmente para extraer y visualizar las facturas electrónicas emitidas por Movistar en linux siguiendo las especificaciones detalladas en https://aeat.es/facturas.pdf [aeat.es]. Para la visualización y validación de la firma electrónica PK7 hace uso de openssl.

Aunque PK7 permite generar dichos archivos a partir del documento especificado y una firma electrónica, no genera la firma.

Más info en: http://jkdsoftware.dyndns.org/drupal/?q=es/content /movistar-e-factura-en-gnulinux [dyndns.org]