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

[_Io]

Perfecto

Muchas Gracias.

[bmfranky]

Hola, a todos, una cosa , los registros enviados y su encadenamiento se ha de almacenar inmutablemente en el SIF, si es erroneo, no se borra, se rectifica creando uno nuevo para la modificacion necesaria, incluso si lo anulamos no se borra ese registro , siempre se encadena con el ultimo registro creado, sea correcto o no, no confundais los registros de Alta,Baja, Modificacion, Anulacion, con las facturas a las que esos registros atañen, no son lo mismo.


Por ejemplo, tu creas 3 facturas, las envias en el mismo registro.


[Cabecera]
->Registro Alta -> Factura1 Encadena No
->Registro Alta -> Factura2 Encadena[ ->Registro Alta -> Factura1]
->Registro Alta -> Factura3 Encadena[ ->Registro Alta -> Factura2]




Me rechazan las 3 por algun motivo, resuelvo los problemas que haya que resolver.


[Cabecera]
->Registro Alta Rectificacion -> Factura1* Encadena[ ->Registro Alta -> Factura3]
->Registro Alta Rectificacion -> Factura2* Encadena[ ->Registro Alta Rectificacion -> Factura1]
->Registro Anulacion -> Factura3 Encadena[ ->Registro Alta Rectificacion -> Factura2] {El cliente no existe me confundi asi que la anulo y creo otra nueva con los datos correctos}.

->Registro Alta -> Factura4 Encadena[ ->Registro Anulacion -> Factura3]
*aqui seria una rectificativa R4, pero lo dejo asi para que se entienda el encadenamiento.



El encadenamiento es siempre al registro de facturacion anterior sea correcto o no , sea rechazado o no, siempre ha de quedar en la base de datos y ellos han de poder leerlos todos, los aceptado y los rechazados, desde una opcion en nuestro programa, e incluso poderexportarlo.

Tened en cuenta que se encadenan los registros que se crean no las facturas, una factura puede tener varios registros.

[Logan05]

Empezado por bmfranky

Hola, a todos, una cosa , los registros enviados y su encadenamiento se ha de almacenar inmutablemente en el SIF, si es erroneo, no se borra, se rectifica creando uno nuevo para la modificacion necesaria, incluso si lo anulamos no se borra ese registro , siempre se encadena con el ultimo registro creado, sea correcto o no, no confundais los registros de Alta,Baja, Modificacion, Anulacion, con las facturas a las que esos registros atañen, no son lo mismo.


Por ejemplo, tu creas 3 facturas, las envias en el mismo registro.


[Cabecera]
->Registro Alta -> Factura1 Encadena No
->Registro Alta -> Factura2 Encadena[ ->Registro Alta -> Factura1]
->Registro Alta -> Factura3 Encadena[ ->Registro Alta -> Factura2]




Me rechazan las 3 por algun motivo, resuelvo los problemas que haya que resolver.


[Cabecera]
->Registro Alta Rectificacion -> Factura1* Encadena[ ->Registro Alta -> Factura3]
->Registro Alta Rectificacion -> Factura2* Encadena[ ->Registro Alta Rectificacion -> Factura1]
->Registro Anulacion -> Factura3 Encadena[ ->Registro Alta Rectificacion -> Factura2] {El cliente no existe me confundi asi que la anulo y creo otra nueva con los datos correctos}.

->Registro Alta -> Factura4 Encadena[ ->Registro Anulacion -> Factura3]
*aqui seria una rectificativa R4, pero lo dejo asi para que se entienda el encadenamiento.



El encadenamiento es siempre al registro de facturacion anterior sea correcto o no , sea rechazado o no, siempre ha de quedar en la base de datos y ellos han de poder leerlos todos, los aceptado y los rechazados, desde una opcion en nuestro programa, e incluso poderexportarlo.

Tened en cuenta que se encadenan los registros que se crean no las facturas, una factura puede tener varios registros.

Perfectamente explicado!!

Gracias!!!

[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: [email protected]

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