![]() |
![]() |
![]() |
![]() |
![]() |
FTP | ![]() |
![]() |
CCD | ![]() |
![]() |
Buscar | ![]() |
![]() |
Trucos | ![]() |
![]() |
Trabajo | ![]() |
![]() |
Foros | ![]() |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Control de flujo
Os cuento mi planteamiento por si le veis algún problema
Una vez generada una factura:
|
#2
|
||||
|
||||
Buenos días compañero.
No lo veo claro. El sistema (a mi forma de ver) es: - Genero factura y la pongo directamente en la cola de facturas a enviar. Puede que no haya ninguna o puede que haya alguna pendiente de envío por lo que esta se agregaría a ese paquete. - Se envía el paquete de posibles facturas pendientes, se recoge el tiempo a esperar para el siguiente envío, se vuelve a poner el programa en modo espera y se evalúan los resultados del último envío. - Las facturas ok se olvidan y luego habrá que manejar manualmente las rechazadas porque casi con toda seguridad necesitarán una factura rectificativa. Saludos.
__________________
Be water my friend. |
#3
|
|||
|
|||
Cita:
|
#4
|
||||
|
||||
Cita:
Pues "ahímasdao". De forma normal las nuevas que se vayan añadiendo a la cola entrarán en tiempo y si no lo hacen es porque el servidor en la respuesta anterior haya enviado un tiempo para el siguiente envío superior a los 2 minutos. La verdad es que no sé si en caso de pasar del tiempo por instrucciones del servidor habría que enviarlas como incidencia o no. Buena cuestión para preguntar a soporte de Verifactu. Saludos.
__________________
Be water my friend. |
#5
|
|||
|
|||
Cita:
De otra forma, el lío se propaga. Tenemos facturas con incidencia que podemos enviar y a la vez hemos generado algunas dentro de tiempo que no deberían ir con incidencia, pero ¿Hemos de comprobar cada una de las generadas para ver si entran en el paquete de incidencia o no? Vale, lo hacemos así y una queda fuera pero como hemos enviado el paquete con incidencia, hemos de esperar otros 60 segundos, por lo que esa que dejamos fuera, que no enviamos porque no cumplía con los requisitos de incidencia, resulta que cuando la vayamos a enviar ya está fuera de plazo y deberíamos marcar incidencia para ella. Me parece mucha, muchísima complicación añadida a lo complicado que resulta ya tener que controlar el flujo... |
#6
|
|||
|
|||
Date cuenta de que cuando se genera una factura esta se envía inmediatamente (vamos, se intenta enviar). Si no hay nada en cola, se envía sóla y no hay problema; si hay más en cola porque todavía no han pasado los 60 segundos desde el último envío, se envía con las demás (dentro del plazo); sólo si las otras que están en cola lo están porque hubo una incidencia, como la incidencia afecta a todo el paquete, esta última añadida se enviará junto con las otras con la marca de incidencia (aunque teóricamente estuviera en plazo)
|
#7
|
|||
|
|||
Cita:
|
#8
|
||||
|
||||
Tiempo de espera.
Hola, lo de incidencia por tiempo de envio, no lo tengais tan en cuenta para las facturas en un mismo registro de envio, al recibir el paquete, ellos desglosan cada factura y saben por el timestamp cual estaba fuera de tiempo, no diran nada por ello, es mas el tiempo de envio es lo unico que esta exento de subsanacion, lo unico que quieren evitar es que la gente se acostumbre a hacer las facturas y enviarlas cuando se les ocurra, por eso ponen un tiempo, pero realmente no lo tienen en cuenta, es mas desde el principio , al enviar debugeando las facturas he tenido varias facturas con el error 2004, y tras diversas consultaas de mi parte y de otros compañeros, nos confirmaron que no necesita subsanacion.
Otra cosa seria que todos los envios de nuestro SIF, fueran marcados con incidencia, supongo que ahi si tendriamos algun problemilla. Tened en cuenta que al responder el tiempo de espera, la operativa es: 1-> Esperar t Segundos o. 2-> Reunir 1000 registros. Lo que se alcance primero. Desde mi punto de vista, crearia una cola de envio automatizada que cada x segundos(o 1000 registros) ,por ejemplo 100", realizara el envio, si hay algun error* , activo el flag de incidencia y continuo agregando registros, la cola deveria intentar el reenvio automaticamente, en el momento que se hayan enviado todos los registros o el primer elemento a enviar este dentro de la franja de 120", se desactiva automaticamente el flag y se continuan enviando los mismos sin incidencia. *Aqui habria que tener en cuenta que causo el error , para implementar la solucion y notificar la causa de la incidencia a la aeat, no es lo mismo, que el servidor de ellos no responda, que nosotros no tengamos internet, que se fuera la luz en pleno envio, que conteste duplicado... Aunque yo no tengo previsto implementar la cola, de momento, puesto que en mi caso , si hoy no puedo hacer factura, perfectamente puedo cobrarle al cliente y enviar a fin de mes la misma, sin problemas.
__________________
Uno se alegra de ser útil. (Isaac Asimov) |
#9
|
|||
|
|||
Cita:
![]() |
#10
|
||||
|
||||
Cita:
1) Generáis 2 facturas con una diferencia de tiempo de 20 segundos y el tiempo que está devolviendo la AEAT para esperar entre envíos es de 60 sg. (por defecto) 2) Si intentáis enviar la facturas inmediatamente después de su generación, váis a tener problemas. ¿Es correcto?
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi ![]() P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#11
|
|||
|
|||
Cita:
Esto me lleva a la conclusión de que va a ser tal el lío que no temdran mas remedio que abrir la.manoy permitir los envios antes de tiempo entre otras cuesriones. Sii no no van a tener capacidad de absorber esto |
#12
|
|||
|
|||
Cita:
|
#13
|
|||
|
|||
Cita:
Creo que la idea es más o menos la misma. Yo decía que genero la factura y la envío pero en realidad lo que hago es ponerla en el paquete para enviar junto con otras posibles (las que puedan estar porque cuando se emitieron no había pasado el tiempo preceptivo de espera). En fin, los envíos se hacen cada X tiempo (por si hubiera alguna en la cola) y también inmediatamente tras la generación (si no ha pasado el tiempo entonces se pone en el paquete de cola). En cualquier caso, con cada envío se procesa todo el paquete. |
![]() |
|
|
![]() |
||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Flujo de datos | lccarvajal814 | SQL | 5 | 05-12-2022 17:00:33 |
Diagrama de flujo de los conspiranoicos | rretamar | La Taberna | 2 | 03-12-2013 18:20:18 |
Variar control de flujo Puerto Serie | bactering | Varios | 3 | 20-03-2011 23:22:28 |
Problema al cerrar un puerto COM con control de flujo | vejerf | OOP | 1 | 25-07-2008 10:58:10 |
Problemas con la paridad y el control de flujo | atapia | Varios | 1 | 18-09-2007 11:35:29 |
![]() |
|