FiveTech Support Forums

Un buen resumen por parte de la agencia tributaria, con una pincelada final a la SPFE.

https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/Reuniones/2024/Present-VeriFactu-SeminarioEEDD-DDII.pdf

Hola a todos,

En este hilo he dejado un resumen a mi manera de la orden ministerial:

https://www.fivetechsupport.com/forums/viewtopic.php?f=19&t=45082&sid=8a281ec9e5b438ba9ae20f352c387ecb#p275353

Me ha ido muy bien leerla, me ha aclarado aspectos.

He abierto ese hilo por que quería tener un hilo en donde se comentaran criterios a aplicar en el desarrollo para VERI*FACTU, no su parte técnica.

Ya me dicen.

Vaya tela.

Los de Hacienda creo que también van un poco de culo.

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.

De momento Hacienda en DIFERENTES pruebas ha respondido:

Codigo[4102].El XML no cumple el esquema. Falta informar campo obligatorio.: Cabecera</faultstring>

Adaptando como dice la versión 0.4.2 del 28/10/2024 solucionado

Codigo[4112].El titular del certificado debe ser Obligado Emisión, Colaborador Social, Apoderado o Sucesor.</faultstring>

Pués eso, que el certificado del que envía (en mi caso) debe ser la misma persona que el obligado (en mi caso).

Anda!(pienso en voz alta), deberé enviar con la firma digital de apoderado de la S.L., la suya personal entiendo que no valdrá.

Codigo[4104].Error en la cabecera: el valor del campo NIF del bloque ObligadoEmision no está identificado.. NIF:39999930J. NOMBRE_RAZON:La, S.L.</faultstring> (1)

Parece ser que coteja el NIF (en este caso) con el nombre que le consta a Hacienda, no estoy seguro por que he omitido el 2o. apellido y se lo ha comido.

Estos 3 primeros errores evitan que hacienda entre a tratar lo enviado, rechaza todo el envío y no mira los diferentes registros enviados, lo rechaza y punto.

Incorrecto-1100-Valor o tipo incorrecto del campo.: Huella

Error mío, estaba enviando sin la huella del registro anterior.

Incorrecto-1108-El NIF del IDEmisorFactura debe ser el mismo que el NIF del ObligadoEmision.

El NIF del obligado que uso en la cabecera, debe ser el mismo que el que emite las facturas.

Incorrecto-1110-Error en el bloque de IdEmisorFactura.. El NIF no está identificado en el censo de la AEAT.. NIF:39999930J. NOMBRE_RAZON:La, S.L..

No estoy seguro, creo que hacia referencia a la identificación de la factura anterior (encadenamiento).

AceptadoConErrores-->>2004-El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos.

Pués eso, que le estaba indicando fecha y hora del mes de octubre (son registros que tenía de pruebas). Pero me ha respondido el CSV !!!!!! Oleeeeee!!!!!

Incorrecto-->>3000-Registro de facturación duplicado.

Bueno, es que estoy probando siempre con el mismo registro.

Y además en esta misma respuesta:

AceptadaConErrores-->>2004-El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de:" (no, no indica valor después de ':')

Bueno por hoy tengo bastante.

Seguimos.

Hola Garbi,

Garbi wrote:

Code (fw): Select all Collapse

curl.exe -k --connect-timeout 60 -m 300 -s -S -L --header "Content-Type: text/xml;charset=UTF-8" --cert empresa.pem --key empresa_key.pem  --data @11.xml https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP --output respuesta.xml -v

Muy importante poner la @ delante del fichero a enviar.

Estoy teniendo algun 'problemilla', en algunos envíos no obtengo respuesta, si lo vuelvo a intentar entonces si.
De buenas a primeras se me ocurre comprobar la existencia de "respuesta.xml", si no existe vuelvo a enviar.

Muchas gracias Garbi.

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.

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

Se hace necesaria, creo yo, una tabla hija de la tabla de facturas.
¿ Por qué ? Porque de una misma factura se puede hacer varios envios: Alta, Alta-subsanación, Anulacion.

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

Para TBai utilizo esta con la siguiente estructura. En realidad para el SII lo tengo exactamente igual. Algunos de los campos sólo son para debug:

paquitohm wrote:

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.

Se hace necesaria, creo yo, una tabla hija de la tabla de facturas.
¿ Por qué ? Porque de una misma factura se puede hacer varios envios: Alta, Alta-subsanación, Anulacion.

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

Para TBai utilizo esta con la siguiente estructura. En realidad para el SII lo tengo exactamente igual. Algunos de los campos sólo son para debug:

ok, y en esa tabla, vas a meter todos los datos del registro de alta? me refiero a los que se envían en el xml, porque leyendo la OM, no veo que defina exactamente la estructura de esta tabla.

ok, y en esa tabla, vas a meter todos los datos del registro de alta? me refiero a los que se envían en el xml, porque leyendo la OM, no veo que defina exactamente la estructura de esta tabla.

No. Sólo los más significativos como huella, CSV, etc.
Si tuviera que rescatar algun dato que no tuviera en la tabla VFEnvio, podría cogerlo del .xml del que si guardo la ruta

Esto, evidentemente, es sólo mi intención de diseño.

Por otra parte, esta tabla tendrá un doble uso, porque también recogerá aquellos campos con datos de la respuesta que sea conveniente almacenar despues de hacerle el parser al xml-respuesta

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?

VictorCasajuana wrote: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

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

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

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

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

yo de momento lo voy a integrar todo dentro del mismo programa ( solo tengo uno :roll: ) 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...