Réponse courte
La connexion consiste à extraire une transaction de l'ERP ou du POS, valider et transformer ses données, l'envoyer vers l'architecture FEC applicable, puis retourner au système source le statut, les identifiants et la preuve fiscale. L'intégration doit prévoir les erreurs et les reprises dès le départ.
Équipes IT, éditeurs et intégrateurs chargés de connecter un ERP, un POS ou une application métier.
Une API ou un connecteur ne suffit pas à prouver la conformité. Le flux complet doit respecter l'architecture et le périmètre homologués.
Flux de référence
- ERP ou POS : données commerciales et fiscales.
- EazLink : mapping, validation, orchestration et journal d'audit.
- Dispositif conforme : traitement selon l'architecture homologuée.
- Retour : statut, code, QR, signature ou preuve attendue.
Modes d'intégration
Selon le système existant, l'échange peut passer par API, fichiers structurés ou connecteur local. Odoo, Dolibarr, Sage, ERPNext, SAP Business One, Microsoft Dynamics et les applications sur mesure peuvent être évalués, mais la compatibilité doit être validée techniquement pour chaque version et chaque périmètre.
Critères d'acceptation
- Aucune vente ne reste sans statut visible.
- Une soumission en double est détectée.
- Une erreur indique une action concrète.
- La preuve retourne dans le système ou l'archive métier.
- Le rapprochement quotidien identifie les écarts.
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
Pas nécessairement. Si le POS expose les données nécessaires et accepte le retour fiscal, une couche d'intégration peut préserver l'interface de caisse.
Non. La conformité dépend aussi du format, des règles, de l'architecture homologuée, des contrôles, de l'exploitation et de la preuve conservée.
Le middleware fiscal isole le mapping, les contrôles, les statuts et les reprises afin que l'ERP ou le POS conserve sa logique métier principale.
Une couche commune peut servir plusieurs systèmes si chacun dispose d'un mapping testé, d'identifiants stables et d'un retour de statut adapté.
L'échange peut utiliser une API, des fichiers structurés ou un connecteur local. Le choix dépend des capacités du système et de l'architecture FEC validée.