Implementación de la Factura Electrónica en México con WebSphere DataPower SOA Appliance

Demostración de como dar de alta un servicio para realizar un timbre fiscal en México, o lo que es lo mismo, una firma digital para una factura electrónica.

Leonardo Rodriguez, Especialista de IT en Websphere Connectivity para Latinoamérica, IBM China

Leonardo Rodriguez es especialista Técnico Certificado con foco en Soluciones de Middleware e Integración en la brand de WebSphere, pertenece al Laboratorio de Soluciones del grupo de Software y asiste a business partners, especialistas en IT y clientes en la región de Latinoamérica.



Gerardo Vega Amabilis, Certified IT Specialist, IBM México

Gerardo es especialista en tecnológica certificado y trabaja en el Laboratorio de Soluciones de Software en IBM de México. Sus tarea principales es apoyar a los clientes a definir sus soluciones y arquitecturas utilizando el software de IBM para soporta las aplicaciones, procesos, su integración y las soluciones en la nube. Cuenta con mas de 20 años de experiencia trabajando con sistemas distribuidos, conectividad y middleware. Ha realizado publicaciones de libros rojos (redbooks ) en diversas tecnologías de IBM.



Fermín Luna Balcazar, Websphere IT Specialist, IBM México

Fermín es especialista Técnico para Software IBM México, es egresado del Instituto Politécnico Nacional, tiene más de 12 años en la industria de TI en áreas de desarrollo de Sistemas y liderazgo de grupos de desarrollo, trabajando en sectores como Banca, Retail, Telecomunicaciones. Actualmente es parte del equipo de Integración de Aplicaciones de WebSphere México, en productos como WebSphere MQ, IBM Integration Bus (formerly WebSphere Message Broker), WebSphere Datapower".



30-09-2013

Factura electrónica

Como indicamos en nuestra primera entrega (Introducción a la facturación electrónica con WebSphere DataPower SOA Appliances en México) se realizará una demostración de cómo dar de alta un servicio para realizar un timbre fiscal en México, o lo que es lo mismo, una firma digital para una factura electrónica. Las reglas pueden cambiar, por lo que es recomendado verificar las ligas oficiales del Servicio de Administración Tributaria (SAT) de México (http://www.sat.gob.mx/sitio_internet/cfd/) . El procedimiento para generar facturas digitales puede variar entre países pero seguramente habrá similitudes.

El procedimiento que demostraremos es básico; sin embargo, la implementación dependerá de muchos factores:

  • Los tipos de validaciones necesarias.
  • El valor agregado en cada implementación para beneficio de los usuarios o la compañía.

Por si es de interés del lector, los datos que son requeridos al generar una factura electrónica están descritos en la siguiente liga del SAT: http://goo.gl/q6NK5.

Para la generación de una factura, entre otras cosas, se requieren:

  • Emisor. Quién genera el documento después de vender un producto o servicio.
  • Receptor. Quién recibe el documento por haber consumido.

El SAT provee de una llave y un certificado a todos aquellos Emisores para que puedan generar sus facturas electrónicas. Por otro lado, además del emisor y el receptor, hay una entidad llamada PAC (Proveedor Autorizado de Certificación) estas entidades son encargadas de prestar servicios de generación de CFDI, y ellos están oficialmente autorizados para prestar este servicio, por lo que también cuentan con una llave y un certificado proveído por el SAT, que servirá para garantizar que las facturas emitidas son genuinas.

Para la generación de nuestras facturas electrónicas abarcaremos los siguientes casos:

Sello

  1. Recibir una factura xml y generar el sello digital con la llave del Emisor y agregarla al XML en un atributo llamado “sello”.
  2. Agregar a este documento un atributo llamado “certificado” que contiene la llave pública del Emisor y otro atributo llamado “nocertificado” que contiene el número de serie del certificado del Emisor.

Timbre

  1. Recibir una factura xml con sello y agregar un elemento llamado Complemento que contiene los datos del PAC, entre otros datos, que hacen válida la factura. Esto es llamado también el timbre fiscal.

Con esta información se tiene la posibilidad de crear un servicio único que genere primero el sello y luego el timbre.

Utilizaremos IBM WebSphere DataPower que es un appliance de propósito específico para dar seguridad en ambientes de manejo masivo de XML, esta seguridad está basada en una infraestructura PKI de manejo de Firmas Digitales ideada por el SAT.

Este appliance alojará un servicio de Generación de Sellos y Timbres Fiscales, utilizaremos los XSD's y XSLT's propios del SAT, además de algunos XSL's personalizados, también se utilizarán extensiones de http://exslt.org/ soportadas por IBM WebSphere DataPower.

Antes de iniciar es importante decir que manejaremos una llave privada única para la generación del sello y del timbre, esta llave y certificado han sido generados en una herramienta incluida con DataPower que se llama “Crypto Tools”, aquí se puede indicar que la llave se genere directamente en el módulo HSM del Appliance o que esta llave pueda ser exportable. Aquí mismo podemos indicar que se genere un Certificate Signing Request (CSR) para enviarlo al SAT. En nuestro caso generaremos una llave que no está en el módulo HSM, sino que se encuentra directamente en el sistema de archivos encriptado del appliance. La llave tiene el nombre dworks_cfdi (dworks_cfdi-privkey.pem) y el certificado tiene el nombre dworks_cfdi (dworks_cfdi-sscert.pem). También encontraran esta llave y certificado adjunto en el artículo.

Recomendación: Si es posible, genere la llave privada en el módulo HSM del Appliance, esto tendrá un impacto positivo muy considerable en el desempeño de las operaciones criptográficas (cifrado, descifrado, generación de firmas, verificación de firmas, entre otros).

Figura 1.
Generación de llaves de prueba

Sello y Timbre Fiscal en WebSphere DataPower

Sello

1. Primero ingresamos a la consola Web de DataPower. Aquí suponemos que tenemos un usuario con los permisos adecuados, además de un Dominio (en este caso trabajaremos con el dominio llamado “dwpac”). La liga de la consola web será como sigue: https://ip_datapower:puerto/login.xml

Dónde

ip_datapower = La dirección IP del dispositivo donde ustedes trabajan.

puerto = El puerto donde hemos decidido que se administra el appliance (por defecto 9090)

Figura 2.
Pantalla de Login de WebSphere DataPower

2. Una vez firmados en la consola, se presenta el menú principal de servicios y damos clic en la opción “XML Firewall”. Este es un servicio HTTP que recibe documentos XML.

Figura 3.
Menu de Servicios WebSphere DataPower XI52

3. Ahora daremos clic en el botón “Add Advanced”.

Figura 4.
Tipo de Servicio XML Firewall

3.1 Tenemos que capturar algunos datos básicos para el servicio Firewall Name=xmlfw_cfdi, Firewall Type=loopback, Processing Policy=Default (por ahora), Local IP Address=0.0.0.0 (escuchará en cualquier IP del appliance), Port Number=2049, Request Type=XML. Los demás datos se pueden quedar con el valor por defecto, ahora damos clic en el botón Apply.

Figura 5.
Servicio Avanzado XML Firewall

4. Ahora vamos a crear una nueva política de procesamiento, para ello damos clic en el botón “+” a la derecha de la opción “Processing Policy”. Esto nos abre una nueva ventana donde necesitamos capturar Policy Name=xmlfw_cfdi y damos click en Apply Policy.

Figura 6.
Configuración de nueva política de procesamiento

5. Inmediatamente después necesitamos crear una nueva regla dando clic en el botón New Rule y modificamos el valor por defecto en el campo Rule Name como xmlfw_cfdi_sello”. Aquí habilitaremos la URL donde escuchará este servicio.

Figura 7.
Nueva regla dentro de la política
Figura 8.
Configuración para dirigir las peticiones a la política (Match)
Figura 9.
Nueva URL para “Matching Rule”

Lo que sigue será crear las acciones necesarias en la regla:

a) Extraer la “Cadena Original”

b) Crear el sello.

La Cadena Original es un término usado por el SAT para referirse a una cadena con los datos fiscales originales de la factura, estos están separados por el caracter “|” y tiene como iniciador y terminador la cadena “||”. Cuando creamos una nueva regla se crea automáticamente una acción tipo “Match” que sirve para dirigir las peticiones, normalmente esto se hace configurando una URL. Para configurar las acciones arrastramos la acción y damos doble clic en la misma.

6. Enseguida configuramos la acción “Transform” que utiliza una hoja de estilo propia del SAT llamada “cadenaoriginal_3_2.xslt”, esta hoja de estilo extrae del XML entrante los datos necesarios para generar el sello, en DataPower guardaremos ese dato en una variable de contexto de la política (cadenaorig_out). Para lograr esto damos clic en la primera acción Transform y luego damos clic en el botón Upload ahí debemos seleccionar el archivo cadena_original_3_2.xslt.

Figura 10.
Agregando los XSL's a la regla de sello
Figura 11.
Configuración de acción de cadena original

7. A continuación vamos a configurar la acción “Transform” que utilizará la hoja de estilo llamada “crea-cfd.xsl”, esta es una hoja de estilo personalizada que se ha creado de antemano y hace uso de funciones de usuario utilizando las extensiones de exslt.org. además de algunas funciones nativas de DataPower disponibles en cualquier XSL que corre en el appliance. Más adelante podremos ver un poco de detalle acerca de este funcionamiento. Por defecto la entrada para esta acción será la salida de la acción anterior, modificaremos esto para que la entrada sea la variable “INPUT” que significa “El documento de entrada original de de la Regla”. Hay que asegurarnos que nuestra regla tiene al final una acción tipo “Result”, que tiene la finalidad de terminar las acciones y enviar el resultado.

Figura 12.
Configuración de acción para crear el timbre fiscal
Figura 13.
Regla de sello para CFD

8. Después de realizar estas configuraciones damos clic en el botón Apply Policy → Close Window y posteriormente en damos clic en el botón Apply de la configuración del XML Firewall.Para estar seguros de que esta información se guarde en la memoria del Appliance damos clic en el botón Save Config que se encuentra en la esquina superior derecha de la consola Web.

Figura 14.
Guardar la configuración en la memoria del Appliance

Timbre

Para configurar el servicio de timbre, suponiendo que a este servicio llega una factura que ya tiene sello, vamos a utilizar la misma política de procesamiento que dimos de alta en el paso cuatro del servicio de Sello, pero agregaremos una nueva regla llamada “xmlfw_cfdi_timbre”. Para ello modificaremos la política dando clic en el botón [...] que se encuentra a la derecha de Processing Policy, habiendo seleccionado la opción “xmlfw_cfdi”. Seguimos las mismas instrucciones desde la número cinco del servicio de Sello, con la salvedad de que la regla se llamará “xmlfw_cfdi_timbre” y el match se hará para la URL “/timbre”, además los XSL utilizados serán los siguientes:

  • cadena-timbre.xsl. Este es un XSL personalizado que utiliza algunas funciones del SAT pero obtiene la cadena que se necesita para el timbre fiscal, este dato lo pondremos en una variable de contexto (cadenacfdi_out) de la política de procesamiento.
  • crea-cfdi.xsl. Este es otro XSL personalizado que utiliza algunas funciones de usuario creadas de antemano para poderse reutilizar. Toma del contexto la cadena calculada para el timbre y genera la firma digital que será el timbre fiscal, agregándolo al documento en un elemento del xml de entrada llamado “Complemento”, también modificaremos la acción para que la entrada sea la variable “INPUT”.

Al finalizar este procedimiento es importante guardar, dar clic en el botón “Save Config” para asegurarnos de que todo sea almacenado correctamente en la memoria del Appliance.

Figura 15.
Regla para timbre fiscal terminado

Hasta este momento tenemos configurados dos servicios:

  • Sello (http://ip_datapower:puerto/sello)
  • Timbre fiscal (http://ip_datapower:puerto/timbre)

Funciones personalizadas con EXSL

En seguida se presentan un par de funciones personalizadas que son habilitadas gracias al soporte de EXSL en el Appliance. Ustedes pueden revisar el XSL llamado utils-cfd.xsl y ahí encontrarán las funciones a las que hacemos referencia.

Prerequisitos

Es necesario agregar los “name-spaces” de exsl y de Datapower, como se ve en la siguiente figura.

Figura 16.
Extracto de name-spaces para XSL utils-cfd.xsl

A = Habilita las funciones de tipo cadena (str) y funciones (func) de EXSLT.

B = Habilita las funciones propias de Datapower.

C = Declara el name-space de nuestas funciones personalidas (utilfn).

Función crea-firma.Tiene como finalidad de crear una firma digital, puede ser útil para crear el sello o el timbre. Pueden ver su uso en el xsl llamado crea-cfd.xsl. Esta función declara que recibe dos parámetros: base-string y key-name.

Figura 17.
Función para crear una firma digital

A = Declaración de una nueva función.

B = Función de Datapower para crear un hash.

C = Función de Datapower para crear una firma digital.

Función crea-timbre.Tiene como finalidad la de crear la estructura del timbre y regresar el nodo xml creado. Pueden ver su uso en el xsl llamdo crea-cfdi.xsl. La función declara que recibe cinco parámetros: trans-uuid, current-date, cfd-signature, cert-serial, firma-timbre.

Figura 18.
Función para crear el nodo xml del timbre

Pruebas

En este momento podemos realizar una prueba para validar que nuestros servicios están funcionando adecuadamente. Para esta finalidad utilizaremos una herramienta disponible para cualquier usuario llamada “Apache Jmeter"; sin embargo, ustedes pueden utilizar la heramienta de su elección o la que su organización haya elegido. Para facilitar estas pruebas encontrarán adjunto el Test Plan de Apache Jmeter (dworks_cfdi.jmx), que contiene la configuración de la prueba, ustedes podrán importar en Jmeter este test plan y modificar los datos necesarios para que funcione en sus ambientes:

  • La dirección IP del Appliance
  • El puerto de escucha del servicio
  • La URI donde deben apuntar
  • El contenido de la petición (xml), etc.

Al momento de estas pruebas se ha utilizado la versión 2.9 de Jmeter que requiere tener instalado java 1.6 o posterior.

Vamos a dar un paseo rápido en lo más importante de este Test Plan:

  • dworks_cfdi (Test Plan). Es el contenedor de la configuración de la prueba.
  • usuarios (Thread Group). Permite modificar el número de usuarios que queremos simular.
  • factura_xml (HTTP Request). Permite modificar la dirección IP, el puerto, la URI, además del contenido XML que queremos envíar al servicio, en este caso usamos el método POST.
  • headers_http (HTTP Header manager). Permite agregar los headers requeridos por el servidor, en este caso solo un header para indicar el tipo de contenido.
  • resultados(View Results Tree). Permite visualizar el resultado de las peticiones. Cuando se realizan pruebas de volumen, es recomendable que se deshabilite o que se borre este componente.
  • resumen (Summary Report). Permite visualizar en tiempo real el desempeño del servicio y al final despliega los tiempos promedio y la tasa de procesamiento promedio, así como el porcentaje de peticiones que tuvieron errores.

Una vez que se han realizado las configuraciones pertinentes se inica la prueba dando clic en el botón con forma de triángulo verde “Start” y se verifican los resultados ya sea en resultado o en resumen

Figura 19.
Prueba de servicio con Jmeter

Archivos Adjuntos

Encontrarán adjunto un único archivo comprimido llamado dworks_cfdi_archivos.zip, cuyo contenido se describe a continuación:

  • dworks_config.zip. Contiene un xml de prueba de sello (factura_ejemplo.xml), el “Test Plan” de jmeter (dworks_cfdi.jmx).
  • cfdi_xsl.zip. Con los archivos xsl utilizados.
  • cfdi_xsd.zip. Con los esquemas utilizados.
  • cfdi_domain.zip. Con un respaldo del dominio de DataPower, que podrán importar en un appliance IBM WebSphere DataPower.
  • cfdi_keys-certs.zip. Que contiene la llave y el certificado usado para estas pruebas; sin embargo, pueden elegir la llave y el certificado con que desean trabajar. En caso que usen el respaldo del dominio incluído (cfdi_domain.zip), podrán utilizar esta llave privada ya que los exports de DataPower no contienen llaves privadas por razones de seguridad.
  • dworks_cfdi.jmx. Que contiene el Test Plan de Jmeter, para realizar las pruebas en el servicio correspondiente.

Referencias

Beneficios de la Factura Electrónica Beneficios de implementar la facturación electrónica en sus empresas.

Requisitos de la Facturación Electrónica Requisitos que deben cumplir las Facturas Electrónicas (CFDI).

WebSphere DataPower SOA Appliances Página oficial de WebSphere DataPower SOA Appliances.

WebSphere DataPower SOA Appliances Library Información detallada del producto WebSphere DataPower SOA Appliances.

Servicio de Administración Tributaria Página oficial del Servicio de Administración Tributaria (SAT).

Proveedor de Factura Electrónica Qué es un PAC (Proveedor de Factura Electrónica).

Facturación Electrónica por el SAT Información general de la facturación electrónica por el SAT.

Cifrado Digital por la W3C Qué es el cifrado digital en XML especificado por la W3C.

Firma Digital por la W3C Qué es la firma digital en XML especificado por la W3C.

XML Appliance Qué es y en qué se basa un appliance de XML.

EXSLT Qué es la organización exslt.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere,
ArticleID=957778
ArticleTitle=Implementación de la Factura Electrónica en México con WebSphere DataPower SOA Appliance
publish-date=09302013