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

[trumbolt]

Empezado por xevi

Yo he tomado la opción de facturar factura a factura. SOLAMENTE VERIFACTU.
Solamente mientras se procesa una factura, nadie más puede generar una nueva.
Generar y enviar el xml a hacienda ANTES de "registrar" la factura, NO imprimir, NO guardar en la base de datos y así evitar posibles encadenamientos posteriores hasta...
Recibida la respuesta de hacienda, salvo error que provoque un rechazo

********* Listado de códigos de error que producen la aceptación del registro de facturación en el sistema (posteriormente deben ser subsanados) *********
2000 = El cálculo de la huella suministrada es incorrecta.
2001 = El NIF del bloque Destinatarios no está identificado en el censo de la AEAT.
2002 = La longitud de huella del registro anterior no cumple con las especificaciones.
2003 = El contenido de la huella del registro anterior no cumple con las especificaciones.
2004 = El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de:
2005 = El campo ImporteTotal tiene un valor incorrecto para el valor de los campos BaseImponibleOimporteNoSujeto, CuotaRepercutida y CuotaRecargoEquivalencia suministrados.
2006 = El campo CuotaTotal tiene un valor incorrecto para el valor de los campos CuotaRepercutida y CuotaRecargoEquivalencia suministrados.

Salvo UNICAMENTE esos, (que quiere decir que hacienda cuenta con el registro)... SALVOGUARDO el registro e imprimo una factura generada VERIFACTU.
Libero la base de datos para que se pueda proceder al siguiente registro de facturación.

Creo entender que no he generado ninguna factura mientras no guarde el registro ni la haya impreso.

Yo no lo haría así. Como otros compañeros han apuntado, si hay algún problema con el server de la AEAT o la instalación tiene mala conexión, te quedas sin poder facturar. Precisamente ese era el planteamiento inicial de TBAI que tuvieron que cambiar de manera que el proceso de facturación de los programas fuese independiente de la notificación de los registros de facturación.

Además, si notificas el registro y luego hay algún problema para guardar ese registro en el software, generas un problema bastante más complicado de solucionar.

Yo veo más bien el tema Veri*Factu, si el software actúa sólo como VERI*FACTU, claro, como una especie de enlace en segundo plano con un programa de contabilidad, exportando los registros de facturación cada x segundos. Obviamente lleva más complicación (hay que asegurar la inalterabilidad de los registros, solucionar los rechazos, ...) pero es una base de planteamiento inicial.

[xevi]

Siempre haciendo referencia a VERIFACTU...
Igual hago algo mal, pero no creo que infrinja la ley, pues yo no emitiré factura alguna hasta que el xml enviado sea aceptado o correcto. No imprimo = no emito registo de factura.
PAra los clientes que voy a ofrecer mi sistema SIF, no va a provocar ningun impedimento a no poder generar una factura si no se puede hasta dentro de x tiempo.

El procedimiento de envio a hacienda es "paralelo" pues mientras "se verifica" los datos a registrar, yo espero respuesta, y si esa respuesta es de rechazo, no voy a registrar ni emitir factura alguna.
La ley orden ministerial no me "obliga" a que deba "permitir" facturas constantemente, independientemente de que se hayan registrado correctamente o no, sinó que, entindo yo, que puedo decidir "bloquear" la emisión de registros de facturación "mientras" no tenga el último registro validado y registrado. Se trata de un sitema de "VERIFICACIÓN" de emitir una factura.

Habrá que poder interpretar la ley no con un único sentido. Yo entiendo que no obliga a cumplir TODAS las casuisticas posibles (cosa casi imposile), sinó que tu SIF debe de cumplir con que los registros de facturas emitidas (emitidas es una vez impresa/añadida a la base de datos) si o SI, se deben de enviar a hacienda y ellos van a salvaguardar datos, trazabilidad... En eso, cuando ya tengo la respuesta de la aceptacion es cuando salvaguardo y doy permiso a emitir una nueva, sinó, esa factura no existe y hacienda no la tiene registrada.

Por contra, si eso no fuera posible, se me ocurre implemengtar el envio previo de la generación d ela factura al portal de prueba, y una vez obtenida la respuesta, si no obtengo erro, pues registrar, imprimir y enviarlo al portal "real".

Quiero evitar por todas, emitir facturas no correctas o con errores.

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

Empezado por xevi

a alguna hasta que el xml enviado sea aceptado o correcto. No imprimo = no emito registo de factura.
PAra los clientes que voy a ofrecer mi sistema SIF, no va a provocar ningun impedimento a no poder generar una factura si no se puede hasta dentro de x tiempo.

No hablamos de infringir ninguna ley, sino de que ese diseño puede provocar serias limitaciones a la hora de trabajar, pero si tu sistema o tus clientes las aceptan así, pues adelante.

Empezado por xevi

La ley orden ministerial no me "obliga" a que deba "permitir" facturas constantemente.
Habrá que poder interpretar la ley no con un único sentido.

Yo creo que ellos dicen que sea asíncrono, porque en la mayoría de sistemas no poder facturar, porque no haya conexión a Intenet no es asumible.
También porque ellos preveen, y así lo avisan, que pueden cambiar el tiempo de espera antes de enviar una factura. Si por ejemplo lo establecen a 120 sg. durante ese tiempo tampoco podrías continuar si tu sistema está diseñado de esa forma.

Otra cosa que debes tener en cuenta es, qué pasará si intentas enviar una factura antes de que pase el tiempo de espera establecido por la AEAT (por defecto 60 sg., pero que se puede ampliar).

Empezado por xevi

Por contra, si eso no fuera posible, se me ocurre implemengtar el envio previo de la generación d ela factura al portal de prueba, y una vez obtenida la respuesta, si no obtengo erro, pues registrar, imprimir y enviarlo al portal "real".

Eso tampoco te lo recomiendo, porque usar los servidores de prueba en real te puede dar problemas.
* Te tienes que preocupar del doble de problemas (caído el de pruebas o el real).
* Los Servicios de pruebas se pueden parar sin aviso o cambiar (no suele pasar con los de produccion)
* Puede ser que la versión o el funcionamiento del servicio de pruebas no sea el mismo que el real y por tanto su comportamiento

[xevi]

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

No hablamos de infringir ninguna ley, sino de que ese diseño puede provocar serias limitaciones a la hora de trabajar, pero si tu sistema o tus clientes las aceptan así, pues adelante.

Gracias por tu respuesta.

Soy un mindundi, un programador básico con unos pocos clientes (50). Solamente pretendo aguantar este cambio de normativa de facturación, no por mi, sinó porque mis clientes me lo piden y llevan años utilizando mi software.

De hecho, solamente me interesa no infringir la ley, y cubrirme de responsabilidades. Mis clientes van a tener que aceptar esa condición, si o SI, o se acogen al SII. No voy a contemplar otras opciones. Lo que no voy a poner en riesgo es mi patrimonio por querer ofrecer un servicio que pueda ocasionar errores de difícil solución o que no los pueda solucionar.
Facturas "raras", pues que utilizen otro SIF (por ejemplo el de hacienda que va a ser gratuito)
Yo no tengo porqué preveer TODAS las cauísticas posibles en unos clientes que el máximo de facturas van a ser 4 o 5 al dia. Poco a poco iré incorporando más cauísticas, seguro, pero no quiero dar por sentado a mis clientes que mi SIF va a poder cubrir todo lo que manda el reglamento. Quien no quiera, puede optar por utilizar otro programa de facturación.

Es eso o que se pasen TODOS al SII o cerrar la empresa, tambiés es una posibilidad.

[siyei]

Pues yo en tu caso, si como dices son 4 o 5 facturas al día, le pegaba una patada a los ordenadores y las emitía en papel, como se ha hecho toda la vida. De estas forma tú podrás dormir tranquilo y tus clientes no estarán obligados a cumplir con Verifactu, porque en ese caso están exentos.

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

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