Tabla 1. Métodos disponibles del servicio.

Nota: Es necesario contar con timbres disponibles al momento de solicitar la transacción ya que, aunque la mayoría de operaciones/métodos no consumen timbres sí se requiere ser cliente vigente de XPD.

Tabla 2. Parámetros generales de entrada.

Agregar CSD Emisor por Web Service

Para poder generar el XML del CFDI a timbrar es necesario que el Emisor proporcione por única ocasión su CSD con el cual se sellará la factura mientras este se encuentre vigente ante el SAT, en cada renovación de CSD o implementación de un nuevo RFC Emisor es necesario proporcionar la llave privada (key), llave pública (cer) y contraseña del CSD.

Los parámetros que se solicitan además de los generales son los siguientes:

• contrasenaLlave: valor de tipo “string” donde el Emisor indica la contraseña de la llave privada (key) del CSD.
• certificadoBase64: expresado en “base64” según sea el caso de implementación, que contiene la llave pública (cer) del CSD.
• llavePrivadaBase64: valor de tipo “byte()” o expresado en “base64” según sea el caso de implementación, que contiene la llave privada (key) del CSD.

Agregar CSD Emisor por medio de interfaz gráfica

Para el ambiente de Producción en timbrado por layout TXT es necesario que el Emisor proporcione la llave pública (.cer) y privada (.key) del CSD solo una ocasión (no es necesario cargar el CSD en cada petición) para sellar el XML a timbrar consumiendo el método “agregarCSD” del Web Service o a través de cualquiera de las siguientes URL:

Agregar Logo

En caso de requerir que el PDF del CFDI contenga un logotipo personalizado es necesario proporcionar la imagen en formato JPEG con una resolución de 300 ppp (pixeles por pulgada).

Los parámetros que se solicitan además de los generales son los siguientes:

• rfcEmisor: valor de tipo “string” donde se indica el RFC Emisor al que corresponde el logotipo, cuando el RFC Emisor del XML coincida con el RFC del logotipo éste último será incrustado en el PDF.

• logoBase64: expresado en “base64” según sea el caso de implementación, que contiene la imagen en formato JPEG en una resolución de 300 ppp (pixeles por pulgada).

Obtener PDF de Acuse de Cancelación

En caso de requerir una representación impresa del Acuse de Cancelación de CFDI del SAT podrá implementarse este método/operación.

Los parámetros que se solicitan además de los generales son los siguientes:

• archivoBase64: expresado en “base64” según sea el caso de implementación, que contiene el Acuse de Cancelación de CFDI del SAT en formato XML.

• plantilla: valor de tipo “integer” que indica el número de plantilla PDF a implementar, por default la plantilla genérica debe ser “1” salvo que se haya contratado una plantilla personalizada se indicará el valor a ingresar en dicho campo.

• observaciones: valor opcional de tipo “string” que indica las observaciones que el usuario desee agregar al documento PDF, similar a las observaciones de un CFDI.

Obtener Código QR

En caso de requerir el código QR en formato de imagen conforme el estándar del SAT indicado en Anexo 20 podrá implementarse este método/operación.

Los parámetros que se solicitan además de los generales son los siguientes:

• archivoXMLBase64: valor de tipo “byte()” o expresado en “base64” según sea el caso de implementación, que contiene el CFDI debidamente timbrado en formato XML.

Obtener PDF y XML

Por medio de esta operación/método es posible recibir un Layout TXT con los complementos Nómina 1.2, Detallista 1.0, Pagos 2.0 y Comercio Exterior 1.1, o en su defecto un XML de CFDI v. 4.0 que incluya cualquier complemento del SAT debidamente formado y sellado con el CSD Emisor.

El Web Service identificará si se trata de un XML o un Layout TXT, en el caso de este último se procederá a serializar el XML, sellarlo con el CSD Emisor previamente cargado a través de la operación/método “agregarCSD”, y crear el documento PDF (opcional).

El Layout TXT está disponible para los clientes que no generan un XML sellado, básicamente recibe un archivo de texto plano con la información del comprobante separada por pipes “|” y el servicio se encarga de serializar y sellar el XML, como respuesta durante la petición devuelve el XML sin timbre y si se desea la representación impresa en PDF.

Los parámetros que se solicitan además de los generales son los siguientes:

• archivoBase64: expresado en “base64” según sea el caso de implementación, que contiene el Layout TXT o XML a timbrar.

• plantilla: valor opcional de tipo “Integer” que indica el número de plantilla PDF a implementar, por default la plantilla genérica debe ser “1”, “2”, “3” ó “4” en caso de CFDI de tipo “I, E, T, P” ó “201” en caso de CFDI de tipo “N”, salvo que se haya contratado una plantilla personalizada se indicará el valor a ingresar en dicho campo.

• observaciones: valor opcional de tipo “string” que indica las observaciones que el usuario desee agregar al documento PDF, similar a las observaciones de un CFDI.

Timbrar

Por medio de esta operación/método es posible timbrar un Layout TXT con los complementos Nómina 1.2, Detallista 1.0, Pagos 2.0 y Comercio Exterior 1.1, o en su defecto timbrar un XML de CFDI v. 4.0 que incluya cualquier complemento del SAT debidamente formado y sellado con el CSD Emisor.

El Web Service identificará si se trata de un XML o un Layout TXT, en el caso de este último se procederá a serializar el XML, sellarlo con el CSD Emisor previamente cargado a través de la operación/método “agregarCSD”, timbrar el XML serializado, crear el documento PDF (opcional) y finalmente disponer del CFDI en el Panel de Administración de Recibos de Nómina en caso de haberse contratado, todo en una misma transacción.

El Layout TXT está disponible para los clientes que no generan un XML sellado, básicamente recibe un archivo de texto plano con la información del comprobante separada por pipes “|” y el servicio se encarga de serializar, sellar y timbrar el XML, como respuesta durante la petición devuelve el XML timbrado y si se desea la representación impresa en PDF.

Los parámetros que se solicitan además de los generales son los siguientes:

• archivoBase64: valor de tipo “byte()” o expresado en “base64” según sea el caso de implementación, que contiene el Layout TXT o XML a timbrar.

• generaPDF: valor de tipo “boolean” que indica si el usuario requiere que se le retorne la representación impresa del CFDI en formato PDF.

• plantilla: valor opcional de tipo “integer” que indica el número de plantilla PDF a implementar, por default la plantilla genérica debe ser “1”, “2”, “3” ó “4” en caso de CFDI de tipo “I, E, T, P” ó “201” en caso de CFDI de tipo “N”, salvo que se haya contratado una plantilla personalizada se indicará el valor a ingresar en dicho campo.

• propertiesBase64: expresado en “base64” según sea el caso de implementación, que contiene información adicional dado el caso de negocio: ✓ Properties = “Prefactura” En este caso el CFDI no se timbrará solo se entregará el XML sellado y el PDF sin Timbre Fiscal Digital, es funcional en casos donde se requiere visualizar la información antes de timbrarse, es importante considerar que el XML generado no ha sido validado por el PCCFDI ya que este último paso se realiza al momento de timbrar.

Llenado del Layout TXT

Existe un Layout definido para cada complemento, mismos que se adjuntan en el directorio “Layouts Timbrado Bridge” donde también encontrará ejemplos de llenado, más sin embargo es importante citar a continuación las consideraciones generales del llenado del Layout.

• Los campos sin signos indican que son opcionales según el SAT.
• Para la mejor comprensión de la organización del Layout el estándar contiene tabulaciones al inicio de cada línea, en la práctica estas pueden omitirse para ahorrar espacio. El orden del Layout obedece el XSD estándar del SAT.
• : Representa un nodo del XML.
• [] Representa que tipo de valor debe contener el campo o bien que valor por default.
• * Representa un Atributo que es Requerido por el SAT
• ** Representa un Nodo o Atributo que es condicional, es decir que depende de las Validaciones Adicionales del SAT pudiendo convertirse en Opcional o Requerido según el caso a validar.
• *** Representa un nodo Iterativo, es decir que puede venir "n" veces dentro del XML (Layout) y por lo tanto puede omitirse en caso de no requerirlo, su existencia depende del valor entero que haya sido especificado para determinar si existirá, por ejemplo:
Si el campo "numTraslados" es igual a 0 el nodo "Traslado:" no debe incluirse.
Si el campo "numTraslados" es igual a 2 el nodo "Traslado:" debe incluirse 2
veces:

Traslado:***|Impuesto*|TipoFactor*|TasaOCuota*|Importe*|
Traslado:***|Impuesto*|TipoFactor*|TasaOCuota*|Importe*|

• Campos con prefijo "num" Se debe indicar cuantos nodos iterativos hijo contiene el Layout en el nivel que se encuentra el prefijo, este campo debe contener un valor entero, ejemplo:

Concepto:|numTrasladosConcepto*[Entero]|
Concepto:|2|

Web Service SOAP de Timbrado TXT para producción

Web Service Restfull de Timbrado TXT para producción

Tabla 3. Web Services ambiente de producción servicio REST.

Web Service SOAP de Timbrado TXT para pre-producción

Web Service Restfull de Timbrado TXT para pre-producción

Tabla 4. Web Services ambiente de pruebas servicio REST.

Códigos de respuesta para el timbrado de CFDI

A continuación, se describen los códigos de respuesta principales y mensajes que el servicio de timbrado devuelve:

Tabla 5. Código de Respuesta de timbrado de CFDI

En especial el código 504 – Ya ha sido timbrado previamente se presenta cuando un CFDI ha sido enviado con anterioridad, por lo que el archivo no será procesado ni timbrado, pero de igual forma se regresará un timbre que es correspondiente al archivo timbrado por primera vez.

Adicionalmente también se devolverán los códigos y mensajes de error estandarizados por el SAT con objeto de las Validaciones Adicionales de CFDI 4.0 y sus complementos.