Mismo documento se emitio al mismo tiempo con el PAC de Timbrado y el PAC de Respaldo

[jflores101292]

Buen día

Después de la auditoria del 2023 por parte del SAT, detectamos que tenemos varios documentos donde se mando a timbrar al mismo tiempo tanto con el PAC principal como con el PAC de respaldo, esto ocasiono que se generaran dos UUID's para la misma factura. ¿Por qué puede pasar esto? No es con todos los casos pero si me sigue generando casos así, adjunto los 2 XML que tengo en el SAT para la misma factura

[Dado]

Busca aquí en el foro un término como “CFDI duplicado” o algo similar, hay una entrada que explica muy ampliamente que puede estar pasando

Ahorita ando en la calle, como para poder buscarlo y dirigirte directamente

[jflores101292]

Gracias Dado

Veo que puede ser que no alcanza a recuperar el CFDI y es por eso que lo vuelve a llamar, voy a probar agregando la función de Recuperar el CFDI y renombrar cada .ini con su fecha y hora único

[jflores101292]

Buenas tardes Dado, estuve revisando el desarrollo y si se utiliza la función de Recuperar el CFDI
Me acaba de reportar el departamento de Fiscal, que en el 2023 hay mas documentos con el mismo caso, donde aparece timbrado con el PAC de Timbrado y el PAC de Respaldo con la misma fecha y hora de emisión. ¿Qué mas puedo revisar, ya que si se utiliza la función para recuperar el CFDI pero aun así sigo tendiendo estos casos?

¿Hay forma de deshabilitar el PAC de Respaldo?

Otra duda, ¿Hay alguna forma de mandar a cancelar estos UUIDs duplicados ante el SAT por este motivo desde alguna utilería del PAC?

[Dado]

Recuerda buscar en el foro por las respuestas, si buscas "deshabilitar el PAC de respaldo" encuentras esta entrada

Acerca de las cancelaciones, tambien hay muchisimas publicaciones al respecto, debes usar la funcion CancelarCFD(archivo.ini)

[jflores101292]

He estado buscando en el foro y veo que ese problema se presenta por varios motivos, revisando todos los casos que tiene la empresa que usa ECODEX, es el siguiente escenario que comentaste en un ticket anterior que vi


Escenario 2. La libreria DLL lo envia dos veces a timbrar
Con el sistema de timbrado doble PAC existe la posibilidad que la DLL envie a timbrar dos veces, esto funciona asi :
Al enviarlo a timbrar espera unos segundos, si no recibe respuesta de Ecodex o la respuesta que recibe es un error (falta de timbres, emisor no registrado, importes invalidos, etc etc) entonces hace un segundo envio al PAC de respaldo.
Si por alguna razon se envio el XML a Ecodex pero se "perdio" en el camino, entonces si cabe la posibilidad de un doble timbrado.
Pero algo muy importante, se envia *exactamente* el mismo XML a los dos PAC, el "timestamp" no debe cambiar, para nada, ni por un segundo. (me refiero al valor Fecha que esta en el encabezado, y no a la fecha de timbrado)
Y en este caso entonces tendriamos dos XML, CON LA MISMA FECHA en el encabezado, con Fecha de timbrado con diferencia de segundos y con RfcProvCertif distinto (RFC del PAC que timbro, uno de Ecodex y el otro del PAC de respaldo)


Ya agregue las líneas en el host para desactivar el PAC de Respaldo, pero es una suma muy importante de impuestos a pagar por este motivo de documentos del 2023, por lo que me están pidiendo escalarlo con personal de ECODEX, ¿tendrás el contacto para exponerles el caso directamente?

Muchas gracias

[Dado]

Los datos de Ecodex estan en el recuadro rojo/rosa hasta arriba, donde dice "ECODEX TIENE ESTOS NUEVOS DATOS DE CONTACTO"

Aver publica un par de esos XML duplicados, para darles una revisada

[jflores101292]

Te adjunto dos casos

Quedo al pendiente de tu revisión para poder contactar a ECODEX
Gracias

[Dado]

Como siempre, hay curiosidades con las horas, pero no es concluyente, solo la observacion siguiente :

En el caso 2 la hora de timbrado de Ecodex es FechaTimbrado="2023-03-07T06:57:32"
Y la del PAC de respaldo es FechaTimbrado="2023-03-07T06:52:52"

Esto es 4 minutos 40 segundos de diferencia, eso significa que no fue en la misma operacion automatica, debio haber sido en un segundo intento *manual* de timbrado, ademas de que se timbro primero con el PAC de respaldo y luego con Ecodex

[jflores101292]

Gracias por tu respuesta

Pero al tener la misma fecha de encabezado los dos XML, coincidente en HHMMss ¿no entra en el supuesto de "Pero algo muy importante, se envia *exactamente* el mismo XML a los dos PAC, el "timestamp" no debe cambiar, para nada, ni por un segundo. (me refiero al valor Fecha que esta en el encabezado, y no a la fecha de timbrado)" ?

¿Si se realiza un segundo intento manual, no debería cambiar la fecha de encabezado?