Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Envío de registros y sus respuestas (https://www.clubdelphi.com/foros/forumdisplay.php?f=66)
-   -   Reenvío de facturas el Entorno de Pruebas SIN especificar Subsanación (https://www.clubdelphi.com/foros/showthread.php?t=97365)

Jarogo08 14-05-2025 17:27:04

jajaja, me da la risa


Acaban de contestarme a mi también, diciendo lo contrario (volví a repreguntar aunque ya me lo dijeran antes https://www.clubdelphi.com/foros/sho...8&postcount=85):


MI PREGUNTA:
Cita:

Supongamos que estuve 2 horas sin internet y en ese tiempo aparecieron 4 facturas:

-Factura 10: la hice hace 1 hora
-Factura 11: la hice hace 220 segundos
-Factura 12: la hice hace 150 segundos
-Factura 13: la hice hace 30 segundos



¿Tendría que hacerlo de esta manera?

Salta el proceso de envío:
1- ¿hay registros que tienen más de 240 segundos de antigüedad? Sí, la factura 10 -> la envío marcada como incidencia. Espero 60 segundos
2- ¿hay registros que tienen más de 240 segundos de antigüedad? Sí, porque la factura 11 ahora tiene 220 + 60 = 280 segundos de antiguedad -> la envío marcada como incidencia. Espero 60 segundos
3- ¿hay registros que tienen más de 240 segundos de antigüedad? Sí, porque la factura 12 ahora tiene 150 + 60 + 60 = 270 segundos de antiguedad -> la envío marcada como incidencia. Espero 60 segundos
4- ¿hay registros que tienen más de 240 segundos de antigüedad? No. La factura 13 ahora tiene 30 + 60 + 60 + 60 = 210 segundos de antiguedad -> la envío SIN la marca de incidencia. Si en este tiempo apareció por ejemplo la factura 14 también iría en este envío. Espero 60 segundos

¿esto es correcto? ¿hacer 3 envíos de incidencias y uno normal?

SU RESPUESTA:
Cita:

Sí, el proceso descrito en su consulta es correcto:
Se deben realizar 3 envíos con la marca de incidencia, ya que las facturas 10, 11 y 12 superan los 240 segundos de antigüedad al momento de realizarse el envío.
Una factura (la 13) será enviada sin la marca de incidencia, ya que no supera el umbral de 240 segundos.El sistema sigue el flujo lógico de esperar 60 segundos entre envíos para no generar un flujo excesivo de registros.
Recuerde que en este proceso, los registros agrupados deben ser enviados de forma ordenada, y una vez recuperada la conexión, los envíos deben respetar las pausas de 60 segundos entre cada envío para no violar las restricciones de flujo del sistema. Este mecanismo ayuda a mantener un control adecuado sobre el volumen de datos y asegura que los registros con incidencias sean correctamente gestionados.

Quedamos a su disposición para cualquier aclaración adicional.


rci 14-05-2025 17:44:19

Cita:

Empezado por Jarogo08 (Mensaje 564612)
jajaja, me da la risa

Acaban de contestarme a mi también, diciendo lo contrario

Cada funcionario interpreta la ley como le parece...

A mi me parece una tontería no enviar todos los registros de golpe en un mismo envío y marcando como incidencia, la verdad.
y aun más porque, del ejemplo de Jarogo08, las facturas 11 y 12, al final también se mandan como incidencia, cuando realmente no la han tenido, bueno si, por "culpa" de que quieren que separemos en dos envíos los registros con incidencia de los que no. Pero realmente la incidencia de que no había internet, podría solo afectar a las otras...
En fin... tendremos que ver como lo hacemos....

Saludos

delphiGar 14-05-2025 17:49:09

Cita:

Empezado por ermendalenda (Mensaje 564611)
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:

Eso tiene logica, lo que no tiene es lo de los dos envios con RF generados en la misma incidencia, esten fuera de plazo o no.

El documento de validaciones dice:

Incidencia

Código:

Indicador que especifica si la remisión voluntaria de los registros de facturación se ha visto afectada por
algún tipo de incidencia técnica (por ej. ausencia de corriente eléctrica, problemas de conexión a Internet, fallo del sistema informático de facturación…).
Si no se informa este campo se entenderá que tiene valor “N”. Este campo forma parte del detalle de las circunstancias de generación de los registros de facturación.
A rellenar sólo en los casos de remisión voluntaria «VERI*FACTU» cuando haya ocurrido alguna situación de este tipo.

Esta bastante claro que no dice nada de los X segundos que tiene que tener el RF una vez generados, sino que por una Incidencia tecnica no se puede enviar al momento, independiente de los tiempos de espera.

ermendalenda 14-05-2025 17:50:14

Cita:

Empezado por rci (Mensaje 564616)
Cada funcionario interpreta la ley como le parece...

A mi me parece una tontería no enviar todos los registros de golpe en un mismo envío y marcando como incidencia, la verdad.
y aun más porque, del ejemplo de Jarogo08, las facturas 11 y 12, al final también se mandan como incidencia, cuando realmente no la han tenido, bueno si, por "culpa" de que quieren que separemos en dos envíos los registros con incidencia de los que no. Pero realmente la incidencia de que no había internet, podría solo afectar a las otras...
En fin... tendremos que ver como lo hacemos....

Saludos

Si, eso también les he preguntado, qur aunqur yo los he intenso enviar y al no poder comprobarse si ya he intentado enviarlos serán lados en aceptarlos en el paquete de incidencia. Y me han respondido que Correcto.
Así que yo no le voy a dar más vueltas.
Todos los que hayan cumplido los 60 segundos o más al volver la conexion, marcados como incidencias y palante.
Habrás pillado el cambio de turno. La próxima vez pregunta por Paquito "el de los flujos"

ermendalenda 14-05-2025 17:58:33

Os pongo la pregunta y respuesta completa, que creo que son claras:
Cita:





Aclaro un poco mis dudas sobre este tema que quizas no me explicado extensamente:
Quizas mi interpretación de esta parte del envio de incidencias cuando existe la casualidad de que hay registros pendientes y según mi interpretación a un correo anterior sobre el mismo hilo,:
----------------------------------------------
...mientras ocurra una incidencia que impida la remisión inmediata de los registros, éstos deben ir acumulándose y el SIF debe tratar de realizar su envío de forma periódica tal y como se indica en la*Orden HAC/1177/2024, de 17 de octubre*en su artículo 16, punto 4. Todos los registros generados durante el intervalo de tiempo en el que transcurre la incidencia, quedarán acumulados para que, en cuanto se solvente la incidencia, sean remitidos*respetando el orden temporal de generación de los registros. Por lo tanto, antes de remitir un registro fuera del intervalo de tiempo en la que se produjo la incidencia (Sin la marca de incidencia), se deben remitir los afectados por dicha incidencia (con la marca de incidencia).

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
--------------------------------------------------------------
Al leer detenamente la repuesa de nuevo, he visto que hay algo que no me queda claro, y quizas estoy dandole demasaaiadas vueltas pero me gustaria ajustarme lo mejor posible a su interpretación, pongo un escenario de ejemplo:
1.Genero un registro a la 13:00:00 y se corta la red, al intentar el envio a las 13:01:00 no puedo enviarlo.
2.Genero un nuevo registro, mientras aun existe la incidencia, a las 13:02:00-.
3.Mi control de flujos está constantemente reintentando la conexión cada pocos segundos.
4.A las 13:05:20 vuelve la red, y ahora tendría:
Un registro Generado hace 320 Segundos.
Un registro Generado hace 200 Segundos.

Según mi interpretación de la normativa, el registro que está en 200 segundos se marcaba como incidencia, ya que al intentar enviarlo no se pudo en ese momento, a pesar que sigo teniendo hasta el segundo 240(o más bien el parametro devuelto [t]+180, según entiendo). Pero claro puedo estar equivocadeo en esa interpretación en que aunque haya intentado la conexión y mientras esté dentro del ttiempo, no deba marcarlo como incidencia.
Ahora viene la otra parte. el segundo registro (200 segundos)si no lo envio en el mismo lote que el que esstá claramente fuera del tiempo de envio, ocurriria que al enviarlo 60 segundos despues, tambien entraria como incidencia(O me devolveria el error fuera del intervalo de 240segundos), ya que habrian pasado 260 segundos.
Que debo hacer:
1. Después del envio de un lote de incidencia puedo interpretar (o me devolverian) el parametro [t]=0 y poder mandar otro lote inmediatamente sin incidencias?
2. Es correcto que, al haberlo intentado previamente, ya lo pueda marcar como incidencia, por tanto podria mandar en el mismo lote ambos?
3.Es opcional y podria mandarlo juntos o separados ya que es un posible escenario contemplado por vds y no saben si el registro de 200segundos fué reintentado o no y potr tanto no sabemos si está en incidencia(en caso de que en los intentados se marquen como incidencia?

RESPUESTA
Buenas tardes:

La normativa no fija un umbral concreto que determine la existencia de una incidencia. No obstante, se considera razonable que, si el sistema detecta fallos consecutivos en los intentos de comunicación o si transcurre un plazo de tiempo sin que haya podido completar el envío y recibir su respuesta (por ejemplo uno o dos minutos) se active el mecanismo.

Respecto a las cuestiones planteadas:

1. Las remisiones de registros con la marca de Incidencia a "S" devolverán igualmente como tiempo de espera 60 segundos. No obstante, si por volumen de facturación, al ser, supuestamente, casos puntuales se admitirá que la siguiente remisión no respete el tiempo de espera. Le confirmamos que no habrá rechazo cuando una remisión se envíe antes de los 60 segundos estipulados pero se revisará que no se produzcan abusos al respecto.

2. Sí. Entendemos que el registro generado hace 200 segundos ya ha tratado de enviarlo varias veces ( y no ha recibido respuesta) por lo que se puede considerar afectado por la incidencia (a pesar de estar dentro del margen de los 240 segundos).

3. Correcto.



La franja horaria es GMT +2. Ahora son las 00:14: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