Club Delphi  
    Paypal   FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Proyecto SIF/Veri*Factu/Ley Antifraude > Envío de registros y sus respuestas
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #121  
Antiguo 14-05-2025
Jarogo08 Jarogo08 is offline
Miembro
 
Registrado: ene 2025
Posts: 344
Poder: 2
Jarogo08 Va por buen camino
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.
Responder Con Cita
  #122  
Antiguo 14-05-2025
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 565
Poder: 6
rci Va por buen camino
Cita:
Empezado por Jarogo08 Ver Mensaje
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
Responder Con Cita
  #123  
Antiguo 14-05-2025
delphiGar delphiGar is offline
Miembro
 
Registrado: ago 2024
Posts: 182
Poder: 2
delphiGar Va por buen camino
Cita:
Empezado por ermendalenda Ver Mensaje
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.
Responder Con Cita
  #124  
Antiguo 14-05-2025
ermendalenda ermendalenda is offline
Miembro
 
Registrado: ago 2021
Posts: 2.759
Poder: 7
ermendalenda Va por buen camino
Cita:
Empezado por rci Ver Mensaje
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"
Responder Con Cita
  #125  
Antiguo 14-05-2025
ermendalenda ermendalenda is offline
Miembro
 
Registrado: ago 2021
Posts: 2.759
Poder: 7
ermendalenda Va por buen camino
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.
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Entorno pruebas AEAT _Io Envío de registros y sus respuestas 8 02-04-2025 14:56:55
Error 2004 - FechaHoraGenRegistro Exento De Subsanacion bmfranky Errores (relacionados con al AEAT) 3 05-12-2024 13:36:39
Error 3002 en subsanacion ermendalenda Errores (relacionados con al AEAT) 5 14-11-2024 10:59:55
Tabla de Facturas vs Detalles de Facturas magnu9 Conexión con bases de datos 9 27-07-2007 17:27:37
Campos calculados, facturas y detalles de facturas. Letty Conexión con bases de datos 7 07-11-2003 11:19:44


La franja horaria es GMT +2. Ahora son las 14:56:02.


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
Copyright 1996-2007 Club Delphi