Problema con RF mal generado (por error en software) e impide los envíos

[espinete]

El XML original estaba mal firmado. El XML nuevo (modificado) estaba correcto (importe, IVA, etc.). Y ese fue el que se envió.

El problema es la Huella, que ya no coincidía porque el XML fue retocado a mano.

Está claro que no es lo correcto, pero es la primera vez y estábamos bajo la presión de hacerlo cuanto antes por el cliente. Obviamente lo ideal es hacerlo de otra manera.

- No podemos modificar la factura original porque el software no lo permite.
- No podemos subsanar o rectificar porque el software sigue intentando enviar el XML defectuoso y dando error constantemente, evitando los envíos siguientes acumulados
- Lo suyo hubiera sido regenerar el XML completo desde cero, para que la huella coincidiera, pero tal cual está hecho el software ahora mismo, no nos fue posible
- Se enviaron todas como 'Incidencia'

[Carlos]

Empezado por espinete

El XML original estaba mal firmado. El XML nuevo (modificado) estaba correcto (importe, IVA, etc.). Y ese fue el que se envió.

El problema es la Huella, que ya no coincidía porque el XML fue retocado a mano.

Está claro que no es lo correcto, pero es la primera vez y estábamos bajo la presión de hacerlo cuanto antes por el cliente. Obviamente lo ideal es hacerlo de otra manera.

- No podemos modificar la factura original porque el software no lo permite.
- No podemos subsanar o rectificar porque el software sigue intentando enviar el XML defectuoso y dando error constantemente, evitando los envíos siguientes acumulados
- Lo suyo hubiera sido regenerar el XML completo desde cero, para que la huella coincidiera, pero tal cual está hecho el software ahora mismo, no nos fue posible
- Se enviaron todas como 'Incidencia'

En el software que utilizo los datos para crear el RF están en la factura (no los tengo duplicados), y valido antes que tenga 'detalle'. Si no hay detalle la marca con error, no se incluye en el envío, y el usuario deberá desde el SIF anular la factura (no la tendrá impresa correctamente por que le falta el 'detalle' y se generará un RF de anulación sin registro previo) y que vuelva a emitir nueva factura ya correctamente.

Saludos,
Carlos G.

[sglorka]

Cuando ser recibe un error al enviar un bloque de RF's y no sabes cúal produjo el problema tu algoritmo debe reintentar el envío de esos RF's de uno en uno, marcando entonces el que está mal como rechazado y no volverlo a envíar. De esta forma, podrás enviar el resto del bloque sin problemas. Luego en el Visor de REF's que tengas donde se relacionan todos los RF's enviados junto con su estado, enviado o rechazado, generas una susbsanación sin registro previo, del registro rechazado. Esta subsanación se hace "ah doc" corrigiendo el error y volviendo a enviar el registro.
Yo tengo un desplegable que me permite generar subsanaciones específicas debido a todas las circunstancias que me han ocurrido hasta ahora.
Ni de pensamiento, debes tocar el RF mal construido, ahí se queda para la eternidad.
La próxima vez que toque comunicar el algortimo enviará siempre primero el bloque entero y conmutará a individual cuando se produzca rechazo

[novatico]

Cuando envías un bloque de facturas, en la respuesta que se obtiene, se detalla por cada factura, cual es "Correcta", cual "Incorrecta" y cual "AceptadaConErrores", por lo que sólo hace falta gestionar las que no son "Correctas."·

[sglorka]

Estamos hablando de un rechazo total del bloque por una mala construcción de alguno de sus RF's. En este caso nunca hay respuesta del servidor indicando qué Rf está mal, simplemente rechaza todo el bloque si detallar nada. Por eso no queda otra que enviar uno a uno

[Carlos]

Empezado por sglorka

Estamos hablando de un rechazo total del bloque por una mala construcción de alguno de sus RF's. En este caso nunca hay respuesta del servidor indicando qué Rf está mal, simplemente rechaza todo el bloque si detallar nada. Por eso no queda otra que enviar uno a uno

Gracias.
Debo modificar mi software para que automatice este tipo de gestión.
En el 2035 aún estaremos puliendo detalles.

[razorxxx]

Yo lo que hice fue implementar la validación de errores de VeriFactu en un programa intermedio. Si pasa la validación, la función genera el RF y devuelve OK para que el programa de facturación pueda marcar la factura como finalizada. Por lo tanto, nunca se puede dar el caso de que una factura en blanco se marque como finalizada.

Las facturas no finalizadas las considero pre-facturas o borradores, y puede darse el caso que la factura de número 10 se finalizó antes que la número 9 por aquello de trabajar en paralelo o aparcar tickets, porque a fin de cuentas lo que el sistema quiere es que los RF se generen por orden de generación de facturas (este comportamiento es algo que me confirmaron por mail hace un año los de VeriFactu y es totalmente válido).

Esto significa que se intercalarán facturas de distintas series, e incluso de distintos ejercicios, pero los RF van siempre en orden de fecha de emisión.