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

[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.

[[newtron]]

Empezado por 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.

Tienes que tener en cuenta de que el que se la "trague" si la envías como subsanación no quiere decir que sea correcto. La ley de facturación dice claramente que no se puede hacer y yo no me la jugaría teniendo en cuenta (entre otras cosas) que estás informando al fisco de la "ñapa" con pelos y señales. Por otro lado seguramente con el tiempo irán apretando las validaciones y no te extrañe que en cualquier momento deje de "tragar" estas cosas.



Saludos.

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

Empezado por siyei

...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.

Está bien probar, pero tened en cuenta que lo que manda es la documentación.
En TicketBAI ya pasó, que para las primeras versiones "tragaban" con determinadas cosas, que con el tiempo han ido corrigiendo, y a medida que han ido saliendo versiones han ido incrementando las validaciones y las restricciones.

[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.