Ce qu'est cette tâche et sa fréquence
Qu'est-ce que c'est et comment est-elle configurée ?
C'est une tâche planifiée du module VeriFactu qui travaille sur la file d'envoi à l'AEAT. Elle est active dès l'installation et s'exécute chaque minute. Elle figure dans les branches publiées pour Odoo 17.0, 18.0, 19.0 et 20.0 ; en 17.0, elle est configurée pour se répéter sans fin.

Envoie-t-elle à l'AEAT chaque minute ?
La tâche s'exécute chaque minute, mais cela ne signifie pas une requête par minute. Chaque réponse de l'AEAT contient TiempoEsperaEnvio, les secondes avant le prochain envoi. D'après le code d'Odoo 20.0, le module enregistre cette heure pour la société et ne lui envoie rien avant qu'elle n'arrive (avec une exception que vous verrez plus bas).
Où voir les entrées qu'elle traite ?
Dans le menu Verifactu / SIF › AEAT Submission › Submission Queue. Chaque niveau du menu demande des droits et, si vous n'en avez pas, vous ne voyez pas ce niveau. Le niveau AEAT Submission demande Accountant, Auditor (read-only) ou SIF Manager. Le niveau Verifactu / SIF demande l'un de ceux-ci : Accountant, Asesoría Operator, Auditor (read-only), Privacy Officer ou SIF Manager. Le champ Reference de chaque entrée se voit dans sa fiche, celle de AEAT Errors, dans le groupe Queue Entry, et aussi dans la liste.

Ce qu'elle fait à chaque passage
Quelles sociétés traite-t-elle et quand en saute-t-elle une ?
Elle ne parcourt que les sociétés qui ont VeriFactu activé. Pour chacune, elle regarde deux heures enregistrées, dont l'une correspond au temps d'attente de la dernière réponse de l'AEAT. Si l'une de ces heures n'est pas encore arrivée, elle saute la société pour ce passage et le note dans le log du serveur. L'exception concerne l'attente de la dernière réponse : s'il y a 1 000 entrées ou plus en attente (en attente ou en nouvel essai), la société n'attend pas à cause d'elle.
Que fait-elle des entrées d'une société ?
Elle demande le lot de la file de cette société et, s'il n'y a rien, elle en a terminé avec elle sans plus. Les entrées qui n'ont ni enregistrement ni annulation liés sont marquées comme échouées. Les autres sont triées par numéro d'enregistrement, car chaque enregistrement nomme son prédécesseur dans le chaînage. Ensuite, elle prépare chacune comme une création ou comme une annulation et les envoie ensemble en une seule requête à l'AEAT. Selon l'AEAT, un envoi contient de 1 à 1 000 enregistrements.
Que se passe-t-il avec la réponse, ou avec l'échec ?
Si l'AEAT répond, le module applique à chaque entrée son résultat. La réponse contient EstadoEnvio (Correcto, ParcialmenteCorrecto ou Incorrecto) et un statut par enregistrement (Correcto, AceptadoConErrores ou Incorrecto). Si elle contient un temps d'attente, le module enregistre l'heure jusqu'à laquelle cette société n'envoie plus. Si la requête échoue avec un 429, le module la traite par un chemin distinct de celui des autres erreurs. Avec toute autre erreur, il fait passer chaque entrée par le traitement d'erreur HTTP et, si une entrée est abandonnée, il lance une seule alerte pour tout le lot au lieu d'une par facture. À la fin de la société, il demande à sa chaîne un unique recalcul pour toutes les entrées.
Renvoie-t-elle ce que l'AEAT a déjà accepté ?
Un enregistrement en double revient de l'AEAT avec le code 3000. S'il figure déjà comme correct ou accepté avec erreurs, il n'y a pas à le renvoyer.
Si elle semble ne rien faire
Que vérifier en premier ?
Vérifiez que la tâche est toujours active (elle l'est dès l'installation), que la société a VeriFactu activé et que la liste de Submission Queue contient des entrées. Regardez aussi si la société est dans une attente : après une réponse de l'AEAT, elle patiente le temps que celle-ci a indiqué, et ce passage est noté dans le log du serveur. Un passage avec un lot vide se termine sans rien envoyer. Si le problème vient du certificat, l'AEAT redirige sans certificat vers la page d'erreur 4033 (« aucun certificat détecté ») et, avec un certificat qui ne valide pas, vers la 4011.
Une erreur dans une société bloque-t-elle les autres ?
D'après le code, non. Chaque société est traitée dans son propre contrôle d'erreurs : si elle échoue, l'erreur reste dans le log du serveur avec le nom de la société et la tâche passe à la suivante.
Qu'est-ce que le résumé de santé de la fin ?
Une fois toutes les sociétés traitées, et seulement si quelque chose a échoué pendant le passage, la tâche prépare un résumé de santé pour FlexigoTech Cloud à des fins de supervision. Elle ne l'envoie pas à chaque passage, mais à intervalles minimaux entre les rapports. Il contient le nombre d'entrées en attente ou en nouvel essai et celui des entrées abandonnées, ainsi que les erreurs regroupées par type, code et nombre d'occurrences.
De l'aide pour votre mise en place
Si vous déployez Odoo et souhaitez vérifier comment cette file se comporte avec vos sociétés, chez FlexigoTech nous déployons Odoo 17, 18, 19 et 20 et développons des connecteurs et des intégrations sur mesure.
À lire aussi
Vérifié dans le code du module (version 17.0 et 20.0) et dans les sources citées
Sources
- Code du module : flexigo_spain_verifactu 20.0 (1fdc980f): data/verifactu_crons.xml
- Code du module : flexigo_spain_verifactu 17.0 (8d43d727): data/verifactu_crons.xml
- Code du module : flexigo_spain_verifactu 20.0 (1fdc980f): models/verifactu_cola_envio.py
- apps.odoo.com/apps/modules/20.0/flexigo_spain_verifactu
- prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/Sis
- sede.agenciatributaria.gob.es/Sede/errores/erro4033.html
- flexigotech.com/en/services.html
