Empezado por ermendalenda (Mensaje 559444)

Bueno parece que he conseguido arañar unos segundos
Tenían un error en el control de flujo respecto al reglamento h se lo he expuesto y dicen que seguramente sufra un cambio muy leve, pero que sepáis que un poco.mas de los 60 segundos después del parámetro [t]
O sea el error en vez 120 pasará a ser 120+ tiempo de descuento que añadan

Empezado por bmfranky (Mensaje 559447)

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... :cool::cool::cool:

Empezado por ermendalenda (Mensaje 559456)

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]

Empezado por bmfranky (Mensaje 559469)

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.

Empezado por ermendalenda (Mensaje 559471)

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

Empezado por CarlosMz (Mensaje 559470)

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

Empezado por ermendalenda (Mensaje 559474)

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 ñ.

Empezado por bmfranky (Mensaje 559476)

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:D:D, y a jugar , ya os comento que no encadenare envios.

Empezado por ermendalenda (Mensaje 559488)

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

Empezado por bmfranky (Mensaje 559490)

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... :cool::cool:

Empezado por ermendalenda (Mensaje 559491)

Si sí, si esta muy bien, pero ese paquete ha podido ir mal y no lo he marcado como incidencia por q7e se me ha escapado. Y además si en el programa, digo que si la diferencia es de 1 minuto o menos no corrijas el sistema...que voy a ser el primero en vigilarlo, pero tienen esa anomalia

Empezado por bmfranky (Mensaje 559495)

Mientras no se les ocurra decir que factura que no se emita en su "Tiempo" no vale, porque eso nos faltaba...

Empezado por bmfranky (Mensaje 559498)

Al final cuando implementen del todo sus servicios de consulta, me parece que haremos una consulta cualquiera y asignaremos como tiempo el que ellos devuelvan, seguro que la acertamos.

Empezado por CarlosMz (Mensaje 559470)

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