API DE INTEGRACIÓN PARA TIMBRADO DE CFDI v4.0

 

Revisión 1	Fecha	Comentarios
1	2017-04-10	Versión inicial de la documentación
2	2017-11­‐06	Se ordena la información y se agregan los métodos de cancelación y consulta en REST y SOAP
3	2020-04-12	Se agregan los métodos de acuse de cancelación, cancelar cfdi, consulta de Cfdi por UUID, Cfd por uuid, consultar cfdi relacionados, consultar peticiones pendientes, responder solicitud cancelación.
4	2020-06-23	Se agregó la opción generar código de barras bidimensional (GENERAR_CBB)
5	2020-08-05	Se actualiza información en los métodos de timbrado vía REST y se agrega url para timbrado en base 64.
6	2020-12-16	Se agrega información de los metodos de timbradoConCSD(SOAP) y timbrarConCSD(REST)
7	2021-03-29	Se agrega información del Portal Firmado Carta Manifiesto
8	2021-06-29	Se agrega la opción de RESPUESTA_JSON
9	2021-10-08	Se agrega la opción de ESTABLECER_CERTIFICADO
10	2021-11-12	Se agrega la opción de CORREGIR_NAMESPACES
11	2021-12-23	Se agrega cambio en cancelación y catálogo de Motivos de Cancelación
12	2022-01-03	Se agrega conexión al servicio de timbrado CFDI 4.0
13	2022-01-04	Se agrega opción ESTABLECER_NO_CERTIFICADO
14	2022-03-01	Se agrega el metodo de enviarXmlAndPdfPorCorreo
15	2022-05-12	Se agrega el la opción REGRESAR_RFCPROVCERTIF

Tabla de contenido

• Prerrequisitos.
• Conexión al Servicio de Timbrado CFDI v3.3
• SOAP
• REST
• XML de ejemplo con estructura correcta.
• Conexión al Servicio de Timbrado CFDI 4.0
  • SOAP
  • REST
  • XML de ejemplo con estructura correcta.
• Descripción del Servicio.
  • Métodos de Timbrado.
    • Nombre de los métodos de timbrado.
    • Parámetros del método de Timbrado.
    • XML de respuesta del Servicio de Timbrado.
  • Opciones del Servicio.
• Generar valor para atributo Confirmación.
  • ¿Qué es el atributo Confirmación?
  • ¿Cuándo lo necesito?
  • ¿Cómo genero este valor con Prodigia?
• Métodos para cancelación de CFDI vía SOAP
  • Cancelación
  • Cancelación con opciones
• Método para cancelación de CFDI vía REST
• Método para consulta de estatus de CFDI vía REST
• Operación para consulta de un CFDI
  • Método de consulta de CFDI por UUID vía SOAP.
  • Método de consulta de CFDI por UUID vía REST.
• Tabla 1: Opciones para los diferentes servicios.
• Tabla 2: Códigos de respuesta para los diferentes servicios.
• Tabla 3: Códigos para los nuevos estatus de cancelación.
  Tabla 4: Códigos para el nodo estatusCfdi en el método de consulta estatus de comprobantes.
• Método para acuse de cancelación
  • Descripción
  • Parámetros
  • Atributos
  • Ejemplo de petición REST
• Método para cancelar cfdi.
  • Descripción
  • Parámetros
  • Atributos
  • Ejemplo de petición REST
  • Códigos presentados en el atributo resultado.
• Método para consultar Cfdi por UUID.
  • Descripción
  • Parámetros
  • Atributos
  • Códigos de estatus en la respuesta
  • Ejemplo de petición REST
• Método para consultar cfdi relacionados
  • Descripción
  • Parámetros
  • Ejemplo de petición REST
  • Atributos
  • Códigos presentados en el atributo resultado.
• Método para consultar peticiones pendientes.
  • Descripción
  • Parámetros
  • Ejemplo de petición REST
  • Atributos
  • Códigos de estatus en la respuesta
• Método responder solicitud cancelación.
  • Descripción
  • Parámetros
  • Ejemplo de petición REST
  • Atributos
  • Estatus UUID en la respuesta

Prerrequisitos

• Contar con un Certificado de Sello Digital válido ante el SAT.
• Estar registrado en la plataforma de  PADE  (con esto obtienes el usuario, contraseña y contrato necesario para autenticarte en el servicio).
• Contar con un software cliente para realizar las peticiones de timbrado.

---

Conexión al servicio de timbrado CFDI v4.0   

El servicio se encuentra disponible en una dirección URL pública:

URL del servicio: https://timbrado.pade.mx/servicio/Timbrado4.0

Parámetros de conexión al servicio. 

• CONTRATO
• USUARIO
• CONTRASEÑA

Al ingresar incorrectamente por 3 veces los atributos de las credenciales de acceso (usuario y contraseña) que se utilizan a través de cualquier servicio (Plataforma pade o web service) se bloquearan, después del bloqueo puede realizarse un desbloqueo ingresando en la plataforma Pade (https://facturacion.pade.mx/) a través del apartado “¿Olvidó su contraseña?” donde se debe ingresar el código de cliente y nombre de usuario para recibir una nueva contraseña al correo asociado con el usuario, la cual debe actualizarse iniciando sesión en la plataforma. 

En caso de utilizar la plataforma pade aplica el RFC, usuario y contraseña, para los web service es contrato, usuario y contraseña, al enviar mal el contrato, el servicio considera que el contrato con código [CONTRATO] no fue encontrado (código 2) pero no aplica como error de log in.

Ejemplo: “<codigo>2</codigo><mensaje>El contrato con código 4b24aa84-a6fa-11a2-a999-109aaaa4aaa20 no fue encontrado</mensaje>”.

Aplica para el servicio en SOAP y REST

SOAP

Ejemplo de petición para timbrar un XML versión 3.3. Se puede observar los parámetros necesarios para el servicio, los cuales se describen más adelante.

REST

El servicio de timbrado mediante REST puede ser accedido desde :

• El urlquery de la petición en REST deberá ser del tipo “POST” y contener al menos el parámetro “contrato” con el código de contrato del usuario como “Query Parameter”.
• También pueden ser especificadas como “Query Parameters” las opciones de timbrado que se detallan en la sección “Opciones del Servicio” (de manera opcional).
• Las credenciales (usuario y contraseña) deberán ir en el HEAD de la petición mediante el atributo “Authorization Basic” con el formato usuario:password codificados en Base64.
• El tipo de contenido (atributo Content-Type) para timbrado y timbradoPrueba será “application/xml”, para timbrarConCSD “application/json” y para timbradoBase64 “text/plain” .
• El parámetro xml deberá enviarse en el “Body” de la petición.
• Para el método timbradoBase64 se deberá agregar el archivo xml codificado en Base64 dentro del “Body”.
• Para el método timbrarConCSD se deberá agregar el archivo en formato JSON dentro del “Body”.

Ejemplo de petición mediante el cliente Advanced REST Client:

Ejemplo de petición REST

Ejemplo de HEAD en la petición

Ejemplo de respuesta del servicio de timbrado:

timbrarConCSD (REST) 

En caso de requerir enviar los archivos del certificado del sello digital (CSD) en la petición y no calcularlos previamente ni solicitar que se calculen por parte de prodigia al enviar la petición, puede utilizarse el método timbrarConCSD (REST) donde pueden enviarse los archivos del CSD codificados en base64 para la construcción del sello del comprobante, como se aprecia en la siguiente petición:

XML de ejemplo con estructura correcta.

El siguiente ejemplo es un XML con estructura correcta. Se recomienda su uso para tener una base y a partir de éste, generar los comprobantes propios.

TimbradoConCSD (SOAP)

En caso de requerir enviar los archivos del certificado del sello digital (CSD) en la petición y no calcularlos previamente ni solicitar que se calculen por parte de prodigia, puede utilizarse el método timbradoConCSD (SOAP) donde se pueden enviar los archivos codificados en base64 para la construcción del sello del comprobante, como se aprecia en la siguiente petición:

NOTA: Los parámetros <cert>, <key> y <keyPass> son requeridos en dicho método.

Conexión al servicio de timbrado CFDI v4.0   

El servicio se encuentra disponible en una dirección URL pública:

URL del servicio:  https://timbrado.pade.mx/servicio/Timbrado4.0

Parámetros de conexión al servicio. 

• CONTRATO

• USUARIO

• CONTRASEÑA

Al ingresar incorrectamente por 3 veces los atributos de las credenciales de acceso (usuario y contraseña) que se utilizan a través de cualquier servicio (Plataforma pade o web service) se bloquearan, después del bloqueo puede realizarse un desbloqueo ingresando en la plataforma Pade (https://facturacion.pade.mx/) a través del apartado “¿Olvidó su contraseña?” donde se debe ingresar el código de cliente y nombre de usuario para recibir una nueva contraseña al correo asociado con el usuario, la cual debe actualizarse iniciando sesión en la plataforma. 

En caso de utilizar la plataforma pade aplica el RFC, usuario y contraseña, para los web service es contrato, usuario y contraseña, al enviar mal el contrato, el servicio considera que el contrato con código [CONTRATO] no fue encontrado (código 2) pero no aplica como error de log in.

Ejemplo:  “<codigo>2</codigo><mensaje>El contrato con código 4b24aa84-a6fa-11a2-a999-109aaaa4aaa20 no fue encontrado</mensaje>”.

Aplica para el servicio en SOAP y REST

SOAP

Ejemplo de petición para timbrar un XML versión 4.0. Se puede observar los parámetros necesarios para el servicio, los cuales se describen más adelante.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:pru="https://timbrado.ws.pade.mx">

<soapenv:Header/>

<soapenv:Body> <pru:timbradoPrueba> <contrato>CONTRATO</contrato> <!--Optional:--> <usuario>USUARIO</usuario> <!--Optional:--> <passwd>CONTRASEÑA</passwd> <!--Optional:--> <cfdiXml><![CDATA[<?xml version="1.0" encoding="UTF-8"?> <cfdi:Comprobante Certificado="MIIFxTCCA62gAwIBAgIUMjAwMDEwMDAwMDAzMDAwMjI4MTUwDQYJKoZIhvcNAQELBQAwggFmMSAwHgYDVQQDDBdBLkMuIDIgZGUgcHJ1ZWJhcyg0MDk2KTEvMC0GA1UECgwmU2VydmljaW8gZGUgQWRtaW5pc3RyYWNpw7NuIFRyaWJ1dGFyaWExODA2BgNVBAsML0FkbWluaXN0cmFjacOzbiBkZSBTZWd1cmlkYWQgZGUgbGEgSW5mb3JtYWNpw7NuMSkwJwYJKoZIhvcNAQkBFhphc2lzbmV0QHBydWViYXMuc2F0LmdvYi5teDEmMCQGA1UECQwdQXYuIEhpZGFsZ28gNzcsIENvbC4gR3VlcnJlcm8xDjAMBgNVBBEMBTA2MzAwMQswCQYDVQQGEwJNWDEZMBcGA1UECAwQRGlzdHJpdG8gRmVkZXJhbDESMBAGA1UEBwwJQ295b2Fjw6FuMRUwEwYDVQQtEwxTQVQ5NzA3MDFOTjMxITAfBgkqhkiG9w0BCQIMElJlc3BvbnNhYmxlOiBBQ0RNQTAeFw0xNjEwMjUyMTUyMTFaFw0yMDEwMjUyMTUyMTFaMIGxMRowGAYDVQQDExFDSU5ERU1FWCBTQSBERSBDVjEaMBgGA1UEKRMRQ0lOREVNRVggU0EgREUgQ1YxGjAYBgNVBAoTEUNJTkRFTUVYIFNBIERFIENWMSUwIwYDVQQtExxMQU43MDA4MTczUjUgLyBGVUFCNzcwMTE3QlhBMR4wHAYDVQQFExUgLyBGVUFCNzcwMTE3TURGUk5OMDkxFDASBgNVBAsUC1BydWViYV9DRkRJMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAgvvCiCFDFVaYX7xdVRhp/38ULWto/LKDSZy1yrXKpaqFXqERJWF78YHKf3N5GBoXgzwFPuDX+5kvY5wtYNxx/Owu2shNZqFFh6EKsysQMeP5rz6kE1gFYenaPEUP9zj+h0bL3xR5aqoTsqGF24mKBLoiaK44pXBzGzgsxZishVJVM6XbzNJVonEUNbI25DhgWAd86f2aU3BmOH2K1RZx41dtTT56UsszJls4tPFODr/caWuZEuUvLp1M3nj7Dyu88mhD2f+1fA/g7kzcU/1tcpFXF/rIy93APvkU72jwvkrnprzs+SnG81+/F16ahuGsb2EZ88dKHwqxEkwzhMyTbQIDAQABox0wGzAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIGwDANBgkqhkiG9w0BAQsFAAOCAgEAJ/xkL8I+fpilZP+9aO8n93+20XxVomLJjeSL+Ng2ErL2GgatpLuN5JknFBkZAhxVIgMaTS23zzk1RLtRaYvH83lBH5E+M+kEjFGp14Fne1iV2Pm3vL4jeLmzHgY1Kf5HmeVrrp4PU7WQg16VpyHaJ/eonPNiEBUjcyQ1iFfkzJmnSJvDGtfQK2TiEolDJApYv0OWdm4is9Bsfi9j6lI9/T6MNZ+/LM2L/t72Vau4r7m94JDEzaO3A0wHAtQ97fjBfBiO5M8AEISAV7eZidIl3iaJJHkQbBYiiW2gikreUZKPUX0HmlnIqqQcBJhWKRu6Nqk6aZBTETLLpGrvF9OArV1JSsbdw/ZH+P88RAt5em5/gjwwtFlNHyiKG5w+UFpaZOK3gZP0su0sa6dlPeQ9EL4JlFkGqQCgSQ+NOsXqaOavgoP5VLykLwuGnwIUnuhBTVeDbzpgrg9LuF5dYp/zs+Y9ScJqe5VMAagLSYTShNtN8luV7LvxF9pgWwZdcM7lUwqJmUddCiZqdngg3vzTactMToG16gZA4CWnMgbU4E+r541+FNMpgAZNvs2CiW/eApfaaQojsZEAHDsDv4L5n3M1CC7fYjE/d61aSng1LaO6T1mh+dEfPvLzp7zyzz+UgWMhi5Cs4pcXx1eic5r7uxPoBwcCTt3YI1jKVVnV7/w=" Exportacion="01" Fecha="2022-01-03T10:34:42" Folio="CFDI" FormaPago="01" LugarExpedicion="83000" MetodoPago="PUE" Moneda="MXN" NoCertificado="20001000000300022815" Sello="cQrKgB/b+Q4nGdBBUYblfLjhV8yubKVvfVAqLQSA0DroGDNYUs4YFPvwU3sg97FzbOzSqMj3lNthTQxSTiWH2qjHfbUQlVK8whlhS/0ETR1AB5HOA7v66bjoNOTL3EozYZpwv2QvJNbqPB+yxpgs/XOx9o96DMzOOttR1uVbkzYKtfFjoS+w+XTep6BAi1eOAsVcpShmHNV9VjEhpwaWk4kiLynWQrmiQysRTVOtE90wadUasmRJK/ZuCwYYo/w2GAP4lcB2SlZW0YJRO4DNA5L7pV7r0PhW3X27FCnJxtbfvF7mUM54XCa0Dxqcx0jHkbWi42XATOqIbNSe8TQyqw==" Serie="4" SubTotal="10" TipoDeComprobante="I" Total="10.32" Version="4.0" xmlns:cfdi="http://www.sat.gob.mx/cfd/4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sat.gob.mx/cfd/4 http://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd"> <cfdi:InformacionGlobal Año="2021" Meses="10" Periodicidad="04"/> <cfdi:CfdiRelacionados TipoRelacion="01"> <cfdi:CfdiRelacionado UUID="A39DA66B-52CA-49E3-879B-5C05185B0EF7"/> </cfdi:CfdiRelacionados> <cfdi:Emisor Nombre="XENON INDUSTRIAL ARTICLES S DE CV" RegimenFiscal="601" Rfc="XIA190128J61"/> <cfdi:Receptor DomicilioFiscalReceptor="83000" Nombre="PUBLICO EN GENERAL" RegimenFiscalReceptor="616" Rfc="XAXX010101000" UsoCFDI="G03"/> <cfdi:Conceptos> <cfdi:Concepto Cantidad="2.00" ClaveProdServ="01010101" ClaveUnidad="CMT" Descripcion="ACERO" Importe="10.00" NoIdentificacion="00001" ObjetoImp="02" Unidad="TONELADA" ValorUnitario="5.00"> <cfdi:Impuestos> <cfdi:Traslados> <cfdi:Traslado Base="2.00" Importe="0.32" Impuesto="002" TasaOCuota="0.160000" TipoFactor="Tasa"/> </cfdi:Traslados> <cfdi:Retenciones> <cfdi:Retencion Base="2.00" Importe="0" Impuesto="002" TasaOCuota="0" TipoFactor="Tasa"/> </cfdi:Retenciones> </cfdi:Impuestos> <cfdi:CuentaPredial Numero="51888"/> </cfdi:Concepto> </cfdi:Conceptos> <cfdi:Impuestos TotalImpuestosRetenidos="0.00" TotalImpuestosTrasladados="0.32"> <cfdi:Retenciones> <cfdi:Retencion Importe="0" Impuesto="002"/> </cfdi:Retenciones> <cfdi:Traslados> <cfdi:Traslado Base="2.0" Importe="0.32" Impuesto="002" TasaOCuota="0.160000" TipoFactor="Tasa"/> </cfdi:Traslados> </cfdi:Impuestos> </cfdi:Comprobante>]]></cfdiXml> <!--Zero or more repetitions:--> <opciones>CALCULAR_SELLO</opciones> </pru:timbradoPrueba> </soapenv:Body> </soapenv:Envelope>

REST

El servicio de timbrado mediante REST puede ser accedido desde : .

https://timbrado.pade.mx/servicio/rest/timbrado40 (Timbrado en produccion)

https://timbrado.pade.mx/servicio/rest/timbrado40Prueba (Timbrado de prueba sin valor fiscal)

https://timbrado.pade.mx/servicio/rest/timbrado/timbrado40Base64 (Timbrado en Base64, para modo prueba utilizar “/timbrado40Prueba/timbradoBase64”).

• El urlquery de la petición en REST deberá ser del tipo “POST” y contener al menos el parámetro “contrato” con el código de contrato del usuario como “Query Parameter”.

• También pueden ser especificadas como “Query Parameters” las opciones de timbrado que se detallan en la sección “Opciones del Servicio” (de manera opcional).

• Las credenciales (usuario y contraseña) deberán ir en el HEAD de la petición mediante el atributo “Authorization Basic” con el formato usuario:password codificados en Base64.

• El tipo de contenido (atributo Content-Type) para timbrado40 y timbrado40Prueba será “application/xml”, para timbrarConCSD “application/json” y para timbrado40Base64 “text/plain” .

• El parámetro xml deberá enviarse en el “Body” de la petición.

• Para el método timbrado40Base64 se deberá agregar el archivo xml codificado en Base64 dentro del “Body”.

• Para el método timbrarConCSD se deberá agregar el archivo en formato JSON dentro del “Body”.

Ejemplo de petición mediante el cliente Advanced REST Client:

Ejemplo de petición RES T

Ejemplo de HEAD en la petición

XML de ejemplo con estructura correcta.

El siguiente ejemplo es un XML con estructura correcta. Se recomienda su uso para tener una base y a partir de éste, generar los comprobantes propios.s

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:timbradoResponse xmlns:ns2="timbrado.ws.pade.mx"> <return><![CDATA[<?xml version="1.0" encoding="UTF-8"?><servicioTimbrado> <id>ece31473-4fd3-44bc-b490-24aca6bbf0dc</id> <timbradoOk>true</timbradoOk> <contrato>9f686960-169e-11e2-ae20-109add4fad20</contrato> <codigo>0</codigo> <version>1.0</version> <UUID>600C98C0-BE60-4C67-BA80-B2F09251C378</UUID> <FechaTimbrado>2017-04-07T10:53:33</FechaTimbrado> <selloCFD>h/zU4yY3Ac+1xfVcQw3kTTeYv9Qyqn5GNpBc9eUZTUdKdgM2+M3h7L60G+lXiUUsYiL70ypZPtZdsKxrPrwrpnCTRPhbLSTV3bSoafv0ClLc+Qmmhv8gMk4mLokreQP9LrhHVp3VxhVEz1SZEIZ81ibVcbI73/H2o/TGuoEMnn0=</selloCFD> <noCertificadoSAT>20001000000300022323 </noCertificadoSAT> <selloSAT>IbN7vFwPlb6nU5sx9flXZozw9jlIAcsnVVf+VB6YD9AHnvtUFiHc9QUTZTWy/UqcAVvUf1klC5sqyOLBBNgBTqM+WCE3/++F0oeRgvqpu4f6d+LFZbuHPXgW4bKzuUORnZOoqfCglCFBza/N98srBFv5FNp9AtAtzn8fUMtwyui8sXXH715MPjZAYvPqyDj/Zn67s+h9njJCYaL7X4mRWgXAT2pMldD6Byu432CF6dhjTL2pbL7QQF/FHgshEjtkg612cKGV4sE3YW8NI0KeeoH4GHC9KJ408UUIUY4qTOPNpJHL672EV3IJu6NhloLZcjt050sPSTCjv5ATDcwQqw==</selloSAT> <xmlBase64>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48Y2ZkaTpDb21wcm9iYW50ZSB4bWxuczpjZmRpPSJodHRwOi8vd3d3LnNhdC5nb2IubXgvY2ZkLzMiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIENlcnRpZmljYWRvPSJNSUlFWVRDQ0EwbWdBd0lCQWdJVU1qQXdNREV3TURBd01EQXlNREF3TURFME1qZ3dEUVlKS29aSWh2Y05BUUVGQlFBd2dnRmNNUm93R0FZRFZRUUREQkZCTGtNdUlESWdaR1VnY0hKMVpXSmhjekV2TUMwR0ExVUVDZ3dtVTJWeWRtbGphVzhnWkdVZ1FXUnRhVzVwYzNSeVlXTnB3N051SUZSeWFXSjFkR0Z5YVdFeE9EQTJCZ05WQkFzTUwwRmtiV2x1YVhOMGNtRmphY096YmlCa1pTQlRaV2QxY21sa1lXUWdaR1VnYkdFZ1NXNW1iM0p0WVdOcHc3TnVNU2t3SndZSktvWklodmNOQVFrQkZocGhjMmx6Ym1WMFFIQnlkV1ZpWVhNdWMyRjBMbWR2WWk1dGVERW1NQ1FHQTFVRUNRd2RRWFl1SUVocFpHRnNaMjhnTnpjc0lFTnZiQzRnUjNWbGNuSmxjbTh4RGpBTUJnTlZCQkVNQlRBMk16QXdNUXN3Q1FZRFZRUUdFd0pOV0RFWk1CY0dBMVVFQ0F3UVJHbHpkSEpwZEc4Z1JtVmtaWEpoYkRFU01CQUdBMVVFQnd3SlEyOTViMkZqdzZGdU1UUXdNZ1lKS29aSWh2Y05BUWtDRENWU1pYTndiMjV6WVdKc1pUb2dRWEpoWTJWc2FTQkhZVzVrWVhKaElFSmhkWFJwYzNSaE1CNFhEVEV6TURVd056RTJNREV5T1ZvWERURTNNRFV3TnpFMk1ERXlPVm93Z2RzeEtUQW5CZ05WQkFNVElFRkRRMFZOSUZORlVsWkpRMGxQVXlCRlRWQlNSVk5CVWtsQlRFVlRJRk5ETVNrd0p3WURWUVFwRXlCQlEwTkZUU0JUUlZKV1NVTkpUMU1nUlUxUVVrVlRRVkpKUVV4RlV5QlRRekVwTUNjR0ExVUVDaE1nUVVORFJVMGdVMFZTVmtsRFNVOVRJRVZOVUZKRlUwRlNTVUZNUlZNZ1UwTXhKVEFqQmdOVkJDMFRIRUZCUVRBeE1ERXdNVUZCUVNBdklFaEZSMVEzTmpFd01ETTBVekl4SGpBY0JnTlZCQVVURlNBdklFaEZSMVEzTmpFd01ETk5SRVpPVTFJd09ERVJNQThHQTFVRUN4TUljSEp2WkhWamRHOHdnWjh3RFFZSktvWklodmNOQVFFQkJRQURnWTBBTUlHSkFvR0JBS1MvYmVVVnk2RTNhT0RhTnVMZDJTM1BYYVFyZTB0R3htWVRlVXhhNTV4MnQvNzkxOXR0Z09wS0Y2aFBGNUt2bFloNHp0cVFxUDR5RVYrSGpIN3l5LzJkLytlN3QrSjYxalRyYmRMcVQzV0QwK3M1ZkNMNkpPckY0aHF5Ly9FR2RmdllmdGRHUk5yWkgrZEFqV1dtbDJTL2hyTjlhVXhyYVM1cXFPMWI3YnRsQWdNQkFBR2pIVEFiTUF3R0ExVWRFd0VCL3dRQ01BQXdDd1lEVlIwUEJBUURBZ2JBTUEwR0NTcUdTSWIzRFFFQkJRVUFBNElCQVFBQ1BYQVdaWDJEdUtpWlZ2MzVSUzFXRktnVDJ1YlVPOUMrYnlmWmFwVjZaellOT2lBNEttcGtxSFUvYmtaSHFLalIrUjU5aG9ZaFZkbitDbFVJbGlaZjJDaEhoOHMwYTB2QlJOSjNJSGZBMWFrV2R6b2NZWkxYanozbTBFcjMxQlkrdVMzcVdVdFBzT05HVkR5Wkw2SVVCQlVsRm9lY1FoUDlBTzM5ZXI4ekliZVUyYjBNTUJKeEN0NHZiREtGdlQ5aTNWMFB1b28ra21ta2YxNUQyckJHUitkcmQ4SDhZZzhUREdGS2YyekttUnNnVDduSWVvdTZXcGZZcDU3MFdJdkxKUVkrZnNNcDMzNEQwNVVwNXlrWVNBeFVHYTMwUmRVekE0cnhONWhUK1c5d2hXVkdEODhURDMzTnc1NXVOUlVjUk8zWlVWSG1kV1JHK0dqaGxmc0QiIENvbmRpY2lvbmVzRGVQYWdvPSJDT05ESUNJT05FUyIgRmVjaGE9IjIwMTctMDQtMDdUMDg6MDA6MDAiIEZvbGlvPSIxNjdBQkMiIEZvcm1hUGFnbz0iMDEiIEx1Z2FyRXhwZWRpY2lvbj0iNDUwNzkiIE1ldG9kb1BhZ289IlBVRSIgTW9uZWRhPSJNWE4iIE5vQ2VydGlmaWNhZG89IjIwMDAxMDAwMDAwMjAwMDAxNDI4IiBTZWxsbz0iaC96VTR5WTNBYysxeGZWY1F3M2tUVGVZdjlReXFuNUdOcEJjOWVVWlRVZEtkZ00yK00zaDdMNjBHK2xYaVVVc1lpTDcweXBaUHRaZHNLeHJQcndycG5DVFJQaGJMU1RWM2JTb2FmdjBDbExjK1FtbWh2OGdNazRtTG9rcmVRUDlMcmhIVnAzVnhoVkV6MVNaRUlaODFpYlZjYkk3My9IMm8vVEd1b0VNbm4wPSIgU2VyaWU9IkEiIFN1YlRvdGFsPSIxMCIgVGlwb0RlQ29tcHJvYmFudGU9IkkiIFRvdGFsPSIxMC4zMiIgVmVyc2lvbj0iMy4zIiB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cuc2F0LmdvYi5teC9jZmQvMyBodHRwOi8vd3d3LnNhdC5nb2IubXgvc2l0aW9faW50ZXJuZXQvY2ZkLzMvY2ZkdjMzLnhzZCI+PGNmZGk6Q2ZkaVJlbGFjaW9uYWRvcyBUaXBvUmVsYWNpb249IjAxIj48Y2ZkaTpDZmRpUmVsYWNpb25hZG8gVVVJRD0iQTM5REE2NkItNTJDQS00OUUzLTg3OUItNUMwNTE4NUIwRUY3Ii8+PC9jZmRpOkNmZGlSZWxhY2lvbmFkb3M+PGNmZGk6RW1pc29yIE5vbWJyZT0iSE9SQUNJTyBMTEFOT1MiIFJlZ2ltZW5GaXNjYWw9IjYwMSIgUmZjPSJMQU43MDA4MTczUjUiLz48Y2ZkaTpSZWNlcHRvciBOb21icmU9IlJBRkFFTCBBTEVKQU5EUk8gSEVSTsOBTkRFWiBQQUxBQ0lPUyIgUmZjPSJIRVBSOTMwMzIyOTc3IiBVc29DRkRJPSJHMDEiLz48Y2ZkaTpDb25jZXB0b3M+PGNmZGk6Q29uY2VwdG8gQ2FudGlkYWQ9IjIuMDAiIENsYXZlUHJvZFNlcnY9IjAxMDEwMTAxIiBDbGF2ZVVuaWRhZD0iQ01UIiBEZXNjcmlwY2lvbj0iQUNFUk8iIEltcG9ydGU9IjEwLjAwIiBOb0lkZW50aWZpY2FjaW9uPSIwMDAwMSIgVW5pZGFkPSJUT05FTEFEQSIgVmFsb3JVbml0YXJpbz0iNS4wMCI+PGNmZGk6SW1wdWVzdG9zPjxjZmRpOlRyYXNsYWRvcz48Y2ZkaTpUcmFzbGFkbyBCYXNlPSIyLjAwIiBJbXBvcnRlPSIwLjMyIiBJbXB1ZXN0bz0iMDAyIiBUYXNhT0N1b3RhPSIwLjE2MDAwMCIgVGlwb0ZhY3Rvcj0iVGFzYSIvPjwvY2ZkaTpUcmFzbGFkb3M+PGNmZGk6UmV0ZW5jaW9uZXM+PGNmZGk6UmV0ZW5jaW9uIEJhc2U9IjIuMDAiIEltcG9ydGU9IjAiIEltcHVlc3RvPSIwMDIiIFRhc2FPQ3VvdGE9IjAiIFRpcG9GYWN0b3I9IlRhc2EiLz48L2NmZGk6UmV0ZW5jaW9uZXM+PC9jZmRpOkltcHVlc3Rvcz48Y2ZkaTpDdWVudGFQcmVkaWFsIE51bWVybz0iNTE4ODgiLz48Y2ZkaTpQYXJ0ZSBDYW50aWRhZD0iMSIgQ2xhdmVQcm9kU2Vydj0iMDEwMTAxMDEiIERlc2NyaXBjaW9uPSJhc2QiPjxjZmRpOkluZm9ybWFjaW9uQWR1YW5lcmEgTnVtZXJvUGVkaW1lbnRvPSIxNSAgNDggIDQ1NjcgIDY5ODEyMzUiLz48L2NmZGk6UGFydGU+PC9jZmRpOkNvbmNlcHRvPjwvY2ZkaTpDb25jZXB0b3M+PGNmZGk6SW1wdWVzdG9zIFRvdGFsSW1wdWVzdG9zUmV0ZW5pZG9zPSIwLjAwIiBUb3RhbEltcHVlc3Rvc1RyYXNsYWRhZG9zPSIwLjMyIj48Y2ZkaTpSZXRlbmNpb25lcz48Y2ZkaTpSZXRlbmNpb24gSW1wb3J0ZT0iMCIgSW1wdWVzdG89IjAwMiIvPjwvY2ZkaTpSZXRlbmNpb25lcz48Y2ZkaTpUcmFzbGFkb3M+PGNmZGk6VHJhc2xhZG8gSW1wb3J0ZT0iMC4zMiIgSW1wdWVzdG89IjAwMiIgVGFzYU9DdW90YT0iMC4xNjAwMDAiIFRpcG9GYWN0b3I9IlRhc2EiLz48L2NmZGk6VHJhc2xhZG9zPjwvY2ZkaTpJbXB1ZXN0b3M+PGNmZGk6Q29tcGxlbWVudG8+PHRmZDpUaW1icmVGaXNjYWxEaWdpdGFsIEZlY2hhVGltYnJhZG89IjIwMTctMDQtMDdUMTA6NTM6MzMiIFVVSUQ9IjYwMEM5OEMwLUJFNjAtNEM2Ny1CQTgwLUIyRjA5MjUxQzM3OCIgbm9DZXJ0aWZpY2Fkb1NBVD0iMjAwMDEwMDAwMDAzMDAwMjIzMjMiIHNlbGxvQ0ZEPSJoL3pVNHlZM0FjKzF4ZlZjUXcza1RUZVl2OVF5cW41R05wQmM5ZVVaVFVkS2RnTTIrTTNoN0w2MEcrbFhpVVVzWWlMNzB5cFpQdFpkc0t4clByd3JwbkNUUlBoYkxTVFYzYlNvYWZ2MENsTGMrUW1taHY4Z01rNG1Mb2tyZVFQOUxyaEhWcDNWeGhWRXoxU1pFSVo4MWliVmNiSTczL0gyby9UR3VvRU1ubjA9IiBzZWxsb1NBVD0iSWJON3ZGd1BsYjZuVTVzeDlmbFhab3p3OWpsSUFjc25WVmYrVkI2WUQ5QUhudnRVRmlIYzlRVVRaVFd5L1VxY0FWdlVmMWtsQzVzcXlPTEJCTmdCVHFNK1dDRTMvKytGMG9lUmd2cXB1NGY2ZCtMRlpidUhQWGdXNGJLenVVT1JuWk9vcWZDZ2xDRkJ6YS9OOThzckJGdjVGTnA5QXRBdHpuOGZVTXR3eXVpOHNYWEg3MTVNUGpaQVl2UHF5RGovWm42N3MraDluakpDWWFMN1g0bVJXZ1hBVDJwTWxkRDZCeXU0MzJDRjZkaGpUTDJwYkw3UVFGL0ZIZ3NoRWp0a2c2MTJjS0dWNHNFM1lXOE5JMEtlZW9INEdIQzlLSjQwOFVVSVVZNHFUT1BOcEpITDY3MkVWM0lKdTZOaGxvTFpjanQwNTBzUFNUQ2p2NUFURGN3UXF3PT0iIHZlcnNpb249IjEuMCIgeHNpOnNjaGVtYUxvY2F0aW9uPSJodHRwOi8vd3d3LnNhdC5nb2IubXgvVGltYnJlRmlzY2FsRGlnaXRhbCBodHRwOi8vd3d3LnNhdC5nb2IubXgvc2l0aW9faW50ZXJuZXQvdGltYnJlZmlzY2FsZGlnaXRhbC9UaW1icmVGaXNjYWxEaWdpdGFsLnhzZCIgeG1sbnM6dGZkPSJodHRwOi8vd3d3LnNhdC5nb2IubXgvVGltYnJlRmlzY2FsRGlnaXRhbCIvPjwvY2ZkaTpDb21wbGVtZW50bz48L2NmZGk6Q29tcHJvYmFudGU+</xmlBase64> </servicioTimbrado>]]></return> </ns2:timbradoResponse> </S:Body> </S:Envelope>

Métodos de Timbrado

Se utiliza para realizar el timbrado del XML especificado en el parámetro. El método realiza la autenticación al servicio, valida la estructura del XML y devuelve un XML sin esquemas, como respuesta a la petición de timbrado. La estructura del XML de respuesta se explica más adelante.

Nombre de los métodos de timbrado

• Timbrado real: timbrado
• Timbrado de prueba: timbradoPrueba

Parámetros del método de Timbrado

• contrato: indica el código de contrato del usuario con el que se realizará el timbrado.
• usuario: indica el usuario con el que se autenticará el servicio de timbrado.
• passwd: indica la contraseña del usuario con el que se autenticará al servicio de timbrado.
• cfdiXml: es el XML que se desea timbrar en texto plano.
• opciones: arreglo de strings que indica al servicio las opciones que se utilizarán en la petición de timbrado, así mismo se puede optar por enviar cada opción en un elemento del arreglo o todas las opciones codificadas en base64 en el primer elemento del arreglo "opciones", formadas en un string donde cada opción va separada por el caracter "pipe" ( | ) y codificada en base 64.
  
  Ejemplo: CALCULAR_SELLO|CONSULTAR_SALDO|GENERAR_PDF codificado en base64.
  
  

XML de respuesta del Servicio de Timbrado

No todos los atributos estarán presentes siempre en la respuesta. La descripción de los mismos se define a continuación.

• id. Identificador de la transacción interna, en formato UUID. Este valor es de uso interno, no está relacionado con ninguna propiedad del XML o del Timbre Fiscal Digital.
• timbradoOk. Indica si la operación de timbrado fue conducida exitosamente. Los valores posibles son “true”, que indica éxito; y “false”, que indica que el CFDI no pudo ser timbrado y en consecuencia no fue aceptado por el servicio.
• contrato. Identificador único del contrato del cliente. Se regresa para fines informativos.
• codigo. El código es un valor cuya función principal es indicar el error que fue detectado, en caso de haberlo. Cuando la transacción de timbrado fue exitosa (timbradoOk vale “true”) el código se regresa con un valor de 0 (cero) y de otra forma se regresa con el código de error específico definido por el SAT. Por otro lado, es posible que se acepte el certificado pero con incidencias, lo que causará que se regrese un código aún cuando el atributo timbradoOk tenga valor de “true”. El código siempre pertenecerá al último error registrado por el servicio(en caso de que se hayan registrado más de uno).
• mensaje. Este valor es un texto informativo. Es especialmente útil cuando ocurren errores en el procesamiento del CFDI. Cuando la transacción de timbrado fue exitosa, éste valor viene vacío. Es probable que la respuesta del servicio incluya más de un mensaje de error, éstos serán separados por un carácter pipe (|).
• versión. Versión del Timbre Fiscal generado. A la fecha, el valor es 1.1. Este valor forma parte del elemento <tfd:TimbreFiscalDigital> dentro del CFDI. Este valor se incluye solamente cuando la transacción de timbrado es exitosa.
• uuid. Folio fiscal asignado al CFDI. Este valor forma parte del elemento <tfd:TimbreFiscalDigital> dentro del CFDI. Este valor se incluye solamente cuando la transacción de timbrado es exitosa.
• FechaTimbrado. Fecha de generación del Timbre Fiscal Digital. Este valor forma parte del elemento <tfd:TimbreFiscalDigital> dentro del CFDI. Este valor se incluye solamente cuando la transacción de timbrado es exitosa.
• selloCFD. Sello del CFDI. Este valor forma parte del elemento <tfd:TimbreFiscalDigital> dentro del CFDI. Este valor se incluye solamente cuando la transacción de timbrado es exitosa.
• noCertificadoSAT. Número de certificado del SAT. Este valor forma parte del elemento <tfd:TimbreFiscalDigital> dentro del CFDI. Este valor se incluye solamente cuando la transacción de timbrado es exitosa.
• selloSAT. Sello del timbre fiscal digital. Este valor forma parte del elemento <tfd:TimbreFiscalDigital> dentro del CFDI. Este valor se incluye solamente cuando la transacción de timbrado es exitosa.
• xmlBase64. String codificado en Base 64 que contiene el documento XML timbrado. Este valor se incluye solamente cuando la transacción de timbrado es exitosa.
• pdfBase64. String codificado en Base 64 que contiene el arreglo de bytes del PDF del documento XML timbrado. Este valor se incluye solamente cuando la transacción de timbrado es exitosa y se utiliza la opción GENERAR_PDF.
• saldo. El valor de este nodo es el número de transacciones disponibles para el contrato con el que se realizó la petición de timbrado. Este valor se incluye solamente cuando la transacción es exitosa y se utiliza la opción CONSULTAR_SALDO.

Opciones del servicio

Las opciones permiten ejecutar acciones adicionales al timbrado que pudieran ayudar en la operación del integrador.

La descripción de cada opción se puede consultar en la tabla 1 “Opciones para los diferentes servicios” al final del documento. Para el timbrado tenemos las siguientes:

• CALCULAR_SELLO
• CONSULTAR_SALDO
• ENVIAR_AMBOS:
• ADDENDA:LIBRE:
• OBSERVACIONES:
• REGRESAR_CADENA_ORIGINAL
• GENERAR_PDF
• VERIFICAR_SERIE_FOLIO
• RESPUESTA_JSON
• ESTABLECER_CERTIFICADO
• ESTABLECER_NO_CERTIFICADO
• CORREGIR_NAMESPACES
  
• REGRESAR_RFCPROVCERTIF
  

---

Método enviarXmlAndPdfPorCorreo

Se encarga de enviar el XML y el PDF de un comprobante timbrado a través de Prodigia, dicho método es solo para el envió de un par de archivos de un UUID, este UUID debe de estar guardado en base de datos. 

El método recibe los siguientes parámetros:

• contrato. 

• usuario. 

• password.

• uuid

• destinatarios.  El parámetro destinatarios permite hasta la captura de 3 correos electrónicos separados por el carácter coma ","

Ejemplo petición REST: 

 

Los parametros de usuario y password se colocan en la cabecera.

"usuario":" ", "password":" ",

 

Petición

{

"contrato":" ", "uuid": " ",

"destinatarios":"correo1@dominio.com, correo2@dominio.com "
}

Respuesta

{
"envioOk": true,
"codigo": "0",
"mensaje": "El correo se envió satisfactoriamente"
}

 

Ejemplo petición SOAP: 

 

<soapenv:Envelope   xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/"   xmlns:tim = "timbrado.ws.pade.mx" >

    <soapenv:Header/>

    <soapenv:Body>

       <tim:enviarXmlAndPdfPorCorreo>

          <contrato> 9f686960-169e-11e2-ae20-109add4fad20 </contrato>

          <usuario> unixlibre </usuario>

          <passwd> A1234567890$ </passwd>

          <uuid> FC6ADEB7-3851-4F8C-86F4-C5AEDC3AE5DA </uuid>

          <destinatarios> correo@ejemplo.com </destinatarios>

       </tim:enviarXmlAndPdfPorCorreo>

    </soapenv:Body>

</soapenv:Envelope>

Generar valor para atributo Confirmación

¿Qué es el atributo Confirmación?

Es un atributo nuevo condicional que se utiliza para expresar la clave de confirmación expedida por el PAC en situaciones donde el CFDI supera ciertos límites establecidos en el Anexo 20 publicado por el SAT.

¿Cuándo lo necesito?

Actualmente existen dos situaciones en las que es necesario incluir este atributo en el CFDI:

• Atributo TipoCambio.- cuando el valor está fuera del porcentaje aplicable a la moneda tomado del catálogo c_Moneda. El emisor debe obtener del PAC que vaya a timbrar el CFDI, de manera no automática, una clave de confirmación para ratificar que el valor es correcto e integrar dicha clave en el atributo Confirmación.
• Atributo Total.- cuando el valor es superior al límite que establezca el SAT en la Resolución Miscelánea Fiscal vigente, el emisor debe obtener del PAC que vaya a timbrar el CFDI, de manera no automática, una clave de confirmación para ratificar que el valor es correcto e integrar dicha clave en el atributo Confirmación.

¿Cómo genero este valor con Prodigia?

Antes de realizar el timbrado del CFDI, se debe ingresar a la plataforma Pade Confirmación con el certificado, llave privada y contraseña del emisor para verificar la identidad.
Una vez que se especifiquen los datos anteriores, se validará la información y en caso de ser válida, se mostrará en pantalla la clave de confirmación asignada.

La dirección URL para la plataforma Pade Confirmación es la siguiente: https://facturacion.pade.mx/PadeConfirmacion/

---

Cancelación de comprobantes (Nuevo esquema)

Te recomendamos consultar la  presentación del nuevo esquema de cancelación  que el SAT  publicó  junto con otros documentos de ayuda.

Métodos para cancelación de CFDI vía SOAP

Operación de Cancelación

Este método crea la solicitud de cancelación de uno o varios CFDI. Debido a los cambios hechos por el SAT, a partir del 1 de noviembre del 2018 será necesario que el receptor responda la solicitud de cancelación (en algunos casos), por lo que te recomendamos utilizar el método consultarEstatusComprobante(descrito más abajo) después de crear la solicitud de cancelación para confirmar el estatus del comprobante. Los argumentos que acepta el método son:

• contrato. Identificador único del contrato de servicios.
• usuario. Nombre del usuario del servicio. Éste usuario debe estar autorizado para utilizar la API de integración.
• passwd. Contraseña del usuario del servicio.
• rfcEmisor. RFC del emisor al que pertenecen los CFDI que se desea cancelar.
• arregloUUID: Arreglo de Strings con el UUID, RFC Receptor, RFC Emisor y Total del Comprobante que se esta cancelando. A partir del 01 de enero del 2022  será requerido el motivo de cancelación  y opcionalmente el folio fiscal que sustituye el UUID que se está cancelando.
  Esta información separada por el carácter pipe (|):
  • UUID para cancelar.
  • RFC Receptor del comprobante.
  • RFC Emisor del comprobante.
  • Total del comprobante.
  • Motivo de cancelación (más adelante se explican los valores que pueden contenerse).
  • Folio fiscal que sustituye el documento a cancelar.

            Ejemplo:  <arregloUUID>UUID|RFC_Receptor|RFC_Emisor|Total|Motivo|FolioFiscalSustituye</arregloUUID>

• cert: Arreglo de bytes con el archivo del certificado de sello digital con que fueron generados los CFDI que se cancelarán. Se debe enviar el archivo binario tal como se obtuvo del SAT (formato CER).
• key: Arreglo de bytes Llave privada correspondiente al certificado.
• keyPass: Contraseña de la llave privada que se está enviando.

El servicio de cancelación regresa un archivo XML sin esquemas, estructurado de la siguiente manera:

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación y de las cancelaciones. La descripción de los atributos se describe a continuación:

• statusOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa. Es importante observar que el valor de este atributo no refleja el valor de cada cancelación individual. Por ejemplo podemos obtener “true” aquí pero error en cada cancelación individual. Obtendremos un valor de false en este atributo en caso de un error mayor, por ejemplo que el contrato de servicios esté expirado, o el usuario tenga una contraseña incorrecta.
• rfc. RFC del emisor de los CFDI. Se proporciona para fines informativos.
• código. Código global de la invocación. Un valor de 0 (cero) indica que la invocación se dio exitosamente, o de otra forma se indica la razón del problema.
• mensaje. Mensaje descriptivo del error en caso que el valor de código sea diferente de cero.
• cancelaciones. Nodo que contiene la lista con los resultados de las operaciones individuales sobre cada UUID.
  • cancelación. Nodo que contiene el resultado de una cancelación individual.
    • uuid. UUID que fue procesado.
    • código. Código generado por el SAT con el resultado de la cancelación. La lista de códigos individuales se muestra al final del documento en la tabla 2 “Códigos de respuesta para los diferentes servicios”.
    • mensaje. Mensaje opcional adicional con la descripción del problema (en caso de haberlo).
• acuseCancelBase64. Acuse de cancelación proporcionado por el SAT, codificado en base 64.

Operación de Cancelación con Opciones

Este método es similar a la operación de cancelación básica. La diferencia es el argumento “opciones”, que es un arreglo de Strings con indicaciones adicionales para el servicio de cancelación. Las opciones reconocidas son:

• PKCS12
• XML_CANCELACION
• CERT_DEFAULT
• CONSULTAR_SALDO

El significado de las opciones se puede consultar en la tabla “Opciones para los diferentes servicios” al final del documento.

La respuesta de la operación es un String XML similar a la respuesta de la operación de cancelación básica.

Ejemplo de las respuestas de prueba en el servicio de cancelación (Ver Tabla 1: Opciones para los diferentes servicios, MODO_PRUEBA:X)

MODO_PRUEBA:1 – No Cancelable

MODO_PRUEBA:2 – En proceso

MODO_PRUEBA:3 – Cancelado sin aceptación

MODO_PRUEBA:4 – Previamente cancelado

MODO_PRUEBA:5 – Rfc no corresponde

MODO_PRUEBA:6 – Uuid no existe

Operación de consulta de peticiones pendientes para aprobar/rechazar cancelaciones

Este método permite consultar las peticiones pendientes de cancelación que un contribuyente tiene como Receptor de comprobantes. Los argumentos que acepta el método son:

• contrato. Identificador único del contrato de servicios.
• usuario. Nombre del usuario del servicio. Éste usuario debe estar autorizado para utilizar la API de integración.
• passwd. Contraseña del usuario del servicio.
• rfcReceptor. RFC del Receptor de los CFDI que se desea consultar.

El servicio de consulta de peticiones pendientes regresa un archivo XML sin esquemas, estructurado de la siguiente manera:

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación y de las cancelaciones. La descripción de los atributos se describe a continuación:

• consultaOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa. Es importante observar que el valor de este atributo no refleja el valor de cada cancelación individual. Por ejemplo podemos obtener “true” aquí pero error en cada cancelación individual. Obtendremos un valor de false en este atributo en caso de un error mayor, por ejemplo que el contrato de servicios esté expirado, o el usuario tenga una contraseña incorrecta.
• codigo. Código global de la invocación. Un valor de 0 (cero) indica que la invocación se dio exitosamente, o de otra forma se indica la razón del problema.
• codigoEstatus. Descripción del código obtenido en la respuesta.
• uuids. Nodo que contiene la lista con los uuids del resultado de la consulta.
  • uuid. UUID encontrado con petición pendiente.

Operación de aprobar/rechazar peticiones pendientes de cancelación

Este método permite responder las peticiones de cancelación realizadas por otros contribuyentes. Los argumentos que acepta el método son:

• contrato. Identificador único del contrato de servicios.
• usuario. Nombre del usuario del servicio. Éste usuario debe estar autorizado para utilizar la API de integración.
• passwd. Contraseña del usuario del servicio.
• rfcReceptor. RFC del Receptor de los CFDI.
• arregloUUID. Arreglo de strings donde cada uno estará formado por el UUID y la respuesta a la petición (‘Aceptación’ o ‘Rechazo’) separados por el carácter pipe. Ejemplo:
  • UUID|Aceptacion
  • UUID|Rechazo
• cert: Arreglo de bytes con el archivo del certificado de sello digital. Se debe enviar el archivo binario tal como se obtuvo del SAT (formato CER).
• key: Arreglo de bytes Llave privada correspondiente al certificado.
• keyPass: Contraseña de la llave privada que se está enviando.
• opciones: arreglo de strings que indica al servicio las opciones que se utilizarán en la petición de cancelación

El servicio de consulta de peticiones pendientes regresa un archivo XML sin esquemas, estructurado de la siguiente manera:

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación y de las cancelaciones. La descripción de los atributos se describe a continuación:

• procesoOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa. Es importante observar que el valor de este atributo no refleja el valor de cada cancelación individual. Por ejemplo podemos obtener “true” aquí pero error en cada cancelación individual. Obtendremos un valor de false en este atributo en caso de un error mayor, por ejemplo que el contrato de servicios esté expirado, o el usuario tenga una contraseña incorrecta.
• codigo. Código global de la invocación. Un valor de 0 (cero) indica que la invocación se dio exitosamente, o de otra forma se indica la razón del problema.
• codigoEstatus. Descripción del código obtenido en la respuesta.
• rfcReceptor. RFC del receptor de los UUIDs que se está respondiendo en la solicitud.
• rfcPac. RFC del PAC que realizó la cancelación.
• fecha. Fecha en la que se realizó la aceptación/rechazo de la petición.
• mensaje. Mensaje.
• Folios. Nodo que contiene un UUID y su respectivo Estatus ante el SAT. Este nodo tiene como atributo “Respuesta” que indica la respuesta que se le dio al SAT. Este nodo aparecerá por cada UUID enviado en la solicitud.
  • uuid. UUID de la solicitud.
  • EstatusUUID. Estatus del UUID en el SAT.

Operación de consulta de documentos relacionados

Este método permite consultar los documentos relacionados que tenga un documento. Los argumentos que acepta el método son:

• contrato. Identificador único del contrato de servicios.
• usuario. Nombre del usuario del servicio. Éste usuario debe estar autorizado para utilizar la API de integración.
• passwd. Contraseña del usuario del servicio.
• rfcReceptor. RFC del Receptor del CFDI.
• uuid. Folio Fiscal del comprobante que se quieren consultar sus documentos relacionados.
• cert: Arreglo de bytes con el archivo del certificado de sello digital. Se debe enviar el archivo binario tal como se obtuvo del SAT (formato CER).
• key: Arreglo de bytes Llave privada correspondiente al certificado.
• keyPass: Contraseña de la llave privada que se está enviando.
• opciones: arreglo de strings que indica al servicio las opciones que se utilizarán en la petición de consulta

Los datos de acceso al servicio como lo son: contrato, usuario y password, deben ser los proporcionados por el receptor, así mismo el certificado, key y keypas,ya que la petición que se origina irá firmada por el receptor.

El servicio de consulta de documentos relacionados regresa un archivo XML sin esquemas, estructurado de la siguiente manera:

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación y de las cancelaciones. La descripción de los atributos se describe a continuación:

• consultaOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa.
• UuidConsultado. UUID del que fue consultados sus documentos relacionados.
• codigo. Código de respuesta del servicio del SAT.
• mensaje. Mensaje del servicio del SAT en caso de ocurrir un error.
• resultado. Resultado de la consulta realizada. Es un mensaje armado por el servicio del SAT.
• UuidsRelacionadosPadre. Este nodo contiene la información de el(los) uuid(s) que el documento consultado tiene como padre.
  •  UuidPadre. Contiene la información de uno de los UUID padre.
    • Uuid. Es el UUID Padre del documento.
    • RfcEmisor. Es el RFC del emisor del documento padre.
    • RfcReceptor. Es el RFC del receptor del documento padre.
• UuidsRelacionadosHijos. Este nodo contiene la información de el(los) uuid(s) que el documento consultado tiene como hijo.
  • UuidRelacionado. Contiene la información de uno de los UUID relacionado como hijo.
    • Uuid. Es el UUID hijo.
    • RfcEmisor. Es el RFC del emisor del documento hijo.
    • RfcReceptor. Es el RFC del receptor del documento hijo.

Operación de consulta estatus de comprobante

Este método permite consultar el estatus de un comprobante ante el SAT. Los argumentos que acepta el método son:

• contrato. Identificador único del contrato de servicios.
• usuario. Nombre del usuario del servicio. Éste usuario debe estar autorizado para utilizar la API de integración.
• passwd. Contraseña del usuario del servicio.
• uuid. Folio Fiscal del comprobante que se quiere consultar su estatus.
• rfcEmisor: RFC del Emisor del CFDI.
• rfcReceptor. RFC del Receptor del CFDI.
• total. Total del comprobante que se quiere consultar.
• opciones. Arreglo de strings que indica al servicio las opciones que se utilizarán en la petición de consulta.

El servicio de consulta estatus de comprobante regresa un archivo XML sin esquemas, estructurado de la siguiente manera:

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación y de las cancelaciones. La descripción de los atributos se describe a continuación:

• consultaOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa.
• codigo. Código de respuesta del servicio del SAT.
• codigoEstatus. Descripción del código de respuesta del servicio del SAT.
• esCancelable. Indica de qué manera se puede cancelar el comprobante.
• estado. Estatus actual del comprobante.
• estatusCancelacion. Indica de que manera se canceló el comprobante. Sólo se devolverá cuando el comprobante se encuentre cancelado.
• codigoEstatusCancelacion. Código representativo a la leyenda del nodo estatusCancelacion. Únicamente cuando el nodo esCancelable = ‘No Cancelable’ se tomará el valor del codigo correspondiente a este nodo
• estatusCfdi. Este código indica el estatus del CFDI ante el SAT. En la Tabla 4 se encuentra la descripción de cada posible código.

Modo de prueba en cancelación

En los métodos relacionados con la cancelación existe una opción que simula una respuesta del servicio para apoyar a los programadores con las pruebas e integración. Dependiendo del método y el escenario será la respuesta que se obtenga del servicio.

Para hacer uso de la opción debe enviarse en la petición la opción: “MODO_PRUEBA:X” donde X se refiere al escenario que se quiere simular en el método.

Ejemplo:

Si estamos consumiendo el método “consultarEstatusComprobante” y enviamos la opción “MODO_PRUEBA:1” estaremos recibiendo una respuesta donde nos indica que el comprobante consultado se encuentra vigente y puede ser cancelado sin aceptación por parte del receptor.

Los escenarios disponibles en el servicio son los siguientes:

Consultar Estatus del Comprobante
1.- Consulta Exitosa – Cancelable sin aceptación – Vigente: El proceso de consulta fue exitoso y se encontró que el comprobante está vigente y puede ser cancelado sin aceptación por parte del receptor.
2.- Consulta Exitosa – Cancelable sin aceptación – Cancelado: El proceso de consulta fue exitoso y se encontró que el comprobante está cancelado y fue cancelado sin aceptación por parte del receptor.
3.- Consulta Exitosa – Cancelable con aceptación – Vigente: El proceso de consulta fue exitoso y se encontró que el comprobante está vigente y puede ser cancelado con aceptación por parte del receptor.
4.- Consulta Exitosa – Cancelable con aceptación – Cancelado: El proceso de consulta fue exitoso y se encontró que el comprobante está cancelado y fue cancelado con aceptación por parte del receptor.
5.- Consulta Exitosa – Cancelable con aceptación – Cancelado – Plazo Vencido: El proceso de consulta fue exitoso y se encontró que el comprobante está cancelado y fue cancelado por plazo vencido.
6.- Consulta Exitosa – Comprobante no encontrado: El proceso de consulta fue exitoso pero no se encontró el comprobante consultado.

Consultar Peticiones Pendientes
1.- Consulta Exitosa – 2 Coincidencias: El proceso de consulta fue exitoso y se encontraron dos peticiones para el RFC receptor especificado.
2.- Consulta Exitosa – 1 Coincidencia: El proceso de consulta fue exitoso y se encontró una peticion para el RFC receptor especificado.
3.- Consulta Exitosa – 0 Coincidencias: El proceso de consulta fue exitoso y no se encontraron peticiones para el RFC receptor especificado.

Responder Solicitud
1.- Respuesta Exitosa – La aprobación y/o rechazo de los comprobantes se realizó con éxito

Consultar Cfdis Relacionados
1.- Consulta Exitosa – Padre e Hijos relacionados: El proceso de consulta fue exitoso y se encontraron CFDIs relacionados como padre y como hijo.
2.- Consulta Exitosa – Hijos relacionados: El proceso de consulta fue exitoso y se encontraron CFDIs relacionados como hijo.
3.- Consulta Exitosa – Padres relacionados: El proceso de consulta fue exitoso y se encontraron CFDIs relacionados como padre.
4.- Consulta Exitosa – No hay CFDIs relacionados (PENDIENTE)

Método para cancelación de CFDI vía REST

El servicio REST dispone de un único método de cancelación en el cual se pueden o no incluir las opciones descritas en el servicio SOAP, el cual puede ser invocado desde la URL:

https://timbrado.pade.mx/servicio/rest/cancelacion/cancelar

Y cuyos parámetros (URL Query Parameters) se describen a continuación:

• contrato: Clave del contrato de servicios.
• rfcEmisor: RFC del emisor de los CFDI’s a cancelar.
• certBase64: Certificado con el cual fueron emitidos los CFDI’s a cancelar en formato Base64
• keyBase64: Llave privada con el cual fueron emitidos los CFDI’s a cancelar en formato Base64
• keyPass: Contraseña de la llave privada.
• arregloUUID: Arreglo de Strings con el UUID, RFC Receptor, RFC Emisor y Total del Comprobante que se esta cancelando. A partir del 01 de enero del 2022  será requerido el motivo de cancelación y opcionalmente el folio fiscal que sustituye el UUID que se está cancelando.
  Esta información separada por el carácter pipe (|):
  • UUID para cancelar.
  • RFC Receptor del comprobante.
  • RFC Emisor del comprobante.
  • Total del comprobante.
  • Motivo de cancelación (más adelante se explican los valores que pueden contenerse).
  • Folio fiscal que sustituye el documento a cancelar.
    
    

Ejemplo:  <arregloUUID>UUID|RFC_ Receptor|RFC_Emisor|Total|Motivo|FolioFiscalSustituye</ arregloUUID>


• opciones: Opciones adicionales a la cancelación (descritas en el servicio SOAP) , este parámetro se puede repetir cuantas opciones desea especificar.

Al igual que el servicio de timbrado vía REST, es necesario además adjuntar al HEAD de la peticion el usuario/contraseña del asociado en el formato usuario:contraseña codificados en Base64.

Ejemplo de petición REST con el cliente Advanced Rest Client

Método para consulta de estatus de CFDI vía REST

El servicio REST dispone de un método para consultar el estatus de un comprobante en el cual se pueden o no incluir las opciones descritas en el servicio SOAP, el cual puede ser invocado desde la URL:

https://timbrado.pade.mx/servicio/rest/cancelacion/consultarEstatusComprobante 

Y cuyos parámetros (URL Query Parameters) se describen a continuación:

• contrato: Clave del contrato de servicios.
• uuid: Folio fiscal del comprobante que se quiere consultar el estatus
• rfcEmisor: RFC del emisor del CFDI que se quiere consultar.
• rfcReceptor: RFC del receptor del CFDI que se quiere consultar.
• total: Es el valor que tiene el atributo Total del CFDI que se quiere consultar
• opciones: Opciones adicionales a la cancelación (descritas en el servicio SOAP) , este parámetro se puede repetir cuantas opciones desea especificar.

Al igual que el servicio de timbrado vía REST, es necesario además adjuntar al HEAD de la petición el usuario/contraseña del asociado en el formato usuario:contraseña codificados en Base64.

Ejemplo de petición REST con el cliente Advanced Rest Client

Catálogo de Motivos de Cancelación

• 01 - Comprobante emitido con errores con relación.

• 02 - Comprobante emitido con errores sin relación.

• 03 - No se llevó a cabo la operación. 

• 04 - Operación nominativa relacionada en la factura global. 

En caso de tener dudas y preguntas con relación al tema de cancelación, favor de consultar la siguiente url 

descargar: Preguntas frecuentes cancelación

Operación para Consulta de un CFDI

Método de consulta de CFDI por UUID vía SOAP

El método obtiene un CFDI previamente timbrado. Los argumentos que acepta el método son:

• Contrato. Identificador único del contrato de servicios.
• Usuario. Nombre del usuario del servicio. Éste usuario debe estar autorizado para utilizar la API de integración.
• Passwd. Contraseña del usuario del servicio.
• Uuid. UUID del CFDI que se desea consultar.

La respuesta es un string XML sin esquemas con la siguiente estructura:

No todos los atributos están presentes en la respuesta, dependerá del resultado de la operación. Esta respuesta se utiliza en todos los métodos de consulta. Los atributos se describen a continuación:

• consultaOk. Toma valores de “true” o “false”, dependiendo del resultado de éxito o error en la consulta.
• contrato. ID del contrato del cliente. Se proporciona para fines informativos.
• código. Código del error, en caso de haberlo. Si el UUID proporcionado no está asociado a un CFDI (no existe), se regresa un código 602 (CFDI no existe).
• mensaje. Mensaje descriptivo del error, en caso de haberlo.
• xmlBase64. String con el XML del CFDI recuperado por la búsqueda, codificado en base64.

Método de consulta de CFDI por UUID vía REST

La petición de consulta en REST se realiza desde la siguiente URL:

Normalización y Certificación Electrónica, S.C. (NYCE), organismo acreditado con el No. 129/17, por la Entidad Mexicana de Acreditación (EMA), certifica que el Sistema de vhz Gestión de Seguridad de la Información de:

Éste método recibe los siguientes parámetros (todos son requeridos) y debe ser una petición GET.

• contrato: Clave del contrato de servicio.
• uuid: UUID del comprobante a consultar.

Al igual que los métodos de timbrado y cancelación deberá adjuntar el usuario y contraseña en el formato usuario:contraseña codificado en Base64 en el HEAD de la petición.

Tabla 1: Opciones para los diferentes servicios.

La siguiente tabla describe las opciones que pueden ser proporcionadas. Los nombres de las opciones son sensibles a mayúsculas y minúsculas, y se deben proporcionar como se indican.

Opción	Aplica en	Descripción
CALCULAR_SELLO	Timbrado	Le indica al servicio que antes de generar el timbre fiscal digital se debe calcular el sello del CFDI. Para que el servicio pueda calcular el sello del CFDI el cliente deberá contar con su certificado de sello digital guardados en la plataforma de Pade. Esta opción tiene las siguientes implicaciones: Puede ser que esta opción no esté disponible para su contrato, dependerá de los servicios que haya solicitado (puede consultarlo con el personal de ventas) y en su caso se se generará un mensaje de error. El atributo “sello” del archivo XML que se envía debe venir vacio. Dentro de esta opción existe la opción de calcular sello con csd en especifico  Al enviar el atributo NoCertificado con un valor distinto al default y vigente, calcula el sello con este valor, en caso contrario regresa el mensaje “Su certificado predeterminado ha caducado, puede actualizarlo desde el portal PADE” , de igual forma si se envía un certificado no existente en Pade se obtiene el mensaje “No se cuenta con un certificado de sello digital previamente guardado con numero 0000…”
ADDENDA:LIBRE:	Timbrado	Esta opción le indica al servicio el texto XML con la addenda en base 64 que deberá ser anexada al CFDI después del procedimiento de timbrado en texto plano. El formato para especificar la addenda libre es: ADDENDA:LIBRE:texto_addenda En donde la cadena “texto_addenda” corresponde al String XML codificado en base 64 que será anexado al CFDI. Esta opción tiene las siguientes implicaciones: La validez del contenido y la estructura de la addenda es responsabilidad del usuario de timbrado. El texto especificado dentro de la opción ADDENDA:LIBRE: será anexado en el XML timbrado en texto plano dentro del nodo:
CERT_DEFAULT	Cancelación	Se utiliza en la cancelación, y le indica a la plataforma que obtenga el certificado por default del usuario para realizar las cancelaciones. La presencia de esta opción causa que sean ignorados la llave publica, llave privada y password de la llave privada proporcionados como argumentos del método.
CONSULTAR_SALDO	Timbrado y Cancelación	Le indica al servicio que devuelva el valor de las transacciones disponibles después del timbrado efectuado.
PKCS12:	Cancelación	Se utiliza en la cancelación y sirve para especificar el certificado de sello digital del emisor y su llave privada empaquetados en un archivo con formato PKCS12.El formato para especificar el archivo PKCS12 es: PKCS12:archivo_base64 En donde la cadena “archivo_base64” corresponde al archivo codificado en base 64. Esta opción tiene las siguientes implicaciones: Se ignora el valor de los parámetros cert y pkey que contienen el CSD y la llave privada (individuales), respectivamente. Se debe especificar el parámetro keyPass. Esta contraseña es la que se emplea para leer el archivo PKCS12 y debe corresponder a la contraseña de la llave privada del emisor. El CSD y la llave privada deben estar alojados en el archivo con un alias, que corresponde al RFC del emisor en letras mayúsculas.
XML_CANCELACION	Cancelación	Esta opción permite recibir el XML de cancelación y, sin modificarlo, realizar la cancelación en el SAT de los UUID’s contenidos en el XML. Es útil cuando el cliente quiere omitir el envío del certificado, llave privada y contraseña a través de éste servicio o evitar el guardarlo en la plataforma de facturación.El formato para especificar el XML de cancelación es: XML_CANCELACION:xml_base64 En donde la cadena “xml_base64” corresponde al XML de cancelación codificado en base 64. Esta opción tiene las siguientes implicaciones: Se debe omitir el envío de los parámetros cert, pkey, keyPass y la opción CERT_DEFAULT. Sólo se puede enviar 1 XML de cancelación por petición. Los parámetros rfc y uuid aún deben enviarse.
ENVIAR_AMBOS:	Timbrado	Esta opción permite enviar por correo electrónico los archivos PDF y XML del comprobante que se timbra. Si la transacción fue exitosa, envía el XML y el PDF timbrados a la dirección de email especificada en la opción. Para realizar el envió a 1 hasta 5 direcciones, cada dato debe de estar separado por un ";" (punto y coma). El formato para utilizar la opción es el siguiente: ENVIAR_AMBOS:correo@dominio.com
GENERAR_PDF	Timbrado	Esta opción permite obtener el PDF del comprobante timbrado. El servicio regresa un String codificado en Base 64 que contiene el arreglo de bytes del PDF del documento XML timbrado.
GENERAR_CBB	Timbrado	Permite generar el QR del CFDI. El servicio regresa un String codificado en Base 64 que contiene el arreglo de bytes del archivo png que incluye el QR del XML timbrado..
OBSERVACIONES:	Timbrado	Esta opción permite agregar texto al campo Observaciones del PDF del comprobante; no tiene ninguna afectación sobre el XML. Para ello se envía la opción OBSERVACIONES:, seguido de las observaciones en formato base 64. Ejemplo: OBSERVACIONES:RmFjdHVyYSBwYWdhZGEu.
REGRESAR_CADENA_ORIGINAL	Timbrado	Esta opción permite obtener la cadena original del timbre fiscal del comprobante. La cadena original se regresa dentro de los nodos de cadenaOriginalTFD.
MODO_PRUEBA:	Cancelación	Esta opción permite simular una respuesta de prueba en el servicio de cancelación dependiendo de la opción enviada. Los modos de prueba reconocidos por el servicio son los siguientes: MODO_PRUEBA:1 – Simula la respuesta para un comprobante No Cancelable MODO_PRUEBA:2 – Simula la respuesta para un comprobante que está En proceso, en espera de respuesta por parte del receptor. MODO_PRUEBA:3 – Simula la respuesta para un comprobante que se canceló sin aceptación por parte del receptor MODO_PRUEBA:4 – Simula la respuesta para un comprobante previamente cancelado MODO_PRUEBA:5 – Simula la respuesta para un comprobante donde el rfc no corresponde con el enviado al servicio MODO_PRUEBA:6 – Simula la respuesta para un comprobante donde el uuid especificado no existe
VERIFICAR_SERIE_FOLIO	Timbrado	Le indica al servicio que si el XML que se envía contiene los mismos atributos SERIE y FOLIO de un comprobante ya timbrado, el servicio regresa la información del comprobante previamente timbrado (con Código 307).
RESPUESTA_JSON	Timbrado	Le indica al servicio de timbrado que devuelva la respuesta del servicio en formato Json en lugar de XML.
ESTABLECER_CERTIFICADO	Timbrado por CSV (a través de la api integración)	Le indica al servicio el numero de certificado en el CSV, esta opción toma el certificado en base64 anteriormente guardado y lo incluye en el request.
ESTABLECER_NO_CERTIFICADO	Timbrado	Coloca el certificado y el NoCertificado que tiene guardado como default en base de datos, en caso de que el request lleve alguno de los datos, estos los reemplaza por el que se encuentra como default en base de datos
CORREGIR_NAMESPACES	Timbrado	Le indica al servicio que revise si los namespaces se encuentran correctamente colocados en el elemento cfdi:Comprobante en caso de que estos namespaces se encuentren en otro lugar se encarga de colocarlos correctamente en el elemento cfdi:Comprobante.
REGRESAR_RFCPROVCERTIF	Timbrado	Agrega el valor del atributo TimbreFiscalDigital.RfcProvCertif a la respuesta del servicio de timbrado. Esta opción funciona tanto para Soap y Rest.

Tabla 2: Códigos de respuesta para los diferentes servicios.

Código	Descripción
0	Timbrado exitoso.
1	El usuario del webservice no existe o proporcionó una contraseña incorrecta.
2	Contrato inválido. El contrato está expirado, o no cuenta con servicio de timbrado.
3	Parámetro inválido. Uno de los parámetros de la operación del webservice es incorrecto o hace falta.
5	Off-line por mantenimiento.
7	El servicio de CancelaciónSAT no está disponible, intente más tarde.
20	El usuario no cuenta con un certificado default.
21	CFDI sin cancelar. Aplica a la consulta de acuse de cancelación.
201	Solicitud de cancelación recibida.
202	El comprobante ya ha sido previamente cancelado.
203	El RFC del emisor no corresponde.
204	Folio Fiscal No Aplicable a Cancelación.
205	Folio Fiscal No Existente.
206	UUID no corresponde a un CFDI del Sector Primario.
207	No se especificó el motivo de cancelación o el motivo no es válido.
208	Folio Sustitución invalido.
209	Folio Sustitución no requerido.
210	La fecha de solicitud de cancelación es mayor a la fecha de declaración.
211	La fecha de solicitud de cancelación limite para factura global.
212	Relación no válida o inexistente.
300	Usuario No Valido.
301	XML mal formado.
302	Sello mal formado.
304	Certificado revocado o caduco.
305	Certificado Inválido.
307	El comprobante ya existe en la base de datos.
309	Certificado Inválido.
310	Motivo no válido.
311	Folio sustitución no válido.
312	Folio sustitución no requerido.
313	Solicitud fuera de la declaración anual.
314	Relación no válida.
402	El contribuyente no se encuentra en la LCO o la validez de obligaciones se reporta como negativa.

Tabla 3: Códigos para los nuevos estatus de cancelación.

Código	Descripción
90	N – 602: Comprobante no encontrado. Este código tiene lugar cuando un comprobante no ha sido encontrado en la base de datos del SAT.
91	S – Comprobante obtenido satisfactoriamente. Este código tiene lugar cuando el comprobante consultado se encuentra en la base de datos del SAT.
92	N – 601: La expresión impresa proporcionada no es válida. Este código tiene lugar cuando alguno de los parámetros enviados para la consulta del estatus del comprobante es erróneo.
93	Indeterminado. Este código tiene lugar cuando el SAT actualizó algún elemento en la respuesta del servicio de consulta de comprobantes y dicho elemento no es reconocido por Prodigia.
94	No Cancelable. Este código comúnmente aparecerá cuando el comprobante que se desea cancelar contenga al menos un cfdi relacionado vigente.
95	Cancelado con aceptación. Este código aparecerá una vez que el cfdi está cancelado y requirió de autorización por parte del receptor para ser cancelado.
96	En proceso. Este código aparecerá cuando se intenta enviar una nueva solicitud de cancelación de un comprobante que previamente intentó ser cancelado y dicha solicitud requiere de aceptación por parte del receptor.
97	Solicitud rechazada. Este código aparecerá cuando el receptor rechaza la cancelación de algún comprobante, para este caso el cfdi queda con estado vigente.
98	Plazo vencido. Este código aparecerá cuando exista una solicitud de cancelación que requiera de aceptación por parte del receptor, y tras pasar las 72 horas, no se obtuvo respuesta alguna. En este caso el cfdi se cancela dando por hecho que la cancelación fue aceptada.
99	Límite máximo alcanzado. Pendiente por definir
201	Cancelado sin aceptación. Este  código aparecerá cuando el cfdi se canceló sin necesidad de que el receptor autorice, básicamente funciona de manera unilateral.
202	Folio Fiscal Previamente Cancelado.
203	Folio Fiscal No Correspondiente al Emisor.
204	Folio Fiscal No Aplicable a Cancelación.
205	Folio Fiscal No Existente.
206	UUID no corresponde a un CFDI del Sector Primario.
207	No se especificó el motivo de cancelación o el motivo no es valido.
208	Folio Sustitución invalido.
209	Folio Sustitución no requerido.
210	La fecha de solicitud de cancelación es mayor a la fecha de declaración.
211	La fecha de solicitud de cancelación límite para factura global.
212	Relación no valida o inexistente.
300	Usuario No Válido.
301	XML Mal Formado. El  certificado puede ser inválido por múltiples razones como son el tipo, la vigencia, etc.
302	Sello Mal Formado.
304	Certificado Revocado o Caduco. Este  código de error se regresa cuando el request posee información invalida, ejemplo: un RFC de receptor no válido.
305	Certificado Inválido. El  certificado puede ser inválido por múltiples razones como son el tipo, la vigencia, etc.
309	Certificado Inválido. El  certificado puede ser inválido por múltiples razones como son el tipo, la vigencia, etc.
310	CSD Inválido.

* Los códigos anteriores pueden aparecer tanto en el servicio de cancelación, como en el de consulta de estatus de comprobantes.

Tabla 4: Códigos para el nodo estatusCfdi en el método de consulta estatus de comprobantes.

Código	Descripción
0	Desconocido. Se obtiene cuando la respuesta del SAT no pudo ser interpretada de acuerdo a un estatus válido del CFDI
1	CFDi no existe. Se obtiene cuando la respuesta del SAT indica que el comprobante no pudo ser encontrado.
2	Vigente. Se obtiene cuando la respuesta del SAT indica que el comprobante se encuentra Vigente y no se puede especificar si se requiere aceptación o no para cancelarlo.
3	Vigente con aceptación. Se obtiene cuando la respuesta del SAT indica que el comprobante se encuentra Vigente y se requiere aceptación para cancelarlo.
4	Vigente sin aceptación. Se obtiene cuando la respuesta del SAT indica que el comprobante se encuentra Vigente y no se requiere aceptación para cancelarlo.
5	Vigente no cancelable. Se obtiene cuando la respuesta del SAT indica que el comprobante se encuentra Vigente y no es posible cancelarlo.
6	Cancelado. Se obtiene cuando la respuesta del SAT indica que el comprobante se encuentra Cancelado y no se puede especificar el medio como fue cancelado(con/sin aceptación o por plazo vencido).
7	Cancelación en proceso. Se obtiene cuando la respuesta del SAT indica que el comprobante se encuentra Vigente y está en espera de la respuesta del receptor para su cancelación.
8	Cancelado con aceptación. Se obtiene cuando la respuesta del SAT indica que el comprobante se encuentra Cancelado y se requirió aceptación del receptor para cancelarlo.
9	Cancelado sin aceptación. Se obtiene cuando la respuesta del SAT indica que el comprobante se encuentra Cancelado y no se requirió aceptación del receptor para cancelarlo.
10	Cancelado por plazo vencido. Se obtiene cuando la respuesta del SAT indica que el comprobante se encuentra Cancelado y no hubo una respuesta del receptor en las 72 horas hábiles posteriores a la solicitud de cancelación.
99	Indeterminado. Se obtiene cuando hay un error en la interpretación de la respuesta del SAT o cuando no hay una respuesta(que el servicio no se encuentre disponible).

Método acuseCancelacion

El método permite recuperar el acuse de cancelación de un comprobante en formato base64

Se encuentra disponible en la siguiente URL:
https://timbrado.pade.mx/servicio/rest/consulta/acuseCancelacion

Y cuyos parámetros (URL Query Parameters) se describen a continuación:

• contrato: Clave del contrato de servicios.
• uuid: UUID del comprobante que se desea recuperar.

Las credenciales (usuario y contraseña) deberán ir en el HEAD de la petición mediante el atributo “Authorization Basic” con el formato usuario:password codificados en base64.

El tipo de contenido (atributo Content-Type) deberá especificar el valor “application/xml“.

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación. La descripción de los atributos se describe a continuación:

• contrato: Clave del contrato de servicios.
• consultaOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa.
• codigo. Código global de la invocación. Un valor de 0 (cero) indica que la invocación se dio exitosamente, o de otra forma se indica la razón del problema.
• xmlBase64. String en formato base64 del xml correspondiente al uuid consultado.

Ejemplo de petición REST con el cliente Advanced Rest Client

Método cfdPorUUID

El método permite recuperar el xml en formato base64 de un cfdi.

Se encuentra disponible en la siguiente URL:
https://timbrado.pade.mx/servicio/rest/consulta/cfdPorUUID

Y cuyos parámetros (URL Query Parameters) se describen a continuación:

• contrato: Clave del contrato de servicios.
• uuid: UUID del comprobante que se desea recuperar.

Las credenciales (usuario y contraseña) deberán ir en el HEAD de la petición mediante el atributo “Authorization Basic” con el formato usuario:password codificados en base64.

El tipo de contenido (atributo Content-Type) deberá especificar el valor “application/xml“.

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación. La descripción de los atributos se describe a continuación:

• contrato: Clave del contrato de servicios.
• consultaOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa.
• codigo. Código global de la invocación. Un valor de 0 (cero) indica que la invocación se dio exitosamente, o de otra forma se indica la razón del problema.
• xmlBase64. String en formato base64 del xml correspondiente al uuid consultado.

Ejemplo de petición REST con el cliente Advanced Rest Client

Método consultarCfdiRelacionados

Este método permite consultar los documentos relacionados que tenga un documento.

Se encuentra disponible en la siguiente URL:
https://timbrado.pade.mx/servicio/rest/cancelacion/consultarCfdiRelacionados

Y cuyos parámetros (URL Query Parameters) se describen a continuación:

• contrato. Identificador único del contrato de servicios.
• rfcEmisor. RFC del Emisor del CFDI.
• rfcReceptor. RFC del Receptor del CFDI.
• uuid. Folio Fiscal del comprobante que se quieren consultar sus documentos relacionados.
• certBase64: String en formato Base64 del certificado.
• keyBase64: String en formato Base64 de la llave privada
• keyPass: String con la contraseña de la llave privada que se está enviando.
• opciones: Lista de strings que indica al servicio las opciones que se utilizarán en la petición

Las credenciales (usuario y contraseña) deberán ir en el HEAD de la petición mediante el atributo “Authorization Basic” con el formato usuario:password codificados en base64.

El tipo de contenido (atributo Content-Type) deberá especificar el valor “application/xml“.

Ejemplo de petición REST con el cliente Advanced Rest Client 

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación. La descripción de los atributos se describe a continuación:

• consultaOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa.
• UuidConsultado. UUID del que fue consultados sus documentos relacionados.
• codigo. Código global de la invocación. Un valor de 0 (cero) indica que la invocación se dio exitosamente, o de otra forma se indica la razón del problema.
• mensaje. Mensaje del servicio del SAT en caso de ocurrir un error.
  resultado. Resultado de la consulta realizada. Es un mensaje armado por el servicio del SAT.
• UuidsRelacionadosPadre. Este nodo contiene la información de el(los) uuid(s) que el documento consultado tiene como padre.
• UuidPadre. Contiene la información de uno de los UUID padre.
• Uuid. Es el UUID Padre del documento.
• RfcEmisor. Es el RFC del emisor del documento padre.
• RfcReceptor. Es el RFC del receptor del documento padre.
• UuidsRelacionadosHijos. Este nodo contiene la información de el(los) uuid(s) que el documento consultado tiene como hijo.
• UuidRelacionado. Contiene la información de uno de los UUID relacionado como hijo.
• Uuid. Es el UUID hijo.
• RfcEmisor. Es el RFC del emisor del documento hijo.
• RfcReceptor. Es el RFC del receptor del documento hijo

Códigos presentados en el atributo resultado.

Código	Descripción
2000	Existen cfdi relacionados al folio fiscal. Este código de respuesta se presentará cuando la petición de consulta encuentre documentos relacionados al UUID consultado.
2001	No Existen cfdi relacionados al folio fiscal. Este código de respuesta se presentará cuando el UUID consultado no contenga documentos relacionados a él.
2002	El folio fiscal no pertenece al receptor. Este código de respuesta se presentará cuando el RFC del receptor no corresponda al UUID consultado.
2003	La consulta supera la cantidad máxima permitida de folios fiscales.Este código de respuesta se presentará cuando la consulta supere la cantidad máxima permitida de folios fiscales.
2004	El folio fiscal no pertenece al emisor. Este código de respuesta se presentará cuando el RFC del emisor no corresponda al UUID consultado.

Método consultarPeticionesPendientes 

El servicio REST dispone de un método para consultar la peticiones pendientes de cancelacion que tiene el receptor por aprobar o rechazar.

Se encuentra disponible en la siguiente URL:
https://timbrado.pade.mx/servicio/rest/cancelacion/consultarPeticionesPendientes

Y cuyos parámetros (URL Query Parameters) se describen a continuación:

• contrato: Clave del contrato de servicios.
• rfcReceptor: RFC del receptor del uuid que desea consultar.
• opciones: Opciones adicionales para el servicio, comunmente usado para verificar los modos de prueba.

Las credenciales (usuario y contraseña) deberán ir en el HEAD de la petición mediante el atributo “Authorization Basic” con el formato usuario:password codificados en base64.

El tipo de contenido (atributo Content-Type) deberá especificar el valor “application/xml“.

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación. La descripción de los atributos se describe a continuación:

• consultaOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa.
• codigo. Código global de la invocación. Un valor de 0 (cero) indica que la invocación se dio exitosamente, o de otra forma se indica la razón del problema.
• codigoEstatus. Codigo devuelto por el servicio del SAT y que es informativo de la consulta.
• mensaje: Mensaje devuelto por la consulta al servicio o informativo de algún error en caso de haberlo.

Códigos de estatus en la respuesta

Este método permite responder las peticiones de cancelación realizadas por otros contribuyentes.

Se encuentra disponible en la siguiente URL:
https://timbrado.pade.mx/servicio/rest/cancelacion/responderSolicitudCancelacion

Y cuyos parámetros (URL Query Parameters) se describen a continuación:

• contrato: Clave del contrato de servicios.
• rfcReceptor: RFC del Receptor de los CFDI.
• arregloUUID. Lista de strings donde cada uno estará formado por el UUID y la respuesta a la petición (‘Aceptación’ o ‘Rechazo’) separados por el carácter pipe. Ejemplo:
  • UUID|Aceptacion
  • UUID|Rechazo
• cert: String en formato Base64 del certificado.
• key: String en formato Base64 de la llave privada
• keyPass: String con la contraseña de la llave privada que se está enviando.
• opciones: arreglo de strings que indica al servicio las opciones que se utilizarán en la petición, consultar Tabla 1. Opciones para los diferentes servicios

Las credenciales (usuario y contraseña) deberán ir en el HEAD de la petición mediante el atributo “Authorization Basic” con el formato usuario:password codificados en base64.

El tipo de contenido (atributo Content-Type) deberá especificar el valor “application/xml“.

Ejemplo de petición REST con el cliente Advanced Rest Client 

No todos los atributos están presentes en la respuesta, y esto dependerá del resultado de la operación. La descripción de los atributos se describe a continuación:

• procesoOk. Los valores posibles son “true” o “false”, y determina si la invocación al webservice fue exitosa. Es importante observar que el valor de este atributo no refleja el valor de cada cancelación individual. Por ejemplo podemos obtener “true” aquí pero error en cada cancelación individual. Obtendremos un valor de false en este atributo en caso de un error mayor, por ejemplo que el contrato de servicios esté expirado, o el usuario tenga una contraseña incorrecta.
• codigo. Código global de la invocación. Un valor de 0 (cero) indica que la invocación se dio exitosamente, o de otra forma se indica la razón del problema.
• codigoEstatus. Descripción del código obtenido en la respuesta.
• rfcReceptor. RFC del receptor de los UUIDs que se está respondiendo en la solicitud.
• rfcPac. RFC del PAC que realizó la cancelación.
  fecha. Fecha en la que se realizó la aceptación/rechazo de la petición.
  mensaje. Mensaje devuelto por el servicio e informativo en caso de algún error.
• Folios. Nodo que contiene un UUID y su respectivo Estatus ante el SAT. Este nodo tiene como atributo “Respuesta” que indica la respuesta que se le dio al SAT. Este nodo aparecerá por cada UUID enviado en la solicitud.
• uuid. UUID de la solicitud.
• EstatusUUID. Estatus del UUID en el SAT.

Estatus UUID en la respuesta

Código	Descripción
300	Usuario No Válido Este código de error se regresa cuando la autenticación del usuario no fue exitosa.
301	XML Mal Formado Este código de error se regresa cuando elrequest posee información invalida, ejemplo: un RFC de receptor no válido
302	Sello Mal Formado
304	Certificado Revocado o Caduco. El certificado puede ser inválido por múltiples razones como son el tipo, la vigencia, etc.
305	Certificado Inválido El certificado puede ser inválido por múltiples razones como son el tipo, la vigencia, etc.
309	Patrón de Folio inválido El patrón de folios para registro fiscal no coincide. Aplicable únicamente a cancelaciones de CFDI de RIF
310	CSD Inválido
1000	Se recibió la respuesta de la petición de forma exitosa
1001	Se recibió la respuesta de la petición de forma exitosa, No existen peticiones de cancelación en espera de respuesta para el uuid.
1002	Ya se recibió una respuesta para la petición de cancelación del uuid
1003	Sello No Corresponde al RFC Receptor
1004	Existen más de una petición de cancelación para el mismo uuid
1005	El uuid es nulo no posee el formato correcto
1006	Se rebasó el número máximo de solicitudes permitidas, Se cuenta con un límite 500 solicitudes pendientes por petición. Estás 500 solicitudes deben pertenecer al mismo Receptor.

Portal Firmado de Manifiesto

Dentro de nuestro servicio se encuentra este portal para que el contribuyente final firme la carta manifiesto. Es necesario utilizar la FIEL además de proporcionar algunos datos.

La URL del portal es:

https://facturacion.pade.mx/manifiesto

Puede hacernos llegar cualquier duda o aclaración de su funcionamiento al correo: soporte@prodigia.com.mx

---

Campos obligatorios para consultar comprobantes