Tiempos de envios

[ermendalenda]

Empezado por bmfranky

Entonces realmente el tiempo de envio sera:
Tiempo base t 60"
Tiempo max m 120"
Tiempo retardo añadido r.


Entonces desde el ultimo envio podemos/devemos esperar .
Tiempo de envio e => t pero < t+m+r

supniendo que en la respuesta anterior nos indique 100"
Tendremos un tiempo de 240 Segundos..

Joder esto parecen matematicas abanzadas...

No
Si te indican 100 a partir del segundo 100, actualmente tienes 60 segundos.
O sea tienes que mandar entre el segundo 101 y el 160
Lo que he solicitado que ese tiempo de 60 segundos (el que se le suma a [t],) no es correcto por un motivo que otro día os explico. Lo han reconocido y parece que subirán algo ese 60
Ya verenos
Os pongo ejemplo el margen es igual si
Me devuelven [t]=60
Si tengo algo de nuevo pendiemte de enviar, Voy mirando desde el último envio hasta la fecha/hora actual hasta que hayan pasado los 60 segundos y ahora tendría que mandar inmediatamente,
inemdiatamebte=60segundos de margen SIEMPRE HASTA QUE CAMBIEN LO QUE OS HE COMENTADO INDEPENTEMENTE DEL PARAMETRO [t]

[bmfranky]

Empezado por ermendalenda

No
Si te indican 100 a partir del segundo 100, actualmente tienes 60 segundos.
O sea tienes que mandar entre el segundo 101 y el 160
Lo que he solicitado que ese tiempo de 60 segundos (el que se le suma a [t],) no es correcto por un motivo que otro día os explico. Lo han reconocido y parece que subirán algo ese 60
Ya verenos
Os pongo ejemplo el margen es igual si
Me devuelven [t]=60
Si tengo algo de nuevo pendiemte de enviar, Voy mirando desde el último envio hasta la fecha/hora actual hasta que hayan pasado los 60 segundos y ahora tendría que mandar inmediatamente,
inemdiatamebte=60segundos de margen SIEMPRE HASTA QUE CAMBIEN LO QUE OS HE COMENTADO INDEPENTEMENTE DEL PARAMETRO [t]

Haber si lo pillo, desde que genearas el registro(Asignas el timestamp) hasta que lo envias han de ser menos de 120", ademas de dejar de momento minimo 60" entre envios, osea que 2 consecutivos inmediatos sin espera serian lo 120" que te da solo 60" de margen, pero si tardas en generar el timestamp , porque estas rellenando los datos de la factura, mas de 60" , sigues teniendo el margen de 120" integros.
Pero si estas enviando los registros de varios puntos de facturacion a la vez, encadenandolos, pues si solo teneis 60" para recopilar y enviar las facturas.
Put**a lo mires como lo mires.

[ermendalenda]

Empezado por bmfranky

Haber si lo pillo, desde que genearas el registro(Asignas el timestamp) hasta que lo envias han de ser menos de 120", ademas de dejar de momento minimo 60" entre envios, osea que 2 consecutivos inmediatos sin espera serian lo 120" que te da solo 60" de margen, pero si tardas en generar el timestamp , porque estas rellenando los datos de la factura, mas de 60" , sigues teniendo el margen de 120" integros.
Pero si estas enviando los registros de varios puntos de facturacion a la vez, encadenandolos, pues si solo teneis 60" para recopilar y enviar las facturas.
Put**a lo mires como lo mires.

No sé si te estoy entendiendo.
Si tienes 2 para enviar los puedes enviar en el mismo paquete (mismo soap). Y a volver a esperar el tiempo que te digan en la respuesta

[bmfranky]

Empezado por ermendalenda

No sé si te estoy entendiendo.
Si tienes 2 para enviar los puedes enviar en el mismo paquete (mismo soap). Y a volver a esperar el tiempo que te digan en la respuesta

Haber el tiempo de espera es por "Paquete" que contiene x registros y el tiempo maximo empieza a contar desde el primer registro añadido a ese paquete.
Globalmente al emitir un paquete completo, hay que tener en cunerta 2 temporizadores,
1 que es para no enviar antes del tiempo especificado en la anterior respuesta que sera minimo 60"
2 que es para que entre que añadimos registros al paquete que enviaremos despues de ese tiempo no superemos 120" desde que añadimos el primero.

[CarlosMz]

Yo, sinceramente voy a intentar enviar de 1 en 1.
Intentaré buscar la fórmula para evitar tener que controlar estos tiempos de envío

[ermendalenda]

Empezado por CarlosMz

Yo, sinceramente voy a intentar enviar de 1 en 1.
Intentaré buscar la fórmula para evitar tener que controlar estos tiempos de envío

Te puede pasar varias cosas:
1. Que te baneen si detectan que incumplesmucho. Ya que en el tema de envioa máximos en el enlace de pruebas han advertido que pueden banear,
2. Que re metan baneos temporales y temporalmente se te bloquee el envío.
3. Que te dejen enviar sin respetar los tiempos (antes de que pasen los 60 segundos) , eso está pasando ahora con las pruebas, pero si lo haces varias veces parece que hacen baneos temporales.
4. Que te devuelva un error hasta que puedas reenviar, eso sería lo ideal ñ.

[CarlosMz]

Lo del BAN no lo sabía... bueno de momento dejo esto de lado para las pruebas
Muchas gracias por la info

[bmfranky]

Empezado por ermendalenda

Te puede pasar varias cosas:
1. Que te baneen si detectan que incumplen mucho. Ya que en el tema de envioa máximos en las pruebas han advertido que pueden banear.
2. Que re metan bancos temporales y temporalmente se te bloquee el envío.
3. Que te dejen enviar sin respetar los tiempos (antes de que pasen los 60 segundos) , eso está pasando ahora con las pruebas, pero si te pasas parece que hacen bancos temporales.
4. Que te devuelva un error hasta que puedas reenviar, eso sería lo ideal ñ.

Imagno que seran *Baneos temporales...
Yo por mi parte he creado una variable global que se llama misteriosamente" int tiempoAntesDeEnvio =60;", que mediante un timerclock, voy decrementando , si no es 0, hago esperar hasta que lo sea, con el valor devuelto recargo la variable , sea 60/70/100/500, y a jugar , ya os comento que no encadenare envios.

[ermendalenda]

Empezado por bmfranky

Imagno que seran *Baneos temporales...
Yo por mi parte he creado una variable global que se llama misteriosamente" int tiempoAntesDeEnvio =60;", que mediante un timerclock, voy decrementando , si no es 0, hago esperar hasta que lo sea, con el valor devuelto recargo la variable , sea 60/70/100/500, y a jugar , ya os comento que no encadenare envios.

Buena idea

[ermendalenda]

Como he comentado en este hilo, he encontrado una pequeña anomalia en la definición del control de flujos respecto al reglamento, por lo cual he rogado que lo revisen para aumentar el tiempo a un tiempo viable, como os he dicho me contestan que lo han entendido y que verán si aumentan el tiempo pero algo leve. Bueno lo que sea es bueno.
Os explico la inconsistencia con un ejemplo:
Si la hora de mi sistema es las 9:00:00 y acabo de remitir una factura en segundo plano y me ha devuelto t=60 o da igual lo que me devuelva y en primer plano genero una factura a la misma hora que no se ha enviado en ese paquete. Esta claro que tengo que esperar un minuto de un registro generado a las 9:00:00...
Perooooo, aquí viene lo bueno...
Resulta que mi sistema tiene justo 1 minuto de retraso, cosa contemplada en el reglamento y no tengo por que arreglarlo, otra cosa es que lo arregle, pero me permite el reglamento? SÍ
Resulta que me espero el minuto y lo que para el reloj de mi sistema son las 9:01:00 para ellos son las 9:02:00 y aunque tarde 1 milésima de segundo en enviarlo justo después del minuto, tomaaaa Error 2004, no señor, me he quedado con el culo al aire y mi control de flujo está dentro del reglamento.
Pues nada solo eso.
Es rebuscado, pero posibles y con tantos envíos seguro que se les da bastantes casos, además la mayoría no vamos a mandar el registro justo en segundo 61, xon lo cual se les multiplica el problema, no tiene que ser justo con relojes retrasados 60 segundos.
Bajo mi punto de vista tendrían que dejar 120 segundos para solucionarlo si quieren dejar 60 segundos de margen. A ver uq e hacen

[bmfranky]

Empezado por ermendalenda

Como he comentado en este hilo, he encontrado una pequeña anomalia en la definición del control de flujos respecto al reglamento, por lo cual he rogado que lo revisen para aumentar el tiempo a un tiempo viable, como os he dicho me contestan que lo han entendido y que verán si aumentan el tiempo pero algo leve. Bueno lo que sea es bueno.
Os explico la inconsistencia con un ejemplo:
Si la hora de mi sistema es las 9:00:00 y acabo de remitir una factura en segundo plano y me ha devuelto t=60 o da igual lo que me devuelva y en primer plano genero una factura a la misma hora que no se ha enviado en ese paquete. Esta claro que tengo que esperar un minuto de un registro generado a las 9:00:00...
Perooooo, aquí viene lo bueno...
Resulta que mi sistema tiene justo 1 minuto de retraso, cosa contemplada en el reglamento y no tengo por que arreglarlo, otra cosa es que lo arregle, pero me permite el reglamento? SÍ
Resulta que me espero el minuto y lo que para el reloj de mi sistema son las 9:01:00 para ellos son las 9:02:00 y aunque tarde 1 milésima de segundo en enviarlo justo después del minuto, tomaaaa Error 2004, no señor, me he quedado con el culo al aire y mi control de flujo está dentro del reglamento.
Pues nada solo eso.
Es rebuscado, pero posibles y con tantos envíos seguro que se les da bastantes casos, además la mayoría no vamos a mandar el registro justo en segundo 61, xon lo cual se les multiplica el problema, no tiene que ser justo con relojes retrasados 60 segundos.
Bajo mi punto de vista tendrían que dejar 120 segundos para solucionarlo si quieren dejar 60 segundos de margen. A ver uq e hacen

Ya, pero programaticamnete deverias verificar , como ya comentamos la hora del timestamp de respuesta de la aeat, que para ello lo devuelven, con la de tu sistema, para efectuar las correcciones adecuadas, o pensabais que de repente incuian eso sin motivo...

[unomasmas]

Empezado por CarlosMz

Yo, sinceramente voy a intentar enviar de 1 en 1.
Intentaré buscar la fórmula para evitar tener que controlar estos tiempos de envío

Me estoy devanando los sesos para ver cómo gestiono este control de flujo, pero enviar de uno en uno no me lo planteo (no me parece viable) porque podría darse que se generasen simultáneamente tres o cuatro (o bastantes más) facturas y si cada una tiene que esperar a que se envíe la anterior, al final se va a pasar ese tiempo máximo. Por otra parte, lo que pretenden ellos (aunque sea a base de fundir nuestras neuronas) es que juntemos las facturas para no enviar de una en una, salvo que la producción sea mínima, claro; vamos, que les asusta más la cantidad de peticiones que van a recibir que el sufrimiento que están infringiendo a nuestras conexiones neuronales.

[thinkows]

Empezado por unomasmas

Me estoy devanando los sesos para ver cómo gestiono este control de flujo, pero enviar de uno en uno no me lo planteo (no me parece viable) porque podría darse que se generasen simultáneamente tres o cuatro (o bastantes más) facturas y si cada una tiene que esperar a que se envíe la anterior, al final se va a pasar ese tiempo máximo. Por otra parte, lo que pretenden ellos (aunque sea a base de fundir nuestras neuronas) es que juntemos las facturas para no enviar de una en una, salvo que la producción sea mínima, claro; vamos, que les asusta más la cantidad de peticiones que van a recibir que el sufrimiento que están infringiendo a nuestras conexiones neuronales.

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.

[[newtron]]

Empezado por thinkows

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.

[thinkows]

Empezado por newtron

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,

[sglorka]

Empezado por thinkows

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.

[[newtron]]

Empezado por thinkows

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,

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.

[ermendalenda]

Empezado por newtron

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.

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