Tiempos de envios

[_Io]

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

Si tu programa/ERP es de facturación, si. Todas las facturas que emita, deben generar XML y se debe enviar o no (dependiendo si es VeriFactu o no-verifactu).

Salvo casos raros y otras excepciones. En funcionamiento normal si.

Perfecto.
Muchas Gracias !!!!

[espinete]

Hace tiempo que no visitaba este hilo.

Nosotros hasta ahora hemos estado enviando las facturas una a una, a medida que se van generando en el SIF.
Puede que no sea lo más recomendable, pero para las pruebas lo hemos estado haciendo así.

(y de hecho para TicketBai funciona así también, no existe nada de eso de tiempos de espera).

Por ahora el TiempoEsperaEnvio que se recibe en las respuestas no vale para nada. No lo están controlando. En nuestras pruebas siempre devuelve "60", pero nosotros hemos podido enviar facturas una a una cada 2 o 3 segundos (incluso menos) entre una y otra sin problema.
Lo digo por si alguien sabe si Hacienda no está controlando esto aún. Les he preguntado pero llevan 2 semanas pensando qué responder. Deben estar eligiendo el tipo de letra o algo...

Además del flujo recomendado (enviar en bloques, respetar el tiempo mínimo de espera, etc.) tengo una duda con respecto al Huso Horario...

¿Qué se debe hacer si una empresa tiene varios empleados teletrabajando, cada uno en un país distinto, incluso en USA, Japón, etc.? ¿Qué pasa si un empleado está en Japón pero su equipo está configurado con "Config. Regional España", etc.? ¿Cómo obtengo el huso horario real de forma 100% fiable?

Yo hasta ahora en nuestras pruebas hemos estado enviando los RF usando la FechaHora actual del PC...

   XSDatetime := TXSDatetime.Create;
   XSDatetime.AsDateTime := now;
   XSDatetime.FractionalSeconds := 0;
   Factura.RegistroAlta.FechaHoraHusoGenRegistro := XSDatetime;

...y se las traga todas sin rechistar.

Así que ya no sé si es que Hacienda está ignorando ese control o qué.

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

Ya lo hemos hablado.
No te puedes fiar de cosas que ahora no se hagan, primero porque es preproducción dentro de las pruebas y puede haber validaciones que todavía no estén activas y segundo, porque ahora es posible que no haya sobrecarga, pero cuando entren los clientes reales es muy posible que esto entre en funcionamiento.
Al final lo que manda es la documentación, no como esté funcionando ahora el sistema.

[espinete]

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

Ya lo hemos hablado.
No te puedes fiar de cosas que ahora no se hagan, primero porque es preproducción dentro de las pruebas y puede haber validaciones que todavía no estén activas y segundo, porque ahora es posible que no haya sobrecarga, pero cuando entren los clientes reales es muy posible que esto entre en funcionamiento.
Al final lo que manda es la documentación, no como esté funcionando ahora el sistema.

Estoy de acuerdo, pero por qué entonces con TicketBAI no se requiere enviar en bloque (salvo Bizkaia, pero no es obligatorio)? ¿Acaso no hay empresas grandes en Gipuzkoa o Araba?

Supongo que es porque no es lo mismo una provincia que 20, pero es que tampoco he tenido que cumplir este requisito de "tiempo de espera" con la factura electrónica de México, Guatemala ni Costa Rica.

Obviamente habrá que hacerlo así, pero que se hayan puesto tan tiquismiquis con esto...

[ermendalenda]

Empezado por espinete

Estoy de acuerdo, pero por qué entonces con TicketBAI no se requiere enviar en bloque (salvo Bizkaia, pero no es obligatorio)? ¿Acaso no hay empresas grandes en Gipuzkoa o Araba?

Supongo que es porque no es lo mismo una provincia que 20, pero es que tampoco he tenido que cumplir este requisito de "tiempo de espera" con la factura electrónica de México, Guatemala ni Costa Rica.

Obviamente habrá que hacerlo así, pero que se hayan puesto tan tiquismiquis con esto...

Es un error, que hayan puesto ese control tan diferente a todos, aunque yo tengo controlado el control de flujos que solicitan estoy seguro de que o no activan el control o.lo quitan y solo dejan que te dé el warning cuando mandes fuera de plazo (los 120segundos famosos, que por cierto tampoco se enteran como va)
El de envío.ppr bloques y esperas no.se.entera el.80% de los desarrolladores con los que he hablado u están haciendo.lo que dices, enviando inmediatamente y están superorgullosos jeje
Al.igual que pienso que en poco tiempo.agr3garan un nodo con los items, no entiendo por qué no lo.hacen del tirón, es marear y marear.
Cada uno tiene sus errores en Perú con el uBL también tienen sus errores de diseño

[espinete]

Os pongo la respuesta que me acaban de dar desde la AEAT sobre el "Tiempo de Espera". Les pregunté si era estrictamente obligatorio, o si como en TicketBAI se pueden enviar las facturas simultáneamente (a medida que se emiten).

Primero me explican la normativa, reglamento, etc. porque les encanta escribir frases con numeritos de leyes y fechas que ignoro por completo.
Luego responden a la consulta:

Por lo tanto, y en respuesta a su consulta, si nos atenemos a la norma se tendría que enviar en ese rango mayor de 60 segundos, aunque si somos puristas en el Reglamento (RD 1007/2023) se habla de generación simultánea. Dicho lo cual, si se envía sin tiempo de espera no se produce ni se producirá un error, aunque no se estará cumpliendo estrictamente con la Orden Ministerial, pero entendemos que para casos donde está enviando 1 o 2 facturas por minuto, esta circunstancia es aceptable y asumible por la AEAT. Si se sobrepasa dicho número sí hay que respetar el mecanismo de control de flujo establecido, es decir, esperar el tiempo de espera entre envíos de 60 segundos, o bien acumular 1000 registros a enviar, la circunstancia que ocurra primero, para remitir el siguiente envío.

Dicho esto, está claro que lo más fiable es desarrollar un sistema que tenga en cuenta ambas cosas, por si acaso, aunque en el 99% de los casos bastará con enviar las facturas sobre la marcha.

Desde luego, menos dolor de cabeza dará enviarlas sobre la marcha, instantáneamente, pero por si las moscas habrá que prever cualquier escenario.

Otra cosa que me indican en la respuesta es la siguiente:

...si se superan los 240 segundos (actualmente es el umbral establecido) entre la fecha y hora de generación del registro (campo "FechaHoraHusoGenRegistro" del registro de facturación) y su recepción en los sistemas de la AEAT (campo "TimeStampPresentacion" de la respuesta obtenida) el registro se aceptará pero en estado "Aceptado con errores" e indicando el error 2004: El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 240 segundos. Este error se excepciona de la necesidad de ser subsanado por lo que no será necesaria ninguna operación posterior.

Es decir, si se envían las facturas fuera de "plazo", las aceptan con errores, pero no es necesario reenviarlas (obviamente, porque está enviada y no hay nada que se pueda corregir, salvo que tengas un Delorean).
Así que en este caso, ese error no se subsana, ni se rectifica ni nada. Habrá que tenerlo en cuenta para que no se marque esa factura como "pendiente de reenviar" ni nada parecido.

[espinete]

Por cierto, alguien sabe qué código de error devolverá Hacienda si enviamos una factura ANTES de que pasen esos 60 segundos de Tiempo de Espera? Por ahora no están controlando eso, pero digo yo que si algún día lo controlan, crearán un error específico que deberíamos tener en cuenta para saber cómo actuar: si esperar un poco más, esperar al siguiente bloque...

[Jarogo08]

Empezado por espinete

Es decir, si se envían las facturas fuera de "plazo", las aceptan con errores, pero no es necesario reenviarlas (obviamente, porque está enviada y no hay nada que se pueda corregir, salvo que tengas un Delorean).
Así que en este caso, ese error no se subsana, ni se rectifica ni nada. Habrá que tenerlo en cuenta para que no se marque esa factura como "pendiente de reenviar" ni nada parecido.

En nuestro caso, contemplamos que la puedas subsanar creando simplemente otro registro igual al anterior. Si la subes ya te devuelve correcto, y así no quedan facturas "aceptadas con errores", que quedan feas en la lista de facturas (me gusta más ver todo "correcto" )

Y estamos planteando que el usuario no tenga ni que subsanarlo, que sea automático: si al obtener la respuesta tenemos un error 2004 automáticamente creamos el nuevo registro.

Saludos

[Decanato]

Empezado por espinete

Os pongo la respuesta que me acaban de dar desde la AEAT sobre el "Tiempo de Espera". Les pregunté si era estrictamente obligatorio, o si como en TicketBAI se pueden enviar las facturas simultáneamente (a medida que se emiten).

Primero me explican la normativa, reglamento, etc. porque les encanta escribir frases con numeritos de leyes y fechas que ignoro por completo.
Luego responden a la consulta:



Dicho esto, está claro que lo más fiable es desarrollar un sistema que tenga en cuenta ambas cosas, por si acaso, aunque en el 99% de los casos bastará con enviar las facturas sobre la marcha.

Desde luego, menos dolor de cabeza dará enviarlas sobre la marcha, instantáneamente, pero por si las moscas habrá que prever cualquier escenario.

Otra cosa que me indican en la respuesta es la siguiente:



Es decir, si se envían las facturas fuera de "plazo", las aceptan con errores, pero no es necesario reenviarlas (obviamente, porque está enviada y no hay nada que se pueda corregir, salvo que tengas un Delorean).
Así que en este caso, ese error no se subsana, ni se rectifica ni nada. Habrá que tenerlo en cuenta para que no se marque esa factura como "pendiente de reenviar" ni nada parecido.

Esto es muy interesante... Obvio que si quieren fomentar la inmediatez del envío no deberían poner trabas precisamente para hacerlo, y me da la sensación de que se les pasa por la cabeza que han caído en una contradicción... Yo hago pruebas de envíos "reales" cuando genero las facturas de soporte mensual a mis clientes y las mando al entorno de pruebas, el proceso es automático e INICIALMENTE he optado por saltarme el control de flujo y me van entrando como correctas, a pesar de que se genera una tras otra con márgenes inferiores al minuto... Algo haré con eso, pero creo que será una de las últimas cosas que trate

[ermendalenda]

Empezado por espinete

Hace tiempo que no visitaba este hilo.

Nosotros hasta ahora hemos estado enviando las facturas una a una, a medida que se van generando en el SIF.
Puede que no sea lo más recomendable, pero para las pruebas lo hemos estado haciendo así.

(y de hecho para TicketBai funciona así también, no existe nada de eso de tiempos de espera).

Por ahora el TiempoEsperaEnvio que se recibe en las respuestas no vale para nada. No lo están controlando. En nuestras pruebas siempre devuelve "60", pero nosotros hemos podido enviar facturas una a una cada 2 o 3 segundos (incluso menos) entre una y otra sin problema.
Lo digo por si alguien sabe si Hacienda no está controlando esto aún. Les he preguntado pero llevan 2 semanas pensando qué responder. Deben estar eligiendo el tipo de letra o algo...

Además del flujo recomendado (enviar en bloques, respetar el tiempo mínimo de espera, etc.) tengo una duda con respecto al Huso Horario...

¿Qué se debe hacer si una empresa tiene varios empleados teletrabajando, cada uno en un país distinto, incluso en USA, Japón, etc.? ¿Qué pasa si un empleado está en Japón pero su equipo está configurado con "Config. Regional España", etc.? ¿Cómo obtengo el huso horario real de forma 100% fiable?

Yo hasta ahora en nuestras pruebas hemos estado enviando los RF usando la FechaHora actual del PC...

   XSDatetime := TXSDatetime.Create;
   XSDatetime.AsDateTime := now;
   XSDatetime.FractionalSeconds := 0;
   Factura.RegistroAlta.FechaHoraHusoGenRegistro := XSDatetime;

...y se las traga todas sin rechistar.

Así que ya no sé si es que Hacienda está ignorando ese control o qué.

Lo del uso horario tendrás que rescatar de Windows cual es el que tiene seleccionado el operador, se sup0ne que Windows tiene una opción que debe funcionar y elegir la hora automáticamente según desde donde se conecte.
En todo caso si no la tienen elegida bien tampoc9 emitirán las facturas a la hora del país de origen, o sea que no darán error en verifactu.
En resumen rescata el.huso del sistema.