Reenvío de facturas el Entorno de Pruebas SIN especificar Subsanación

[sglorka]

Empezado por espinete

Si, eso está claro. Lo que quiero decir es que aunque no indiques "Subsanación = S", te la aceptan, y no deberían. Deberían requerir indicar "subsanación = S", pero no lo están haciendo.
Obviamente mi intención es enviarla como subsanación, pero haciendo pruebas me pareció raro que las aceptaran sin indicarlo.

Vamos, que siendo tan tiquismiquis con todo lo demás, me parece raro que con esto se lo estén saltando, al menos por ahora.

En realidad, si lo piensas, ellos no pueden saber si la estás enviando continuamente como un alta nueva puesto que te la rechazan en cada envío y para ellos es válida cuando ya es correcta y la informas como alta nueva por quinta vez. Por lo tanto, entiendo que te dejen hacerlo sin rechistar. Pero otra cosa es lo que te comentaba, no sabemos con qué información se quedan para su control y si en un futuro, controlarán esto.
Con los fallos de encadenamiento también actúan igual, te los permiten porque saben que pueden haber huecos debido a rechazos, pero si fuera una casuística recurrente en tu SIF, entiendo que te llamarían a capítulo

[VJSoftware]

Voy a volver sobre este tema de las subsanaciones por si algún alma caritativa me lo deja claro, porque la verdad aún no me entero.

Supongamos que envío un XML con un conjunto de 20 facturas y supongamos que la número 10 me devuelve incorrecto, en mi caso concreto, por el tema del NIF. El resto de posibles errores ya los tengo blindados para que el usuario no los pueda cometer antes de enviar la factura. Ahora leyendo lo del webservice para la comprobación del NIF veré a ver qué hago.

Se supone que no se puede modificar la factura para cambiar el NIF o el nombre del cliente (por ejemplo uno con apellidos compuestos que tienen guiones supongamos ALBERTO MARTIN-GARCIA FERNANDEZ).

Así que hacienda la factura 10 no la tiene, mi SIF ya tiene generado un registro de envío de la 10 encadenado con la 9 y también uno para la 11 encadenado con la 10 que me devolvió correcto, a pesar de que la 10 no la cogió.

Si ahora decido volver a enviar la 10 eligiendo como decís eso de (otro no censado), ¿tengo que volver a encadenar ese envío de la subsanación de la 10 con la huella de la 20 que fue la última que se envió? y luego cuando envíe la 21, la tengo que encadenar con el envío de la subsanación de la 10 que sería el último enviado? y si me doy cuenta del error mañana la fecha y hora que hay que poner es la del registro del envío de la subsanación, imagino. No la fecha de la factura. ¿no?

Y por último otro problema que tengo es el siguiente, si genero un XML con 200 facturas, el proceso de creación del XML con los encadenamientos, etc me tarda más de los 240 segundos y por tanto cuando lo mando, los primeros registros del conjunto me los acepta con errores por que dice que ha pasado más tiempo del debido. De momento no pienso hacer nada con eso, pero ¿es legal? Gracias de antemano y perdón por el rollo.

[espinete]

Empezado por VJSoftware

Voy a volver sobre este tema de las subsanaciones por si algún alma caritativa me lo deja claro, porque la verdad aún no me entero.

Supongamos que envío un XML con un conjunto de 20 facturas y supongamos que la número 10 me devuelve incorrecto, en mi caso concreto, por el tema del NIF. El resto de posibles errores ya los tengo blindados para que el usuario no los pueda cometer antes de enviar la factura. Ahora leyendo lo del webservice para la comprobación del NIF veré a ver qué hago.

Se supone que no se puede modificar la factura para cambiar el NIF o el nombre del cliente (por ejemplo uno con apellidos compuestos que tienen guiones supongamos ALBERTO MARTIN-GARCIA FERNANDEZ).

Si ahora decido volver a enviar la 10 eligiendo como decís eso de (otro no censado), ¿tengo que volver a encadenar ese envío de la subsanación de la 10 con la huella de la 20 que fue la última que se envió? y luego cuando envíe la 21, la tengo que encadenar con el envío de la subsanación de la 10 que sería el último enviado? y si me doy cuenta del error mañana la fecha y hora que hay que poner es la del registro del envío de la subsanación, imagino. No la fecha de la factura. ¿no?

Y por último otro problema que tengo es el siguiente, si genero un XML con 200 facturas, el proceso de creación del XML con los encadenamientos, etc me tarda más de los 240 segundos y por tanto cuando lo mando, los primeros registros del conjunto me los acepta con errores por que dice que ha pasado más tiempo del debido. De momento no pienso hacer nada con eso, pero ¿es legal? Gracias de antemano y perdón por el rollo.

Piensa que por cada factura puede haber varios "registros de facturación" (XML). Si haces una factura, creas su RF (XML) y lo envías. Si luego tienes que hacer una subsanación, crearás otro RF para la "misma" factura, y lo envías. Este nuevo RF irá encadenado con lo que toque: el último RF generado.

Dicho de otra forma: imagina que no tienes conexión a internet durante un día, pero tu ese día necesitas hacer facturas. Y no solo facturas, sino rectificativas, subsanaciones, etc. Las que quieras (el envío ya lo harás cuando vuelva internet). Pues bien, para que eso sea posible, tu tienes que encadenarlo todo "cronológicamente", a medida que vaya surgiendo lo que tengas que hacer. Olvídate de seguir una numeración correlativa, no tiene que ver con eso. Tu puedes enviar el RF de la factura 1000 después de haber enviado un RF de la Rectificativa 200-R o de un tícket (simplificada) 351-T.

Es difícil que se tarde más de 240 segundos en generar y enviar el XML con 200 facturas, pero si se diera el caso, debes enviar el XML indicando Incidencia = S en la Cabecera.
Esto puedes comprobarlo ANTES de generar la cabecera: compruebas si en el bloque que vas a enviar hay alguna factura que se haya emitido hace más de 240 segundos y, si es así, marcas el envío como Incidencia.

He leído por aquí que algunos marcan todos los envíos como Incidencia aunque no la haya (Hacienda lo acepta), pero no soy partidario de que sea lo correcto.

A mí me respondieron desde VeriFactu que por lo pronto este error y otros similares no los van a tener en cuenta, salvo que sea algo muy recurrente en tu software. Ahí supongo que te dirían algo si lo consideran sospechoso.

[VJSoftware]

Empezado por espinete

Piensa que por cada factura puede haber varios "registros de facturación" (XML). Si haces una factura, creas su RF (XML) y lo envías. Si luego tienes que hacer una subsanación, crearás otro RF para la "misma" factura, y lo envías. Este nuevo RF irá encadenado con lo que toque: el último RF generado.

Dicho de otra forma: imagina que no tienes conexión a internet durante un día, pero tu ese día necesitas hacer facturas. Y no solo facturas, sino rectificativas, subsanaciones, etc. Las que quieras (el envío ya lo harás cuando vuelva internet). Pues bien, para que eso sea posible, tu tienes que encadenarlo todo "cronológicamente", a medida que vaya surgiendo lo que tengas que hacer. Olvídate de seguir una numeración correlativa, no tiene que ver con eso. Tu puedes enviar el RF de la factura 1000 después de haber enviado un RF de la Rectificativa 200-R o de un tícket (simplificada) 351-T.

Es difícil que se tarde más de 240 segundos en generar y enviar el XML con 200 facturas, pero si se diera el caso, debes enviar el XML indicando Incidencia = S en la Cabecera.
Esto puedes comprobarlo ANTES de generar la cabecera: compruebas si en el bloque que vas a enviar hay alguna factura que se haya emitido hace más de 240 segundos y, si es así, marcas el envío como Incidencia.

He leído por aquí que algunos marcan todos los envíos como Incidencia aunque no la haya (Hacienda lo acepta), pero no soy partidario de que sea lo correcto.

A mí me respondieron desde VeriFactu que por lo pronto este error y otros similares no los van a tener en cuenta, salvo que sea algo muy recurrente en tu software. Ahí supongo que te dirían algo si lo consideran sospechoso.

Muchas gracias por la respuesta. Me aclaraste las dudas.

[bmfranky]

Hola, lo que no has de esperarte tanto para generar el registro a enviar, si realmete te tarda tanto en generar y enviar, no apures, envia cada menos, envez de esperar los 240" envia a los 210 y mientras generas cumples con los 60" o lo que te inmpongan , no has de esperar 240" para enviar.
La cronologia es , envias el primer envio del dia, antes de cumplir 240" del primer registro, poner a 0 el contador e inicializar la cuenta de 60" o lo que te pidan par impedir un n uevo envio, en el momento de generrse un registro que encolas pones a 0 el contador de envios, cuando llegue a 210", seguro que has superado los x segundos que te indican en la respuesta, cierras el xml a enviar y envias, poniendo a 0 el contador de de registros de los 210" si se genera alguno, entre tanto recuperas el tiempo de espera, lo asignas y activas el contador, vas encolando si se generan registros de alta, abono, alta de subsanacion etc... y lo mismo , al llegar a 210" del primer registro encadenado, seguro qe has superado los segundos de espera, envias y vuelves a empezar, es lioso de explicar pero sencillo de implementar.
2 contadores uno de espera minima en principio 60" que se inicializa con el tiempo de la respuesta y tiende a 0 cada segundo y otro de espera maxima que empieza en 0 al encolar el primer registro, ya sea del dia , desde inicio del SIF o desde el anterior envio, y se incrementa hasta llegar a 210" por ejemplo y una subrutina que se encarga cada segundo de decrementar el de 60" si mayor a 0 y de incrementar el de 210 si menor a 210, cuando llegues a 210" envias lo que hay encolado en la tabla que almacenas los registros a enviar y vuelves a empezar.

[Jarogo08]

Empezado por bmfranky

Hola, lo que no has de esperarte tanto para generar el registro a enviar, si realmete te tarda tanto en generar y enviar, no apures, envia cada menos, envez de esperar los 240" envia a los 210 y mientras generas cumples con los 60" o lo que te inmpongan , no has de esperar 240" para enviar.
La cronologia es , envias el primer envio del dia, antes de cumplir 240" del primer registro, poner a 0 el contador e inicializar la cuenta de 60" o lo que te pidan par impedir un n uevo envio, en el momento de generrse un registro que encolas pones a 0 el contador de envios, cuando llegue a 210", seguro que has superado los x segundos que te indican en la respuesta, cierras el xml a enviar y envias, poniendo a 0 el contador de de registros de los 210" si se genera alguno, entre tanto recuperas el tiempo de espera, lo asignas y activas el contador, vas encolando si se generan registros de alta, abono, alta de subsanacion etc... y lo mismo , al llegar a 210" del primer registro encadenado, seguro qe has superado los segundos de espera, envias y vuelves a empezar, es lioso de explicar pero sencillo de implementar.
2 contadores uno de espera minima en principio 60" que se inicializa con el tiempo de la respuesta y tiende a 0 cada segundo y otro de espera maxima que empieza en 0 al encolar el primer registro, ya sea del dia , desde inicio del SIF o desde el anterior envio, y se incrementa hasta llegar a 210" por ejemplo y una subrutina que se encarga cada segundo de decrementar el de 60" si mayor a 0 y de incrementar el de 210 si menor a 210, cuando llegues a 210" envias lo que hay encolado en la tabla que almacenas los registros a enviar y vuelves a empezar.

Nosotros lo tenemos de otra manera... es un servicio de windows que salta por defecto cada 60 segundos (controlado con el propio timer del servicio). La mayoría de las veces no habrá nada para enviar y estará saltando cada 60 segundos pero cuando sí encuentre algo entonces para el timer, envía, obtiene la respuesta, coge el valor de "TiempoEsperaEnvio" (que en las pruebas que hago siempre me devuelve 60), y vuelve a poner en marcha el timer asignándole como intervalo el valor de "TiempoEsperaEnvio".

De esta manera enviará o intentará enviar cada 60 segundos. Pero si un día la respuesta del envío dice que tenemos que esperar por ejemplo 200 segundos automáticamente el timer pasará a saltar cada 200 segundos.

No sé si alguien más lo tiene así o si le veis alguna traba!

Saludos

[VJSoftware]

Empezado por Jarogo08

Nosotros lo tenemos de otra manera... es un servicio de windows que salta por defecto cada 60 segundos (controlado con el propio timer del servicio). La mayoría de las veces no habrá nada para enviar y estará saltando cada 60 segundos pero cuando sí encuentre algo entonces para el timer, envía, obtiene la respuesta, coge el valor de "TiempoEsperaEnvio" (que en las pruebas que hago siempre me devuelve 60), y vuelve a poner en marcha el timer asignándole como intervalo el valor de "TiempoEsperaEnvio".

De esta manera enviará o intentará enviar cada 60 segundos. Pero si un día la respuesta del envío dice que tenemos que esperar por ejemplo 200 segundos automáticamente el timer pasará a saltar cada 200 segundos.

No sé si alguien más lo tiene así o si le veis alguna traba!

Saludos

Y ¿sería legal generar los RF a futuro? es decir, imaginemos que son las 10:00:00. Voy encadenando tickets con la fechahorausohorario a las 10:20:00 cuando realmente llegue esa hora, mando todo lo que tenga encadenado. ¿Cómo lo veis a nivel legal?

[[newtron]]

Empezado por VJSoftware

Y ¿sería legal generar los RF a futuro? es decir, imaginemos que son las 10:00:00. Voy encadenando tickets con la fechahorausohorario a las 10:20:00 cuando realmente llegue esa hora, mando todo lo que tenga encadenado. ¿Cómo lo veis a nivel legal?

Nidecoña. De forma normal no puede pasar más de 60s desde que se genera la factura hasta que se envía.

[Faneka]

Efectivamente, se tiene que enviar el RF al 'instante' de crearlo. Además si el cliente de turno le da por leer el QR puede decirte, aquí me dice que no esta en el portal, xD.

[ermendalenda]

Empezado por espinete

Si, eso está claro. Lo que quiero decir es que aunque no indiques "Subsanación = S", te la aceptan, y no deberían. Deberían requerir indicar "subsanación = S", pero no lo están haciendo.
Obviamente mi intención es enviarla como subsanación, pero haciendo pruebas me pareció raro que las aceptaran sin indicarlo.

Vamos, que siendo tan tiquismiquis con todo lo demás, me parece raro que con esto se lo estén saltando, al menos por ahora.

Perdón error

[ermendalenda]

Empezado por Jarogo08

Nosotros lo tenemos de otra manera... es un servicio de windows que salta por defecto cada 60 segundos (controlado con el propio timer del servicio). La mayoría de las veces no habrá nada para enviar y estará saltando cada 60 segundos pero cuando sí encuentre algo entonces para el timer, envía, obtiene la respuesta, coge el valor de "TiempoEsperaEnvio" (que en las pruebas que hago siempre me devuelve 60), y vuelve a poner en marcha el timer asignándole como intervalo el valor de "TiempoEsperaEnvio".

De esta manera enviará o intentará enviar cada 60 segundos. Pero si un día la respuesta del envío dice que tenemos que esperar por ejemplo 200 segundos automáticamente el timer pasará a saltar cada 200 segundos.

No sé si alguien más lo tiene así o si le veis alguna traba!

Saludos

Hola, lo veo arriesgarl por no decir MAL, a ver, te pongo un escenario:
Envías a las 12:30:05 por que tu timer ha llegado a los 60segundos y había 1 ó 2 registros.inmed8atemente están generando un registro que se graba a las 12:30:07 que no entra en ese lote, pero es que tampoco podría entrar en wl siguiente por que no ha llegado a los 60 segundos de antigüedad, con lo cual cuando lo vayas a enviar tiene 118segundos, con lo cual ese envío tiene que estar finalizado en 2 segundos máximo, es arriesgado.
O sea, todo lo que generes después de el último envio no lo puedes enviar hasta que cumpla cada uno de ellos 60 segundos, lo siento, pero lo tienes mal.
Repasalo
Por ejemplo:
Reduce el timer a 10 segundos y mira cada registro pendiemte si ya ha cumplido los 60 segundos y metelos en el lote de envío.

[novatico]

Yo lo tengo como Jarogo08, con una pequeña variación:
- Tras recoger la respuesta del envío realizado y comprobar el tiempo de espera, es entonces donde hago una pausa con ese valor, y tras ello vuelvo a comprobar si ya hay más registros de facturacion pendientes de enviar.

[bmfranky]

Empezado por newtron

Nidecoña. De forma normal no puede pasar más de 60s desde que se genera la factura hasta que se envía.

O si, como mínimo 61" de tiempo entre generar y enviar, teniendo en cuenta que si solo enviamos de 1 en 1 registro "Deberíamos" esperar los t" , segundos que nos indican en la respuesta del envío antes del siguiente, aunque que a efectos prácticos, realmente tienes razón y no sera 60, segundos porque mientras generas el ticket algunos segundos tardas... , incluso un cajero avanzado no tarda 1" en finalizar y cobrar un ticket (Digo ticket porque es lo mas rápido de gestionar que se me ocurre, un ticket de supermercado.), aunque un supermercado de mas de 1 caja , imagino que tendrán la generación de tickets de caja centralizada, y el servidor sera el encargado de encolar los registros y enviarlos y demás y no la caja...

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

Empezado por Jarogo08

Nosotros lo tenemos de otra manera...
* es un servicio de windows que salta por defecto cada 60 segundos (controlado con el propio timer del servicio).
* La mayoría de las veces no habrá nada para enviar y estará saltando cada 60 segundos pero cuando sí encuentre algo entonces para el timer, envía, obtiene la respuesta, coge el valor de "TiempoEsperaEnvio" (que en las pruebas que hago siempre me devuelve 60),
* y vuelve a poner en marcha el timer asignándole como intervalo el valor de "TiempoEsperaEnvio".

De esta manera enviará o intentará enviar cada 60 segundos. Pero si un día la respuesta del envío dice que tenemos que esperar por ejemplo 200 segundos automáticamente el timer pasará a saltar cada 200 segundos.

Nosotros lo tenemos igual.

Empezado por ermendalenda

Hola, lo veo arriesgarl por no decir MAL, a ver, te pongo un escenario:

1) Envías a las 12:30:05 por que tu timer ha llegado a los 60segundos y había 1 ó 2 registros.
2) inmed8atemente están generando un registro que se graba a las 12:30:07 que no entra en ese lote, pero es que tampoco podría entrar en wl siguiente por que no ha llegado a los 60 segundos de antigüedad, con lo cual cuando lo vayas a enviar tiene 118segundos, con lo cual ese envío tiene que estar finalizado en 2 segundos máximo, es arriesgado.

Creo que en este caso el error de concepto está aquí:
"pero es que tampoco podría entrar en wl siguiente por que no ha llegado a los 60 segundos de antigüedad"

Un registro NO DEBE enviarse con más de 240 sg. de antigüedad, de otra forma hay que marcarlo con INCIDENCIA, pero lo que es incorrecto es que no se pueda enviar con menos de 60 sg. de antigüedad.
Tú puedes geberar un Registro de Facturación y enviarlo 2 sg. después, no hay problema, siempre y cuando el último envío haya sido hace 60 sg.

Es decir, el escenario que dice [Jarogo08], que tenemos nosotros y que es correcto sería por ejemplo este:

12:00:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:01:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:01:10 Generamos factura 1
12:01:45 Generamos factura 2
12:02:00 Se prepara envío (2 facturas);  60 sg. de espera
12:03:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:03:10 Generamos factura 3
12:03:20 Generamos factura 4
12:03:30 Generamos factura 5
12:03:40 Generamos factura 6
12:03:50 Generamos factura 7
12:04:00 Se prepara envío (5 facturas); AEAT contesta con 120 sg. de espera
12:06:00 Se prepara envío (como es vacio, no se envía NADA); 120 sg. de espera
12:08:00 Se prepara envío (como es vacio, no se envía NADA);  120 sg. de espera
12:09:50 Generamos factura 8
12:10:00 Se prepara envío (1 factura); AEAT contesta con 60 sg. de espera
12:11:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
...

NOTA ACLARATORIA: No lo había puesto para simplificar. Cuando aparece "se genera envío (vacío)" realmente el sistema no envía. Detecta que no hay nada y lo que hace es esperar hasta el siguiente. (no conecta con la AEAT)

[rci]

Empezado por ermendalenda

Hola, lo veo arriesgarl por no decir MAL, a ver, te pongo un escenario:
Envías a las 12:30:05 por que tu timer ha llegado a los 60segundos y había 1 ó 2 registros.inmed8atemente están generando un registro que se graba a las 12:30:07 que no entra en ese lote, pero es que tampoco podría entrar en wl siguiente por que no ha llegado a los 60 segundos de antigüedad, con lo cual cuando lo vayas a enviar tiene 118segundos, con lo cual ese envío tiene que estar finalizado en 2 segundos máximo, es arriesgado.
O sea, todo lo que generes después de el último envio no lo puedes enviar hasta que cumpla cada uno de ellos 60 segundos, lo siento, pero lo tienes mal.
Repasalo
Por ejemplo:
Reduce el timer a 10 segundos y mira cada registro pendiemte si ya ha cumplido los 60 segundos y metelos en el lote de envío.

el tiempo máximo ya no son 120 segundos, son 240 ahora mismo. yo creo que tienes tiempo de hacerlo como dice Jarogo08.

Nosotros lo hacemos de forma muy similar, el servicio tiene una tarea que salta siempre cada 60 segundos. en ese momento comprueba el valor t que contestó el último envío y la fecha del último envío. Si ya ha pasado el tiempo o si hay mas de 1000 registros, envía. sino vuelve a esperar 60 segundos y vuelve a comprobar.

Los 60 segundos de espera de nuestra tarea podría ser otro valor, por ejemplo 30... también habíamos probado con 1 segundo pero en ese caso consumía muchos recursos y no hace falta. mientras se despierte una vez cada minuto creo que ya está bien

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

Creo que os estáis liando con el tema de tiempos.
Lo que tiene que esperar 60 segundos son los envíos, no un registro de facturación para ser enviado.
Un Registro de Facturación puede enviarse 1 sg. después de haberse generado (siempre que en los últimos 60 sg. no hayas hecho un envío).

[rci]

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

Creo que os estáis liando con el tema de tiempos.
Lo que tiene que esperar 60 segundos son los envíos, no un registro de facturación para ser enviado.
Un Registro de Facturación puede enviarse 1 sg. después de haberse generado (siempre que en los últimos 60 sg. no hayas hecho un envío).

Exactamente

[bmfranky]

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

Nosotros lo tenemos igual.

12:00:00 se genera Primer* envío (vacio); AEAT contesta con 60 sg. de espera <<<<------ A partir de este, no seria mas eficiente para los recursos del sistema, comprobar si no hay cola y 
                                                                                                                 no enviar nada, simplemente quedar a la espera del siguiente envió  predefinido de la anterior respuesta?
 12:01:00 Si cola vacía, se espera 60 sg. 

12:01:10 Generamos factura 1
 12:01:45 Generamos factura 2
12:02:00 se genera envío (2 facturas); AEAT contesta con 60 sg. de espera
12:03:00  Si cola vacía, se espera 60"
12:03:10 Generamos factura 3
12:03:20 Generamos factura 4
12:03:30 Generamos factura 5
12:03:40 Generamos factura 6
12:03:50 Generamos factura 7
12:04:00 se genera envío (5 facturas); AEAT contesta con 120 sg. de espera
12:06:00 se genera envío (vacio); AEAT contesta con 120 sg. de espera
12:08:00 se genera envío (vacio); AEAT contesta con 120 sg. de espera
12:09:50 Generamos factura 8
12:10:00 se genera envío (1 factura); AEAT contesta con 60 sg. de espera
12:11:00 se genera envío (vacio); AEAT contesta con 60 sg. de espera
...

Creo que seria mas eficiente para los recursos, comprobar si hay algo que enviar, si no lo hay volver a esperar el tiempo inicial de 60", no ir enviando consultas a la aeat, cada minuto por que si, no creéis?



*El primer envío es el de puesta en marcha del servicio.

[rci]

Empezado por bmfranky

Creo que seria mas eficiente para los recursos, comprobar si hay algo que enviar, si no lo hay volver a esperar el tiempo inicial de 60", no ir enviando consultas a la aeat, cada minuto por que si, no creéis?

Si, yo tampoco entiendo a que te refiere exactamente neftali con

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

se genera envío (vacio); AEAT contesta con 60 sg. de espera

Si no hay registros pendientes de envío ya no se envía nada y AEAT no contesta no?

[Jarogo08]

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

Creo que os estáis liando con el tema de tiempos.
Lo que tiene que esperar 60 segundos son los envíos, no un registro de facturación para ser enviado.
Un Registro de Facturación puede enviarse 1 sg. después de haberse generado (siempre que en los últimos 60 sg. no hayas hecho un envío).

Exactamente + 2