Hola buenas noches.
Alguno a probado a construir el xml desde el xsd con el XML Data Binding de Delphi
Yo no consigo pasar de rellenar la cabecera, el resto de datos como si no existieran.
No se si estoy haciendo algo mal o es una cagada integra e integral en el xsd de la AEAT.
Si alguien me puede decir algo al respecto, se lo agradecería.

pRIMER INTENTO ALTA FACTURA
 

este primer intento es siguiendo un poco el ejemplo del pdf, pero sin meter el soap, a ver si encontrais los fallos please.

¿Qué fallos tenemos que encontrar?.
Yo a simple vista, lo he copiado/pegado en un visor de xlm para ver un poco más "pretty" y aparentemente está ok, con su cabecera y todo que es lo que al menos a mi me trae loco.

A mi pasó en su momento. Si lo intento hacer utilizado el xsd me pasa lo que a tí, y si lo intento hacer utilizando el xsdl, entonces tengo acceso a los registros de facturación, pero no a la cabecera.

Puedes retroceder un poco para atrás y verás lo que fui posteando.

Yo creo que si que han debido de meter la pata en algo, pero como soy muy novato en estos temas, tampoco me atrevo ni se donde poder hacer consultas más técnicas.

A mi me despista esto del xsd:

Edito.
ok ok nada. eso son nodos a insertar cuando esten empaquetados en el soap

Pues a mi por ejemplo la Huella no me cuadra con la obtenida con varias herramientas online.
Tampoco entiendo (no estoy muy puesto en el tema) motivo por el cual añades las etiquetas sum1 y esto que comentas de meter el soap :confused:
Si que rogaría y teniendo en cuenta que puede haber gente muy puesta y otra menos puesta como puede ser mi caso hacer los textos mas entendibles a los que no estamos tan puestos y tenemos el problemón encima. Espero que nadie se ofenda por lo que digo, lo hago con la mejor intención del mundo.

Si, si, la huella no es esa, es que he cambiado el contenido pero no la huella, por no dejar datos reales.

las etiquetas sum y sum1 son prefijos que se refieren a un enlace, esos prefijos puedes decidir tú como se llaman pero tienen que estar igual en los sitios a los que hacen la mis ma referencia.

El soap:
cada fichero verifcatu se refiere a un alta o anulacion, pero para el envio, tienes que meter (*n) archivos en un solo fichero con los nodos del soap.

*n=numero de archivos verifactu, este numero está condicionado por las respuestas que te de la aeat en cada envio, te pueden decir cuantos (n) tienes que mandar o cuanto tiempo tienes que esperar para el siguiente envio (Maximo 1000 registros o archivos verifactu).
Espero que te aclare un poco, sé que es un poco lioso.

Yo me voy algo antes. ¿Alguien me puede aclarar de qué va el rollo de la huella y cómo se genera?


Gracias y un saludo.

es el calculo del hash sobre un texto, este hash puede ser sha256, sha512...., pero en este caso solo tienen la opción sha256, la mayoria de programas de desarrollo tienen herramientas para crear esa secuencia de cálculo sha256, (texto a sha256), y si no podeis usar las apis de windows (para los que usan windows). Hay que tener especial cuidado que este cálculo es muy, perro que muy sensible a cualquier caracter del texto, un retorno de carro, un caracter especial, nulo, tabulador... te cambia el calculo totalmente, por eso en las pruebas que hagais debeis verificar que estais haciendolo bien, y el mismo formato que le deis al texto enviado debe ser el mismo que con el que habeis calculado el hash.
Por otro lado, ese calculo del hash puede estar devuelto en sistemas distintos, pero el más frecuente es el hexadecimal, que tambien teneis que tenerlo en cuenta. Cualquier texto va a devolver una sha256 del mismo tamaño (mismo número de caracteres), por muy pequeño o grande que sea el texto.
Para calcular la huella del verifactu teneis que calcularla sobre el nodo [RegistroFacturacion] incluyendo las eiquetas de apertura y cierre, aquí es donde podeis tener la duda si después de la etiqueta de cierre hay retorno de carro hay que incluirla para el calculo o no, y aunque la normativa dice que el nodo incluyen los retornos de carro posteriores, no sabemos si van a aplicar la normativa, os aconsejo que despues de la etiqueta de cierre no hagaios saltos de lineas ni retornos de carro.
Saludos

Gracias compañero.


Entiendo entonces que hay que generar un fichero XML por cada factura que se va a enviar y calcular unitariamente ese hash para meterlo posteriormente en la llamada que se hace para cada factura.


A ver si algún colega que use Delphi puede mostrarnos alguna función/ejemplo.


Saludos.

correcto, cada alta o anulacion con su hash, y en el paquete de envio todos los ficheros xml con su huella.

Perfecto, gracias.


Haciendo una búsqueda "tontuna" he encontrado este link con una función simple para generar el hash SHA-256. Imagino que servirá.


Saludos.

Un hash se puede calcular con muchas herramientas, editores, etc. pero lo único "vital" es asegurarse de que se hace sobre el texto correcto, siempre igual.
Por ejemplo, si el texto está en ascii o utf-8 serán distintos, ¡¡¡aunque lo veamos igual!!! y también, como han dicho antes, cuidado con los fin de línea, retornos de carro, etc. que es distinto si se ha generado en windows o si está calculado en un servidor linux.

hay webs para comprobar tambien, como metoido adicional mientras programas, pero cuidado con los cortar y pegar que cambian caracteres en los cuadros de introduccion del texto de la web.

Toda la parte que está en rojo (NombreRazon hasta NIF) está repetida del principio y no está bien formado.
Luego la parte en azul, etiquetas NombreRazonEmisor y TipoRegistroSIF deben venir antes de TipoFactura, y las etiquetas TipoFactura y DescripcionOperacion repetidas después deben quitarse.

(He añadido CR para leerlo mejor en pantalla)
IdSistemaInformatico está limitado a dos caracteres, tu ejemplo tiene 19...
Además, falta justo antes un elemento NombreSistemaInformatico que no es opcional.
Si se reemplaza por me da OK

La fecha debe ir con guiones, las barras no validan el XSD

Gracias
Repaso todo
Al cambiarlo de la 0.1 a la 1.0 l he liado

Si por "ascii" te refieres a US-ASCII en sentido restringido a los caracteres imprimibles más eventualmente CR y LF pues no, no serán distintos :o
Pero cualquier tilde o eñe sí creará problemas.

Mensaje de error al importar wsdl en Delphi X2
 

Cuando lo intenté con el la versión 10.3 no me dio error, sin embargo, con esta versión más antigua me da esos errores durante la importación.

Quizás por eso no está haciendo la importación correcta y le faltan "partes". ¿Podrá ser?

Pero en hacienda pueden comprobar si el hash es correcto?
Basta con cojan el nodo y hagan el hash o tendrán que saber la codoficacion usada?

No tienen que saber codificación, el hash siempre es el mismo para una cadena, da igual quien, donde y desde que programa se calcule.
Pueden calcularlo y es su forma de verificar que no hay trampa.
Ver significado funcionmiento del blockchain, por ejemplo para las criptomoneda, aunque estas tienen además otros algoritmos tienen aplicado los cálculos de hash.

¿Cuando te refieres a "versión más antigua" te refieres a la versión del Delphi que estás usando?


Saludos

He probado con 3 versiones diferentes:
- Delphi 2007: Me da error de empty document (que creo que es el mismo mensaje que te salía a ti o algún otro compañero en este mismo hilo)
- Delphi 10.3: No da error en la importación, pero el elemento "Cabecera" no lo encuentro por ninguna parte, con lo cual no puedo formar el XML "completo".
- Delphi X2: Que lo acabo de instalar para probar a ver que pasaba, y con esta versión, no me da el de Empty Document, pero me da ese otro error del que he pegado pantallazo y que sino me confundo, se corresponde a algo que ya había comentando yo antes. Y es que en la estructura del wsdl, hay vínculos a páginas que realmente no existen.

Ok pues imagino que tendrás que usar la 10.3. Lo que me tiene despistado es que para generar la cabecera hay que hacerlo importando el fichero .xsd según comentaba Neftalí usando XML Data Binding. El problema es que por ahí puedes generar la cabecera y por el wsdl cada registro de factura pero no se me ocurre cómo juntar todo eso en una llamada para que genere un XML con las dos cosas. Se me ha ocurrido que habrá alguna llamada desde la cabecera para "pegarle" las facturas pero no encuentro la forma.


Saludos.

Edito: ¿Podrías poner un ejemplo de creación de una factura? Porque también estoy haciendo pruebas y no consigo meter el desglose.

El "problema" es que en mi caso, la programación "importante" la tengo con librerías que en el 10.3 no me compilan. Por eso mi interés en poder hacerlo con el D2007.

La otra opción serán crearlo a mano como en su momento hice para el SII.

Yo tengo el mismo problema que tú. Se generar la cabecera por un lado y los registros de facturación por otro. Lo que no sé es unirlos y meterlos a la llamada SOAP...

Intento rebuscar lo que hice para generar los registros de facturación, lo que tengo que mirar es si me coinciden correctamente con los que ha puesto un poco más arriba @ermendalenda .

Por otro lado, el visto el post que pusiste indicando un método de hacer el hash, pero por lo que veo tampoco es compatible ni con el 2007, ni con el XE2. Tendré que mirar que al menos lo sea con el 10.3.

Seguimos aprobando
 

http://www.hacienda.gob.es/Documenta...-1007-2023.pdf
http://www.hacienda.gob.es/Documenta...-1007-2023.pdf
http://www.hacienda.gob.es/Documenta...-1007-2023.pdf
No puedo copiar los enlaces del boe
Pero hay 3, en estado de consultas sobre la tramitacion .

Compañero yo puse un codigo para calcular el hash de RegistroFacturacion metido en una librería de enlace dinámico (dll)
No se si está en la página 37 o 38 y me funciona está creada con delphi 10.2 y la llamo desde delphi 7 me crea el hash 256 que he comprobado en algunas web's y está perfecto.

Aqui está el código de la librería:

Ejemplo de llamada:

Enlaces
 

http://www.hacienda.gob.es/Documenta...-1007-2023.pdf

http://www.hacienda.gob.es/Documenta...-1007-2023.pdf

http://www.hacienda.gob.es/Documenta...-1007-2023.pdf


Ejemplo de contenido de estos documentos del boe sobre los SIF (Verifactu):

El código «QR» deberá tener un tamaño entre 30x30 y 40x40 milímetros y seguir las especificaciones de la norma ISO/I
EC 18004. Para la generación del código «QR» se
empleará el nivel M (medio) de corrección de errores, lo que ofrece un 15% de recuperación
de caracteres.
2. El contenido del código «QR» será el siguiente:
a) «URL» del servicio de cotejo o remisión de información por parte del receptor de la
factura, del cual se informará en la Sede electrónica de la Agencia Estatal de
Administración Tributaria.(pendiente de que la publiquen)

b) Información de la factura que formará parte de la «URL»:
1.ºNIF del obligado a expedir la factura

2.º Número de serie y número de la factura expedida
3.º Fecha de expedición de la factura
4.º Importe total de la factura

Hola VERIFACTU EN VISUAL BASIC
 

Hola buenas tardes, alguien sabe si hay algún foro sobre la normativa VERIFACTU para programadores en Visual Basic. Gracias

Buenas tardes.
Este es para todo,
Yo estoy en Visual Basic.

Mas cositas de la norma
 

Algunas particularidades de la norma, aunque está en periodo de consulta hasta el día 24 del presente mes:

- Gestion de certificados electronicvos. Los certificados electrónicos serán utilizados para autenticarse en la conexión con la Agencia Estatal de Administración Tributaria de cara a la remisión de la información y, en su caso, para generarla firma electrónica de los registros de facturación.-Antes de la generación de un nuevo registro habrá que comprobar si los 5 últimos registros estan correctamente encadenados.
-Si hay problemas con el envio debe reintentarse como máximo en una hora.
-Mostrar una alarma, clara y visible en todos los equipos del sistema informatico SIF, si hay alguna particularidad que impide generar correctamente los registros y generar el registro de eventos en ese caso.
-La fecha y hora empleada en los sistemas informaticos, deben ser exactos, con un maximo de un margen de 1 minuto.
- Tener comprobaciones de registros generados: comprobacion de la huella hash, y que te permitan ir a partir de un registro al anterior o posterior.
- El formato de los xml será en codificación UTF8




-Se deben crear estos eventos:
* Instalacion o puesta en marcha
* Inicio como verifactu
* Fin verifactu
* un evento por hora si no hay registros.¿¿??
y los demas eventos de los sistemas que no vayan a enviar verifactu



Esto tendran que aclararlo un pelin más:
"Para un determinado obligado tributario, el sistema informático producirá una única cadena de registros de facturación, es decir, todos los registros de facturación generados por un mismo sistema informático deberán formar parte de la misma cadena. Si hay varios terminales o dispositivos de facturación pertenecientes al mismo sistema informático, todos ellos deberán generar registros que se integrarán en la única cadena existente para dicho sistema informático"


La generación de la huella o «hash» de los registros de facturación se realizará conforme a las siguientes directrices:
a)La información a la que se realizará la huella o «hash» será el fichero XML del registro de facturación.
b)Se usarán el algoritmo y codificación indicados en el documento técnico que se publicará la Sede electrónica de la Agencia Estatal de Administración Tributaria.



Etc etc etc...
Vaya dolor de cabeza

Gracias por la info compañero.

¿Donde se deben crear o registrar estos eventos compañero?

Buenas
en el pdf de las especificaciones que colgó hacienda creo recordar que venia el formato, aunque hasta que no lo aprueben totalmente no quiero mirarlo.
En resumen tendras que crear un xml de los eventos.

os adjunto ejemplo factura simplificada pdf, ya que va a ser obligatorio generar un pdf (no se si es obligatorio generarlo o tener la posiblidad)

La mayoria del qr es de prueba, aun no se sabe la url, ni el formato, ni si lleva un CR de control, aunque las medidas sí son correctas

Adjunto xml de prueba del pdf anterior. Gracias antonie0 creo que ya está subsanado lo que me dijiste

CODIGO vb 6.0 de ejemplo
 

Buenos días podrías mandar un código de ejemplo de como generar el xml en vb 6.0. Muchas gracias

Son simples output a un fichero.

Tienes que esperar un poco para los detalles.

Hay dos partes a las especificaciones de interfaz: una para Veri*factu y la otra para aplicaciones «que reportan a Hacienda bajo requerimiento». Evidentemente estas dos partes comparten mucho. Diferencias entre las dos partes incluyen:

• un punto de contacto distinto
• indicar el número de requerimiento (en lugar de la fecha final en modo Veri*factu)
• tener cada registro firmado individualmente
• tener un libro de eventos
• y poco más

De momento lo único publicado con explicaciones es la interfaz con los sistemas Veri*factu. Faltan dos piezas importantes:

1. la orden ministerial, que explicará cosas como la forma de los QR, la descripción de los eventos, las marcas de tiempo, la manera de normalizar los nodos XML para calcular las huellas, o el contenido que se firme
2. la otra interfaz, para los requerimientos

Sin embargo, estamos lo suficientemente listos como para mirar en los documentos que se nos han facilitado; y allá hemos encontrado la especificación (en versión 0.3) de los eventos, tal como deben ser enviados bajo requerimiento.

Entonces, para contestar a tu pregunta, y sin ninguna garantía de nadie, solo bajo deducción: los eventos se deben registrar en una lista encadenada similar y paralela a la de las facturas.

Es antoine0 :) No eres el primero con esta ortografía. ;)

Ahora hay un nodo "sum1:PeriodoImputacion" que no sé de dónde viene pero no lo acepta el validador de esquema XML...

Siento el error.
Cierto
El periodo de imputación lo he visto en el esquema xsd pero no en el ejemplo.
Lo tengo marcado para quitarlo o dejarlo
Viene solo en la definición de complextipe name. Puede que lo hayan quitado del nodo adrede o se les ha olvidado.como estaba en la versión 0.1 dd momento lo dejo