España: Normativa sancionadora sistemas informáticos

[Xevi]

Llevo ya este año de quebraderos de cabeza... finalmente, con la OM ya publicada, no hay más que ya si o SI ponerse manos a la obra a quien quiera seguir haciendo aplicaciones enteras, hasta el resultado de la factura final.

Creo que tengo TODO funcionando, para registros de Alta, guardando el XML que envio y el de respuesta, de momento con resultados muy satisfactorios por mi parte. Tema de huella, QR, XML, envio al WS, guardar en tabla datos enviados y respuesta...
Solamente tengo una inquietud, de momento, y no veo luz en como abordarla. Pues cuando genero en bloque (dias 15 o 30 de cada mes) 20 o 30 facturas, no puedo enviar registro a registro para poder guardar cada registro con su respuesta... así pues debería de enviar en bloque, sinó, esperar un retardo de 60segundos mínimo entere factura y factura. Esto no es viable.

¿Como lo abordais vosotros, o teneis pensado solucionarlo???
En cada registro guardar TODO el XML de las 20 o 30 facturas enviadas y la correspondiente respuesta de los 20 o 30 registros???
No se si "esmenuzar" el contenido de la respuesta, pues si en esos 30 registros hay uno o mas de no correctos, puedo formar un follón, ¿no???

Y otra duda que me inquieta es la RESPONSABILIDAD que tendría como programador. Mi aplicación con mandar los registros y guardar el estado/respuesta, y no dejar tocar nada ya enviado, ¿estaría cumpliendo con VERIFACTU??? yo entiendo que si... y como hacienda va a crear un portal (como en el SII) y va a ser otro SIF distinto, pues desde ahí se podrían "arreglar" lo que mi aplicación no abarque... ¿no??? otro SIF distinto, otro encadenamiento y listo el pollo!!!

No se, muchas noches dandole vueltas a si me compena seguir estos 5 añitos que me quedan y meterme con VERIFACTU o les planteo a mis clientes que se acojan al SII, que lo tengo implementado de hace ya unos 5 años, y me quito ese quebradero de cabeza y responsabilidades.

[FiveWiDi]

¿Como lo abordais vosotros, o teneis pensado solucionarlo???
En cada registro guardar TODO el XML de las 20 o 30 facturas enviadas y la correspondiente respuesta de los 20 o 30 registros???
No se si "esmenuzar" el contenido de la respuesta, pues si en esos 30 registros hay uno o mas de no correctos, puedo formar un follón, ¿no???

Yo también guardo el XML enviado y el recibido de respuesta.

He "esmenuzado" la respuesta y lo gestiono todo en 3 DBF relacionadas entre si:

a) Registros de alta/anulación VERIFACTU
b) Datos del envió del XML
c) Errores recibidos de VERIFACTU.

Llevo todo el fin de semana en ello haciendo pruebas unitarias, lo voy depurando y parece que funciona.
He empezado a empaquetarlo en una única función y también funciona.

Y MENOS MAL del control de los bucles. Tengo el envió en un bucle por si tarda la respuesta.
Pues bien, les debo haber cogido a los de Hacienda 'tocando' algo, he recibido el error:
<faultcode>env:Server</faultcode><faultstring>Conexión a DB2 no disponible.</faultstring></env:Fault>
y en algunos reintentos (el bucle) no obtenía respuesta y se quedaba 'pillado'.
Este error no lo he visto documentado.


En cuando al envió, yo tengo el mismo caso que tu, 25 facturas a final de mes.
Pues bien, cuando lanzo el proceso de facturación, primero desactivo un 'semáforo' para que el proceso VERIFACTU no se lance, cuando acabo de facturar activo el 'semáforo'.

Y otra duda que me inquieta es la RESPONSABILIDAD que tendría como programador. Mi aplicación con mandar los registros y guardar el estado/respuesta, y no dejar tocar nada ya enviado, ¿estaría cumpliendo con VERIFACTU??? yo entiendo que si...

Yo creo que también.
Posteriormente cuando esté rodado el nuevo desarrollo, dejaré tocar las facturas y según que sea daré de alta nuevos 'registros de alta/anulación', y vuelta a empezar. Pero eso por ahora sólo es una idea.

...y como hacienda va a crear un portal (como en el SII) y va a ser otro SIF distinto, pues desde ahí se podrían "arreglar" lo que mi aplicación no abarque... ¿no??? otro SIF distinto, otro encadenamiento y listo el pollo!!!

No lo he estudiado. Si permite indicar para esas facturas una serie distinta a las de tu aplicación, entiendo que si.

[Garbi]

Hola a todos.

No he podido conectarme desde el fatídico día 29, soy afectado de la DANA. Personalmente todos bien, materialmente bueno ya veremos como queda el tema.

Hoy es el primer día que trabajo.

Yo me quede en que habían cambiado la estructura del fichero XML por lo que puso Victor puesto que me daba error el envio del xml.

Como puedo saber cual es la estructura correcta y continuar para empezar a implementar.

Paquito, ya tienes la estructura completa del xml para sustituir los datos necesarios para poder empezar a hacer pruebas.

Agradecería cualquier ayuda que me pudieras sugerir.

Un saludo.

[FiveWiDi]

No he podido conectarme desde el fatídico día 29, soy afectado de la DANA. Personalmente todos bien, materialmente bueno ya veremos como queda el tema.
Yo me quede en que habían cambiado la estructura del fichero XML por lo que puso Victor puesto que me daba error el envio del xml.

Hola Garbi,

Antes de nada, siento mucho lo ocurrido, un familiar ha ido a la zona, no tenía palabras para describirlo, literalmente me dijo "De los que están en planta baja hay gente que está con lo puesto, están sobreviviendo".

Ayer miré en https://www.agenciatributaria.es/AEAT.d ... FACTU.html si había actualizaciones.

Lo último que vi en mis pruebas del 03/11/2011 es:
"El documento "Veri-Factu_Descripcion_SWeb.pdf" aunque en la 1ra. página indica Fecha 18/10/2024 Verisón 0.4.1, realmente/parece ser, es la Versión 0.4.2 Fecha 28/10/2024; de hecho hay páginas con estos valores.
Si se tocan los TAG Cabecera, RegistroAlta y RegistroAnulacion, ya se pueden hacer pruebas. (han modificado el nombre del TAG)"

Tenemos tiempo, si se tiene claro que se debe hacer es un desarrollo más.

Un abrazo,

[VictorCasajuana]

Hola a todos.

No he podido conectarme desde el fatídico día 29, soy afectado de la DANA. Personalmente todos bien, materialmente bueno ya veremos como queda el tema.

Hoy es el primer día que trabajo.

Yo me quede en que habían cambiado la estructura del fichero XML por lo que puso Victor puesto que me daba error el envio del xml.

Como puedo saber cual es la estructura correcta y continuar para empezar a implementar.

Paquito, ya tienes la estructura completa del xml para sustituir los datos necesarios para poder empezar a hacer pruebas.

Agradecería cualquier ayuda que me pudieras sugerir.

Un saludo.

Hola Garbi, mucha fuerza para continuar hacia adelante.

Yo para saber la estructura correcta siempre miro este enlace https://www.agenciatributaria.es/AEAT.desarrolladores/Desarrolladores/_menu_/Documentacion/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU.html
sobre todo documento diseño registro facturación
En el caso de utilizar los xsd, antes de cada prueba bajad la última versión, me volví loco hace días con un dato que no estaba reflejado en los dos documentos y fue culpa mía, ya que la xls del documento diseño registro facturación siempre la miro online y el xsd me lo voy descargando.

[FiveWiDi]

Hola,

Yo uso CURL.EXE para enviar el XML.
Si envío una firma digital que no es del obligado tributario (el emisor de las facturas), reacciona bien, da un mensaje VERIFACTU de error y te enteras.

Pues bien, he convertido con OpenSSL.exe una firma CADUCADA del obligado tributario de .PFX a .PEM
He usado esta firma para enviar el XML, VERIFACTU reacciona MAL, NO te enteras de su respuesta, no tiene la estructura esperada.

En el fichero de respuesta (lo capturo en el CURL.exe), lo que llega lo abro con el browser y se muestra una 'página web' donde indica esto:

"This page contains the following errors:
error on line 10 at column 8: Opening and ending tag mismatch: meta line 8 and head
Below is a rendering of the page up to the first error.
Agencia Tributaria: 401"

Como no se corresponde con la estructura que debería responder VERIFACTU, pues no lo estaba capturando.
Le tendré que meter otro control a lo que llega.

Y así estamos.
Seguimos.

[paquitohm]

Hola a todos.

No he podido conectarme desde el fatídico día 29, soy afectado de la DANA. Personalmente todos bien, materialmente bueno ya veremos como queda el tema.

Hoy es el primer día que trabajo.

Yo me quede en que habían cambiado la estructura del fichero XML por lo que puso Victor puesto que me daba error el envio del xml.

Como puedo saber cual es la estructura correcta y continuar para empezar a implementar.

Paquito, ya tienes la estructura completa del xml para sustituir los datos necesarios para poder empezar a hacer pruebas.

Agradecería cualquier ayuda que me pudieras sugerir.

Un saludo.

Garbi,

Cuanto siento lo que os ha ocurrido a muchos valencianos. Como muchos otros españoles, he estado y estoy al tanto. Ya comenté que tengo algún cliente por la zona. A los políticos no les vale el dineral que les pagamos en impuestos para hacer su trabajo. Quieren más dinero, para eso está Verifactu, para prestarnos cada vez menos ayudas "que la pidan si la necesitan" se atrevió a decir el gran felón.

Te he mandado por email una estructura completa basada en el ultimo xsd y sacada con SOAPUI.

Yo no me preocuparía realmente por el xml, que ya lo has probado, sino por:

1º Sólo por aquellos campos raros que hay que enviar
2º Diseñar la estructura de la aplicacion para envio y recepcion de la respuesta. Yo la llamo API, en el sentido genuino de la palabra (interfaz)
2.1.- Agrupacion de registros de envio
2.2.- Recepcion de la respuesta

Yo por mi parte, como comenta Víctor, sin rascar bola. Sólo leo.
Como dice FiveWidi:

Tenemos tiempo, si se tiene claro que se debe hacer es un desarrollo más.

P.D. No sé qué hay de cierto en el rumor de que lo postpondrán para enero de 2026. Aunque lo hicieran no quita ni una gota la obligación de que los programas estén preparados para 29-7-2025

Veremos