En nuestro programa hay una marca visual que avisa cuando ha ocurrido algo, por ejemplo si ha habido problemas al enviar facturas a Veri*Factu.
El usuario encargado tendrá que consultar esos avisos, y corregir lo que haga falta, si procede.

Si el usuario no lo hace, pienso que es su problema, no del desarrollador. Pero si... vamos a tener un montón de llamadas

Si
Ya se hizo la consulta

Si haces un wnvio de 1000 registros con incidencias y en el segundo envío no hay incidencias y están en tiempo no tienes que marcarlo, además so no r3cuerdo mal tendrías que mandarlo inmediato.

A ver si a ti no te contestan una cosa y a mi la contraria :eek:

Buenas.


Ya me han contestado, y queda clara la respuesta:


PREGUNTA:

Supongamos que estuve 2 horas sin internet y en ese tiempo hice 10 facturas/tickets. Si ahora ya tengo internet y aparte de esos 10 registros “antiguos” (que tienen más de 240 segundos) tengo otros 2 que hice hace 20 segundos por ejemplo…

Si en este momento salta el proceso que me va a subir los registros a Verifactu, ¿Qué opción sería correcta?

1- Crear un único envío con los 12 registros y con la marca “Incidencia” a “S” (teniendo en cuenta que de los 12 registros 2 realmente no son incidencia)

2- Crear dos envíos: uno con los 10 registros “antiguos” y con la marca “Incidencia” a “S” y otro con los 2 registros “nuevos” y sin marca de incidencia. Puedo hacer los 2 envíos sin esperar 60 segundos, uno a continuación de otro

3- Crear dos envíos: uno con los 10 registros “antiguos” y con la marca “Incidencia” a “S” y otro con los 2 registros “nuevos” y sin marca de incidencia. Entre ambos envíos tendría que esperar 60 segundos



RESPUESTA:

Gracias por su consulta.
La respuesta correcta a su planteamiento es la número 3.


Osea que los que marcáis un envío como incidencia pero lleva registros que no lo son, lo estáis haciendo mal. Y yo que hago dos envíos pero uno a continuación de otro también :(

Pues vaya, supongo que tendré que cambiarlo.
Eso si la interpretación del funcionario es la correcta :( porque yo no he visto nada de eso en la ley.
Por lo que veo, no han derivado la pregunta a niveles superiores, ya que han contestado relativamente rápido.

A ver si le contestan lo mismo a ermendalenda

Pues mira que bien, justo como lo hago yo, :)

Ya lo he cambiado, pero yo aquí veo un "vacío legal"...

Imaginemos una empresa que tiene muchos tickets (tipo supermercado/cafetería con varias cajas) y se genera un ticket cada 30 segundos. Si enviamos los registros con incidencias y esperamos 60 segundos, el registro que se hizo hace 210 segundos y que antes no tenía incidencia ahora pasará a tenerla. Lo enviamos y esperamos otros 60 segundos. El registro que se hizo hace 180 segundos y que antes no tenía incidencia ahora pasará a tenerla, etc.
Con lo que estaríamos mandando todos los envíos como incidencias. Vale que es un caso extremo... lo normal es que antes o después no haya movimientos durante un par de minutos y ya se regularice, pero bueno... muy bien planteado no lo veo :confused:

Siguiendo con el tema, en el BOE, reza esto.

Según entiendo leyendo el BOE, se debe indicar incidencia, desde que ocurrió la incidencia(Valga la redundancia) y mientras quede algún registro por enviar, osea que si desde que se activa la incidencia , hasta que se puede re emprender el envío de los Registros generas 100, da igual cuando, los has de enviar todos los que tengas encolados en un envío, y entonces quitar la marca de incidencia y volver a encolar, ademas de dejar de mostrar al usuario el mensaje de incidencia que lo indica, no pone nada de solo enviar los que provocaron la incidencia, sino mas bien todos los que haya desde que se origino la incidencia , hasta que dejo de existir la misma.


Realmente a efectos practicos, lo de notificar incidencia, solo evita que responda con el error "2004", por pasarte del tiempo, o por lo menos eso era lo que hacia cuando lo prove.

Tal como lo planteas puede entenderse que los 10 registros estan listos para enviar y que en ese momento te viene Internet,
logicamente tendrias que enviarlos de inmediato, y los otros dos que generes seria otro envio adicional esperando el tiempo que te indiquen.

Si por el contrario le huebieses planteado que tienes los 12 registros listos para enviar y que esos 2 ultimos se han generado en los ultimos 20 segundos y en ese momento te llega internet.,
Yo pienso que el paquete igualmente hay que enviarlo con Incidencia, ya que hay registros que se
salen del tiempo maximo de envio e igualmente tienen la incidencia de que no se han podido enviar de inmediato por falta de Internet sin que tengan retraso los dos ultimos.

Tened en cuenta que aun no han incluido una casilla para incluir el motivo de la incidencia, aunque ellos si que ponen en el BOE que hay que indicar el motivo.

Eso mismo lw iba a decir yo

También pregunté si lo estaba haciendo bien, enviando en un solo paquete con incidencia todos los registros (aunque algunos no la tengan) y pidiendo donde ponía en la ley, que se tenia que separar en dos envíos.
Me han contestado lo siguiente:

Pues te contestaron lo mismo que a mí, dejándolo muy clarito: dos envíos (las incidencias por un lado y los que no son por otro) y esperando los 60 segundos. Así habrá que hacerlo

Osea que desde que ocurre la incidencia , hay que tener 2 colas,
1-> una con los registros que presentaron la incidencia.
2-> una con los registros recien generados y que estén en plazo de envío - 60"


Ademas de tener un script/función, que cada 60" verifique si algún registro de la cola 2 se paso de tiempo y añadirlo a la 1 y ademas verificar si ya paso la incidencia, para realizar el envio 1 y encender el temporizador de envio de la 2.


Complicar por complicar.

¿estás seguro? Yo no lo he planteado así, de hecho hacer el cambio no me supuso casi nada.

1- salta el proceso que envía. ¿hay registros pendientes de enviar? Pasamos al punto 2
2- ¿alguno de esos registros pendientes tiene más de 240 segundos? preparamos un envío sólo con esos y los enviamos (marcando la cabecera con Incidencia a "S")

Y ya... en 60 segundos vuelve a saltar el proceso y estamos nuevamente en el punto 1

¿le véis pegas a este método?

Hola, es que lo que te están diciendo es que solo puedes enviar en la cola de incidencia registros generados con la misma, osea, que si generas un registro y nada mas generado ya se puedenen enviar, ese y los que tengan menos de 180" de antigüedad, no los puedes enviar con los antiguos, los has de encolar en el siguiente envío, porque no tienen incidencia.

A lo que me refiero es que un registro pude tener menos de 240" de antigüedad, pero si tiene 181", y esperas 60" ya sale con retraso ergo error 2004, por 1 segundo, pero lo tiene.

Me imagino la formula así, (TimestampActual - TimestamGenerado)+60 >=240 pues a la cola de error.

O sea pinta que tocará mandar incidencias hasta que los registros cumplan con el tiempo de envío. La verdad que muy sencillo no lo ponen estos de la AEAT.

correcto, pero entiendo que es lo que hay que hacer. Ese error 2004 que entra aceptado con errores lo podrás subsanar después (el 2004 en concreto ni siquiera sería necesario)

Ese problema ya lo exponía un poco más arriba:


Pero entiendo que es la manera correcta

No, porque entonces estarás mandando uno que tiene 190 segundos como incidencia, y te dice que no puede ser.


vuelvo a insistir, creo que el método correcto es (según yo, claro :D):

1- salta el proceso que envía. ¿hay registros pendientes de enviar? Pasamos al punto 2
2- ¿alguno de esos registros pendientes tiene más de 240 segundos? preparamos un envío sólo con esos y los enviamos (marcando la cabecera con Incidencia a "S")

En 60 segundos vuelve a saltar el proceso y estamos nuevamente en el punto 1

Yo he preguntado al correo de Verifactu lo mismo y esto es lo que me han contestado:

Buenos días:

Por un lado, le informamos que el envío de 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 (actualmente es el umbral establecido) 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: 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.

Por otro lado, se ha establecido un mecanismo de control de flujo que determina que deben transcurrir 60 segundos tras la última presentación o bien acumular 1000 registros a enviar, la circunstancia que ocurra primero, para poder remitir el siguiente envío.

Por lo tanto, en casos de grandes volúmenes, si generar 1000 registros antes de los 60 segundos, podrá realizar la siguiente remisión. Si no es el caso y deben generar un gran lote de facturas, a medida que vayan generando los registros de facturación, cuando transcurran 60 segundos deben realizar el envío de los registros que hayan generado hasta ese momento y así sucesivamente cada 60 segundos.

Únicamente en caso de incidencias que impidan la inmediata remisión, por causas ajenas al SIF, como pérdida de internet, certificado electrónico caducado o problemas en el hardware que lo soporta, deben agrupar todos los registros generados durante dicho intervalo y marcar el campo denominado "Incidencia" a "S" de la cabecera de la remisión. Pueden consultar más detalles en el artículo 16 de la Orden HAC/1177/2024, de 17 de octubre.

Yo voy a tomar la siguiente decisión:
Cada vez que tenga que realizar un envío, voy a mirar todos los Registros de Facturación pendientes de enviár (en mi caso no puede darse que superen los 1000), me voy a posicionar en el último Registro de Facturación. Si éste supera los 240 segundos, entonces marcaré el envío con "Incidencia=S". en caso contrario no. De forma que, si algún Registro de facturación supera los 240 segundos, volverá como "Aceptado con errores", pero como no debe subsanarse, no tengo que hacer nada.

Gracias
Me acabo de enterar que han subido el tiempo a 240segunfos
Esto no termina

Supongo que funcionará... pero no estarás cumpliendo lo que dice la ley (mandas registros "antiguos" sin la marca "Incidencia=S")

¿te supone mucho cambio hacerlo de otra manera? ordenas de más reciente a más antigo, y si el último de la lista (el más antiguo) supera los 240 segundos haces un envío con todos los que se pasen de esos 240 segundos. Y los más recientes quedan para el próximo envío que será en 60 segundos

Ojo, parece que pueden estar cambiando el.flujo de envios desde que han puesto los 240 segundos de margen.
Antes tenías que enviar todo lo pendiente(pasados los 60 segundos) como incidencia
Ahora parece que al tener más margen, te dicen que no, que envíes solo los que están como incidencia revisar control De flujos, lo han complicado.

Por como tengo diseñado el Control de Flujo, solamente puede haber registros que superen los 240 segundos, porque se se haya producido un problema en el sistema, por alguna de las causas que ellos mismos especifican, pues el proceso va a estar revisando cada 60 segundos. Realmente, si supera los 240 segundos, lo superará por mucho más.

Si quieren cambiar eso tienen que cambiar una cosa.
Imaginaos que pasa
Se va la Red
Vuelve y me encuentro con 2 registros
Uno que ha pasado 1 hora
Otro que han pasado 200segundos
Si solo envias el primero como incidencia y te devuelven que esperes 60 segundos al enviar el siguiente también tienes que enviarlo como incidencia.
O una de 3:
Opcion 1: cuando mandas una incidencia te envían t=0 envías inmediatamente el que no está como incidencia
Opcion 2: todos los que hayan pasado de 180 segundos enviarlos como incidencia.
Opcion 3:Que te digan como antes, que mandes todo como incidencia.

Anteriormente, tengo consultas que si intentabas enviar un registro y no te daba conexión, ya podías marcarlo como incidencia y marcarlo como tal.
Si no he entendido mal, ahora si están dentro de los 240segundos hay que enviarlos aparte.
Como sean la opción 1 ó 2 a cambiar control de flujos toca.

Interminable
Enviada consulta, a ver que responden

Podrías coger esos correos de respuesta de consultas donde indicaban eso y repreguntar para comprobar si te dicen que han cambiado el criterio...

o la opción 4... envías el que ha pasado 1 hora como incidencia, te devuleven 60 segundos, los esperas, y mandas el que ha pasado 200 + 60 como incidencia (que creo que es el correcto)

Coreecto, parece que es la que proponen, pero la veo absurda, ya que la interpretación del control de flujos puede dar lugar a 2 interpretaciones.
Como ese registro ya estuvo en tiempo de envio(el de 200segundos), ya intenté enviarlo hace 1 minuto(por ejemplo) y al no poder mandarlo lo pude marcar como incidencia, o no?
Yo lo veo hasta opcional.

La Incidencia, vuelvo a repetir, es porque no lo has podido enviar en el tiempo que se genero por causas externa, como que no tienes Internet, en nignun sitio
pone que sea por que se haya pasado los 240 segundos, sino al contrario, que debemos marcarlo por que ha habido una incidencia a la hora de enviar.

Yo he echo la consulta y estoy esperando la respuesta.

Pero no tiene ninguna logica ese planteamiento, ya que lo que quiere la AEAT es tener los registros en el momento, y hacer dos envios de lo mismo
generado en el mismo paquete que se va a enviar lo veo absurdo, ya que como digo la Incidencia es de todos, no solo de los 240 segundos.

Veremos lo que me contestan.

Tambien hay que tener cuidado con quien te contesta, ya que hemos visto en otras preguntas que se les ha echo que pueden tener un caracter subjetivo.
No son inspectores los que contestan.

También he mandado xonsulta, no parece que esté muy bien detallado (o analizado) cierto escenarios.

Hola,

Perdón por la duda, pero siempre hablamos de los 240 segundos como límite máximo para el envío.
Pero no encuentro ese dato de los 240 segundos en ninguno de los documentos oficiales publicados hasta ahora.
¿Alguien me puede indicar en qué documento aparece ese límite?
Gracias.

Saludos

También podemos pedirles que en lugar de poner "Incidencia=S", se pueda poner "Incidencia=P" que signifique "Parcialmente incidencia" jajajajaja

Perdón, perdón, necesitaba poner un poquito de humor.

Si miras más atrás, verás un post mío con una respuesta de verifactu en que dicen que actualmente, ese es el tiempo límite.

Sí, lo había leído. Gracias.
Pero lo que no encuentro es la normativa legal que establece ese tiempo límite en 240 segundos.

Saludos

Hola, normativa legal no hay, pero es lo que responde el error 2004, así que es a lo que nos acogemos.

Los 240 segundos, no es un periodo de gracia para enviar es un margen de error de tiempo, si no por que la hora de tu sistema no esté con la misma hora sincronizada que lps servidores de hacienda, en la OM ese tiempo de desfase estaba a 60 segundos, supongo que al igual que yo les dije que ese tiempo era demasiado restrictivo además de que tebia un fallo al poner el t +60 ya que no contemplaban los posibles retardos de envio y que lo lógico que fuera los 60 segundos más un tiempo prudencial de envío, me respondieron que era correcto y que lo aumentarian levemente, tal y comente en otro post, y como digo, se habrán quedado más gente lo han aumentado a 240.
A tu pregunta si está detallado en algún documento es no, es una información adicional que te pueden proporcionar o puedes ver en la respuesta de un envio enviado fuera de ese intervalo de 240 segundos, por consiguiente no cabe quejarse por una mejora en las restricciones de la OM

Ayer envié una consulta al respecto de los envíos como incidencia sí o no de los registros recientes después de 60 segundos si se envían o no.
Y me han dado la respuesta genérica de que lo que se envíe fuera de hora es como incidencia y el resto no.
Pero esta mañana les puse una consulta mucho más detalla con el ejemplo que puse en este hilo de un registro con 200 segundos. A ver que me contestan a ese.

Aclarado, podéis enviarlo en el mismo envío de la incidencia o no. Según el control de flujos que hagáis

Aquí tenéis la respuesta clara: