Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Registros de Facturacion y Eventos (XML) (https://www.clubdelphi.com/foros/forumdisplay.php?f=67)
-   -   Duda encadenamiento facturas rechazadas o parcialmente aceptadas (https://www.clubdelphi.com/foros/showthread.php?t=97527)

richidemola 13-06-2025 09:04:11

Duda encadenamiento facturas rechazadas o parcialmente aceptadas
 
Buenos días tengo una duda sobre como encadenar facturas que han sido completamente rechazadas o parcialmente aceptadas, pongo ejemplos a ver si me podéis sacar de dudas.

Caso 1: Factura parcialmente aceptada pero con errores, en este caso si corrijo los errores y la vuelvo a enviar me da error 3000 de factura duplicada por lo que tengo que enviarla con el campo Subsanacion = S para que me la acepte, hasta ahí todo bien, la duda que tengo es con que factura debo encadenar ese nuevo envío, ¿debo encadenarla con la factura inmediatamente anterior o con la última factura generada aceptada por completo?

Caso 2: Factura totalmente rechazada, en este caso al corregir los errores y volver a enviarla me la acepta sin problemas, no da error de factura duplicada, la duda es con que factura debo encadenar ese nuevo envío, ¿con la factura inmediatamente anterior o con la última factura generada aceptada por completo?

Caso 3: Factura aceptada por completo pero la factura inmediatamente anterior fue totalmente rechazada, en este caso ¿esta factura debe ir encadenada con la factura anterior que fue rechazada o con la última factura aceptada correctamente?

Caso 4: Similar al anterior, factura aceptada por completo pero la factura inmediatamente anterior fue parcialmente aceptada, en este caso ¿esta factura debe ir encadenada con la factura anterior que fue parcialmente aceptada o con la última factura aceptada correctamente?

Eso es todo, gracias por comentar.

gcqZW 13-06-2025 09:09:02

Caso 1: la factura inmediatamente anterior.

Caso 2: la factura inmediatamente anterior.

Caso 3: la factura anterior que fue rechazada.

Caso 4: la factura anterior que fue parcialmente aceptada.

richidemola 13-06-2025 09:56:54

Genial, muchas gracias, todo mucho más claro.

Ahora me ha surgido otra duda, cuando vuelvo a enviar esas facturas que fueron parcialmente aceptadas o rechazadas, una vez corregidas, para generar el encadenamiento debo usar el mismo FechaHoraHusoGenRegistro que usé la primera vez que envié la factura o debo generar un FechaHoraHusoGenRegistro nuevo? Porque estoy viendo que si genero un nuevo FechaHoraHusoGenRegistro en el segundo envío de una misma factura para subsanarla entonces el hash es distinto a la primera vez que lo mande ...

Saludos y gracias.

gcqZW 13-06-2025 10:21:50

Tienes que generarlo nuevo, piensa que si subsanas un RF, es otro envío aunque sea una modificación de la factura por lo que puedes generarlo justo inmediatamente después de que te venga la respuesta de aceptado con errores o dentro de una semana (o cuando sea), por lo que tienes que generarlo nuevo sino te dará error.

richidemola 13-06-2025 10:49:29

Correcto, acabo de probar a reenviar el registro con el hash original y me ha dado error, si genero el hash nuevamente con el nuevo huso horario me acepta la factura, ahora la duda es, la siguiente factura que envíe tras subsanar la anterior si debe llevar el hash del primer envío o del segundo. En principio he probado a usar el hash del primer envío para encadenar la siguiente factura y me lo ha aceptado, pero no se si es correcto, es decir:

Envío factura con errores y es parcialmente aceptada, tiene un hash en ese primer envío, corrijo los errores y la vuelvo a enviar generando un hash nuevo porque el uso horario ha cambiado, el sistema me acepta por completo la factura reenviada, la siguiente factura la encadeno con el primer hash de la factura anterior en lugar de encadernarla con el segundo hash que se generó al reenviarla, en este caso me lo ha aceptado y lo que no tengo claro si es así o debía de haberla encadenado con el segundo hash que generé, el del segundo envío de la misma factura.

[EDITO] Si en lugar de encadenar con el hash del primer envío lo encadeno con el hash del segundo envío también me la acepta, no se cual es la opción válida la verdad.

Gracias.

Jarogo08 13-06-2025 10:53:21

SIEMPRE que crees un registro de facturación debe ir encadenado con el último que hayas creado.

Da igual si el último es de la misma factura, de otra, si es subsanación, si es anulación, si fue correcto, si fue incorrecto, si aún no lo enviaste, si ....

SIEMPRE encadenas con el último

richidemola 13-06-2025 10:58:59

Entonces lo que dice gcqZW no es válido no? Porque según me dice más arriba, cuando reenvias una factura que ha sido rechazada o parcialmente aceptada hay que encadenarla con la factura anterior a esta y tu me estás diciendo que no, que hay que encadenarla con la última factura enviada, a ver si me lo podéis aclarar porque me estoy liando.

Gracias.

gcqZW 13-06-2025 11:11:13

A lo mejor no me he expresado bien, pero es lo que dice jarogo, siempre encadenas con el ultimo RF creado, a eso me refería con la factura anterior, no que encadenes con la factura de la serie justo anterior.

richidemola 13-06-2025 11:14:01

Pues ya está, aclarado entonces, aunque había programado lo necesario para hacerlo como te había entendido a ti, pero no pasa nada, jajaja

Muchas gracias !!!

richidemola 13-06-2025 11:28:02

Pues casi lo tengo, me falta resolver esto:

Genero factura con errores, puede ser rechazada o parcialmente aceptada da igual, esa factura la enviarla tiene el hash 648b76f384396f63f36b23e68476f999cf324a5aad00b18e0823695260d7c281, corrijo la factura y la vuelvo a enviar, en este caso genero un nuevo hash que es A744AE16B0CA7FFE198FC8F7F5F38B31D8A8914F7392C3604A270F0D7109A018, la pregunta es: ¿la siguiente factura que envíe debe encandenarse con el primer hash o el segundo? Entiendo por lo que me habéis dicho que debo encadenarla con el segundo, ¿correcto?

Gracias.

Jarogo08 13-06-2025 11:32:23

Cita:

Empezado por richidemola (Mensaje 565467)
tu me estás diciendo que no, que hay que encadenarla con la última factura enviada


No sé donde leiste eso en mi respuesta :confused:

te lo vuelvo a poner:


SIEMPRE que crees un registro de facturación debe ir encadenado con el último que hayas creado.

Da igual si el último es de la misma factura, de otra, si es subsanación, si es anulación, si fue correcto, si fue incorrecto, si aún no lo enviaste, si ....

SIEMPRE encadenas con el último

Jarogo08 13-06-2025 11:34:53

Cita:

Empezado por richidemola (Mensaje 565471)
la pregunta es: ¿la siguiente factura que envíe debe encandenarse con el primer hash o el segundo? Entiendo por lo que me habéis dicho que debo encadenarla con el segundo, ¿correcto?

Gracias.


Si quieres vuelvo a poner otra vez la respuesta :D

CON EL ÚLTIMO QUE HAYAS GENERADO !!!!!!!!!!!!

richidemola 13-06-2025 11:35:22

Si perdona, a lo mejor no me expresé bien, ya me lo aclaró el compañero.

Saludos.

richidemola 13-06-2025 11:42:06

Otra duda, lo siento en el alma la verdad, es la última lo prometo.

Envío factura y es rechazada o aceptada con errores, al volver a enviarla genero un nuevo hash para ese segundo envío y resulta que la última factura que envié era esa misma factura por lo que la duda es si debo encadenarla con el hash anterior de esa misma factura, porque casualmente la última factura enviada es la misma que estoy reenviando o tengo que usar el hash de la última factura enviada anterior a esa?

gcqZW 13-06-2025 11:50:44

Siempre la ultima que hayas generado, un pequeño apunto respecto al caso planteado por jarogo
Cita:

si aún no lo enviaste
En este caso (véase no la has enviado por problemas técnicos) la encadenas con la anterior si aun no la has enviado, pero al volver a enviar a la AEAT tendrás que respetar ese orden para el envío (no podrás mandarlas en orden inverso por ejemplo, sino se te descuadra el encadenamiento), por ejemplo:

genero F1 y envío
genero F2 (encadenada a F1) y no puedo enviar por x problema
genero F3 (encadenada a F2) sigo sin poder
genero F4 (encadenada a F3) sigo sin poder
genero F5 (encadenada a F4) sigo sin poder
me doy cuenta que ya puedo
envío F2, F3, F4, F5 en bloque -> correcto
envío F2, F3, F4, F5 por separado -> correcto aunque no tiene mucho sentido ya que te dará error 2004
envío F5, F4, F3, F2 en bloque -> incorrecto ya que al crear los RF encadené al revés


edit: de todas formas si sigues teniendo dudas echale un ojo a los post de control de flujo que hay varios que lo explican todo genial y con toda la casuística posible.

richidemola 13-06-2025 11:56:16

Vamos que siempre la encadeno con el hash de la última factura enviada aunque de la casualidad de que es la misma factura que la estoy reenviando por que era errónea, con el nuevo envío se genera un nuevo hash que debo asociar a ese registro, cambiando el hash anterior del envío erroneo, para que pueda ser usado en el encadenamiento de la siguiente factura el nuevo hash.

Todo aclarado, muchas gracias.

Jarogo08 13-06-2025 12:12:31

Cita:

Empezado por richidemola (Mensaje 565477)
Vamos que siempre la encadeno con el hash de la última factura enviada aunque de la casualidad de que es la misma factura que la estoy reenviando por que era errónea, con el nuevo envío se genera un nuevo hash que debo asociar a ese registro, cambiando el hash anterior del envío erroneo, para que pueda ser usado en el encadenamiento de la siguiente factura el nuevo hash.

Todo aclarado, muchas gracias.



Madre mía... vaya lío tienes!


Cita:

Vamos que siempre la encadeno con el hash de la última factura enviada

vuelvo a insistir... no es con la última enviada, es con la última creada!!!!!


Cita:

con el nuevo envío se genera un nuevo hash que debo asociar a ese registro

el hash lo generas antes de enviar: creas el registro de facturación y le asignas el hash. Y luego ya haces el envío cuando sea


Aunque estés una semana sin enviar (porque no tienes internet por ejemplo) deberías poder crear registros de facturación con su hash y encadenándolos como toque (efectivamente... con el último generado ;))

richidemola 13-06-2025 12:31:46

A ver, es que yo no genero el hash cuando se crea la factura, yo las facturas que se crean las almaceno en una base de datos y las marco como NO enviadas, luego hay un demonio que obtiene todas las facturas pendientes de enviar en orden de creación, por cada factura sin enviar encontrada obtengo el hash y los datos de la última factura de la base de datos que se envió, ya sea correcta, incorrecta o parcialmente correcta, entonces genero el hash de la factura que voy a enviar encadenandola con la última que se envió y la envío, luego asocio el hash que se ha generado a la factura que acabo de enviar y la marco como enviada si no ha dado error, si ha dado error no se marca como enviada para que pueda volver a enviarse una vez corregida y cuando se vuelve a enviar el hash y los datos de factura que se obtienen son las de la última que se envió, y así sucesivamente, no genero un nuevo registro de factura cuando una factura es rechazada, simplemente actualizo su hash con el que le corresponda en función de la última factura que se envió que coincide con el último hash generado y enviado, yo creo que mi sistema vale también porque cada factura se encadenan siempre con la última factura generada, aunque sea el reenvio de una factura que tenía errores.

Por que si no vale me toca generar el hash al crear la factura usando el hash de la última factura que se generó para el encadenamiento, que tampoco es un problema pero me toca la moral modificar todos los archivos donde se generan facturas.

bmfranky 13-06-2025 12:48:18

Acerca del encadenamiento...
 
Hola, el encadenamiento es mas sencillo de lo que os complicáis , en general, os pongo un mini FAQ al respecto.


1 -> Como he de encadenar?, La operativa es , crear una lista o tabla o lo que queráis de encadenamientos y registros, Se crea un registro, para encadenar se consulta el ultimo almacenado, se crea este
encadenamiento y se encola al final de la lista, se envía y si hay algún error , lo subsano, anulo, modifico, creo otro..., Pues se crea un nuevo registro y se consulta la cola de la
lista para saber los datos a usar, y a jugar.



2 ->Que fecha hora uso?, Estas creando uno registro nuevo siempre , así que la que obtienes en el momento.


3 ->Con que factura encolo?, *Con ninguna, con los datos del ultimo registro creado, sea de lo que sea y de cuando sea, puedes estar rectificando una factura de hace tres meses, y
has de crear el registro hoy.


4 -> Si no envío, que fecha hora uso? ,La creación del hash, el Qr, y el registro de alta, baja y demás es el mismo, ahora, el envío puede ser en el momento, mas tarde o **nunca,
pero se encola en el momento de crear la factura, abono, modificación....


5 -> El registro anterior fue rechazado, he de usarlo para crear el nuevo?, Si, has de crearlo usando los datos de la cola de encadenamientos, se lo haya tragado o no, tu has de
guardar tanto el hash encolado como el registro creado y rechazado, modificar lo que sea necesario y crear un nuevo registro para comunicar los cambios a la aeat, con las
opciones necesarias para ello, pero siempre guardando los datos anteriores, una vez creados no pueden desaparecer ni ser alterados.




* Recordad que los registros, pueden ser de alta, baja , modificación y anulación...


**En los no Veri*Factu, se han de encolar los registros y guardarlos, pero no enviarlos si no se los requieren.


Espero que os quede algo mas claro.

bmfranky 13-06-2025 12:50:23

Cita:

Empezado por richidemola (Mensaje 565479)
A ver, es que yo no genero el hash cuando se crea la factura, yo las facturas que se crean las almaceno en una base de datos y las marco como NO enviadas, luego hay un demonio que obtiene todas las facturas pendientes de enviar en orden de creación, por cada factura sin enviar encontrada obtengo el hash y los datos de la última factura de la base de datos que se envió, ya sea correcta, incorrecta o parcialmente correcta, entonces genero el hash de la factura que voy a enviar encadenandola con la última que se envió y la envío, luego asocio el hash que se ha generado a la factura que acabo de enviar y la marco como enviada si no ha dado error, si ha dado error no se marca como enviada para que pueda volver a enviarse una vez corregida y cuando se vuelve a enviar el hash y los datos de factura que se obtienen son las de la última que se envió, y así sucesivamente, no genero un nuevo registro de factura cuando una factura es rechazada, simplemente actualizo su hash con el que le corresponda en función de la última factura que se envió que coincide con el último hash generado y enviado, yo creo que mi sistema vale también porque cada factura se encadenan siempre con la última factura generada, aunque sea el reenvio de una factura que tenía errores.

Por que si no vale me toca generar el hash al crear la factura usando el hash de la última factura que se generó para el encadenamiento, que tampoco es un problema pero me toca la moral modificar todos los archivos donde se generan facturas.


Hola, eso es incorrecto, lo respondo un poco mas arriba, el momento de generar el HASH, QR y registro es el de generar la factura, total mente independiente del momento de envío/impresión de la factura.
Siempre, has de crear y conservar los registros de facturación/ facturas sin modificarlos, si has de crear uno nuevo , los has de hacer y encolar independientemente de los rechazos, parciales o totales, eso es impepinable.

Jarogo08 13-06-2025 13:19:39

Cita:

Empezado por richidemola (Mensaje 565479)
A ver, es que yo no genero el hash cuando se crea la factura, yo las facturas que se crean las almaceno en una base de datos y las marco como NO enviadas, luego hay un demonio que obtiene todas las facturas pendientes de enviar en orden de creación, por cada factura sin enviar encontrada obtengo el hash y los datos de la última factura de la base de datos que se envió, ya sea correcta, incorrecta o parcialmente correcta, entonces genero el hash de la factura que voy a enviar encadenandola con la última que se envió y la envío, luego asocio el hash que se ha generado a la factura que acabo de enviar y la marco como enviada si no ha dado error, si ha dado error no se marca como enviada para que pueda volver a enviarse una vez corregida y cuando se vuelve a enviar el hash y los datos de factura que se obtienen son las de la última que se envió, y así sucesivamente, no genero un nuevo registro de factura cuando una factura es rechazada, simplemente actualizo su hash con el que le corresponda en función de la última factura que se envió que coincide con el último hash generado y enviado, yo creo que mi sistema vale también porque cada factura se encadenan siempre con la última factura generada, aunque sea el reenvio de una factura que tenía errores.

Por que si no vale me toca generar el hash al crear la factura usando el hash de la última factura que se generó para el encadenamiento, que tampoco es un problema pero me toca la moral modificar todos los archivos donde se generan facturas.


Pues lo estás haciendo mal...

-El hash se genera en el momento de la creación, no sirve que lo haga el demonio en el momento que va a enviar.


Cita:

no genero un nuevo registro de factura cuando una factura es rechazada, simplemente actualizo su hash
-Esto es incorrectísimo! estás rompiendo la trazabilidad del encadenamiento. Una factura puede tener 10 registros de facturación y tienes que guardarlos todos, no puedes sobrescribir

Galahad 15-06-2025 22:02:40

Pregunta sobre momento de crear registro
 
Veo que se ha comentado que hay que crear el registro de facturación en el momento en que se crea la factura.
Nosotros creamos el registro y su hash cuando se emite la factura al cliente, ya sea por correo,impresora ftp,etc. Entendemos que mientras no se emite la factura al cliente se puede modificar ,anular,etc..
una vez emitida , la factura se envía y se bloquea para bloquear borrados y controlar modificaciones de la misma.
¿ Este enfoque no es correcto¿?.
No pasa nada sinpor ejemplo creo 40 facturas por la mañana y las mando por la tarde?. Entendíamos la 'emision' como el momento de creación del registro de facturación. ????

Neftali [Germán.Estévez] 16-06-2025 08:45:24

Cita:

Empezado por Galahad (Mensaje 565513)
Veo que se ha comentado que hay que crear el registro de facturación en el momento en que se crea la factura.
Nosotros creamos el registro y su hash cuando se emite la factura al cliente, ya sea por correo,impresora ftp,etc. Entendemos que mientras no se emite la factura al cliente se puede modificar ,anular,etc..
una vez emitida , la factura se envía y se bloquea para bloquear borrados y controlar modificaciones de la misma.
¿ Este enfoque no es correcto¿?.
No pasa nada sinpor ejemplo creo 40 facturas por la mañana y las mando por la tarde?. Entendíamos la 'emision' como el momento de creación del registro de facturación. ????

Ya lo hemos comentado antes.
Deberías revisar hilos anteriores.
Personalmente creo que el planteamiento es erróneo.

Básicamente porque la normativa dice que el registro de facturación debe crearse y enviarse (esto segundo sólo si estás en veri*factu) inmediatamente después de crear la factura:
"La modalidad denominada VERI*FACTU, que exige que los registros informáticos de factura sean remitidos a la Sede electrónica de la Agencia Tributaria inmediatamente después de su producción, evitándose con ello su alteración posterior, y asegurando su conservación."

Si tú dices que vas a generar el Registro cuando "emites" la factura al cliente, resulta que en realidad puedes crear el "registro de facturación" cuando quieras; 1 minuto, 1 hora o 1 día después, dependiendo de cuando se la envíes/emitas al cliente.

Deberíais hacer una consulta a la AEAT para verficarlo.

bmfranky 16-06-2025 13:26:18

Cita:

Empezado por Galahad (Mensaje 565513)
Veo que se ha comentado que hay que crear el registro de facturación en el momento en que se crea la factura.
Nosotros creamos el registro y su hash cuando se emite la factura al cliente, ya sea por correo,impresora ftp,etc. Entendemos que mientras no se emite la factura al cliente se puede modificar ,anular,etc..
una vez emitida , la factura se envía y se bloquea para bloquear borrados y controlar modificaciones de la misma.
¿ Este enfoque no es correcto¿?.
No pasa nada sinpor ejemplo creo 40 facturas por la mañana y las mando por la tarde?. Entendíamos la 'emision' como el momento de creación del registro de facturación. ????

Hola, de veis de interpretar el momento de crear el registro a enviar a verifactu, como el que se asigna el numero de factura a la factura, la imprimáis/enviéis o no, según entiendo , cara a a hacienda es cuando pasa de ser papel mojado a una factura, siempre que se termine y guarde la misma.

Galahad 16-06-2025 13:43:35

Cita:

Empezado por Neftali [Germán.Estévez] (Mensaje 565516)
Ya lo hemos comentado antes.
Deberías revisar hilos anteriores.
Personalmente creo que el planteamiento es erróneo.

Básicamente porque la normativa dice que el registro de facturación debe crearse y enviarse (esto segundo sólo si estás en veri*factu) inmediatamente después de crear la factura:
"La modalidad denominada VERI*FACTU, que exige que los registros informáticos de factura sean remitidos a la Sede electrónica de la Agencia Tributaria inmediatamente después de su producción, evitándose con ello su alteración posterior, y asegurando su conservación."

Si tú dices que vas a generar el Registro cuando "emites" la factura al cliente, resulta que en realidad puedes crear el "registro de facturación" cuando quieras; 1 minuto, 1 hora o 1 día después, dependiendo de cuando se la envíes/emitas al cliente.

Deberíais hacer una consulta a la AEAT para verficarlo.

Hola,, si, se ha comentado muchas veces en el foro, pero sigo sin estar completamente seguro de que el registro se tenga que crear con la creación de la factura.
Tal y como me has comentado , he hecho la consulta con la aeat
Me contestan esto:

Cita:

Los registros de facturación "RF" (que no de las facturas mismas) debe producirse en los términos del artículo 16.1 del RRSIF (reglamento de los requisitos de los sistemas informáticos de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre) de forma continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente. Para otorgar el carácter de instantánea a la remisión (lo cual puede entenderse como inmediatamente después de la expedición de las facturas, sin que exista una demora, o, si esta existe, que sea mínima), se ha establecido un mecanismo en el que si se superan los 240 segundos entre la fecha y hora de generación del registro (campo "FechaHoraHusoGenRegistro" del registro de facturación) y su recepción en los sistemas de la AEAT (campo "TimeStampPresentacion" de la respuesta obtenida) el registro se aceptará pero en estado "Aceptado con errores" e indicando el error 2004 (que ustedes remiten): El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 240 segundos. Este error se excepciona de la necesidad de ser subsanado por lo que no será necesaria ninguna operación posterior.

Aquí parece que este confirmando que tenga que ser inmediatamente después de la expedición de la factura ....
Esto es un lio..

richidemola 16-06-2025 18:36:11

Cita:

Empezado por Jarogo08 (Mensaje 565478)
Madre mía... vaya lío tienes!





vuelvo a insistir... no es con la última enviada, es con la última creada!!!!!





el hash lo generas antes de enviar: creas el registro de facturación y le asignas el hash. Y luego ya haces el envío cuando sea


Aunque estés una semana sin enviar (porque no tienes internet por ejemplo) deberías poder crear registros de facturación con su hash y encadenándolos como toque (efectivamente... con el último generado ;))

Vale lo entiendo y así lo hace mi programa ahora, pero veo un problema a lo que dices de enviar los registros a la aeat en otro momento ya que para generar el hash del registro de facturación hay que usar el parámetro FechaHoraHusoGenRegistro con la fecha y hora en la que se creó el registro, si luego uso el mismo valor de FechaHoraHusoGenRegistro en el xml, si lo envío más tarde de 240 segundos me da error.

Vamos, que segun el web service el registro lo tengo que enviar no más tarde de 4 minutos desde que se genera, por lo que no creo que pueda estar una semana sin enviar los registros, a no ser que el valor de FechaHoraHusoGenRegistro en el xml no sea el mismo que se usó al generar el hash, si no que ese valor es la fecha y hora a la que se envía el registro, por que si no es así no le veo lógica a lo que dices de envíar los registros en otro momento.

gcqZW 17-06-2025 08:03:56

Puedes enviar pasados esos 240 segundos, pero tendrás que marcarlos como incidencia.

Jarogo08 17-06-2025 09:40:38

Cita:

Empezado por richidemola (Mensaje 565555)
Vale lo entiendo y así lo hace mi programa ahora, pero veo un problema a lo que dices de enviar los registros a la aeat en otro momento ya que para generar el hash del registro de facturación hay que usar el parámetro FechaHoraHusoGenRegistro con la fecha y hora en la que se creó el registro, si luego uso el mismo valor de FechaHoraHusoGenRegistro en el xml, si lo envío más tarde de 240 segundos me da error.

Vamos, que segun el web service el registro lo tengo que enviar no más tarde de 4 minutos desde que se genera, por lo que no creo que pueda estar una semana sin enviar los registros, a no ser que el valor de FechaHoraHusoGenRegistro en el xml no sea el mismo que se usó al generar el hash, si no que ese valor es la fecha y hora a la que se envía el registro, por que si no es así no le veo lógica a lo que dices de envíar los registros en otro momento.


Como te comentó gcqZW, puedes enviar pasado ese tiempo, pero debes marcar el envío como incidencia a "S". De todas maneras, ese tiene que ser un caso puntual (te falla internet o fallan los servicios de la AEAT). En el resto de casos, tendrás que tener una tarea o algo que cada menos de 4 minutos haga el envío de los registros para que no se dé este caso

El campo FechaHoraHusoGenRegistro le das valor cuando generas el registro de facturación, y luego en el XML tiene que ir ese valor, no puedes volver a calcularlo.

Sistel 18-06-2025 09:37:30

Cita:

Empezado por gcqZW (Mensaje 565559)
Puedes enviar pasados esos 240 segundos, pero tendrás que marcarlos como incidencia.

Ahora son 240 segundos el límite, pero sólo según las contestaciones que están dado a consultas.
Ese tiempo límite no está ni en la Orden Ministerial ni en ningún documento publicado.
Así que lo cambiarán cuando les apetezca.

Jarogo08 18-06-2025 10:24:46

Cita:

Empezado por Sistel (Mensaje 565623)
Ahora son 240 segundos el límite, pero sólo según las contestaciones que están dado a consultas.
Ese tiempo límite no está ni en la Orden Ministerial ni en ningún documento publicado.
Así que lo cambiarán cuando les apetezca.


Yo lo guardé en un campo de la base de datos. Si en algún momento lo cambian saco una versión que le cambie el valor y debería seguir funcionando el tema de enviarlo marcado como incidencia pasado el tiempo del nuevo valor

Sistel 19-06-2025 10:35:38

Cita:

Empezado por Jarogo08 (Mensaje 565626)
Yo lo guardé en un campo de la base de datos. Si en algún momento lo cambian saco una versión que le cambie el valor y debería seguir funcionando el tema de enviarlo marcado como incidencia pasado el tiempo del nuevo valor

La verdad es que están jugando con nosotros como si fuésemos muñecos.
Cambian las validaciones y los criterios a su antojo (y sin comunicarlos) a cada momento.
Y nos tenemos que estar basando en hacerles consultas que nos responde un técnico con el criterio que le salga en ese momento.
Y sin una normativa establecida en un documento oficial serio y estable.

¡¡¡ Por favor, AEAT (por si lo lee algún responsable), un poco más de seriedad !!!

delphiGar 19-06-2025 12:36:00

Cita:

Empezado por Sistel (Mensaje 565701)
La verdad es que están jugando con nosotros como si fuésemos muñecos.
Cambian las validaciones y los criterios a su antojo (y sin comunicarlos) a cada momento.
Y nos tenemos que estar basando en hacerles consultas que nos responde un técnico con el criterio que le salga en ese momento.
Y sin una normativa establecida en un documento oficial serio y estable.

¡¡¡ Por favor, AEAT (por si lo lee algún responsable), un poco más de seriedad !!!

Coincido contigo 100%. Es un desproposito total.

Carlos 23-08-2025 13:59:34

Es una cuestión de concepto.

No se envían facturas.
No se encadenan facturas.

Se envían registros de facturación.
Se encadenan registros de facturación

¿Para que sirve un registro de facturación?

Para indicarle a Hacienda qué estás haciendo con la factura:
-la doy de alta -->> nuevo registro de facturación
-la rectifico -->> nuevo registro de fascturación
-la anulo -->> nuevo registro de facturación

Y siempre se encadena una registro de facturación con su anterior independientemente de la tipología de la operación y la factura a la que hace referencia.

Realmente es muy sencillo, cuando ya has perdido casi 1 mes de desarrollo por no leer/comprender (hace meses, ya no me hierve la sangre).

Saludos,
Carlos G.

Carlos 23-08-2025 14:19:35

Cita:

Empezado por delphiGar (Mensaje 565704)
Coincido contigo 100%. Es un desproposito total.

Yo no estoy de acuerdo.
Nos dicen que tenemos de crear y enviar el registro de facturación inmediatamente a la generación de la factura, pués lo hago, tomo nota de la fecha y hora y genero el valor de FechaHoraHusoGenRegistro.

Y lo enviaré cuando Hacienda ME LO PERMITA.

A tener en cuenta que a cada respuesta de Veri*factu, viene cuantos segundos debemos esperar para enviar nuestro siguiente XML, y ahí yo pongo el valor FechaHoraHusoGenRegistro que he calculado para cada registro, tanto si ha pasado 60 segundos como 2 horas.

Que esto es lo que puede suceder en los días punta de Navidad, si Hacienda tiene problemas empezará a contestar con 500 segundos o los que precise, y mientras nosotros debemos seguir facturando.

Ya me dirá hacienda si lo hago bien.

emailesc 10-09-2025 21:48:31

Dos registros de facturación erroreos sobre la misma factura
 
Hola, os planteo un caso que no tengo muy claro qué se debe hacer. Haciendo pruebas con rectificativas he generado dos registros de facturación incorrectos de la misma factura rectificativa, y los dos enviados. El segundo encadenado al primero. Bien cojo el primer registro de facturación erróneo y le creo una subsanación (el xml no era correcto), y por tanto un nuevo tercer registro de facturación, encadenado al segundo, la envío y la da correcto. Ahora la pregunta es, ¿Que hago con el segundo registro de facturación erróneo? No puedo borrarlo puesto que está en el encadenamiento, no puedo mandar una subsanación puesto que ya esta subsanado, no es cosa de hacer otra rectificativa porque la factura está bien y ya enviada...lo dejo así y santas pascuas puesto que en realidad ya está arreglado en el tercer envío ???
Como estoy en pruebas, puedo arreglarlo a lo bestia, borro el registro y atpc el encadenamiento, pero si se diera en producción no tengo claro que se debería hacer...

Jarogo08 11-09-2025 08:36:03

Cita:

Empezado por emailesc (Mensaje 567579)
Hola, os planteo un caso que no tengo muy claro qué se debe hacer. Haciendo pruebas con rectificativas he generado dos registros de facturación incorrectos de la misma factura rectificativa, y los dos enviados. El segundo encadenado al primero. Bien cojo el primer registro de facturación erróneo y le creo una subsanación (el xml no era correcto), y por tanto un nuevo tercer registro de facturación, encadenado al segundo, la envío y la da correcto. Ahora la pregunta es, ¿Que hago con el segundo registro de facturación erróneo? No puedo borrarlo puesto que está en el encadenamiento, no puedo mandar una subsanación puesto que ya esta subsanado, no es cosa de hacer otra rectificativa porque la factura está bien y ya enviada...lo dejo así y santas pascuas puesto que en realidad ya está arreglado en el tercer envío ???
Como estoy en pruebas, puedo arreglarlo a lo bestia, borro el registro y atpc el encadenamiento, pero si se diera en producción no tengo claro que se debería hacer...

Buenas

Es que subsanas la factura, no cada uno de los registros de facturación

Supongamos este caso:

-Creas una factura, creas su registro de facturación y lo envías.
-Da error porque el XML no estaba correcto.
-Cambias código, le das a subsanar y creas otro registro de facturación.
-Vuelve a dar error porque el XML sigue siendo incorrecto
-Vuelves a cambiar código, le das a subsanar y creas otro registro de facturación.
-Vuelve a dar error porque el XML sigue siendo incorrecto
-Vuelves a cambiar código, le das a subsanar y creas otro registro de facturación.
-Ahora ya entra correcto.

No tendrías que hacer nada más, la factura ya está correcta y subida.

Los pasos que hiciste son:

Registro 1- Alta de factura -> error al subir
Registro 2- Subsanación de factura -> error al subir
Registro 3- Subsanación de factura -> error al subir
Registro 4- Subsanación de factura -> todo correcto al subir

Has creado y enviado 4 registros de facturación para una factura hasta que entró correcta. Pero no tienes que subsanar los registros 1, 2 y 3 (los que dieron error). Tienes que subsanar la factura.

emailesc 11-09-2025 08:57:56

Cita:

Empezado por Jarogo08 (Mensaje 567582)
Buenas

Es que subsanas la factura, no cada uno de los registros de facturación

Supongamos este caso:

-Creas una factura, creas su registro de facturación y lo envías.
-Da error porque el XML no estaba correcto.
-Cambias código, le das a subsanar y creas otro registro de facturación.
-Vuelve a dar error porque el XML sigue siendo incorrecto
-Vuelves a cambiar código, le das a subsanar y creas otro registro de facturación.
-Vuelve a dar error porque el XML sigue siendo incorrecto
-Vuelves a cambiar código, le das a subsanar y creas otro registro de facturación.
-Ahora ya entra correcto.

No tendrías que hacer nada más, la factura ya está correcta y subida.

Los pasos que hiciste son:

Registro 1- Alta de factura -> error al subir
Registro 2- Subsanación de factura -> error al subir
Registro 3- Subsanación de factura -> error al subir
Registro 4- Subsanación de factura -> todo correcto al subir

Has creado y enviado 4 registros de facturación para una factura hasta que entró correcta. Pero no tienes que subsanar los registros 1, 2 y 3 (los que dieron error). Tienes que subsanar la factura.



Gracias por tu ayuda. Es un punto de vista, el de subsanar la factura, sin embargo en este caso la factura es correcta y no cambia nada en ella desde el primer registro, es la confección del xml del registro de facturación que lo creó de forma errónea por un error de programación (se podría dar y sería el caso más normal que fuera la factura la que estuviera mal y ahí sí se subsanase la factura), por lo que, en cierta manera lo que estoy subsanando es el registro de facturación que la "registra" en Verifactu. Por otro lado llevamos un control de los registros de facturación, para controlar los que están enviados, los que no están correctos y que por tanto hay que corregir de una manera u otra (rectificación, subsanación, etc), y los registros que están erróneos, si se corrigen con otro registro de facturación, se marcan como corregidos y qué registro los corrige, por lo que en principio no puedo dejar registros incorrectos sin corregir, para que en condiciones normales, los marcadores de errores estén "a cero". Por lo que entiendo de lo que dices no habría que hacer nada respecto a Verifactu (a mi tampoco se me ocurre qué se debería hacer, de ahí la pregunta), por lo que puedo marcar el registro que queda erroneo como corregido manualmente (que en producción también lo podría hacer) y santas pascuas.

Jarogo08 11-09-2025 09:58:53

Cita:

Empezado por emailesc (Mensaje 567583)
Gracias por tu ayuda. Es un punto de vista, el de subsanar la factura, sin embargo en este caso la factura es correcta y no cambia nada en ella desde el primer registro, es la confección del xml del registro de facturación que lo creó de forma errónea por un error de programación (se podría dar y sería el caso más normal que fuera la factura la que estuviera mal y ahí sí se subsanase la factura), por lo que, en cierta manera lo que estoy subsanando es el registro de facturación que la "registra" en Verifactu. Por otro lado llevamos un control de los registros de facturación, para controlar los que están enviados, los que no están correctos y que por tanto hay que corregir de una manera u otra (rectificación, subsanación, etc), y los registros que están erróneos, si se corrigen con otro registro de facturación, se marcan como corregidos y qué registro los corrige, por lo que en principio no puedo dejar registros incorrectos sin corregir, para que en condiciones normales, los marcadores de errores estén "a cero". Por lo que entiendo de lo que dices no habría que hacer nada respecto a Verifactu (a mi tampoco se me ocurre qué se debería hacer, de ahí la pregunta), por lo que puedo marcar el registro que queda erroneo como corregido manualmente (que en producción también lo podría hacer) y santas pascuas.


Si lo haces así, tendrás que subsanar siempre el último. Y cuando entre correcto marcar como "corregidos" todos los anteriores: si una factura tiene 5 envíos incorrectos y el sexto entra correcto, que actualice los 5 primeros.

Pero insisto, no tienes que subsanar los 5 que dieron error, tienes que subsanar el quinto y cuando entre correcta la factura ya estaría lista

emailesc 11-09-2025 10:05:23

Cita:

Empezado por Jarogo08 (Mensaje 567587)
Si lo haces así, tendrás que subsanar siempre el último. Y cuando entre correcto marcar como "corregidos" todos los anteriores: si una factura tiene 5 envíos incorrectos y el sexto entra correcto, que actualice los 5 primeros.

Pero insisto, no tienes que subsanar los 5 que dieron error, tienes que subsanar el quinto y cuando entre correcta la factura ya estaría lista

Sí, esa es la idea, subsanar uno y marcar como corregidos el resto, bien manualmente, bien de forma automática, que también los puedo localizar por el numero de factura, serie, centro, tipo de documento, y estado del registro.
Gracias por la ayuda ^\||/


La franja horaria es GMT +2. Ahora son las 16:25:08.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi