Tiempo de Envios
 

Veo que todos estamos mas o menos igual ....

Yo pretendo no tener que enviar en un mismo soap mas de una factura y estoy pensando en lo siguiente :

Tengo dos procesos independientes uno genera facturas/tickets y otro proceso envía.

En la BD grabo FechaFactura YYMMDDHHMMSS y FechaRegitroFacturacion con YYMMDDHHMMSS.MMMMMMM por cada operación de venta ya sea ticket o factura.

El primer envío del día sin problemas genero el XML justo antes del envío, un solo registro, el siguiente espero "t" segundos después del primero generando el XML igualmente al momento, es decir como si cada "t" segundos se efectuara una operación de venta.

Si entre ventas pasan mas de "t" segundos se comporta como el primer envío.

Todo dependerá del número de documentos que haga la empresa por minuto porque como sean muchos en algún momento igual si los envías uno a uno tardas más del tiempo suficiente que debe de pasar entre la generación del documento y el envío.


A mi entender lo "eficiente" es agrupar y enviar de una tacada los posibles documentos que se puedan generar mientras se está a la espera del siguiente envío.


Saludos.

Gracias por responder Newtron,

La idea es generar y enviar el XML de una sola operación de venta en el mismo momento en que se cumpla el "t" segundos.


Saludos,

El Xml no se puede generar cuando nos venga conveniente, el Xml se generar antes o en el mismo momento de emitir la factura. Esto está muy claro y explicado en el reglamento. Intenta leerlo de nuevo porque creo que no es factible lo que propones.

No sé si me estoy enterando bien del planteamiento pero si te he entendido quieres enviar un documento, esperar 60 segundos (si es lo que te devuelve como respuesta), a los 60 segundos enviar otro y así sucesivamente. Eso te limita bastante los documentos que puedes enviar y es posible que empieces a tener problemas si te pasas del tiempo máximo de envío entre la generación del documento y el envío del mismo. Si hablamos de una empresa que emite 10 documentos al día podría ser factible pero si (por ejemplo) hablamos de un supermercado claramente no funcionaría y muchos tickets entrarían fuera de plazo.


No sé, ya que estás puesto yo lo haría de la manera que te comento, enviando en un paquete los n documentos que se han generado desde el último envío.



Por si te sirve de algo yo lo estoy haciendo de la siguiente manera: Un programa aparte que está atento a ficheros que "aparezcan" en una carpeta determinada. Desde el programa que emite las ventas genero un fichero .csv en esa carpeta, el programa detecta ese fichero y lo "encola" a los posibles ficheros que ya pueda haber pendientes de envío. Cuando llega el momento de enviar los lee, los envía y se queda a la espera de nuevos ficheros. Mientras no llega el momento del nuevo envío los ficheros se van encolando y cuando llega el momento se leen y se envían. El lapso de tiempo del envío lo tengo puesto en un control TTimer del que voy refrescando el tiempo de ejecución en función de la respuesta del último fichero enviado.


Creo que de esta manera se puede manejar bien el asunto del envío de los ficheros, tiempos, etc.


Saludos.

Tiempo de Envios
 

Yo partía de la base (veo que errónea, de que se puede generar el xml de la factura posteriormente a la entrega del documento al cliente) pretendo generar el xml y enviar en el mismo momento, la factura ya tendría su URL QR que el cliente ya lleva impresa, todos los registros en la BD estarían ordenados para su envió en día, hora, minuto, segundo y milésima de segundo solo esperar los "t" segundos entre envíos para generar y enviar el siguiente.

No sé si me explico lo suficiente.

Saludos y muchas gracias por vuestras aportaciones.

No veo porque no se puede hacer lo que dices, lo único que cambia en el xml de generación de factura y el xml de envío es la fecha "FechaHoraHusoGenRegistro" que bien puede ser la del envío, no la de la generación.

Hola, esto es como la pescadilla que se muerde la cola, ya hemos comentado que esta gente , presupones y espera que se genere el xml al mismo tiempo que la factura, y que se envie en no menos de 120" despues de generada, la hayas o no entregado al cliente.

Yo lo he pensado como 2 procesos distintos y en ese caso, lo veo más simple; Tal vez se me está pasando algo.
ACTUALIZO el mensaje para explicarlo mejor (me he dejado algunos detalles)...


PROCESO 1: Genera facturas las firma y las encola (en una tabla de BD)
PROCESO 2: Envía el contenido de la cola con un máximo de 1000 registros.

El PROCESO 2, cada X segundos coge lo que haya en la cola (tabla) y lo envía. El retorno devuelve los N segundos a esperar hasta el próximo envío.
a) Si hubiera más de 1000 registros en cola, se envían los 1000 primeros y X se coloca a 0 sg (no hace falta esperar para realizar el siguiente envío).
b) Si hubiera menos de 1000 registros, se envían y a X se le asigna el valor N (y es el tiempo a esperar hasta el próximo envío).

En nuestro caso tenemos N terminales que facturas y el envío es un servicio que se conecta directamente a la BD.

Nuestra idea inicial era hacerlo tal como indicas Neftali, todo igual excepto que pensábamos siempre enviar solo una factura.
Viendo los comentarios ... puede que tengamos que replantear lo de enviar un paquete de facturas. Algunos de nuestros clientes pueden hacer muchas facturas a lo largo del día y si entre envíos tenemos que esperar ...

Gracias

Si por lo que fuera, hacen varias facturas muy seguidas (nosotros tenemos procesos masivos de facturación) podrías tener problemas enviando de 1 en 1.

Exacto, ya lo he comentado algunas veces, de uno en uno es arriesgado y más ee uno va a llegar tarde. Solo tebeis que hacer mentalmente pruebas y veréis como se pueden salir del tiempo de 60 segundos después del tiempo de espera. Hay poco tiempo de margen para enviar

Eso pienso yo, no veo como van a saber a que hora se ha generado el registro en la BD y se la lleva/o no el cliente y la hora de generación del xml + envio la fecha que contenga la Huella va a ser lo mismo que lo que contenga FechaHoraHusoGenRegistro

Voy a releer la documentación otra vez.


Saludos,

Es fácil
El cliente lee el QR y ya tienen que la hora de generación no puede ser posterior. Y os acordáis las multas para los tramposos cuanto es?
Otra cosa que coincida la hora de entrega al cliente con la de generacion(pero todos sin altos y en orden, eso puede sevir para generacion previa masivamente)

Creo que en algún post anterior de otro hilo, alguien comento sobre esto mismo:

Si el cliente ya tiene la factura impresa con el QR y lo escanea para verificar, le dirá que no se ha recibido todavía y la agencia tributaria sabrá la hora en que se ha consultado. Luego cuando generes el xml y lo envíes, la agencia tributaria podrá comprobar que la fecha hora de generación del registro es posterior a la hora que el destinatario lo ha comprobado, y que por lo tanto no se cumple la ley porque no se ha generado el registro de facturación al emitir la factura.

Me suena algo así y me pareció convincente.

Ahora veo que ermendalenda ya lo ha dicho. gracias

Tiempos ENvío
 

Anda, ese post se me habrá escapado .... en el QR no está la hora pero si el cliente hace saltar la liebre y ellos lo controlan está claro que encolar... en fin ... :cool:

Está claro que hay que empaquetar, no tiene sentido enviar 1 a 1 esperando t cuando tienes múltiples facturas en cola.

Primera (pequeña) nota, el PROCESO 2 solo envía los primeros 1000 registros de la cola, no todos. Pero esto ya lo sabes.

Después veo otra tema lógico: si tienes 1999 registros en la cola, los primeros 1000 saldrán de seguida, pero los demás 999, más todos los demás que vendrán en el intervalo, van a tardar la totalidad de las N segundos.
Es un poco ineficiente. Pero ¿podría resultar un problema?
Depende del ritmo de llegada de los documentos, que puede ser más o menos regular. Pero como no tengo experiencia de un sistema que puede verse desbordado por el limite ese de los 1000, no consigo evaluar el tamaño de los problemas. Solo veo que los extremos no son casos con problema: un ritmo regular (x documento por minuto, fijo) no debe rellenar la cola con 1999 registros (N=180 s ⇒ x=666⅓ :eek: más de 11/s); por otro lado un ritmo completamente irregular, después de poner 1999 registros en cola, o 2999 o 3999, se va a parar para un rato muy superior a N segundos, por tanto no hay problema tampoco.

Este es el planteamiento que tengo en borrador:

Emito la factura
Intento el envío. Antes de hacer el envío compruebo 1) si hay facturas pendientes y 2) si estoy en plazo para el envío (han pasado ya 60 segundos desde el último). Tres supuestos:
a) Han pasado los 60 segundos y no hay pendientes: envío esta factura sólo e inicio el contador de los 60 segundos.
b) Han pasado los 60 segundos y hay facturas pendientes: las junto todas en un único envío e inicio el contador de los 60 segundos.
c) No han pasado los 60 segundos: Añado la factura emitida a la lista de pendientes.

Lo de las 1000 facturas, la verdad, me preocupa menos. No creo que nadie llegue a ese tope; aún así, se incluye un timer que evalua cada x segundos si hay algo pendiente de enviar; en ese caso, aunque no haya ninguna generación de factura en curso, descarga el almacén de pendientes enviándolas e iniciando igualmente el contador de los 60 segundos.

Es cierto. No es exactamente como lo has puesto pero te he cogido la idea creo.
Pongamos una empresa que manda todo a un servidor central (el corte inglés por ejemplo), en ocasiones le puede pasar que por ejemplo genere 1500 registros envía 1000 se le queden 500 por enviar y al esperar los 60 segundos o el tiempo que le pongam (Si NO HA VUELTO A LLEGAR A LOS 1000 REGISTROS) lo más probable es que algunos registros de esos primeros 500 del FIFO van a llegar tarde y CHAN error 2004
Se quejaran y tendrán que mejorar y repensar el control de flujos. Supongo que si mandas 1000 devolverán 0 o 1 en [t] es la forma de corregir el problema.