VERIFACTU, criterios, dudas 10/11/2024

[FiveWiDi]

Hola a todos,

Estoy retomando el tema de VERIFACTU, y ya de entrada se me presentan dudas de criterio, a ver que opinan.

Por ejemplo.

¿Cómo tratarían Ustedes las facturas RECTIFICATIVAS (que por cierto no tengo la certeza de cómo usarlas y ni en que casos), en VERIFACTU?
¿Para estas facturas RECTIFICATIVAS, en sus registros VERIFACTU indicarían que son "Subsanaciones"? Siempre? En que casos?
¿Las facturas RECTIFICATIVAS deben tratarse en sus registros VERIFACTU como el resto de facturas?
¿Qué entienden Ustedes que son subsanaciones en VERIFACTU? Únicamente se refieren a subsanar registros VERIFACTU o tiene que ver con la naturaleza de las facturas?

Cómo ven tengo algunas dudas, y quizás estoy mezclando conceptos.

Muchas gracias,

[FiveWiDi]

Última actualización 01/11/2024

Opiniones y deducciones muy personales a la Orden Ministerial HAC/1177/2024 de 17 de octubre, publicada en el BOE el 28/10/2024.
https://www.boe.es/buscar/act.php?id=BOE-A-2024-22138

Sólo trataré aspectos que afecten a sistemas VERI*FACTU.

No trataré los aspectos que afecten a sistemas NO VERI*FACTU.
=============================================================


APARTADO I de las disposiciones Generales

1ra. Disposición de la Orden Ministerial
"...El artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, ha incorporado una nueva obligación tributaria formal, que establece que los productores, comercializadores y usuarios de los sistemas y programas informáticos o electrónicos que soporten los procesos contables, de facturación o de gestión de quienes desarrollen actividades económicas, deben garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos..."

Es decir lo que se haga debe quedar reflejado en registros consultables e inalterables. TODO lo que se haga.

2a. Disposición de la Orden Ministerial
"...La finalidad última de la disposición anterior es impedir o dificultar la fabricación, producción, importación y tenencia de sistemas y programas informáticos que permitan o faciliten la manipulación u ocultación de datos contables, de facturación o de gestión a la Administración tributaria,..."

Que es manipulación?
http://www.rae.es
RAE -->> "Manipulación" -->> "Acción y efecto de manipular".
1ra. acepción:-->> "manejo, uso, utilización, empleo, realización, ejecución, fabricación, procedimiento, proceso."
2a. acepción:-->> "adulteración, falsificación, amaño."

Tal como dice la RAE "manipulación" en esta Orden Ministerial NO se referirá al hecho de "manejo, uso, utilización, empleo, realización, ejecución, fabricación, procedimiento, proceso.", ya que la finalidad de un SIF es precisamente eso; por tanto "manipulación" en esta Orden Ministerial se referirá a "adulteración, falsificación, amaño."

(sin pensarlo mucho) -->> Dicho esto, nuestros SIF deben permitir lo que se está haciendo ahora mismo pero con la SALVEDAD de que TODO lo que se haga en las facturas DEBE comunicarse a Hacienda Publica, precisamente para evitar la "adulteración, falsificación, amaño."

3ra. Disposición de la Orden Ministerial
"...Por lo que se refiere a los sistemas informáticos de facturación, el desarrollo reglamentario...dichos sistemas con el fin de garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación."

Es decir, los usuarios no pueden tocar los registros de facturación (que no las facturas), que de manera automática genere nuestro SIF, los pueden ver (yo dejaré verlos) pero no tocarlos/modificarlos/borrarlos.

4a. Disposición de la Orden Ministerial
Inclusión del código QR y frase "VERI*FACTU"

5a. Disposición de la Orden Ministerial
Autoriza a Hacienda para que publique y/o modifique las especificaciones técnicas de los SIF.

APARTADO II de las disposiciones Generales
Explica el contenido de esta Orden Ministerial, no desarrolla nada aquí.

APARTADO III de las disposiciones Generales
Nos dice que esta Orden ministerial cumple con todos los requisitos legales y es además bonita, linda y chupiguay.

CAPÍTULO I
Disposiciones Generales

Artículo 1
Nada a destacar.

Artículo 2
El uso del SIF para VARIOS Obligados Tributarios, debe gestionar de manera TOTALMENTE INDEPENDIENTE para cada Obligado Tributario: los registros de facturación y cadenas de registros de facturación; y además DEBERÁ VISUALIZAR el NOMBRE (esto lo digo yo) del obligado tributario (así el usuario sabe en cada momento para que obligado tributario está facturando).

CAPÍTULO II
Artículo 3
Nos dice que si se trabaja en sistemas VERI*FACTU "no les serán de aplicación los artículos 6.b), 6.c), 6.d), 6.e), 6.f), 7.f), 7.h), 7.i), 7.j), 8 y 9 de esta orden."
Ole tu!!!

Artículo 4
Nos dice que nuestro SIF debe ser capaz de enviar registros de facturación y procesar la respuesta de Hacienda Pública.

Artículo 5
Nos dice que la remisión de registros debe realizarse con la identificación electrónica del REMITENTE, pudiendo ser el obligado tributario o un tercero (una gestoría?).

Artículo 6
Pues eso, que cada registro de facturación debe tener su huella.

Artículo 7
"Trazabilidad de los registros de facturación"
"a) Cada registro de facturación, de alta o de anulación, contendrá el siguiente conjunto de datos referido al registro de facturación, de alta o de anulación, inmediatamente anterior por orden cronológico de fecha de generación:"
Dice "... INMEDIATAMENTE ANTERIOR..."
Ojo, no indica si es un registro de alta o anulación o con/sin subsanación; por tanto PUEDE darse el caso de que un registro de facturación esté enlazado con uno anterior que haga referencia a la misma factura. Estoy en lo cierto? En el d) me dan la razón.

"c) Para un determinado obligado tributario, cada sistema informático producirá una única cadena de registros de facturación, es decir, todos los registros de facturación de un mismo obligado tributario generados por un mismo sistema informático deberán formar parte de la misma cadena."
Esto me puede llevar a tener un SIF que no funciona en red, pero se conecta a internet para el envío de lo que sea, que está instalado en más de 1 lugar distantes entre si y que generen facturas; por tanto deberían llevar un indicador de instalación del SIF (creo que lo contempla VERI*FACTU) para diferenciar las diferentes cadenas de registros de facturación.

"d) La cadena de registros de facturación generada contendrá tanto los registros de facturación de alta como los registros de facturación de anulación."
Autoexplicativo.

Artículo 8
No afecta instalaciones VERI*FACTU

Artículo 9
No afecta instalaciones VERI*FACTU

CAPÍTULO III
Generación registros de facturación

Artículo 10
Registro de Alta
Nos remite a las especificaciones técnicas de Hacienda.

Artículo 11
Registro de Anulación
Nos remite a las especificaciones técnicas de Hacienda.

Artículo 12
"...Cuando exista alguna autorización a que se refiere la disposición adicional primera del Real Decreto 1007/2023, de 5 de diciembre,..."
Para casos de autorización o resolución de no aplicación. No he entrado a ver a que se refiere esa disposición adicional.

Artículo 13
Respecto de la huella para los registros de facturación.
Yo:
- crearé la huella en el momento de la generación del XML y su envío; es decir no generaré el XML ni la huella si en ese momento no voy a enviar.
- guardaré la huella en un campo de la DBF de los registros de facturación; a partir de ese momento ya no se podrá modificar/borrar el registro de facturación.

Artículo 14
"Firma electrónica de los registros de facturación."
¿Me afecta?

CAPÍTULO IV
Declaración responsable

Artículo 15
"Declaración responsable de los sistemas informáticos"
Detalla como debe ser esta declaración, con datos obligatorios y otros voluntarios.

"3 La declaración responsable deberá encontrarse disponible de manera legible e individualizada dentro del propio sistema informático a que se refiere y ser accesible por el usuario de forma rápida, fácil e intuitiva. Asimismo, deberá ponerse a disposición del comercializador y del cliente, tanto en el momento de su adquisición como posteriormente,..."
Con un PDF es suficiente.
Yo pondré un PDF en el apartado "Acerca" del SIF.

CAPÍTULO V
Características de la remisión

Artículo 16
"Especificaciones técnicas de la remisión"
Se deberá respetar el tiempo de espera que A CADA respuesta de Hacienda (a nuestro envío de los XML con los registros de facturación), nos sea indicado; inicialmente 60 segundos entre envíos.

En mi caso estableceré un delay en mi SIF de 10 minutos, y así en un solo envío generaré todos los registros de facturación de las facturas (yo hago 25 facturas casi idénticas a las anteriores, 1 vez al mes).
Las anulaciones y subsanaciones serán tratadas como cualquier otro registro.

"La respuesta afirmativa por parte de la Agencia Estatal de Administración Tributaria no implica que los registros de facturación remitidos sean completamente válidos, ni impide posteriores validaciones por parte de la Agencia Estatal de Administración Tributaria."
Por tanto un Ok de Hacienda no implica que de lo enviado no tengamos futuras 'noticias'.

"4... en cuanto sea posible, respetando el orden temporal de generación de los registros de facturación...
El sistema informático deberá reintentar periódicamente, al menos una vez cada hora, el envío de los registros de facturación pendientes de remitir."

Inicialmente yo planteaba el envió de información mirando la factura, eso no es correcto, debo mirar los registros que se han generado a partir de las facturas.
De la misma manera que yo iba a guardar los XML cuando esto no es necesario; parece ser (voy pensando en voz alta) que a Hacienda la da igual el XML, le interesa su contenido (es lógico, el XML es el medio, no la información en si).
¿Por tanto puedo borrar el XML una vez enviado? Creo que si, la información de los registros, incluida huella, la tengo en la DBF creada a tal efecto.
Tendré creadas 2 DBF, una de los registros y otra de los envíos, vinculando ambas sabré que registros se enviaron en cada momento/envío, y su respuesta con el CSV (esa si que creo que mejor guardarla, al menos de momento).

Artículo 17
"Condiciones y plazos de inicio y renuncia ...."
Como mi SIF será siempre VERI*FACTU no me afecta.

CAPÍTULO VI
Remisión de registros de facturación para responder un requerimiento

Artículo 18
Nos remite a las especificaciones técnicas de Hacienda.

CAPÍTULO VII
Requisitos aplicación informática de facturación de Hacienda

Artículo 19
Respecto de la aplicación informática que desarrolle Hacienda.
No me afecta, usaré mi SIF.

CAPÍTULO VIII
Elementos adicionales

Artículo 20
"Representación gráfica a incluir en la factura"
Incluirá código QR
Incluirá literal "VERI*FACTU"

Artículo 21
"Código QR"
"Para la generación del código «QR» se empleará el nivel M (medio) de corrección de errores."
Entiendo que con FWH podemos generar este código QR, Cierto?
Nos remite a Hacienda para tamaños y ubicación en la factura.


DISPOSICIÓN ADICIONAL PRIMERA
Habilita a Hacienda Pública para publicar las especificaciones técnicas.

Fin
Chimpum

[VictorCasajuana]

Gran resumen!

Estoy de acuerdo contigo salvo en no guardar los .XML, yo de momento los generaré y guardaré en una carpeta del programa, a borrarlos siempre estoy a tiempo. Esto es "por si acaso" las especificaciones sufrirán muchos cambios y puede que los XML sufran cambios. Si hay algún problema, siempre tendré lo que realmente envié. Quizás me plantee cuando ya esté todo funcionando bien y las versiones de los requerimientos estables, el borrarlos.
Salud!

[quim]

Excelente resumen, es importante poder expresar nuestras opiniones, dudas o conclusiones ya que es un tema que como desarrolladores de programas de gestión y en este caso de facturación, nos toca de lleno

Voy a intentar expresar algunas de mis conclusiones, con el objetivo de poder ir identificando una problemática común a la que deberemos responder al adaptar nuestros sistemas

• Coincido con @VictorCasajuana en guardar tanto los XML enviados como los recibidos, para constancia, posterior tratamiento, pruebas, etc
  Para ello podemos guardar en carpetas o en campos de texto de SGBD tipo MariaDB, Sqlite o DBF memo (FPT)
  Pensar que si algun dia, estos XML deben de ir firmados, ya tenemos la infraestructura preparada para guardarlos
• Diferenciar los registros de facturacion de nuestro sistema (albaranes i/o facturas) parcialmente modificables con los registros 'inmutables' para VeriFactu (en adelante VF)
  Además la relación puede ser de 1 factura a N registros VF
• Existiran registros VF que aún teniendo relación con una unica factura, se 'auto-replican' para informar, por ejemplo, que no se han podido enviar 'en razonable tiempo real' por problemas X (red, hardware, etc) y por ello deberán de volverse a enviar, independientes de la factura
• Facturas rectificativas y facturas de abono. Es el eterno dilema de como debe responder el usuario ante las numerosas situaciones que deberá resolver y como lo vamos a resolver nosotros
  Hasta ahora lo más fácil ante un error en facturación, una devolución de mercancía, un cambio de condiciones comerciales, era realizar un abono (factura negativa) y volver o no a generar una factura correcta
  Por lo que tengo entendido, la principal diferencia entre una factura rectificativa y una de abono (corríjanme si me equivoco) es su signo, es decir, una rectificativa su signo es positivo, hace referencia a la numeración de la factura que rectifica (en algunos ERP sirve la misma numeracion) y describe brevemente lo que rectifica. En cambio, una factura de abono, en principio anula total o parcialmente una operación mercantil anterior, incluso algunos asesores fiscales que he consultado, reservan el término de 'abono' para efectivamente operaciones mercantiles a las que hay que devolver al cliente el importe pagado previamente
  Es un pequeño 'galimatías' legal con el que tendremos que lidiar y tener claro como traducirlo en programación
• En VF tenemos 3 tipos de facturas/registro a informar : Alta normal, Alta por subsanación y Anulación. En las subsanaciones/anulaciones especificando si ha existido un rechazo previo por parte de la AEAT

Creo -humildemente- que se pueden definir 4 conceptos a desarrollar :

1. Adaptar facturación ERP/SIF para producir registros VF a enviar, de forma automática y en paralelo al proceso de facturación, según anterior casuística planteada
2. XML y envio. Generar XML, gestion de certificados, envio y tratamiento de la respuesta. Puede ser XML o HTML (en este último caso cuando falla el certificado -caducidad, no admitido, etc.-)
3. Gestion de registros VF posteriores al envio automatico. Informar al usuario que debe subsanar, posiblemente desde registros VF (Fallo en la huella, encadenamiento erróneo) o desde el ERP (El NIF no existe en la AEAT, etc)
4. Algun tipo de servicio en segundo plano, programador de tareas, etc. Que revise la 'cola' de nuevos registros VF generados y atendiendo el tiempo de espera recibido por la AEAT, en una ultima comunicacion correcta, procese segun el concepto 2

Como se puede comprobar, creo que el menor de los problemas es la generacion y envio XML y el principal, toda la gestión que deben realizar nuestros sistemas

Qué opináis ?

[FiveWiDi]

• Coincido con @VictorCasajuana en guardar tanto los XML enviados como los recibidos, para constancia, posterior tratamiento, pruebas, etc
  Para ello podemos guardar en carpetas o en campos de texto de SGBD tipo MariaDB, Sqlite o DBF memo (FPT)
  Pensar que si algun dia, estos XML deben de ir firmados, ya tenemos la infraestructura preparada para guardarlos
  

Finalmente así lo haré yo también.

Diferenciar los registros de facturacion de nuestro sistema (albaranes i/o facturas) parcialmente modificables con los registros 'inmutables' para VeriFactu (en adelante VF)

Los albaranes creo que están al margen de todo este montaje.
Las facturas... Ay!!! las facturas.
En las primeras pruebas que acabo de hacer uno de los errores de respuesta de Hacienda ha sido:
Ha sido un "AceptadoConErrores"
Error:2004 -->> "El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos."
Por tanto, si esto no cambia, desde que se genera el registro de facturación hasta que se envía a Hacienda... pues eso, tenemos 120 segundos.... Pero es que he recibido un "<tikR:TiempoEsperaEnvio>60</tikR:TiempoEsperaEnvio>", por tanto mi TIMER de envío no puede superar los 60 segundos. En fin, continuo.

Además la relación puede ser de 1 factura a N registros VF

Existiran registros VF que aún teniendo relación con una unica factura, se 'auto-replican' para informar, por ejemplo, que no se han podido enviar 'en razonable tiempo real' por problemas X (red, hardware, etc) y por ello deberán de volverse a enviar, independientes de la factura

Facturas rectificativas y facturas de abono. Es el eterno dilema de como debe responder el usuario ante las numerosas situaciones que deberá resolver y como lo vamos a resolver nosotros
Hasta ahora lo más fácil ante un error en facturación, una devolución de mercancía, un cambio de condiciones comerciales, era realizar un abono (factura negativa) y volver o no a generar una factura correcta
Por lo que tengo entendido, la principal diferencia entre una factura rectificativa y una de abono (corríjanme si me equivoco) es su signo, es decir, una rectificativa su signo es positivo, hace referencia a la numeración de la factura que rectifica (en algunos ERP sirve la misma numeracion) y describe brevemente lo que rectifica. En cambio, una factura de abono, en principio anula total o parcialmente una operación mercantil anterior, incluso algunos asesores fiscales que he consultado, reservan el término de 'abono' para efectivamente operaciones mercantiles a las que hay que devolver al cliente el importe pagado previamente

En VF tenemos 3 tipos de facturas/registro a informar : Alta normal, Alta por subsanación y Anulación. En las subsanaciones/anulaciones especificando si ha existido un rechazo previo por parte de la AEAT

Creo -humildemente- que se pueden definir 4 conceptos a desarrollar :

1. Adaptar facturación ERP/SIF para producir registros VF a enviar, de forma automática y en paralelo al proceso de facturación, según anterior casuística planteada
2. XML y envio. Generar XML, gestion de certificados, envio y tratamiento de la respuesta. Puede ser XML o HTML (en este último caso cuando falla el certificado -caducidad, no admitido, etc.-)
3. Gestion de registros VF posteriores al envio automatico. Informar al usuario que debe subsanar, posiblemente desde registros VF (Fallo en la huella, encadenamiento erróneo) o desde el ERP (El NIF no existe en la AEAT, etc)
4. Algun tipo de servicio en segundo plano, programador de tareas, etc. Que revise la 'cola' de nuevos registros VF generados y atendiendo el tiempo de espera recibido por la AEAT, en una ultima comunicacion correcta, procese segun el concepto 2

Básicament coincido.

Como se puede comprobar, creo que el menor de los problemas es la generacion y envio XML y el principal, toda la gestión que deben realizar nuestros sistemas

Exacto.

[FiveWiDi]

Hola a todos,

A ver si entienden lo mismo que yo.
Al respecto de los requerimientos de Hacienda, Hacienda dice en el XLS de la estructura del XML:
"...Sólo cuando el motivo de la remisión sea para dar respuesta a un requerimiento de información previo efectuado por parte de la AEAT, se deberá indicar aquí la referencia de dicho requerimiento, lo que forma parte del detalle de las circunstancias de generación del registro de facturación..."

Dos apuntes.
Primera.
Entiendo que la remisión voluntaria y por requerimiento no pueden ir juntas en un mismo envío, ya que estos indicadores no afectan a los registros individualmente si no a todo el envío.

Segunda.
Debo entender que debo generar nuevos registros en los cuales añadir la referencia del requerimiento.
Pues yo duplicaré el registro afectado, y en el campo referencia requerimiento indicaré su valor, generaré el XML y enviaré.
OJO!! La huella de este NUEVO registro y la de su anterior, ¿Cuales deben ser? ¿Las del registro original? Entiendo que no, que debo generar nueva huella para el NUEVO registro afectado y enviar la de su INMEDIATO anterior (sea cual sea).

Esto requerirá una gestión de los registros generados con la posibilidad de lanzar un proceso que duplique el registro e indique la referencia del requerimiento.
Llegados a este punto, si estoy en lo cierto, puedo equivocarme al indicar que registro está afectado por el requerimiento y deberé permitir su borrado si ha sido error del usuario (y no se ha enviado claro).

¿Qué opinan?

[quim]

Dos apuntes.
Primera.
Entiendo que la remisión voluntaria y por requerimiento no pueden ir juntas en un mismo envío, ya que estos indicadores no afectan a los registros individualmente si no a todo el envío.

Ni van juntas ni tienen la misma URL para el WS

Segunda.
Debo entender que debo generar nuevos registros en los cuales añadir la referencia del requerimiento.

Si tu sistema es VF desde el primer dia, no vas a tener requerimiento, puesto que los datos ya estan en poder de la AEAT
Sólo en caso de que renuncies -o dejes a tu cliente esa posibilidad- que tu sistema sea VF, es decir NO VeriFactu como asi lo llaman, ante un requerimiento SI debes generar según el esquema para remitir todos los registros bajo dicho requerimiento

Por esto es importante optar por VF desde el minuto 0 y si el cliente no quiere enviar los registros a hacienda, puede buscarse otra alternativa, es así de claro como lo tengo yo

No voy a meterme en requerimientos NO VeriFactu con todo lo que conlleva, incluidas sanciones por que mi cliente quiere ocultar algo o mantiene actitudes conspiranoicas con la AEAT

Siempre pueden seguir con los bloques de comandas de los chinos o el trueque, pero conmigo que no cuenten

[FiveWiDi]

Hola a todos,

Como trataran Ustedes el rechazo TOTAL de un envío de fichero XML a VERIFACTU?

El caso es que tengo marcadas las facturas como que se han gestionado a VERIFACTU; pero deberé corregir datos (que no afectan a las facturas), generar un nuevo fichero XML y enviar de nuevo a VERIFACTU.

A tener en cuenta que tengo un "registro de ALTA" para cada factura que aunque enviado, no ha sido procesado por VERIFACTU.

La solución debe ser automática, sin (o poca) intervención del usuario.

Caso práctico:
Se genera el fichero XML indicando una firma digital que no se corresponde con el obligado tributario (el emisor) de las facturas; VERIFACTU rechaza el envío sin indicar nada al respecto de los registros enviados; rechaza el envío no los registros.

Ustedes reutilizarían los "registros de alta" ya existentes para crear un nuevo XML?
Crearían nuevos "registros de alta" marcando los enviados previamente como "rechazo fichero"?

Creo que optaré por crear de nuevo "registros de alta", pero acepto sugerencias e ideas.

Muchas gracias,

[paquitohm]

Hola FiveWidi.

Me parece que yo haría exactamente lo mismo que tu: Nuevo registro de envío y marcar el anterior como Si enviado para que ya no esté en la cola de envios.

¿ Por qué ?

Porque un registro de envio, al menos el diseño que yo concibo, tiene muchos campos: huella, csv, fecha de envio, usuario de envio, etc..
Esos campos son necesarios que estén en el nuevo envio y no los vamos a duplicar en el mismo registro de envío o incluso triplicar o incluso cuadruplicar o inscluso quintuplicar... ad eternum

Asi que mejor un nuevo registro de envio

Salu2

[FiveWiDi]

Me parece que yo haría exactamente lo mismo que tu: Nuevo registro de envío y marcar el anterior como Si enviado para que ya no esté en la cola de envios.

¿ Por qué ?

Porque un registro de envio, al menos el diseño que yo concibo, tiene muchos campos: huella, csv, fecha de envio, usuario de envio, etc..
Esos campos son necesarios que estén en el nuevo envio y no los vamos a duplicar en el mismo registro de envío o incluso triplicar o incluso cuadruplicar o inscluso quintuplicar... ad eternum

Si y no.
El caso es que en este envío no se han rechazado los registros, no se han evaluado por hacienda.
Ayer estuve haciendo pruebas; los registros del envío rechazado los marco como 'finalizados' y les agrego un error de "Error envío".
Entonces los clono con los mismas fecha/hora de generación e importes (la fecha/hora envío la aplico al momento de enviar, la huella la genero siempre antes de enviar, y no tienen csv), a estos nuevos registros los trato como cualquier otro dejándolos en cola para la nueva generación de XML y su envío.

Veré si hacienda me regaña cuando esté en real, de momento lo dejo así.

Muchas gracias,

[FiveWiDi]

Si y no.
El caso es que en este envío no se han rechazado los registros, no se han evaluado por hacienda.
Ayer estuve haciendo pruebas; los registros del envío rechazado los marco como 'finalizados' y les agrego un error de "Error envío".
Entonces los clono con los mismas fecha/hora de generación e importes (la fecha/hora envío la aplico al momento de enviar, la huella la genero siempre antes de enviar, y no tienen csv), a estos nuevos registros los trato como cualquier otro dejándolos en cola para la nueva generación de XML y su envío.

Donde digo digo, digo Diego.

Me corrijo.

Voy a reutilizar los mismos registros cuando el envío sea totalmente rechazado, y éstos no hayan sido evaluados por Hacienda.

Una de mis DBF es para guardar los datos de los envíos realizados: su identificación única, su fecha/hora de envío/recepción, etc ... Ahí indicaré que el envío ha sido rechazado y el motivo (a ser posible).

Otra de mis DBF está concebida para guardar los errores que se produzcan; utilizaré esa DBF para indicar un error que relacione el envío rechazado con cada registro enviado. Ahí estoy dejando rastro de lo que ha pasado/he hecho.

Dejaré los registros (del envío rechazado) preparados para ser incluidos en el siguiente XML, y vuelta a empezar.

Si clonaba los registros, me surgía el problema de:
De que registro anterior (en el siguiente envío) debo indicar su huella? De un registro rechazado del cual hacienda no tiene constancia?
Pues no los clono, y reutilizándolos la relación anterior-actual-siguiente se mantiene.
De hecho no se ha alterado nada en la facturación, por tanto no es justificable clonar/crear un 'registro de alta/anulación' con datos 'idénticos'.

Seguimos.

[FiveWiDi]

Venga la siguiente.

A ver. En un envío puede estar el indicador de 'Incidencia', y éste lo es a nivel de envío no de registro.

Entonces, en un envío pueden estar registros que han estado afectados por una incidencia con otros que no? Deben ir en envíos independientes?

Que opinan?

Seguimos