FiveTech Support Forums

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-antifraude-y-veri-factu-a-quien-afecta-e-implicaciones?cst=1

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

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.

Xevi wrote:¿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'.

Xevi wrote: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.

Xevi wrote:...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.

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 wrote: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.desarrolladores/Desarrolladores/_menu_/Documentacion/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_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,

Garbi wrote: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.

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.

Garbi wrote: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 8)

Hola a todos,

Hoy he estado viendo un webminar de SAGE, que tengo algún cliente que tienen su solución, porque como ya os he comentado anteriormente, nosotros nos dedicamos sobre todo a mantenimiento de hardware, y algún que otra aplicación que hemos desarrollado, y me ha llamado la atención que han comentado que el software debe estar certificado por AEAT.

Y ahí es donde viene mi pregunta, ¿Sabéis como se debe hacer ese certificado para los programas de facturación estén legales con la AEAT? NO vale solo que pueden enviar la factura a Veri*Factu sino que también debe estar certificado.
Porque si nos ponemos a desarrollar el envio y después no lo podemos certificar, vamos a perder el tiempo.

Gracias.

Garbi wrote:Hola a todos,

Hoy he estado viendo un webminar de SAGE, que tengo algún cliente que tienen su solución, porque como ya os he comentado anteriormente, nosotros nos dedicamos sobre todo a mantenimiento de hardware, y algún que otra aplicación que hemos desarrollado, y me ha llamado la atención que han comentado que el software debe estar certificado por AEAT.

Y ahí es donde viene mi pregunta, ¿Sabéis como se debe hacer ese certificado para los programas de facturación estén legales con la AEAT? NO vale solo que pueden enviar la factura a Veri*Factu sino que también debe estar certificado.
Porque si nos ponemos a desarrollar el envio y después no lo podemos certificar, vamos a perder el tiempo.

Gracias.

En algunos foros se ha dicho esto de la certificación, pero no he visto ningún documento oficial de la AEAT que lo indique. Si alguien lo encuentra que lo publique por favor.

Respuesta de hacienda:

La certificación del cumplimiento de un Sistema Informático de Facturación se realizará a través de declaraciones responsables incluidas en los SIF

por lo que no hay que preocuparse por esto.

VictorCasajuana wrote:Respuesta de hacienda:

La certificación del cumplimiento de un Sistema Informático de Facturación se realizará a través de declaraciones responsables incluidas en los SIF

por lo que no hay que preocuparse por esto.

Victor podria explicar a que se refiere eso y como se hace.

Garbi wrote:Victor podria explicar a que se refiere eso y como se hace.

En la documentación al respecto de VERIFACTU, no recuerdo que documento, se especifica que datos deben constar en la declaración responsable.

Qué es?
Pues un documento (en un A4 cabe) en donde indicamos que nuestro software cumple con los requisitos para 'ser' VERIFACTU; debe estar fácilmente accesible en nuestro software.

Yo pondré un PDF en la opción del menú 'Acerca'; creo que será suficiente.

Supongo que sirve para dar publicidad (en el 2026 nadie se acordará de este documento), y que el cliente esté tranquilo con el software que ha pagado.

Si tu software no cumple con los requisitos VERIFACTU te van a sancionar independientemente de esa declaración; si además no has redactado y no muestras esa declaración en el software te sancionaran por eso también.

Hola a todos,

Estoy haciendo pruebas de envío del XML a VERIFACTU.

Lo estoy haciendo con curl.exe mediante un bucle a la espera de recibir y grabar la información en un fichero; con 'n' lanzamientos como máximo, cuando detecto el fichero dejo de enviar.

El caso es que siempre debo lanzar el envío 2 veces, a la primera no capturo nada y a la segunda si.

Cómo están haciendo Ustedes el envío de su XML a VERIFACTU?

Yo no tengo conocimiento de como hacerlo mediante código propio y por eso lo hago con esta utilidad externa.

Muchas gracias,

Tengo un problema al generar el hash con el ejemplo que viene en la documentación de la Agencia Tributaria.

Lo hago utilizando todo en una cadena continua de caracteres

FWrite( nMan, Upper( HB_SHA256( "IDEmisorFactura=89890001K&NumSerieFactura=12345678/G33&FechaExpedicionFactura=01-01-2024&TipoFactura=F1&CuotaTotal=12.35&ImporteTotal=123.45&Huella=&FechaHoraHusoGenRegistro=2024-01-01T19:20:30+01:00" )))

Me da el resultado del ejemplo de la AEAT

3C464DAF61ACB827C65FDA19F352A4E3BDC2C640E9E9FC4CC058073F38F12F60

Si utilizo variables

LOCAL aCampo := { "IDEmisorFactura", ;

              "NumSerieFactura", ;

              "FechaExpedicionFactura", ;

              "TipoFactura", ;

              "CuotaTotal", ;

              "ImporteTotal", ;

              "Huella", ;

              "FechaHoraHusoGenRegistro" }

LOCAL aDatos := { "89890001K", "12345678/G33", "01-01-2024", "F1", "12.35", "123.45", "", "20240101T19:20:30+01:00" }

FOR nI := 1 TO 8

IF nI < 8

cCadena += aCampo[ nI ] + Chr( 61 ) + aDatos[ nI ] + Chr( 38 )

Else

cCadena += aCampo[ nI ] + Chr( 61 ) + aDatos[ nI ]

EndIf

NEXT

FWrite( nMan, cCadena )

El resultado en totalmente distinto.

26760D0A3DCA72374C31149DAFF7133729EA2BE897819BAD382B4DA6E82B7E98

No lo entiendo.

Llevo varios días intentándolo de todas las maneras que conozco y no me funciona.

Si algún compañero sabe la razón estaría muy agradecido de que me indicara cómo hacerlo.

Gracias