Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[Neftali [Germán.Estévez]]

Empezado por ramherfer

No se ni por donde empezar ni por donde cogerlo, no he usado estructuras xml en mi vida. Para no mentir en los archivos SEPA que crea la aplicación para subir las remesas al banco (sin usar la aplicación de cada uno de ellos) y que los creo manualmente linea a linea según la estructura que en su día se presento para tal efecto. No se si para generar el fichero xml, sería de la misma forma. No se como generar el hash, ni de que generarlo (fichero completo o algún contenido del fichero -según he leido de algún nodo completo-) y no se como enviarlo ya que no se si dispongo de la funcionalidad curl, aunque se me paso por la cabeza mientras leia utilizar algún enlace php con la aplicación de escritorio.

Sigo pensando que la cosa está muy verde para "liarse a fondo" con esto.
Aquí tienes "toda" la documentación que han publicado, que es poca (muy poca):
https://www.agenciatributaria.es/AEA...ERI_FACTU.html

Si quieres empezar con los XML (que yo no los haría manualmente) puedes buscar hilos en los foros que encontrará muchos.
https://www.clubdelphi.com/foros/showthread.php?t=93774

Y fuera también:
https://delphiallimite.blogspot.com/...entos-xml.html
https://delphiallimite.blogspot.com/...os-xml-ii.html
https://delphiallimite.blogspot.com/...xml-y-iii.html

El código para generar un XML es sencillo, como muestra el siguiente:

Código Delphi [-]
uses
  XML.XMLDoc, XML.XMLIntf;

procedure TForm3.Button1Click(Sender: TObject);
var
  node, nodeObli:IXMLNode;
begin
  var XmlDoc:TXMLDocument := TXMLDocument.Create(nil);
  XmlDoc.Active:=True;
  XmlDoc.Version:='1.0';
  XMLDoc.Encoding:='utf-8';

  node := XmlDoc.AddChild('Cabecera');
  node.AddChild('IDVersion', '1.0');
  nodeObli := node.AddChild('ObligadoEmision');

  nodeObli.AddChild('NombreRazon', 'Razón social');
  nodeObli.AddChild('NIF', '12345678N');
  nodeObli.AddChild('NombreRazonRepresentante', 'Mi Representante');
  nodeObli.AddChild('NIFRepresentante', '87654321A');

  XMLDoc.SaveToFile('r:\fichero.xml')
end;

En este documento (al final) tienes acceso a los fichros XSD y WSDL que hay hasta ahora:
https://www.agenciatributaria.es/sta...ervicioWeb.pdf

Otra opción es importar el XSD.
Desde las versiones nuevas puedes importar el XSD con: File->New->other y seleccionar xml data binding
No recuerdo si en esa versión tienes esta opción.

AÑADO: Por lo que veo aquí, sí tienes esa opción.


Revisa esto:
https://delphiallimite.blogspot.com/...xml-y-iii.html

[ermendalenda]

Yo creo que no hay que esperar, nos han dado unampriemra versión que seguro que hacen algún cambio, pero ya os digo que solo el.plantear el software para todo esto se tarda meses, pero claro si ya lo tienes preparado para tixketbai es otro cantar.
Que falta:
Que detallen el webservice del servicio Rest/soap donde se envian los datos.
Hecho de menos alguna doctrina por ejemplo, ue especifique que cuando el comercio se quede sin luz, si podemos temporalmente emitir un documento alternativo en papel, igual que ticketbai.
Casos dwl uso del nodo de incidencia.
Que pasa si hay una rotura del encadenamiento y no nos damos cuenta, que requerimientos podemos tener.

Por otro lado dejéis también curraros una aplicación para generar los xmls apartir de una ultima factura y/poder ingresar manualmente el último encadenamiento que se ha enviado(por por ejemplo una rotura de disco, un virus...), ya que seguro tendremos acceso a través de la aeat a esos datos o a una copia propia.
Por ultimo, me gusta destacar que, hay un aspecto técnico sobre el envío, en las especificaciones dicen que ellos te dirán cuanto y/o cuando enviar el próximo lote de factura/s.eso es que tu enviS la primera factura y ellos en la contestación te dicen que el próximo envío lo podrás tealjzar dentro de X segundos/minutos o un mínimo de x facturas, xon lo fual si intentais el envío en otras ciscunstancias os dará algún tipo de error.

[ermendalenda]

Mensaje erroneo.No procede

[ermendalenda]

Hola, ya tengo resuelta la duda sobre el tema de encadenamiento de las anulaciones, que es diferente a ticketbai ya que en ticketbai no se encadenamiento la anulacion.
Planteada la duda al servicio dedudas de verifactu de la aeat :
*Se emite la factura 1
*Se emite la factura 2 (encadenanda con hash, fecha y número de la factura 1)
*Se anula la factura 1 (encadenanda con hash, fecha y número de la factura 2)
*
*La duda está relacionada con cómo se encadena la siguiente factura. ¿Cuál de los siguientes casos sería el correcto al emitir la factura 3?
** *a) Se encadena con hash de anulación y datos factura número 2 (fecha y numero)
*** b) Se encadena con hash de anulación y fecha de la anulacion y número de la factura anulada (que coincide con el de la factura 1)
*** c) Se encadena con hash de factura numero 2 y fecha y número factura nunero 2.
*** d) La anulación no se encadena tal y como pasa con Ticketbai.

Me responden

Buenos días:

Conforme a la secuencia planteada, «más o menos» la opción correcta sería la b).

Creemos que es más sencillo plantearse el encadenamiento teniendo en cuenta el IDFactura completo. El IDFactura se compone de:


Y el bloque de encadenamiento:




El encadenamiento sigue el orden secuencial cronológico de la generación de registros de facturación (tanto de alta como de anulación), por lo que cualquier registro nuevo tiene que ir encadenado al registro de facturación inmediatamente anterior. Eso quiere decir que el bloque "EncadenamientoFacturaAnterior" se rellenará con los datos del bloque "IDFactura" del registro de facturación anterior.

[[newtron]]

Me hace gracia eso de "más o menos". Cuando llegue el inspector de turno a sancionarme por lo que sea le diré...Señor inspector esto está "más o menos" bien.

Gracias de nuevo por tu info compañero.

[ermendalenda]

Empezado por newtron

Me hace gracia eso de "más o menos". Cuando llegue el inspector de turno a sancionarme por lo que sea le diré...Señor inspector esto está "más o menos" bien.

Gracias de nuevo por tu info compañero.

Bueno. Realmente es correcto el mss o menos, ya que la b) no era del todo correcta, ya que la fecha de emisión es la de la factura 1.
Pero es verdad que ea 7na respuesta un pelin rara

[ermendalenda]

Aquí os dejo parte de la ayuda, más detallada, que me dió la aeat sobre el encadenamiento de verifactu.

Creemos que es más sencillo plantearse el encadenamiento teniendo en cuenta el IDFactura completo. El IDFactura se compone de:



Y el bloque de encadenamiento:




El encadenamiento sigue el orden secuencial cronológico de la generación de registros de facturación (tanto de alta como de anulación), por lo que cualquier registro nuevo tiene que ir encadenado al registro de facturación inmediatamente anterior. Eso quiere decir que el bloque "EncadenamientoFacturaAnterior" se rellenará con los datos del bloque "IDFactura" del registro de facturación anterior.





En la secuencia planteada, se usarán 2 veces la Id factura1 para el encadenamiento, pero irá acompañado de distinta huella/hash.
La primera vez tendrá la huella del registro de alta de la factura1 y la segunda vez tendrá la huella del registro de anulación de la factura1.
Pero en ambos casos será la misma IDFactura.
:

También nos gustaría saber si hay alguna novedad en el reglamento, por ejemplo si hay alguna nueva versión para generar los ficheros xmls o si se esperan más cambios en las estructuras de los ficheros xmls que se describen en el reglamento.

En cuanto a otras novedades en el reglamento, por el momento no hay nada. El Proyecto de Real Decreto xx/2022 continúa en tramitación. No tenemos información de fechas estimadas. Sigue sin haber entorno de pruebas disponible ni está toda la documentación técnica necesaria, todo está pendiente de la publicación de la normativa.

[Neftali [Germán.Estévez]]

Empezado por newtron

Me hace gracia eso de "más o menos". Cuando llegue el inspector de turno a sancionarme por lo que sea le diré...Señor inspector esto está "más o menos" bien.

A mi también se me han ido los ojos justo hacia ese punto....