I.1. Définition des messages EDI - ERP Silog

Owned by Hugues Dubuisson
Last updated: Aug 29, 2024
23 min read

Sommaire

1. Introduction

Dans le langage EDI, un document commercial tel qu’un bon de commande, une facture ou un avis préalable à l’expédition constitue un « message ».

Il est composé de :

  • Segments : Un segment dans un jeu de transaction EDI est un groupe d’éléments de données similaires (les lignes de commandes par exemple ou les entêtes de commandes).

  • Eléments de données : Informations individuelles présentes dans le document, les données comme la ville, le pays, la référence, la quantité ou le prix par exemple. Ces éléments sont regroupés en segments.

Chaque élément de données d’un jeu de transaction est défini dans la norme EDI par le type de données qu’il représente. Par exemple, il faut distinguer les données numériques, le texte ou les dates …

 Un message EDI contient donc des segments qui contiennent des éléments de données dont le formatage dépend de la règle d’une norme EDI normalisée et commune entre deux partenaires.

 Il contient :

  • La description de la structure des messages (Segments),

  • Le mappage des données sources et destinations (Eléments de données),

  • Les traitements SQL à exécuter avant ou après le traitement du fichier informatique pour mettre à jour ou filtrer les données avant la tâche d’intégration ou d’émission,

  • La mise en place de contrôles spécifiques personnalisés bloquants ou non dont la trace sera visible dans le rapport de fin des traitements.

2. L’application

Le mode Liste présente l’ensemble des messages configurés dans Silog avec le type de message, « I » pour intégration et « E » pour émission, puis une description.

Mode Liste de l’application « Définition des messages »

Le mode Page présente le détail d’un message.

Mode Page de l’application « Définition des messages »

2.1. L’onglet Général

Masque des clés

  • Code Message :  Saisir un code message. Saisir le nom du message EDI, exemple ORDRERS, DESADEV…

 

L’onglet « Général ».

  • Type de Message : Sélectionner le type de message EDI concerné, « Intégration » ou « Emission ».

  • Type de fichier : Sélectionner le type de fichier concerné parmi les choix suivants : « CSV », « FIXE », « XML » ou « XLS ».

  • Entête XML : Si le fichier émis est un fichier au format XML, il est possible de saisir dans cette zone une ligne à insérer au début du fichier, comme par exemple la version de XML :

  • Description : Saisir une description pour le message.

  • Séparateur de champ : Saisir le caractère séparateur de champ.

  • Marqueur début de ligne : Si un marqueur de début de ligne est présent dans le message, saisir ce marqueur.

  • Marqueur fin de ligne : Si un marqueur de fin de ligne est présent dans le message, saisir ce marqueur.

  •  Format « Dates » :

Format entrée des dates : Saisir le format de date contenu dans le message à intégrer (exemple : JJ/MM/AAAA, JJ/MM/AA…).

Format de sortie des dates : Saisir le format de date attendu en emission ou en intégration (exemple : JJ/MM/AAAA, JJ/MM/AA…).

  •  Format Numérique » :

Séparateur millier : Saisir le séparateur de millier si nécessaire.

Séparateur décimal : Saisir le séparateur de décimal, si cette zone n’est pas renseignée, les paramètres systèmes sont utilisés.

Coefficient : Si les numériques doivent subir une conversion, saisir le coefficient dans cette zone.

  •  Le format des nombres numériques et entiers :

Le format des nombres dans le module EDI est réalisé par une fonction SQL : « Dbo.to_char ».

Elle accepte 2 paramètres :

  • Le nombre,

  • Le format.

Le nombre peut être un entier ou un numérique. Le format est la chaine de caractère qui définit la forme que l’on veut obtenir pour le nombre.

Exemples d’utilisation, pour le nombre suivant : 1234.567

Format        Résultat #####.##     "1234.57" 00000.00      "01234.57" #####         "1235" # ###,00     "1 234,57" Vide        "1234.567"

Le zéro permet de forcer l’affichage de zéros non significatifs.

Le # permet de préciser le nombre de chiffres après la virgule.

Si le format est vide, on affiche le strict nécessaire pour ne pas modifier la valeur du nombre.

Il est possible d’indiquer un séparateur de milliers.

Il est possible de forcer le séparateur de décimales.

 Cartouche « Chaine » (Emission seulement) :

  • Majuscule : Utilisé en émission pour forcer l’écriture des chaines en majuscule.

 Nom du fichier (SQL) (Emission seulement) :

  • Fichier : Nom du fichier émis. Si la structure du nom du fichier EDI émis utilisé par défaut ne convient pas, cette zone permet de renseigner la syntaxe SQL désirée, elle remplace, si renseignée, la valeur par défaut présentée dans la zone suivante.

  • Valeur par défaut : Syntaxe SQL utilisée par défaut pour construire le nom du fichier. Zone Non modifiable.

Par défaut, le nom du fichier en émission est structuré de la façon suivante.

CodeMessage+DateSysteme+’.’+TypeFichier ce qui se traduit en langage SQL par : EDI_MESSAGEE.CodeMessage+'_'+dbo.to_char(getdate(),'yyyymmddhhnnss')+'.'+EDI_MESSAGEE.TypeFichier

 

Requête présélection (Emission seulement) :

Cette zone est facultative, elle est utilisée pour les messages de type « émission », elle permet de saisir la requête de présélection des données si nécessaire. Si la tâche d’émission est lancée manuellement depuis l’application « Définition des tâches », un listage de présélection des données à traiter sera présenté à l’utilisateur parmi les enregistrements de cette requête. Par défaut tous les enregistrements de la requête seront présélectionnés.

Pour un filtre sur les codes familles articles la requête peut être la suivante :

Le listage de présélection suivant sera présenté lors de l’exécution de la tâche manuellement. Le résultat de la sélection est enregistré dans une table de sélection dont le nom est dans le Tag #TABLE_SELECTION.

2.2. L’onglet « Structure ».

C’est dans cet onglet que la structure du message doit être déclarée.

2.2.1. Les blocs SQL

Le traitement d’un message EDI est effectué en plusieurs étapes, chaque étape est basée sur une table de données spécifique. Des points d’entrées permettent d’intervenir sur le contenu de ces différentes tables, il s’agit de blocs de champs textes saisissables en langage SQL.

 Ces blocs permettent par exemples, de traiter les données ou déclarer des variables avant qu’elles ne soient transmises à l’étape suivante d’intégration ou d’émission.

 Ils sont de différents types :

1 : Blocs sql avant permet d’alimenter toutes les tables segments (uniquement pour les messages d’intégration).

2 : Bloc sql après s’exécute aprés avoir alimenté les tables de données.

3 : Condition segment (en émission seulement) pour mettre une condition d’alimentation du segment en cours.

4 : « Where table source » ou « Where table Silog » pour appliquer un filtre sur les données à traiter.

 Il est nécessaire de comprendre comment le traitement d’exécution du message EDI procède pour savoir où interviennent les différents blocs SQL dans l’intégration ou l’émission EDI.

2.2.1.1.  Exemple 1 : Prenons l’exemple d’un message simple de type intégration suivant :

Ce message est  composé de deux segments : « ROOT » (la racine, segment toujours présent quel que soit le message) et « ART » qui contient les données « Article », dans l’exemple.

 Remarque : Le segment « ROOT » est toujours présent, il est le père de tous les segments. Les variables déclarées dans ce segment sont héritées dans toute la déscendance.

En intégration, l’origine des données est toujours un fichier texte dans l’un des format suivant :

  • format xml,

  • longueur fixe,

  • csv,

  • ou xls.

 Schéma du processus d’intégration :

Les tags utilisables en intégration :

Sql avant table segment : #TABLE_SOURCE

Sql avant message : #TABLE_SOURCE

Sql après message : #TABLE_SOURCE

 

2.2.1.2. Exemple 2 : Prenons l’exemple d’un message simple de type émission en CSV suivant

Schéma du processus d’émission :

Les tags utilisables en émission :

Sql avant message : #TABLE_SELECTION et #TABLE_SOURCE

Sql après message : #TABLE_SELECTION et #TABLE_SOURCE

Sql avant segment : #TABLE_SELECTION et #TABLE_SOURCE

Sql après segment : #TABLE_SELECTION et #TABLE_SOURCE 

Remarque :

Il est possible d'utiliser des tables fixes plutôt que les table # dans les taches d’intégration mais ces tables doivent à minima contenir les champs suivants

NoEnreg NUMERIC(19,0)

IdEvent NUMERIC(19,0)

Filename VARCHAR(500)

Flag SMALLINT

Suppression SMALLINT

Lien VARCHAR(MAX)

DesactiverAction SMALLINT

Dans ce cas, seuls les champs ayant exactement le même nom que les tables standards seront mappées automatiquement.

Pour les autres champs, il faudra utiliser les fonctions « e_MEC », « e_MEN ».... dans les fichiers évènements (voir chapitre « Les instructions permises dans les fichiers évènements : »).

 

2.2.1.3. Bloc sql avant d’alimenter les tables « segment » (uniquement en intégration)

Lorsque la tâche d’intégration est exécutée, le fichier en entrée est inséré dans une table temporaire pour permettre d’être manipulé en langage SQL.

 Le nom de cette table temporaire est contenu dans le tag « #TABLE_SOURCE ». La table #TABLE_SOURCE est utilisée dans le cadre d'un message d'import : elle contient le contenu brut de l'import du fichier avant bascule dans les tables liés au segment à  raison d'un enregistrement par ligne de fichier.

Le champ Data contient la globalité de la ligne du fichier.

=>On intervient parfois sur la table source pour supprimer la première ligne qui contient les entête de colonne

 Le principe d’alimentation de cette table est le suivant :

  •  Pour tous les fichiers non ‘XML’, chaque ligne du fichier source est enregistrée dans la colonne « DATA » de cette table. La table ne contient qu'un seul enregistrement => le champ data contient tout le fichier XML.

Par exemple :

Pour le fichier de type csv dont le nom est « Article1.csv » suivant :

Exemple 1 :

La table source est alimentée de la façon suivante :

Chaque ligne du fichier fait partie d’un enregistrement de la table, y compris la ligne d’entête si elle existe, ces lignes sont contenues dans la colonne « Data ».

Exemple 2 sans ligne d’entête  :

Le fichier :

La table : Même principe.

Chacune de ces lignes est identifiée par un numéro d’enregistrement « NoEnreg » à l’intérieur d’un identifiant d’évènement « IdEvent ».

La colonne « Filename » permet de mémoriser le nom du fichier en entrée, plusieurs fichiers de même structure peuvent en effet etre traités dans le message, cette colonne permet donc de faire le lien entre les fichiers sources et les données.

La colonne « Flag » n’est pas utilisée par les traitements réalisés par Silog.

 

  • Pour les fichiers de type ‘XML’,

C’est le contenu entier du fichier qui alimente le champ « Data », une ligne par fichier xml si plusieurs fichiers sont traités. Une fois que ce principe est assimilé, alors il devient plus aisé de manipuler les données avant de les traiter.

Notre exemple contient en ligne 1 le contenu de la ligne d’entête du fichier CSV.

Dans ce bloc SQL, il est donc possible de supprimer les lignes qui contiennent le libelle « CodeArticle » dans le champ « Data ».

 = > Delete from #TABLE_SOURCE where Data like « CodeArticle% » 

Ce qui permet de nettoyer la table source avant qu’elle ne soit traitée pour alimenter les tables segments.

2.2.1.4. Bloc sql avant (Intégration et émission)

Avant de saisir des données dans ce bloc, il est important d’avoir défini la structure des segments du message.

Une fois ces segments définis, le système va créer une table par segment.

Dans l’exemple simple ci-dessous : 

Le segment « ART » donne naissance à la table « EDI_IMP_ART_ART » (‘EDI_’+CodeMessage+’_’+alias Segment). Cette table s’alimente lors de l’exécution de la tâche associée.

Cette table contient une colonne par champ associé au segment. Dans l’exemple, « CodeArticle », « CodeFamille » et « Unité ».

Chacune de ces lignes est identifiée par un numéro d’enregistrement « NoEnreg » à l’intérieur d’un identifiant d’évènement « IdEvent ».

La colonne « Filename » permet de mémoriser le nom du fichier en entrée, plusieurs fichiers de même structure peuvent en effet être traités dans le message, cette colonne permet donc de faire le lien entre les fichiers sources et les données.

Ce bloc intervient sur les tables segments, il permet de jouer sur le contenu de ces tables et du mappage.

Par exemple pour déclarer des variables, affecter des valeurs à ces variables et les utiliser dans le mappage des données avec Silog.

Dans l’exemple ci-dessous, la variable ‘@DateMessage’ prend la valeur de la date système, cette valeur est utilisée dans certains champs dates du segment pour initialiser une valeur par défaut lorsque cette date n’est pas renseignée.

 

2.2.1.5. Bloc sql après (Intégration et Emission)

Chaque segment contient le mappage des données avec les tables Silog (voir : structure des segments du message).

Avant d’intégrer les données en mode Macro ou d’exporter les données (émission), le système va créer des tables temporaires de même structure que les tables de destination Silog en intégration ou de même structure que le fichier exporté en émission (#TABLE_SOURCE). Chacune de ces tables contient les données.

 Ce bloc SQL permet d’exécuter un traitement SQL après avoir alimenté la table source du ficher en émission ou la table de donnée source de la macro en intégration. Il peut être utilisé pour mettre à jour les données des tables de données avant émission ou intégration.

Par exemple, en émission :

Exemple : Si on souhaite créer un fichier CSV avec un en-tête de colonne, il faut insérer la ligne de l’en-tête dans la table source du fichier.

En émission, le TAG permettant d’obtenir le nom de la table source du fichier est #TABLE_SOURCE. 

Exemples :

2.2.2. Segments du message

22.2.1. Introduction

Cette partie permet de décrire la structure du message en segments. Cette description est arborescente, elle est multi-niveau. A l’issue de cette description, une table par segment sera automatiquement créée.

Elle nécessite de se documenter sur la structure du message à décrire et de bien connaitre la structure des données de Silog pour mapper les données du message avec les données de Silog (tables et champs de destination).

Pour les messages d’intégration, la source des données est un fichier.

  • Exemple 1, cas d’un CSV simple sans segment de rupture - fichier « ARTICLE ».

Il suffit de créer un seul segment, exemple « ART » qui contient l’ensemble des données du fichier source :

Exemple : 

  • Exemple 2, cas d’un CSV avec deux segments de rupture mononiveau : Dans l’exemple ci-dessous, le fichier source contient à la fois les données « ARTICLE » et « FAMILLE ». 

La colonne 1 contient la donnée qui permet d’identifier le segment.

« ART » pour les données « Article ».

« FAM » pour les données « Famille ».

 Il faut donc créer deux segments « ART » et « FAM » par exemple et ajouter pour chaque entité « Famille » ou « Article » le champ qui contient la valeur de rupture, dans l’exemple ci-dessous, « Typeligne » en premier dans la description.  

  • Exemple 3, cas d’un CSV avec plusieurs segments en multiniveau : Le principe est similaire. 

Pour les messages d’émission, la source des données est une table ou une vue Silog.

Il n’y a pas de zones de rupture. La zone de rupture doit être déclarée comme un champ avec en valeur par défaut, la valeur de rupture.

Exemple : 

Pour cet exemple, le fichier émis est de ce type : 

22.2.2. Création/Modification/Duplication et consultation des segments

La création de l’arborescence est effectuée à l’aide du menu contextuel en mode création ou modification. 

Cas du XML pour un message en emission :

Nom : Nom du segment

Parent : Nom du segment parent.

Alias : Alias du segment, c’est ce libellé qui est utilisé dans les traitements.

Table Silog : En intégration, il s’agit de la table destinatrice des données du segment.

Alias TableSilog : Alias de la table Silog utilisé dans les traitements.

Suffixe balise XML : Cette zone n’est présente qu’en émission pour les messages de type XML. Elle permet de saisir le suffixe de la balise du segmant, ce dernier sera ajouté à la balise ouvrante du segment.

Afficher si vide : Réservé aux fichiers émis de type XML Pour que le segment soit affiché dans le message émis même s’il ne contient aucune donnée.

Exporter (uniquement en emission) : Cette zone permet de définir, si le segment doit être exporté dans le fichier, par défaut, cette zone est cochée.

Export (uniquement en emission) :

Lorsque ces zones sont alimentées, cela signifie que l’émission générera un fichier par segment au lieu d’un fichier global pour tous les segments.

Ce cartouche “Export” est dédié à la création d’un fichier d’émission pour le segment en cours.

Nom du Fichier : Nom du fichier à générer. Si le nom n’est pas renseigné, c’est le nom du fichier du segment père qui sera utilisé sinon c’est le nom du fichier renseigné dans l’onglet « Général » du message. Il est possible de saisir un nom en dure, dans ce cas il faut l’encadrer par des quotes.

Il est également possible de saisir une syntaxe SQL.

Champ SILOG à mettre à jour =>  Zone de la table silog à mettre à jour si nécessaire.

Dans cet exemple le fichier ‘article01.csv’ est créé et la variable « VarAlphaUtil » de la table « Article » est mise a jour pour les codes articles exportés.

 Condition segment (uniquement en emission): Ce bloc est lié aux messages de type « Emission », il permet de saisir une condition d’alimentation sur le segment en cours. par exemple, pour ne traiter que les Articles de la famille « ACI ».

 Exemple :

Where table SOURCE : Ce bloc SQL permet de saisir un filtre sur les données des tables segments. Ce filtre permet d’alimenter les tables de données avant l’intégration ou l’emission. Par exemple, dans le cas d’un fichier CSV, si la premiere ligne du fichier est une ligne d’entête qui contient le nom des colonnes, nous avons vu précédemment qu’il est possible de supprimer ces lignes de la table source. Nous voyons donc ici qu’il existe une autre méthode qui consiste à filtrer les données à prendre en compte pour exclure ces lignes.

Dans cet exemple, dans la table segment, la ligne d’entête des colonnes a été traitée comme s’il s’agissait d’une donnée, la colonne « CodeArticle » contient donc parmi ces valeurs « CodeArticle ». Pour exclure ces lignes du traitement, la syntaxe suivante suffit :

Exemple 

Autre exemple : Si une requête de sélection a été saisie dans le message d’émission, il faut filtrer les données à traiter du segment par rapport au contenu de la sélection, le tag correspondant au nom de la table de sélection est #TABLE_SELECTION.

Dans cet exemple, la requête de sélection est basée sur la liste des codes familles. Pour ne traiter que les articles qui appartiennent aux codes familles qui seront sélectionnés, la syntaxe de la clause where peut être la suivante

Bloc SQL Avant /Après : Le principe est similaire au bloc SQL avant/aprés de l’onglet structure, mais ne concerne que le segment en cours et ses fils. Il est possible de saisir ici la syntaxe SQL du traitement désiré.

Exemple :

Le bouton  permet d’importer la variable associée à un champ à l’endroit d’un bloc sql où se trouve le curseur. Le listage des champs de toutes les tables Silog associées à des segments du message en cours apparaît, dans l’exemple suivant les tables « ARTICLE » et « FAMRUB ».

Il suffit de sélectionner le champ concerné, puis valider, pour que la variable concernée soit insérée :

Exemple :

Supprimer segment : Cette action supprime le segment sélectionné.

Dupliquer segment : Cette action duplique le segment sélectionné. Un numéro de compteur est apposé en suffixe pour codifier le segment dupliqué.

Consulter le détail du segment : Pour consulter le détail du segment sélectionné.

Ligne en rouge : Si l’alias du segment n’est pas unique

Ligne en orange : Si un bloc SQL avant ou après existe pour le segment.

Ligne en gras : Si un champ du segment est une clé. 

Ce listage permet d’insérer en masse les champs de la table Silog du segment dans la zone « Champs du segment ».

Il faut sélectionner les champs a importer et valider. Les champs sélectionnés sont associés au segment :

22.2.3. Champs du segment

La description des champs appartenant à un segment s’effectue dans la partie « Champs du segment ». Il faut être en mode « Création ou Modification ».

Cette description permet d’affecter chaque élément de données du fichier source (séparé par un caractère séparateur déclaré dans la description) au segment en cours dans le but de créer les tables segments. Il est donc important de saisir les champs dans l’ordre où ils apparaissent dans le fichier d’intégration ou dans l’ordre où ils apparaitront dans le fichier en émission, la séquence doit être respectée.

22.2.3.1. Les champs 

Le menu contextuel permet d’insérer, de modifier ou de supprimer des champs dans le segment sélectionné.

Emission CSV :

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Intégration CSV :

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Emission Fixe :

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Intégration Fixe :

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Emission XLS :

Intégration XLS :

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Emission XML :

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Intégration XML :

Nom : Nom du champ.

Code EDIFACT : Saisir le code EDIFACT s’il est connu.

Type de champ : Sélectionner le type de champ concerné VARCHAR, INT, NUMERIC ou DATE.

Libellé : Libellé du champ à saisir.

Longueur pour contrôle (en intégration uniquement) : Pour contrôler la longueur d’une donnée, et vérifier par exemple qu’un code article ne dépasse pas 30 caractères. C’est un contrôle bloquant, on le retrouve dans le rapport de traitement final.

Longueur fixe : uniquement pour les fichier de type Fixe, permet de définir la longueur du champ.

Suffixe Balise XML : Uniquement en émission, pour ajouter un suffixe à la balise XML.

Afficher si vide : Uniquement en émission, pour ne pas afficher la balise XML s’il n’y a pas de données.

Valeur rupture segment (en intégration uniquement) : Cette zone permet de saisir la valeur du segment qui permet de faire la rupture avec le type de données précédent.

Par exemple ci-dessous, le fichier contient le type de données « Article » et « Famille », la premiere ligne de chaque entité est consacrée à la zone de rupture.

 Exemple de fichiers : 

La traduction de cette structure pour les articles :

 

 

 

 

Et pour les familles :

Séparateur champ : Saisir le caractère permettant de séparer deux champs différents.

Clé : Si la données est une clé.

Obligatoire : Si la données est obligatoire, cocher cette option.

Valeur par défaut : Valeur par défaut à saisir. Si la zone n’est pas alimentée, alors elle prend la valeur saisie ici.

Exemple de valeur fixe :

Exemple d’utilisation d’une variable déclarée et initialisée dans un bloc SQL.

Champ SILOG : Nom du champ correspondant dans la table Silog. Un listage permet d’importer le champ parmi les champs de la table associés au segment.

Formule associée au champ : Formule du champ a utiliser dans les blocs SQL. Non modifiable.

Bloc SQL Avant /Aprés: Le principe est similaire au bloc SQL avant/aprés de l’onglet structure, il ne concerne que le segment en cours et le champ en cours. Il est possible de saisir ici la syntaxe SQL du traitement désiré.

Le bouton  “Importer champ SILOG” permet d’importer la variable associée à un champ dans un blog SQL à l’endroit où se trouve le curseur. Le listage des champs de toutes les tables Silog associées à des segments du message en cours apparaît, dans l’exemple suivant les tables « ARTICLE » et « FAMRUB ».

Il suffit de sélectionner le champ concerné, pour que la variable associée soit insérée :

Exemple :

22.2.3.2. La légende

Ligne en rouge : Longueur fixe non définie.

Ligne en orange : Destination, ou bloc SQL avant ou SQL après non vide renseigné.

Ligne en gras : Le champ est une clé.

 

22.2.4. Champs bloqués du segment :

Ces zones sont les champs supplémentaires des tables nécessaires aux traitements. Il ne s’agit pas de zones appartenant au message EDI.

22.2.4.1. Les champs

NoEnreg : Numéro de l’enregistrement

IdEvent : Numéro de l’événement d’intégration ou d’émission.

Filname : Non du fichier source

Flag : Zone non gérée.

Aucun ajout ou suppression n’est autorisé. Seule la modification ou la consultation est permise.

Par défaut, il n’est pas nécessaire de modifier ces zones.

Modifier ces zones si les tables de données ne sont pas les tables gérées par le traitement en standard.

Exemple :

22.2.4.2. La légende

Ligne en rouge : Longueur fixe non définie.

Ligne en orange : Destination, ou bloc SQL avant ou SQL après non vide renseigné.

Ligne en gras : Le champ est une clé.

2.3. L’onglet « Contrôle».

Cet onglet permet de lister les contrôles de données personnalisés mis en place.

En mode création ou modification, le menu contextuel permet d’Ajouter/Modifier/Supprimer des contrôles.

Exemple : Pour tester la longueur du code article dans la table source et afficher dans le rapport de traitement les codes article dont la longueur dépasse 4 caractères. 

Le bouton « Importer champ Silog » permet de sélectionner un champ d’une table Silog  dans un listage et de l’insérer à l’endroit où se trouve le curseur (Il s’agit des champs appartenant aux tables enregistrées dans la structure du message).

Le type de message permet de rendre bloquant le contrôle, cela signifie que le traitement du message ne se fera pas si une erreur est détectée.

L’erreur est visible dans le journal (log).

Autres exemples :

Pour ne pas lancer le traitement d’intégration des commandes si un code client n’existe pas dans la base de données. 

Pour ne pas lancer le traitement d’intégration des commandes si un code article n’existe pas dans la base de données. 

2.4. L’onglet « Recherche ».

Cet onglet permet de rechercher du texte ou une partie de texte dans tous les éléments du message.

Saisir la chaine de caractère recherchée dans la zone de saisie puis faire « Tabulation » ou « Entrée ».

Le texte est recherché dans tout le message :

Message : Dans tous les blocs SQL avant et après les segments du message.

Segment : Dans  les segments.

Champs : Dans les champs.

Contrôles : Dans les contrôles.

2.5. Les traitements

2.5.1. Initialiser la structure :

Cette option permet d’initialiser la structure du message EDI en cours à partir d’un fichier de paramétrage d’extension «.ini » de l’ancienne version de l’EDI Silog.

Exemple de fichier :

Avant de lancer ce traitement, il faut créer et valider un message, le traitement va alimenter la structure du message de la fiche en cours.

La fenêtre suivante permet de sélectionner le fichier concerné : 

Remarque : Le fichier doit être présent sur le serveur SQL. 

Valider.

2.5.2. Tester la structure :

Ce traitement permet de repérer les anomalies du message.

Exemple : Ci-dessous une erreur SQL. 

Le message indique une erreur SQL concernant une syntaxe incorrecte « client2 ».

L’onglet « Recherche » permet  de trouver toutes les itérations concernées par l’erreur.

Dans l’exemple, la source de l’erreur se trouve dans le bloc SQL avant du message. 

2.5.3. Publier un message

Ce traitement permet de générer un fichier XML contenant la structure du message. Le but de cette action est de permettre d’installer la structure du message sur une autre base de données de l’ERP. 

Le fichier généré se trouve dans le répertoire « EDI_CONFIG\SetUp\MESSAGE » de l’ERP Silog. Il porte le nom du message.

Exemple :

2.5.4. Installer un message

Ce traitement permet d’installer un message qui a été publié dans un fichier XML par le traitement précédent.

La fenêtre suivante permet de saisir le code du nouveau message ainsi que le chemin et le nom du fichier XML.

Valider. 

 

Donnez votre avis sur la Base de connaissance Silog ici ou contactez-nous directement par mail sur confluence@silog.fr