España: Normativa sancionadora sistemas informáticos

[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,

[VictorCasajuana]

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,

https://www.agenciatributaria.es/AEAT.d ... dores.html
https://www.agenciatributaria.es/AEAT.d ... FACTU.html

de momento, todo en modo Borrador con versiones preliminares 0.x.x toca esperar. Hasta el 1 de noviembre tienen plazo para publicar las versiones operativas y abrir las url de prueba, de lo contrario ya no hay un plazo de 9 meses hasta el 1 de julio de 2025

[FiveWiDi]

Muchas gracias!!!

01/11.... ??

Del 01/11/2024 al 01/07/2025 van 8 meses.
Yo creo que tienen hasta el 01/10.

[VictorCasajuana]

Muchas gracias!!!

01/11.... ??

Del 01/11/2024 al 01/07/2025 van 8 meses.
Yo creo que tienen hasta el 01/10.

encima les daba cancha... pues entonces ya ha empezado la cuenta atrás, quedan 19 días.
tic, tac, tic, tac...

[VictorCasajuana]

https://www.agenciatributaria.es/AEAT.d ... dores.html

según el último post de hacienda, en menos de 12 días han de sacar la documentación

tic, tac, tic, tac ...

[Garbi]

¿Esto quiere decir que ya tenemos que empezar? No tengo ni idea por donde empezar.

https://www.agenciatributaria.es/AEAT.d ... dores.html

26-09-24VERI*FACTU - Apertura de servicios de remisión voluntaria y servicio de cotejo de QR en el entorno de Pruebas Externas (PREPRODUCCIÓN)
Desde hoy, 25 de septiembre de 2024, se ha realizado la apertura de los servicios web de remisión voluntaria para los sistemas VERI*FACTU y el servicio de cotejo de QR para los sistemas VERI*FACTU y no VERI*FACTU en el entorno de Pruebas Externas (PREPRODUCCIÓN).
La URL de acceso a los servicios web de remisión voluntaria puede ser consultada en el enlace a su WSDL, que ha sido actualizado y publicado en el Portal de Desarrolladores, con nombre: SistemaFacturacion.wsdl
Las instrucciones para realizar las llamadas al servicio de cotejo de QR, junto con la posibilidad de probar ejemplos en el entorno de Pruebas Externas, puede ser consultado a través del "Documento de detalle de las especificaciones técnicas del código QR de la factura (v0.4.3)".
Además, se ha actualizado el documento de Descripción de Servicios Web, en consonancia a los _ publicados en el Diseño de registro y Validaciones, en su versión 0.4.0, y en calidad de borrador.
En las futuras semanas, se creará una sección dentro del "Portal de Pruebas Externas", que incluirá un cliente de servicios web y donde se irá publicando el resto de los servicios y formularios del sistema.
Ante cualquier duda/sugerencia y/o falta de corrección sobre la nueva información publicada, se recuerda el buzón de consultas técnicas de VERI*FACTU: verifactu@correo.aeat.es

[paquitohm]

Ya están aquii

[AngelSalom]

Esto va a ser dirvertido