|
Tiempos de envios
A falta de una normativa clara sobre los tiempos de envios y por otras cuestiones a ver si conseguimos que suban esos 120 segundos.
De momento he lanzado un 🎯 a ver si doy en la diana |
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 |
Cita:
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: |
Cita:
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] |
Cita:
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. |
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 |
Cita:
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 |
Cita:
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. |
Cita:
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 ñ. |
Lo del BAN no lo sabía... bueno de momento dejo esto de lado para las pruebas
Muchas gracias por la info |
Cita:
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. |
Cita:
|
Inconsistencia control de flujo
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 |
Cita:
|
Cita:
|
Cita:
|
Cita:
Si, menos mal que dejan pasar. |
Tiempo AEAT
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.
|
Cita:
El de las consultas de nifs por ejemplo, croe que tb devuelve el time stamp |
Cita:
|
Tiempo de Envios
Cita:
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. |
Cita:
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. |
Cita:
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, |
Cita:
|
Cita:
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
Cita:
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. |
Cita:
|
Cita:
|
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. |
Cita:
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 |
Cita:
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. |
Cita:
|
Cita:
Voy a releer la documentación otra vez. Saludos, |
Cita:
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) |
Cita:
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
Cita:
|
Cita:
|
Cita:
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. |
Cita:
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. |
Cita:
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. |
| La franja horaria es GMT +2. Ahora son las 16:26:41. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi