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

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

[xevi]

Hombre, eso si!!!. Tengo una tabla de RF, donde guardo el xmlsaliente, xmlrespuesta, factura, fecha, huella...
De ahí que obtengo la trazabilidad "MIA" y que 'debería' de cuadrar con la de AEAT, pero como en esa tabla voy guardando TODOS los registros, aceptados, con errores, rechazados... TODOS tienen una huella y trazabilidad, como digo "la mia"... pero como bien digo, no se va a corresponder con la de AEAT, dado que los registros "rechazados" no estan disponibles en AEAT.

No se si me explico.

[IcuScc]

Hola YellowStone..

Tu respuesta es mas que clara y al menos a mi me ha ayudado a terminar de convencerme de que lo entendía bien, porque la verdad que tambien me ha costado.
Me pregunto si esto sería correcto, entiendo que si, por si se da este caso, me apoyo en tu ejemplo.

RF1 - Factura 1 - (sin encadenamiento). Ok.
RF2 - Factura 2 - RF1. Error

Pero ahora me doy cuenta del error, subsano y mando de nuevo la factura 2, esto me genera el Registro de facturación 3 y cojo la huella del Registro anterior que curiosamente es de la misma factura.
RF3 - Factura 2 - RF2. Error

Pero como me vuelve a dar error, subsano y mando de nuevo la factura 2, esto me genera el Registro de facturación 4 y cojo la huella del registro anterior que curiosamente vuelve a ser de la misma factura.
RF4 - Factura 2 - RF3. Error. nuevamente

Sigo facturando.
RF5 - Factura 3 - RF4. Ok.

Ahora modifico el dato incorrecto de la factura 2 que había dado error y envio, esto genera el registro de facturación 6
RF6 - Mod. Factura 2 - RF5. Ok.
RF7 - Anul. Factura 1 - RF6. Ok.
RF8 - Factura 4 - RF7
...
...


Gracias a todos...