Buenos días.

Estoy un poco perdido en este asunto del control de flujo.
Tengo claro por la documentación, que en la respuesta nos marcarán un tiempo mínimo de espera.
Pero lo que no entiendo es cuando habláis de 120" (de límite desde que se generan el Registro de facturación hasta que se envía), ¿Dónde viene este requisito?

Os pongo un ejemplo, como funcionaría mi sistema:

1º En la base de datos, se genera/n 1, 2, 5 facturas.
2º Hago el envío de esa/s factura/s
3º Espero el tiempo que me indiquen
4º Compruebo la base de datos, vuelvo al punto 1º.

¿Dónde están esos 120"? o ¿Dónde los debería aplicar?

Espero haberme explicado bien.

Muchas Gracias.

Esos 120" son entre el punto 1 y el punto 2.
Si todo funciona bien no tiene porqué pasar, pero en determinados casos se podría dar ese error.

No se cómo haces el envío, pero imagina que lo haces desde tu mismo programa. Podría pasar si se diera esta situación:


1º En la base de datos, se genera/n 1, 2, 5 facturas.
==> Se produce una excepción, el programa se cierra y el usuario tarda unos minutos en arrancarlo de nuevo.

2º Hago el envío de esa/s factura/s

En este caso el tiempo entre que las has generado y las has enviado son más de 120". Este es un caso excepcional y no debería darse continuamente.
Es una forma de conseguir que las facturas se envíen "inmediatamente".
Al principio la gente hablaba de ir generando facturas y enviarlas al final de día o cada hora (o el usuario manualmente) para simplificar. Con esta restricción te están diciendo que eso "no vale".

Hola.

Gracias por tu respuesta.

Me he leído el hilo con más detenimiento y ya me ha quedado claro el asunto.
La filosofía que quería plantear, por lo que estoy viendo no sería correcta, generar la factura en BD y después con posterioridad hacer el envío, y la hora de la factura sería la del envío.
El asunto del QR, que habéis comentado, podría dar problemas (lectura QR antes del envío de la factura.


Me ha quedado claro, que lo que tenía en mente, no vale ^\||/


Leyendo el Hilo, me ha generado otra duda. ¿Es obligatorio generar el XML de cada factura o grupo de facturas que se envían?


Muchas Gracias !!!!!

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 !!!!

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

...y se las traga todas sin rechistar.

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

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.

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.

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

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.

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

Respuesta de Hacienda sobre qué pasará si se envían varias facturas, una a una, sin respetar el Tiempo de Espera:

Creo que ni ellos mismos saben todavía qué hacer en estos casos.

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" :D)

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

Yo creo que cuando el error sea ese, no voy a hacer nada. Simplemente las marco como "enviada" y listo. No quiero tener que hacer otro envío adicional innecesario, tener de nuevo en cuenta el tiempo de espera, etc.

Y si no, que la acepten sin errores. Si al final la van a aceptar y no requiere subsanación, pa qué aceptarla "con errores"? Acéptala y punto!

cuánta razón tienes...

Yo voy a hacer otra cosa:
Cuando vaya a realizarse el envío, compararé la fecha y hora en que se generó el registro de facturación que tengo grabado, con la fecha y hora actuales. Si la diferencia supera los 120' marcaré el envío con INCIDENCIA='S'.

Exactamente esto es lo que hacemos nosotros, y creo que también otros compañeros, porque ya se ha comentado en otros posts

Lo único que dudo es del valor, porque inicialmente eran 120 segundos pero ahora me parece que ya son 240, por lo que si la diferencia es por ejemplo 150 segundos, imagino que no haría falta marcar como incidencia.
Pero como vayan cambiando ese valor...

Saludos

Yo hago eso, desde que comienzo a generar el RF hasta que se envia si pasan mas de 120 segundos marco la cabecera con S en incidencia.

Hombre
Si tienes en cuenta de que te pueden cambiar el tiempo no estaría mal. Pero q0 segundos a pelo puedes tener problemas

Para el que lo use, el servicio de respuesta del ROA, esta caido....

Hola a tod@s

Ya tengo casi terminado el control de flujo + tiempo de espera, etc. pero me surge una duda.
Por lo general, el tiempo de espera mínimo es de 60 segundos. Al menos yo nunca he recibido otro distinto nunca.
Pero he leído que hay gente que hace los envíos cada 30 segundos, otros cada 50, etc. Yo hasta ahora he estado probando cada 30 porque mis clientes harán como mucho 1 factura por minuto, y esperar 60 para el envío me parece mucho.

Pues eso. ¿Vosotros sois 100% estrictos haciéndolo cada 60 segundos o lo hacéis cada menos tiempo?

La única pega que le veo a esperar "tanto" es que la validación del QR no estará disponible hasta 1 minuto después (en el peor de los casos). No es que me preocupe, pero algún cliente se quejará de que "he comprobado el QR y dice que aún no se encuentra la factura" :rolleyes:

Hombre... ya puestos lo suyo es hacer caso a las indicaciones de la aeat, a ti te va a costar lo mismo el desarrollo y cumples la norma. Yo en particular cumplo de forma estricta el tiempo que me devuelve en el envío anterior.


Saludos.

yo lo hago así:


https://www.clubdelphi.com/foros/sho...6&postcount=46

Si, yo creo que la mayoría lo hacemos así.

Buenas a todos,

he preguntado esto a VeriFactu

Cuando me respondan, si lo hacen pego la respuesta

Yo entiendo que lo estás haciendo de manera correcta, y en un par de minutos el cliente ya verá que sí existe la factura. Yo ya no le doy más vueltas a los envíos, nos dejaron claro que había que esperar entre envío y envío
Pero bueno, con lo que te contesten nos dices!

Yo pregunté lo mismo hace tiempo. Tardaron lo suyo en responder, pero finalmente respondieron. Creo que dejé la respuesta más arriba en el hilo, no me acuerdo ya.
No te van a dejar nada claro, pero te van a decir que lo IDEAL es usar el control de flujo ese que exigen, aunque en el 99% de mis clientes no se haga más de una factura por minuto.

Ellos mismos me dijeron que "siendo estrictos y puristas, la documentación habla de "inmediatez", pero sin embargo se exige un tiempo de espera"

Así que se contradicen un poco. Al final me dijeron que que mantuviera el control de flujo aunque en el 99% de los casos lo ideal sea el envío instantáneo.

Yo referido a este tema tengo varias dudas si nos enfocamos en un bar por ejemplo.
Ellos van sacando tickets, si no ha pasado el tiempo de espera desde el último envío, no puedes hacer a la persona que esté atendiendo que se quede esperando para que finalmente el ticket se envíe a la AEAT y te devuelva estado correcto, imprimir el ticket con el QR correcto... Por lo que, obviamente, nos tenemos que acoger a imprimir la factura simplificada con su QR construido aunque esta aún no haya sido emitida a la AEAT, hasta aquí todo bien, pero si por algún casual te la acaban rechazando, has impreso y entregado una factura simplificada a un cliente que no existe en la AEAT y que puede comprobarse por medio del QR... ¿Debes corregir esa factura simplificada en el momento, y entregarle la factura subsanada o rectificada al cliente? No lo veo

Por otro lado, tampoco puedes pedir a la gente que esté cobrando en un bar que con todo el jaleo que tienen de normal, se pongan a hacer subsanaciones, rectificativas o lo que haya que hacer en el caso de que te devuelva que alguna factura simplificada tiene algún error...

Me suena de haber leído en alguna respuesta (creo que a la que se refieres @espinete) de alguien que si se generan pocas facturas te podías salta el tiempo de espera, pero no confirmaban ni dejaban claro nada.

Si es a un cliente de contado no se me ocurren muchos casos en los que pueda dar error (el que creo que va a ser más común, el del cif incorrecto, en ese caso ya no lo tendrías), a no ser que sean problemas de creación del xml (errores de programación, digamos). Y en ese caso, tras corregirlos, el registro debería terminar subiendo y la impresión que se llevó el cliente con su QR terminará dando que la factura es correcta. ¿no?

Más o menos te van a responder que las van a aceptar si no es una barbaridad de facturas por minuto, o sea, ellos ya están respondiendo que normalmente se puede mandar sin esperar el tiempo de wnvio(inmediatamente) si no detectan un uso abusivo.
En las pruebas que realicé hace tiempo te baneam unos minutos si haces emvios de muchísimos registros a la vez y recurrentemente

Opcionalmente puedes pedir que te den un correo o teléfono l(digo opcionalment3 por que no puedes obligarlo) u eso te va a ayudar a avisar al cliente de que le has dado mal la factura.

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

Desde mi punto de vista el control de flujo tiene una función oculta que no dicen, y es que si permitieran enviarlas de forma inmediata podrías, en caso de rechazo, no generar la factura y reutilizar el numero y eso ellos no quieren que ocurra. Esta es mi opinión, pero parece evidente, no veo otro sentido

Se lo consulté a la AEAT y aquí la respuesta, por lo que dicen, se podrá emitir la factura simplificada con el QR aunque aún no se haya emitido y, de ser rechazada, no sería un problema mientras se corrija cuanto antes... Aunque esto seguiría dejando al cliente con una factura simplificada que si la consulta le sale que no existe...

Resalto en negrita la respuesta de la AEAT para que se entienda el flujo de los mensajes.

Espero que os sirva de ayuda! :D

Yo tengo una duda respecto a esto del control de flujo. Entiendo que el limite actual de tiempo "establecido" son 240 segundos, que está por encima de los 60 segundos que devuelve la respuesta "normal" ahora mismo. Sin embargo el control de flujo está para que si se les saturan los servidores, aumentar los tiempos entre envíos. El día que se les saturen (que lo harán), si te dan un tiempo entre envíos de 1 hora, ¿¿¿ hay que marcar los registros que pasen de 240 segundos de su generación como incidencia ??? :confused:

Hola
No son 240 segundos
Es el tiempo que te envian de espera +180
Si son 60 será 60+180
Si es una hora será 3600+180

Entendido, gracias !!!

Disculpa, ya he visto que has respondido esto mismo en otras ocasiones. Esto te ha venido en alguna respuesta de la AEAT o figura en alguna documentación ??.
Si es esto último, me la indicas por favor ?