Perché fa cadere l'invio intero
Il documento di validazione dell'AEAT distingue tre tipi di controllo: strutturali, sintattici e di business. I controlli strutturali verificano che l'XML rispetti lo schema, con i suoi tag obbligatori, e quando falliscono il rifiuto riguarda l'intero messaggio. Quel rifiuto torna come SoapFault e nessuna fattura della richiesta viene registrata, nemmeno quelle corrette.
L'elenco ufficiale lo dice così: «El XML no cumple el esquema. Falta informar campo obligatorio.» Si trova nella prima sezione, quella dei codici che respingono l'invio completo.

Cosa fa il modulo perché non arrivi
Un solo record malformato trascinerebbe con sé tutti gli altri dello stesso invio. Per evitarlo, il modulo valida ogni record contro lo schema ufficiale dell'AEAT prima di inviarlo. Ne porta con sé una copia, il file SuministroLR.xsd con le sue dipendenze, e il percorso è questo:
- Alla registrazione della fattura Si crea il suo record di fatturazione, che non cambia più.
- Al giro successivo della coda Ogni record in attesa viene convertito in XML e validato contro lo schema.
- Se un record non è conforme Viene segnato come respinto in Odoo con il messaggio dello schema, senza codice dell'AEAT, e non parte.
- Il resto Va all'AEAT nella stessa richiesta, senza il record difettoso.
Così un record difettoso non trascina con sé le fatture corrette che viaggiano insieme.
Come lo vedi in Odoo
Nella coda di invio, il record bloccato compare in Failed con il messaggio del validatore nell'ultimo errore, al posto di un codice a quattro cifre. Quel messaggio indica l'elemento che manca o che è di troppo, cioè esattamente ciò che ti serve per capire da dove viene. Nell'elenco dei record di fatturazione, il suo stato è «Rechazado AEAT», anche se l'AEAT non l'ha mai visto.

Prima ancora dello schema ci sono dati senza i quali il modulo non costruisce nemmeno l'XML, e te lo dice con un messaggio proprio:
Company … has no NIF for Veri*Factu.quando l'azienda non ha il NIF.Record … has no tax breakdown (Desglose) to declare.quando il record non ha il dettaglio delle imposte.
Se il 4102 arriva dall'AEAT
Se la risposta con il 4102 viene dall'AEAT stessa, il record ha superato la validazione locale e l'AEAT l'ha respinto con il proprio schema. La spiegazione più ragionevole è che lo schema dell'AEAT e la copia del modulo non coincidano più. In quel caso non serve reinviare: scrivi a comercial@flexigobe.com con la risposta completa, il campo Raw Response della coda, perché possiamo rivedere la copia dello schema.
Posso correggere il dato e riprovare?
Dipende da dove si trova il dato. L'intestazione viene costruita a ogni invio con i dati dell'azienda in quel momento: se l'errore era nel nome, correggilo e usa Riprova selezione in Errori AEAT. Se era nel NIF, correggerlo non basta, perché il NIF era entrato anche nell'hash di ogni fattura alla registrazione e il reinvio torna con il 2000. Se il dato si trova nel record della fattura, il tentativo manda la stessa cosa e fallisce di nuovo. In questi due casi, scrivici.
La fattura si perde?
No. Il record resta in Odoo, concatenato, e la coda elabora i lavori in attesa ogni 1 minuto non appena il problema è risolto.
Continua a leggere
Verificato nel codice del modulo (versione 20.0) e nelle fonti collegate
Fonti
- www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validacione
- Codice del modulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_aeat_client.py
- Codice del modulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): data/verifactu_crons.xml
- Codice del modulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cola_envio.py
- Codice del modulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_registro.py
- prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/err
- Codice del modulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cadena.py
