Prefacturacion, Proformas y Borradores de facturas (Faq Verifactu)

[CarlosR]

En respuesta a uno de los últimos post que hacían alusión a una participación mía sobre el famoso (t)




1º Si se fija en lo que yo he escrito verá que he hablado de que al juntar 1000 registros debe enviar. Ergo es un máximo. Apartado 4.
2º que si ha llegado a un período de 2 horas sin juntar 1000 (máximo por envío) registros debe enviar lo que tenga. Apartado 3.
Lo tiene en mi post.

Con respecto al link que usted me ha propuesto leer...

Página 24 de su documento reseñado : bajo el item TiempoEsperaEnvio ... "Segundos de espera entre envíos.
Para poder realizar el siguiente envío, el sistema
informático deberá esperar a que transcurran
<TiempoEsperaEnvio> segundos desde el anterior envío
o deberá esperar a tener acumulados un número de
registros de facturación igual al límite establecido en el
diseño de registro para cada envío, la circunstancia que
ocurra primero"

Página 26 de su documento reseñado : Bajo el epígrafe 6.3.1.1.Mecanismo de control de flujo.
Viene especificado en el artículo 16.2 de la orden:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre
envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser
tenido en cuenta para el siguiente envío.

un link de esa pregunta hecha ya en abril de este mismoo año ...
http://www.clubdelphi.com/foros/showthread.php?p=555426

Aunque ahora ya no hay pdf colgados en la página de la AEAT atrasados, creo recordar (y tendría que revisar en los pdf impresos) que se especificaba que el tiempo (t) podría variar en función de la saturación de datos de la propia AEAT.
Actualmente es 60 segundos. Por eso indiqué en mi post en el apartado 2 que son 60 actualmente, en el futuro dependerá de la propia AEAT.

De todos modos si en algo estoy errado, por favor, indíquemelo para poder corregir mi código a tiempo. Ya llevo cambiado muchas veces el código desde que salió el primer borrador de proyecto de Ley. Por ello no sería la primera vez.

Gracias de antemano.


"Errar es de humanos, rectificar es de sabios"

[CarlosR]

Página 26 del PDF reseñado anteriormente.

a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t»
entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o
deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío,
la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva
actualización del valor del parámetro «t».


Después de darle vueltas a esto creo que tengo que rectificar mi concepto de 2 horas por el famoso (t) que devuelve la AEAT.

Creo que el usuario ermendalenda me lo decía así ayer.

¿ Es así ?

Gracias de antemano.

[bmfranky]

Empezado por CarlosR

Página 26 del PDF reseñado anteriormente.

a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t»
entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o
deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío,
la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva
actualización del valor del parámetro «t».


Después de darle vueltas a esto creo que tengo que rectificar mi concepto de 2 horas por el famoso (t) que devuelve la AEAT.

Creo que el usuario ermendalenda me lo decía así ayer.

¿ Es así ?

Gracias de antemano.

Hola, si , lo de las 2 horas ya no es asi ,creo que desde la version 0.2 del servicio, ahora ay que enviar en t>envio<t+120" despues de crear o encadenar los registros, si envia varios , tenga en cuanta que los 120 segundos empiezan a contar desde el primer timestamp.

[bmfranky]

Empezado por CarlosR

En respuesta a uno de los últimos post que hacían alusión a una participación mía sobre el famoso (t)




1º Si se fija en lo que yo he escrito verá que he hablado de que al juntar 1000 registros debe enviar. Ergo es un máximo. Apartado 4.
2º que si ha llegado a un período de 2 horas sin juntar 1000 (máximo por envío) registros debe enviar lo que tenga. Apartado 3.
Lo tiene en mi post.

Con respecto al link que usted me ha propuesto leer...

Página 24 de su documento reseñado : bajo el item TiempoEsperaEnvio ... "Segundos de espera entre envíos.
Para poder realizar el siguiente envío, el sistema
informático deberá esperar a que transcurran
<TiempoEsperaEnvio> segundos desde el anterior envío
o deberá esperar a tener acumulados un número de
registros de facturación igual al límite establecido en el
diseño de registro para cada envío, la circunstancia que
ocurra primero"

Página 26 de su documento reseñado : Bajo el epígrafe 6.3.1.1.Mecanismo de control de flujo.
Viene especificado en el artículo 16.2 de la orden:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre
envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser
tenido en cuenta para el siguiente envío.

un link de esa pregunta hecha ya en abril de este mismoo año ...
http://www.clubdelphi.com/foros/showthread.php?p=555426

Aunque ahora ya no hay pdf colgados en la página de la AEAT atrasados, creo recordar (y tendría que revisar en los pdf impresos) que se especificaba que el tiempo (t) podría variar en función de la saturación de datos de la propia AEAT.
Actualmente es 60 segundos. Por eso indiqué en mi post en el apartado 2 que son 60 actualmente, en el futuro dependerá de la propia AEAT.

De todos modos si en algo estoy errado, por favor, indíquemelo para poder corregir mi código a tiempo. Ya llevo cambiado muchas veces el código desde que salió el primer borrador de proyecto de Ley. Por ello no sería la primera vez.

Gracias de antemano.


"Errar es de humanos, rectificar es de sabios"

Hola, saludos, primero que nada aclarar que no tengo ninguna vendeta contra usted,simplemente es ayudar.
Lo que le insisto es en que su codigo a de remitir pseudo inmediatamente(Despues de un tiepo demomento t minimo de 60" y menor a t + 120") , los datos del/los registro-os/factura-as generada-as, sin demoras mas alla de 120", a no ser por causa externas al programa en uso, y si se produce esa demora marcar incidencia, para en principio evitar el error por exceso de tiempo de generacion, tenga en cuenta que el tiempo maximo antes del envio se cuenta desde que asigna el TimeStamp TipoHoraGeneracionRegistro.
Realmente ,en los primeros borradores tenian en cuenta qu en principio o se gestionarian los envios por tiempo o numero de registros, ahora se gestiona solo por tiempo.

[CarlosR]

Empezado por bmfranky

Hola, saludos, primero que nada aclarar que no tengo ninguna vendeta contra usted,simplemente es ayudar.
Lo que le insisto es en que su codigo a de remitir pseudo inmediatamente(Despues de un tiepo demomento t minimo de 60" y menor a t + 120") , los datos del/los registro-os/factura-as generada-as, sin demoras mas alla de 120", a no ser por causa externas al programa en uso, y si se produce esa demora marcar incidencia, para en principio evitar el error por exceso de tiempo de generacion, tenga en cuenta que el tiempo maximo antes del envio se cuenta desde que asigna el TimeStamp TipoHoraGeneracionRegistro.
Realmente ,en los primeros borradores tenian en cuenta qu en principio o se gestionarian los envios por tiempo o numero de registros, ahora se gestiona solo por tiempo.

No hombre no, no considero que haya ensañamiento y alevosía, faltaría mas.

Es mas, agradezco las contribuciones de otros.

Hay dos formas de hacer un proyecto, bueno tres. He hecho unos cuantos desde cero a lo largo de mi carrera profesional.

1- Buscando apoyo de consultroes externos. (pagando y a veces no poco), doy fe.

2- Buceando en foros y compartiendo tiempo y esfuerzo de gente que tenga experiencia.
3- Inventándose las normas.
El primero tiene un coste. El tercero no va.
El segundo es muy viable si estás en el foro adecuado.
Para nada me ofende hombre, todo lo contrario.
No he visto a nadie en el canal con afán de ofender. Solo he visto gente colaborativa.
Otra cuestión es el estado de ánimo que uno tenga en un momento dado.


Saludos a todos !

[bmfranky]

Empezado por CarlosR

No hombre no, no considero que haya ensañamiento y alevosía, faltaría mas.

Es mas, agradezco las contribuciones de otros.

Hay dos formas de hacer un proyecto, bueno tres. He hecho unos cuantos desde cero a lo largo de mi carrera profesional.

1- Buscando apoyo de consultroes externos. (pagando y a veces no poco), doy fe.

2- Buceando en foros y compartiendo tiempo y esfuerzo de gente que tenga experiencia.
3- Inventándose las normas.
El primero tiene un coste. El tercero no va.
El segundo es muy viable si estás en el foro adecuado.
Para nada me ofende hombre, todo lo contrario.
No he visto a nadie en el canal con afán de ofender. Solo he visto gente colaborativa.
Otra cuestión es el estado de ánimo que uno tenga en un momento dado.


Saludos a todos !

Si,si, doy fe al estado de animo, ayer encadene una de "Clientes" amables , que cuando llegue a casa parecia un pisonn de carretera, rebotando...

[novatico]

Partiendo de toda la documentación que hay sobre este tema, en mi caso, y teniendo en cuenta el volumen de mis clientes, yo voy a desarrollarlo como un módulo independiente.

La gestión de facturación podrá seguir emitiendo facturas si tener que realizar esperas, y además de los procesos habituales que teníamos hasta ahora, grabará en un fichero los datos de cada factura generada, de forma secuencial, marcados como pendientes de enviar.

El módulo de "Control de Flujo", estará revisando este fichero de "envios pendientes", y en mi caso, cada vez que detecte 1 pendiente, tomará el "datetime" de ese instante y actualizando el "registro de facturación de alta", realizará el envío, controlando en la respuesta los posibles errores.
Tras la respuesta, tendré una pausa de los segundos que esta me indique, y volveré a la revisión de pendientes.
Este módulo estará activo en todo momento, incluso a la entrada al programa de facturación revisaré si está activo.

Prefiero enviar uno a uno, porque me resulta más fácil controlar los errores.

Por cierto, no sé porque habéis nombrado a "Mercadona" o similares. Ellos no tienen que hacer nada, están sujetos al SII.

[bmfranky]

Empezado por novatico

Partiendo de toda la documentación que hay sobre este tema, en mi caso, y teniendo en cuenta el volumen de mis clientes, yo voy a desarrollarlo como un módulo independiente.

La gestión de facturación podrá seguir emitiendo facturas si tener que realizar esperas, y además de los procesos habituales que teníamos hasta ahora, grabará en un fichero los datos de cada factura generada, de forma secuencial, marcados como pendientes de enviar.

El módulo de "Control de Flujo", estará revisando este fichero de "envios pendientes", y en mi caso, cada vez que detecte 1 pendiente, tomará el "datetime" de ese instante y actualizando el "registro de facturación de alta", realizará el envío, controlando en la respuesta los posibles errores.
Tras la respuesta, tendré una pausa de los segundos que esta me indique, y volveré a la revisión de pendientes.
Este módulo estará activo en todo momento, incluso a la entrada al programa de facturación revisaré si está activo.

Prefiero enviar uno a uno, porque me resulta más fácil controlar los errores.

Por cierto, no sé porque habéis nombrado a "Mercadona" o similares. Ellos no tienen que hacer nada, están sujetos al SII.

Hola, si seguro, pero como es el que tenemos al lado de casa, pues nos sale solo...

[ermendalenda]

Empezado por novatico

Partiendo de toda la documentación que hay sobre este tema, en mi caso, y teniendo en cuenta el volumen de mis clientes, yo voy a desarrollarlo como un módulo independiente.

La gestión de facturación podrá seguir emitiendo facturas si tener que realizar esperas, y además de los procesos habituales que teníamos hasta ahora, grabará en un fichero los datos de cada factura generada, de forma secuencial, marcados como pendientes de enviar.

El módulo de "Control de Flujo", estará revisando este fichero de "envios pendientes", y en mi caso, cada vez que detecte 1 pendiente, tomará el "datetime" de ese instante y actualizando el "registro de facturación de alta", realizará el envío, controlando en la respuesta los posibles errores.
Tras la respuesta, tendré una pausa de los segundos que esta me indique, y volveré a la revisión de pendientes.
Este módulo estará activo en todo momento, incluso a la entrada al programa de facturación revisaré si está activo.

Prefiero enviar uno a uno, porque me resulta más fácil controlar los errores.

Por cierto, no sé porque habéis nombrado a "Mercadona" o similares. Ellos no tienen que hacer nada, están sujetos al SII.

Hola
Si emites 2 tiques dentro del mismo minuto y sólo envías 1 cuando envíes el segundo estará fuera de tiempo y te dará el error 2004 mejor manda todo lo qie tebgas en el mismo paquete

Hay ejemplos más claros que mercadona, hay muchos negocios que emiten tiques más rápidos que un supermercado. Por ejemplo una autopista, una panadería, algun tipo de negocios de juegos...

[sglorka]

Yo creo que como resumen para el tema de control de flujo, deberíamos estar de acuerdo en que cada "t" segundos se mira lo que está pendiente de enviar y se envía todo hasta la cantidad de 1000 registros como máximo. Luego actualizamos el valor de "t" que nos devuelve la última comunicación y volvemos a proceder de la misma manera

[sglorka]

Obviamente, para los que envían los registros de 1 en 1, los primeros registros sería Aceptados (si procediera) y el resto le respondería Aceptado con errores por exceso de tiempo

[razorxxx]

Empezado por sglorka

Yo creo que como resumen para el tema de control de flujo, deberíamos estar de acuerdo en que cada "t" segundos se mira lo que está pendiente de enviar y se envía todo hasta la cantidad de 1000 registros como máximo. Luego actualizamos el valor de "t" que nos devuelve la última comunicación y volvemos a proceder de la misma manera

Menos mal que hay alguien que pide coherencia en el foro. Me he recorrido centenares de mensajes y he leído auténticos disparates, lo cual me da a pensar que la mitad ni se ha leído los dos BOE (el de la OM y el del Reglamento).

Sin ánimo de ofender a nadie, convendría por el bien de todos no publicar cosas sin contrastar con fuentes fiables primero para evitar desinformar al grupo, porque al final tendremos diferentes formas de hacer las cosas y tal vez la mayoría estén mal. Y para cuando te des cuenta de que están mal, a lo mejor ya Veri*Factu entró en vigor.

Hablan por aquí de prefacturas, borradores, enviar 1000 registros en 2 horas, enviar 1 cada minuto para facilitarme las cosas, etc. El Reglamento lo especifica bien claro: se envían todos los registros de facturación en un único envío cada 60 segundos, o menos si se alcanzan los 1000 registros antes de ese tiempo, y en la respuesta te devuelven el tiempo (que seguramente vuelvan a ser 60 segundos) en el que deberás enviar los nuevos registros de facturación generados desde el último envío. Las empresas que por su naturaleza suelan tener que acometer cambios en las facturas antes de entregárselas al cliente final, para evitar tener una maraña de rectificativas lo que harán será trabajar con albaranes o proformas como hasta ahora, los cuales no son documentos fiscalizados (no tienen validez lega, y por tanto se pueden modificar, borrar e incluso alterar sus contadores). Esas proformas se convertirán en factura definitiva cuando convenga y los grupos de albaranes se convertirán en lo que se suele llamar "factura resumen", y es entonces cuando pasará a ser documento legal y del que se generará su correspondiente registro de facturación.

Para tranquilidad de todos, si la AEAT actúa como con el SII, decir que de nuestra veintena de clientes acogidos por ser gran empresa, ninguno hasta ahora ha recibido una carta o multa de la AEAT por enviar fuera de plazo. No sé cómo harán con Veri*Factu pero si no quieren que se les vaya de las manos o mandarnos a todos al "talego" deberán de flexibilizar esto. Al final lo que les interesa es que la información que mandes sea correcta, no creo yo que importe tanto el tiempo como la forma.

Y recuerden que sólo se envían los registros de facturación, y no los de eventos (que también he visto algún hilo diciendo este disparate).

[edari]

Empezado por razorxxx

Menos mal que hay alguien que pide coherencia en el foro. Me he recorrido centenares de mensajes y he leído auténticos disparates, lo cual me da a pensar que la mitad ni se ha leído los dos BOE (el de la OM y el del Reglamento).

Sin ánimo de ofender a nadie, convendría por el bien de todos no publicar cosas sin contrastar con fuentes fiables primero para evitar desinformar al grupo, porque al final tendremos diferentes formas de hacer las cosas y tal vez la mayoría estén mal. Y para cuando te des cuenta de que están mal, a lo mejor ya Veri*Factu entró en vigor.

Hablan por aquí de prefacturas, borradores, enviar 1000 registros en 2 horas, enviar 1 cada minuto para facilitarme las cosas, etc. El Reglamento lo especifica bien claro: se envían todos los registros de facturación en un único envío cada 60 segundos, o menos si se alcanzan los 1000 registros antes de ese tiempo, y en la respuesta te devuelven el tiempo (que seguramente vuelvan a ser 60 segundos) en el que deberás enviar los nuevos registros de facturación generados desde el último envío. Las empresas que por su naturaleza suelan tener que acometer cambios en las facturas antes de entregárselas al cliente final, para evitar tener una maraña de rectificativas lo que harán será trabajar con albaranes o proformas como hasta ahora, los cuales no son documentos fiscalizados (no tienen validez lega, y por tanto se pueden modificar, borrar e incluso alterar sus contadores). Esas proformas se convertirán en factura definitiva cuando convenga y los grupos de albaranes se convertirán en lo que se suele llamar "factura resumen", y es entonces cuando pasará a ser documento legal y del que se generará su correspondiente registro de facturación.

Para tranquilidad de todos, si la AEAT actúa como con el SII, decir que de nuestra veintena de clientes acogidos por ser gran empresa, ninguno hasta ahora ha recibido una carta o multa de la AEAT por enviar fuera de plazo. No sé cómo harán con Veri*Factu pero si no quieren que se les vaya de las manos o mandarnos a todos al "talego" deberán de flexibilizar esto. Al final lo que les interesa es que la información que mandes sea correcta, no creo yo que importe tanto el tiempo como la forma.

Y recuerden que sólo se envían los registros de facturación, y no los de eventos (que también he visto algún hilo diciendo este disparate).

Ayer asistí a un webinar de una empresa de auditorías de Verifactu y venían a decir que en la reglamentación de la facturación "técnicamente" también se impide que se puedan borrar albaranes al completo de la base de datos.


También me sorprendió.

[razorxxx]

Empezado por edari

Ayer asistí a un webinar de una empresa de auditorías de Verifactu y venían a decir que en la reglamentación de la facturación "técnicamente" también se impide que se puedan borrar albaranes al completo de la base de datos.


También me sorprendió.

Lo dicho, hay mucho desconocimiento y parece que Veri*Factu cambia las leyes anteriores y no es así. Las leyes de facturación siguen igual, por tanto un presupuesto o un albarán no son documentos fiscalizados y por ende puedo hacer con ellos lo que me venga en gana. Puedo borrarlos y que haya saltos o huecos en la numeración, y tampoco existe una rectificativa de albarán o de proforma. No estaría incumpliendo Veri*Factu porque literalmente no son facturas.

Tampoco hay que añadir a las facturas el campo hora, las facturas siguen como hasta ahora y sólo llevan fecha de expedición. Son los registros de facturación los que se les añade la hora y huso horario en que fueron generados para poder controlar si los registros se están mandando a su debido tiempo.

Fíjense que el reglamento sólo afecta a programas que realicen facturas (esto ya me informé con los de Veri*Factu por mail), pero si tienes un programa que sólo sirve para contabilidad no te va a afectar. Lo único que han dicho para estos software es que impidan llevar contabilidad "B". He visto algunos software de contabilidad que obligan a hacer contraapuntes cada vez que te equivocas. Tener esa información banal es un engorro para la persona que lleve contabilidad, cada vez que saque un extracto de una cuenta va a querer cortarse las venas porque le va a costar llevar un seguimiento. Lo lógico es que el programa contable permita editar los apuntes a menos que hayan sido ya enviados al SII o se hayan declarado impuestos.

[ermendalenda]

Empezado por razorxxx

Menos mal que hay alguien que pide coherencia en el foro. Me he recorrido centenares de mensajes y he leído auténticos disparates, lo cual me da a pensar que la mitad ni se ha leído los dos BOE (el de la OM y el del Reglamento).

Sin ánimo de ofender a nadie, convendría por el bien de todos no publicar cosas sin contrastar con fuentes fiables primero para evitar desinformar al grupo, porque al final tendremos diferentes formas de hacer las cosas y tal vez la mayoría estén mal. Y para cuando te des cuenta de que están mal, a lo mejor ya Veri*Factu entró en vigor.

Hablan por aquí de prefacturas, borradores, enviar 1000 registros en 2 horas, enviar 1 cada minuto para facilitarme las cosas, etc. El Reglamento lo especifica bien claro: se envían todos los registros de facturación en un único envío cada 60 segundos, o menos si se alcanzan los 1000 registros antes de ese tiempo, y en la respuesta te devuelven el tiempo (que seguramente vuelvan a ser 60 segundos) en el que deberás enviar los nuevos registros de facturación generados desde el último envío. Las empresas que por su naturaleza suelan tener que acometer cambios en las facturas antes de entregárselas al cliente final, para evitar tener una maraña de rectificativas lo que harán será trabajar con albaranes o proformas como hasta ahora, los cuales no son documentos fiscalizados (no tienen validez lega, y por tanto se pueden modificar, borrar e incluso alterar sus contadores). Esas proformas se convertirán en factura definitiva cuando convenga y los grupos de albaranes se convertirán en lo que se suele llamar "factura resumen", y es entonces cuando pasará a ser documento legal y del que se generará su correspondiente registro de facturación.

Para tranquilidad de todos, si la AEAT actúa como con el SII, decir que de nuestra veintena de clientes acogidos por ser gran empresa, ninguno hasta ahora ha recibido una carta o multa de la AEAT por enviar fuera de plazo. No sé cómo harán con Veri*Factu pero si no quieren que se les vaya de las manos o mandarnos a todos al "talego" deberán de flexibilizar esto. Al final lo que les interesa es que la información que mandes sea correcta, no creo yo que importe tanto el tiempo como la forma.

Y recuerden que sólo se envían los registros de facturación, y no los de eventos (que también he visto algún hilo diciendo este disparate).

Gracias por tu propuesta, pero de eso se trata de exponer, errar y corregir, esto no es una asesoría fiscal, si puedes ayudar te lo agradecemos, si ves fallos te agradecemos la correcciones, a mi también me jode mucho haberme equivocado en el desarrollo por un post erroneo, pero es lo que hay, yo creo que todos intentan ser los más congruente posible y también me equivoco en cosas que pensaba que eran seguras, para eso estamos, gracias de nuevo.

[razorxxx]

Empezado por ermendalenda

Gracias por tu propuesta, pero de eso se trata de exponer, errar y corregir, esto no es una asesoría fiscal, si puedes ayudar te lo agradecemos, si ves fallos te agradecemos la correcciones, a mi también me jode mucho haberme equivocado en el desarrollo por un post erroneo, pero es lo que hay, yo creo que todos intentan ser los más congruente posible y también me equivoco en cosas que pensaba que eran seguras, para eso estamos, gracias de nuevo.

En serio, no es mi intención que te ofendas ni que se ofenda nadie. Pero entiéndeme que uno está ya cansado de la desinformación y de las noticias fake que circulan por cualquier foro o red social que se pisa.

Una cosa por ejemplo es que hayas hecho una rutina de desarrollo y que alguien te corrija o te proponga otra manera mejor de hacerlo, pero en el contexto en que estamos metidos en este hilo, afirmar cosas de la normativa que ni siquiera aparecen en ella y que nadie de Veri*Factu te ha resuelto por mail al final lo que hace es sembrar mayor incertidumbre y dudas.

Siempre por impulsividad es más fácil largar lo que se te pasaba por la cabeza en ese momento sin pararte a pensar las repercusiones, pero aquí no estamos lanzando mensajes al aire: una "cagada" importante puede provocarnos sanciones de la AEAT como para cerrarnos el kiosko.

[novatico]

Empezado por ermendalenda

Hola
Si emites 2 tiques dentro del mismo minuto y sólo envías 1 cuando envíes el segundo estará fuera de tiempo y te dará el error 2004 mejor manda todo lo qie tebgas en el mismo paquete

Hay ejemplos más claros que mercadona, hay muchos negocios que emiten tiques más rápidos que un supermercado. Por ejemplo una autopista, una panadería, algun tipo de negocios de juegos...

Si repasas los procesos que voy a realizar, verás que digo "El módulo de "Control de Flujo", estará revisando este fichero de "envios pendientes", y en mi caso, cada vez que detecte 1 pendiente, tomará el "datetime" de ese instante y actualizando el "registro de facturación de alta", realizará el envío, controlando en la respuesta los posibles errores."

Esto evita el error por superar el tiempo.
Por supuesto también me supone actualizar a la vez la "huella".

[CarlosArjonomia]

¿Controlan ya lo de los 60"?, lo digo porque puedo enviar registros sin esperar ese tiempo y no devuelve ningún error.

[edari]

Empezado por CarlosArjonomia

¿Controlan ya lo de los 60"?, lo digo porque puedo enviar registros sin esperar ese tiempo y no devuelve ningún error.

Creo que todavía no porque a mí también me dejó el otro día

[sglorka]

Empezado por novatico

Si repasas los procesos que voy a realizar, verás que digo "El módulo de "Control de Flujo", estará revisando este fichero de "envios pendientes", y en mi caso, cada vez que detecte 1 pendiente, tomará el "datetime" de ese instante y actualizando el "registro de facturación de alta", realizará el envío, controlando en la respuesta los posibles errores."

Esto evita el error por superar el tiempo.
Por supuesto también me supone actualizar a la vez la "huella".

Quiero entender bien lo que hace tu proceso, creas la factura, creas el registro de facturación, salvas en una tabla de envíos pendientes los registros de facturación y luego un módulo aparte, verifica si tiene que enviar algún registro. Si hay que enviar, controlas ese instante para volver a generar el nodo de fecha de creación, si fuera el caso ya que puedes estar fuera de los 60 segundos, y reconstruyes la huella de ese registro.

Bueno, si es así como funciona, bajo mi punto de vista, no es correcto porque el pilar principal de Verifactu es que una vez creado el registro de facturación este es "inmutable"
No puedes modificar un registro de facturación una vez emitido. De todas formas, este error no tienes que subsanarlo.