Appearance
Mise en service ERP
Ce guide décrit la mise en production de l'intégration ERP pour une régie. L'objectif est de connecter le SI métier aux opérations de collecte (portail citoyen) et de décaissement (paiements en masse) sans mélanger ce canal avec l'API ministry checkout.
Prérequis côté régie
| Élément | Responsable | Description |
|---|---|---|
| Endpoints REST | Équipe ERP | Health, dues, disbursements, payment confirmations |
| Identifiants contribuable | ERP | subject_ref stable par contribuable |
| Identifiants créance | ERP | erp_due_ref unique par ligne ouverte |
| Catalogue recettes | ERP + métier | revenue_line_code par type de créance |
| Secrets M2M | Officer régie | Auth HTTP vers l'ERP (voir Auth et secrets) |
| Environnement de test | ERP | Jeu de données représentatif (contribuable test, lot disbursement test) |
Parcours officer régie
- Ouvrir Intégration ERP dans le portail régie (
/erp). - Choisir l'adaptateur :
- Sandbox (
fake) : données déterministes, aucun appel HTTP réel. Utile pour formation et démonstration. - REST (
rest) : appels HTTP versbase_urlselon le contrat REST.
- Sandbox (
- Renseigner la connexion : URL de base, mode d'authentification, interrupteur actif.
- Configurer la correspondance : chemins API, paramètre
subject_ref, en-têtes non secrets. - Définir les mappings services : liaison
revenue_line_code→ service catalogue (voir Mapping services). - Enregistrer et lancer Tester la connexion (onglet Vérification).
- Prévisualiser dues et lignes disbursement avec des références de test.
- Tester la notification payment confirmation (probe) avant recette bout en bout.
Parcours super-admin
Même surface sous Régies → {tenant} → Intégration ERP. Le super-admin peut activer l'intégration, révéler les credentials une fois (rotation), et consulter le journal communications ERP.
Phases recommandées
| Phase | Périmètre | Critère de sortie |
|---|---|---|
| P0 - Sandbox | Adaptateur fake, UI régie | Officers formés, parcours UI validé |
| P1 - Connexion | Health + auth REST | Probe connexion OK, latence journalisée |
| P2 - Collecte | GET dues + POST confirmation | Portail citoyen ou probe dues ; confirmation reçue par ERP |
| P3 - Décaissement | GET disbursements | Preview lot ERP, batch sandbox exécuté |
| P4 - Production | Trafic réel | Recette signée (voir Journal et recette) |
Distinction des canaux
| Canal | Configuration | Direction |
|---|---|---|
| API ministry checkout | Clé application | Ministry crée des sessions checkout |
| Webhooks application | Endpoint HTTPS par application | Epayment notifie le SI ministry |
| Intégration ERP | Config tenant ERP | Epayment interroge l'ERP et pousse les confirmations |
Les webhooks application ne remplacent pas POST /payment-confirmations sur l'ERP. Ce sont des mécanismes distincts pour des intégrateurs distincts.
Points d'attention
- Une seule configuration ERP active par régie.
- Les montants sont toujours en unités mineures (
amount_minor, centimes XAF). - Les timestamps sont ISO 8601 UTC (
...Z). - Tout appel HTTP ERP sortant est journalisé ; les secrets sont masqués.