API Gestion Commun gerer Zone Parametree

Version ACE : 1.2  

Package : fr.ACE.metier.bc4j.commun.common

GestionCommungererZoneParametree

   
Schémas d’entrée et de sortie : IN OUT

Attention

Cette API, disponible depuis la version ACE 1.2, est aussi implémentée en version ACE 4.5.00.

Cette API permet de gérer les accès en lecture/écriture aux zones paramétrées (appelées aussi zones datées) des tables suivantes :

ADR Adresses
CAE Eléments du catalogue
EVE En-têtes d’évènement
EVP Postes d’évènement
OPE Opérations commerciales
PRO Produits
TIE Tiers

API imbriquées : aucune.

Contraintes et limites de fonctionnement (hors périmètre)

Les zones paramétrées des autres tables (EVS, CTC, etc) ne sont pas concernées par cette fonctionnalité et sont mémorisées dans la table ZOD.

En outre, cette fonctionnalité (gestion des zones paramétrées dans les structures XXX_CMP) n’est pas gérée pour les points suivants :

  • les critères de segmentation,
  • les multi-variantes (voir paramètre MULVAR),
  • les types « WEB » et « VAR » pour les produits,
  • la gestion des coûts (parités et unités des containers) (voir paramètre TARVEN),
  • l’historique des données des objets Lots (voir paramètre HSTOST),
  • l’optimisation des barèmes quantitatifs (voir paramètre ARRCA1),
  • les affaires (voir paramètre AFFAIR).

Paramétrage (PPE)

Cette fonctionnalité est gérée par le paramètre ZODMOD.

Processus, contrôles et règles de gestion

ETAPE DESCRIPTION DU PROCESSUS
1 PASSAGE DE PARAMÈTRES À L’API :
  • Modes d’action :
    • « C » pour Create (création)
    • « R » pour Retrieve (lecture)
    • « U » pour Update (modification)
    • « D » pour Delete (suppression)
    • « M » pour Manage (gestion : création/modification)
  • Liste de ZoneParametree
    Si aucun attribut « ZoneParametree » n’est renseigné :
    • En mode « R », toutes les zones paramétrées relatives au contexte sont récupérées.
    • En mode « D », toutes les zones paramétrées sont supprimées.
    • Dans les autres modes, elles sont propagées du contexte d’origine (obligatoire dans ce cas) vers le contexte à gérer.
  • L’un des contextes à gérer selon le champ :
    • Evenement,
    • Poste,
    • Tiers,
    • Adresse,
    • Produit,
    • Element (de type ReferenceCatalogue),
    • Operation (code opération).
  • L’un des contextes d’origine suivants (facultatif) :
    • EvenementOrigine,
    • PosteOrigine,
    • TiersOrigine,
    • AdresseOrigine,
    • ProduitOrigine,
    • ElementOrigine (de type ReferenceCatalogue),
    • OperationOrigine (code opération),

Le contexte d’origine permet la propagation des zones paramétrées.

Ex : Un produit vers un autre dans le cas de la duplication d’un produit.

2 LECTURE DU PARAMÉTRAGE DE ZODMOD

Détermination du mode de gestion des zones paramétrées pour la table concernée par le contexte (zone paramétrée de la table EVE si le contexte en entrée de l’API est l’Evenement, table CAE pour un Element, etc.)
  • Si le code de gestion vaut 0, alors on gère de façon standard les zones paramétrées dans la table ZOD (fonctionnement standard historique).
  • Si le code vaut 1, alors on gère les zones paramétrées dans les structures de type XXX_CMP (EVE_CMP pour les entêtes d’évènement, OPE_CMP pour les opérations commerciales, …).
  • Si le code vaut 2, alors les zones paramétrées sont gérées principalement dans les nouvelles structures XXX_CMP, à l’exception de certaines de ces zones qui « restent » datées et par conséquent gérées par la table ZOD .

Pour connaître la zone gérée en mode datée ou non, un indicateur « Indcmpzod » est utilisé dans la table ZON.

3a MODE « R » : LECTURE DES ZONES PARAMÉTRÉES

Si une liste de ZoneParametree est renseignée en entrée de l’API :
  • Pour chaque ZoneParametree :
    • Si la zone recherchée est datée (table ZOD ), lecture de la table ZOD avec une datzod <= date du jour (si date non renseignée en entrée d’API)
    • Si la zone recherchée est non datées (table XXX_CMP), lecture de la table XXX_CMP correspondante afin de récupérer les 100 valzn correspondantes et lecture éventuelle de la table ZOD si une des données paramétrées (parmi les 100 valzn lues) est gérée en mode datée (code = 2).
Si aucune ZoneParametree n’est renseignée en entrée :
  • Boucle sur les 10 enregistrements à récupérer

Même principe que pour la lecture d’une zone paramétrée.

3b MODE « C », « U », « M » : MISE À JOUR DES ZONES PARAMÉTRÉES

Si une liste de ZoneParametree est renseignée en entrée de l’API :
  • Pour chaque ZoneParametree :
    • Si mode = 1 ou 2 (mode non datée) : chargement d’un tableau contenant les valeurs des zones paramétrées à mettre à jour et mise à jour éventuelle des zones paramétrées datées dans la table ZOD .

      Mise à jour des enregistrements dans la table XXX_CMP à partir du tableau.

    • Si mode = 0 (mode datée) : mise à jour de la table ZOD avec la valeur de la zone paramétrée renseignée en entrée d’API.
      • Si l’enregistrement n’existe pas et que le mode vaut « C » ou « M »

        -> création de l’enregistrement dans la table ZOD ou XXX_CMP

      • S’il n’existe pas et que le mode vaut « U », aucune action n’est réalisée
      • Sinon modification de l’enregistrement.
    • Si aucune ZoneParametree n’est renseignée en entrée :
      • Création/Modification des enregistrements dans la table ZOD ou XXX_CMP (en fonction du paramétrage) en dupliquant les zones paramétrées du contexte origine (obligatoire dans ce cas).

3c MODE « D » : SUPPRESSION DES ZONES PARAMÉTRÉES

Si une liste de ZoneParametree est renseignée en entrée de l’API :
  • Parcours des zones paramétrées définies en entrée d’API et suppression de l’enregistrement dans XXX_CMP ou dans ZOD en fonction du paramétrage.

    Dans le cas de la suppression de zones paramétrées dans la table XXX_CMP, si certaines zones sont gérées en mode « daté », elles sont supprimées de la table ZOD.

Si aucune ZoneParametree n’est renseignée en entrée :
  • Suppression de l’ensemble des enregistrements dans la table XXX_CMP ou dans la table ZOD, relatifs au contexte défini en entrée d’API (ex : toutes les zones paramétrées du produit XXX).

Erreurs possibles

CAUSE EFFET
Le contexte à gérer ou le contexte d’origine n’existe pas :
  • Evènement inexistant
  • Poste inexistant
  • Adresse inexistante
Exception « ELT_PASTRO »
Le produit à gérer ou le produit d’origine n’existe pas Exception « PRO_PASTRO »
Le tiers à gérer ou le tiers d’origine n’existe pas Exception « TIE_PASTRO »
Le numéro de la zone paramétrées est < 100 alors que la zone est gérée en mode « daté » dans la table ZOD. Exception « ERR_PARAM »
Si la zone paramétrée existe et que l’on est en mode « C » - création. Exception « ELT_EXISDE »

Exemple(s) d’utilisation

Cette API est déployée partout dans les sources où l’on doit accéder en lecture comme en écriture aux données paramétrées des tables EVE, EVP, TIE, ADR, PRO, CAE ou OPE dans la limite du cadre fonctionnel définie ci-dessus.

Ex. Lors de la duplication d’un évènement, on duplique en autres, les zones paramétrées du poste et de l’entête. Dans ce cadre, on appelle l’API en lui passant l’évènement d’origine à dupliquer, l’évènement à créer et le mode « M » pour Manage signifiant que l’API doit créer la donnée complémentaire si elle n’existe pas pour ce nouvel évènement.