BI

Contenu dans cette page

PRINCIPE GENERAL

PARAMÉTRAGE Cegid Orli

EXPORT depuis Cegid Orli

Zone d’échange

IMPORT dans Retail Intelligence

 

 

 

PRINCIPE GENERAL

 

Objectif

Cette documentation reprend tous les éléments concernant les échanges entre Cegid Orli et Retail Intelligence. Elle s’adresse à tous (techniciens, consultants, R&D, clients).

Ce module va exporter des données depuis Cegid Orli (le Datawarehouse) vers Retail Intelligence (le Datamart), en les mettant à disposition dans un espace de partage de fichiers.

 

Contexte

La finalité est l’obtention de rapports métiers (ou cubes) utiles pour le suivi de l’activité.

 

Les traitements analytiques en ligne (OnLine Analytical Processing ou OLAP) sont utiles en informatique décisionnelle, pour aider la direction à avoir une vue transversale de l'activité de l’entreprise. On parle de cube OLAP pour désigner l’application informatique permettant l'analyse sur-le-champ d'informations selon plusieurs axes.

 

Une seule base Retail Intelligence qui regroupe les données Cegid Orli et Cegid Retail Y2 :

• assure le pilotage et le suivi de l’activité :
  • Les analyses sur les ventes : pouvoir obtenir dans le même reporting les ventes wholesale (Cegid Orli) et les ventes (Cegid Retail Y2)
  • Les analyses sur les ventes consommateurs (celles de Cegid Retail Y2, et celles récupérées par Cegid Orli via le portail B2B)
  • Les analyses sur les stocks de produits finis : dans un même reporting, visualisation des stocks des dépôts de Cegid Orli et les stocks des boutiques (Cegid Retail Y2)
• optimise les prises de décision
• allège les systèmes de production
• centralise les données de tous les métiers
• analyse le résultat de la simulation client de Cegid Orli (‎car peu d’informations pour analyser ceci côté Cegid Orli).
• mesure la fiabilité d’un fournisseur (respect de ses délais confirmés), la qualité de livraison (écart entre délais confirmés, et délais réels de livraison) à la fois sur les commandes clients et les achats fournisseurs (point fort et différentiel de Cegid Orli).

Les échanges de données Cegid Orli nécessaires à Retail Intelligence (BI) n’ont pas d’impact structurel dans Cegid Orli.

 

Cegid Orli met à disposition des données dans le Datamart de Cegid Retail Y2, pour la génération d’états existants dans Retail Intelligence sur l’activité wholesale (achat, vente, stock).

 

Cinématique

• Paramétrage Cegid Orli

  JP201 / JP202 / JP212

• Export depuis Cegid Orli

  XC500

• Zone d’échange

Depuis l’explorateur Windows

\\SRV-BI\vtNextDW\DB_OW\BatchRepositoryIn

• soit via Partage CIFS
  ‎ (Pour plus de précisions, Cf. Installation)
  
• soit via Partage de répertoire
  ‎ (Pour plus de précisions, Cf. Environnement de Base et JP015)

• Import dans Retail Intelligence
  Depuis console via navigateur :

http://SRV-BI/reports

• Restitution Datamart :

Pour plus de précisions, Cf. Analyses KPI

 

Prérequis d’installation

La mise en place en production ne pourra se faire qu’après installation et contrôles sur une base de test. La mise en place des échanges avec Retail Intelligence est disponible en standard avec Cegid Orli et nécessite une installation particulière, via le module technique MOD-BI. Ce module ne gère pas la mise en place de Retail Intelligence, mais uniquement le connecteur pour alimenter le Datamart de Retail Intelligence.

 

Avant tout échange de données, vérifier l’intégrité des données dans la base Cegid Orli :

• analyses techniques et fonctionnelles préalables de mise en place
  ‎ (Intervention Consulting et Prestation technique).
• contrôle et analyses de la base de données à transmettre à Retail Intelligence
  ‎ (Intervention R&D Cegid Orli).
• mise en place (paramétrage Cegid Orli) et initialisation des données dans la BI
  ‎ (Intervention Consulting BI)

 

Actions à prévoir pour installer les échanges côté Cegid Orli

Copie base Cegid Orli de production vers base de test
(Support technique Cegid Orli)

Installation interface sur base de test

Mise en place paramétrage standard Cegid Orli
(Intervention R&D Cegid Orli)

• Vérification des règles d’intégrité des données Cegid Orli à transmettre à Retail Intelligence
  (AS500 + AS601 + AS602 au minimum).
  ‎Prévoir le « nettoyage » des données (Liens perdus, doublons éventuels, …)
  (Intervention R&D Cegid Orli)
• Initialisation du Datamart de Retail Intelligence et timing pour future mise en place en production (Intervention Consulting BI)

 

Activation du suivi des données
(Intervention R&D Cegid Orli).

Installation base de Production

Mise en place paramétrage standard Cegid Orli
(Intervention R&D Cegid Orli)

Vérification des règles d’intégrité des données Cegid Orli à transmettre à Retail Intelligence
(AS500 + AS601 + AS602 au minimum).

Prévoir le « nettoyage » des données (Liens perdus, doublons éventuels, …)
(Intervention R&D Cegid Orli)

Initialisation du Datamart Retail Intelligence
(Intervention Consulting BI)

Activation des Triggers de suivi des données
(Intervention R&D Cegid Orli)

Automatisation des extractions via le planificateur de tâches, création de filtres
(Intervention Consulting BI).

 

Synchronisation des données

En plus de la mise à jour quotidienne, Cegid conseille de réinitialiser régulièrement le Datamart de Retail Intelligence avec les données de Cegid Orli.

 

 

Cohabitation entre Cegid Orli / Cegid Retail Y2 / RETAIL INTELLIGENCE

Il est possible de faire cohabiter dans Retail Intelligence des données provenant d’origines différentes. Si vous êtes dans ce contexte, il faut prendre contact avec le service consulting pour paramétrer cette transition.

Mise en place interface avec Cegid Retail Y2 a posteriori de l’interface avec la BI.

L’intervention d’un consultant est indispensable. Penser à vérifier et modifier si nécessaire :

 

TA962 : Paramétrage export -> Cegid Retail

Onglet : Articles/Familles et Statistiques

 

En l’absence d’interface entre Cegid Orli et Cegid Retail Y2, ‎paramétrage d’export par défaut des familles :

1.  = Société
2.  = Réseau
3.  = Marque
4.  = Activité
5.  = Famille matière commerciale
6.  = Ligne de produit fini
7.  = Forme
8.  = Nature de produit fini

 

Si la mise en place de l’interface Cegid Orli / Cegid Retail Y2 implique de changer ces critères, il est nécessaire de renvoyer en mode « initialisation » tout le référentiel « article » à Retail Intelligence.

Voir intervention consultant pour cette action.

La modification de l’option de codification du code article implique la même action.

 

Règles de base

• Cegid Orli n’envoie pas les traductions. C’est la langue du site qui est envoyée à Retail Intelligence
• Cegid Orli ne gère pas les suppressions des entités gérées en différentiel (Exemple : une commande client envoyée à Retail Intelligence puis supprimée dans Cegid Orli).

  Sauf : suppression des livraisons et suppression des factures/avoirs fournisseur.

  Il est interdit de supprimer des données Cegid Orli quand celles-ci ont pu être envoyées à la BI, il y a un risque de détruire la cohérence entre Cegid Orli et BI. La seule solution, dans ce cas, est une réinitialisation totale des données.

  Activation obligatoire de l’option : LA001W01/SUPPR_LIGNE=2

• Cegid Orli n’envoie pas les images des produits finis (BLOB)
• Cegid Orli envoie uniquement les produits finis/coloris/tailles mouvementés au moins 1 fois
  ‎(Cegid Orli envoie à Cegid Retail Y2 les produits finis ayant au moins 1 GENCOD)

 

PARAMÉTRAGE Cegid Orli

La mise en place des échanges avec Retail Intelligence est disponible en standard avec Cegid Orli et nécessite une installation particulière, via le module technique MOD-BI

 

JP201 : Partenaire

JP201W01
Fonction de paramétrage des extractions de données à destination de la BI (le moteur XC500 permet ensuite de lancer l’extraction)

 

Gestion des partenaires (exemple : Retail Intelligence) avec lesquels Cegid Orli peut échanger des données.

Seule l’équipe R&D Cegid Orli détient les droits pour créer de nouveaux partenaires et leurs versions d’échanges.

‎Pour chaque Partenaire, on visualise :

• les versions d’échanges disponibles (Ses versions disponibles)
• la version actuellement activée (Coche ‘Activée’)

‎Pour activer une version pour un partenaire, il suffit de cocher, parmi les versions disponibles, la version à activer et valider.

Cette activation déclenche le suivi des données, c’est-à-dire l’enregistrement des événements (création, modification, suppression) sur les données concernées par l’échange avec le partenaire.

 

Jeu de caractères des fichiers : définit le codage des caractères qui est utilisé dans les fichiers échangés avec le partenaire.

 

Répertoire externe : le répertoire d’extraction des fichiers vers le partenaire est à indiquer ici dans le cadre de l’envoi des fichiers zippés vers AzureStorage. C’est vers ce répertoire que seront extraits les fichiers zippés dans le cadre d’un XC500 avec ‘Génération des fichier’ vers ‘Répertoire externe du partenaire’.

N.B. :
ce type de génération des fichiers est obligatoire pour les clients en Saas Cegid Orli.

Date de dernier traitement : date de la dernière génération des données. C’est-à-dire la date à partir de laquelle il faudra envoyer les données de suivi.

Changer : permet de modifier la date de dernier traitement (dans le cas où un problème se serait produit dans la phase d’échange et qu’il faudrait retraiter les données suivies depuis une date antérieure). Il est possible de modifier cette date jusqu’à 15 j en arrière du dernier traitement affiché. Ceci permet d’extraire à nouveau les données suite à un éventuel problème de perte de fichier ou autre.

Entités partenaire : ce bouton donne accès à la fonction (JP201W02) de gestion des entités du partenaire composé des informations fournis par le partenaire : Code, Libellé et Numéro d’ordre. Une entité partenaire peut être éclatée en plusieurs versions (numéro entre parenthèse à la fin du code) si le lien avec les données Cegid Orli est trop complexe (exemple : liée à plusieurs entités Cegid Orli).
‎

JP202 : Partenaire-Version

JP202W01
Fonction de description par Partenaire/Version des données Cegid Orli transmises au partenaire

 

L’écran se divise en plusieurs parties :

 

Entité :
‎Liste des entités partenaires définies au niveau de JP201 Partenaire

 

Libellé :
‎Libellé de l’entité partenaire

 

Numéro d’ordre :
‎correspond à l’ordre d’intégration des données par le partenaire

 

Envoi des données :
‎permet d’indiquer comment les données sont envoyées au partenaire

 

Type d’entité :
‎permet de faire une correspondance entre l’entité partenaire et l’entité Cegid Orli

 

Table principale Cegid Orli :
‎table mère de recherche des données pour l’entité partenaire

 

Critère date :
‎DATE de la table principale utilisée comme critère restrictif lors de l’initialisation de l’entité

 

Table :
‎Liste des tables du partenaire rattachées à l’entité partenaire

 

Libellé :
‎Libellé de la table

 

Script :
‎Permet de traiter les cas complexes d’extraction/transformation des données en ajoutant une restriction sur la table principale Cegid Orli.

 

Dans la partie ‘Table’, le bouton ou la touche de création permet l’accès à JP201W03.

‎ 

JP201W03 : Table partenaire

JP201W03
Fonction de définition de table pour un partenaire dans une version.

 

• Entité partenaire associée à la table
• Libellé de la table
• Script :
  Permet de traiter les cas complexes d’extraction/transformation.
• Test SELECT :
  Permet de tester le SQL d’extraction/transformation.
• Colonne :
  Liste des colonnes de la table
• N° ordre : 
  Numéro d’ordre unique de la colonne dans la table
• Libellé :
  Libellé de la colonne
• Type :
  Type de donnée SQL de la colonne
• Longueur :
  Longueur maximum de la colonne
• Nb Décimales :
  Nombre de chiffres possibles après la virgule
• Coches :
  Vide possible - Clé primaire - Unique
• Déf Partenaire :
  Définition de la colonne selon le partenaire
• Coche Utilisé :
  si coché, indique que la donnée sera envoyée
• Table et Colonne Cegid Orli :
  Pour construire la partie SELECT de la donnée
• Déf Cegid Orli :
  Description de la donnée extraite dans Cegid Orli
• Doc Utilisateur :
  Aide utilisateur

 

 

JP212 : Liste tables colonnes partenaire

JP212W01
Fonction de consultation des données de tables partenaire.

 

MUL de consultation des données saisies dans JP201W03-Table partenaire.

Il est possible de demander un Export Excel.

Le bouton ‘Actions complémentaires’ permet d’accéder en consultation à JP201W03.

‎ 

EXPORT depuis Cegid Orli

 

XC500 : Extraction vers Retail Intelligence

XC500W01
Fonction d’extraction des fichiers Cegid Orli à destination de Retail Intelligence.

 

Cette fonction se compose de plusieurs onglets de critères :

• Fonctionnels
  • Type de traitement (Mode d’envoi) 
    • INITIALISATION SANS date dernier envoi
      ‎(ni contrôles de cohérence, valable pour toutes les entités)
    • SUIVI AVEC date dernier envoi JP201
      ‎(et contrôles de cohérence si on ne renseigne pas de critères sélectifs)
  • Mode Purge :
    • X : purge des données déjà envoyées à la BI pour l’entité
    • vide (mode normal, pas de purge des données déjà envoyées à la BI)
  • Génération des fichiers :
    • 0 / Répertoire externe du partenaire :
      ‎dans le répertoire /orli/editions/temp/NUM_DEM du serveur d’édition ;
      ‎utilisation du routage Répertoire (SFTP, Azure Storage) ‎défini dans JP201 pour accéder au répertoire de partage de la BI ‎et y déposer des fichiers (données compressés .ZIP par tranches de 20Mo, puis configuration compressée .ZIP)

      Ce mode est obligatoire si vous êtes dans un contexte Saas Cegid Orli.

      Dans ce cas, il ne faut pas indiquer de répertoire sur la seconde page de routage de la demande.

    • 1 / Routage de l’édition :
      ‎dans le répertoire /orli/editions/temp/NUM_DEM du serveur d’édition ;
      ‎utilisation du routage de la demande pour accéder au répertoire de partage de la BI (de préférence routage Répertoire) ‎et y déposer les fichiers résultats (.DAT et .FMT, non compressés)
    • Vide / Serveur base de données :

      dans le répertoire $ODIS/PXC_BI de ce serveur ; un partage CFIS doit alors être paramétré entre ce répertoire et le répertoire BI (BatchRepository)

      cf. Cinématique/Zone d’échange
      ‎

      
      ‎ 

• Standards
  • Partenaire
  • Entité partenaire
  • No Ordre entité
  • Date de l’entité
• Libres
• Avancés

 

 

Les fichiers traités doivent être au format .dat (données) et .fmt (structure des données), déposés dans un répertoire de partage. Le nom du serveur SRV-BI sera déterminé lors de la phase de mise en place de la BI. Celui-ci devra pouvoir être accessible pour réaliser un partage afin de mettre à disposition les fichiers Cegid Orli pour la BI.

 

Répertoire de dépôt des fichiers :

\\SRV-BI\BatchRepositoryIn

Vider les fichiers du dossier avant chaque nouvelle demande,
‎sinon le système essaie de retraiter les fichiers stockés dans 

\\SRV-BI\DataPreparationLoad

 

Dossier associé sur le serveur :

D:\vtNextDW\DB_OW\BatchRepositoryIn

 

Un lot de fichiers généré par XC500 contient systématiquement les fichiers des tables de l’entité DATABASE_CONFIGURATION permettant de décrire et de contrôler le contenu du lot lors de l’intégration dans Retail Intelligence.

 

En cas d’un lancement du XC500 en mode ‘Génération des fichiers’ = ‘Répertoire externe du partenaire’, tous ces fichiers sont zippés dans plusieurs .zip et ce sont ces .zip qui sont transférés vers AzureStorage.

 

En cas d’un lancement du XC500 en mode ‘Génération des fichiers’ = ‘Serveur Base de données’,

XC500 bloquera l’extraction si le fichier fichier_test_cifs.txt (créé lors de l’installation sur le répertoire BI BatchRepositoryIn) n’est pas visible dans le répertoire $ODIS/PXC_BI.
‎Cela indique que le partage CIFS du répertoire d’échange est tombé.

 

AS500 : Contrôle données BI

 

AS500W01
Cette fonction garantit l’intégrité des données envoyées à la BI

 

Cette fonction regroupe les contrôles suivants :

Le mode mise à jour permet de supprimer les « vrais » doublons
‎(à savoir, n enregistrements strictement identiques).

 

(*) : indique que cette erreur, si elle n’est pas corrigée, sera bloquante lors de l’import dans la BI

‎ 

Zone d’échange

 

Schéma Fonctionnement et Répertoire de partage

 

 

 

Formalisme des fichiers Cegid Orli sur le plan technique

Tous les fichiers à importer possèdent un nom construit de la manière suivante :

 

IDORI_IDDEST_6_NOMTABLEENTITE_BCHN_FMVERSIONFORMALISME.TYPEFICHIER

 

exemple :
OW_BI_6_vtStageCustomerOrderTransaction_BCH1302344_FM6-20

 

• IDORI : Identifiant alphanumérique de la base origine (de 1 à 4 caractères), cet identifiant est paramétré dans BI ARCHITECT lors de la déclaration de la base tiers à importer
  ‎(sa valeur est donc dynamique selon le contexte)

 

• IDDEST : Identifiant de la base destinataire (de 1 à 4 caractères), cet identifiant est paramétré dans BI ARCHITECT lors de la déclaration de la base BI ARCHITECT dans un contexte de consolidation multi-bases (sa valeur est donc dynamique selon le contexte)

 

• 6 : Type de source, il s’agit d’une constante qui vaut toujours 6
  ‎ (indique qu’il s’agit d’un système externe)

 

• NOMTABLEENTITE: Nom de la table à importer (dans BI).
  ‎JP201 référence les entités gérées ; pour chacune d’elles, on peut avoir une ou plusieurs tables « partenaire » référencées dans JP201, et reliées aux tables Cegid Orli.
  ‎Ces liens sont consultables par JP212.

 

• BCHb: Mot clé « BCH » pour batch (ou lot) et numéro b de type entier et positif , donc
  ‎de 1 à 2^{^}31 (soit 2 147 483 647). Ce numéro correspond au lot à importer, il doit être unique. Le numéro d’unicité est à la charge du système source externe. Si on essaye d’importer un lot avec un numéro déjà importé, le lot sera rejeté. Si on importe un lot avec un numéro inférieur au dernier numéro de lot importé, le lot sera rejeté. Les trous sont autorisés,
  ‎mais il n’est pas conseillé d’en avoir, normalement les numéros de lots correspondent à un compteur séquentiel qui s’incrémente de 1 à chaque nouveau lot.

Il faut éviter de mettre des zéros significatifs avant le numéro du lot afin d’avoir une longueur de fichier fixe, en règle générale le numéro du lot doit être formaté tel que :

 

• IDORI_IDDEST_6_NOMTABLEENTITE_BCH1_FM5-50.TYPEFICHIER

• IDORI_IDDEST_6_NOMTABLEENTITE_BCH2_FM5-50.TYPEFICHIER

…

• IDORI_IDDEST_6_NOMTABLEENTITE_BCH17_FM5-50.TYPEFICHIER

etc…

 

BCHb : b est un numéro séquentiel propre à l’extraction vers BI

 

N.B. :
ce compteur des N° de lots est visible dans JP201
‎(un compteur par partenaire, modifiable si besoin en cas de problème de cohérence BI).

Pour les sites déjà installés :
le nouveau compteur prend la valeur de l’ancienne séquence Oracle ORLWEB_LOGID au moment de la mise à jour.

 

• FMVERSIONFORMALISME : Numéro de la version de formalisme précédé du mot clé FM tel que FM6-20, le numéro de version du formalisme est un numéro avec une partie entière et une partie décimale, la partie décimale est séparée de la partie entière par le caractère moins « - ». A partir de ce numéro le système :
  • Vérifie l’intégrité de la version.

 

• TYPEFICHIER : Extension du fichier :
  • Les fichiers traités doivent être au format .dat (données à importer) et .fmt (structure des données).

N.B. :
Le nom de la table partenaire est préfixé par vtStage

 

3 fichiers regroupent des données de configuration « CFG » :

• OW_BI_6_vStageBIEntityOfBatch…

• OW_BI_6_vStageDatabase…

• OW_BI_6_vStageFileOfBatch…

 

Dans le cas d’un routage répertoire du partenaire (JP201), ces 3 fichiers font l’objet d’un fichier « CFG » compressé additionnel (OW_BI_6_CFG_BCHb.zip), envoyé à la suite du ou des n fichiers compressés (OW_BI_6_BCHb.zip.nnn, 20Mo maxi par fichier compressé) ; comme il est transmis en dernier, ce fichier « CFG » donne à BI le signal que le transfert est terminé.

 

Liste des données non traitées

• Sont exclus :
  • La consommation matière
  • Les nomenclatures
  • Les encours de fabrication (jalons, paquets) ou d’achat
  • Les suivis des commandes fournisseurs PF au niveau atelier/phase
  • Les droits d’accès Cegid Orli (non transmis à Retail Intelligence, mais c’est Retail Intelligence qui définit ses droits d’accès, avec des niveaux plus fins que dans Cegid Orli).

‎ 

IMPORT dans Retail Intelligence

 

Vérifier dans la BI le formalisme .dat (données) et .fmt (structure des données)

 

Se connecter à Retail Intelligence

 

Lancement de l'import Retail Intelligence

 

URL:

‎http://SRV-BI/reports
‎

Aller dans :
‎System / Monitoring / Execute BI job process

• Sélectionner le Job à exécuter :
  ‎BI ARCHITECT DATA MART load
• Cliquer sur Afficher le rapport
  ‎(ce qui lance l’intégration, puis rafraichit le statut du process) :

Lorsque le message « La demande… envoyée au système » s’affiche, aller dans :

‎System / Monitoring / BI Entities status

Le devant l’un des éléments permet de visualiser le détail. Utile si message d’erreur.

 

Lorsque le statut est à ‘Ended’, les données traitées peuvent être restituées par entité.

‎ 

FAQ

 

En intégration dans Retail Intelligence

 

1. Le message « Batch : _BCH249653 (roadmap OW_BI_6_vtStageDatabase_BCH249653.dat) already imported, date : Feb 23 2015 4:21PM, package ID 06E50D53-C43C-428B-B78B-2760D36015F4, the batch is ignored for origin database OW » signifie que :
   ‎« Le lot 249653 ayant déjà été importé une fois il n’est pas possible de l’importer une 2^nde fois »

    

2. Pour vérifier un fichier importé dans la BI

    

   Le répertoire de dépôt des fichiers est :

   \\SRV-BI\DataArchiveload

    

   Sur le serveur Windows ce dossier est :

   D:\vtNextDW\DB_OW\DataArchiveload

    

   Mot de passe pour ouvrir un fichier :

‎Ext3rn1lSource

 

 

‎ 

 

1. Gestion des rejets d’intégrité

À la suite des trop nombreux cas de rejets d’intégrités lors des imports Cegid Orli, pas de blocage de l’entité en erreur en cas de problème d’intégrité : si Cegid Orli envoie une info non intègre
‎(exemple : un produit fini qui n’existe pas dans une pièce), un message d’avertissement est généré
‎(pour ce produit fini et cette pièce), et la pièce est intégrée avec une valeur NULL pour le produit fini, mais l’entité n’est pas bloquée. Il y aura néanmoins un message d’erreur global final généré pour indiquer au client qu’il il y un problème d’intégrité, mais les lots ne sont pas bloqués.

Ce comportement étant paramétrable, il pourra être modifié en fonction des clients,
‎mais c’est le comportement par défaut lors de l’installation BI avec Cegid Orli.

L’inconvénient de ne pas bloquer l’entité est le suivant : même si le produit fini est envoyé par la suite car recréé dans Cegid Orli, il faudra également renvoyer les pièces associées à ce produit fini au BI pour recréer le lien.

La version BI minimum à installer est 6.21.03

 

Dans Cegid Orli

1. Comment activer les triggers ?

   Les triggers (TRG) sont activés lors de la mise en place de la version. La table PXC_PART_OPT.TABLE_NAME est mise à jour à ce moment-là. La fonction lit JP202 (TAB_PRINC ou recherche dans partie "champs" ou interprétation du script) pour trouver la table à suivre. Événements du TRG ? Voir JP202 "Envoi de données" sur chaque entité.

   En cas de modification de la structure d’un fichier, il faut faire :

   DELETE PXC_DATA WHERE PXC_DEM=0 AND TYP_REC='FMT';

   

    

   
   ‎ 

2. Comment savoir qu'ils sont activés ?

Table PXC_PART_OPT, la colonne TABLE_NAME est renseignée lors de l'activation des triggers.

 

Consultation du DB970, ce sont les déclencheur qui commence par ‘OWPX%’

1. Comment savoir que les triggers NE sont PAS activés ?

Consultation du DB970, ce sont les déclencheur qui commence par ‘OWPX%’ 

1. Table de stockage des clefs issues des triggers ?

PXC_REC.

Installation des TRG : lancer

 

Les données restent dans PXC_REC et ne sont pas traitées de nouveau car teste avec DAT_REC et date de dernier traitement stockée dans PXC_PART_OPT (NOM_OPT = 'LAST_TODO' ).

Le bouton JP201 permet de changer la date de dernier envoi et permettre ainsi de renvoyer les PXC_REC déjà envoyés.

Après avoir changé cette date, si on précise une entité dans XC500, tous les PXC_TODO auront été créé depuis PXC_REC, mais seuls ceux concernés par l'entité saisie seront envoyés.

En fin d'extraction ces PXC_TODO sont supprimés.

Si on ne précise pas d'entité, tous les PXC_REC seront extraits.

1. Prix différent lors initialisation de la BI ?

   Le connecteur envoi en priorité les prix spéciaux pour les commandes et pièces. Si les créations /Modifications de prix de vente n’ont pas été répercutées sur les commandes avec mise en prix spéciaux, il est possible que lors de l’initialisation de la BI, le connecteur trouve un nouveau prix (dans PR022) pour la même période de tarif et donc applique ce dernier.

2. Pièces (factures/avoir) envoyées à la BI ?

Les pièces (factures/avoir) sont toutes envoyées à la BI mais elles sont « typées » en fonction du fait qu’elles soient envoyées ou non en comptabilité.

L’option FA007W01/MAJ_CLI_INT est prise en compte.

Si le type de document de la pièce ne correspond pas à la condition ci-dessous la pièce n’est pas prise en compte par la BI dans le calcul du CA.

« la fonctionnalité du type de document = ‘06’ et l’option MAJ_CLI_INT=1 »

ou « la fonctionnalité du type de document est différente de '02','03','04','05' et '06' »

 

Liste des entités gérées

 

Détail des tables associées et du nombre de champs colonnes utilisés (depuis JP212) :

‎ 

Migration OnPremise > SaaS

 

La génération des fichiers Cegid Orli vers BI nécessite un stockage Azure Storage, avec :

 

Un compte Azure Storage accessible via Microsoft Azure Storage explorer :
‎

 

Compte de stockage
exemple :

bidevorli
‎

Blob Container
‎exemple :

‎ dbowin

 

 

Un répertoire externe (JP015) :

 

Ce répertoire externe est à indiquer dans JP201

 

Le lancement du XC500 doit se faire avec :

• Génération des fichiers = ‘0’ ‘Répertoire externe du partenaire’
• Sur la page de routage, il ne faut PAS choisir l’extraction vers un répertoire
  ‎MAIS plutôt à l’écran. Le répertoire cible est celui du JP201 et non plus celui indiqué ici.