Réponse courte
Une API fiscale pour éditeurs de logiciels doit faire plus que transmettre un JSON. Elle doit valider les données, préserver un identifiant stable, exposer les statuts, gérer les réponses incertaines et retourner la preuve au produit source. Le connecteur DGI reste soumis à l'architecture et au périmètre homologués.
Éditeurs ERP, POS, logiciels métiers et équipes produit qui veulent intégrer la FEC sans disperser la logique pays.
L'API facilite l'intégration mais ne constitue pas une homologation. Les spécifications officielles et les essais du système complet restent déterminants.
Le contrat technique minimal
- Identifiant métier stable et idempotent.
- Schéma versionné avec erreurs lisibles.
- Statuts séparant attente, refus et confirmation.
- Retour des identifiants et éléments fiscaux.
- Journal permettant le rapprochement.
Pourquoi isoler la logique pays
Quand chaque module du produit connaît les règles FEC, une évolution réglementaire oblige à modifier plusieurs parcours. Un middleware fiscal centralise le mapping et laisse au logiciel métier la gestion de la vente, du client et du stock.
Ce qu'il faut tester avec l'éditeur
Les tests doivent partir des documents réels du produit : vente, avoir, annulation et cas de données incomplètes. Ajoutez les coupures et les réponses incertaines avant de valider l'intégration.
Ce que l'éditeur délègue à EazLink
L'éditeur garde l'écran de vente, le client, le stock et ses règles métier. EazLink prend en charge le contrat fiscal convenu : validation, mapping, soumission, lecture des réponses, reprise et journal technique.
Le produit reçoit un statut exploitable et les éléments à afficher ou à archiver. Les équipes évitent ainsi d'éparpiller les règles FEC dans plusieurs modules, tout en gardant la maîtrise de l'expérience utilisateur.
| Dans le produit métier | Dans EazLink |
|---|---|
| Vente, client et stock | Contrôles et mapping fiscal |
| Écran de facture | Statuts, erreurs et preuve retournée |
| Cycle de version du produit | Contrat d'API et mapping versionnés |
Votre projet avec EazLink
Passez des termes à une architecture testable
Choisissez le point de départ qui correspond à votre système et à la responsabilité que vous souhaitez conserver.
Sources officielles
Consultez le centre documentaire FEC de la DGI et les conditions et modalités d'émission. Les textes officiels prévalent sur ce guide.
L'équipe produit EazLink de Xiamen DataMega Technology Co., Ltd rédige ces guides à partir des publications officielles et de son travail sur les systèmes fiscaux. Le contenu aide à cadrer un projet technique. Il ne remplace pas une confirmation de la DGI ni un avis fiscal local.
Questions fréquentes
Non. Certains systèmes utilisent des fichiers structurés ou un connecteur local. Le choix doit rester compatible avec le flux et l'exploitation attendus.
Le projet doit définir l'archive de référence et rendre la preuve accessible depuis le système métier ou le rapprochement.
Utilisez un contrat commun, puis un mapping versionné par produit et par version. Les écarts ne doivent pas être masqués dans un format générique.
La continuité dépend de l'architecture autorisée. Une file locale peut être nécessaire, mais ses limites doivent être testées et validées.
Non. L'éditeur reste responsable de ses données métier et de l'expérience utilisateur. EazLink peut prendre en charge la couche d'intégration fiscale convenue.