Buscar en este blog

miércoles, 14 de noviembre de 2018

(VirtualPAC) Aviso IMPORTANTE sobre CFDIs no existentes en el SAT


El pasado día Jueves 8 de Noviembre 2018, nuestro PAC primario “DFacturE” (Facturación Electrónica, S.A.) emitió erróneamente CFDI’s con UUID que no fueron registrados en el SAT, notando esta falla el día Viernes 9 de Noviembre.

Para corregir este error, DFacturE re-emitió los CFDI erróneos el día 10 de Noviembre, lo que generó distinto UUID al que originalmente fue emitido. 

El contenido del CFDI se mantuvo exactamente igual y el CFDI se encuentra debidamente registrado en el SAT cambiando únicamente el timbre fiscal digital y su correspondiente UUID. En algunos casos, la re-emisión del CFDI no fue posible.

Para ayudar a nuestros usuarios a identificar los documentos afectados por esta falla, DFActurE nos ha proporcionado un listado con los UUID erróneos, los UUID correctos y los UUID que no pudieron re-emitirse, ordenados por RFC emisor.

Dentro de las próximas 24 hrs. pondremos a su disposición a través del portal de Administración de VirtualPAC (http://admin.virtual-pac.mx), un archivo ZIP conteniendo los archivos XML con el timbre fiscal digital correcto; así como una hoja de MS Excel con la información correspondiente al RFC Emisor, UUID Erróneo, UUID Correcto, así como UUID que no pudieron ser re-emitidos.

Lamentamos las molestias que esto pueda ocasionarles y en compensación por nuestra parte, asignaremos sin costo 10 timbres fiscales a cada emisor por cada UUID que no haya sido procesado correctamente. 

Para más información relativa a esta falla y dado que escapa a nuestra competencia directa, les pedimos atentamente se pongan en contacto directo con el PAC “DFacturE” en el teléfono: 01-222-248-5252 con la Srta. Pilar Curiel o al correo integraciones@dfacture.com
 
Reiteramos nuestro compromiso con nuestros clientes para proporcionarles el mejor servicio de timbrado.

viernes, 9 de noviembre de 2018

(VirtualXML) El valor del campo TotalImpuestosRetenidos debe ser igual a la suma de los importes registrados en el elemento hijo Retencion

El día de hoy Viernes 9 de Noviembre 2018 muchos emisores han comenzado a obtener este mensaje de error:

CFDI33181 El valor del campo TotalImpuestosRetenidos debe ser igual a la suma de los importes registrados en el elemento hijo Retencion. El nodo Impuestos:Retenciones no contiene elementos.

No es un mensaje de error, es un error de llenado del XML mismo que las nuevas guias de llenado publicadas por el SAT en Septiembre de 2018 ya habían comentado que se validaría.

¿ En que consiste el error ?

El error consiste en poner 0.00 en el nodo TotalImpuestosRetenidos, cuando el CFDI NO TIENE RETENCION DE IMPUESTOS, es decir, no hay retención de IVA o de ISR (retenciones que solo existen cuando las personas físicas emiten recibos de honorario ó arrendamiento a personas morales) o bien en algunos casos de retención por ventas a gobierno.

Por lo tanto, si un CFDI no tiene retenciones no tiene porque contener el nodo TotalImpuestosRetenidos y por ende este nodo no debe tener ningúnn valor.

Usando VirtualXML y la función:


Es la causa del problema pero al mismo tiempo la solución.

El problema se causa cuando haces:

VirtualXML_SetImpuestosInfo_cfdi33(hXml, "ImporteTraslados","0.00")

El último parámetro de la función es el que se utiliza para indicar el importe de los impuestos retenidos, si estos no existen en tu CFDI, debes usar esta función así:

VirtualXML_SetImpuestosInfo_cfdi33(hXml, "ImporteTraslados","")

Como verás el último parámetro está vacío, con lo cual no se generará el nodo "TotalImpuestosRetenidos"cuando estos no existan.

Este mismo error lo tendrás cuando pongas un valor de "0.00" en los descuentos de las partidas, pero este asunto ya lo hemos tratado en otro post del blog que puedes consultar en:

http://virtual-pac.blogspot.com/2018/02/virtualxml-el-problema-de-los.html 

Es importante recalcar que cuando un nodo relativo a importes (SubTotal, Total, Descuentos, etc) cuando no tienen valor NO DEBEN SER LLENADOS CON 0.00, simplmente o deben existir.
 
Es importante que realices este cambio ya que el SAT continuará siendo mas exigente con el llenado de los CFDI 3.3

lunes, 22 de octubre de 2018

(VirtualXML) 2 Nuevas funciones para el nuevo esquema de cancelaciones


El día de hoy Lunes 22 de Octubre de 2018, estamos liberando una nueva version de VirtualXML que incluye 2 funciones muy importantes para el nuevo esquema de cancelación:

La función:
VirtualXML_CancelaCFDI()

Que publicamos la semana pasada, sufrió algunos cambios internos para mejorar su desempeño y 2 validaciones adicionales que no estabamos realizando. Ahora funciona correctamente en todos los casos.

Les recuerdo que cuando la función devuelva un valor 1 (que indica que se ha solicitado la cancelación por medio del buzón tributario, se cobrará 1 timbre por el uso del servicio), cuando la cancelación sea directa, o no proceda ya sea porque el CFDI no es cancelable o bien porque no se encuentre en los registros del SAT, no habrá cobro por el uso de la función.


Incluimos una nueva fucnión:

VirtualXML_GetStatusCFDI()

Esta función tiene como objetivo obtener el estado de un CFDI (Cancelable, no cancelable o no existente) durante el proceso de cancelación bajo el nuevo esquema, por ejemplo:
  • Puedes consultar el estado (ver si es cancelable, no cancelable y como se puede cancelar: directamente o con autorización) de un CFDI ANTES de cancelarlo
  • Puedes consultar si un CFDI ya se encuentra en los registros del SAT y es cancelable
  • Puedes consultar si un CFDI ya se autorizó para cancelación o bien esta en PROCESO de autorización
  • Puedes consultar si un CFDI aplicó cancelación Ficta o fue rechazado por el el receptor.
Es muy importante recordarles que el uso de esta función tiene costo de 1 timbre fiscal por UUID consultado, el cual se cobrará una unica vez, la primera vez que se solicite la consulta, despues de la primer consulta, podrás realizar todas las consultas que desees sobre el mismo UUID tantas veces como quieras sin costo, solo se cobra la primer consulta.

La documentación y ejemplo de esta nueva función ya se encuentra en la documentación en línea de VirtualXML:

http://www.virtual-pac.mx/doc/html/Virtualxml_GetStatusCFDI.htm

Les recordamos que el nuevo esquema de cancelaciones entra en vigor el día 1 de Noviembre, por lo que cuentan con poco mas de 1 semana para realizar los cambios en sus sistemas.

La nueva DLL se encuentra disponible como siempre en nuestro sitio:

http://www.virtual-pac.mx/vxml_x86x64_xp2003.zip
 
Los wrappers de las nuevas funciones ya se encuentran disponbiles en los respectivos ejemplos en cada lenguaje que pueden descargar de nuestra pagina web: www.virtual-pac.mx



sábado, 13 de octubre de 2018

(VirtualXML) Nueva función de Cancelación Vigente a partir del 1 de Noviembre 2018

Tenemos el tiempo encima para la entrada del nuevo esquema de cancelaciones el cual entrará en vigor el día 1 de Noviembre de 2018.

El nuevo método de cancelación es bastante complejo y esta vez TENDRA COSTO en un caso específico, por favor, lee este artículo hasta el final para saber cuando tendrás que pagar un timbre y cuando la cancelación será sin costo.

La nueva función es:

VirtualXML_CancelaCFDI()

No confundir con  VirtualXML_CancelaUUID(), esta función es la que esta actualmente vigente pero no funcionará a partir del 1 de Noviembre.

Veamos la sintaxis de esta nueva función:

VirtualXML_CancelaCFDI( cUsuario,         
                        cRfcEmisor,
                        cRfcReceptor,
                        cTotal,
                        cUuid,
                        cCert,
                        cKey,
                        cPwd,
                        cArchResult,
                        cArchLog ) -> nResultado

 Donde :

    cUsuario: Nombre del usuario VirtualPAC
  cRfcEmisor: RFC del emisor del CFDI que deseamos cancelar.
cRefReceptor: RFC del receptor del CFDI que deseamos cancelar
      cTotal: Importe total del CFDI que queremos cancelar
       cUuid: UUID del CFDI a cancelar:
       cCert: Ruta y nombre del archivo .CER del emisor del CFDI
        cKey: Ruta y nombre del archivo .KEY del emisor del CFDI
        cPwd: Password de archivo KEY
 cArchResult: Ruta y nombre de un archivo donde se colocará el resultado de la cancelación
    cArchLog: Ruta y nombre de un archivo donde se colocará una bitacora donde se registrarán los eventos del proceso de cancelación.

Devuelve:

nResultado: Un valor numérico que nos indica el resultado del proceso de cancelación y que puede tener 5 posibles valores:

    • 1 - Significa que el CFDI no puede cancelarse directamente y que se ha solicitado al receptor, mediante el buzon tributario, la cancelación del CFDI, en este caso habrá que esperar las 72 horas que marca la ley para obtener una cancelación FICTA si el receptor no rechaza la cancelación o bien si el receptor rechaza la cancelación, el documento no se cancelará, en cualquier caso, si la función devuelve un valor de "1" (UNO) se te cobrará un timbre del saldo del emisor. El cobro de este timbre NO GARANTIZA que la cancelación proceda exitosamente, queda a criterio del SAT y del receptor aplicar la cancelación correspondiente.
    • 0 - Significa que el CFDI se puede cancelar directamente y que se ha cancelado con éxito, en este caso no se te cobrará timbre por la cancelación del documento.
    • -1 - Significa que el CFDI NO SE PUEDE CANCELAR, esto puede deberse a varios motivos, como por ejemplo, el CFDI ha sido previamente cancelado o bien, el CFDI esta en estado de "PROCESANDO", la cancelación ha sido rechazada por el receptor, el CFDI tiene documentos relacionados y otros posibles errores, mismos que podrán consultarse mas a detalle en el archivo de resultados.
    • -2 Indica que el CFDI no existe aún en los registros del SAT, si obtienes este resultado, deberás revisar que has indicado un CFDI correcto o bien tendrás que esperar algun tiempo hasta que el CFDI sea registrado en el SAT, te recordamos que el tiempo que marca la ley para que el PAC envie al SAT los CFDI es de un máximo de 72 horas.
    • -3 Indica que existe algún error en el proceso interno de cancelación como por ejemplo que el servicio de cancelaciones del SAT no está disponbile, para mas detalles deberás consultar el archivo de bitácora (ultimo parámetro de la función) donde se guardan detalles técnicos de operación de la función. 
Ejemplo:

nResultado := VirtualXML_CancelaCFDI( "Usuario",                        "AAA010101AAA",
                        "CTE940531F58",
                        "1160.00",
                        "D8E18C2F-2859-4927-A0F0-EA3E93642DDC",
                        "c:\certificados\archivo.cer",
                        "c:\certificasos\archivo.key",
                        "PasswordDelKey",
                        "d:\resultados\resultado.ini",
                        "d:\resultados\bitacora.log")

Por favor nota que esta nueva función incluye 2 archivos de resultados, el primero es un archivo donde aparecerán los resultados completos del proceso de cancelación, si el nombre lo indicas con la extensión ".INI", obtendras un archivos con los resultados expresados en formato INI, si utlizas otra extensión o no le pones extensión al archivo, lo obtendrás como un texto plano dividido en renglones. En este archivo se guardará toda la información devuelta por el SAT del proceso de cancelación


Entre otros datos podrás encontrar el error de la cancelación, el estado del comprobante, si el comprobante es cancelable y el estatus de cancelación, así como también el PAC que canceló el documento.

El segundo archivo es un archivo de bitácora similar al VirtualXML.LOG donde la función guarda todos los pasos seguidos en el proceso de cancelación, este archivo solo será necesario para fines de depuración y control de errores, pero te recomendamos tenerlo a mano para hacerlo llegar a nuestra area de soporte en caso de que tengas fallas (que las vas a tener) con el nuevo esquema de cancelaciones.

Esta nueva función ya esta disponible en la versión de VirtualXML del 08 de Octubre de 2018 y que ya está disponible en nuestra página web (www.virtual-pac.mx).

TODOS LOS EMISORES DEBERAN ACTUALIZAR SU DLL PARA TENER ACCESO A LA NUEVA FUNCION DE CANCELACIONES.

Nuestros PACs nos han informado que ya es posible realizar pruebas en un entorno "real" proporcionado por el mismo SAT ya que hasta la fecha, todas las pruebas solo se podían realizar en entornos simulados por los PACs no reales.

La batería de funciones de cancelación no está concluida aún, faltan 3 funciones muy importantes que de momento no podemos liberar hasta que empiecen a fluir las cancelaciones reales bajo el nuevo esquema y que son:

  1. Función para revisar el estado de un documento en PROCESO y saber si la cancelación ya fue autorizada o bien fue rechazada por el receptor, estamos considerando utilizar una función que ya viene incluida en VirtualXML que es VirtualXML_ConsultaEstadoCFDI() que ya existe actualmente y que debemos modificar para devolver nuevos valores, de momento no podemos hacerlo hasta ver que resultados nos va a devolver el SAT exactamente, que ya hasta el momento de escribir este artículo aún no esta disponible la plataforma de consultas.
  2. Función para descargar todas las peticiones de cancelación de nuestros proveedores, a fin de evitar tener que estar consultado el buzón fiscal todos los dias, tendremos una función que te permitirá descargar todas las peticiones de cancelacions que hayas recibido en tu buzón fiscal, el uso de esta función se cobrará a 1 timbre por consulta.
  3. Función para autorizar/rechazar las peticiones de cancelación recibidas, esta función tiene por objeto que puedas autorizar o rechazar las peticiones que hayas descargado sin necesidad de utilizar el buzón fiscal, el uso de esta función también tiene el costo de 1 timbre por uso. 
El hecho que de en esta ocasión tengamos que cobrar los timbres por algunos servicios, se debe a que los PACs que prestan el servicio de cancelación también nos van a cobrar a nosotros por las cancelaciones, y tienen razón, se está utilizando un servicio que les ha costado desarrollar, implementar y mantener, por lo mismo tienen que cobrar el servicio.

Esperamos que esta información te sea de utilidad para comenzar a trabajar con el nuevo esquema de cancelaciones, por nuestra parte seguimos trabajando para tener pronto toda la batería de funciones lista.

viernes, 5 de octubre de 2018

(VirtualXML) CRP213 El campo CtaOrdenante no cumple con el patrón requerido

Lo sabía, lo sabía, lo sabía.

Conforme avanza la implementación del Complemento de Recepción de Pago (CRP) también conocido como Recibo Electrónico de Pago (REP) entre nuestros emisores, surgen distintos casos, muchas dudas, y problemas que "antes no pasaban".

Uno de ellos, que es por el que mas nos han llamado esta semana es un error que dice textualmente lo siguiente:

"CRP213 El campo CtaOrdenante no cumple con el patrón requerido."


Y venga la avalancha de llamadas de..... es que me esta rechazando pagos que antes si dejaba pasar....

Bien aclaremos y resolvamos esta incógnita de una vez y para siempre.

Para dar con el culpable, tendremos que irnos al Catálogo de Complemento de Pagos, publicado por el SAT en:


 Este catálogo es una hoja de Excel, donde el primer libro, llamado c_FormaPago tiene la respuesta a nuestras preguntas.

En este libro tenemos el Catálogo de Formas de Pago que tendremos que usar para llenar nuestro complemento y esta divido, entre otras en las siguientes columnas, que son las que nos importan realmente:
  • Clave de la Forma de Pago
  • Descripción
  • Bancarizado
  • Numero de operacion
  • RFC del emisor de la cuenta ordenante
  • Cuenta ordenate y.......
  • PATRON PARA LA CUENTA ORDENANTE
O lo que es lo mismo:


Como podemos ver, en la columna Patrón para cuenta ordenante, está definida la EXPRESION REGULAR (Regular Expression) que define como debe de ir conformado el numero de cuenta ordenante.

No voy a entrar en detalle de lo que es una expresión regular, asumo que ya lo sabes, pero por si acaso, te dejo el link de la Wikipedia para mas información:


Bien, volviendo al tema, si revisamos las RegEx (Regular Expressions) de los patrones de cuenta ordenante lo primero que podemos apreciar, es que el patrones que define el pago con Cheque nominativo no es el mismo que el patrón que define el pago con Transferencia electrónica de fondos, ni el mismo de la tarjeta de crédito.

Veamos:

Para pago con cheque nominativo la RegEx es: 

[0-9]{11}|[0-9]{18}

Que significa lo siguiente:

Este patron acepta 2 formatos:
  1. 11 digitos del 0 al 9
  2. 18 digitos del 0 al 9 (esto equivale a la Clave Bancaria Estandarizada CLABE) 
Hasta aquí aparentemente no hay problema, si nos pagan con cheque nominativo entonces la cuenta debe de ir expresada con 11 dígitos, o bien debo poner la CLABE que siempre van a ser 18 digitos.

¿ Que pasa si la cuenta tiene menos de 11 dígitos ?, por ejemplo una cuenta de Banamex tiene solo 7 dígitos, muy fácil, rellenaré con ceros "0" a la izquierda, hasta alcanzar los 11 dígitos, por ejemplo:

La cuenta Banamex: 4575787
Quedaría como: 00004575787

Pero si utilizo la CLABE no tengo problema: 002180065145757870

Analicemos ahora la RegEx para el pago con transferencia electrónica de fondos:

[0-9]{10}|[0-9]{16}|[0-9]{18}

A diferencia del anterior, este patrón acepta 3 formatos:
  1. 10 dígitos del 0 al 9
  2. 16 dígitos del 0 al 9
  3. 18 dígitos del 0 al 9
Vemos que salvo el caso de la CLABE (18 digitos), el patrón para pago con cheque NO ES EL MISMO QUE EL PATRON PARA PAGO CON TRANSFERENCIA, por lo tanto NO PODEMOS USAR EL MISMO NUMERO DE CUENTA QUE USAMOS EN EL PAGO CON CHEQUE QUE EN EL PAGO CON TRANSFERENCIA.

Volviendo al ejemplo de Banamex:

La cuenta Banamex: 4575787
Para pago con cheque quedaría: 00004575787
Para pago con transferencia quedaría: 0004575787
Para pago con cheque y transferencia indistintamente: 002180065145757870

Nota que para el pago con cheque he tenido que añadir 4 ceros a la izquierda para alcanzar la logitud de 11 caracteres mientras que para el pago con transferencia he tenido que agregar solo 3 ceros para alcanzar la longitud de 10 dígitos.

¿ No es incoherente que para un caso la cuenta se maneje con 10 dígitos mientras que para otra forma de pago la misma cuenta se maneje con 11 dígitos ?

Probablemente sí, sin embargo hay una solución universal para este problema: Utilizar la CLAve Bancaria Estandarizada (CLABE), que siempre tiene una longitud de 18 dígitos y que todo parece indicar que el SAT junto con BANXICO quieren fomentar su uso, en el complemento de pagos.

Con esto queda revelado el misterio de porqué "el campo CuentaOrdenante no cumple con el patrón requerido".

¿ Porque algunas veces no timbra otros documentos que antes si timbraba ?, no hay misterio, seguramente estas metiendo el numero de cuenta que usabas para el pago con cheque en el pago con transferencia o viceversa.

Pare de sufrir:  utiliza siempre la CLABE y te olvidas de problemas que si con 10 dígitos cuando es transferencia ú 11 dígitos cuando es cheque.

lunes, 24 de septiembre de 2018

(VirtualXML) Como poner un "namespace" en la seccion Comprobante de un CFDI con VirtualXML

Con la entrada del nuevo Complemento de Recepción de Pagos 1.0, algunos de nuestros usuarios nos han comentado que ciertos validadores de terceros marcan un error en la ubicación de los "namespace" del complemento de pagos (o de otros complementos).

De acuerdo a la Wikipedia, un "namespace" o "espacio de nombres" es un contexto en el que un grupo de uno o más identificadores pueden existir. En términos generales podríamos decir que un namespace, es una forma de agrupar clases, funciones, tipos de datos, etc. que están relacionadas entre sí.


Para que te des una idea de lo que es un namespace, estas son las lineas que lo definen para un CFDI:


xmlns:cfdi="http://www.sat.gob.mx/cfd/3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.sat.gob.mx/cfd/3 http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv33.xsd"




En el caso del CFDI un "namespace" nos sirve para ubicar en internet la definción que establece las reglas de como debe de conformarse un CFDI en cualquiera de sus variantes.

Un namespace consta básicamente de 3 partes:
  • Nombre del namespace
  • URL en internet del namespace
  • Schema Location, que es la ubicación del archivo XSD que define las reglas de conformación del XML.

Si bien no existe una regla general que obligue a un namespace a colocarlo en alguna parte específica del XML, usualmente este se define en el punto donde sus reglas van a aplicarse, en el caso de un CFDI este lugar puede ser el nodo principal <cfdi:Comprobante> o bien cualquiera de sus subnodos en el caso de los complementos.

Algunos validadores de terceros requieren que los namespaces de los complementos usados en un CFDI se coloquen al nivel del nodo <cfdi:Comprobante> y no a nivel del nodo que define el complemento, que es como lo hace VirtualXML.

En todo caso, tu puedes editar manualmente el XML con cualquier editor de textos y mover los namespaces de la definición del complemento a la definción del nodo <cfdi:Comprobante> y no tendrá repercusión alguna ya que los namespaces no se utilizan para la generación de los sellos digitales por lo tanto pueden ir en cualquier parte del documento XML.

Debido a que entendemos que tener que editar un XML manualmente, mover namespaces y luego guardar el XML es un tarea tediosa, sobre todo si tienes muchos XMLs que requieran mover los namespaces, hemos desempolvado del baúl de los recuerdos de VirtualXML una función que hacía mucho tiempo no utilizabamos.:

VirtualXML_AddNameSpace()

Esta función, como su nombre lo indica te permitirá añadir un namespace directo en la definición de namespaces del nodo <cfdi:Comprobante>, solucionando con esto el problema de la ubicación que algunos validadores te pueden marcar.

Esta función NO MUEVE LOS NAMESPACES DE LUGAR, crea nuevos namespaces a la altura del nodo <cfdi:Comprobante> pero los namespaces definidos en los complementos se van a mantener, esta duplicidad de namespaces NO AFECTA LA INTEGRIDAD DEL XML, por lo que será timbrado sin problema por el PAC y reconocido por los validadores.

Sintaxis:

VirtualXML_AddNameSpace (
<hHandle>, 
<cNombre>, 
<cUrl>,
<cSchemaLocation>)

Donde:

<hHandle> Identificador en memoria devuelto por la función VirtualXML_New()
<cNombre> Cadena de caracteres con el nombre del namespace
<cUrl>  Cadena de caracteres con el URL del namespace
<cSchemaLocation> Cadena de caracteres con la URL del archivo XSD que define la estructura del XML.

Ejemplo:

Supongamos que queremos poner los namespaces del Timbre Fiscal Digital y del complemento de pagos a nivel del nodo <cfdi:Comprobante>, haríamos lo siguiente:

nHandler := VirtualXML_New("3.3")

/* Agregamos el namespace del TFD */
VirtualXML_AddNameSpace(nHandler,;
"xmlns:tfd",;
"http://www.sat.gob.mx/TimbreFiscalDigital","http://www.sat.gob.mx/sitio_internet/cfd/TimbreFiscalDigital/TimbreFiscalDigitalv11.xsd")

/* Agregamos el namespace del Complemento de pagos*/
VirtualXML_AddNameSpace(nHandler,;
"xmlns:pago10",;
"http://www.sat.gob.mx/Pagos","http://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd")

Y de esta manera agregamos 2 namespaces nuevos dentro la definición del nodo <cfdi:Comprobante> y aunque estos se van a repetir cuando agreguemos los complementos correspondientes, no afectarán la integridad del XML.

¿ Hasta cuantos namespace puedo agregar usando esta función ? Todos los que tu quieras o consideres necesarios, si quieres agregar TODOS los namespaces de TODOS los complementos lo puedes hacer sin ningún problema.

Esperamos que esta función te solucione los problemas que alguno que otro validador de CFDI te pueda dar.

lunes, 13 de agosto de 2018

(VirtualXML) Mas sobre el tema de las cancelaciones (Actualizado al dia 15 de Agosto 2018)

Estamos a unos días en que entren en vigencia los nuevos cambios en el esquema de cancelaciones del SAT, por lo que considero importante hacer un resumen de todo lo que sabemos hasta ahora para que puedan empezar a tomar medidas al respecto y comenzar a indicarles el funcionamiento de las nuevas funciones de cancelación de VitualXML.

Quiero agradecer a nuestro PAC principal DFacturE, por la información y las gráficas que nos ha facilitado para escribir este artículo.

Antes de empezar, revisemos como estamos realizando el proceso de cancelación actualmente, y lo hacemos según el siguiente diagrama:


Bajo el esquema actual un CFDI solo puede tener 2 estados: CANCELADO y VIGENTE; si un CFDI esta VIGENTE luego entonces es CANCELABLE y podemos proceder con una CANCELACION DIRECTA.

Sin embargo, el nuevo esquema de cancelación es un poco mas complejo como veremos mas adelante, pero antes de continuar, debemos saber CUANDO SI se pueden cancelar facturas sin necesidad de "autorización" por parte del receptor, sin importar el monto que ampare dicho comprobante.

Estos son los casos en los que se pueden cancelar los CFDI sin necesidad de una autorización por parte del receptor, ni del proceso de cancelación a través del Buzón Tributario:
  • Comprobantes de cualquier tipo (I, E, N, P, T) y cualquier monto y que no hayan pasado mas de 72 horas desde su emisión.
  • Comprobantes de Nomina, Egreso, Traslado, Pago y Retención, sin limite de monto ni tiempo.
  • El comprobante emitido para contribuyente del Sector Primario.
  • El comprobante emitido para contribuyente del Regimen de Incorporación Fiscal (RIF). 
  • El comprobante fue emitido por un integrante del Sistema Financiero (bancos)
  • El comprobante de Ingreso con importe menor a $5,000.00 ANTES DE IMPUESTOS 
  • El comprobante de Ingreso emitido a través del portal "Mis Cuentas" de la página del SAT.
  • El comprobante de Ingreso emitido al publico en general (Rfc generico: XAXX010101000)
  • El comprobante de ingreso emitido al un cliente extranjero (Rfc genérico extranjero: XEXX010101000)
 Aquí tenemos que considerar que si no han pasado 72 horas desde la emisión del documento, yo lo puedo cancelar con la misma función con la que los he venido cancelado hasta el día de hoy (VirtualXML_CancelaUUID()).

Si el CFDI no se encuentra en los supuestos anteriores, o bien ya pasaron mas de 72 horas desde su emisión, para cancelarlos será necesario tomar en cuenta el nuevo esquema de cancelaciones, que gráficamente se presenta así:




Similarmente a como estabamos acostumbrados, el CFDI puede tener 2 estados: CANCELADO y VIGENTE, en el caso de los CFDIs vigentes, en el nuevo esquema de cancelaciones, estos pueden presentar 2 estados: CANCELABLE y NO CANCELABLE.

Para poder considerar un documento como CANCELABLE, este deberá ser de Ingreso, estar vigente, Y NO TENER DOCUMENTOS RELACIONADOS, esto último es muy importante, ya que si existen documentos relacionados al documento que se desea cancelar, el CFDI será NO CANCELABLE, para convertirlo en un CFDI CANCELABLE será necesario cancelar primero los documentos relacionados y posteriormente cancelar el documento original, SE VALIDARA LA EXISTENCIA DE DOCUMENTOS RELACIONADOS AL MOMENTO DE INTENTAR CANCELAR.

Si un documento es CANCELABLE, puede presentar 3 estados:

NO REQUIERE ACEPTACION, en este caso podemos proceder a cancelarlo directamente como lo habíamos venido haciendo hasta el dia de hoy, es decir mediante la función VirtualXML_CancelaUUID().

Un CFDI CON ACEPTACION requerirá realizar una solicitud de cancelación del mismo por 2 vías:

  1. Buzón tributario del contribuyente en el portal del SAT
  2. A través de los servicios de un PAC.
A pesar de que nuestros 3 PACs ya se encuentran autorizados para el nuevo esquema de cancelación, hasta el momento de escribir este artículo, ninguno de los 3 nos ha indicado el proceso para solicitar la cancelación a través de sus servicios, por lo que en cuanto tengamos la nueva información disponible, esta será materia de otro artículo del blog.

Una vez hecha la solicitud por cualquiera de los dos medios mencionados anteriormente, esta será enviada al SAT y el comprobante quedará en el estado de "OPERANDO", que es algo así como el limbo de los comprobantes fiscales, durante el plazo que indica el SAT para aceptar o cancelar el documento que es de 72 horas contadas a partir de la fecha de solicitud de la cancelación.

El estado del CFDI se podrá verificar desde código usando la función VirtualXML_ConsultaEstadoCFDI(), la cual ahora devolverá 3 posibles valores: VIGENTE, CANCELADO y OPERANDO.

Si el receptor ACEPTA la cancelación antes de 72 horas, el documento quedará automáticamente cancelado en los registros del SAT, y deberás utilizar la función de ConsultaEstadoCFDI() para saber si ya pasó del estado de OPERANDO al estado de CANCELADO.

Si después de las 72 horas el receptor explicitamente NO RECHAZA la solicitud de cancelación, el documento quedará cancelado en los registros del SAT y no habrá necesidad de hacer ningún otro procedimiento adicional, a este proceso se le llama "aceptación FICTA o aceptación por plazo vencido", esto minimiza en impacto que nuestros usuarios pudieran tener en sus sistemas, sin embargo, es su responsabilidad el estar revisando constantemente el estado del CFDI hasta que transcurran las 72 horas de plazo.

En caso de que el receptor RECHACE la cancelación del documento y el emisor vuelva a solicitarla, nuevamente tendrá el plazo de 72 horas para manifestarse al respecto, pero en este segundo intento de cancelación, si no hay respuesta por parte del receptor NO SE CANCELARA EL DOCUMENTO, a esto se le llama "rechazo FICTO".

En el caso de que existan documentos relacionados a un CFDI que se quiera cancelar, se deberá seguir el orden inverso para ir cancelado los documentos relacionados ANTES de cancelar el CFDI que los referencie.

Debemos de tener en cuenta que nuestros emisores estan en los dos lados, tanto necesitan cancelar CFDIs como autorizar la cancelación de CFDIs, por ello VirtualXml incluirá 5 funciones para realizar el proceso de cancelación, de momento estos son los PROTOTIPOS de las funciones, aun nos falta pulirlas, ver su lista de parámetros, probarlas e incluirlas en la DLL, NO SON FUNCIONALES NI ESTAN INCLUIDAS EN VIRTUALXML, así que por favor, no pidan documentación, parámetros ni área de pruebas hasta que les informemos que ya están implementadas y que ya hemos liberado una nueva versión de la DLL.

Serán 5 funciones para cancelación, divididas en 2 categorías:

Funciones para cancelar CFDI emitidos:

VirtualXML_ConsultaStatusCFDI() : esta función se utiliza para obtener el estado del CFDI antes de intentar cancelarlo y devolverá los siguientes valores:
  • Codigo: 201 Mensaje: Comprobante obtenido satisfactoriamente, Cancelable: Cancelable SIN aceptacion
  • Codigo: 211 Mensaje: Comprogante obtenido satisfactoriamente, Cancelable: Cancelable CON aceptacion
  • Codigo: 602 Mensaje: Comprobante no encontrado, Cancelable: No aplica
  • Codigo: 215 Mensaje: El UUID no cumple con la estructura válida, Cancelable: No aplica
VirtualXML_CancelaUUID(): Es la función que se utiliza actualmente solo que ahora devolverá los siguientes valores:
  • Codigo: 201 Mensaje: UUID Correctamente cancelado
  • Codigo: 211 Mensaje: UUID Cancelable con aceptacion
  • Codigo: 221 Mensaje: El UUID enviado no tiene un formato valido
  • Codigo: 205 Mensaje: El comprobante aun no se encuentra reportado en el SAT 
VirtualXML_ConsultaDocumentos relacionados(): Esta función se utiliza para obtener todos los documentos relacionados del documento que se intenta cancelar así como los documentos relacionados que puedieran tener los primeros documentos relacionados (en pocas palabras, los documentos relacionados de los documentos relacionados)., devuelve los sigentes valores:
  • Codigo:2000 Mensaje: Se encontraron CFDIs relacionados y un texto con la estructura "padre, UUID,RFCMISOR,RFCRECEPTOR", seguido del texto "hijo,UUID,RFCEMISOR,RFCRECEPTOR"
  • Codigo:2001 Mensaje: No existen CFDI relacionados

Funciones para consultar las peticiones recibidas de emisores:

VirtualXML_ConsultaPeticionesPendientes(): Esta función se utiliza para obtener una lista de los UUID que estan pendientes de Autorizar/Rechazar solicitados por nuestros emisores, devuelve los sigientes valroes:
  • Codigo: 1001 Mensaje: Una lista con los UUIDS pendientes de Autorizar/Rechazar, uno por renglon
  • Codigo: 1101 Mensaje: No hay UUIDs pendientes de cancelar.
VirtualXML_AceptacionRechazo(): Esta funcion se utiliza para Autorizar/Rechazar UUIDs ya sea masiva o individualmente, Regresa los siguientes valores:
  • Codigo: 1000, Mensaje: "UUID, Aceptado ó Rechazado" dependiendo si se autorizo o se rechazo la autorización
  • Codigo: 1001, Mensaje: "UUID, Rechazado,No existen peticiones de cancelacion en espera"
Tengan en cuenta que estas dos funciones son nuevas y son explicitamente para autorizar o rechazar la cancelación de documentos.

En los proximos días publicaremos mas información sobre estas funciones a fin de que puedan implementarlas en sus sistemas.

El SAT ha publicado un video donde podrán conocer mas a detalle aspectos relacionados con el nuevo esquema de cancelación: