# Reference - EDI, ADEC, dematerialisation

## Principe general

Dans les ERP CDJ historiques, l'EDI n'est pas un simple import de fichier. C'est une chaine:

1. Transport sécurisé.
2. Réception dans des répertoires ou files.
3. Reconnaissance d'un donneur d'ordre ou partenaire.
4. Validation du format.
5. Mapping vers les objets internes: dossier, personne, acte, événement, pièce, finance.
6. Historisation et gestion des rejets.
7. Retour vers le partenaire.

## AFT / ADEC

Les éléments locaux reconstruits montrent une architecture probable:

- compte AFT, certificat, référence ADEC;
- répertoires IN, OUT, REJ, TMP, historiques;
- donneurs d'ordre identifiés par tags et masques de fichiers;
- flux métier séparés: SDR, IPNet, ZIP PJ, SECURACT, E-Acte, SIV, EXPLOC, etc.

Ce qu'il faut retenir pour l'ERP:

- le transport classe les fichiers;
- l'ERP interprète le payload métier;
- un XML valide ne suffit pas: il faut le partenaire, le modèle de réception, les codes événement et les mappings internes.

## Signification électronique

La signification électronique nécessite une plateforme, de la traçabilité, de la signature/archivage et souvent le consentement du destinataire selon les cas. SECURACT est un exemple cité par la profession.

Implication produit:

- consentement et canal électronique doivent être des données métier;
- les preuves de dépôt, remise, refus ou absence doivent être historisées;
- l'acte électronique doit rester relié au dossier et au répertoire.

## Rejets et reprises

Les rejets sont normaux en EDI:

- fichier mal formé;
- partenaire non reconnu;
- dossier introuvable;
- code acte ou événement non mappé;
- doublon;
- pièce jointe manquante;
- échec de rapprochement personne/adresse.

Un ERP doit prévoir:

- une file "à intégrer";
- une file "rejets";
- des actions de correction;
- une relance d'intégration idempotente;
- un journal technique et métier.

## Écrans EDI attendus

| Écran | Usage |
| --- | --- |
| Partenaires | Alias, identifiants, répertoires, règles de mapping, modèles de réception. |
| Flux reçus | Liste des fichiers ou messages avec statut transport et statut métier. |
| Rejets | Diagnostic, payload, correction guidée, action de reprise. |
| Événements dossier | Ce que le flux a réellement modifié dans le dossier. |
| Retours sortants | Messages générés vers le partenaire avec preuve d'émission. |

## Règle produit

Un flux EDI ne doit jamais mettre à jour silencieusement un dossier sans trace compréhensible. Chaque intégration doit laisser une ligne métier: source, identifiant externe, mapping appliqué, objet créé ou modifié, utilisateur ou automate, date, et éventuel retour produit.