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

[trumbolt]

En su momento, con el tema del FAQ que encontré sobre el rechazo de alguna de las facturas enviadas y la posibilidad del uso de la figura de subsanación por rechazo inicial, me quedó duda y terminé escribiendo a la AEAT. Fueron muy claros. Siempre hay que usar rectificativas, así que el tema del envío de una subsanación por rechazo inicial debe de ser algo tan tan residual que no se me ocurre ningún caso normal en el que lo pueda usar en mi software.

Os pego el correo enviado y la respuesta que redactaron.

[...] y nos ha surgido una duda en el caso de los registros de facturación rechazados. Según la norma, ese registro debe de ser subsanado y vuelto a enviar y para eso estaría la figura de la subsanación por rechazo. Bien, si, por ejemplo, ese rechazo se produce porque el nif del titular de la factura estaba incorrecto (pongamos un error 1110 - Error en el bloque Destinatario.. El NIF no está identificado en el censo de la AEAT.) nos surje la siguiente duda:

En las preguntas frecuentes presentes en el portal del desarrollador encontramos lo siguiente:

Esto nos lleva a pensar que la figura del registro de subsanación por rechazo sería perfectamente usable para solventar este error 1110 pero según el reglamento de facturación (Real Decreto 1619/2012), cualquier error en la identificación del receptor de una factura debe de ser solventado con una factura rectficativa.

En resumen. En estos casos, ¿se puede usar esa subsanación por rechazo o hay que realizar una factura rectificativa? En el caso de que tengamos que realizar una rectificativa,, lógicamente tendrá una serie y numeración distinta y estará modificando una factura que teóricamente no existe en su sistema porque ha sido rechazada. ¿Esto va a funcionar?

[...]

Buenos días:

Los registros de facturación de subsanación únicamente deben utilizarse cuando sea un supuesto que el Reglamento de Obligaciones de Facturación no exija la emisión de una factura rectificativa (u otro mecanismo contemplado en dicho reglamento). Por lo cual, tal y como comenta, en el ejemplo indicado se debe proceder mediante la emisión de una factura rectificativa. Esta factura rectificativa conllevará la generación del correspondiente registro de facturación de tipo alta inicial (distinto IDFactura).

Respecto al registro inicialmente rechazado no deberá realizarse ninguna actuación posterior ya que el error quedará resuelto por la vía de la rectificación de facturas.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: verifactu@correo.aeat.es

Creo que con ésto, queda ya meridianamente claro (a los que no lo tenían ya ), que prácticamente cualquier cambio implicará la emisión de una rectificativa con su propia numeración y serie que encadenará, además, como bien se está comentando en los últimos post, con el último documento emitido, haya sido aceptado o no.

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

Empezado por trumbolt

...así que el tema del envío de una subsanación por rechazo inicial debe de ser algo tan tan residual que no se me ocurre ningún caso normal en el que lo pueda usar en mi software.

A nosotros también nos han salido muy pocos casos:

1. Envío rechazado por error en el certificado.
2. Envío rechazado por un error del software al generar el XML.
3. Envío rechazado por un error del software al rellenar un campo del XML.
4. Alguno más que ahora no recuerdo...

En estos casos la factura se rechaza, pero en si la factura es correcta como tal en el sistema, por lo tanto no tiene sentido hacer una rectificativa.
En estos casos enviamos una subsanación con RechazoPrevio=X (Con RechazoPrevio y no existe en la AEAT)

[trumbolt]

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

A nosotros también nos han salido muy pocos casos:

1. Envío rechazado por error en el certificado.
2. Envío rechazado por un error del software al generar el XML.
3. Envío rechazado por un error del software al rellenar un campo del XML.
4. Alguno más que ahora no recuerdo...

En estos casos la factura se rechaza, pero en si la factura es correcta como tal en el sistema, por lo tanto no tiene sentido hacer una rectificativa.
En estos casos enviamos una subsanación con RechazoPrevio=X (Con RechazoPrevio y no existe en la AEAT)

Ya que comentas el tema del certificado, lo único que he podido probar es uno caducado o revocado, con el que obtengo un 401. Como no ha habido ni siquiera un rechazo, entiendo que hay que volver a enviar todas las facturas como si nada hubiese pasado, lo mismo que si obtienes un soap fault, bien env:Client o env:Server.

Los únicos errores que veo podrían monitorizarse y que son causa de rechazo son el 4108 (Error técnico al obtener el certificado), 4112 (El titular del certificado debe ser Obligado Emisión, Colaborador Social, Apoderado o Sucesor) y 4132 (El titular del certificado debe ser el destinatario que realiza la consulta, un Apoderado o Sucesor). ¿Se me escapa algo más de cara a sustitutivas?

[xevi]

Sigo vuestros hilos y consigo entender bastantes cosa, pero cuesta mogollón asimilar toda la información.

En un proceso de emisión de facturas
Factura1, primer registro (sin huella anterior)
Factura2, encadenado con huella Factura1
Factura3, encadenado con huella Factura2

La Factura2 recibo respuesta error 1100, en mi SIF lo marco como error.
El encadenamiento que tengo en mi SIF no se corresponde con el de AEAT.
Por lo que me pregunto ¿su encadenamiento estará "truncado" y me pueden pedir un requerimiento???
Porque, al emitir la Factura4 seguiré encadenando con la huella Factura3 y así sucesivamente...

¿Como se "repara" ese encadenamiento en AEAT??? En este caso el error es 1100, pero puede ser otro, que no haya conexión con su servidor...
Cuando aubsane el error, debo encadenar con la huella del último registro de mi SIF, por lo que ese "truncado" de AEAT siempre va a existir.
Vaya, que si voy al portal de consultas VERI*FACTU y compruebo los registros enviados, veo la correspondencia de huellas, y claramente, hay un salto, un truncado de trazabilidad.


Vaya, no se, no lo veo nada claro!!!

[YellowStone]

Tienes que cambiar el "chip" y diferenciar entre registro de facturación y factura. A mi también me costó entenderlo al principio.

Lo que se encadenan son los registros de facturación, no las facturas.

Un registro de facturación pertenece a una única factura, pero una factura puede tener X registros de facturación, según las veces que se haya enviado hasta que te dé respuesta correcta.

Normalmente será 1 registro de facturación por factura. Tu tienes que encadenar los registros de facturación.

RF1 - Factura 1 - (sin encadenamiento). Ok.
RF2 - Factura 2 - RF1. Error
RF3 - Factura 3 - RF2. Ok.
RF4 - Mod. Factura 2 - RF3. Ok.
RF5 - Anul. Factura 1 - RF4. Ok.
RF6 - Factura 4 - RF5

etc, etc.

[xevi]

Si, si lo entiendo!!!

Pero lo que no me queda claro es ese "vacio" en la trazabilidad que tendrá AEAT respecto a las facturas que "realmente" reciban, pues habrá huellas que no seguiran la trazabilidad de Registros enviados. ¿Como podrán saber que la "trazabilidad" es "honerosa", que no hay "manipulación" de datos y que no hay "alterabilidad" entre nuestros registros de facturación y los suyos???

Ahí es donde quiero llegar. Entiendo lo que leo y veo que es de esa manera, pero no "comprendo" el tener que nosotros guardar una trazabilidad de RF cuando segun VERIFACTU, la trazabilidad no corre por nuestra cuenta, sinó que son ellos los que van a garantizar la trazabilidad, salvaguarda, custodia, etc...

Nuestra responsabilidad ¿donde finaliza con un sitema VERIFACTU???

[YellowStone]

Hombre, para poder encadenar correctamente los registros de facturación, tendrás que guardarlos en alguna tabla de tu base de datos, porque sin los datos del anterior registro de facturación no puedes encadenar el siguiente. Si tu no guardas esa trazabilidad, no veo cómo vas a poder encadenarlos.