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

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

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