Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[thinkows]

Empezado por CarlosArjonomia

En el caso habitual de parámetros (1,0), el sistema informático enviará los registros de facturación individualmente y sin tener en cuenta tiempos de espera entre envíos.

Gracias, Carlos

En el ultimo documento especificaban :

Viene especificado en el artículo 16.2 de la orden:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre
envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser
tenido en cuenta para el siguiente envío.
El número máximo de registros a remitir en cada envío queda determinado por el diseño de registro incluido en el apartado 2.2 del anexo.
El funcionamiento será el siguiente:
a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t»
entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o
deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío,
la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva
actualización del valor del parámetro «t».
Ejemplo de respuesta con el parámetro de tiempo de espera de 60 segundos entre envíos:

<sf:TiempoEsperaEnvio>60</sf:TiempoEsperaEnvio>

Y en todas las pruebas devuelven 60.

Saludos

[bmfranky]

Empezado por thinkows

Gracias, Carlos

En el ultimo documento especificaban :

Viene especificado en el artículo 16.2 de la orden:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre
envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser
tenido en cuenta para el siguiente envío.
El número máximo de registros a remitir en cada envío queda determinado por el diseño de registro incluido en el apartado 2.2 del anexo.
El funcionamiento será el siguiente:
a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t»
entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o
deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío,
la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva
actualización del valor del parámetro «t».
Ejemplo de respuesta con el parámetro de tiempo de espera de 60 segundos entre envíos:

<sf:TiempoEsperaEnvio>60</sf:TiempoEsperaEnvio>

Y en todas las pruebas devuelven 60.

Saludos

Hola, si de momento devuelven 60 segundos, que es el minimo, pero cuando empecemos a enviar todos en serio y reciban bloques de 1 factura de 2.000.000 de usuarios a lavez, veras como te dicen que o agrupes mas o te esperes x tiempo.
por ejemplo yo hago las facturas de 1 en una, igual la siguiente la hago mañana o en 3 dias, no me voy a esperar a tener 10 facturaspara enviarlas todas en grupo, me esperare por ejemplo imaginemos 600", que a lo sumo es lo que tardaria en hacer otra factura y enviarla.

[CarlosArjonomia]

Empezado por bmfranky

Hola, si de momento devuelven 60 segundos, que es el minimo, pero cuando empecemos a enviar todos en serio y reciban bloques de 1 factura de 2.000.000 de usuarios a lavez, veras como te dicen que o agrupes mas o te esperes x tiempo.
por ejemplo yo hago las facturas de 1 en una, igual la siguiente la hago mañana o en 3 dias, no me voy a esperar a tener 10 facturaspara enviarlas todas en grupo, me esperare por ejemplo imaginemos 600", que a lo sumo es lo que tardaria en hacer otra factura y enviarla.

No se, me parece que han puesto ese campo para curarse en salud. Los servidores actuales pueden tragar millones de peticiones instantáneas. Y más los de hacienda. Espero que sea así, si no será otro problema.

[edari]

Hablando de agrupar o no agrupar...


Yo nunca mando sin agrupar, cada factura en un xml al estilo de Ticket Bai aunque me gustaría, porque no me convence eso de que unas veces los mandas sin agrupar otras agrupado...


Cómo hacéis vosotros?

[bmfranky]

Empezado por edari

Hablando de agrupar o no agrupar...


Yo nunca mando sin agrupar, cada factura en un xml al estilo de Ticket Bai aunque me gustaría, porque no me convence eso de que unas veces los mandas sin agrupar otras agrupado...


Cómo hacéis vosotros?

Hombre supongo que depende de tu linea de trabajo, si tienes que embiar los tickets de 10 cajas facturando al momento, igual no hace falta, pero si son 45 como en un carrefour ,lo logico es que los agrupes y envies los que se generen en los 3 minutos que tenemos de tiempo para el envio, creo yo.

Si facturas como yo , una factura cada vez que termino una reparacion, lo que pueden ser maximo 7 al dia, pues no voy a empaquetarlas y enviar 6 con incidencia, junto con la ultima sin...

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

Empezado por edari

Hablando de agrupar o no agrupar...
Yo nunca mando sin agrupar, cada factura en un xml al estilo de Ticket Bai aunque me gustaría, porque no me convence eso de que unas veces los mandas sin agrupar otras agrupado...
Cómo hacéis vosotros?

Nosotros tenemos una cola donde se van añadiendo las facturas (los terminales).
Por otro lado, un servicio que cada X segundos cogerá todas las de la cola y las enviará. Según la respuesta, si hay que cambiar el tiempo, pues variará el parámetro X hasta el siguiente envío.
Si se llega a las 1000 ( el valor límite Y) facturas antes de el tiempo X se envía y de nuevo a esperar.

[ermendalenda]

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

Nosotros tenemos una cola donde se van añadiendo las facturas (los terminales).
Por otro lado, un servicio que cada X segundos cogerá todas las de la cola y las enviará. Según la respuesta, si hay que cambiar el tiempo, pues variará el parámetro X hasta el siguiente envío.
Si se llega a las 1000 ( el valor límite Y) facturas antes de el tiempo X se envía y de nuevo a esperar.

En mi caso cada terminal es un SIF distinto.
Una cola en cada uno.
Ahira que te leo a ver si hago una prueba de enviar 1000 registros a ver como se comportan los servicios.

[antoniomarquezc]

Hola a todos.

¿Alguien sabe si hay que incluir las retenciones que pueda llevar una factura ?

[ermendalenda]

Empezado por antoniomarquezc

Hola a todos.

¿Alguien sabe si hay que incluir las retenciones que pueda llevar una factura ?

Pues la verdad no he visto ninguna mención sobre irpf ni ninguna otra retención en verifactu, es raro no?
Por que si se lo descuentas de la factura para que el clientebpague el irpf en tu nombre pero no lo declaras en verifactu, mmmm, cuando den el próximo paso que hagan el modelo 303 automáticamente, como lo contemplan?
Vaya lio

[ermendalenda]

Empezado por bmfranky

Hola, si de momento devuelven 60 segundos, que es el minimo, pero cuando empecemos a enviar todos en serio y reciban bloques de 1 factura de 2.000.000 de usuarios a lavez, veras como te dicen que o agrupes mas o te esperes x tiempo.
por ejemplo yo hago las facturas de 1 en una, igual la siguiente la hago mañana o en 3 dias, no me voy a esperar a tener 10 facturaspara enviarlas todas en grupo, me esperare por ejemplo imaginemos 600", que a lo sumo es lo que tardaria en hacer otra factura y enviarla.

Lo dificil es combinarlo con el warning que te devuelven, que has superado el tiempo de 120 segundos, no sé qué importancia le darán a la constancia de pasarse del tiempo, pero yo voy a tenerlo lo más atado posible

[bmfranky]

Empezado por ermendalenda

Lo dificil es combinarlo con el warning que te devuelven, que has superado el tiempo de 120 segundos, no sé qué importancia le darán a la constancia de pasarse del tiempo, pero yo voy a tenerlo lo más atado posible

Hola, una cosa, no entiendo como se os puede pasar el tiempo entre que la generas y embias.
Si es porque el servidor no la acepta, pues tendras que enviarla como incidencia, deveriaias asignar El campo " altaFactura.FechaHoraHusoGenRegistro" , lo ultimo antes de serializar y visualizar la factura, y si es por empaquetar varias, poner un temporizador que cierre el registro de envio a los x segundos.

[ermendalenda]

Empezado por bmfranky

Hola, una cosa, no entiendo como se os puede pasar el tiempo entre que la generas y embias.
Si es porque el servidor no la acepta, pues tendras que enviarla como incidencia, deveriaias asignar El campo " altaFactura.FechaHoraHusoGenRegistro" , lo ultimo antes de serializar y visualizar la factura, y si es por empaquetar varias, poner un temporizador que cierre el registro de envio a los x segundos.

Existen varios motivos por los que puede pasar.
Si tienes 100 comercios xon 2 o 3 tpvs en cada uno y el 50 % dependiente de un router de datos por tener dificl la instalación de cableado etc..
Esta claro que sí lo pones como incidencia, aparentemente problema resuelto, pero si tienes un comercio en una zona de difícil cobertura vas a estar mandando las incidencias continuamente, lo dejas en cola, detectas que no has podido mandarlo a tiempo y lo pones como incidencia.
Para mi marcarlo como incidencia es casi igual que no marcarlo, y creo que para ellos es igual, por que, si tienen tiempo y dependiendo del numero de incidencias o de envíos fuera de hora te pueden clavar la inspección.
Lo de marcarlo como incidencia es solo para que digas "ya lo sé" antes de que te lo digan ellos.. Absurdo.

[bmfranky]

Empezado por ermendalenda

Existen varios motivos por los que puede pasar.
Si tienes 100 comercios xon 2 o 3 tpvs en cada uno y el 50 % dependiente de un router de datos por tener dificl la instalación de cableado etc..
Esta claro que sí lo pones como incidencia, aparentemente problema resuelto, pero si tienes un comercio en una zona de difícil cobertura vas a estar mandando las incidencias continuamente, lo dejas en cola, detectas que no has podido mandarlo a tiempo y lo pones como incidencia.
Para mi marcarlo como incidencia es casi igual que no marcarlo, y creo que para ellos es igual, por que, si tienen tiempo y dependiendo del numero de incidencias o de envíos fuera de hora te pueden clavar la inspección.
Lo de marcarlo como incidencia es solo para que digas "ya lo sé" antes de que te lo digan ellos.. Absurdo.

Los 300 tpvs, los encadenas desde un unico servidor??, ya os digo me alucina, mi forma de pensar es monopunto como los coches antiguos... Pensar en atender tantos puntos a la vez.. bufff

[ermendalenda]

Empezado por bmfranky

Los 300 tpvs, los encadenas desde un unico servidor??, ya os digo me alucina, mi forma de pensar es monopunto como los coches antiguos... Pensar en atender tantos puntos a la vez.. bufff

Nos. Pero la intención era enviarlo a un punto común (un servidor de una empresa externa) para que hicieran el trabajo de enviarlos como terceros.
Hasta que henos visto los tiempos. Así que al ver que tu pusiste lo de que se podía hacer el soap a pelo, me puse yo a programr el envio. bufff menos mal

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

Empezado por ermendalenda

Lo dificil es combinarlo con el warning que te devuelven, que has superado el tiempo de 120 segundos, no sé qué importancia le darán a la constancia de pasarse del tiempo, pero yo voy a tenerlo lo más atado posible

Entiendo que ese tiempo es variable según la respuesta de tiempo mínimo hasta el siguiente envío.
Si en la respuesta te devuelven que el siguiente envío debe ser como muy pronto en 60 sg. No deberían pasar más de 120 sg. entre generar y enviar.

Si el timpo lo suben a 300 sg. lo lógico será que el tiempo de warning sea de 600 sg. (por poner una relación).

Es una forma de asegurarse de que el envío es "inmediato"; es decir, que no envías las facturas al final del día, por decirlo así.