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

Buenas compañeros,

Tengo bastante bola con un problema que ya llegó a insinuar @ermendalenda en algún post pero que no me ha quedado muy claro. Tiene que ver con la solución a los problemas de facturas / registros de facturación rechazados tras su envío a la AEAT y la figura de "subsanación por rechazo".

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.

En este escenario y teniendo mentalidad TBAI, para empezar tendría un error de encadenamiento porque me faltaría la factura "a que es con la que "encadenaría" la 3A (cuando se rechaza una factura, no se guarda nada en la AEAT) pero parece que con Veri*Factu esto no es un excesivo problema.

En esta momento y cuando el cliente pudiera, habría que solventar el problema del nif de la factura número 2A. Y aquí llega la historia y la "bola".

Teóricamente, el software NO puede permitir la modificación de ningún registro ya emitido. Entiendo que ésto también es extensible a los rechazados por la AEAT. En tal caso, no veo la manera de poder usar la figura de envío de alta de subsanación por rechazo. Si no se permite la modificación de un registro ya guardado, ¿cómo puedo volver a enviarlo utilizando esta posibilidad?. No lo acabo de entender.

Bien, si sigo con el hilo de pensamiento, como no se puede modificar de ninguna manera la factura 2A, la única opción es hacer otra factura que la modifique, es decir, emitir una factura rectificativa. Pongamos entonces que el cliente emite la factura 1R (en mi soft y supongo que en el de todos, las rectificativas llevan su propia serie y numeración), que modifica la factura 2A. Esta nueva factura, encadena con la última factura emitida, la 3A, llevará su propia huella e incluirá la info identificativa de la factura 2A en el nodo <FacturasRectificadas>. En este momento entonces, se está enviando una factura que informa en <FacturasRectificadas> de una factura que no existe en la AEAT. ¿Eso es correcto?

¿Algún otro concepto que se me esté escapando?

Gracias a todos.

Es tan fácil como generar un nuevo registro de facturación para la factura 2A con el nif correcto, nadie te dice que no puedas modificar los datos asociados a la factura, te dicen que no puedes modificar el registro de factura ya generado. El nuevo registro de facturación estará encadenado con el 3A.

Cuando tú guardas una factura se genera el RegistroDeFacturación, posteriormente esos registrosDeFacturación se envían o no dependiendo de si tienes Verifactu o no-verifactu, pero el encadenamiento se hace en el momento de generar los XML.

Al crear las factuuras 1A, 2A, y 3A se generan los 3 RegistrosDeFacturación (XML) y se van encadenando. 1A -> 2A -> 3A
Que luego la factura 2A sea rechazada, no afecta a los 3 RegistrosDeFActuración ya generados y encadenados.


Eso es correcto. No se puede modificar un RegistroDeFacturación ya generado (eso es innegociable).
En este caso, para corregir ese error, deberá generarse un nuevo RegistroDeFacturación 2B y encadenarlo con el último 3A (el cómo se genere, sea con sustitutiva, sea con una nueva versión del programa,...). Y luego enviarlo o no dependiendo de si tienes verifactu o no-verifactu.
El encadenamiento quedará como: 1A -> 2A -> 3A ->2B

Eso está claro. El tema, o como lo he entendido, es que ese registro de facturación de sustitución por rechazo, tiene que tener el mismo numero que la factura original pero lógicamente cambiará su encadenamiento ya que ira asociada a la última factura emitida. Algo así 1A-2A (rechazada)-3A-2A(sustitutiva por rechazo). Yo no sé si esto es así o es todo una paja mental mía, sobretodo porque en mi software, un registro de facturación es el equivalente, digamos, a una "factura en papel" y no pueden existir dos "facturas en papel" con el mismo número ...

Hola Neftali, a que te refieres con "una nueva versión del programa" ?

Nosotros en ese caso teníamos pensado permitir al usuario introducir manualmente el valor correcto a subsanar y con eso generar un nuevo registro de facturación, de la misma factura.
Esa factura pasaría a tener dos registros de facturación, el de alta y el de subsanación.

Me parece haber leído algo parecido en otra parte del foro

Puede haber mas de un registro de facturación para cada factura, uno de alta, uno de anulación, ...

Digamos que puede haber varias situaciones por las que una factura puede tener 2 registros de facturación (o más) como tú dices y se pueden generar de formas distintas.
Por ejemplo, varias situaciones:

1) La que tú comentas, el usuario cambia un valor de la factura (por ejemplo una causa exenta E4 por una E6) y se genera un nuevo RegistroDeFacturación para esa factura (tendrá uno de alta y otro de subsanación).

2) El programa tiene un error y genera mal el RegistroDeFacturación. La factura F1 es correcta pero el programa ha generado mal el RegistroDeFacturación. Nosotros en ese caso tenemos previsto (una vez corregido el error en el programa), que sin cambiar/modificar la factura (porque en este caso la factura es correcta), el usuario pueda "forzar" a que se genere un nuevo registro de facturación de esa factura. Si se ha corregido el error correctamente, esa factura tendrá, al igual que antes, 2 RegistrosDeFacturación. Pero se han generado con métodos distintos.

Con el comentario de antes me refería a la segunda.

Me parece muy interesante para esos casos.

Faltaría ver como controlar esa "opción del programa", para evitar que cualquier usuario pueda ir creando nuevos registros de facturación de las facturas.
Imagino que seria una opción disponible solamente para las facturas que han sido rechazadas en el envío del último registro de facturación por ejemplo... lo estudiaremos.

Muchas gracias

Muy buenas ideas que me dan que pensar sobre cómo se podría implementar todo ésto en mi software. Entiendo, no obstante, que siempre nos estamos refiriendo a subsanaciones (bien por un primer rechazo en el alta o por algún cambio "menor", verdad? porque si hay alteraciones ya en la parte económica o fechas, creo que ya estaríamos hablando de realizar rectificativas ...

Buenas.


Aclarar un par de temas. Según creo una subsanación es la corrección de una factura rechazada por motivos que no afecten a la ley de facturación, o sea, casi ningunos. En el caso de tener que corregir algo que afecte a la ley de facturación (Nif, fecha...) hay que emitir una factura rectificativa que tendría un número de factura nuevo (porque va en otra serie) y estaría encadenada a la última factura que se haya hecho.


En la práctica creo que pocas facturas se podrán subsanar (manteniento el número) y que habrá que hacer facturas rectificativas.


Saludos.

Yo hace tiempo que como Ian Martens en su famosa anécdota de cuantos dientes tiene un camello, en lugar de perderme en "literaturas" lo que hago es probar las cosas directamente.

Por ejemplo, aunque en teoría no se puede enviar una factura con fecha anterior a la fecha actual, de momento Verifactu las acepta sin problemas (excepto anteriores a 2024).
Esto en mis programas tiene sentido porque muchas veces los clientes, cuando el fin de mes coincide en fin de semana, facturan los albaranes pendientes el lunes, pero con fecha anterior al día.

Otro tema que también he comprobado es que me permite enviar la misma factura, una vez corregida, en caso de rechazo. Es decir, en principio no hace falta generar una nueva factura, sino corregir directamente el error y volver a enviarla.

Esto que puede parecer que no tiene mayor recorrido, es clave, porque si a final de trimestre se envía una factura, pero nos damos cuenta después del envío que ha sido rechazada, por la razón que sea, si me permite enviar la misma factura entraría en dicho trimestre. En cambio, si hacemos lo que en teoría manda la documentación, habría que hacer una nueva factura de corrección pero ya no entraría en dicho trimestre.

Tienes que tener en cuenta de que el que se la "trague" si la envías como subsanación no quiere decir que sea correcto. La ley de facturación dice claramente que no se puede hacer y yo no me la jugaría teniendo en cuenta (entre otras cosas) que estás informando al fisco de la "ñapa" con pelos y señales. Por otro lado seguramente con el tiempo irán apretando las validaciones y no te extrañe que en cualquier momento deje de "tragar" estas cosas.



Saludos.

Vamos a ser serios.

Una cosa es las "ñapas" que comentas, que todo el mundo conoce y otra cosa es el funcionamiento del día de a día de una empresa.

Por ejemplo, las facturas recibidas se suelen introducir en días posteriores, cuando se reciben por email, etc, aunque esto se supone que cambiará cuando entre en vigor la factura electrónica con la cual también nos vamos a divertir.

Por ello el SII te proporciona un margen de días para transmitir dicha información a Hacienda.

Lo que no tiene sentido, "desde mi punto de vista", es que Verifactu imponga mayores restricciones que el SII.

La ley debería estar diseñada para facilitar el funcionamiento de las empresas, no para obstaculizar su desarrollo.

De hecho siempre tienes la opción de acogerte voluntariamente al SII y en ese caso no estas obligado a instalar Verifactu. Es una opción que no descarto en aquellos clientes que la entrada de Verifactu vaya a suponer un problema.

En cuanto a lo primero es una opción bastante restringida, como comentas.
En cuanto a lo segundo está en estudio, porque puede ser una factura que se ha generado mal, pero a ojos de hacienda es correcta y se ha aceptado (por ejemplo hemos enviado un E6 en lugar de un E4, por error del programa). Está aceptada, pero igualmente hay que enviar un nuevo registro una vez corregido el programa.

Si, correcto.
Hay muy pocos cambios en la factura que generen subsanación (cambios menores como dices). La mayoría de los cambios en factura generan una rectificativa.

Totalmente de acuerdo.
Lo has explicado de forma clara.

Está bien probar, pero tened en cuenta que lo que manda es la documentación.
En TicketBAI ya pasó, que para las primeras versiones "tragaban" con determinadas cosas, que con el tiempo han ido corrigiendo, y a medida que han ido saliendo versiones han ido incrementando las validaciones y las restricciones.

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 creo que no es la forma correcta. En el momento en el que "intentas" enviar una factura a VeriFactu esa factura ya existe y va a misa, no puedes decir..."uis... me he equivocado y me olvido de la factura". Seguro que VeriFactu "sabe" que has intentado enviar una factura con unas características determinadas aunque te la rechace e igual no pasa nada que igual si. Yo en particular no optaría por ese método.


Saludos.

Yo pienso igual, no es la forma correcta. "Es empezar la casa por el tejado".

Hay que pensar que puede haber problemas de internet o del mismo servidor de Hacienda, como pasó hace días, que nos impida enviar las facturas en tiempo real.

En ese caso no debes de parar de facturar, imagínate una tienda abierta al púbico.

El problema que le veo a esto es que si los servidores de la AEAT caen durante 2 horas (por decir algo) se te va a quedar el sistema parado.
Imagino que tampoco tienes procesos al estilo de facturación automática (que generen X facturas de forma seguida en poco tiempo), porque con este sistema tampoco sería viable.

Revisando las FAQ que están en el sitio de desarrolladores, he encontrado algo interesante:

No sé si estará vigente / actualizado ésto pero puedo inferir que cualquier registro rechazado (bien sea por nif incorecto o cualquier otra causa) es susceptible de ser enviado por subsanación indicando que es subsanación por rechazo. Entiendo que hacen diferencia entre, por ejemplo, haber emitido un registro de facturación con un nif correcto pero "equivocado" y tener que modificarlo (lo que acarrea una rectificativa según se especifica en el reglamento de facturación) a que el registro de facturación ha sido rechazado porque tiene un nif inválido y que se puede solucionar con una sustitutiva y no haría falta una rectificativa.

¿Alguien ha preguntado ésto a la AEAT? ¿Cómo lo veis?

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.

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.

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.

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

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

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.

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. :):)

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.

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:


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.

Entonces todo correcto,xD.

Perfecto ^\||/

Muchas Gracias.

Encadenamiento
 

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

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.


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.

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?

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

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.

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

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.