Messages EDI normalisés

 

EXPORT de messages

 

Pour tous ces messages le principe adopté est le suivant :

Cegid Orli génère un fichier ASCII qui est ensuite transmis à un traducteur ‎(fourni par un prestataire extérieur).

Ce traducteur prend en charge la transformation du fichier à la norme EDIFACT.

 

Remarques :

• Pour tous les messages en extraction :
  il faut définir le lien entre le code EDI et chaque client « centrale » (onglet Association entité Cegid Orli de TA440).
• Pour les messages ORDRSP et DESADV :
  des formats de fichier prédéfinis existent
• Pour le message PRICAT :
  l’utilisateur peut librement paramétrer la structure du fichier qu’il souhaite générer à partir d’une bibliothèque de données contenant l’ensemble des informations « Article/Produit/EAN » disponibles dans Cegid Orli.

N.B. :
il n’existe pas de format standard, car les échanges d’article se définissent à chaque mise en place entre les 2 partenaires, selon les besoins du client d’une part, et selon les données propres au fournisseur (codes statistiques…) issues de sa base Cegid Orli.

‎ 

IMPORT de messages

 

Le message initialement reçu est à la norme EDIFACT.

Ce message doit impérativement être retraité par un traducteur
‎(fourni par un prestataire extérieur).

Ce traducteur prend en charge le décodage des informations et la transcription de ces dernières sous forme de fichier ASCII.

Le message reformaté peut ensuite être intégré dans Cegid Orli.

Remarque :
un fichier prédéfini existe pour le message ORDERS
ce fichier contient de façon native un maximum d’informations.

‎ 

Notion de partenaire EDI

Le but est de pouvoir définir, pour un client précis (partenaire EDI), le type de message traité et le langage utilisé pour communiquer. Ceci est rendu nécessaire par le fait que les traitements d’intégration de commandes, d’envois d’articles, d’avis d’expédition ou encore d’envois d’accusés de réception sont différents suivant le langage utilisé (champs à envoyer au partenaire EDI différents suivants le langage).

• Il est donc conseillé de définir une provenance spéciale par partenaire EDI,
  ‎ce qui permet de gérer chaque particularité de manière indépendante et étanche.

 

La liaison d’appartenance « partenaire EDI » est gérée dans TA014, via la fonctionnalité 59 : elle permet d’attacher à un partenaire EDI les différents clients qui doivent être traités avec le type de message et le langage du partenaire.

 

exemple : Si vous devez effectuer des échanges EDI avec les GALERIES LAFAYETTE, il conviendra de créer un client «Partenaire» GALERIES LAFAYETTE, tous les clients GAL qui vont réellement passer les commandes devront être rattachés au client partenaire via une liaison de fonctionnalité 59.

 

Le partenaire EDI est ensuite défini de façon précise au niveau de la fonction TA471 (l’utilisateur indique au niveau de cette forme les différents messages traités (fiches produits, commande, accusés de réception, avis d’expédition) et leurs modalités d’échange.

 

TA446 / Recodification données EDI

Cette fonction permet, pour chaque code EDI, et chaque table traduisible (JP044), de relier les valeurs internes "code Cegid Orli" aux valeurs "code externe"

‎ 

Répertoire d’échanges de fichiers

Principe

Les fichiers à intégrer dans Cegid Orli doivent obligatoirement être déposés sur le serveur de base de données sur un répertoire particulier (généralement celui défini dans la variable d’environnement $ODIE)

Pour les fichiers extraits, il existe une possibilité de déposer les fichiers sur un serveur, appelé
‎« routage répertoire » (paramétrage dans TA450 Paramétrage extraction fichier).
‎Cependant, étant donné que le traducteur (ou autre prestataire) doit venir déposer les fichiers sur le serveur de base de données, il est plus simple que le traducteur vienne également les récupérer (un seul pilotage).

 

Répertoire

 

Intégrations :

• Par défaut, les fichiers seront récupérés dans le répertoire défini dans la variable d’environnement $ODIE
• Il est conseillé de créer un sous-répertoire identifiant le partenaire EDI, afin d’isoler les fichiers et faciliter la recherche et le suivi
  (exemple : $ODIE/GL)

 

Extractions :

• Par défaut, les fichiers seront déposés dans le répertoire défini dans la variable d’environnement $ODIS
• Comme pour l’intégration, il est conseillé de créer un sous-répertoire identifiant le partenaire EDI, afin d’isoler les fichiers et faciliter la recherche et le suivi
  (exemple : $ODIS/GL)

‎

 

Étude détaillée des différents messages disponibles

Description succincte des messages en version EDIFACT-EANCOM® 97
‎ (sur la base du dictionnaire de données EDIFACT D 96.A) :

• Message PRICAT pour les informations tarifaires associées aux produits et à leurs caractéristiques techniques
• Message ORDERS pour la commande
• Message ORDRSP pour la réponse à la commande
• Message DESADV pour décrire les conditions de livraison et le contenu des unités livrées

‎ 

Envoi des catalogues de prix (message PRICAT)

1^er Point :

Lien Partenaire EDI / Catalogue EDI

Il faut dans un premier temps définir un catalogue contenant les différents produits devant être envoyés au partenaire EDI (AR072) :

 

• Généralement, PRICAT doit contenir une liste particulière d’articles pour le client EDI, qui n’est pas la collection complète. Il faut donc pouvoir définir une liste d’article pour une liste de client : ceci est géré via la notion de catalogue, qui devient donc OBLIGATOIRE pour gérer le message PRICAT.
• Comme la gestion du catalogue est gérée via un paramètre général (GEST_CATAL_PROD), il peut être difficile de l’activer du jour au lendemain ‎(car impact important sur les prises d’ordres).
• Dans ce cas, vous pouvez l’activer seulement pour un utilisateur dédié, ‎qui sera chargé de lancer l’extraction du message PRICAT.
• Le catalogue utilisé doit être mono division commerciale / mono saison de vente :
  • en effet, comme il n’y a pas de possibilité de sélectionner une division commerciale et une saison de vente lors de l’extraction du PRICAT, le seul moyen est de passer par le catalogue, qui doit donc être mono division et mono saison.
  • S’il était multi, il ne serait pas traité par l’extraction du PRICAT.
• Généralement, le code catalogue devra donc identifier :
  ‎« client EDI » + « Division commerciale » + Saison de vente ».
  
  exemple : GLD0100P avec

GL = Galerie Lafayette, D01 = Division commerciale D01, 00P = Permanente

 

Une fois le catalogue créé, il suffit de l’associer au partenaire EDI concerné.

Ceci est possible au niveau de la fonction TA471.

‎ 

2^ème Point :

Format paramétrable du fichier PRICAT

Afin de s’affranchir le plus possible des langages et des traducteurs, il a été décidé de laisser à l’utilisateur la possibilité de définir lui-même la structure du fichier qu’il souhaite générer.
‎Pour ce faire, il dispose d’une bibliothèque de données recensant les différentes informations susceptibles d’apparaître dans le message PRICAT (informations articles, coloris, statistiques, etc...).

Il n’a alors plus qu’à les positionner comme il le désire en utilisant la fonction TA476.

 

Lors de la constitution du fichier, les règles de gestions suivantes doivent cependant être respectées :

 

• Types d’enregistrement autorisés

Le fichier généré peut contenir les types d’enregistrements suivants :

• Enregistrement « Début de catalogue » (1 seule occurrence)
  Niveau 00
• Enregistrement « Article » (X occurrences)
  Niveau 01
• Enregistrement « Produits » (X occurrences)
  Niveau 02
• Enregistrement « Taille » (1 à 20 occurrences)
  Niveau 03
• Enregistrement « Fin de catalogue » (1 seule occurrence)
  Niveau 04

 

Chaque enregistrement est caractérisé par un niveau (00 à 04) et un sous niveau (de 00 à 99) afin de pouvoir gérer le cas éventuel de plusieurs enregistrements de même niveau.

 

• Structure de l’enregistrement

L’utilisateur peut définir, pour chaque enregistrement, les informations qui le constituent (en appelant une liste de valeur qui lui propose les différentes données disponibles). Pour chaque donnée sélectionnée, il peut renseigner la position de début et de fin de cette dernière, le type de la donnée, le format date éventuel. Il peut également indiquer si la zone est obligatoire lors de la génération du message PRICAT.

Remarque : Afin d’ouvrir au maximum le paramétrage, l’utilisateur peut également saisir du texte libre.
‎

3^ème Point :

Génération du message PRICAT

C’est le module standard d’extraction de fichiers XC300 qui est utilisé.

 

Le principe retenu consiste à alimenter une table donnant la liste des enregistrements à générer dans l’interface et à générer le fichier séquentiel correspondant au message PRICAT à partir de cette table.

Afin de ne pas modifier l’applicatif Cegid Orli, cette alimentation est obtenue par la création de TRIGGER SUR TABLE permettant de lister les entités à prendre en compte au moment où l’interface est lancée (triggers déclenchés lors de chaque Création/Maintenance/Suppression concernant un article, un produit ou un EAN appartenant au catalogue EDI).

 

 

Niveau d’ANNULE-REMPLACE

 

Le message PRICAT fonctionne en ANNULE–REMPLACE.

Le mode d’ANNULE-REMPLACE est paramétrable par partenaire EDI.

Il peut ainsi être défini au niveau ARTICLE ou PRODUIT.

 

• ANNULE-REMPLACE au niveau ARTICLE

  Dès qu’un coloris d’un article est créé, modifié ou supprimé, l’article est automatiquement renvoyé. Par contre, tous les coloris de l’article sont présents dans le fichier généré (qu’ils aient été modifiés ou non)

   

• ANNULE-REMPLACE au niveau PRODUIT

  Dès qu’un coloris d’un article est créé, modifié ou supprimé, l’article est automatiquement renvoyé au partenaire. Par contre, seul le coloris crée, modifié ou supprimé est présent dans le fichier généré.

   

  Envoi des Création/Modification/Suppression

  L’utilisateur peut définir, par partenaire, les types d’actions susceptibles de déclencher l’envoi d’un article ou d’un produit.

  Quatre possibilités sont offertes :

  Envoi uniquement des entités (articles ou produits) créées

  Envoi des entités créées ou modifiées

  Envoi des entités créées ou supprimées

  Envoi des entités créées, modifiées ou supprimées

  
  ‎Absence d’une zone obligatoire

   

  En cas, d’absence d’une zone obligatoire, la fonction réagit de la façon suivante :

   

• ANNULE-REMPLACE au niveau ARTICLE

  Si la zone manquante concerne un enregistrement de niveau « ARTICLE », l’article concerné n’est pas inséré dans le fichier généré.

  Par contre, si la zone manquante concerne un enregistrement de niveau « PRODUIT », l’article concerné est tout de même envoyé au partenaire EDI. En fait, tous les autres coloris sont insérés dans le fichier. Le coloris manquant est transféré lors du prochain envoi du PRICAT
  ‎(sous réserve que la donnée obligatoire ait été renseignée par l’utilisateur).

   

• ANNULE-REMPLACE au niveau PRODUIT

Toute zone manquante concernant un enregistrement de niveau ARTICLE ou PRODUIT bloque l’envoi du produit concerné.

 

Réception des commandes EDI (message ORDERS)

Le fonctionnement général du module peut se résumer en 7 points :

 

1) Récupération des fichiers séquentiels :

Les commandes doivent être présentes dans un fichier séquentiel appelé orders.asc

Ce fichier est un fichier ASCII dont la structure a été prédéfinie. Il n’est pas à la norme EDIFACT.

Il doit être posé dans un répertoire paramétrable dans notre applicatif.

N.B. :
aucune automatisation n’est prévue pour aller récupérer le fichier déposé sur le PC par le traducteur et le positionner sur le répertoire UNIX.

 

2) Lancement de l’intégration :

Le lancement de l’intégration s’effectue via XC20B.

Cette fonction assure la lecture du fichier orders.asc et l’alimentation des tables réceptacles qui serviront ensuite de base à la création effective des commandes.

 

 

3) Contrôle de cohérence des différentes commandes :

À ce niveau, l’ensemble des contrôles effectués dans Cegid Orli lors de la saisie des commandes est appliqué aux commandes à intégrer.

‎ 

 

4) Intégration des commandes :

Seules les commandes qui ont passé avec succès tous les contrôles cités ci-dessus peuvent être intégrées dans le portefeuille de commandes. Les commandes pour lesquelles des anomalies ont été détectées peuvent être maintenues via la fonction CD360W02.

Une fois l’intégration terminée, plusieurs états de contrôles sont édités :

• Liste des anomalies au niveau de la lecture du fichier
• Liste totale des commandes reçues
• Liste des commandes traitées et intégrées
• Liste des commandes traitées et intégrées avec warnings
• Liste des commandes traitées et rejetées en anomalie
• Liste des commandes traitées et définitivement rejetées en anomalie

 

5) Historisation des commandes :

Toute commande EDI traitée est automatiquement historisée. Ce système permet de conserver l’état initial de la commande reçue afin d’avoir l’historique des quantités initialement commandées par le partenaire, puisque l’utilisateur peut supprimer certaines tailles commandées via la fonction de maintenance des commandes EDI (CD360W02).

 

6) Maintenance des commandes EDI 

La maintenance des commandes EDI rejetées est assurée par la forme CD360W02.

Les différentes actions autorisées doivent être définies lors de l’accord d’inter-change. Elles sont alors renseignées au niveau de la forme TA471 : GESTION DES PARTENAIRES EDI

Selon le paramétrage défini avec le partenaire en TA471, l’utilisateur peut effectuer les actions suivantes:

• Supprimer la commande
• Modifier les délais de l'entête de commande
• Supprimer totalement une ligne de commande
• Supprimer partiellement une ligne de commande
• Modifier les délais de la ligne de commande
• Modifier les tarifs de la ligne de commande
• Modifier les natures et types de commande

 

7) Relance de l’intégration des commandes EDI après maintenance :

La relance des commandes EDI maintenues est prise en charge par la fonction CD620.

 

‎ 

SCHÉMA FONCTIONNEL DU MODULE

 

 

‎PARAMÉTRAGE AVANT INTÉGRATION

Codification du fournisseur

Selon les partenaires EDI, l’identification du fournisseur peut se faire par l’intermédiaire du Code International Entreprise (GENCOD), du No de TVA ou du No de SIRET.

 

Codification des clients

Selon les partenaires EDI, l’identification des clients peut se faire par l’intermédiaire du code international entreprise (GENCOD), du No de TVA, du No de SIRET ou d’une référence interne.

 

Codification des produits

Dans le cadre des échanges EDI, les articles reçus par EDI correspondent en général aux codifications envoyées aux partenaires par l’intermédiaire du message PRICAT.

Cependant, ces messages n’étant pas forcément gérés, il est impératif de savoir comment vont s’effectuer les correspondances ARTICLE entre Cegid Orli et les partenaires EDI

 

Trois cas sont à envisager :

1. Le partenaire accepte de récupérer un fichier contenant les références Article Cegid Orli (message PRICAT). Dans ce cas, la récupération des articles ne pose aucun problème (car les références reçues sont les codifications Cegid Orli).
2. Le partenaire envoie ses propres codifications EAN. Dans ce cas, il convient de saisir tous les GENCOD du partenaire dans notre applicatif (fonction CA001).
3. Le partenaire envoie ses propres références (non EAN). Dans ce cas, il convient de saisir les toutes les références du partenaire dans notre applicatif (fonction CL005).

 

‎ 

Accusés de réception des commandes EDI (message ORDRSP)

Dans le cadre des échanges de commandes via EDI, il se peut que le partenaire EDI demande la génération d’un accusé de réception pour les différentes commandes échangées. La nécessité de générer un accusé de réception est gérée par la fonction TA471 qui décrit les différentes modalités d’échange avec les différents partenaires EDI.

Pour la génération des accusés de réception, le module standard d’extraction de fichiers XC300 est utilisé.

 

 

Le principe adopté est le suivant :

 

Il faut en premier lieu mettre en place un trigger sur la table des entêtes de commande et sur la table d’historique des commandes EDI.

La mise en place de ce trigger doit être effectuée par Cegid. Elle conditionne l’utilisation des passerelles assurant la génération des accusés de réception. Ce trigger se déclenche lors de chaque création d’un entête de commande ou lors de la mise à jour du flag annulation en entête d’historique de commande (cas d’une commande rejetée pour laquelle un accusé de réception négatif doit être généré).

 

Le fichier généré s’appelle

ordrsp.asc.<No de demande>
‎

Ce fichier est placé dans un répertoire UNIX paramétrable. La récupération de ce fichier et la mise à disposition de ce dernier dans la boite aux lettres du partenaire est à la charge du client.

‎ 

PARAMÉTRAGE AVANT EXTRACTION

L’utilisateur doit indiquer, pour chaque partenaire, au niveau de TA471,
‎les types d’accusés de réceptions qui doivent être générés.

 

8 types d’accusés sont disponibles : 

 

Accusé Positif COMPLET 

Cas d’une commande acceptée sans aucune modification.

 

Accusé Positif avec MODIFICATION ENTÊTE  

Cas d’une commande acceptée avec modification de l’entête.

 

Accusé Positif avec MODIFICATION LIGNE

Cas d’une commande acceptée avec modification des lignes de commande (modification des délais ou des tarifs).

 

 

Accusé Positif PARTIEL

Cas d’une commande acceptée avec suppression de certaines lignes de commande.

 

Accusé Positif PARTIEL AVEC MODIFICATION
‎(Rejet de certaines lignes + Modification délais entête ou ligne).

Cas d’une commande acceptée partiellement avec suppression de certaines lignes et modifications de délais au niveau entête ou lignes.

 

Accusé Négatif (REJET ENTÊTE uniquement)

Cas d’une commande rejetée avec un motif de rejet définie au niveau de l’entête de commande.

 

Accusé Négatif (REJET LIGNE uniquement).

Cas d’une commande rejetée avec un motif de rejet définie au niveau lignes de commande.

 

Accusé Négatif (REJET ENTÊTE + LIGNE).

Cas d’une commande rejetée avec un motif de rejet définie au niveau lignes et entête de commande.

‎ 

Avis d’expédition des commandes EDI (message DESADV)

Dans le cadre des échanges de commandes via EDI, il se peut que le partenaire EDI demande la génération d’un fichier d’avis d’expédition pour les différentes commandes échangées.
‎La nécessité de générer un fichier des avis d’expédition est gérée par TA471 qui décrit les différentes modalités d’échange avec les différents partenaires EDI.

Pour la génération des avis d’expédition, le module standard d’extraction de fichiers XC300 est utilisé.

Le principe adopté est le suivant :

En fait, il faut en premier lieu mettre en place un trigger sur la table des lignes de BP/BE/Facture. La mise en place de ce trigger doit être effectuée par Cegid. Elle conditionne l’utilisation des passerelles assurant la génération des avis d’expédition.

Ce trigger se déclenche lors de chaque maintenance d’une ligne de BP/BE/Pièce.

Il teste la zone No de bon d’expédition.

Si cette dernière est modifiée et est différente de « . » (on vient de créer le bon d’expédition) et si la commande concernée est de type EDI, il insère un enregistrement dans la table XC_FIC (table standard utilisée lors des extractions de données). Cette table sert ensuite de base à la génération du fichier contenant les avis d’expédition.

 

Le fichier généré s’appelle :

desadv.asc.<No de demande> ou desadv.<No de demande>.asc

(codification paramétrable au niveau de la fonction TA471).

Ce fichier est placé dans un répertoire UNIX paramétrable. La récupération de ce fichier et la mise à disposition de ce dernier dans la boite aux lettres du partenaire est à la charge du client.

 

 

PARAMÉTRAGE AVANT EXTRACTION

L’utilisateur doit indiquer, pour chaque partenaire, au niveau de la fonction TA471,‎ le format du fichier d’avis d’expédition qui doit être généré.

Actuellement, 3 formats différents sont disponibles :

• Un fichier DESADV sans détail du colisage
• Un fichier DESADV avec détail du colisage
• Un fichier DESADV mixte
  (synthèse des deux)

 

 

Synthèse des messages

N.B. : Les messages d’EXPORT sont présentés sur fond gris, ‎
par opposition aux messages d’IMPORT sur fond blanc (avec le cas de PORDERS qui est bidirectionnel)

Notes techniques

 

les triggers installés sont référencés dans la table sys.dba_triggers

 

 

table XC_FIC

 

 

un trigger est créé dans le noyau ORACLE à l’aide d’un fichier .trg stocké dans $TRG,

starté à l’installation, avec le code PL/SQL du type :

 

le code source de création des triggers associés dans la documentation de chaque message.