Reenvío de facturas el Entorno de Pruebas SIN especificar Subsanación

[Jarogo08]

Empezado por rci

Si, yo tampoco entiendo a que te refiere exactamente neftali con "se genera envío (vacio); AEAT contesta con 60 sg. de espera"

Si no hay registros pendientes de envío ya no se envía nada y AEAT no contesta no?

A mí también me descolocó esa frase, jeje. Si no hay registros pendientes yo no envío nada, espero a que vuelva a saltar el timer (cuya frecuencia es la que marcó el último envío, que puede ser del día anterior por ejemplo)

[Neftali [Germán.Estévez]]

Empezado por bmfranky

Creo que seria mas eficiente para los recursos, comprobar si hay algo que enviar, si no lo hay volver a esperar el tiempo inicial de 60", no ir enviando consultas a la aeat, cada minuto por que si, no creéis?
*El primer envío es el de puesta en marcha del servicio.

No lo había puesto para simplificar.
Cuando aparece "se genera envío (vacío)" realmente el sistema no envía. El sistema ve que no hay nada que enviar y no conecta.
He añadido la nota en el mensaje anterior.

[Neftali [Germán.Estévez]]

Empezado por rci

Si, yo tampoco entiendo a que te refiere exactamente neftali con
Si no hay registros pendientes de envío ya no se envía nada y AEAT no contesta no?

Si es correcto.
Lo he puesto así para mantener la uniformidad.

Cuando dice que hace "se genera envío (vacio);" significa que no hace envío.
Voy a editar el mensaje anterior.

[Neftali [Germán.Estévez]]

Reescrito quedaría así (a ver si se entiende mejor...)

Inicio sistema (no habrá nada)
...
12:00:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:01:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:01:10 Generamos factura 1
12:01:45 Generamos factura 2
12:02:00 Se prepara envío (2 facturas en el envío);  60 sg. de espera
12:03:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:03:10 Generamos factura 3
12:03:20 Generamos factura 4
12:03:30 Generamos factura 5
12:03:40 Generamos factura 6
12:03:50 Generamos factura 7
12:04:00 Se prepara envío (5 facturas en el envío); AEAT contesta con 120 sg. de espera
12:06:00 Se prepara envío (como es vacio, no se envía NADA); 120 sg. de espera
12:08:00 Se prepara envío (como es vacio, no se envía NADA);  120 sg. de espera
12:09:50 Generamos factura 8
12:10:00 Se prepara envío (1 factura en el envío); AEAT contesta con 60 sg. de espera
12:11:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
...

[Jarogo08]

Empezado por Neftali [Germán.Estévez]

Reescrito quedaría así (a ver si se entiende mejor...)

Inicio sistema (no habrá nada)
...
12:00:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:01:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:01:10 Generamos factura 1
12:01:45 Generamos factura 2
12:02:00 Se prepara envío (2 facturas en el envío);  60 sg. de espera
12:03:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:03:10 Generamos factura 3
12:03:20 Generamos factura 4
12:03:30 Generamos factura 5
12:03:40 Generamos factura 6
12:03:50 Generamos factura 7
12:04:00 Se prepara envío (5 facturas en el envío); AEAT contesta con 120 sg. de espera
12:06:00 Se prepara envío (como es vacio, no se envía NADA); 120 sg. de espera
12:08:00 Se prepara envío (como es vacio, no se envía NADA);  120 sg. de espera
12:09:50 Generamos factura 8
12:10:00 Se prepara envío (1 factura en el envío); AEAT contesta con 60 sg. de espera
12:11:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
...

Nosotros lo tenemos tal cual, no cambia ni una coma

Lo único que añadiría es que cuando salta el proceso, si hay algo para enviar, paramos el timer y lo volvemos a poner en marcha cuando termina. Esto, dependiendo de cuanto tarde en enviar, puede provocar algunos "desajustes". Pongo un ejemplo:

12:00:00 Se prepara envío: como es vacío, no se envía NADA. 60 sg. de espera
12:01:00 Se prepara envío. Aparecieron 5 facturas. Preparo todo, conecto, envío, cojo la respuesta y la proceso. En la respuesta me dicen que el próximo en 60 segundos. Pero imaginemos que esto todo lleva 5 segundos. Por tanto pongo el timer nuevamente en marcha a las 12:01:05
12:02:05 Se prepara envío: como es vacío, no se envía NADA. 60 sg. de espera

Si os fijáis, del primer al segundo envío pasaron 60 segundos, pero del segundo al tercero pasaron 65. Entiendo que si hay poquitas facturas los 5 segundos que puse son exagerados pero si a lo mejor se está haciendo un proceso de facturación masivo y aparecen 90-100 facturas en ese minuto pues el proceso de envío puede llevar tranquilamente 5-10 segundos. O si internet va lento en ese momento, o si el web service tarda algo más de lo normal en responder..

Con esta manera de operar realmente no envío cada 60 segundos, sino que hay unas pequeñas variaciones. Pero bueno, como tenemos el margen de los 240 segundos por ahora no me estoy preocupando por ello.

[rci]

Empezado por Neftali [Germán.Estévez]

Reescrito quedaría así (a ver si se entiende mejor...)

Inicio sistema (no habrá nada)
...
12:00:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:01:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:01:10 Generamos factura 1
12:01:45 Generamos factura 2
12:02:00 Se prepara envío (2 facturas en el envío);  60 sg. de espera
12:03:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
12:03:10 Generamos factura 3
12:03:20 Generamos factura 4
12:03:30 Generamos factura 5
12:03:40 Generamos factura 6
12:03:50 Generamos factura 7
12:04:00 Se prepara envío (5 facturas en el envío); AEAT contesta con 120 sg. de espera
12:06:00 Se prepara envío (como es vacio, no se envía NADA); 120 sg. de espera
12:08:00 Se prepara envío (como es vacio, no se envía NADA);  120 sg. de espera
12:09:50 Generamos factura 8
12:10:00 Se prepara envío (1 factura en el envío); AEAT contesta con 60 sg. de espera
12:11:00 Se prepara envío (como es vacio, no se envía NADA);  60 sg. de espera
...

De esta forma se entiende mucho mejor.

Me parece correcto el sistema.

En nuestro caso la tarea despierta siempre cada 60, pero a la práctica los envíos se harían en el mismo momento que este ejemplo de Germán, porque al despertar la tarea busca el valor de tiempo de espera indicado en la última comunicación (TiempoEsperaEnvio) y también la fecha y hora de ese último envío (TimestampPresentacion).
Luego suma el TiempoEsperaEnvio al TimestampPresentacion y compara con la hora actual (del ROA). si ya ha pasado el tiempo, envía, sinó termina la tarea hasta la siguiente iteración, hay un sleep de 60s.

Lo hemos hecho de esta forma, y no haciendo que la tarea espere un tiempo variable para despertar, porque la misma tarea al despertar envía (en procesos separados) registros de facturación de varios OT y he aceptado la posibilidad (supongo que remota o casi inexistente) de que para cada envío (a un OT) la AEAT conteste tiempos de espera distintos, y claro si fuera el caso, siempre esperaria solo el TiempoEsperaEnvio del último envío (del último OT). Imagino que nunca pasará pero por si a caso, tenemos una tabla donde se registra para cada OT el TiempoEsperaEnvio y el TimestampPresentacion del último envío y el servicio lo consulta antes de enviar.

Encontráis algún problema en nuestro planteamiento? a parte de ser un poco mas de trabajo para el desarrollador y alguna conexión a base de datos mas

Muchas Gracias

[VJSoftware]

Buenos días. La verdad es que me ha quedado todo claro. Gracias a los intervinientes. Ahora saco otro tema (aunque está relacionado con esto de los envíos) para ver si me echáis una manita.

Supongamos que hago un envío de 10 RF y no tengo internet. Mi servicio de envío se da cuenta del error y marca los 10 RF para volver a enviarlos como un alta con incidencias.

A todo esto, siguen llegando nuevos RF para enviar.

¿Vosotros cómo procedéis?

1.- Seguís haciendo nuevos intentos de envío, que incluyen los 10 primeros RF más todos los nuevos que hayan entrado, marcando el XML como incidencia sucesivamente hasta que entre.

2.- Seguís intentando enviar solamente los primeros 10 RF (como incidencia hasta que entre) y luego enviáis ya el resto de los quedan (también como incidencia por la cuestión de los 240 segundos).

Y otra cuestión, ¿en qué ocasiones vais a avisar al usuario de que algo está pasando? o estáis diseñando un programa que no necesite supervisión y sea capaz de resolver todas las incidencias él solito... Para el caso de TPV's, que la mayoría de las veces hacen facturas simplificadas sin necesidad de cliente ni NIF (que pueden provocar más errores), pocas son las incidencias que se pueden dar salvo cuando hagan una factura (con su cliente y su NIF) que será recapitulativa sí o sí (al menos en mi SIF) y en ese caso, si hay algún problema, insisto, ¿cómo vais a avisar al usuario de la caja de que ha hecho una factura con un NIF erróneo que debe ser subsanada?. Suponiendo que el ordenador que tiene instalado el programa que envía los RF no está a su alcance (tienda con 3 TPV's con un servidor en un despacho).

[Jarogo08]

Empezado por VJSoftware

Buenos días. La verdad es que me ha quedado todo claro. Gracias a los intervinientes. Ahora saco otro tema (aunque está relacionado con esto de los envíos) para ver si me echáis una manita.

Supongamos que hago un envío de 10 RF y no tengo internet. Mi servicio de envío se da cuenta del error y marca los 10 RF para volver a enviarlos como un alta con incidencias.

A todo esto, siguen llegando nuevos RF para enviar.

¿Vosotros cómo procedéis?

1.- Seguís haciendo nuevos intentos de envío, que incluyen los 10 primeros RF más todos los nuevos que hayan entrado, marcando el XML como incidencia sucesivamente hasta que entre.

2.- Seguís intentando enviar solamente los primeros 10 RF (como incidencia hasta que entre) y luego enviáis ya el resto de los quedan (también como incidencia por la cuestión de los 240 segundos).

Y otra cuestión, ¿en qué ocasiones vais a avisar al usuario de que algo está pasando? o estáis diseñando un programa que no necesite supervisión y sea capaz de resolver todas las incidencias él solito... Para el caso de TPV's, que la mayoría de las veces hacen facturas simplificadas sin necesidad de cliente ni NIF (que pueden provocar más errores), pocas son las incidencias que se pueden dar salvo cuando hagan una factura (con su cliente y su NIF) que será recapitulativa sí o sí (al menos en mi SIF) y en ese caso, si hay algún problema, insisto, ¿cómo vais a avisar al usuario de la caja de que ha hecho una factura con un NIF erróneo que debe ser subsanada?. Suponiendo que el ordenador que tiene instalado el programa que envía los RF no está a su alcance (tienda con 3 TPV's con un servidor en un despacho).

En nuestro caso, si yo quiero enviar 10 registros y no tengo internet no le actualizo nada, siguen en la tabla de envíos como estaban (pendientes).
Si vuelvo a tener internet por ejemplo 3 horas después, ahí se enviarán esos 10 que siguen pendientes más los X nuevos que aparecieron en esas 3 horas. Eso sí, a la hora de hacer el envío detecto los que tienen más de 240 segundos de los que no y hago 2 envíos. Uno con la cabecera con Incidencia a "S" y otro normal. De esa manera, el envío marcado como incidencia puede llevar 30 registros (los 10 que ya tenía más los 20 que aparecerieron en esas 3 horas - 240 segundos) y el envío marcado como normal puede llevar 5 registros (los que aparecerieron en los últimos 240 segundos de esas 3 horas).


Y en cuento a avisar, no hacemos nada especial. En la pantalla de facturas y tickets, cuando ves la lista, estará el campo con los valores "Correcto"-"Incorrecto"-"Aceptado con errores" y pintado en verde-rojo-amarillo (estilo semáforo). Así, al entrar en la pantalla, verás de manera muy fácil el resultado y todo lo que no sea verde tendrán que ir a él y ver que le pasó

[Neftali [Germán.Estévez]]

Empezado por VJSoftware

Supongamos que hago un envío de 10 RF y no tengo internet. Mi servicio de envío se da cuenta del error y marca los 10 RF para volver a enviarlos como un alta con incidencias.

A todo esto, siguen llegando nuevos RF para enviar.
¿Vosotros cómo procedéis?

1.- Seguís haciendo nuevos intentos de envío, que incluyen los 10 primeros RF más todos los nuevos que hayan entrado, marcando el XML como incidencia sucesivamente hasta que entre.
2.- Seguís intentando enviar solamente los primeros 10 RF (como incidencia hasta que entre) y luego enviáis ya el resto de los quedan (también como incidencia por la cuestión de los 240 segundos).

Nosotros separamos en el primer envío los que están con incidencia, que podrían ser:
* Los que fallaron en el primer envío que no había internet
* Y los que se han ido generando posteriormente y tienen antigüedad de más de 240 sg.

Y luego un segundo envío con los que en ese momento están "correctos".

[Faneka]

Nosotros tambien, primero se envian los que tuvieron incidencia y luego los nuevos RF creados.

[rci]

Empezado por Jarogo08

En nuestro caso, si yo quiero enviar 10 registros y no tengo internet no le actualizo nada, siguen en la tabla de envíos como estaban (pendientes).
Si vuelvo a tener internet por ejemplo 3 horas después, ahí se enviarán esos 10 que siguen pendientes más los X nuevos que aparecieron en esas 3 horas. Eso sí, a la hora de hacer el envío detecto los que tienen más de 240 segundos de los que no y hago 2 envíos. Uno con la cabecera con Incidencia a "S" y otro normal. De esa manera, el envío marcado como incidencia puede llevar 30 registros (los 10 que ya tenía más los 20 que aparecerieron en esas 3 horas - 240 segundos) y el envío marcado como normal puede llevar 5 registros (los que aparecerieron en los últimos 240 segundos de esas 3 horas).

Empezado por Neftali [Germán.Estévez]

Nosotros separamos en el primer envío los que están con incidencia, que podrían ser:
* Los que fallaron en el primer envío que no había internet
* Y los que se han ido generando posteriormente y tienen antigüedad de más de 240 sg.

Y luego un segundo envío con los que en ese momento están "correctos".

Empezado por Faneka

Nosotros tambien, primero se envian los que tuvieron incidencia y luego los nuevos RF creados.

Anda y porque lo separáis en dos envíos? Hay alguna parte de la ley que lo diga?

en nuestro caso, todos los registros pendientes se ponen en el mismo paquete, marcando incidencia porque algunos de los registros están "fuera de plazo" y se envían todos juntos.

A parte, si separáis en dos envíos para no marcar los dos como incidencia, el siguiente envío será como mínimo 60 segundos mas tarde y podría ser que en ese momento ya también estuviera "fuera de plazo" y tuvierais que marcar también incidencia. No le veo motivo suficiente para separarlo en dos.

Gracias

[ermendalenda]

En la cabecera del envío es donde se marca si es invidenca y debes enviar todo lo que tengas, los que habías marcados y los que están en hora.
Si lo haces de otra forma ten en cuenta que:
1.Los envíos deben hacerse en orden cronológico de generación .
2. Si mandas un lote solo con las incidencias tienes que volver a esperar el minuto con lo cual, probablemente cuando vayas a mandar el siguiente lote vuelva a estar fuera de hora, y además detectará que tendrás registros generados antes del envío de las incidencias que tendrás que haber mandado, ya que tienes que enviar todos los que cumplan el requisito de haber pasado el tiempo[t].
En resumen todo lo que tengas después del tiempo[t] lo tienes que enviar sí o sí e el mismo lote como incidencia

[Jarogo08]

Empezado por rci

Anda y porque lo separáis en dos envíos? Hay alguna parte de la ley que lo diga?

en nuestro caso, todos los registros pendientes se ponen en el mismo paquete, marcando incidencia porque algunos de los registros están "fuera de plazo" y se envían todos juntos.

A parte, si separáis en dos envíos para no marcar los dos como incidencia, el siguiente envío será como mínimo 60 segundos mas tarde y podría ser que en ese momento ya también estuviera "fuera de plazo" y tuvierais que marcar también incidencia. No le veo motivo suficiente para separarlo en dos.

Gracias

Porque un envío va marcado como incidencia (con sus registros) y el otro no (con sus registros). Pero me acabo de dar cuenta que no estoy esperando los 60 segundos entre los dos envíos: salta el servicio, reviso los registros pendientes que hay, y si hay X "antiguos" e Y "nuevos" genero y mando los 2 envíos (sin separarlos los 60 segundos, van uno a continuación del otro).
Entiendo que esto es algo especial y no debería darse muy a menudo, pero igual le tengo que echar un vistazo. Igualmente, los 2 envíos entran sin problema

[rci]

Empezado por ermendalenda

En la cabecera del envío es donde se marca si es invidenca y debes enviar todo lo que tengas, los que habías marcados y los que están en hora.
Si lo haces de otra forma ten en cuenta que:
1.Los envíos deben hacerse en orden cronológico de generación .
2. Si mandas un lote solo con las incidencias tienes que volver a esperar el minuto con lo cual, probablemente cuando vayas a mandar el siguiente lote vuelva a estar fuera de hora, y además detectará que tendrás registros generados antes del envío de las incidencias que tendrás que haber mandado, ya que tienes que enviar todos los que cumplan el requisito de haber pasado el tiempo[t].
En resumen todo lo que tengas después del tiempo[t] lo tienes que enviar sí o sí e el mismo lote como incidencia

Así es como lo hacemos nosotros, por eso me extraña los tres compañeros que han comentado que separan en dos envíos.
No se si está bien o mal pero no veo el motivo.

[espinete]

Nosotros marcamos la cabecera con Incidencia si en el bloque que se va a enviar hay al menos un RF fuera de tiempo. Aunque el resto no lo estén.

¿Por qué?

Porque puedo

En realidad es por lo que si no, pasa lo que pone ermendalenda en el post anterior. Además de que se me complicaba demasiado el algoritmo en un software multi-tenant en la nube.

[espinete]

Empezado por rci

Así es como lo hacemos nosotros, por eso me extraña los tres compañeros que han comentado que separan en dos envíos.
No se si está bien o mal pero no veo el motivo.

El motivo probablemente es por la duda de si es correcto o no enviar RF en un bloque con incidencia si realmente esos RF concretos no tienen incidencia pero otros sí. Yo también tuve esa duda hace unas semanas, pero decidí enviar un solo bloque y no dos.

Entiendo que como la Incidencia va en la cabecera, significa que hace referencia al BLOQUE, no a un RF concreto, por lo que ya es cosa de ellos analizar el bloque. Simplemente les estás diciendo que "en este bloque hay alguna incidencia", no que todo el bloque la tenga.
Así lo entiendo yo. Otra cosa es que Hacienda ahora se reúna un viernes por la noche en un bar y decidan cambiar las cosas 3 días antes del 1 de Enero

[Jarogo08]

Empezado por espinete

Nosotros marcamos la cabecera con Incidencia si en el bloque que se va a enviar hay al menos un RF fuera de tiempo. Aunque el resto no lo estén.

Empezado por espinete

El motivo probablemente es por la duda de si es correcto o no enviar RF en un bloque con incidencia si realmente esos RF concretos no tienen incidencia pero otros sí. Yo también tuve esa duda hace unas semanas, pero decidí enviar un solo bloque y no dos.

¿alguien hizo la consulta? ¿quien se anima?

[rci]

Empezado por Jarogo08

¿alguien hizo la consulta? ¿quien se anima?

A mi me suena algunos posts en otros hilos que ya se hablaba de esto y creo recordar que no había problema para enviar la marca incidencia en la cabecera aunque algún registro de facturación del bloque estuviera dentro de tiempo y por lo tanto a ese RF no le hiciera falta la marca incidencia...

[VJSoftware]

Vale. Pues lo voy a hacer de la manera que decís, marcando todo el bloque como incidencia. Entiendo que si nos tiramos dos días sin internet, por la razón que sea, puede ser que se nos junten más de 1000 registros y entonces habrá que hacer dos bloques y marcarlos ambos como incidencia.

Resuelto. Muchas gracias.

No habéis abundado en lo de informar al usuario, suponemos entonces que alguien de la empresa podrá mirar los RF y ver el estado de su envío y tomar las decisiones que sean (subsanarlos, anularlos o simplemente volver a enviarlos). Madre del amor hermoso, esto va ser una auténtica locura con la cantidad de usuarios que tengo que no tienen ni idea de nada....Creo que el precio de los contratos de mantenimiento se va a multiplicar por 3. De verdad, con 60 tacos que tengo, tener que meterme ahora en esto...en fin.

[Jarogo08]

Yo lancé la consulta, a ver si me confirman que en un envío marcado como incidencias pueden ir registros que no son incidencias. Cuando me respondan lo pongo aquí