España: Normativa sancionadora sistemas informáticos

[VictorCasajuana]

Duda.
He leído que no hay problema en enviar facturas a Verifactu con fecha emisión anterior a la de su envío a Verifactu.
Ahora bien, se de una persona que envía las facturas de alquiler días antes de la fecha factura (envío el dia 28 de mes, fecha factura día 1 del mes siguiente) . De esto no he encontrado nada. Si las envía a Verifactu... Qué ocurrirá?

Muchas gracias,

Yo pondría como fecha Operación el día 1 y como fecha emisión 28 ya que es el día que se crea la factura.

[paquitohm]

t= 60
Se hace un primer envio y hasta pasado t entonces no se puede volver a enviar
Pero y si en la espera se han impreso mas ? Las tiene que mandar el usuario. Pero y si se le olvida, entonces ya no seria envio "inmediato". Entonces, parece que tiene que haber un demonio enviador dando vueltas aunque tu sistema tenga un solo usuario con un pc en un rincon de una fabrica

[FiveWiDi]

Yo pondría como fecha Operación el día 1 y como fecha emisión 28 ya que es el día que se crea la factura.

Gracias Víctor, pero no es el caso.

La factura y la operación tendran fecha de emisión día 1 de mes, pero hoy en día la envían 4 días antes.

No se... en las pruebas veremos que responde Hacienda (Verifactu).

Muchas gracias,

[FiveWiDi]

t= 60
Se hace un primer envio y hasta pasado t entonces no se puede volver a enviar
Pero y si en la espera se han impreso mas ? Las tiene que mandar el usuario. Pero y si se le olvida, entonces ya no seria envio "inmediato". Entonces, parece que tiene que haber un demonio enviador dando vueltas aunque tu sistema tenga un solo usuario con un pc en un rincon de una fabrica

Ahí está la cosa; lo puedes enviar más tarde si te lo dice Hacienda, pero y si lo decides tu?

El tema del demonio, yo le meteré un TIMER que avise si hay envíos pendientes, y que el usuario le de al botón. De paso el TIMER tendrá en cuenta el 'retardo' que nos haya indicado Verifactu en el último envío.

Este desarrollo parecía relativamente sencillo, pero debe contemplar situaciones que no se pueden dejar que se resuelvan a mano, la 'liarían parda' los usuarios.

Por ejemplo debe haber un historial de xml enviados que se relacionen con las facturas que en ellos se tratan, no es una relación 1 factura a 1 xml. Siempre es bueno tener información de lo que se ha hecho.
Si en un envío hay un error se debe volver a enviar con los datos erróneos del primer envío corregidos (eso he entendido), por tanto una misma factura puede aparecer en 'n' xml diferentes. Por cierto ese envío de la corrección, cuando debe hacerse? Antes de la siguiente factura? Cuando tengamos tiempo de resolver el error?

Otra cuestión. Asi como contemplar y establecer un procedimiento para tratar esos 'retardos' en el envío del xml, momento en el cual puedes tener 1 o varios xml pendientes de enviar; entonces que hago? Me los cargo todos y hago uno solo? los envío uno detrás de otro con su respectivo 'retardo'? Y me planto en el cierre de la oficina con varios xml pendientes de enviar?
Creo que estableceré un estado 'EnColaVF' y cuando se pueda enviar el xml, en ese momento lo creo con todo lo pendiente y lo envío.

Ese 'retardo' a final de mes (trimestre/año) puede ser considerable.

Muchas gracias,

[paquitohm]

Hola,

Ahí está la cosa; lo puedes enviar más tarde si te lo dice Hacienda, pero y si lo decides tu?

No entiendo bien a qué te refieres
Entiendo que hay que enviar inmediatamente en cuanto permita el flujo de la infraestructura de la agencia

El tema del demonio, yo le meteré un TIMER que avise si hay envíos pendientes, y que el usuario le de al botón. De paso el TIMER tendrá en cuenta el 'retardo' que nos haya indicado Verifactu en el último envío.

No recuerdo si al final t=60 iba a ser fijo o iba a venir como tag en la respuesta. En todo caso parece que tenemos que trabajar con t variables.
Si, como comentas habrá que usarlo. Estoy pensando en que el timer, si hay pendiente de envio y el flujo está ok, hará una llamada automatica al ejecutable con un parametro ProgramaMio /ENVIA_VERIFACTU y así simulo multitarea y tambien impido que el usuario pueda cerrar el programa bruscamente durante el envio

Este desarrollo parecía relativamente sencillo, pero debe contemplar situaciones que no se pueden dejar que se resuelvan a mano, la 'liarían parda' los usuarios.

Así es. Esto complica el proceso de facturacion pero lo peor es que lo limita y obliga a ir a rectificativas

Por ejemplo debe haber un historial de xml enviados que se relacionen con las facturas que en ellos se tratan, no es una relación 1 factura a 1 xml. Siempre es bueno tener información de lo que se ha hecho.

Buena idea.
En mi programa tengo ya un log para el proceso automatico de contabilizacion de facturas y un log para el proceso de generacion-impresion de facturas. Tambien tengo un log para el tema del TicketBAI donde se relacionan los pasos que se hacen. Se trataria de incorporar al log el .xml donde "viaja" la factura o incluso, por cada registro en la tabla facturas_ventas se puede crear un campo donde indique el .xml desde el que se envió la fra.

Si en un envío hay un error se debe volver a enviar con los datos erróneos del primer envío corregidos (eso he entendido), por tanto una misma factura puede aparecer en 'n' xml diferentes. Por cierto ese envío de la corrección, cuando debe hacerse? Antes de la siguiente factura? Cuando tengamos tiempo de resolver el error?

Hasta donde yo sé Verifactu no permite modificaciones: Altas y Anulaciones solamente. Modificaciones, si no son Anulaciones, se habrán de hacer con nueva factura a través de Rectificativa.

Otra cuestión. Asi como contemplar y establecer un procedimiento para tratar esos 'retardos' en el envío del xml, momento en el cual puedes tener 1 o varios xml pendientes de enviar; entonces que hago? Me los cargo todos y hago uno solo? los envío uno detrás de otro con su respectivo 'retardo'? Y me planto en el cierre de la oficina con varios xml pendientes de enviar?
Creo que estableceré un estado 'EnColaVF' y cuando se pueda enviar el xml, en ese momento lo creo con todo lo pendiente y lo envío.

Ese 'retardo' a final de mes (trimestre/año) puede ser considerable.

Si, lo que comentas parece lo mejor: El .xml se genera justo cuando se puede enviar y no antes, es decir, la "cola" ha de ser de envios pendientes (facturas) y no de .xml(s)

Salu2

[VictorCasajuana]

una opción buena para los fallos de envío es tener una cola FIFO de los XML que se han generado y cada vez que se genere uno nuevo, pues se mete en la cola y se procesa, así te aseguras la secuencialidad de los envíos. Esto, mejorable por supuesto con los timers que indicáis para que sea más transparente al usuario.

[VictorCasajuana]

Yo pondría como fecha Operación el día 1 y como fecha emisión 28 ya que es el día que se crea la factura.

Gracias Víctor, pero no es el caso.

La factura y la operación tendran fecha de emisión día 1 de mes, pero hoy en día la envían 4 días antes.

No se... en las pruebas veremos que responde Hacienda (Verifactu).

Muchas gracias,

Revisando las preguntas y respuestas: https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/20240214-Preguntas-respuestas-Verifactu.pdf cuando se pregunta si la fecha de la factura no es la del día en que se genera, te remiten a la fecha de operación. No obstante, supongo que cuando saldrá el reglamento definitivo habrá muchas preguntas sobre esta fecha, ya que suele ser una práctica habitual en algunos sectores que no sea la del día que se emite la factura.
Queda poco margen ya para que publiquen el reglamento y se pueda cumplir el la fecha 1-7-25 teniendo en cuenta los 9 meses de plazo.

[paquitohm]

Hola,

una opción buena para los fallos de envío es tener una cola FIFO de los XML que se han generado y cada vez que se genere uno nuevo, pues se mete en la cola y se procesa, así te aseguras la secuencialidad de los envíos. Esto, mejorable por supuesto con los timers que indicáis para que sea más transparente al usuario.

Por lo que comenta el compañero, me pareciera a mi que, como comenté anteriormente, se hace necesario crear los .xml en el momento del envio

[paquitohm]

Si, lo que comentas parece lo mejor: El .xml se genera justo cuando se puede enviar y no antes, es decir, la "cola" ha de ser de envios pendientes (facturas) y no de .xml(s)
Salu2

Rizando el rizo rizado
Una cosa que puede ser de segundo o incluso primer nivel: Hacer un proceso, para todos las facturas enviadas, que compruebe la diferencia de tiempo entre la creacion de la factura y su envio y que muestre aquellos con una diferencia muy grande. Esto inicialmente estará muy bien en la fase de pruebas, para ver que todo funciona como es debido. Despues valdrá al usuario para cuando se produzcan fallos de infraestructura y se envian las facturas con demasiado retardo y probablemente tenga que explicar/justificar a la agencia el motivo de ese retardo

¿ Qué os parece ? ¿ Vamos bien ?
A ver si entre todos vamos dando ideas y hacemos equipo que nos ahorre tiempo final de tecleo y sobre todo muchos dolores de cabeza

[VictorCasajuana]

Rizando el rizo rizado
Una cosa que puede ser de segundo o incluso primer nivel: Hacer un proceso, para todos las facturas enviadas, que compruebe la diferencia de tiempo entre la creacion de la factura y su envio y que muestre aquellos con una diferencia muy grande. Esto inicialmente estará muy bien en la fase de pruebas, para ver que todo funciona como es debido. Despues valdrá al usuario para cuando se produzcan fallos de infraestructura y se envian las facturas con demasiado retardo y probablemente tenga que explicar/justificar a la agencia el motivo de ese retardo

Mi duda es, que si hay una factura que no se ha enviado por algún motivo, entrará en la cola y hasta que no se envíe, el resto de facturas quedarán a la espera, correcto?

Una buena idea sería que todo xml a enviar, aya a la cola y la cola procese, me refiero a que no haya un envío directo y si no funciona entonces enviarlo a la cola, esto podría provocar errores de secuencia en los envíos.

Por cierto, ya que estamos con el envío de los XML, para evitar errores, vais a chequearlos antes con los XSD correspondientes? esto podría reducir el nº de problemas.

Salud!

[FiveWiDi]

Mi duda es, que si hay una factura que no se ha enviado por algún motivo, entrará en la cola y hasta que no se envíe, el resto de facturas quedarán a la espera, correcto?

Yo así lo haré. No enviaré una factura si su anterior no se ha enviado.
Permitiré que el usuario deje en "Stand By" el 'proceso' Verifactu, pero podrá seguir facturando; cuando vuelva a activar Verifactu se enviarán las facturas por orden, estableciéndose en el momento de la creación del XML el vínculo entre una factura, su anterior y su siguiente.

Una buena idea sería que todo xml a enviar, aya a la cola y la cola procese, me refiero a que no haya un envío directo y si no funciona entonces enviarlo a la cola, esto podría provocar errores de secuencia en los envíos.

No crearé XML si no son para enviarse en ese momento ya sea con 1 o varias facturas a la vez. No le veo sentido y si riesgo a tener XML creados pendientes de enviar, si debo y quiero enviar las facturas por orden.

Por cierto, ya que estamos con el envío de los XML, para evitar errores, vais a chequearlos antes con los XSD correspondientes? esto podría reducir el nº de problemas.

Estaría bien, pero no se como se hace.

[paquitohm]

Hola a todos los Vfactureros,

Mi duda es, que si hay una factura que no se ha enviado por algún motivo, entrará en la cola y hasta que no se envíe, el resto de facturas quedarán a la espera, correcto?

Yo así lo haré. No enviaré una factura si su anterior no se ha enviado.
Permitiré que el usuario deje en "Stand By" el 'proceso' Verifactu, pero podrá seguir facturando; cuando vuelva a activar Verifactu se enviarán las facturas por orden, estableciéndose en el momento de la creación del XML el vínculo entre una factura, su anterior y su siguiente.

Como yo lo veo:
En ticketbai al menos eso no es posible porque en el QR que se imprime va un trozo de la firma del xml. Creo que el xml de Vfactu no se ha de firmar, pero dudo que no incluyan algo en el QR que ligue QR impreso con xml. Es "curioso" como este "detalle" determina tanto la forma en que tenemos que hacer el diseño del software y por eso nos conviene tenerlo bien claro

Una buena idea sería que todo xml a enviar, aya a la cola y la cola procese, me refiero a que no haya un envío directo y si no funciona entonces enviarlo a la cola, esto podría provocar errores de secuencia en los envíos.

No crearé XML si no son para enviarse en ese momento ya sea con 1 o varias facturas a la vez. No le veo sentido y si riesgo a tener XML creados pendientes de enviar, si debo y quiero enviar las facturas por orden.

Por cierto, ya que estamos con el envío de los XML, para evitar errores, vais a chequearlos antes con los XSD correspondientes? esto podría reducir el nº de problemas.

Estaría bien, pero no se como se hace.

Me pareciera a mi que la cola consiste en (pongamos por caso) una .dbf que se va alimentando de facturas impresas y que siempre se envia en modo FIFO
Validacion XML vs XSD: Rafa Carmona lo implementó: https://www.fivetechsoft.com/forums/vie ... hp?t=31745

Salu2

[VictorCasajuana]

Validacion XML vs XSD: Rafa Carmona lo implementó: https://www.fivetechsoft.com/forums/vie ... hp?t=31745
Salu2

Lo he probado, pero con xml y xsd más complejos que el del ejemplo, muestra error.

[FiveWiDi]

Hola a todos los Vfactureros,
Como yo lo veo:
En ticketbai al menos eso no es posible porque en el QR que se imprime va un trozo de la firma del xml. Creo que el xml de Vfactu no se ha de firmar, pero dudo que no incluyan algo en el QR que ligue QR impreso con xml. Es "curioso" como este "detalle" determina tanto la forma en que tenemos que hacer el diseño del software y por eso nos conviene tenerlo bien claro

Yo también lo creía, pero hice una lectura 'rápida' de los datos que lleva el QR y no vi que fuera necesario pasar antes por Verifactu.

Muy bueno eso de "Vfactureros",

Estamos 'pillando' de lo lindo con Verifactu.

[FiveWiDi]

Hola,

He perdido los links de Hacienda Pública Española para consultar información al respecto del desarrollo y requisitos de Verifactu.

No los tendrá alguien a mano?

Muchas gracias,