| ORIGINE | FONCTION |
|
RPT |
XC496 |
Ce message a pour but principal de récupérer les ventes effectuées par les boutiques d’un partenaire EDI et de générer automatiquement les factures fermes correspondant à ces dernières.
Chaque facture ferme générée peut donner lieu à la création d’un avoir conditionnel pour justifier la mise à jour du stock du magasin associé au client (cf documentation sur les dépôts conditionnels).
Seuls des documents de type « factures » peuvent être traités par ce message. Il n’est pas possible de générer des avoirs.
Notre module d’accueil standard permet l’intégration des ventes 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 ventes à traiter. 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 la fonction 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 résumé en six points particuliers :
1) Récupération des fichiers séquentiels :
Les fichiers présents sous le compte paramétrable au niveau de la fonction TA350 sont automatiquement renommés afin de conserver intact les fichiers d’origine. Ils sont archivés dans le répertoire « répertoire du 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.
N.B. :
actuellement, aucune automatisation n’est prévue pour aller récupérer les fichiers déposés sur le PC par le traducteur et les positionner sur le répertoire UNIX.
2) Lancement de l’intégration :
Le lancement de l’intégration s’effectue par XC20B.
L’utilisateur doit saisir le code provenance et le code origine correspondant à l’intégration des ventes EDI (SLSRPT / FAC).
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 :
À 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 ventes :
À ce niveau, l’ensemble des contrôles effectués par Cegid Orli lors de la saisie/maintenance d’une facture par la fonction FA002 sont appliqués aux ventes à intégrer.
6) Intégration des ventes :
Seules les ventes 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 (FA051).
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 des ventes rejetées
- Liste des ventes traitées et intégrées
Les ventes pour lesquelles aucune anomalie n’a été détectée apparaissent dans la liste des ventes intégrées (le No de pièce créé est automatiquement présent dans ce rapport).
Les ventes pour lesquelles des anomalies ont été détectées apparaissent dans la liste des ventes rejetées.
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
( description du fichier à intégrer)
N.B. :
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.
Les fonctions du module peuvent être scindées en plusieurs parties :
- PARAMETRAGE AVANT INTEGRATION
- LANCEMENT DE L’INTEGRATION
XC20B : INTEGRATION DE FICHIERS SEQUENTIELS - CONTROLES ET INITIALISATIONS DES DONNEES
XC250 : Intg. Facture - SUIVI DE L’INTEGRATION
XC299 : SUIVI DES INTEGRATIONS DE FICHIERS - MODIFICATION DES DONNÉES A INTEGRER
FA051 : MAINTENANCE INTEGRATION BONS / FACTURES - VALIDATION DES DONNÉES A INTEGRER
FA052 : REPRISE INTEGRATION BONS / FACTURES
À la fin du traitement, plusieurs états sont imprimés :
- Liste des anomalies d’intégration
- Liste des factures créées
Avant d’utiliser ce module, un certain nombre de données doit être renseigné dans Cegid Orli.
Vous devez renseigner les informations suivantes :
Le message SLSRPT contient systématiquement, pour chaque vente EDI envoyée, une donnée dont le but est d’identifier la société à laquelle doit être rattachée la vente 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 la fonction TA009
Le message SLSRPT contient systématiquement, pour chaque vente EDI envoyée, une donnée dont le but est d’identifier le client étant à l’origine de la vente.
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 les 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 factures sont différents suivant le langage utilisé (champs à envoyer au partenaire EDI différents suivants le langage).
La liaison d’appartenance « partenaire EDI » de fonctionnalité 59 (dans TA014) 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.
Cette fonction permet à l’utilisateur de définir les différents partenaires avec lesquels la société souhaite effectuer des échanges EDI.
C’est dans cette fonction que l’utilisateur doit indiquer les spécificités associées au traitement d’intégration des ventes selon le partenaire en précisant les différentes données qui seront indispensables à la création des pièces (type de document, saison de vente, nature de commande, type de commande, cohérence pour mise à jour des stocks, mode de regroupement des lignes de pièces …). Cette saisie doit se faire dans l’onglet « Ventes ».
Commentaires :
Type de document « Facture »
Le type de document saisi devra impérativement être de type « Facture ».
Il pourra par contre être de nature « normal (01) », « interne (06) » ou « ferme (07)».
Il devra être « Manuel ».
Si le type de document est de nature « Ferme », un avoir conditionnel sera automatiquement généré lors de la création de la pièce (ceci sera notamment le cas si vous gérez les dépôts conditionnels).
Coche pour MàJ des stocks
Si l’utilisateur renseigne un document dont la nature est « Ferme » cela signifie qu’il gère les dépôts conditionnels. Il y a donc logiquement un magasin associé aux différentes boutiques du partenaire (CL045). Notre passerelle génèrera donc une facture FERME avec MàJ de stock et un avoir conditionnel pour justifier les mouvements de stocks.
Si l’utilisateur a renseigné dont la nature est « Non Ferme »
Cela signifie qu’il ne gère pas les dépôts conditionnels. Il n’y a donc logiquement pas de magasin associé aux différentes boutiques du partenaire. Notre passerelle devrait donc se limiter à générer une facture sans MàJ de stock.
Cependant, la coche « MàJ des stocks » permettra quand même à l’utilisateur de forcer la MàJ du stock lors de la création des pièces (le stock MàJ sera alors le magasin « Entrepôt »).
N.B. :
si le type de document renseigné et de nature « ferme », la mise à jour du stock sera obligatoire.
Type de document « Avoir »
Cette zone devra impérativement être renseigné sir le type de document facture renseigné est de nature « Ferme ».
Le type de document saisi devra impérativement être de type « Avoir ».
Il devra être de nature « conditionnel (03) ».
Il devra être « Manuel ».
Motif d’avoir
Cette zone devra impérativement être renseigné si le type de document facture renseigné est de nature « Ferme ».
Le contexte du motif devra être « Avoir Sur Commande Client » (AV-CDECLI »).
Mode de regroupement des factures
Par défaut, les pièces créées seront mono Client/Monnaie.
Les deux coches suivantes permettront néanmoins de modifier le mode de regroupement des lignes de ventes :
Coche « facture mono BL »
En fait, lors de l’envoi des ventes par EDI, le fichier transmis devra impérativement contenir une référence « BL » qui permettra de regrouper les lignes de ventes.
La coche présente dans la fonction TA350 permettra de préciser si les factures créées doivent prendre en compte cette zone.
Si elle est cochée, les pièces générées seront mono BL. Le No de BL sera alors conservé dans la zone « référence de commande client ».
Si elle n’est pas cochée, les pièces générées seront multi BL. Le No de BL ne sera pas conservé dans les pièces créées.
Coche « facture mono Date de vente »
Zone associée au paramètre d’intégration « DAT_FACT », défini pour la passerelle d’intégration du SLSRPT.
Elle permet de déterminer les valeurs à affecter aux informations « Date de pièce » et « date de valeur ».
Plusieurs cas seront à envisager :
- Paramètre DAT_FACT renseigné
Dans ce cas, les pièces créées se verront systématiquement affecter la date définie dans le paramètre d’intégration.
La date de vente éventuellement présente dans le fichier transmis ne sera pas prise en compte par notre interface.
De la même façon, la coche « Facture mono Date de vente » ne sera pas prise en compte lors de la création des pièces.
- Paramètre DAT_FACT non renseigné et coche « Facture mono Date de vente » à X
Dans ce cas, la date de vente éventuellement présente dans le fichier transmis sera prise en compte par notre interface.
Si la date de vente est renseignée dans le fichier, l’interface générera une pièce par date.
Si la date de vente n’est pas renseignée dans le fichier, l’interface générera une seule pièce par client/monnaie. Cette pièce se verra alors affecter la date du jour.
- Paramètre DAT_FACT et coche « Facture mono Date de vente » non renseignés
Dans ce cas, la date de vente éventuellement présente dans le fichier transmis sera prise en compte par notre interface.
L’interface générera une seule pièce par client/monnaie.
Si la date de vente est renseignée dans le fichier transmis et si toutes les dates de vente sont identiques pour l’ensemble des lignes de vente du client, cette date sera automatiquement affectée à la pièce créée.
Si la date de vente est renseignée dans le fichier transmis et si toutes les dates de vente ne sont pas toutes identiques pour l’ensemble des lignes de vente du client, la date du jour sera automatiquement affectée à la pièce créée.
Si la date de vente n’est pas renseignée dans le fichier transmis, la date du jour sera automatiquement affectée à la pièce créée.
La procédure d'intégration prend en compte la valeur de différents 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 1er choix à prendre en compte lors d'un mouvement de stock. - LONG_ORD_FAC
permet de définir la longueur du no d'ordre des factures/avoirs dans le cas de numérotation des factures par mois - CPT_NUM_MOIS
permet de définir à partir de quel numéro, le compteur part quand la numérotation des factures mensuelles est gérée (numérotation dans TA194 par type de document. - GEST_MULT_CANA
permet de définir si les factures multi division commerciale sont gérées. - ENT_PAR_CANA
permet d’indiquer que les factures doivent obligatoirement être mono division commerciale. - OPT_ELMT_TARI
- CTRL_VENT_PAYS
permet d’indiquer le mode de contrôle effectué par pays pour la vente des articles. - MON_SITE
- NB_DEC_SIT
- LANG_SITE
XC20B : Lancement de l’intégration
La première page permet d’indiquer le code provenance et le code origine fournis par Cegid et correspondant à un paramétrage particulier (FIXE/RPT ou SEPARAT/RPT).
La seconde page permet de renseigner les différents critères utilisés pour l’intégration. L’accès à cette page est conditionné par la définition ou non de critères lors du paramétrage réalisé par Cegid.
Paramètres d’intégration disponibles :
- DAT_FACT
permet de forcer la date de la pièce générée (format DDMMYYYY) - PRIX_HT_UNIT
indique si le montant éventuellement transmis est un montant unitaire ou global
(X = Prix unitaire, NULL = Prix global). - SOCIETE
force la société qui facture. - TYP_CB
indique le type de code à barres transmis (1 = GENCOD, 2 = SKU) - STK_CLT_ABS_AUT
si positionné à X, permet de ne pas déclencher de message d’anomalie lors de la mise à jour des stocks des magasins CLIENT (CL045) si aucun stock n’est présent dans ce magasin pour l’article concerné.
Les différents contrôles lors de l'intégration des fichiers
Ces contrôles consistent à vérifier :
- Si tous les champs obligatoires sont présents dans l’enregistrement
- Si le type des champs est correct : numérique, caractère, date, ...
Seuls les enregistrements pour lesquels aucune erreur de structure n’est détectée, sont intégrés dans les tables réceptacles.
Les enregistrements à problème (exemple : champs obligatoire non présent) sont rejetés et insérés dans un fichier de sauvegarde de structure identique au fichier reçu. L’utilisateur peut venir le consulter s’il le souhaite sous le répertoire $ODI/portable.
Les noms des différents fichiers générés lui sont remis le jour du paramétrage.
Toutefois, à chaque intégration, des fichiers sont présents dans le répertoire $ODI/portable,
avec les extensions suivantes:
- .err : fichier des enregistrements sortis en anomalie contenant l’enregistrement à intégrer avec une phrase explicative de l’erreur
- .rej : fichier des enregistrements rejetés contenant tous les enregistrements pour lesquels une anomalie a été détectée (à chaque anomalie présente dans le .err correspond un enregistrement dans .rej)
- .temp : fichier temporaire utilisé par le traitement, il est toujours vide.
Chaque anomalie rencontrée donne lieu à l’écriture d’une ligne d’erreur dans la table des anomalies qui est ensuite éditée.
Les différents contrôles spécifiques aux message SLSRPT
Contrôle d’existence de la société
Si la société n’a pas pu être identifiée, l’anomalie suivante sera générée :
CONNECTEUR : impossible de récupérer le code société
Contrôle d’existence du client
Si le code du client n’a pas pu être identifié, l’anomalie suivante sera générée :
CONNECTEUR : impossible de récupérer le code client
Contrôle d’existence de la monnaie
Si le code monnaie n’a pas pu être identifié, l’anomalie suivante sera générée :
CONNECTEUR : impossible de récupérer la monnaie
Contrôle d’existence du partenaire EDI
Si le code partenaire EDI n’a pas pu être identifié, l’anomalie suivante sera générée :
CONNECTEUR : impossible de récupérer le partenaire EDI
Contrôle si le partenaire EDI gère le message SLSRPT
Si le code partenaire EDI n’a pas pu être identifié, l’anomalie suivante sera générée :
CONNECTEUR : le partenaire EDI ne gère pas le message SLSRPT
Contrôle si le paramétrage du message SLSRPT existe pour le partenaire EDI
Si le code partenaire EDI n’a pas pu être identifié, l’anomalie suivante sera générée :
CONNECTEUR : pas de paramétrage SLSRPT pour le partenaire EDI
Contrôle d’existence du produit
Si le code partenaire EDI n’a pas pu être identifié, l’anomalie suivante sera générée :
CONNECTEUR : Impossible de récupérer le produit
N.B. :
si une de ces anomalies est détectée, le fichier traité sera rejeté dans son intégralité. L’utilisateur devra alors modifier les données erronées et recycler le fichier initial.
Les différents contrôles d’intégration standard des factures
A) Contrôle sur chaque Entête de pièce
Test que tous les champs obligatoires sont bien renseignés.
Si tel n’est pas le cas l’anomalie suivante est générée :
Tous les champs obligatoires ne sont pas renseignés
Rejet 604
1) Test d’existence du BE
Ce test a pour but de s’assurer que le BE en cours de traitement n’a pas déjà été facturé lors d’un lancement précédant de la fonction.
En cas de BE déjà existant l’anomalie suivante est générée :
Bon déjà existant
Rejet 603
2) Test de la division Commerciale
Si la division commerciale est renseignée en entête de BE, elle doit exister pour le client. De la même façon, tous les produits présents dans le BE doivent être distribués dans cette même division commerciale.
Si tel n’est pas le cas insertion d’un enregistrement dans la table des Anomalies.
Division commerciale inexistante
Rejet 120
Cohérence client + division commerciale
Rejet 121
3) Test du Client
Le client doit exister dans CL001 avec un code état à 0 et ne doit pas être bloqué en préparation ou en expédition.
Si problème alors mise à jour des anomalies suivantes:
Client inconnu
Rejet 104
Client bloqué en Commande/Préparation/Expédition
Rejet 105
4) Test de la Monnaie
Le code monnaie doit exister dans TA016.
Par ailleurs, il doit être possible de récupérer le taux de change dans TA100.
Si problème alors mise à jour des anomalies suivantes:
Code monnaie inexistant
Rejet 137
Incohérence code tarif / Code monnaie
Rejet 138
5) Test du type de document
Le type de document doit exister et être de type Manuel (TA180)
Si problème, alors mise à jour de l’anomalie suivante :
Type de Document inexistant ou non manuel
Rejet 608
6) Test du RIB et du mode de règlement
Si le mode de règlement indique qu’il est nécessaire d’avoir un RIB (TA015) et que ce dernier n’est pas renseigné, alors mise à jour de l’anomalie suivante :
RIB obligatoire par rapport au mode de règlement
Rejet 159
B) Contrôle sur chaque Lignes de Bon
1) Test des zones Obligatoires
Test que tous les champs obligatoires sont bien renseignés.
Si tel n’est pas le cas insertion d’un enregistrement dans la table des Anomalies.
Test que la zone NUM_COLI est renseignée si le colisage est géré (sinon rejet 605).
Si tel est le cas le colis doit être défini dans la table ORL_EXP_BP_COL (table contenant l’ensemble des colis du bon d’expédition en cours de traitement) pour le BE traité.
2) Test Saison / Article/Coloris
A ce niveau les contrôles suivants sont effectués :
- Contrôle d’existence de la saison dans la table des SAISON.
- Contrôle existence de l’article dans AR001 avec un code état à 0.
- Contrôle existence du produit dans AR001 avec un code état à 0.
- Test si l’article est bien distribué dans la division commerciale éventuellement définie en entête de bon (Test effectué dans la fonction AR014 en fonction des données Article (Société, Réseau, Marque, Ligne de produit, Activité et Forme)
- Si l’article est relié à un client particulier alors vérification que le client du BE est le client de l’article, ou bien qu’il est lié à ce dernier par une liaison centrale ou filiale.
- Si le paramètre CTRL_VENT_PAYS=1
vérification que l’article ne soit pas interdit à la vente pour le pays du client . - Si le paramètre CTRL_VENT_PAYS=2
vérification que l’article soit autorisé à la vente pour le pays du client.
- Si le paramètre CTRL_VENT_PAYS=1
- Contrôle que la date du BE ne soit pas supérieure à la date d’arrêt commerciale.
- Contrôle que la date du BE ne soit pas supérieure à la date d’arrêt technique.
Si problème alors mise à jour d’un des motifs de rejet suivants :
Saison inexistante
Rejet 204
Article inexistant
Rejet 205
Produit inexistant
Rejet 206
Article non distribué dans la division commerciale
Rejet 207
Article non fabriqué pour ce client
Rejet 208
Article interdit à la vente dans ce pays
Rejet 209
Date de commande supérieure à la date d’arrêt commerciale
Rejet 211
Date de commande supérieure à la date d’arrêt technique
Rejet 212
3) Test de la finition spéciale
Si la finition spéciale est présente dans le fichier reçu, les 3 contrôles suivants sont appliqués :
- Test que l’article ne soit pas un article semi fini auquel cas la finition spéciale doit être à NULL
- Test de l’existence de la finition spéciale.
- Test si la finition spéciale existe pour l’article.
Si problème alors mise à jour d’un des motifs de rejet suivants :
Finition Spéciale inexistante
Rejet 214
Finition spéciale inconnue pour le Produit
Rejet 215
4) Contrôle/Initialisation du Tarif
Si la zone code tarif est renseignée (au niveau ligne ou entête) alors les contrôles suivants sont effectués :
Contrôle d’existence du tarif dans TA082
Contrôle si tarif associé au client (dans la table CLIENT) ou si tarif spécial pour le client (fonction de la nature de commande et de la division commerciale) ou si tarif récupérable dans la fonction TA301 (critères d’application des tarifs)
Si un problème est rencontré lors de l’initialisation ou du contrôle du tarif, il est procédé à la mise à jour des motifs de rejet suivants :
Code tarif inexistant
Rejet 135
Code tarif non applicable au client
Rejet 136
Si la période de tarif est renseignée alors test de cette dernière dans la fonction TA108.
Dans le cas contraire, récupération de cette dernière période en fonction de la saison de commande (si plusieurs périodes sont trouvées, récupération de celle dont la date de début de période est la plus élevée tout en étant inférieure à la date de facture).
Une fois les données TARIF et PERIODE renseignées, la fonction s’assure que des prix sont définis pour le produit traité (Vérification dans la fonction PR022).
Par la même occasion, un test est effectué afin de s’assurer que toutes les tailles livrées sont à la vente.
Si problème alors mise à jour du motif de rejet suivant :
Taille non à la vente
Rejet 224
Code tarif inexistant
Rejet 225
Période de tarif inexistante
Rejet 226
Pas de prix de vente incorrects pour l’article/tarif/période
Rejet 227
Détermination du prix de vente, via tarif + période tarif :
Le code tarif est connu, soit via passerelle, soit via règle de gestion TA301.
La période de tarif est recherchée via paramètre RECH_PER_LIGN :
- 0 = liste totale des périodes de tarif, et sélection selon saison de vente et date de commande
dans ce cas, il se peut que la période qui correspond n’existe pas (encore) - 1 = liste des périodes de tarif existantes dans les prix de vente de l’article et sélection de la période de tarif via paramètre TRI_RECH_PERLIG :
- 0 = alphabétique, soit la dernière saison (pour la période la plus récente)
- 1 = chronologique, soit la période la plus récente (en se basant sur la date début période)
(dans ce cas, il existe forcément une période qui correspond
5) Gestion des Prix spéciaux
Si la zone FLAG_PRIX_SPEC est cochée alors les contrôles suivants sont effectués :
Test que le tarif (de la ligne de BE est à NULL et que des prix spéciaux sont bien présents dans la ligne de BE.
Si tel n’est pas le cas les rejets suivant sont générés :
Absence de prix spéciaux pour la ligne de Bon
Rejet 241
Présence d’un tarif pour une ligne à prix spéciaux
Rejet 242
Test que des prix spéciaux peuvent être affectés au client du BE
Si tel n’est pas le cas le rejet suivant est généré :
Prix spéciaux interdits pour le Client
Rejet 239
6) Test/Initialisation du lieu et magasin d’origine
Si ces données sont présentes dans les tables réceptacles, il faudra vérifier qu’elles sont bien associées au produit en cours de traitement.
Dans le cas contraire, si paramètre général GEST_MULT_MAG=0 alors elles sont récupérées à partir de la fiche PRODUIT ; en revanche, si paramètre général GEST_MULT_MAG=1, la recherche s’effectuera dans la table LIEN_FS_MAG_DIV (en fonction de la division commerciale si présente dans le fichier).
Si problème alors mise à jour du motif de rejet suivants :
Impossible de récupérer le lieu et le magasin d’origine
Rejet 216
Lieu et magasin d’origine inconnu
Rejet 607
Création des factures
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 peut être lancée :
-
FAC_CLI_ENT
-
LIV_FAC_LIGN
-
LIV_FAC_COLIS
-
FAC_ELMT_TARI
-
FAC_ELMT_FACTU
Seules les ventes pour lesquels aucune anomalie n’a été détectée sont facturées.
La facture créée est une facture de type Manuelle (idem création via FA002).
Pour chaque BE, les traitements suivants sont donc effectués :
- Création d’une commande client manuelle (avec génération des éléments de tarification pour l’entête et les lignes de la commande)
- Création d’une facture Manuelle
- Génération des éléments de tarification et calcul du pied de facture
- Mise à jour du stock (Si demandée par l’utilisateur)
Problème : Il est possible que les articles expédiés sur un BE appartiennent à des divisions commerciales différentes.
Pour rester standard, la facture manuelle créée pour le BE doit correspondre à des commandes manuelles. Ces commandes doivent bien sûr être mono division commerciale.
Pour résoudre ce problème, si un bon d’expédition réunit des produits correspondant à X divisions commerciales, il est procédé à la création d’une seule facture et de X commandes (Une commande par division Commerciale).
N.B. :
la liste des regroupements de facture (TA195) n’est pas utilisée.
Modification des données à intégrer
Cette fonction permet de consulter et corriger les Bons d’expédition en anomalies.
Une fois les anomalies levées, l’intégration des bons d’expédition corrigés doit être relancée par la fonction FA052.
Fonctionnement
Tous les champs affichés sont modifiables par l’utilisateur.
Seuls les tests d’existence des données entrées sont effectués (tous les contrôles de cohérence du FA002 sont ensuite effectués lors du nouveau lancement de l’intégration du bon par le biais de la fonction FA052).
La fonction FA051 est composée de plusieurs pages accessibles en fonction de leurs N° de page. Pour accéder à la zone page dans chaque image écran il suffit de faire page suivante.
1ère Page : Maintenance des Entêtes de Bon
La page d’entête de bon est sensiblement identique à celle de FA002.
Une coche « Ano » permet à l’utilisateur d’accéder à une page de visualisation des anomalies en cours pour l’entête de la commande traitée.
Si le code client est modifié, les données suivantes sont aussitôt mises à jour :
- Code échéance
- RIB
- Mode de règlement
- Domiciliation bancaire
- Transporteur
- Profil de facturation
- Conditions de port
- Priorité
- Mode d’expédition
De la même façon, si une tranche est touchée (livraison demandée, confirmée, ou départ usine), les dates de début et fin de période sont automatiquement mises à jour en entête et en ligne.
2ème Page : Consultation des Lignes de Bon
Comme pour les entêtes, une coche « Ano » sur la page des lignes, permet à l’utilisateur d’accéder à une page de visualisation des anomalies en cours pour la ligne de bon traitée.
La coche « Info» permet à l’utilisateur de visualiser (et modifier si besoin) les prix de vente de la ligne de bons. Si la ligne de bon a des prix spéciaux, ceux-ci s’affichent sinon la fonction propose des prix de vente liés au tarif et à la période de tarification.
N.B. :
L’utilisateur peut visualiser les quantités taille à taille de la ligne de bon, mais il ne peut en aucun cas le modifier.
Si le code tarif ou la période de tarif est modifié, les prix spéciaux éventuellement présents, sont écrasés.
4ème Page : Pied de Bon
Cette dernière page permet de visualiser le pied du Bon en cours de traitement (montant HTB, nombre de pièces, nombre de lignes ...).
Il peut éventuellement saisir des textes sur factures (Appel d’une sous forme permettant la création des textes sur factures).
N.B. :
La suppression d’un BE ou d’une ligne de BE est conditionnée par l’option variable par l’utilisateur SUP_LIGN_ENT
Si SUP_LIGN_ENT=0 : Suppression interdite
Si SUP_LIGN_ENT=1 : Suppression autorisée
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, la 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, GENCOD 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é à é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é.