Cita:
Empezado por trumbolt
Para el ejemplo, pongamos que envío tres facturas, la 1A, 2A y 3A, en una conexión. La primera se acepta, la segunda se rechaza con un error de nif incorrecto y la tercera se acepta.
En este escenario y teniendo mentalidad TBAI, para empezar tendría un error de encadenamiento porque me faltaría la factura "a que es con la que "encadenaría" la 3A (cuando se rechaza una factura, no se guarda nada en la AEAT) pero parece que con Veri*Factu esto no es un excesivo problema.
|
Cuando tú guardas una factura se genera el RegistroDeFacturación, posteriormente esos registrosDeFacturación se envían o no dependiendo de si tienes Verifactu o no-verifactu, pero el encadenamiento se hace en el momento de generar los XML.
Al crear las factuuras 1A, 2A, y 3A se generan los 3 RegistrosDeFacturación (XML) y se van encadenando.
1A -> 2A -> 3A
Que luego la factura 2A sea rechazada, no afecta a los 3 RegistrosDeFActuración ya generados y encadenados.
Cita:
Empezado por trumbolt
Teóricamente, el software NO puede permitir la modificación de ningún registro ya emitido. Entiendo que ésto también es extensible a los rechazados por la AEAT. En tal caso, no veo la manera de poder usar la figura de envío de alta de subsanación por rechazo. Si no se permite la modificación de un registro ya guardado, ¿cómo puedo volver a enviarlo utilizando esta posibilidad?. No lo acabo de entender.
|
Eso es correcto. No se puede modificar un RegistroDeFacturación ya generado (eso es innegociable).
En este caso, para corregir ese error, deberá generarse un nuevo RegistroDeFacturación
2B y encadenarlo con el último 3A (el cómo se genere, sea con sustitutiva, sea con una nueva versión del programa,...). Y luego enviarlo o no dependiendo de si tienes verifactu o no-verifactu.
El encadenamiento quedará como:
1A -> 2A -> 3A ->2B