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

[trumbolt]

Buenas compañeros,

Tengo bastante bola con un problema que ya llegó a insinuar @ermendalenda en algún post pero que no me ha quedado muy claro. Tiene que ver con la solución a los problemas de facturas / registros de facturación rechazados tras su envío a la AEAT y la figura de "subsanación por rechazo".

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.

En esta momento y cuando el cliente pudiera, habría que solventar el problema del nif de la factura número 2A. Y aquí llega la historia y la "bola".

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.

Bien, si sigo con el hilo de pensamiento, como no se puede modificar de ninguna manera la factura 2A, la única opción es hacer otra factura que la modifique, es decir, emitir una factura rectificativa. Pongamos entonces que el cliente emite la factura 1R (en mi soft y supongo que en el de todos, las rectificativas llevan su propia serie y numeración), que modifica la factura 2A. Esta nueva factura, encadena con la última factura emitida, la 3A, llevará su propia huella e incluirá la info identificativa de la factura 2A en el nodo <FacturasRectificadas>. En este momento entonces, se está enviando una factura que informa en <FacturasRectificadas> de una factura que no existe en la AEAT. ¿Eso es correcto?

¿Algún otro concepto que se me esté escapando?

Gracias a todos.

[DemonAscun]

Es tan fácil como generar un nuevo registro de facturación para la factura 2A con el nif correcto, nadie te dice que no puedas modificar los datos asociados a la factura, te dicen que no puedes modificar el registro de factura ya generado. El nuevo registro de facturación estará encadenado con el 3A.

Empezado por trumbolt

Buenas compañeros,

Tengo bastante bola con un problema que ya llegó a insinuar @ermendalenda en algún post pero que no me ha quedado muy claro. Tiene que ver con la solución a los problemas de facturas / registros de facturación rechazados tras su envío a la AEAT y la figura de "subsanación por rechazo".

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.

En esta momento y cuando el cliente pudiera, habría que solventar el problema del nif de la factura número 2A. Y aquí llega la historia y la "bola".

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.

Bien, si sigo con el hilo de pensamiento, como no se puede modificar de ninguna manera la factura 2A, la única opción es hacer otra factura que la modifique, es decir, emitir una factura rectificativa. Pongamos entonces que el cliente emite la factura 1R (en mi soft y supongo que en el de todos, las rectificativas llevan su propia serie y numeración), que modifica la factura 2A. Esta nueva factura, encadena con la última factura emitida, la 3A, llevará su propia huella e incluirá la info identificativa de la factura 2A en el nodo <FacturasRectificadas>. En este momento entonces, se está enviando una factura que informa en <FacturasRectificadas> de una factura que no existe en la AEAT. ¿Eso es correcto?

¿Algún otro concepto que se me esté escapando?

Gracias a todos.

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

[_Io]

Empezado por trumbolt

Buenas compañeros,

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

Buenos días

En el caso que se rechacen los tres registros, el envío tambien sería rechazado y no habría CSV.
En este caso, ¿cómo quedaría el encadenamiento?, ¿qué registro sería el último eslabón? el 3A o supongamos
que antes de de este lote fallido, se emitió el registro 0A, ¿seguiría siendo el registro 0A el último eslabón?

Muchas gracias.

[Faneka]

Yo lo tengo que el último RF creado sera el encadenamiento del siguiente que se cree, independientemente de que una vez enviado este correcto o no.

[_Io]

Empezado por Faneka

Yo lo tengo que el último RF creado sera el encadenamiento del siguiente que se cree, independientemente de que una vez enviado este correcto o no.

Hola.

Yo lo tengo así, como tu, pero al leer esto:

P: Buenas tardes, si hay un problema con una factura enviada en un lote de varias facturas, porque se
rechaza, que pasa con la trazabilidad. ¿Las anteriores se enviaron y son correctas y las posteriores
también? Esa factura tiene una referencia a la anterior que no será la físicamente anterior.

R: En primer lugar, si el resto de registros de facturación enviados están bien, no se rechaza el lote completo, solamente el
marcado como rechazado. Dicho registro de facturación se debe subsanar con una nueva remisión de otro registro de
facturación (ya que no se puede alterar el erróneo). De acuerdo con el nuevo diseño de registro que se publicará en la
orden ministerial (y en la Sede electrónica de la AEAT), deberá llevar 'Tipo de registro'="Sustititivo" e indicador
SubsanaError a "S". La trazabilidad no se ve afectada porque esta va ligada a los registros de facturación según el orden
temporal de su generación, no a las facturas a las que estos referencian.

Me ha surgido la duda de se rechaza el lote completo, si verifactu ante el rechazo del bloque completo, no toma el encadenamiento del último registro de este bloque.

Es por eso la duda.

En un principio sigo con el mismo criterio que el tuyo.

Muchas gracias.

[[newtron]]

Empezado por _Io

Hola.

Yo lo tengo así, como tu, pero al leer esto:




Me ha surgido la duda de se rechaza el lote completo, si verifactu ante el rechazo del bloque completo, no toma el encadenamiento del último registro de este bloque.

Es por eso la duda.

En un principio sigo con el mismo criterio que el tuyo.

Muchas gracias.

El encadenamiento es sobre la última factura enviada sea aceptada o no.


Saludos.

[Faneka]

Entonces todo correcto,xD.