Réponse courte
Pour connecter un ERP ou un POS à la FEC, il faut d'abord vérifier le parcours certifié retenu. Le connecteur extrait ensuite la vente, contrôle les données, les traduit au format attendu et renvoie au logiciel source le statut, les identifiants et la preuve fiscale. La version du logiciel, les volumes, les magasins et le fonctionnement hors ligne doivent être testés avant le déploiement.
É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.
Faut-il remplacer l'ERP ou le POS ?
Pas nécessairement. Un logiciel existant peut rester l'outil de travail s'il expose les données requises et peut recevoir le retour fiscal. Il faut toutefois vérifier son statut exact. La liste DGI associe chaque homologation à un fournisseur, un produit et une version.
La présence de SAGE 100 v12.00 dans la liste ne signifie pas que toutes les versions de Sage 100 sont couvertes. Le même contrôle s'applique à chaque ERP, POS, module ou personnalisation.
Sources : Liste des logiciels homologués, DGI
Quel flux prévoir entre le système métier et la FEC ?
| Étape | Traitement | Résultat attendu |
|---|---|---|
| 1. Vente | L'ERP ou le POS crée la transaction | Identifiant métier stable |
| 2. Contrôle | Le connecteur vérifie client, taxes, lignes et totaux | Erreur lisible avant soumission |
| 3. Transformation | Les données sont mappées vers le format retenu | Message conforme au parcours certifié |
| 4. Traitement fiscal | Le dispositif applique les contrôles prévus | Statut et identifiants fiscaux |
| 5. Retour | Le connecteur met à jour le système source | Preuve visible et rapprochable |
Sources : Spécifications techniques des SFE, DGI · Spécifications techniques des SECeF, DGI
API, fichier ou connecteur local : que choisir ?
Une API convient lorsque le logiciel peut envoyer la vente et recevoir un statut sans bloquer l'utilisateur. Un fichier structuré peut suffire pour un traitement par lot. Un connecteur local est souvent utile quand le POS fonctionne dans un réseau fermé ou doit continuer pendant une coupure Internet.
Odoo, Dolibarr, Sage, ERPNext, SAP Business One, Microsoft Dynamics et les applications sur mesure peuvent être évalués. La compatibilité n'est acquise qu'après un test de la version, des extensions et des cas réels.
Sources : Centre des documents FEC, DGI
Comment gérer plusieurs magasins et les coupures Internet ?
Chaque magasin doit conserver un identifiant de transaction stable et une file dont l'état est visible. Après le retour du réseau, la reprise ne doit ni perdre une vente, ni créer une seconde facture. Le support doit pouvoir distinguer une transaction en attente, refusée ou déjà certifiée.
Avant le pilote, mesurez le volume courant et les pointes, le nombre de caisses, la stabilité du réseau et le délai acceptable. Ces données déterminent le mode de connexion et la supervision nécessaire.
- Tester une coupure avant et après l'envoi.
- Renvoyer sans dupliquer une transaction incertaine.
- Afficher le statut dans le POS ou l'ERP.
- Rapprocher chaque jour ventes, factures et preuves.
- Conserver la configuration et la version par site.
Quels critères valident la mise en production ?
- Chaque vente obtient un statut compréhensible.
- Les doublons sont bloqués par un identifiant stable.
- Les erreurs indiquent une correction possible.
- La preuve fiscale revient dans le système ou l'archive métier.
- Le rapprochement détecte les écarts sans recherche manuelle dans plusieurs outils.
- Le périmètre déployé reste celui qui a été testé et, lorsque requis, homologué.
ERP / POS · critères à vérifier
De la vente au rapprochement : un parcours à tester.
Ce tableau est une grille de préparation, pas un rapport de capacités déjà testées. Chaque résultat doit être démontré sur votre version du logiciel et le dispositif FEC retenu.
| Étape | Décision à documenter | Preuve demandée au pilote |
|---|---|---|
| Source et mapping | API, fichier structuré ou agent local ; identifiant métier stable ; taxes et totaux. | Exemple anonymisé du format convenu et liste des champs. |
| Validation et envoi | Contrôles, destinataire et responsable de chaque rejet. | Cas accepté et cas refusé avec un message exploitable. |
| Succès / refus / inconnu | Ne pas confondre un délai dépassé avec un refus fiscal. | Réponse perdue après envoi ; statut retrouvé avant une reprise. |
| Reprise contrôlée | Règle de consultation, identifiant stable et prévention des doublons. | Redémarrage et répétition du même événement sans seconde facture. |
| Retour ERP / POS | Document cible, références fiscales, preuve et visibilité utilisateur. | Retour consultable dans le système source et archive associée. |
| Rapprochement et exploitation | Écarts, version par site, support et escalade. | Liste des ventes sans preuve, journal et responsable désigné. |
Exemple synthétique : une réponse perdue
Une vente de démonstration BF-DEMO-001 est envoyée, puis la connexion s'interrompt. Son état devient « inconnu ». Le pilote doit montrer comment retrouver le résultat avant de décider une nouvelle émission. Une vente en attente n'est pas présentée comme une facture certifiée.
Exemple pédagogique sans appel à une API réelle. Aucun endpoint, format DGI, délai de traitement ni compatibilité universelle n'est revendiqué.
Télécharger la grille de préparation ERP/POS (CSV) · Lire le guide de connexion ERP/POS · Définir un pilote technique
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
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.