Standard ORDERS message

Cegid Orli - Documentation fonctionnelle - 2025

 

ORIGINE FONCTION

96A

XC218
XC201

 

Principe général

 

Toutes les commandes traitées sur Cegid Orli ne sont pas toutes saisies à l’origine sur cet applicatif. Certaines sont saisies sur d’autres produits et peuvent être envoyées via EDI. Il est donc indispensable d’intégrer le plus rapidement et plus simplement possible ces commandes dans Cegid Orli afin qu’elles puissent être traitées et livrées dans les meilleures conditions.

Le module d’accueil de commandes permet l’intégration de ces commandes de manière rapide dans les tables Cegid Orli. Pour se faire, le partenaire EDI doit mettre à notre disposition un fichier séquentiel contenant les différentes commandes à intégrer. La description et la structure du fichier sont imposées et fournies par Cegid. Ces fichiers doivent ensuite être mis à disposition dans un répertoire paramétrable au niveau de TA350.

Le module d’accueil de commandes a pour but d’extraire les données de ces fichiers, de les contrôler puis de les insérer dans les tables Cegid Orli correspondantes.

 

Le fonctionnement général du module peut être décrit en plusieurs points :

 

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

Les fichiers présents sous le compte paramétrable au niveau de TA350 sont automatiquement renommés afin de conserver intact les fichiers d’origine. Ils sont archivés dans le répertoire « répertoire de TA350/arc » sous le nom YYMMDDHHMMSS. « nom du fichier à intégrer ». Un numéro de lot leur est ensuite affecté. Ce numéro de lot est un numéro séquentiel attribué à chaque fichier traité pour un même numéro de demande et permettant d’effectuer un suivi des transactions.

 

Remarque : 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 par l’appel de XC20B. L’utilisateur doit saisir le code provenance et le code origine correspondant à l’intégration des commandes EDI (EDI / 96A)

Ces deux données permettent de déterminer la source émettrice des fichiers.

 

3) Intégration des fichiers dans les tables réceptacles Cegid Orli :

A ce niveau, seuls des tests de structure des enregistrements sont effectués :

  • Enregistrement obligatoire ou non
  • Type d’enregistrement erroné
  • Champ obligatoire ou non
  • Test sur le type de champ : numérique, caractère, date.

 

4) Contrôles spécifiques liés à la provenance des fichiers reçus :

Tous les contrôles et initialisations de données éventuelles sont effectués dans cette phase.

 

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

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

 

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 les tables définitives. Dans le cas contraire, une fonction permet de réaliser les corrections nécessaires (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

 

 

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).


‎ 

Schéma fonctionnel du module

Image 69


Description des fonctions du module

Avant la première utilisation de ce module, une phase de paramétrage est indispensable. Celle-ci est réalisée EXCLUSIVEMENT par Cegid. Elle permet de décrire la structure du fichier et de vous affecter un code provenance et un code origine pour le lancement de l’intégration. Ce paramétrage est standard et correspond au format de fichier géré par Cegid

(voir structure du fichier à intégrer)

 

Le descriptif du fichier est évolutif et peut être amené à être modifié en fonction de vos demandes. La description de votre fichier doit être cependant étudiée et peut nécessiter la création de fonctions annexes pour l’initialisation de certaines données. A l’issue de cette étude, un paramétrage (facturable) et éventuellement la réalisation de fonctions sous forme d’aménagement seront nécessaires.
Ce module est chargé d’intégrer des commandes sans notion de solde de commande. Pour pouvoir prendre en compte ces notions, il faut utiliser le module PAS-EXP qui permet d’intégrer l’expédié par ligne de commande.

 

 

Les fonctions du module peuvent être scindées en plusieurs parties :

  • PARAMÉTRAGE AVANT INTÉGRATION
  • LANCEMENT DE L’INTEGRATION
    • XC20B INTEGRATION DE FICHIERS SEQUENTIELS
  • CONTROLES EFFECTUES
    • CD362 HISTORISATION DES COMMANDES EDI
  • MODIFICATION DES DONNES A INTEGRER
    • CD360W02 MODIFICATION DES COMMANDES EDI
  • VALIDATION DES DONNEES A INTEGRER
    • CD620 RELANCE ET VALIDATION DES COMMANDES EDI

 

 

 

Paramétrage avant intégration

 

Avant d’utiliser ce module, un certain nombre de données doivent être renseignées dans Cegid Orli.

 

Vous devez renseigner les informations suivantes :

 

TA009 : Société

Le message ORDERS contient systématiquement, pour chaque commande EDI envoyée, un enregistrement dont le but est d’identifier la société vers laquelle doit être orientée la commande EDI en cours de traitement

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

Il est donc primordial de renseigner ces informations au niveau de TA009

 

 

CL001 : Gestion des clients

Le message ORDERS contient systématiquement, pour chaque commande EDI envoyée, un enregistrement dont le but est d’identifier le client étant à l’origine de la commande.

Il peut également contenir un enregistrement indiquant, pour chaque commande EDI, le client livré ou facturé.

Selon les partenaires EDI, l’identification de ces 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. Il est donc primordial de renseigner ces informations au niveau de CL001.

N.B. :
dans la majeure partie des cas, le code international entreprise est utilisé par les partenaires EDI (Galeries Lafayette etc.)
La notion de GENCOD CLIENT par RAYON est gérée.

 

 

NOTION DE PARTENAIRE EDI

Afin de gérer au mieux ces différences de langages EDI, la notion de PARTENAIRE EDI permet de 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 de commandes, d’avis d’expédition ou encore d’envois de pièces sont différents suivant le langage utilisé (champs à envoyer au partenaire EDI différents suivants le langage).

Pour ce faire, la liaison d’appartenance « partenaire EDI» (TA014, fonctionnalité 59) 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.

 

 

TA471 : Gestion des partenaires EDI

Cette fonction permet à l’utilisateur de définir les différents partenaires avec lesquels la société souhaite effectuer des échanges EDI.

 

Il permet ainsi de définir, pour chaque partenaire, chaque langage et chaque version, les différents échanges gérés (réception de commandes, envoi d’accusés de réception (complets, partiels, avec modification), envoi des avis d’expédition, des pièces, des catalogues de prix, des catalogues articles).

 

Onglet Message ORDERS

indique les spécificités de traitement des commandes selon le partenaire (mode de gestion des commandes prévisionnelles (automatique, manuelle, non gérée), seuil de tolérance lors du contrôle des prix par rapport à PR022, modification des délais autorisée O/N etc ...) ; il permet également à l’utilisateur de définir les notions indispensables à la création des commandes dans Cegid Orli (données ne pouvant pas être initialisées à partir des informations présentes dans les fichiers reçus des partenaires (notamment la saison de commande, la nature de commande, le type de commande, la période de prix, etc...).

En dernier lieu, il permet à l’utilisateur de définir, par langage et version, les correspondances nécessaires aux dialogues entre les correspondants (EAN transporteur, mode d’expédition, code emballage ...).

 

 

8 onglets sont utilisés pour le message ORDERS ; les autres onglets concernent quant à eux l’envoi des pièces (message INVOIC)

 

Premier et deuxième onglets
permettent de définir pour chaque partenaire, chaque langage et chaque version, les différents échanges gérés (ainsi que les spécificités de traitement des données reçues du partenaire).

 

Troisième onglet 
permet à l'utilisateur de définir, pour chaque partenaire, le catalogue EDI qui lui sera envoyé lors de la génération du message PRICAT ainsi que les éléments indispensables à la valorisation des produits associés au catalogue (à savoir le tarif et la période de tarif).

Il permet également de définir le format qui sera utilisé pour la constitution du message.

 

Quatrième onglet

permet à l’utilisateur de renseigner les différents paramètres à partir desquels seront initialisées les données obligatoires lors de l'intégration des commandes dans Cegid Orli (données ne pouvant pas être initialisées à partir des informations présentes dans le fichier traité, notamment la saison de commande, la nature de commande, le type de commande, le tarif, etc...).

Ces paramètres de base sont le partenaire, le langage, la version, une fourchette de date de commande et une fourchette de dates de livraison.

Une fois, ces critères renseignés, l’utilisateur peut définir, pour chaque association Partenaire/Langage/Version/Dates de commande/Dates de Livraison, les informations indispensables à la création de la commande.

L’utilisateur peut également définir, au niveau de cet onglet, les différents types de commande EDI que le partenaire EDI est susceptible de lui envoyer (exemple : Commande Ferme, Commande prévisionnelle, commande Ferme sur prévisionnelle) et leur associer une type de commande et une nature de commande Cegid Orli.

 

Cinquième onglet
permet de définir les correspondances entre les modes d’expédition Cegid Orli et les modes d’expédition gérés par les différents langages utilisés par les partenaires (indispensable si le partenaire envoie ces propres modes d’expédition).

 

Sixième onglet
permet de définir les correspondances entre les codes unité Cegid Orli et les codes unité gérés par les différents langages utilisés par les partenaires (indispensable si le partenaire envoie ces propres codes emballages).

 

Septième onglet
permet de définir les correspondances entre les codes conditions de port Cegid Orli et les codes condition de port gérés par les différents langages utilisés par les partenaires (indispensable si le partenaire envoie ces propres codes emballages).

 

Huitième onglet
permet de définir, par partenaire et par langage/version, les différents codes EAN des transporteurs gérés dans Cegid Orli
(indispensable si le partenaire envoie la référence du transporteur par lequel il souhaite être livré).

 

CA001/ CA011/ CL005 Codification des articles

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ées, 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 vos références Articles (message PRICAT). Dans ce cas, la récupération des articles ne pose aucun problème (car les références reçues sont vos propres codification (EAN ou non).
  2. Le partenaire envoie ses propres codifications EAN. Dans ce cas, il convient de saisir les GENCOD du partenaire au niveau de CA001 (avec le CNUF du partenaire).
  3. Le partenaire envoie ses propres références (non EAN). Dans ce cas, il convient de saisir les références du partenaire au niveau de CL005 (avec le CNUF du partenaire).

 

 

 

Lancement de l’intégration

 

XC20B : Lancement de l’intégration

Le premier onglet permet d’indiquer le code provenance et le code origine fournis par Cegid et correspondant à un paramétrage particulier (EDI / 96A) dans le cas des commandes EDI.

Le second onglet permet de renseigner les différents paramètres utilisés pour l’intégration. L’accès à cet onglet est conditionné par la définition ou non de paramètres lors du paramétrage réalisé par Cegid.

exemple : pour les commandes, un paramètre consiste à demander à l’utilisateur s’il souhaite renuméroter ses commandes ou au contraire, conserver le numéro indiqué dans le fichier.

 

Ces paramètres sont issus de TA350, ils doivent être saisis dans le paramétrage.

Les paramètres d'import qui peuvent être utilisés sont les suivants :

 

  • AFFECT_RAYON
    Récupération rayon (API)
    • X = récupération du code rayon éventuellement renseigné au niveau de l’enregistrement ADR (pour le client commande ou livraison) au niveau d’un des champs No référence X si Qualif référence X = API

       

  • BLOC_PART_LIV
    Blocage si indication livraison
    • X = Blocage si présence d’indications particulières Paiement ou Livraison

       

  • DIV_COM_FORC 
    Division commerciale de la commande
    • Permet de forcer la valeur de ce paramètre au niveau de la division commerciale, quelle que soit celle récupérée par la passerelle

       

  • GEST_SUR_MESURE
    Gestion du sur-mesure
    • X = Permet de récupérer à partir de l’enregistrement MES les champs « Taille de base » et « Commentaire » pour les ajouter au texte formaté normalement

       

  • LIAISON_CDE
    Liaison pour textes commandes
    • Permet de spécifier un code liaison pour les textes sur commandes et ne pas récupérer le premier code associé à la fonctionnalité ‘00’ dans TA014

       

  • LIAISON_FTX
    Liaison pour information FTX
    • Permet de spécifier un code liaison pour les textes « FTX » renseignés dans l’enregistrement LIG au lieu des liaisons envoyées dans « Qualif X FTX »

       

  • LIAISON_MES 
    Liaison pour mesure spec.
    • Permet de spécifier un code liaison pour les textes sur commandes et ne pas récupérer le premier code associé à la fonctionnalité ‘04’ dans TA014

       

  • LIAISON_PCB
    Liaison pour information PCB
    • Permet de spécifier un code liaison pour les textes concernant les informations de « Qté par conditionnement PCB » éventuellement renseigné dans l’enregistrement LIG

       

  • LIEN_SAP_OBL
    • X : Données SAP obligatoires

       

  • CDES_ALLOTIES
  • Ce paramètre permet d’indiquer que les commandes reçues sont de type « Alloties » à une même référence de commande présente dans le fichier transmis par le partenaire doit ainsi donner lieu à X commandes dans Cegid Orli (une commande par destinataire).
    On doit donc avoir X clients différents pour la référence de commande concernée.

Ce paramètre peut prendre les valeurs suivantes :

X : Intégration de commandes « Alloties »

NULL : Intégration de commandes classiques

 

Cas particulier

1 : Intégration de commandes « alloties » multi destinataires mais mono client. Dans ce cas, l’éclatement des commandes se fait par code personne.

 

  • NAT_CDE_SIM_ALL
    Nature compl. (Sim. Allotie).
    Ce paramètre n’est actif que si le paramètre CDE_ALLOTIES=1.

Il contient alors la nature de commande qui devra être affectée aux commandes non alloties si le partenaire envoie dans un même fichier des commandes « Alloties » et « Non alloties »

 

  • SANS_CTL_CLI_LF
    • X: Pas d'ano sur client livré/facturé

       

  • SM_MONO_TAIL
    Création lignes mono-taille SM
    • Equivalent au critère CDE_MONO_TAIL mais uniquement sur les commandes Sur Mesure (avec une taille BTB renseignée dans le fichier)

       

  • SM_RECH_PDT_BTB
    Recherche sur taille de base
    • Recherche de la référence Cegid Orli (selon EAN, code article du partenaire EDI, …) en prenant en compte le champ « Taille de base BTB » envoyé dans l’enregistrement LIG

       

  • SOCIETE
    Société de la commande
    • Permet de forcer la société d’une commande. Si ce paramètre est renseigné, la valeur présente dans l’enregistrement ADR n’est pas contrôlée

       

  • WARN_CTRL_PRI
    Warning Ctrl Prix dans CD620.
    • Ce paramètre permet de ne pas bloquer une commande dont le seuil de tolérance des prix a été dépassé

 

N.B. :
d’autres paramètres d’intégration sont disponibles. Consulter la documentation « MODULE_Passerelle (Intégration Commande client PF) »

 

 

NOTION DE COMMANDES ALLOTIES

Il se peut que le partenaire EDI demande une gestion des commandes « ALLOTIES ». Si tel est le cas, le fichier de commandes ne contient en fait qu’une seule commande concernant X destinataires distincts (le destinataire final étant précisé dans l’enregistrement détaillant les différentes lignes de la commande).

Pour intégrer ces commandes, il suffit de positionner le paramètre d’intégration CDE_ALLOTIES=X dans TA350. La commande globale reçue est alors éclatée en autant de sous-commandes que de destinataires présents dans les lignes.

 

 

Les différents contrôles :

 

Plusieurs types de contrôles sont réalisés à des étapes différentes dans l’intégration.

 

F Dans un premier temps, lors de l’extraction des données du fichier pour intégration dans les tables réceptacles, un premier contrôle est réalisé.

 

Celui-ci consiste à vérifier :

Si le type de l’enregistrement n’est pas erroné

Si tous les champs obligatoires sont présents dans l’enregistrement

Si le type des champs est correct : numérique, caractère, date, ...

 

Cette étape a donc pour but de vérifier l’intégrité des données reçues et d’intégrer les données extraites dans les tables réceptacles prévues à cet effet. Ces tables servent ensuite de base à tous les traitements effectués avant l’intégration réelle des commandes dans les tables définitives.

N.B. :
pour les commandes EDI, il n’existe qu’un seul fichier contenant X types d’enregistrements différents. Le caractère obligatoire ou facultatif de chaque enregistrement n’est pas contrôlé.

Chaque anomalie rencontrée donne lieu à l’écriture d’une ligne d’erreur dans la table des anomalies qui est ensuite éditée.

 

Dans un second temps, des contrôles spécifiques liés à la provenance des fichiers de commandes reçus sont réalisés.

 

Tous les contrôles et initialisations de données éventuelles sont effectués dans cette phase. Cette dernière est facultative car liée à la provenance des fichiers reçus. Dans le cas des commandes EDI les contrôles spécifiques effectués sont :

  • 407 : Enregistrement Adresse Inconnu

  • 408 : Client commande introuvable

  • 409 : Client facture introuvable

  • 410 : Client livré introuvable

  • 411 : Récupération du fournisseur Impossible (TA009)

  • 412 : Récupération du partenaire EDI impossible

  • 413 : Commande prévisionnelle Non gérée par le partenaire

  • 414 : Commande Prévisionnelle Inconnue

  • 415 : Type de commande EDI inconnu (TA471)

  • 416 : Incohérence Type Commande EDI / Nature Commande Cegid Orli

  • 417 : Fonction EDI inconnue

  • 418 : Accuse Inconnu

  • 419 : Incohérence Type d’accusé demandé

  • 420 : Présence d’indications particulières de livraison (warning)

  • 421 : Code Monnaie EDI inconnu (code ISO de #TA TA016)

  • 422 : Transporteur EDI inconnu

  • 423 : Mode expédition EDI inconnu

  • 424 : Commande à ANNULER

  • 425 : Incohérence NB LIGNES

  • 426 : Incohérence QTE

  • 427 : Code Pays EDI inconnu

  • 428 : Impossible de récupérer les paramètres EDI (de la centrale rattachée au client qui passe la cde)

  • 429 : Impossible de récupérer le représentant

  • 430 : Impossible de récupérer le secteur de vente

  • 431 : Impossible de récupérer la division commerciale

  • 432 : Impossible de récupérer le produit

  • 435 : Seuil de tolérance dépassé

  • 436 : Unité d’achat inconnue

 

 

Dans un troisième temps, des initialisations et des contrôles de données identiques à ceux réalisés dans la fonction CD001 sont effectués.

 

Tous les contrôles effectués à ce niveau sont détaillés dans la documentation PAS-CDE.

 

CD362 : Historisation des commandes EDI:

CD362W01
Historisation des commandes EDI

 

Les commandes EDI traitées sont toutes historisées (après les phases de contrôle des données). Ces commandes sont alors visualisables par l’intermédiaire de CD362.

Cette fonction de visualisation des historiques de commandes EDI fonctionne de la façon suivante :
‎Elle permet à l'utilisateur de sélectionner les commandes qu'il souhaite visualiser.

 

Pour cette sélection, les critères suivants sont à sa disposition :

  • Provenance de la commande
  • Origine de la commande
  • No de la commande
  • No de la commande externe
  • Secrétaire commerciale
  • Partenaire EDI (client + société)
  • Client de la commande (client + société)
  • Division commerciale
  • Saison de vente
  • Nature de commande
  • Type de commande
  • Référence de la commande
  • Date de la commande
  • Référence marquage
  • Code personne
  • Kit client
  • Le flag d'annulation de la commande
  • Un flag indiquant le mode de création ou d'annulation de la commande
    ‎Ce flag peut prendre les deux valeurs suivantes :
  • "A" : Cas d'une commande créée lors du premier lancement du XC20B ou annulée automatiquement par la fonction de contrôle (présence d'un motif de rejet définitif)
  • "M" : Cas d'une commande créée après passage par la fonction CD361 ou annulée par CD361

Une fois les différentes commandes sélectionnées, l'utilisateur peut visualiser le détail de chacune d'elle en passant par chaque onglet.
‎Il accède alors aux onglets suivants :

  • condition de livraison
  • condition de vente
  • état de la commande
  • lignes de commande (avec visualisation possible des commentaires)
  • adresses de la commande
  • textes sur la commande

N.B. :
Au niveau de cette fonction, seule la consultation des données est autorisée. L'utilisateur ne peut en aucun cas modifier les commandes visualisées.

 

Modification des données à intégrer

 

CD360W02 Modification des commandes EDI

La maintenance des commandes EDI est assurée par 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 TA471 : GESTION DES PARTENAIRES EDI

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

 

a) Supprimer la commande

Si l'utilisateur décide de supprimer la commande, il doit utiliser la coche "Annulation" prévue à cet usage et impérativement saisir un motif d'annulation soit au niveau de l'entête de commande, soit au niveau des lignes de commande. Ce motif sera ensuite récupéré lors de la génération de l'accusé de réception négatif éventuellement envoyé au partenaire EDI.

 

b) Modifier les délais de l'entête de commande

Cette modification n'est possible que si le partenaire EDI accepte les modifications de délais de livraison. Pour ce faire, il suffit à l’utilisateur de cliquer sur l'onglet "Cond. Livraison" prévu à cet usage. Au niveau de cet onglet, l'utilisateur ne peut par contre accéder qu'aux délais de livraison.

Remarque: En cas de modification des délais de livraison, l'utilisateur peut choisir, par l'intermédiaire d'une question écran, d'affecter ou non les nouveaux délais à toutes les lignes de la commande en cours de traitement.

 

c) Supprimer totalement une ligne de commande

Lors de la suppression d'une ligne de commande, l'utilisateur doit utiliser la coche "Ann" prévue à cet usage et doit saisir un motif d'annulation L'annulation d'une ligne de commande n'est possible que si le partenaire autorise les acceptations partielles de commande

 

d) Supprimer partiellement une ligne de commande

La suppression partielle consiste en fait à supprimer certaines tailles de la ligne de la commande. La suppression d'une taille s'accompagne également de la saisie d'un motif d'annulation. L'annulation d'une taille d'une ligne n'est possible que si le partenaire autorise les acceptations partielles de commande.

 

 

e) Modifier les délais de la ligne de commande

La modification des délais d'une ligne de commande n'est possible que si le partenaire EDI autorise les modifications de délais. Pour ce faire, il suffit à l’utilisateur de cliquer sur l'onglet "Particularités" prévu à cet usage. Au niveau de cet onglet, l'utilisateur ne peut par contre accéder qu'aux informations suivantes:

  • Période/Tarif
  • Délais de livraison.

RAPPEL : Selon le paramétrage défini dans TA131 pour le type de commande, il est possible de ne pas déclencher les contrôles sur les tailles épuisées, les dates d'arrêt commercial et les délais commerciaux.

f) Modifier les tarifs de la ligne de commande

La modification des tarifs d'une ligne de commande n'est possible que si le partenaire EDI autorise les modifications de tarifs. Pour ce faire, il suffit à l’utilisateur de cliquer sur l'onglet "Prix Spéciaux" prévu à cet usage.

 

g) Modifier les natures et types de commande

La modification des tarifs d'une ligne de commande n'est possible que si le partenaire EDI autorise les modifications de natures ou types de commande.

 

N.B. :
L'option AFF_LIG_ANO_EDI permet à l'utilisateur de sélectionner les lignes de commandes qui doivent être affichées par la fonction.
‎Si cette option est positionnée à 0, seules les lignes en anomalies peuvent être visualisées.
‎Si cette option est positionnée à 1, toutes les lignes sont affichées, qu'elles soient ou non en anomalie.

La création de lignes de commande est interdite.

 

Validation des données à intégrer

 

CD620 Relance et validation des commandes EDI

Cette fonction permet de valider les commandes EDI qui sont prêtes à être intégrées dans le portefeuille commande.

Les critères provenance, origine et éventuellement numéro de lot doivent être saisis. Il faut ensuite cliquer sur l’onglet « critères sélectifs » et la fonction vous propose les commandes pouvant être relancées.

La commande ne doit ni être rejetée, ni être déjà traitée pour être sélectionnée. Après la recherche, vous accédez au champ de validation qu’il vous faut cocher pour signifier que la commande est validée.

L’onglet « Paramètres d’intégration » vous permet de saisir les paramètres d’intégration.

exemple : renumérotation des commandes

N.B. :
Lors de l’intégration des commandes EDI, il se peut que certaines références article envoyées par le partenaire n’aient pas pu être reconnues (CL005 non renseignés, GENCODs non créés etc…). Si tel est le cas, lors de la relance de l’intégration des commandes EDI, une routine permet l’affectation de ces références non identifiées lors du premier traitement, aux lignes de commandes déjà créés. Cette routine adopte le mode de fonctionnement suivant :

 

Deux cas de figure peuvent se présenter :

 

Un produit n’a pas été identifié :

Dans ce cas, une nouvelle ligne de commande sera créée pour le produit concerné.

 

Une taille d’un produit n’a pas pu être identifiée

Dans ce cas, si le produit concerné a été commandé sur d’autres tailles qui ont pu être identifiées, la quantité présente dans la taille non identifiée sera affectée à la ligne de commande déjà créée.

Si le produit concerné n’a pas été commandé sur d’autres tailles, une nouvelle ligne de commande sera créée pour le produit/taille concerné.

 

Gestion de lots dans les commandes EDI

 

ATTENTION : Cette gestion n’a rien à voir avec les N° lots pour nommer les fichiers EDI, ni avec les commandes alloties.

 

Certains partenaires envoient des commandes avec, pour certains articles, des quantités en nombre de packs, ou de lots, et non en nombre de pièces.

Pour gérer ce cas, il faut utiliser la notion de série-type.

Les articles pouvant être commandés par lots doivent se voir affecter une série-type au niveau de la fonction AR001.

Cette série-type sera ensuite récupérée lors de l’intégration des commandes EDI.

Cependant, il est indispensable de pouvoir définir les partenaires pour lesquels les articles concernés doivent être gérés en série-type.

Dans TA471, la coche ‘Gestion des séries type’ permet de gérer la notion de packs. Si l'utilisateur coche cette zone la fonction fonctionne alors de la façon suivante : lors de l'intégration des commandes EDI, la fonction récupère la série type éventuellement rattachée aux différents articles traités. Si une série type a été trouvée, la quantité commandée est alors obtenue en multipliant la quantité présente dans le fichier par la quantité d'articles présente dans la série type (quantité renseignée en TA208).

N.B. :
La gestion des séries-type par partenaire ne sera possible que si le paramètre SERI_TYP_ART=0.


‎ 

Documentations annexes

Pour plus de précisions, Cf.