Connexion e-MCF
e-MCF en RDC : comment relier un SFE au parcours DGI ?
Le rôle de e-MCF dans un flux intégré, les responsabilités du SFE et les points à tester avant une mise en production.
Mis à jour le 4 septembre 2026 par l'équipe EazLink. Relecture : Équipe éditoriale EazLink.
Le communiqué DGI présente e-MCF comme un module relié à un SFE homologué. Dans un projet d'intégration, le SFE ou sa couche de connexion prépare la facture, l'envoie selon le référentiel applicable et conserve le résultat. L'ERP ou le POS doit retrouver le statut et la preuve sans créer une seconde facture lorsque la réponse tarde.
Source de référence : Inscription sur e-DEF et utilisation de e-UF ou e-MCF.
Le flux à répartir entre les systèmes
Chaque composant a un rôle précis. Les mélanger complique les mises à jour et le support.
| Composant | Responsabilité | Preuve attendue |
|---|---|---|
| ERP ou POS | Créer la vente et garder la référence métier | Facture, ticket ou avoir d'origine |
| SFE ou middleware | Contrôler, transformer et suivre la demande | Historique des états et des reprises |
| e-MCF | Assurer le parcours connecté prévu | Réponse associée à la même demande |
| DGI | Appliquer le traitement fiscal officiel | Statut et éléments rendus par le parcours |
Le découpage exact dépend du référentiel DGI et du SFE homologué. Le tableau décrit les responsabilités à clarifier dans le projet.
À retenir
e-MCF concerne un parcours connecté à un SFE homologué.
Le document métier doit garder une référence stable pendant toute la soumission.
Une absence de réponse ne signifie ni confirmation ni rejet.
Les références techniques et les cas de test doivent correspondre à la version publiée par la DGI.
Dessinez le retour avant de développer l'envoi.
Le statut, la preuve et le motif de rejet doivent revenir dans le logiciel où l'utilisateur travaille.
Le document part du système métier
Une vente existe d'abord dans un ERP, un POS ou une application métier. Le connecteur lit le vendeur, le client, les lignes, les taxes et la devise. Il ne doit pas deviner un champ absent ni corriger silencieusement un total pour faire accepter le document.
La demande reçoit une référence d'idempotence. Si le réseau coupe après l'envoi, cette référence permet de rechercher le résultat connu. Renvoyer la même vente avec un nouvel identifiant est une mauvaise reprise, car le service distant peut avoir traité la première demande.
Le retour compte autant que l'envoi
Un connecteur n'est pas terminé lorsque la requête quitte l'entreprise. Il doit restituer le statut, les identifiants et les éléments de preuve au document d'origine. La finance doit comprendre si la facture est confirmée. Le support doit voir un rejet ou une attente sans ouvrir un journal brut.
Prévoyez les états intermédiaires dès la conception. Reçu, en validation, en soumission, en attente, confirmé et rejeté ne demandent pas la même action. Un bouton de relance unique crée des doublons ou répète une erreur de données.
Ce qu'il faut tester
Le test couvre une facture simple, plusieurs taux, une remise, un avoir et une devise étrangère. Ajoutez une fiche client incomplète, une interruption réseau et une seconde soumission avec la même référence. Vérifiez que la réponse revient au bon document dans l'ERP.
La DGI a publié en février 2026 une mise à jour des groupes de taxation et des cas de test. Ce type de changement montre pourquoi la version du schéma, de la configuration et du SFE doit rester visible. Un test ancien ne prouve pas le comportement de la version déployée.
La place d'EazLink
EazLink fournit une couche stable entre les systèmes métier et le connecteur pays. Les adaptateurs Odoo, Sage, SAP ou POS traduisent les données vers un document commun. La logique DGI reste dans un module séparé, ce qui limite les modifications dans chaque ERP.
La plateforme conserve les états, les reprises et l'audit. Elle peut aussi rapprocher la file du magasin lorsque le réseau est instable. Le déploiement doit toutefois utiliser un parcours et une version dont la situation officielle est confirmée auprès de la DGI.
Questions fréquentes
e-MCF est-il une API publique ?
Le communiqué le décrit comme un module relié à un SFE homologué. Le projet doit utiliser le référentiel technique officiel fourni pour le parcours concerné.
Un ERP peut-il appeler e-MCF directement ?
Le montage dépend du SFE homologué et des règles techniques applicables. Une couche de connexion sépare souvent l'ERP du protocole fiscal.
Que faire si la réponse e-MCF tarde ?
Conservez la demande et sa référence, puis vérifiez le statut avant toute nouvelle soumission.
EazLink est-il un e-MCF homologué ?
Cette page ne revendique pas ce statut. Les homologations et agréments doivent être vérifiés dans les listes DGI.
Sources et vérification
Vérifiez les procédures et listes actuelles avant toute décision de conformité.
Communiqué DGIInscription sur e-DEF et utilisation de e-UF ou e-MCFMise à jour DGIMise à jour 2026 des groupes de taxation et des cas de test SFEMises à jour officiellesCommuniqués officiels de la DGI RDCVous préparez un connecteur e-MCF pour un ERP ou un POS ?
Indiquez le système source, le nombre de sites et l'état du dossier SFE. Nous pourrons cadrer le flux et les tests à prévoir.