/
III.11. EDI

III.11. EDI

1. Introduction

L’EDI — Échange de Données Informatisé — dans le transport désigne l’utilisation de logiciels pour échanger des informations entre différentes parties prenantes de la chaîne logistique.

2. Codification EDI

3. Intégration du prévisionnels dans Helios ERP

Le périmètre de la fonctionnalité est :

  • Commande prévisionnelles -> FO.csv

  • Prévisionnel de consommation -> GN.csv

  • Format propriétaire Helios → PA.txt

3.1 Intégration AirSupply (FO/GN)

La solution AirSupply de SupplyOn prend en charge les processus SCM collaboratifs entre les clients et les fournisseurs de manière optimale. Elle rassemble tous les processus éprouvés des sous-traitants de l’aéronautique au sein d’une plateforme Web commune. AirSupply constitue un des composants principaux du hub Boost AeroSpace et offre un panel étendu de processus métiers et de fonctionnalités à sélectionner au fur et à mesure par le client. En résumé, AirSupply est un hub collaboratif qui vise à améliorer la visibilité, le contrôle et l’intégration des processus business critiques dans la chaîne d’approvisionnement.

image-20240703-122946.png

Basé sur la spécification fournie par AirSupply :  EDI Setup | SupplyOn Support Center

 

image-20240703-122142.png

Le mapping des données est effectué sur les noms des entêtes, cela nécessite un fichier avec les entêtes présentes pour que l’intégration puissent se faire depuis Helios ERP alors que l’intégration HeliosII se basait sur le numéro des colonnes.

Si il y a une évolution de la spécification AirSupply le mapping mis à jour dans Helios ERP et disponible via un patch. Cependant si le fichier reçu n’est pas dans le format attendu cela n’a plus d’impact si les noms des colonnes n’évoluent pas et peu importe leur position dans le fichier.

Si la colonne n’existe pas dans le fichier elle sera ignorée en lecture.

Exemple

Evolution du format du fichier FO.csv passage de 126 colonnes à 135 colonnes avec l’introduction de 9 nouvelles colonnes en fin de fichier

Avant (HeliosII) il fallait :

  • Modifier la procédure de cohérence du fichier

  • Modifier la lecture du fichier qui est basé sur les numéros de colonnes

    • Livraison d’un nouveau choix dans le paramétrage de lecture du FO.csv

  • Modifier les mapping entre les champs du fichier et ceux traitant l’information en cohérence avec le paramétrage actif

  • Un seul format de fichier (126 ou 128 colonnes) peut être intégré pour le flux sauf en modifiant le paramétrage entre deux intégrations

Maintenant ( Helios ERP)

  • Intégration du fichier si les noms des colonnes n’évoluent pas et peu importe leur position dans le fichier.

Exemple

Evolution du format du fichier FO.csv passage de 126 colonnes à 135 colonnes avec l’introduction de 9 nouvelles colonnes en fin de fichier

Avant (HeliosII) il fallait :

  • Modifier la procédure de cohérence du fichier

  • Modifier la lecture du fichier qui est basé sur les numéros de colonnes

    • Livraison d’un nouveau choix dans le paramétrage de lecture du FO.csv

  • Modifier les mapping entre les champs du fichier et ceux traitant l’information en cohérence avec le paramétrage actif

  • Un seul format de fichier (126 ou 128 colonnes) peut être intégré pour le flux sauf en modifiant le paramétrage entre deux intégrations

Maintenant ( Helios ERP)

  • Intégration du fichier si les noms des colonnes n’évoluent pas et peu importe leur position dans le fichier.

A partir des données stockées en base (EDI_FOS par exemple pour le prévisionnel issu du fichier des Forecast FO.csv)

Le traitement sera

  • Extraction de la donnée

  • Alimentation d’un journal d’intégration et consolidation de la donnée

  • Mise à jour du carnet de commande prévisionnel

    • Création / Modification / Suppression

    • Gestion des contrats

    • Mise à jour des prix

  • IHM et Tableau de bord

3.2 Intégration prévisionnel Helios (PA)

Les donneurs d’ordre fournissent des fichiers avec des prévisionnels sous divers formats​ , Helios ERP ne peut intégrer tous ces formats en natif et c’est pour cela que nous proposons des formats simplifiés.

La démarche a faire ​:

  • A partir du fichier client généralement un fichier .csv ou .xls​

  • Constitution d’une macro par un RDP Helios ou un utilisateur formé qui permet d’extraire les données minimales pour bâtir un plan d’appro et sauvegarder ces résultats dans un de nos fichiers pivot​

  • Les données nécessaires minimales sont ​

    • Emetteur (client)​

    • Référence (article)​

    • Quantité​

    • Date

Plusieurs formats de sortie possibles, fichiers textes avec des colonnes séparées par tabulations (que l’on séparera ici par des virgules):

  • Format 6 colonnes

    • REF, LIBELLE, QTE, DATE_LIV, N_DOSSIER, 4 ou 9 ou 0 (pour HP/HF/PDP),TYPE_LG

    • S’intègre sur le client lié au traducteur EDI : ici CLIENT(18)​

  • Format 7 colonnes (spécifique variance)

    • REF, LIBELLE, QTE, DATE_LIV, N_DOSSIER, 4 ou 9 ou 0 (pour HP/HF/PDP), VARIANCE

  • Format 8 colonnes

    • N_EDI_EMET, CONTACT_EMET, REF, LIBELLE, QTE,DATE_LIV,N_DOSSIER,4 ou 9 ou 0 (pour HP/HF/PDP)

    • Possède une colonne identifiant l’émetteur -> Peut s’intégrer sur plusieurs clients Hélios différents (correspond généralement à plusieurs sites d’un même client)​

    • Possède une colonne pour identifier le nom du contact​

    • Les autres colonnes sont les mêmes que le fichier PA.txt à 6 colonnes​

3.3 Résumer

Chacun des formats prévisionnels géré par Helios ERP suit le process ci-dessous. L’étape de traitement du fichier sera ensuite la même quel que soit le prévisionnel intégré.

3.4 Fichier PO.csv

Le paramétrage des fichiers PO s’effectue au niveau du module Client onglet EDI

La case a cocher : image-20241029-164120.png permet dans le cas d'un changement de date dans le PO de mettre le système à jour (recaler les lignes de commande client)

Ce n'est plus le paramétrage EDI qui compte mais cette coche par fiche client sinon, l'EDI ne viendra pas mettre à jour la ligne de commande client

4. Processus d’intégration technique des prévisionnels FO

4.1 Récupération des donnés dans le fichier FO.csv

Helios sait intégrer différent Format EDI. Cette information est stockée dans la table EDI. Par exemple, la clé 35 correspond à la définition des données pour l’intégration d’un fichier FO.csv​

Pour un format EDI, il peut exister n Traducteur EDI (table EDI_C) c’est-à-dire des emplacements sur disque qui contiennent un fichier structuré selon le format défini​

Exemple ci-dessous, les emplacements contenant un fichier du format FO.csv​

 

 

Exemple ci-dessous, les emplacements contenant un fichier du format FO.csv​

 

 

1.2 Règles métiers

Il n’existe pas de règles métiers pour chaque colonne du fichier FO.csv​, les règles métiers sont basées sur des colonnes qui sont référencées dans la table EDI_SD​

Les 4 champs de base d’une intégration prévisionnelle sont N_EDI_EMET, REF_ART, QTE, DATE_LIV​, pour faciliter le traitement des données par Helios ERP une nouvelle colonne a été rajoutée. Elle contient le nom de la colonne de la table (EDI_FOS dans notre cas) ou sera stockée l’information.

  • N_EDI_EMET

Le champ est géré dynamiquement avec le paramètre ​”Intégration du FO par émetteur” (12)

Se sera soit la colonne CUSTOMERORGCODE (si décoché) soit la et il contient le numéro EDI de l’émetteur du fichier. ​

On l’utilise pour déterminer le client (champ CD_CLIENT) sur lequel sera créé la commande client grace à l’information présente sur la fiche client ou la codification EDI_SITE​.

  • REF_ARTI

Dans la colonne SUPPLIERMATERIALNUMBER du fichier FO.csv​ nous devons y trouver la référence article. La valeur du champ n’est pas traitée directement. Elle est épurée en tenant compte du paramétrage caractères ignorés du paramétrage articles​ image-20240905-144749.png

En comparant avec le champ REF_EPURE de la table ARTICLE elle nous permet de détermine le CD_ARTICLE qui devra être intégré.

Si il n’y a pas de correspondance existante alors une création automatique est possible en fonction du paramétrage EDI image-20240905-144843.png

  • QTE colonne DEMANDQUANTITY, la quantité commandée à l’échéance​

  • DATE_LIV : colonne DEMANDDATE, la date de livraison de l’échéance​

Ces informations sont le minimum pour pouvoir constituer un PA

4.2. Alimentation des tables

On alimentation d’une nouvelle structure qui sera le point d’entrée de toute nouvelle intégration prévisionnelle de commande client​

  • Uniformisation des traitements des fichiers prévisionnels​

  • EDI_JOURNAL_PA : Les plans d’appro​

  • EDI_JOURNAL_PA_LG : Le détail d’un plan d’app

4.3. Déroulé : processus automatique sans intervention humaine

4.3.1 Préparation des données

  • Extraction des couples REF_ARTI / N_EDI_EMET c’est-à-dire la liste des articles par client et stockage des données dans EDI_JOURNAL_PA​

  • Par couple extrait, extraction du nouveau prévisionnel de commande et stockage des données dans EDI_JOURNAL_PA_LG​

4.3.2. Consolidation de la donnée extraite

  • Détermination des clients émetteurs (via table EDI_SITE)  CD_CLIENT dans EDI_JOURNAL_PA​

  • Détermination des articles -> CD_ARTICLE dans EDI_JOURNAL_PA​

  • Recherche des plans d’appro existants -> CD_C_CMD_PREV dans EDI_JOURNAL_PA​

  • Recherche des contrats associés aux clients et aux articles en fonction de la date de livraison prévisionnelle -> CD_ARTI_CONTRAT / N_LIEN dans EDI_JOURNAL_PA_LG​

  • Détermination du type de ligne de commande client -> CD_C_CMD_LG_TYPE dans EDI_JOURNAL_PA_LG​​

4.3.3. Anomalie sur les données

Listing des anomalies ou point de vigilance​:

  • Emetteur inconnu  Fiche client non existante ou Numéro EDI émetteur à rattacher à un client existant via la codification EDI_SITE​

  • Article inconnu  En fonction du paramétrage l’article peut être créé automatiquement. Sinon il faudra les créer manuellement​

  • Emetteur incohérent  Une référence article lié à deux numéros EDI émetteurs différents mais qui sont liés à un même client Helios. En théorie 2 plans d’appro différents mais que l’on ne saura pas intégrer correctement​

4.3.4. Statistique

Indicateurs de l’évolution du prévisionnel​

  • Extraction des données des plans d’appro existant et calcul​

    • Nb d’échéance / Horizon du plan / Cumul des quantités du plan​

  • Idem avec le plan d’appro en cours de d’intégration​

4.3.5. Mise a jour des données

  • Intégration du nouveau plan d’appro​

  • Création des nouveaux plans d’appro ​

  • Mise à jour des données  Dates et Quantités sur les numéros d’échéances communs​

  • Création des nouvelles échéances sur les plans d’appro existants​

  • Mise en conformité des lignes créées au format Helios ERP​

  • Identification des échéances à supprimer  Suppressions de ces échéances par plan d’appro

4.4. Entreprise étendue

 

Pour l'Entreprise étendue​ on alimentera la table EDI_FOS_ST​ pour la prise en compte du cadencement ​ou des sous-traitants de niveau 1​.

Génération des fichiers ​pour chaque sous-traitant paramétré​ au format PA : FO (csv)​ et a l’emplacement défini​ (Chemin AL doit être connu du serveur d’application​, il faut donc privilégier les chemins réseaux ​)

  • Extraction de la donnée pour le sous-traitant concerné​

  • Génération du fichier FO.csv​

4.5 Intégration fichier GN.csv

La récupération des données dans le fichier GN.csv​ est conditionner a la clé 38 correspond à la définition des données pour l’intégration d’un fichier GN.csv​. Comme précédemment différents traducteurs EDI peuvent être lié à ce format de fichier​

Pour le fichier GN.csv, on retrouve le mapping EDI_SD dans la table EDI_SD​ et on retombe dans le cas précédent ou on identifie l’émetteur l’article et le PA du couple à partir des informations qui y sont présentes

La logique précédente pour le fichier FO.csv reste vrai à savoir​

  • Identification des articles et des clients émetteurs​

  • Identification des commandes prévisionnelles existantes pour le couple Client émetteur / Article​ (Création si nécessaire)

  • Mise à jour des données par échéances entre le Plan d’Appro existant dans Helios et le nouveau Plan d’Appro reçu​

    • Si échéance commune alors mise à jour quantité et date​

    • Si nouvelle échéance alors création de ligne​

    • Si moins d’échéance alors suppression de l’excédent​

  • Les données sont consolidées dans les 2 tables précédemment citées : EDI_JOURNAL_PA et EDI_JOURNAL_PA_LG​

4.6. Intégration Fichier PA.txt

Comme précédemment on se ramène au même processus d’intégration​

  • Identification des articles et des clients émetteurs​

  • Identification des commandes prévisionnelles existantes pour le couple Client émetteur / Article​ (Création si nécessaire ​)

  • Mise à jour des données par échéances entre le Plan d’Appro existant dans Helios et le nouveau Plan d’Appro reçu​

    • Si échéance commune alors mise à jour quantité et date​

    • Si nouvelle échéance alors création de ligne​

    • Si moins d’échéance alors suppression de l’excédent​

  • Les données sont consolidées dans les 2 tables précédemment citées : EDI_JOURNAL_PA et EDI_JOURNAL_PA_LG​

5. Paramétrage EDI

  1. Path de recherche des dossiers EDI par Client

  2. Permet de généré des commandes multilignes lors de l’intégration d’un fichier PO

  3. Permet d’activer l'unicité de la commande est N° cde, Num poste et requestnumber. Requestnumber est un N° d'échéance présent sur des commandes airsupply. A ne pas activer seul (sans conseil ou tests sur base de TEST).

  4. Le paramétrage des groupes d’entreprise permet d’ignorer des lignes reçues dans le fichier qui ne sont pas destinés au site recevant le message. S’effectue lors de l’extraction des données depuis EDI_FOS vers EDI_JOURNAL_PA. Ces lignes seront en anomalie et elles ne seront pas à intégrer

  5. Comme le point 4 mais pour PO

  6.  

  7. Valeur par défaut du lancement de l’intégration ED

  8. Valeur par défaut du lancement de l’intégration ED

  9. Valeur par défaut du lancement de l’intégration EDI Champs a laisser cocher sous peine de rejet du prévisionnel

  10. Ce paramétrage permet de créer des contacts clients lorsque ceux-ci sont présent dans le fichier FO.csv et de les associer à la ligne de commande prévisionnelle. Dans tous les cas de figure, si le contact existe pour le client il faut le lier à la ligne de commande

  11. Champs a laisser cocher sous peine de rejet du prévisionnel

  12. L’intégration du fichier FO.csv par site émetteur intervient sur le choix de la colonne par laquelle l’identification du client sera effectuée (transformation du N_EDI_EMET en CD_CLIENT).

  13. Unicité des adresses de Livraison : Cocher on ne génère pas l’adresse si il y a une différence. ( Peux provoquer des erreur de livraison si seulement l’adresse de Quai change.

  14. Mise a jour des commentaire des ligne de commande

  15. Utilisé pour créer ou non les articles automatiquement lorsqu’ils ne sont pas identifiables

  16. Recalage de la commande

  17. Supprimer OF en attente

  18. Recalage de la ligne

  19. Utiliser Prix de l AL: cocher mise a jour des les revue de contrat, Si décocher on intègre au prix de notre contrat ( La facturation est rejetée si le prix est différent entre le contrat et le prix du fichier intégrant la commande.

  20. Mise a jour de la ligne de commande si la ligne de commande existe

  21. Permet de supprimer les logs a partir du nombre de jour définie. Uniquement si la tache planifié d’Intégration EDI est active.

  22. Envoi une notification Agora au personnel ayant la compétence paramétré

  23. Permet de définir le nombre de colonne du fichier a intégré PO ( évolue en fonction des modification Airsupply)

  24. Permet de définir le nombre de colonne du fichier a intégré DA ( évolue en fonction des modification Airsupply)

  25. Permet de définir le nombre de colonne du fichier a intégré GN ( évolue en fonction des modification Airsupply).

  26. Permet de définir le nombre de colonne du fichier a intégré FO ( évolue en fonction des modification Airsupply).

  27. .

  28. .

  29. .

  30. .

  31. .

  32. .

  33. .

  34. .

  35. .

  36. .

  37. .

  38. .

  39. .

  40. .

  41. .