España: Normativa sancionadora sistemas informáticos

[VictorCasajuana]

Gracias paquito, continuamos avanzando.

Otra duda que tengo con este registro de alta es en los casos que existe un TPV a parte de las facturas de cliente, ya que se crean tickets y Facturas que internamente tienen 2 ficheros diferentes, pero supongo que tendrán que incluirse ambos en el mismo fichero de registro de alta para cumplir el requisito de encadenamiento por emisor. Hice la consulta al principio ( hace más de un año ) a los de hacienda pero la respuesta fue confusa. Tenéis el mismo caso?

[paquitohm]

Gracias paquito, continuamos avanzando.

Otra duda que tengo con este registro de alta es en los casos que existe un TPV a parte de las facturas de cliente, ya que se crean tickets y Facturas que internamente tienen 2 ficheros diferentes, pero supongo que tendrán que incluirse ambos en el mismo fichero de registro de alta para cumplir el requisito de encadenamiento por emisor. Hice la consulta al principio ( hace más de un año ) a los de hacienda pero la respuesta fue confusa. Tenéis el mismo caso?

Lo que yo entiendo, a riesgo de estar equivocado.
Si el TPV no estuviera en el mismo sistema informatico, entenderia que llevara su propia "cola" de encadenamiento.

Si están en el mismo sistema, y parece ser que en el mismo programa, me parece a mi, que aunque el programa lo trate en tablas distintas, forman parte de la misma cola de encadenamiento.

Cuando llegue el momento daré mi experiencia con el tema de las colas de encadenamiento en TB que hasta hace bien poco me ha estado dando problemas... seguramente porque no supe abordarlo bien

[FiveWiDi]

Hola.
Para el registro de alta, vais a crear una tabla específica o utilizaréis la misma tabla que almacena las facturas de venta?
Saludos.

Hola a todos,

Yo he optado por tener las 2 tablas, de datos factura y datos contenido factura (hasta ahora funcionando); y ahora añadiré 3 más:

1-Registros originados por la gestión de las facturas (alta, modificación, anulación, requerimiento, ...).
2-Registros de los envíos de los ficheros XML.
3-Registros de los errores que se produzcan tanto a nivel de envió XML como a nivel de registro (altas,...).

En el momento de la generación y envío del XML se alimentará campos de los registros YA existentes en mi tabla -1-(altas, anul...), y se AÑADIRÁ un registro en mi tabla -2- (XML enviados)
Con la recepción de la respuesta de Hacienda, se alimentará campos de los registros YA existentes en las 2 primeras tablas y AÑADIRÁ registros en la 3ra. tabla (errores).

Una factura puede tener 'n' registros de mi tabla -1-(altas, anul...).
Un registro de mi tabla -1- (altas, anul...) sólo estará relacionado con un registro de la tabla -2- (XML enviados).
Un registro de mi tabla -2- (XML enviados) estará asociado a 'n' registros de mi tabla -1-(altas, anul...).
Un registro de mi tabla -3-(errores) estará relacionado con un registro de mi tabla -1-(altas, anul...) o de mi tabla -2-(XML enviados) -->>(1)

(1) Hay errores a nivel de envío o a nivel de registro. Creo que NO hay errores que se puedan asociar tanto al envío (XML) como con un registro de alta (por ejemplo).

En la respuesta de Hacienda al envío del XML, los datos se asocian a los registros de mi tabla -1-(altas, anul...) según el CÓDIGO de FACTURA que se ha enviado a Hacienda en el XML, y que se recibe en el XML de respuesta de hacienda. Y, como la respuesta de hacienda la capturo en un fichero al que le doy nombre yo, el nombre del fichero me permite identificar el registro de mi tabla -2-(XML enviados); conociendo el CÓDIGO de FACTURA y el registro del XML enviado, localizo con exactitud el registro de mi tabla -1-(altas, anul...), y así poder indicar el resultado para este registro concreto según Hacienda.

Las tablas 'actuales' de datos factura y contenido factura no debo modificarlas; el campo código factura (que ya tienen, y que utiliza hacienda en su respuesta XML) será el vínculo con los registros de mi tabla -1-(altas, anul...).

Seguimos.

[FiveWiDi]

Sería esta tabla la que tendría que enviarse en orden de fecha y hora cada NN segundos

Mi intención es ser escrupuloso en el envío cronológico de los registros.

Iré registro a registro desde el más antiguo no gestionado en adelante. Si encuentro un registro de anulación entre los de alta, será tratado como tal en el mismo XML, si se diese el caso (creo que no puede darse si trabajo en Verifactu) de encontrar un registro provocado por un requerimiento, cerraré el XML en curso, lo enviaré y empezaré un nuevo XML para este registro 'requerimiento', y viceversa, si estoy en 'modo' requerimiento y encuentro una alta, cierro XML, envío XML y empiezo XML para esa alta.

Seguimos.

[paquitohm]

Lo que va quedando claro


Lo que va quedando claro es que:

• La creacion del .xml es el menor de nuestros problemas
  Que soluciones de terceros sólo sirven para generar el .xml y por tanto de poco nos sirven
  Que nos tenemos que arremangar y transmitir donde fuera menester que esto necesita arremangamiento
  Que si tenemos pequeños programas igual es mejor unificarlo en uno donde si vamos a tener VF desarrollado porque nos puede resultar muy costoso mantener un pequeño programa que no pare de generar incidencias VF

Lo ideal sería:

• Desarrollar un API entre VF y nuestro programa que nos permita aislar VF lo más posible de nuestro código
  Tocar lo menos posible nuestras tablas y por eso que lo maximo posible de VF vaya a tablas nuevas

[FiveWiDi]

Lo que va quedando claro

Lo ideal sería:

• Desarrollar un API entre VF y nuestro programa que nos permita aislar VF lo más posible de nuestro código
  Tocar lo menos posible nuestras tablas y por eso que lo maximo posible de VF vaya a tablas nuevas

Buscando una solución sencilla y pequeña.
Más que crear un API, sería crear un EXE (que haga todo el proceso de VF) que compartirá con la aplicación de facturación una tabla de registros VF (tendrá sus propias tablas pero compartirá la de regsitros VF).

Las tablas de la aplicación de facturación posiblemente no se deban tocar, el número de factura es lo que vincula con la respuesta de Hacienda, y ese valor ya debe existir en las tablas actuales.
Lo mínimo que se debe hacer en las aplicaciones actuales es que al generar una factura, den de alta un "registro VF de alta" para que el sistema VF (independiente del de facturación), haga su tarea.

Cuidado, el modificar facturas.... Cuando se vaya a modificar una factura, si la generación del XML VF ya se ha realizado, lo sencillo es no permitir su modificación ni borrado, crear una factura de abono, que de de alta un "registro VF de anulación", e iniciar el proceso de nueva factura con los datos correctos y seguir con esta última como con cualquier factura nueva.
Esto a grandes pinceladas.

[VictorCasajuana]

yo de momento lo voy a integrar todo dentro del mismo programa ( solo tengo uno ) con una tabla de registro de alta, me han confirmado los técnicos de hacienda que facturas y facturas simplificadas es lo mismo, independientemente como lo gestione yo ( lógico )

Otra cosa que hay que tener en cuenta es que cuando se haga el envío la fecha y hora sea la correcta. Yo he pensado en hacer una consulta a un servidor horario de internet antes de cada conexión para que esté todo correcto. El tema es que si se detecta diferencia horaria grande ( pillería ) parar el envío y avisar o simplemente hacer caso de la hora de internet que será la correcta...

[PAUL SIMM]

Webinar de Fiskaly

Dado el aluvión de consultas y preguntas que nos están llegando desde la publicación de la Orden Ministerial el pasado día 28 de octubre, desde fiskaly hemos decidido organizar una serie de webinars gratuitos para intentar aclarar todas vuestras dudas. No podía menos que invitaros…
¿Sabías que ya ha iniciado el plazo obligatorio para adaptar los software de facturación a la Ley Antifraude y los sistemas Veri*factu? Conoce a fondo la normativa y cómo cumplir con ella con nuestra serie de webinars enfocada en Veri*factu para desarrolladores de software en España.

En este primer webinar aprenderás sobre:

• La Ley Antifraude y los sistemas Veri*factu
• ¿A quiénes afecta?
• Calendario de implementación
• Sanciones por incumplimiento
• ¿Cómo adaptarte sin cambiar tu software?

¿Cuándo?: Miércoles, 13 de noviembre de 2024, 12h (hora Madrid).

Apúntate gratis, aquí.

https://fiskaly.webinargeek.com/ley-ant ... ones?cst=1

No te pierdas esta oportunidad para estar al día con los últimos cambios fiscales y evitar posibles sanciones.

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