Español
EnglishPer què fa caure l'enviament sencer
El document de validacions de l'AEAT distingeix tres tipus de comprovació: estructurals, sintàctiques i de negoci. Les estructurals miren que l'XML compleixi l'esquema, amb les seves etiquetes obligatòries, i si fallen el rebuig és del missatge sencer. Aquest rebuig arriba com un SoapFault i no queda registrada cap factura de la petició, tampoc les que estaven bé.
El text de la llista oficial ho diu tal qual: «El XML no cumple el esquema. Falta informar campo obligatorio.» És al primer apartat, el dels codis que rebutgen l'enviament sencer.
El que fa el mòdul perquè no arribi
Un sol registre mal format arrossegaria tots els altres del mateix enviament. Per evitar-ho, el mòdul valida cada registre contra l'esquema oficial de l'AEAT abans d'enviar-lo. En porta una còpia a dins, el fitxer SuministroLR.xsd amb les seves dependències, i el recorregut és aquest:
- En publicar la factura Es crea el seu registre de facturació, que ja no canvia.
- A la volta següent de la cua Cada registre pendent es converteix en XML i es valida contra l'esquema.
- Si un registre no el compleix Es dona per rebutjat a Odoo amb el missatge de l'esquema, sense codi de l'AEAT, i no surt.
- La resta Surt cap a l'AEAT a la mateixa petició, sense el registre dolent.
Així, un registre defectuós no s'emporta per davant les factures bones que viatgen amb ell.
Com ho veuràs a Odoo
A la cua d'enviament, el registre aturat apareix en Failed amb el missatge del validador a l'últim error, en lloc d'un codi de quatre xifres. Aquest missatge anomena l'element que falta o que sobra, que és just el que necessites per saber d'on ve. A la llista de registres de facturació, el seu estat és «Rechazado AEAT», encara que l'AEAT no el va arribar a veure.
Fins i tot abans de l'esquema, hi ha dades sense les quals el mòdul ni tan sols construeix l'XML, i t'ho diu amb el seu propi missatge:
Company … has no NIF for Veri*Factu.quan l'empresa no té NIF.Record … has no tax breakdown (Desglose) to declare.quan el registre no té desglossament d'impostos.
Si el 4102 arriba de l'AEAT
Si la resposta amb el 4102 ve de la mateixa AEAT, el registre va passar la validació local i l'AEAT el va rebutjar amb el seu esquema. L'explicació raonable és que l'esquema de l'AEAT i la còpia que porta el mòdul ja no coincideixen. En aquest cas no serveix de res tornar a enviar: escriu-nos a comercial@flexigobe.com amb la resposta completa, el camp Raw Response de la cua, perquè revisem la còpia de l'esquema.
Puc corregir la dada i tornar-ho a provar?
Depèn d'on sigui la dada. La capçalera es munta a cada enviament amb les dades de l'empresa d'aquell moment: si la fallada era al nom, corregeix-lo i fes servir Retry Selected a AEAT Errors. Si era al NIF, corregir-lo no n'hi ha prou, perquè el NIF també va entrar a l'empremta de cada factura en publicar-la i el reenviament torna amb el 2000. Si la dada és al registre de la factura, el reintent envia el mateix i tornarà a fallar. En aquests dos casos, escriu-nos.
Es perd la factura?
No. El registre continua a Odoo, encadenat, i la cua processa el que està pendent cada 1 minut tan bon punt el problema es resol.
Continua llegint
Comprovat al codi del mòdul (versió 20.0) i a les fonts enllaçades
Fonts
- www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validacione
- Codi del mòdul: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_aeat_client.py
- Codi del mòdul: flexigo_spain_verifactu 20.0 (aa2ea3d2): data/verifactu_crons.xml
- Codi del mòdul: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cola_envio.py
- Codi del mòdul: 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
- Codi del mòdul: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cadena.py