generacion del verifactu y validarlo
 

Hola, lo primero de todo: perdón si este tema ya se ha tratado en el foro o si no estoy usando correctamente el foro.

Estoy intentando trabajar con VERI*FACTU y tengo un par de dudas:

¿Existe algún ejemplo completo de la estructura XML que debe tener el envío?
He visto que debe enviarse un archivo .xml, pero la mayoría de "ejemplos" que encuentro son de gente diciendo que no les funciona. ¿Hay algún ejemplo oficial o funcional que pueda usar como referencia para asegurarme de que la estructura es correcta?

¿Cómo se valida un envío VERI*FACTU?
Por lo que he leído en el foro, ya hay disponible una zona de pruebas, pero parece que hace falta un certificado digital para identificarse, entre otros requisitos.
¿Me podéis decir qué necesito para validar un envío y si hay algún ejemplo del proceso?

Trabajo con Delphi 2005, que sé que ya tiene sus años, y no estoy seguro de si con esta versión voy a poder realizar el envío correctamente al sistema de la AEAT, lo comento por si alguien ha podido probar con esta versión y me puede dar algún consejo.

Yo uso C++ Builder pero para el caso es lo mismo, tengo también una versión muy antigua, anterior a Delphi 5, imagínate :-) lo que hago es generar el XML a pelo en un string, lo guardo en disco y luego lo envío con una llamada a system del curl.
Te adjunto varios XML, de una factura ordinaria, simplificada y rectificativa, así como del comando curl.
Hay mas variaciones, distintos tipos de IVA/IGIC, exentas, rectificativa de una simplificada, envíos masivos, etc. Pero jugando con estos ejemplos los puedes ir viendo, de todas formas, en esta web hay infinidad de ejemplos.
Un saludo.
Factura ordinaria:
Factura simplificada:
Factura rectificativa:
Comando curl:

El compañero seccion_31 ha hecho un espléndido ejemplo de envío/recepción a Verifactu:


https://terawiki.clubdelphi.com/Otro...go-proyectos_/


Funciona en Delphi 7 por lo que no deberías de tener problemas para que te funcione en Delphi 2005.


Saludos.

Muchas gracias a los dos sobre el tema de la estructura he encontrado este documento sede.agenciatributaria.gob.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Veri-Factu_Descripcion_SWeb.pdf algunos campos me coinciden otros no tanto, ¿es aquí donde has sacado la estructura o de otro documento?

unos campos que me parecen raro como se llaman son:
->FacturaSimplificadaArt7273
->FacturaSinIdentifDestinatarioArt61d

supongo que tendrán alguna razón

Aquí tienes el enlace donde está la documentación técnica de Verifactu. Échale un vistazo porque tienes bastante que estudiar.


Saludos.

Una pregunta que a lo mejor es un poco tonta estaba con la huella del sha256 y me he fijado que en el campo 'numSerieFactura' lo separas así: 'Nºserie-Nºfactura' pero en el ejemplo de la documentación pone: NumSerieFactura=12345678/G3,

mi pregunta que debo de usar como separador: ¿'-' o '/'?

Puedes poner el que quieras, como si no quieres poner ninguno.

Pues lo que quieras, incluso no usar separador, por ejemplo 0100001 para la serie 1 y 0200001 para la serie 2, pero siempre usar el mismo formato.

me ha entrado una duda con el encadenamiento, yo estaba usando la misma serie para mis pruebas y todo parecía funcionar, el problema es cuando he cambiado de serie, yo como lo tengo montado el encadenamiento separo las series en los encadenamientos tal que así:

1/25->1/26->1/27...

2/10->2/11...

si intento juntar las series 1/25->2/10 (orden de generación de factura) me da error 'El cálculo de la huella suministrada es incorrecta. Datos de entrada cálculo huella:..'

así que entiendo que la opción correcta es la primera.

pero cuando creo una serie nueva sin estrenar 3/1 me obliga a poner que no es primer resgitro por que si no me da este error: 'No debe informarse como primer registro, existen facturas emitidas con el obligado emisión y el sistema informático actual.' en resumen que tendría que poner
<PrimerRegistro>
N
</PrimerRegistro> ¿pero que debo poner en registro anterior para que no me salte ?

Creo que es un error de planteamiento. El encadenamiento no debe de ir por serie sino por SIF, es decir, todas las facturas que se emitan desde un mismo sistema informático, ya sea monopuesto, red, con distintas series, etc. debe de ir encadenado de forma conjunta.

Fallo mio, el has se estaba calculando con la serie equivocada 😰

entonces el orden de encadenamiento debe de ser por emisión de factura entiendo

1/25->2/10->2/11->1/56

Correcto, el encandenamiento es con el último registro creado, sea de la misma serie o de otra


Saludos

Facturas normales y simplificadas
 

Si el sistema emite facturas simplifaicadas y facturas normales ¿llevan encadenamientos distintos? Se puede dar el caso de que ambas tengan coincidencias de serie y número

Muchas gracias

No, el encadenamiento sería el mismo. Y no deberías permitir que facturas normales y simplificadas compartan serie porque la liarás

Efectivamente. El que no se puedan repetir números de facturas "normales" y simplificadas es una cosa que intuía y no había probado. He hecho la prueba de enviar una factura "normal" y luego una simplificada con el mismo número y en la simplificada me da error de factura duplicada.

Efectivamente!

Las facturas normales y simplificadas no pueden compartir serie, dará registro de factura duplicada si coincide en el mismo día (sí son días distintos no, pero no puedes contar con que no van a coincidir).

Si el numero de serie y factura, es el mismo da igual el día, te dará error de registro de facturación repetido, a no ser que la fecha sea parte de tu numero de factura, cosa que no veo muy correcto.

Gracias a todos.:)

He optado por añadir a la serie, en el xml, un prefijo a la serie ("T." par tiquet y "F." para facturas) para que no se puedan producir coincidencias. Supongo que, al final, lo que buscan en un identificador que no lleve a confusión.

Por que no lo ves correcto?? Nosotros le añadimos la opción al cliente de poner MMAA o MMAAAA en las series.

¿Has llegado a probarlo? Porque yo tengo el mismo serie/factura en distintos días y no me dio nada de registro duplicado!

Y en esos casos el NIF_OT, ID_SIF y Nº INSTALACION eran los mismos ??

Hola, me referia a en la serie o numero DDMMAA, el dia no lo veo correcto porque te cambia la serie todos los dias, el año , yo si lo incluyo, pero cambiar la serie todos los meses, no se lo veo raro, pero es mi opinión.

Si, a mi me dio error, al intentar enviar de nuevo un registro de facturación, que ya había usado en las primeras pruebas, estoy hablando de un registro enviado en octubre, que dio error en diciembre, osea que a mi si me paso.
Ahora no lo he probado, pero si el Registro, incluye la misma identificacion, ha de dar error, si cambia la serie, porque incluye el mes, como me indicabais arriba, pues ya no es la misma serie.
Es mas , no me pasa el control del registro, enviándolo a la AEAT, para verificarlo.

sí sí...

y si hago la consulta en la página de la AEAT veo los dos registros, uno de ayer y otro de hoy:

Pues ya te digo yo, que eso es un fallo de ellos, al validar, porque una cosa es que sea de otro año/periodo fiscal, pero de otro día, antes daba fallo.

Humm... Yo sólo sé que no sé nada.

De una forma o de otra yo evitaría enviar el mismo número de factura en una factura normal y en una simplificada.