Español
English
Català
Deutsch
Português
Italiano
Nederlands
PolskiPour qui il est fait et pour qui il ne l'est pas, en bref
Lorsque vous confirmez une facture ou un avoir client dans un journal activé, le connecteur génère un XML UBL 2.1 qui suit la structure PINT AE, le vérifie avec le validateur propre au module et l'enregistre en pièce jointe sur la facture. Hors mode sandbox, il envoie ce XML à l'endpoint que vous configurez.
Il vous sert si vous voulez mettre en place ce flux dans Odoo, le tester avec le simulateur et, si votre prestataire accrédité accepte le contrat générique du module, lui envoyer vos factures. Il ne vous sert pas, tel qu'il est documenté, si vous avez besoin que le XML respecte les règles PINT AE 1.0.4, si votre prestataire ne travaille qu'avec sa propre API ou si vous voulez recevoir des factures fournisseurs : le module ne les reçoit pas.
Six idées reçues avant d'acheter
« Une fois installé, mes factures sont conformes à PINT AE »
La fiche est claire : le XML n'a pas été validé par rapport aux règles PINT AE 1.0.4 et en enfreint plusieurs. Elle cite celles-ci : les avoirs sont envoyés comme des factures, les indicateurs de type de transaction manquent, les factures en devise étrangère ne comportent pas les montants en AED et l'endpoint de l'acheteur utilise le TRN à 15 chiffres au lieu du TIN à 10 chiffres. Le validateur qui contrôle le XML est celui du module lui-même. Si vous émettez des avoirs ou des factures dans une autre devise, ce sont justement les cas que la fiche signale en échec.
« Il se connecte à n'importe quel prestataire accrédité (ASP) »
Il n'y a d'intégration avec aucun prestataire accrédité par la FTA en particulier. La fiche explique que les prestataires accrédités ne partagent pas d'API standard : l'option REST ne fonctionne donc qu'avec un prestataire qui accepte le contrat générique du module, à savoir un POST vers /invoices avec un bearer token et une interrogation périodique du statut. L'autre option est une enveloppe SOAP AS4 basique, sans WS-Security ni recherche SMP. Avant de décider, demandez à votre prestataire s'il accepte l'un de ces deux formats.
« Si je vois Accepted, la FTA a accepté la facture »
Le mode sandbox est activé par défaut et exécute un simulateur de prestataire dans Odoo. En sandbox, rien ne sort d'Odoo, et les statuts Accepted et les numéros de référence affichés sont simulés. Cela vous permet de parcourir tout le flux à l'écran, pas de prouver un envoi réel.
Accepted est simulé.« Le FTA Clearance ID est l'autorisation de la FTA »
Le champ s'appelle FTA Clearance ID dans l'application, mais la fiche du module précise qu'il ne contient que la référence renvoyée par le prestataire. Selon cette même fiche, le système des EAU ne prévoit pas d'étape d'autorisation préalable (clearance) : dans le modèle des EAU, c'est le prestataire qui transmet les données fiscales à la FTA, et la FTA n'autorise pas les factures avant leur envoi. La réponse et la référence du prestataire sont conservées sur la facture et dans un journal d'audit qui ne peut être ni modifié ni supprimé.
« Avec un identifiant actif, le module signe les factures »
Avec un identifiant actif, le module insère un élément de signature factice au lieu d'une vraie signature. La fiche ajoute que PINT AE n'exige pas de signature dans le document et que cet élément rend le XML invalide.
« Le QR code du PDF est exigé par la réglementation et émis par la FTA »
Le QR code sur le PDF de la facture est facultatif. La documentation du module indique que les règles des EAU n'exigent pas de QR code sur les factures électroniques et que ce QR code n'est pas émis par la FTA.
Ce qu'il apporte vraiment et ce qu'il vous faut avant de l'installer
En plus de générer et d'envoyer le XML, le module comprend :
- Un envoi immédiat ou par lots planifiés, des relances avec back-off, une limitation de débit et un webhook signé HMAC pour les réponses du prestataire.
- Un assistant de configuration et des paramètres par société : TIN, phase et ses dates, et journaux.
- Des identifiants du prestataire chiffrés avec une clé que vous définissez dans l'environnement du serveur (
FLEXIGO_UAE_EINVOICE_FERNET_KEY) et des alertes d'expiration des certificats.
- Le XML joint à la facture et un assistant qui exporte dans un ZIP les factures électroniques d'un TRN.
Le README indique comme prérequis Odoo 20 avec le module l10n_ae (localisation des EAU). Sur Odoo Apps, il est publié pour 17.0, 18.0, 19.0 et 20.0, et les quatre fiches affichent 49 € HT, paiement unique par version d'Odoo. Si vous êtes en 17, 18 ou 19, consultez la fiche de votre version avant d'acheter.
La mise en route décrite dans le README est courte :
- Installez le module depuis Apps.
- Lancez l'assistant de configuration.
- Allez dans
Accounting > UAE E-Invoicing > Configuration > UAE E-Invoicing Settings.
- Saisissez le TIN de la société et choisissez la phase.
- Laissez le mode sandbox actif pour tester le flux avec le simulateur.
- Activez la facturation électronique sur les journaux souhaités.
Le détail de chaque champ et des statuts se trouve dans la mise en route du connecteur.
Comment décider selon votre cas
| Si vous êtes dans ce cas | Ce que dit la documentation |
|---|---|
| Vous voulez voir le flux dans Odoo sans rien envoyer | Le sandbox est actif par défaut et simule prestataire, statuts et références dans Odoo |
Votre prestataire accepte un POST vers /invoices avec bearer token, ou de l'AS4 basique | L'envoi réel peut pointer vers son endpoint, mais le XML conserve les défauts listés par la fiche |
| Vous avez besoin d'un XML conforme aux règles PINT AE 1.0.4 | Il n'a pas été validé par rapport à elles et en enfreint plusieurs |
| Vous émettez des avoirs ou des factures en devise étrangère | Les avoirs partent comme des factures et les montants en AED manquent |
| Vous devez recevoir des factures fournisseurs | Il ne les reçoit pas |
| Votre prestataire ne propose que sa propre API | Il n'y a d'intégration avec aucun prestataire accrédité en particulier |
Si vous préférez d'abord comprendre quels menus il ajoute et par quelles étapes passe chaque facture, lisez comment le connecteur fonctionne en interne.
Comment FlexigoTech vous accompagne
FlexigoTech déploie Odoo 17, 18, 19 et 20 et développe des connecteurs et des intégrations sur mesure. Si votre prestataire accrédité n'accepte pas le contrat générique du module, ou si vous avez besoin de quelque chose que la documentation laisse de côté, nous pouvons étudier avec vous un développement sur mesure. Vous trouverez le détail du module sur sa page sur flexigotech.com et sur la fiche Odoo Apps.
À lire aussi
Vérifié dans le code du module (version 20.0) et dans les sources citées
Sources
- Code du module : flexigo_uae_fta_e_invoicing_connector 20.0 (bd3e6ed9): README.rst
- Code du module : flexigo_uae_fta_e_invoicing_connector 20.0 (bd3e6ed9): static/description/index.html
- apps.odoo.com/apps/modules/20.0/flexigo_uae_fta_e_invoicing_connector
- apps.odoo.com/apps/modules/17.0/flexigo_uae_fta_e_invoicing_connector
- apps.odoo.com/apps/modules/18.0/flexigo_uae_fta_e_invoicing_connector
- apps.odoo.com/apps/modules/19.0/flexigo_uae_fta_e_invoicing_connector
- flexigotech.com/en/services.html