u/Ok-Information-8148

▲ 3 r/Spanishtaxes+2 crossposts

Veri*Factu: ¿el encadenamiento incluye los registros rechazados por la AEAT o solo los aceptados? [ENGLISH] Veri*Factu (Spain): does the hash chain include AEAT-rejected records, or only accepted ones?

Buenas, estoy implementando Veri*Factu en un ERP propio y tengo una duda con el encadenamiento que no consigo cerrar del todo. A ver si alguien que ya lo tenga en producción me lo confirma.

El caso:

  1. Genero la factura A, la envío, la AEAT la acepta. Huella = H-A.
  2. Genero la factura B, encadenada a A. Huella = H-B. La envío y la AEAT la rechaza (o sea, en la AEAT no consta).
  3. Ahora genero la factura C.

¿A qué debe encadenarse C?

  • Opción 1: a H-B, el último registro generado, aunque fuera rechazado. Cadena: A → B → C
  • Opción 2: a H-A, el último registro aceptado, saltándose el rechazado. Cadena: A → C

He visto implementaciones de las dos formas: algunas encadenan con todo lo generado (incluidos los rechazados) y otras solo con lo que la AEAT ha aceptado. Por lo que he leído en las FAQs de desarrolladores de la AEAT, el encadenamiento es con el último registro generado (RF n-1), lo que apuntaría a la Opción 1, pero me gustaría confirmarlo con gente que lo tenga funcionando de verdad.

  • ¿Vosotros encadenáis con los rechazados o solo con los aceptados?
  • ¿Alguien ha tenido problemas con la AEAT por encadenar a un registro que ella misma rechazó?
  • Y ya puestos: cuando luego subsanáis ese registro B (Subsanacion=S, RechazoPrevio=X), ¿a qué lo encadenáis, al último generado en ese momento o al anterior original?

Gracias, cualquier experiencia real me vale.

In English

Title: Veri*Factu (Spain): does the hash chain include AEAT-rejected records, or only accepted ones?

Building Veri*Factu into our own ERP and I can't fully settle one thing about chaining. Hoping someone with it in production can confirm.

Scenario:

  1. Generate invoice A, send it, AEAT accepts. Fingerprint = H-A.
  2. Generate invoice B, chained to A. Fingerprint = H-B. Send it, AEAT rejects it (so it doesn't exist on their side).
  3. Now generate invoice C.

What should C chain to?

  • Option 1: H-B — the last record generated, even though rejected. Chain: A → B → C
  • Option 2: H-A — the last record accepted, skipping the rejected one. Chain: A → C

I've seen it implemented both ways — some systems chain through everything generated (rejected included), others only through what AEAT accepted. AEAT's developer FAQ says chaining is to the last generated record (RF n-1), which points to Option 1, but I'd like confirmation from people actually running this.

  • Do you chain through rejected records, or only accepted ones?
  • Has anyone had AEAT push back for chaining to a record it rejected?
  • Related: when you later fix that rejected record (Subsanacion=S, RechazoPrevio=X), what do you chain that to — the latest generated record, or the original predecessor?

thanks in advance

reddit.com
u/Ok-Information-8148 — 8 days ago