Logistique (Livraison/Expédition)

 

ORIGINE	FONCTION	FONCTION « avant »
BON CBP	XC220	XC005

 

 

Passerelle de validation des bons de livraison (PAS-BON)

Principe général

 

L’objectif de ce module consiste à interfacer des livraisons, entre un outil de gestion externe ‎(exemple : WMS) et le progiciel Cegid Orli, afin d’automatiser tout ou partie des fonctionnalités de :

• Création des bons de préparation générés par un WMS
• Modification / annulation des bons de préparation
• Saisie du colisage global et détaillé
• Validation des préparations de bons de livraisons
• Expédition des bons de livraisons (N° B.E.)
• Chargement des bons de livraison (N° B.C.)
• Facturation des B.E. ou B.C.

 

La validation et l’expédition sont les fonctionnalités le plus couramment utilisées à l’aide de ce module.

N.B. :
les données reçues via la passerelle viennent remplacer les données existantes dans le BP.

 

Ce module assure toutes les fonctions de base ‎couvertes par la fonction de VALIDATION DES BONS (LI011).

 

Le module se compose de deux parties :

1. Une mise à disposition de données nécessaires à l'outil externe. Cette mise à disposition est automatique et ne demande donc aucune manipulation utilisateur.
2. Le traitement des informations en retour de l'outil externe. Son utilisation est simple et correspond au lancement d'une procédure qui assure toutes les mises à jour.

 

L’ensemble des contrôles effectués dans LI011 de validation des bons, sont appliqués aux bons à intégrer. Seuls les bons qui ont passé avec succès tous les contrôles peuvent être intégrés dans les tables définitives.

 

Schéma fonctionnel du module

 

XC20B : Lancement de l’intégration

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

Une fois l’intégration terminée, un état de contrôle est édité, donnant la liste des anomalies
‎au niveau de la lecture du fichier ; la liste exhaustive des codes rejets BONxxx et de leurs messages respectifs est disponible dans le document MODULE_Passerelle (Liste Rejets).

 

Intégration à partir des tables réceptacles

Le traitement d’intégration est décomposé en trois parties indépendantes.

• la modification, la suppression, le colisage et la validation de bons de préparation
• l’expédition des bons de livraison
• la génération des bons de chargement

 

Chaque partie est elle-même décomposée en une phase de contrôle et une phase de mise à jour.

 

Paramètres & Options

La procédure d’intégration prend en compte les paramètres généraux de JP014 :

 

• PROD_HIS 
  permet de spécifier, avec la valeur ‘1’, la gestion d’un historique lors d’un éventuel mouvement de stock.
• CHOI_1 
  correspond au code du 1^er choix à prendre en compte lors d’un mouvement de stock.
• GEST_AFFLIG 
  permet, avec la valeur ‘1’, la gestion des traces d’affectation-désaffectation (gestion de la table AFF_CLI_LIGN)
• GEST_MATR 
  permet d’indiquer le choix de la prise en compte des matricules
• NUM_COLI_PF_UNI 
  valeur « 1 » pour contrôler la numérotation unique des colis.
• CB_COLI_CREA
  valeur « 1 » pour formater le code barre dès la création du colis.

 

Les options (JP012) spécifiques à la procédure d’intégration sont définies pour la fonction XC220W01 :

• BLOQ_VALI_BP=1
  permet de ne pas valider les bons des clients bloqués en préparation.
• BON_CHARG_EDIT=1
  permet de considérer le bon de chargement créé comme déjà édité.
• BON_CHARG_VALID=0
  permet de considérer le bon de chargement créé comme validé. Sinon, la validation du Bon de chargement doit se faire par LI070.
• COLIS_OBLIG=1
  permet de contrôler que le colisage soit complet pour valider le bon de préparation.
• EMB_PAR_DEFO 
  doit contenir, en cas de gestion du colisage, le code emballage par défaut pour les colis ou il n’est pas renseigné.

• GEST_BLOQ_EXP=1 
  permet de ne pas bloquer l’expédition des bons pour des clients ou commandes bloqués.

• GEST_FLAG_EXT

Dans un environnement WMS externe (stock et livraison clients), prise en compte du déphasage entre la définition du stock physique informatique (coté Cegid Orli) et cette même position côté WMS.

Côté Cegid Orli, le stock physique est défalqué dès la création des BP.

Sur un WMS, le stock physique est mis à jour uniquement quand les BP sont expédiés.

Un « marquage » des BE gérés par un système externe permet de savoir si leur quantité doit ou non faire partie intégrante du stock physique Cegid Orli : on peut comparer les stocks entre Cegid Orli et le système externe, via l'inventaire PF (stock physique Cegid Orli + encours sur BP / BE = stock physique du système externe).

 

exemple : valeur 2, afin d’utiliser la passerelle PAS-BON en 2 temps :

1. Création BE : les produits sont encore dans l'entrepôt, le BE est seulement un document administratif, il ne faut donc pas le marquer (pour tenir compte de ses marchandises dans l'inventaire).
2. Expédition BE au titre du BP (avec FLAG_EXPED) : c'est seulement à ce moment-là que le BE est marqué comme parti (il n'est donc plus pris en compte dans l'inventaire).

 

• MAJ_DAT_EDIT_BP=1 
  Dans la mesure où un WMS est capable de créer et imprimer les BP, la passerelle permet, si le BP n’a pas été édité par Cegid Orli, de renseigner cette date d’édition du BP avec la date de sa création.
• QTE_SUP=1 
  permet d’autoriser l’augmentation des quantités d’un bon de préparation.

 

Traitement de validation

Cette partie comprend les traitements :

• de suppression de lignes de bons ou de bons complets.
• de modification des lignes de bons ou d’information dans l’en-tête.
• de colisage de bons

de validation de bons.

 

Suppression de lignes de bons ou bons complets

La suppression de tout un bon est fonction de la coche FLAG_SUPPR dans l’en-tête et la suppression d’une ligne de la coche FLAG_SUPPR dans la ligne. Par défaut, le stock est remis à jour et reste affecté à la commande. Deux coches permettent, soit de ne pas remettre en stock les pièces affectées, SANS_MAJ_STOK, soit de les remettre sans les affectées à cette commande. Une coche saisie dans l’en-tête est prise en compte pour toutes les lignes.

 

Modification des lignes de bons ou d’information dans l’en-tête

Le principe du traitement de modification consiste à ne traiter que les informations présentes dans les tables réceptacles (en-tête et ligne) et différentes. Ainsi, les lignes non modifiées peuvent même ne pas être toutes présentes dans la table réceptacle des lignes. De même, les codes de l’en-tête, tel le transporteur ou le mode d’expédition, ou les quantités des lignes, gardent leurs valeurs s’ils ne sont pas renseignés dans la table réceptacle. Comme pour le traitement de suppression, en cas de diminution des quantités préparées, par défaut, le stock est remis à jour et reste affecté à la commande. Deux coches permettent, soit de ne pas remettre en stock les pièces affectées, SANS_MAJ_STOK, soit de les remettre sans les affectées à cette commande. Une coche saisie dans l’en-tête est prise en compte pour toutes les lignes.

‎ 

Colisage de bons

Le principe du traitement de colisage est basé sur la présence d’un numéro de colis dans les lignes de bon et la présence d’un enregistrement Colis. Les quantités des lignes reparties sur différents colis doivent donc être renseignées. Les colis sont alors constitués par cumul des lignes du bon (exemple : complétés au niveau du poids, de l’emballage, du code emplacement AP BP…, par les informations renseignées dans la table du colisage).

Un seul des poids nets ou brut peut être renseigné, l’autre est alors automatiquement calculé par le poids de l’emballage. Le numéro de bon d’origine permet également de référencer le complément d’un colis d’un autre bon de livraison.

N.B. :
au niveau de l’enregistrement colis, les informations intégrées à vide écrasent par vide l’existant. On suppose que le colis est intégré en une seule fois, donc attention, en cas de modification par une 2^ème intégration.

 

Le poids doit nécessairement être indiqué en Kilogrammes

 

Validation de bons

La validation du bon est fonction de la coche FLAG_VALID de l’en-tête de bon.
‎Cette validation est nécessaire pour enchaîner les deux étapes validation/expédition.

‎ 

Traitement d’expédition

Le traitement d’expédition est fonction de la coche FLAG_EXPED de l’en-tête de bon.

Cette coche peut prendre deux valeurs :

• X pour indiquer une expédition directe avec possibilité de regroupement sur un bon d’expédition en cours. Ce regroupement est réalisé pour un même client, même mode d’expédition, même condition de port, même transporteur, même monnaie, même adresse de livraison et de facturation, même division commerciale et même code de regroupement sur facture.
• 1 pour indiquer qu’un bon de livraison donne lieu à un bon d’expédition.

Si le code regroupement sur facture est renseigné, il remplace celui déterminé par défaut lors de la génération du bon d’expédition.

 

Traitement d’un chargement

Le traitement de chargement est fonction de la présence d’un code chargement (CODE_CHARG) dans l’en-tête de bon. Dans ce cas, ce traitement est exécuté éventuellement avant le traitement de validation et/ou le traitement d’expédition.

Si le code transporteur est renseigné, il remplace celui déterminé lors de la création du BP.

‎ 

 

Les différents contrôles lors de l’intégration à partir des tables réceptacles

• Traitement de validation
• Traitement d’expédition
• Traitement de chargement

 

Une fois tous les contrôles de données réalisés, l’intégration des bons dans les tables définitives de l’application Cegid Orli 

• BP_CLI_ENT
• LIV_FAC_LIGN
• LIV_FAC_COLIS
• BE_CLI_ENT

peut être lancée.

 

 

Suivi de l’intégration

JP530 : Suivi des Intégrations

Comme toutes les autres éditions, cette fonction a pour but de conserver une trace de tous les traitements lancés par XC20B.

JP530 permet d’accéder au résultat PDF de l’intégration (qui donne le N° de lot),
‎aux critères de présentation utilisés lors de la demande et au journal des anomalies.

L’utilisateur peut alors consulter le compte rendu de son intégration.

 

JP031 : Suivi de l’intégration

Une fois les contrôles de données réalisés, l’intégration des bons dans les tables définitives Cegid Orli :

• BP_CLI_ENT
• LIV_FAC_LIGN
• LIV_FAC_COLIS
• BE_CLI_ENT

peut être lancée.

 

Seuls les bons pour lesquels aucune anomalie n’a été détectée sont intégrés.

 

Cette fonction a pour but de conserver une trace de toutes les réceptions de fichiers quelle que soit leur provenance.

Elle permet également de connaître le numéro de lot affecté à chaque fichier lors de la phase d’intégration des données dans le réceptacle Cegid Orli.

Seule la zone PURGE peut être saisie. Quand elle est cochée, elle indique que les fichiers trace doivent être supprimés

• .err

• .rej

• .temp

 

Aucune modification, création ou suppression n’est autorisée dans ce programme.

La zone « Pb » permet d’indiquer si le traitement s’est passé sans encombre (dans ce cas, la zone est nulle) ou au contraire, si des anomalies ont été détectées (dans ce cas, la zone est renseignée par la valeur ‘0’).

 

L’utilisateur peut alors consulter le compte rendu de son intégration.
‎

Annexe : Description des fichiers à intégrer (origine BON)

 

3 types d’enregistrement :

1. E / Entête/ ORL_EXP_BP_ENT
2. L / Lignes/ ORL_EXP_BP_LIG
3. C / Colis / ORL_EXP_BP_COL

 

Au niveau E Entête

La passerelle ne modifie que les champs NON VIDES

 un champ passé à vide ne déclenche donc aucune mise à jour.

 

Le champ « N° de BE (NUM_BE) » est présent dans ORL_EXP_BP_ENT, permettant d’expédier le BP sur ce BE qui :

• soit existe déjà dans Cegid Orli
• soit a été fourni par Cegid Orli lors de l’extraction
  ‎(mise en place par développement à demander)
• soit est créé par la passerelle
  ‎(et rejeté, s’il ne respecte pas les conditions de regroupements sur BE)

 

Le message particulier « BP n'entrant pas dans le cadre des modifications par PAS-BON » est restitué quand on reçoit un entête de BP qui remplit ces 5 conditions :

• n’est pas à valider
• n’est pas à supprimer
• n’a pas de lignes à intégrer (pour modification) lui correspondant
• n’a pas de colis à intégrer lui correspondant
• n’a pas de magasin Après BP

 

dans ce cas, rien n’est à faire, donc la passerelle n’a aucune utilité.

 

 

Au niveau C Colis

Nécessaire seulement dans le cas d'une gestion du colisage, permettant de définir pour chaque bon de préparation la liste des colis avec leurs codes emballages et leurs poids.

Le numéro de bon d'origine permet de relier un même No de colis de deux bons de préparation différents.

La passerelle modifie TOUS les champs ci-dessus, VIDES ou NON VIDES

Tous les champs sont donc mis à jour
‎(ce qui permet éventuellement d’annuler une valeur précédemment créée par la passerelle)

exemple :
dans le cadre d’un magasin PF avec adressage obligatoire (TA034 / onglet Données principales / valeur 1 = adressage obligatoire au niveau colis), on peut annuler ‎les valeurs de ‘Palette’ et/ou ‘Emplacement’.

 

 

Remarque sur le Poids :

PAS-BON intègre un bon réalisé par un système externe ; on considère donc que c’est ce système externe qui calcule le poids et qui nous donne le résultat.

PAS-BON ne fait donc jamais ce calcul ‎(contrairement à LI011/LI044 qui répondent au paramètre CALC_POIDS_COLI)

 

 

Au niveau L Lignes

 

Le champ NUM_ORDR_TRAIT (20 caractères, format YYYYMMDDHHMISS)
‎permet de gérer un horodatage de chaque enregistrement (voir service Ingénierie).
‎La passerelle PAS-BON doit alors être appelée par une fonction « chapeau », chargée de traiter chaque horodatage dans l’ordre (et non pas tout le fichier en séquentiel) ; il est alors possible de maîtriser l’ordre d’intégration de chaque BP.

 

Chaque ligne de bon peut être intégrée :

• Avec l’information Gencod :
  • Soit en générant 1 ligne par Gencod, en renseignant bien uniquement les zones GENC_T1 et QTE_T1 avec pour chaque ligne les données taille correspondantes
  • Soit en générant 1 seule ligne avec les 20 Gencod ; cette solution nécessite le développement d’un programme « avant » pour mouliner la table réceptacle afin d’être dans la config 1 ligne par Gencod.
• Sans l’information Gencod :

Si le No ligne n’est pas connu, il faut renseigner tous les champs permettant d’identifier la ligne (Saison, article, coloris, …)

• en une ligne avec chacune de ses quantités sur les champs QTE_Tx
• OU en autant de lignes que de tailles : c’est-à-dire qu’il peut y avoir une ligne par taille : Dans ce cas, il faut mettre la quantité sur le champ QTE_T1 et le libellé de la taille dans LIB_TAIL. Attention, dès que LIB_TAIL est renseigné, on ne considère que la 1^ère quantité.

N.B. :
en cas de regroupement de lignes dans ce cas, on met FLAG_SUPPR à X seulement si toutes les lignes regroupées étaient à X, de même, on met le champ SANS_MAJ_STOK à ‘X’ si au moins une ligne a ce champ à ‘X’ (idem pour AVEC_DESAFF)

 

Les lignes non présentes dans cette table ne sont pas modifiées au niveau Cegid Orli.

‎ 

Passerelle de création des bons de livraison (PAS-CBP)

 

Principe général

L’objectif de ce module est similaire à PAS-BON (colisage de BP existants).

Cependant, les BP sont créés par le WMS, et transmis pour être créés à leur tour dans Cegid Orli

 

 

Le principe est de travailler avec un programme AVANT : XC005

création des BP

déstockage via type mouvement 695

(groupe des mouvements « préparation automatique »)

 

 

Il est ensuite enchaîné au programme standard PAS-BON : XC220

colisage

mise à jour lignes BP (en + ou en -)

 

 

Ces 2 programmes sont associés dans la nouvelle origine CBP (via provenance FIXE ou SEPARAT)

paramètre SUPPRIM_LIGN :

• 0 (= Ne pas supprimer lignes d’intégration) permet d’enchainer PAS-BON (XC220) à la suite de la création de BP par PAS-CBP (XC005)

 

Une fois l’intégration terminée, un état de contrôle est édité, donnant la liste des anomalies
‎au niveau de la lecture du fichier ; la liste exhaustive des codes rejets CBPxxx et de leurs messages respectifs est disponible dans le document MODULE_Passerelle (Liste Rejets).

‎ 

 

Annexe : Description des fichiers à intégrer (origine CBP)

N.B. :
Quand XC005 est lancé AVANT XC220, il ne faut pas que les tables qui ont servi à XC005 soient détruites comme dans toutes les intégrations standards. Pour cela, le paramètre SUPPRIM_LIGN permet d’indiquer qu’il ne faut pas détruire les lignes après le traitement XC005. De plus, dans ce cas, il faut que le traitement mette à jour les lignes (+ en-tête + colis) avec le nouveau N° de BP quand c’est XC005 qui l’a attribué.

SUPPRIM_LIGN = Destruction des tables en fin de traitement

• 0 = Pas de destruction : Utile si un programme après a besoin des mêmes enregistrements
• 1 = Destruction : Valeur par défaut.

 

 

1 seul type d’enregistrement :

Lignes / ORL_EXP_BP_LIG

 

‎

Commentaires

 

Ce N° renseigné à "." indique à Cegid Orli d’attribuer le N°BP via JP020.

Toute autre valeur correspondra au N° BP externe, que Cegid Orli doit utiliser :

• N° inconnu
   création de cette ligne pour ce nouveau N°BP
• N° connu
   regroupement de cette ligne à réaliser dans ce N°BP si encours
  ‎ (non historisé / validé / expédié)

 

Ce N° renseigné (en général = N°colis) est utilisé si NUM_BP="." 
‎ pour regrouper (selon critères standards) plusieurs lignes sur un même N° BP Cegid Orli.

 

Ce flag permet de gérer 2 cas :

• Valeur X
  Le logiciel externe augmente des quantités sur ligne existante (idem LI011) ; dans ce cas, XC005 n’est pas utile, c’est XC220 qui va se charger seul d’augmenter les quantités de la ligne de bon.
• Valeur NULLE
  Le logiciel externe ajoute des lignes de commandes sur un BP (idem LI005) ; ‎dans ce cas, c’est bien XC005 qui va préparer la nouvelle ligne de commande sur un BP(/colis) existant, puis XC220 qui va la coliser.