Cómo solventar el error de una factura rechazada y subsanación por rechazo

[Neftali [Germán.Estévez]]

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.

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

[trumbolt]

Empezado por Neftali [Germán.Estévez]

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.


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

Eso está claro. El tema, o como lo he entendido, es que ese registro de facturación de sustitución por rechazo, tiene que tener el mismo numero que la factura original pero lógicamente cambiará su encadenamiento ya que ira asociada a la última factura emitida. Algo así 1A-2A (rechazada)-3A-2A(sustitutiva por rechazo). Yo no sé si esto es así o es todo una paja mental mía, sobretodo porque en mi software, un registro de facturación es el equivalente, digamos, a una "factura en papel" y no pueden existir dos "facturas en papel" con el mismo número ...

[rci]

Empezado por Neftali [Germán.Estévez]

el cómo se genere, sea con sustitutiva, sea con una nueva versión del programa,...)

Hola Neftali, a que te refieres con "una nueva versión del programa" ?

Nosotros en ese caso teníamos pensado permitir al usuario introducir manualmente el valor correcto a subsanar y con eso generar un nuevo registro de facturación, de la misma factura.
Esa factura pasaría a tener dos registros de facturación, el de alta y el de subsanación.

Me parece haber leído algo parecido en otra parte del foro

Empezado por trumbolt

en mi software, un registro de facturación es el equivalente, digamos, a una "factura en papel" y no pueden existir dos "facturas en papel" con el mismo número ...

Puede haber mas de un registro de facturación para cada factura, uno de alta, uno de anulación, ...

[Neftali [Germán.Estévez]]

Empezado por rci

...a que te refieres con "una nueva versión del programa" ?
Nosotros en ese caso teníamos pensado permitir al usuario introducir manualmente el valor correcto a subsanar y con eso generar un nuevo registro de facturación, de la misma factura.
Esa factura pasaría a tener dos registros de facturación, el de alta y el de subsanación.

Digamos que puede haber varias situaciones por las que una factura puede tener 2 registros de facturación (o más) como tú dices y se pueden generar de formas distintas.
Por ejemplo, varias situaciones:

1) La que tú comentas, el usuario cambia un valor de la factura (por ejemplo una causa exenta E4 por una E6) y se genera un nuevo RegistroDeFacturación para esa factura (tendrá uno de alta y otro de subsanación).

2) El programa tiene un error y genera mal el RegistroDeFacturación. La factura F1 es correcta pero el programa ha generado mal el RegistroDeFacturación. Nosotros en ese caso tenemos previsto (una vez corregido el error en el programa), que sin cambiar/modificar la factura (porque en este caso la factura es correcta), el usuario pueda "forzar" a que se genere un nuevo registro de facturación de esa factura. Si se ha corregido el error correctamente, esa factura tendrá, al igual que antes, 2 RegistrosDeFacturación. Pero se han generado con métodos distintos.

Con el comentario de antes me refería a la segunda.

[rci]

Empezado por Neftali [Germán.Estévez]

Nosotros en ese caso tenemos previsto (una vez corregido el error en el programa), que sin cambiar/modificar la factura (porque en este caso la factura es correcta), el usuario pueda "forzar" a que se genere un nuevo registro de facturación de esa factura.

Me parece muy interesante para esos casos.

Faltaría ver como controlar esa "opción del programa", para evitar que cualquier usuario pueda ir creando nuevos registros de facturación de las facturas.
Imagino que seria una opción disponible solamente para las facturas que han sido rechazadas en el envío del último registro de facturación por ejemplo... lo estudiaremos.

Muchas gracias

[trumbolt]

Empezado por rci

Me parece muy interesante para esos casos.

Faltaría ver como controlar esa "opción del programa", para evitar que cualquier usuario pueda ir creando nuevos registros de facturación de las facturas.
Imagino que seria una opción disponible solamente para las facturas que han sido rechazadas en el envío del último registro de facturación por ejemplo... lo estudiaremos.

Muchas gracias

Muy buenas ideas que me dan que pensar sobre cómo se podría implementar todo ésto en mi software. Entiendo, no obstante, que siempre nos estamos refiriendo a subsanaciones (bien por un primer rechazo en el alta o por algún cambio "menor", verdad? porque si hay alteraciones ya en la parte económica o fechas, creo que ya estaríamos hablando de realizar rectificativas ...

[[newtron]]

Buenas.


Aclarar un par de temas. Según creo una subsanación es la corrección de una factura rechazada por motivos que no afecten a la ley de facturación, o sea, casi ningunos. En el caso de tener que corregir algo que afecte a la ley de facturación (Nif, fecha...) hay que emitir una factura rectificativa que tendría un número de factura nuevo (porque va en otra serie) y estaría encadenada a la última factura que se haya hecho.


En la práctica creo que pocas facturas se podrán subsanar (manteniento el número) y que habrá que hacer facturas rectificativas.


Saludos.

[siyei]

Yo hace tiempo que como Ian Martens en su famosa anécdota de cuantos dientes tiene un camello, en lugar de perderme en "literaturas" lo que hago es probar las cosas directamente.

Por ejemplo, aunque en teoría no se puede enviar una factura con fecha anterior a la fecha actual, de momento Verifactu las acepta sin problemas (excepto anteriores a 2024).
Esto en mis programas tiene sentido porque muchas veces los clientes, cuando el fin de mes coincide en fin de semana, facturan los albaranes pendientes el lunes, pero con fecha anterior al día.

Otro tema que también he comprobado es que me permite enviar la misma factura, una vez corregida, en caso de rechazo. Es decir, en principio no hace falta generar una nueva factura, sino corregir directamente el error y volver a enviarla.

Esto que puede parecer que no tiene mayor recorrido, es clave, porque si a final de trimestre se envía una factura, pero nos damos cuenta después del envío que ha sido rechazada, por la razón que sea, si me permite enviar la misma factura entraría en dicho trimestre. En cambio, si hacemos lo que en teoría manda la documentación, habría que hacer una nueva factura de corrección pero ya no entraría en dicho trimestre.

[Neftali [Germán.Estévez]]

Empezado por newtron

Aclarar un par de temas.

Según creo una subsanación es la corrección de una factura rechazada por motivos que no afecten a la ley de facturación, o sea, casi ningunos.

En el caso de tener que corregir algo que afecte a la ley de facturación (Nif, fecha...) hay que emitir una factura rectificativa que tendría un número de factura nuevo (porque va en otra serie) y estaría encadenada a la última factura que se haya hecho.

En la práctica creo que pocas facturas se podrán subsanar (manteniento el número) y que habrá que hacer facturas rectificativas.

Totalmente de acuerdo.
Lo has explicado de forma clara.

[Neftali [Germán.Estévez]]

Empezado por rci

Faltaría ver como controlar esa "opción del programa", para evitar que cualquier usuario pueda ir creando nuevos registros de facturación de las facturas.
Imagino que seria una opción disponible solamente para las facturas que han sido rechazadas en el envío del último registro de facturación por ejemplo... lo estudiaremos.

En cuanto a lo primero es una opción bastante restringida, como comentas.
En cuanto a lo segundo está en estudio, porque puede ser una factura que se ha generado mal, pero a ojos de hacienda es correcta y se ha aceptado (por ejemplo hemos enviado un E6 en lugar de un E4, por error del programa). Está aceptada, pero igualmente hay que enviar un nuevo registro una vez corregido el programa.

Empezado por trumbolt

Entiendo, no obstante, que siempre nos estamos refiriendo a subsanaciones (bien por un primer rechazo en el alta o por algún cambio "menor", verdad? porque si hay alteraciones ya en la parte económica o fechas, creo que ya estaríamos hablando de realizar rectificativas ...

Si, correcto.
Hay muy pocos cambios en la factura que generen subsanación (cambios menores como dices). La mayoría de los cambios en factura generan una rectificativa.