API Gestion Commun créer Zone Datée

Version ACE : 1.0  

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

GestionCommuncreerZoneDatee

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

Cette API permet de gérer les accès en lecture / écriture aux zones paramétrées (communément appelées zones datées) des tables EVE, EVP, TIE, ADR, PRO, CAE et OPE.

Attention

Cette API n’est implémentée qu’en version ACE 1.0 (CS 4.5.00).

API imbriquées : aucune.

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

Cette API n’est implémentée qu’en version ACE 1.0 (4.5.00). Les zones paramétrées pour les 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 suivant :

  • les critères de segmentation,
  • les multi-variantes (paramètre MULVAR),
  • les types « WEB » et « VAR » pour les produits,
  • la gestion des coûts (parités et unités des containers) liée au paramètre TARVEN,
  • la fonctionnalité liée au paramètre HSTOST,
  • la fonctionnalité spécifique liée au paramètre ARRCA1 ,
  • les affaires (paramètre AFFAIR).

Paramétrage (PPE)

Cette API 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 suivant :
    • Un Evenement
    • Un Poste
    • Un Tiers
    • Une Adresse
    • Un Produit
    • Un Element (de type ReferenceCatalogue)
    • Une Operation (code opération)
  • L’un des contextes d’origine suivant (facultatif) :
    • Un EvenementOrigine
    • Un PosteOrigine
    • Un TiersOrigine
    • Une AdresseOrigine
    • Un ProduitOrigine
    • Un ElementOrigine (de type ReferenceCatalogue)
    • Une 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 nouvelles structures XXX_CMP, tel que EVE_CMP pour les entêtes d’évènement, OPE_CMP pour les opérations commerciales, etc.
  • 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 TBL 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), utilisation de la table ZOD avec une date antérieure ou égale à la date du jour (si date non renseignée en entrée d’API).
    • Si la zone recherchée est non datée (table XXX_CMP), utilisation de la table XXX_CMP correspondante afin de récupérer les 100 champs de type « valzn » correspondants et utilisation é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.

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

Cas d’erreurs

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ée 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 utilisée partout 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.