Les deux codes
- 4113
- «El XML no cumple con el esquema: se ha superado el límite permitido de registros para el bloque.» Un bloc du XML contient plus de répétitions qu'il n'en admet.
- 4114
- «El XML no cumple con el esquema: se ha superado el límite máximo permitido de facturas a registrar.» La requête contient plus de factures que le nombre autorisé.
Les deux relèvent de la section qui rejette l'envoi complet. Selon le document de validations de l'AEAT, le bloc RegistroFactura se répète de 1 à 1000 fois dans chaque requête, et les inscriptions et les annulations peuvent aller ensemble, chacune dans son propre RegistroFactura.

Comment Odoo répartit les envois
La file du module s'exécute toutes les 1 minute et, à chaque passage, regroupe les enregistrements en attente de chaque société dans une seule requête, dans l'ordre de la chaîne. Cette requête ne dépasse jamais 1000 enregistrements :
- Le paramètre verifactu.max_envelope_records fixe le nombre d'enregistrements envoyés à chaque passage ; si personne n'y touche, il vaut 1000.
- Ce qui ne rentre pas reste dans la file pour le passage suivant.
- Si, par un chemin quelconque, plus de 1000 enregistrements devaient partir, le client du module s'arrête avant l'envoi avec «The AEAT accepts at most 1000 records per request.».
Dans chaque enregistrement, le module ajuste aussi les blocs à leurs plafonds : la ventilation fiscale est ramenée à 12 lignes, sans avertissement, et un échange de factures simplifiées porte jusqu'à 1000 factures remplacées.

Le rythme imposé par l'AEAT
Outre la taille, l'AEAT fixe le rythme. Chaque réponse contient un TiempoEsperaEnvio, le nombre de secondes à attendre avant l'envoi suivant, et le module le respecte. Une exception : si 1000 enregistrements sont déjà en attente, il n'attend pas, car la requête est pleine. Si l'AEAT répond par un HTTP 429 pour excès de requêtes, le module attend le délai indiqué par son en-tête Retry-After et, à défaut, 60 secondes.
Si l'un de ces codes apparaît
Avec le paramètre à sa valeur, un 4113 ou un 4114 ne devrait pas se produire. Si quelqu'un a relevé verifactu.max_envelope_records au-delà de 1000, remettez-le à 1000 ou laissez-le vide. Puis renvoyez les envois en Failed depuis Envoi à AEAT › Erreurs AEAT avec Réessayer la sélection : la file les répartira en requêtes de la bonne taille.
Les inscriptions et les annulations vont-elles dans la même requête ?
Oui. L'AEAT l'admet tant que chacune se trouve dans son propre RegistroFactura, et la file du module envoie ensemble les inscriptions et les annulations en attente de la société, dans l'ordre de la chaîne.
Faut-il baisser le paramètre ?
Ce n'est pas nécessaire. Moins d'enregistrements par requête signifie plus de requêtes, et chacune doit attendre le TiempoEsperaEnvio fixé par l'AEAT.
Si vous obtenez un de ces codes avec le paramètre à 1000, écrivez à comercial@flexigobe.com avec la réponse de l'envoi.
À lire aussi
Vérifié dans le code du module (version 20.0) et dans les sources citées
Sources
- www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validacione
- Code du module : flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_aeat_client.py
- Code du module : flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cola_envio.py
- Code du module : flexigo_spain_verifactu 20.0 (aa2ea3d2): data/verifactu_crons.xml
- prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/Sis
- prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/err
