Coût façon négoce

Cegid Orli - Documentation fonctionnelle - 2025

 

ORIGINE FONCTION

COU

XC249

 

Principe général

Cette interface permet l’intégration au niveau de Cegid Orli des coûts façon/négoce.

Cette passerelle correspond à la saisie manuelle faite dans PR037.

 

Paramètre GÉNÉRAL

  • CTRL_DAT_EF_PRI

Option FONCTION
‎(XC249W01)

  • ACC_MAJ_COU_LOF

Paramètre PASSERELLE

  • ENVOI_ACQUIT
  • CODE_ORIG_ACQ


‎ 

Formats d'import / Lancement de l’import / Contrôles / Initialisations / Mise à jour des données

Toutes ces informations sont résumées dans :

Passerelle d’import

 

 

 

Description des fonctions du module

Ce module se compose d’une seule fonction qui gère la création d’une seule entité :
‎les coûts de fabrication/négoce (PR037).

 

Particularité de la maintenance

La valeur du code état est attribuée à « A » par défaut. La passerelle identifie seule si elle doit passer en mode « C » ou « M ». Ainsi, si le partenaire qui génère le fichier ne peut nous envoyer cette information, elle sera gérée nativement par la fonction.

Les différentes valeurs possibles du code état sont donc :

  • A pour automatique.
  • C pour création
  • M pour modification
  • S pour suppression
    L’ordre de traitement des codes état, par la passerelle, est S, C, M.

 

Le mode « automatique » (code état = « A ») permet de laisser la passerelle détecter elle-même si l’on se trouve en mode création ou maintenance. La suppression n’est donc pas possible dance ce cas.

 

Principe de création 

Un enregistrement n’est pas créé s’il existe déjà un enregistrement strictement identique sur une date d’effet inférieure ; en effet, il est inutile d’avoir deux enregistrements coûts identiques sur deux dates d’effet différentes, ceci pour éviter la pollution de données et de la volumétrie inutile.

 

Principe de maintenance 

Seuls les prix sont modifiables. Nécessite l’envoi de l’intégralité des données.

Si l’enregistrement à modifier n’est pas retrouvé, un message d’anomalie est listé. L’enregistrement de PR037 sera recherché sur les critères suivants :

Saison, article, coloris, société, phase, lieu, atelier, date d’effet, circuit, monnaie, coche PRI et quantité par prix. Mise à jour TOP PRI NEG ou FAC selon mode de gestion.


Principe de suppression 

Pas de contrôles des données, donc pas de message d’anomalie. Si la donnée envoyée n’existe pas, elle ne sera donc pas supprimée.

L’enregistrement de PR037 sera supprimé sur les critères suivants :

Saison, article, coloris, société, phase, lieu, atelier, date d’effet, circuit, monnaie, coche PRI et quantité par prix.

 

Mise à jour TOP PRI NEG ou FAC selon mode de gestion.

 

En cas d’anomalie, tous les enregistrements ayant les mêmes informations

(Saison, article, coloris, société, phase, lieu, atelier, date effet, circuit, monnaie, coche PRI par quantité, quantité par prix) sont bloqués.

Vocabulaire

Un fichier est un ensemble de données regroupées sous un même nom. Il est composé d’un enregistrement.

Un enregistrement représente une ligne d’un fichier, il est composé de champs présents chacun dans une colonne. Un enregistrement est composé de plusieurs champs ou données.

 

XC20B intègre les données dans la table réceptacle prévue (ORL_COUT_FACON_NEG) et lance XC249 qui se charge de lire chaque enregistrement de cette table.

XC249 se contente alors d’appeler les fonctions de contrôle de données et d’intégration de la passerelle pour chaque enregistrement.

Les anomalies sont gérées par XC20B dans la table ORL_ANOMALIE et éditées en fin d’intégration.

 

 

Code état (à ne pas confondre avec l’état d’un article, actif ou non) :

Cette information indique si l’enregistrement doit être :

C
Créé

M
Modifié

S
Supprimé

A
géré en mode Automatique par la passerelle (M si existe / C si n’existe pas) 

 

 

Dans un deuxième temps, des initialisations et des contrôles sont effectués (procédure P_XC249_CONTROLE).


 

 

Suivi de l’intégration

 

Cette partie est assurée par la procédure P_XC249_GENERATION.

La table réceptacle qui servira de base à l’intégration est ORL_COUT_FACON_NEG.

La table ORLI mise à jour lors de l’intégration COUT_FACON_NEGOCE.

Toute anomalie rencontrée lors du contrôle des données donnera lieu à l’écriture d’un enregistrement dans la table des anomalies d’intégration ORL_ANOMALIE.

Cette table a la structure suivante :

FONC    NOT NULL VARCHAR2(5)  XC249

NUM_DEM   NOT NULL NUMBER

CODE_PROV_CDE  VARCHAR2(25)  EXTERNE

CODE_ORIG_CDE  VARCHAR2(25)  COU

CRITERE_1   VARCHAR2(25)  valeur dépendant du test

CRITERE_2   VARCHAR2(25)  valeur dépendant du test

CRITERE_3   VARCHAR2(25)  valeur dépendant du test

CRITERE_4   VARCHAR2(25)  valeur dépendant du test

CRITERE_5   VARCHAR2(25)  valeur dépendant du test

TEXT_ANO   VARCHAR2(132) Texte de l’erreur

REF_ANO    VARCHAR2(132) 132 premiers cars de l’enreg.

 

Dès qu’une anomalie aura été détectée, l’enregistrement sera automatiquement placé en anomalie (Mise à jour à ‘X’ de la zone FLAG_ANO dans la table réceptacle traitée).

 

 

Zone 34 : utilisée selon option XC249W01/ACC_MAJ_COU_LOF

Valeurs :

" " = pas de Répercussion

"0" = Répercussion totale

"1" = Répercussion seulement des spécificités


‎ 

 

Répercuter les créations / modifications des coûts dans les lignes de commandes :

  • Totale
    ‎Mise à jour des coûts, pour le niveau traité (circuit + atelier + phase + monnaie + quantité)
    ‎et pour date de commande supérieure ou égale à DAT_EFFET.
    ‎Si coût renseigné à l'article, répercussion sur toutes les lignes quel que soit le coloris article
  • Avec spécificités
    ‎Mise à jour des coûts, pour le niveau traité (circuit + atelier + phase + monnaie + quantité)
    ‎et pour date de commande supérieure ou égale à DAT_EFFET, mais uniquement pour les tailles pour lesquelles le coût « avant » des commandes était égal au coût « avant » (PR037).
    un coût particulier pour une taille sera conservé pour la ligne de commande

Les contrôles

Les contrôles sont de trois ordres :

 

  1. Contrôle du bon déroulement du lancement du module
  2. Contrôle des données contenues dans le fichier ou dans l’enregistrement
  3. Contrôle de cohérence du message

 

 

Contrôle du lancement du module

Le module contrôle plusieurs choses :

* on doit avoir spécifié 5 arguments (numéro de demande, lot, null, utilisateur (OPS$),webuser)

* le nom du fichier à traiter ne doit pas être trop long

* l’enregistrement ne doit pas dépasser la longueur admise

* l’ouverture du fichier à traiter de même que sa fermeture doit être possible.


‎ 

 

Contrôle des données

Dans un premier temps, le module contrôle qu’aucune donnée obligatoire ne manque
‎(cf. tableaux de détail des données par type d’enregistrement afin de connaitre les zones obligatoires).

 

Dans un second temps, le module contrôle que les données sont cohérentes entre elles et avec Cegid Orli. Ces contrôles sont différents suivant le type d’enregistrement traité.

  • Existence de la monnaie (TA016).

  • Existence du code article (AR001).

  • Existence du produit (AR001).

  • Existence du code circuit (TA079).

  • Article actif (AR001).

  • Produit actif (AR001).

  • Contrôle de cohérence entre le circuit et l’atelier.

  • Contrôle de cohérence entre le circuit, l’atelier et la phase.

  • Contrôle d’unicité entre la phase et le circuit (PR037 et table réceptacle).

  • Contrôle d’unicité du prix d’achat (PR037 et dans la table réceptacle) (Pour même société / PF / circuit / atelier / phase / date d’effet / saison appro / monnaie / quantité)

  • Contrôle d’unicité de la coche quantité PRI (PR037 et dans la table réceptacle) (Pour même société / PF / circuit / atelier / phase / date d’effet / monnaie)

  • Contrôle de la société (TA009 ; existence et de contexte comptable analytique ou juridique).

  • Contrôle de la date d’effet en fonction du paramètre CTRL_DAT_EF_PRI

  • Contrôle que seules les tailles fabriquées de la grille aient un prix.

  • Contrôle que les tailles de la grille avec un prix aient un type de fabrication.

  • Contrôle que toutes les tailles fabriquées aient un prix.