SX302-Safe X3 BI v5

Sage X3
Business Intelligence
A partir de la version 5
©
Sage X3 Business Intelligence Sage 2008 Page : 1 / 44
Sommaire
1. INTRODUCTION ....................................................................................................................................... 4
2. PRINCIPE GENERAL ............................................................................................................................... 5

2.1. OBJECTIFS DE LA SOLUTION SAGE X3................................................................................................... 5
2.1.1. Une solution complètement intégrée, pilotée depuis X3 ................................................................ 5
2.1.2. Mise en œuvre ................................................................................................................................ 7
2.1.3. Paramétrage du profil utilisateur (Paramétrage/Utilisateur /Utilisateur) .................................... 9
2.2. ELEMENTS DE BASE DU DICTIONNAIRE SAGE X3 POUR LA BUSINESS INTELLIGENCE .......................... 11
3. LES ELEMENTS DU DICTIONNAIRE SAGE X3.............................................................................. 12

3.1. LE DATAWAREHOUSE ......................................................................................................................... 12
3.1.1. Définition ..................................................................................................................................... 12
3.1.2. Paramétrage (Développement/Business Intelligence/Datawarehouse) ....................................... 14
3.2. LE DATAMART .................................................................................................................................... 15
3.2.1. Définition ..................................................................................................................................... 15
3.2.2. Paramétrage ................................................................................................................................ 16
3.3. LES TABLES DE FAIT............................................................................................................................ 17
3.3.1. Définition ..................................................................................................................................... 17
3.3.2. Paramétrage ................................................................................................................................ 19
3.4. LES DIMENSIONS ........................................................................................................................... 25
3.4.1. Définition ..................................................................................................................................... 25
3.4.2. Les dimensions pères et fils.......................................................................................................... 25
3.4.3. Paramétrage ................................................................................................................................ 25
3.5. LES HIERARCHIES ......................................................................................................................... 29
3.5.1. Définition ..................................................................................................................................... 29
3.5.2. Paramétrage ................................................................................................................................ 29
3.6. LES CONDITIONS PREDEFINIES.................................................................................................. 31
3.6.1. Définition ..................................................................................................................................... 31
3.6.2. Paramétrage ................................................................................................................................ 31
4. LES REGLES DE SYNCHRONISATION ............................................................................................. 32

4.1. GENERALITES ..................................................................................................................................... 32
4.2. ALIMENTATION DES DONNEES DU DATAMART .................................................................................... 32
4.3. REGLES D’AFFECTATION ..................................................................................................................... 32
4.4. ONGLET ORIGINE ................................................................................................................................ 34
4.5. ONGLET DESTINATION........................................................................................................................ 34
5. LA VALIDATION DU DATAWAREHOUSE ....................................................................................... 35

5.1. PARAMETRAGE.................................................................................................................................... 35
6. LA SYNCHRONISATION DU DATAWAREHOUSE.......................................................................... 37
6.1. PARAMETRAGE ................................................................................................................................... 37
©
7. LA GENERATION DE L’UNIVERS...................................................................................................... 39
7.1. DEFINITION ......................................................................................................................................... 39
7.2. PARAMETRAGE ................................................................................................................................... 39
8. LA TRADUCTION DES ETATS............................................................................................................. 40
9. LE MAPPING DES ETATS ..................................................................................................................... 41

9.1. DEFINITION ......................................................................................................................................... 41
10. LES ETATS BUSINESS OBJECT...................................................................................................... 42

10.1. PROCESSUS DANS SAGEX3 ET BO....................................................................................................... 42
10.2. IMPRESSIONS ...................................................................................................................................... 42
10.3. LANCEMENT DE L’ETAT ...................................................................................................................... 43
©
1. INTRODUCTION
Qu’est ce que la Business Intelligence ?
La business intelligence couvre l’ensemble des technologies permettant en bout de chaine d’apporter
une aide à la décision.
Pour être aidé dans ses choix, le décideur a besoin d’une information exacte lui permettant de jauger
son activité à l’aide d’indicateurs de performance clefs. Sans cette démarche critique, les décisions
perdent de leur acuité ou prennent beaucoup plus de temps.
Leur besoin se tourne donc vers une analyse poussée qu’il est possible d’affiner en reformulant
différemment la requête.
Les 4 grandes étapes de la chaine ou du processus décisionnel sont :
¾ Etape 1 : extraction des données

Pour produire les indicateurs voulus, il convient d’aller chercher les données utiles où
elles se trouvent.
Connecté aux différentes applications et bases de données, l’outil d’ETL (EXTRACTION
TRANSFER LOADING) se charge de récupérer ces données et de les centraliser dans
une base de données particulière, l’entrepôt des données ou datawarehouse. L’ETL doit
donc pouvoir se connecter aux sources qu’il s’agisse des applications ou des bases de
production.
¾ Etape 2 : consolidation :
Une fois les données centralisées, celles-ci doivent être structurées au sein de l’entrepôt
de données. Il s’agit d’un prétraitement permettant aux outils d’analyse d’y accéder plus
facilement, sachant que ces Datawarehouses ne sont pas renseignés à la main.
¾ Etape 3 : traitement
En fonction d’une question plus ou moins complexe posée à l’aide d’un formulaire, l’outil
d’analyse recueille la requête et confronte les données correspondantes, de façon à
produire les indicateurs voulus.
¾ Etape 4 : restitution :
Egalement appelée reporting, cette étape se charge de diffuser et de présenter les
informations à valeur ajoutée de telle sorte qu’elles apparaissent de la façon la plus lisible
possible pour le ou les décideurs(s).
L’objectif de la Business Intelligence est de préparer les données afin que celles-ci soient facilement
utilisées pour la création ou modification d’état, sans avoir le besoin d’avoir une bonne connaissance
ni du modèle de données, ni de la technique de développement.
©
2. PRINCIPE GENERAL
2.1. OBJECTIFS DE LA SOLUTION SAGEX3
¾ Intégrer une solution de Business Intelligence dans l’offre Sage X3 :
Pré-packagée (incluant des états prêts à l’emploi)

Basée sur le dictionnaire X3 pour permettre
- La traduisibilité des intitulés
- La gestion des spécifiques
- La livraison par patch
¾ Les choix faits :
Utiliser une base de données dédiée (datawarehouse ) avec une structure adaptée à
l’analyse décisionnelle.
Paramétrer à la fois cette recette structurelle et les règles d’alimentation ( ETL
intégré), afin de générer automatiquement l’ensemble depuis X3
Se baser sur Business Objects et générer automatiquement l’Univers correspondant
Etre en mesure d’appeler un état BO exactement comme un état Crystal Reports
(avec passage d’arguments et zooms vers X3)
2.1.1. Une solution complètement intégrée, pilotée depuis X3
Clients X3
Serveur X3
ERP X3
Données de gestion Serveur BO (WebI)
Etats
Dictionnaire des données
Dictionnaire BI
Univers Business Object
Règles de transformation
Base de données
Serveur batch Business Intelligence

(DATAWAREHOUSE)
©
La solution choisie par Sage X3 est celle de Business Objects : Web Intelligence ou appelé plus
communément Webi.
¾ Pour se connecter à Business Objects Enterprise : cela implique de :
Soit passer par Sage X3 (Impressions/Exécution BO)
Soit lancer le navigateur (par exemple : Internet Explorer) et saisir l’url permettant
l’accès au serveur BO (on arrive à une fenêtre INFOVIEW)
©
Pour utiliser Infoview, il n’est pas nécessaire d’installer les logiciels supplémentaires sur l’ordinateur.
INFOVIEW est une interface web à laquelle les utilisateurs finaux accèdent pour visualiser, planifier et
assurer le suivi des documents publiés.
Toutes les requêtes BO effectuées par l’utilisateur sont dirigées vers le niveau d’application BO.
Le serveur web transmet directement la requête utilisateur à un serveur d’application où la requête est
traitée par le Web Composant Adapter( WCA)
2.1.2. Mise en œuvre
¾ Code Activité : ABI. (Les fonctions de la BI sont conditionnées par le code activité ABI.)
¾ Valeurs Paramètres superviseurs : groupe BI dans lequel on renseigne 9 pyramides

sections. 1 pyramide section par axe, 3 pyramides natures et sur chaque niveaux de
pyramides : 5 niveaux.
Valeurs paramètres SUP groupe BI
©
¾ Le paramétrage de la Business Intelligence se situe au niveau du menu Développement
dans SageX3.
¾ Le déroulement du processus dans Sage X3 s’effectue de la manière suivante :
Décrire la structure
Générer la structure dans la base Business Object
Décrire les liens entre la base d’exploitation et la base décisionnelle pour la mise à
jour
Extraction des données.
Génération des univers BO
Interface BO.
¾ La base Business Object est différente de la base X3.

(dans la ligne 100 par exemple, la base est la même mais les volumes sont différents :
Dans ce cas pour Business Object : il y a une base virtuelle)
¾ Préconisation : 2 serveurs distincts et deux machines.
Pour avoir uns structure de données épurée (afin de ne pas retrouver toute la base
d’exploitation)
Pour que les requêtes de Business Object ne ralentissent pas la base d’exploitation.
¾ L’architecture complète de la BI se déclare dans X3. Le superviseur gère ensuite l’ensuite

des éléments dans la BI
¾ L’alimentation de la base Business Object se fera donc soit par re génération totale soir
en incrémentale.
©
¾ Sage X3 passe par son propre ETL (plutôt que de prendre un de ceux existant sur le
marché)
2.1.3. Paramétrage du profil utilisateur (Paramétrage/Utilisateur

/Utilisateur)
¾ Business Object définit ses propres utilisateurs (cf. cours Administering)
A réaliser dans Business Object

Affectation d’un mot de passe dans Business Object
¾ Sage X3 permet d’enregistrer des profils utilisateurs associés : Rajout d’une zone : Profil
BI : dans une table dédiée
Dans cette zone, on associe le code utilisateur BO et le code utilisateur X3.

Avec enregistrement du mot de passe BO dans une table SAGEX3(pour permettre
une authentification automatique) via le menu Fonctions/mot de passe BI
Table AFCTFCY : table des autorisations site : est recopiée dans la base BO avec
transcodage de l’utilisateur puisque BO ne connait que ses utilisateurs.
Il y a réunion des droits dans BO
Ex : si on fait des groupes utilisateurs BO avec des profils différents il y aura union
des droits sur les sites différents
¾ En effet Sage X3 ne sait pas créer d’utilisateurs dans BO
On sait par contre, importer les utilisateurs par fichier texte (il faut créer le modèle
d’import) : celui-ci n’existe pas encore
©
¾ Profil BI (Paramétrage/Utilisateurs/Profil BI)
©
2.2. ELEMENTS DE BASE DU DICTIONNAIRE SAGEX3 POUR LA BUSINESS INTELLIGENCE
> Un datawarehouse qui contient

− Un ou plusieurs datamarts
Vocabulaire générique de la
> Un datamart qui contient
− Une ou plusieurs tables de faits
business Intelligence
− Un ensemble de dimensions
− Des hiérarchies
− Des conditions prédéfinies
> Des éléments complémentaires Concepts spécifiquement
− Une table d’association avec liés à Business Object
des utilisateurs BO
− Des états BO
− Un dictionnaire des états BO Eléments liés à X3 et au
− Des règles de synchronisation liens entre X3 et la BI
©
3. LES ELEMENTS DU DICTIONNAIRE SAGE X3
3.1. LE DATAWAREHOUSE
3.1.1. Définition
¾ Le Datawarehouse ou Entrepôt de données correspond à une instance de base de données.
¾ L'entrepôt de données, ou datawarehouse, est une méthode spécifique de l'informatique

décisionnelle, issue d'un constat simple : les données de l'informatique de production
(également appelée « transactionnelle »), notamment les progiciels de gestion intégrés (ou
ERP, Enterprise Ressource Planning) ne se prêtent pas à une exploitation dans un cadre
décisionnel
Les systèmes de production sont construits dans le but de traiter des opérations individuelles
qui peuvent impliquer différents métiers de l'entreprise et surtout, sans se préoccuper de leur
compilation dans le temps. À l'inverse, les systèmes décisionnels doivent permettre l'analyse
par métiers ou par sujets et le suivi dans le temps d'indicateurs calculés. Il est donc souvent
indispensable de séparer ces deux mondes et repenser les schémas de données, ce qui
implique l'unification des différents gisements de données de l'entreprise en un entrepôt de
données global (datawarehouse) ou restreint par sujet/métiers (datamart).
¾ On va le subdiviser en plusieurs parties. Ces parties seront appelées un DATAMART.
¾ D’un point de vue technologique, il n’y a à priori que très peu de différence entre un
datawarehouse et un datamart. Les deux sont des entrepôts de données à part entière.
Mais sur son utilisation, le datawarehouse s’avère complètement centralisé et

regroupe des informations en provenance d’applications transversales ou disséminées
à travers l’entreprise, en vue de produire une vision plus globale lors de l’étape de
restitution.
De l’autre coté, le datamart est plus spécialisé suivant une fonction ou un domaine
vertical de l’entreprise.
¾ Il est alimenté par un dossier (à terme par plusieurs)
¾ Défini par des paramètres au niveau de la console d’administration, et par une fiche.
¾ La plateforme de Business Intelligence de BO isole l’utilisateur final de la complexité et de la

diversité des sources de données.
Elle respecte la terminologie métier dont l’utilisateur a l’habitude et qui est partagée dans t
toute l’entreprise.
©
¾ Business Object n’est pas destiné à produire du papier comme Crystal Reports mais plutôt
destiné à produire des résultats sur un écran. Et donc surtout à être utilisé en interactif
Pour cela aller dans INFOVIEW / préférences /Web Intelligence: pour BO,
paramétrage en HTML interactif
¾ La visualisation des documents Web Intelligence au format HTML interactif permet de

modifier les options d’affichage d’un document.
Les options disponibles sont :
Les calculs simples de type somme, moyenne

Les filtres express pour n’afficher qu’une partie des données
La transformation en graphique ou en différents types de tableaux
Le tri croissant, décroissant ou personnalisé.
©
3.1.2. Paramétrage (Développement/Business Intelligence/Datawarehouse)
¾ On peut mixer les environnements Oracle, SQL.
¾ Dans la fiche Datawarehouse : on renseigne
La machine
Le service
Le dossier : comme si c’était un dossier X3
¾ Zone dimensionnement : Uniquement pour oracle : on peut laisser cette zone à vide (celle-ci
est gérée en méga octets)
¾ Zone Format : Unicode ou ascii
¾ On renseigne les datamarts les dossiers
La solution est multi dossier (plusieurs dossiers X3 peuvent alimenter 1 solution BO)
Dans ce cas, il faut faire attention aux identifiants (ex : 2 dossiers avec le client
TOTO.
On a limité artificiellement à un seul dossier. (variable GADONIX =2 pour modifier le
nombre de dossiers)
En cas de multi dossier : problème de régénération complète (pas de contrôle) il faut
donc créer un dossier maitre.
Ne pas écrire le datawarehouse dans chaque dossier (impliquerait un problème de
performance)
©
3.2. LE DATAMART
3.2.1. Définition
¾ Chaque Datamart va générer un univers.
¾ Un utilisateur lambda ne connait rien aux bases de données. Pour cette raison, on interroge
un « univers BO »
¾ Univers : c’est la représentation métier de données permettant aux utilisateurs d’interroger

une base de données et d’analyser avec leur vocabulaire quotidien.
Exemples : Ressources Humaines, Contrôle de gestion, Gestion commerciale.
Il est possible de faire des états multi –univers.

Webi permet de créer un document comprenant plusieurs requêtes portant sur un ou
plusieurs univers.
¾ Les Univers sont constitués d’objets : ceux-ci seront directement manipulés par les
utilisateurs : dimensions, mesures, informations et dimensions pères.
Exemple : pour un univers de type gestion commerciale : la date de commande, le

nom de l’article, la quantité cédé, le CA
¾ De même ces objets peuvent être regroupés en classes et sous classes : i.e. regroupement
thématiques d’objets tel que pour le Produit : le nom du Produit, le prix du produit, la gamme
du produit.
Il faut faire attention car on ne peut avoir deux classes avec le même nom
¾ Un Datamart contient un ensemble de table de fait reliés à des dimensions.
Les tables de fait : ce sont des tables de mouvement.

Chaque ligne de la table va caractériser un fait (exemple : tel client achète tel article à
tel prix avec telle remise)
Les dimensions sont des pointeurs vers d’autres tables.
¾ Il existe plusieurs structures dans les datamarts :
Schéma en étoile : la table de fait est au centre et les tables de dimensions autour
Schéma en flocon : même principe que dans le schéma en étoile mais certaines
dimensions sont normalisées
Schéma en constellation : plusieurs tables de fait pour décrire plusieurs séries de
données sur le métier étudié et partageant les tables dimensionnelles
(Exemple: Table de fait des expéditions ayant pour table de dimension temps, article,
site)
©
3.2.2. Paramétrage
¾ Dans le cadre de l’implémentation Sage X3, un datamart par groupe de modules
(Comptabilité, Production, Stock/négoce)
¾ En général : on essaie de créer une table de fait par datamart afin de ne pas faire des univers
trop gros
Limite à ne pas dépasser : 300 objets dans la table de faits. (dimensions, mesures,
informations et dimensions pères)
¾ Zone Abréviation : faire attention à l’unicité sur les abréviations.
¾ Zone autorisation site : certaines fonctions ont des autorisations sites
Par exemple : la saisie du code client sur un site.

On a voulu reproduire dans BO cette autorisation pour que l’utilisateur ait les mêmes
droits dans BO que dans X3.
Si on coche autorisation site : on précise la fonction (habilitation fonctionnelle) pour ne
pas avoir à refaire une autre couche d’habilitation.
BO a ses propres habilitations (cf. cours Administration)= on décoche alors
autorisation site
¾ Limiter la taille du résultat : si « 0 » pas de limite.
¾ Limiter l’exécution : si « 0 » pas de limite
©
3.3. LES TABLES DE FAIT
3.3.1. Définition
¾ Gère le détail le plus fin des informations que l’on souhaite analyser.
¾ Les tables de fait : contiennent 4 types de données
Dimensions : ce sont des critères d’analyse et de regroupement qui peuvent pointer

vers d’autres tables. Elles permettent d’effectuer l’analyse multidimensionnelle et la
synchronisation.
Exemple : le client, une date (stockée dans la table des dates)
Informations : Ce sont des précisions sur le fait (exemple : le commentaire, le

numéro de commande, adresse) Celles-ci n’ont pas vocation à regroupement. Elles
sont toujours associées à un objet dimension auquel elles apportent des informations
complémentaires (détail).
©
Mesures : Valeurs que l’on analyse à différents niveaux d’agrégation.
Une mesure, c’est ce qui quantifie un fait (exemple : le prix de vente, la quantité, la
remise).
Elles permettent d’extraire des données numériques résultant de calculs effectués sur
les données d’une base de données.
Zones techniques : pour gérer les habilitations par exemple
¾ Exemple : dans une table de fait
Dimensions (zone en gris)

Mesures (zone en vert)
Informations (zone en orange)
Zones techniques (zone en rose)
Type Date Numéro de pièceSociété

Société Site Compte Tiers Nature Section 1… Section N Montant
Jour Mois
Compte Cumul 3
Semaine
Trimestre Cumul 2
Devise
Semestre Site Cumul 1
Année Ville Société juridique
©
3.3.2. Paramétrage
Il se fait sur 5 onglets
3.3.2.1. Onglet description :
¾ Autorisation site : Permet de définir automatiquement un filtrage des données par site. Les
sites autorisés à un utilisateur pour un état sont définis par l’intermédiaire d’un code fonction.
Cette autorisation s’effectue table de fait par table de fait.
¾ Infos épurations : se base sur un champ de type date.
Par défaut, le champ ACCDAT est proposé.
¾ Type mise à jour : « Incrémental » ou « Annule et remplace » : Permet de définir la façon dont
la mise à jour des données est faite.
Cette mise à jour passe par le système d’audit (cf. la doc superviseur). Table
déclenchante + trigger
Si les tables de fait sont de petites tailles : il est possible de passer par la mise à jour
« Annule et remplace ».
Sinon, il est préférable de passer par « incrémental ».
¾ Objet nombre de : nombre de ligne de la requête. Crée un objet correspondant dans l’univers.
ex : si on lance une requête sur une commande de vente : on veut le nombre de

commandes de la requête.
©
3.3.2.2. Onglet champs
¾ Les champs : sont à peu près équivalent à ceux de la table dans X3.
Mesure, dimension, information ou technique
Champ Intitulé Type Lng Date Menu Table Type objet Compte distinct Code activité
Permet de disposer d’un objet compte

par valeur de champ
Type et caractéristiques associées :
• longueur
• niveaux d’agrégation des dates
• numéro de menu local ou de table diverse
Définition du champ :
• le code est celui du champ dans la base
• l’intitulé est ce qui est vu par l’utilisateur
©
¾ Dans chaque ligne de table de fait : on a les données, les règles, l’identifiant de la table
déclenchante = clef de l’enregistrement déclenchant
¾ un code champ et son intitulé,
En V.5 .1 =possibilité d’avoir un intitulé « évalué » : par exemple : les messages

dans sage X3 ex les sections. (1= affaire 2= services)
Si c’est un champ « technique » l’utilisateur ne le verra jamais.
¾ Certains champs sont automatiquement dans les dimensions : menus locaux, tables diverses,
dates, codes accès. Si on a coché autorisation site, on a aussi les sites.
¾ 1 type de donnée au sens X3.
Si le champ est alpha ou numérique = longueur.

Si le champ est de type menu local : on a le choix
- soit d’indiquer le texte du menu local (exemple ML 1 : OUI/NON),
- soit d’indiquer le numéro du menu local (ML 1) et Sage X3 fera le lien
avec la table des menus locaux
Si date : pour BO = 1 dimension : il faut pré définir les objets que l’utilisateur
pourra voir dans BO (le standard dans BO = Q=>QUARTER trimestre) Y =YEAR
(année) M=MONTH (mois)
Autre cas : le code d’accès.
¾ Astuce : dans la Table de fait : il est préférable de créer des mesures pour le débit et le crédit
que des montants de la pièce et sens.
¾ Tunnel vers objet : possibilité dans BO d’associer un lien vers un objet X3.
¾ Compte distinct : champs sur lesquels on veut avoir une mesure particulière.
Champ type dimension
Ex le client. Il peut être intéressant de définir le nombre de client par ex = une mesure =
nombre de client dans la table de fait mais pas dans la table de dimension
¾ Code activité = utilisable lors de la création d’une table de fait spécifique par exemple.
©
3.3.2.3. Onglet liens
¾ La table de dimensions est liée à la table de faits (le lien se fait par la clé principale définie
dans la dimension)
¾ Chaque champ référencé comme une dimension doit être présent dans au moins une
expression de lien
¾ Il est possible d’avoir plusieurs fois la même dimension (clients livrés, clients facturés)
¾ Il existe des dimensions « implicites » qui n’ont pas à être définis (table des dates, des menus
locaux, tables diverses, table des codes d’accès et la table de filtrage des sites)
©
3.3.2.4. Onglet index
Sert pour l’implémentation technique (optimisation)
¾ Dans la description, on indique la syntaxe habituelle des index dans le dictionnaire Sage X3.
¾ Caractéristiques de stockage : même principe que pour les tables de base.
3.3.2.5. Onglet Agrégats
¾ Les agrégats sont des cumuls intermédiaires mis à jour par le datamart afin d’accélérer les
restitutions lorsque l’on a fait des regroupements de lignes.
¾ Afin d’éviter de relire certaines lignes, on va maintenir à jour un agrégat en temps réel .Si on
utilise les champs qui sont les dans les agrégats = on va voir dans les agrégats.
¾ Si les champs demandés lors de la requête sont hors de la liste de l’agrégat, on va voir dans
les lignes.
Ex : pour la comptabilité - Agrégat : la balance

Pour les ventes : les statistiques.
¾ L’écran des agrégats se découpe en trois parties :
Le premier tableau définit la liste des agrégats

Le second définit les champs qui composent l’agrégat de la ligne courante du
tableau supérieur
Le troisième permet de définir un index à des fins d’optimisation technique. On
utilisa la syntaxe habituelle des index dans le dictionnaire Sage X3.
©
¾ Au début, il est préférable de ne pas mettre trop de lignes dans les agrégats.
¾ Si on utilise l’autorisation site : il est impératif que le site soit dans chaque agrégat.
¾ Zone Champ : on explicite quel champ (avec la possibilité d’en avoir plusieurs. Ex : ligne 5
Period)
¾ On ne peut pas mettre plus de 16 éléments dans une clé.
¾ On peut mettre 1 index sur la table d’agrégat.
Agrégats
Nom Code activité
Dimensions
associées
à la ligne
courante Pour type
du tableau Dimensions
Date :
supérieur Type dimension Dimension Champs Niveau d’agrégation
Jour,
Mois,
Trimestre,
Semestre,
ou Année
Date, Menu local, Table diverse, ou Autre Code dans Valeur de clé affichée pour dimension Autres,
la table des ou Champ correspondant pour Date, Table
dimensions diverse, ou Menu local
(pour dimensions Autres)
©
3.4. LES DIMENSIONS
3.4.1. Définition
¾ La dimension définit une table dont la clé est un critère d’analyse et d’agrégation.
3.4.2. Les dimensions pères et fils

¾ Une dimension père : c’est un pointeur qui amène lui-même vers un pointeur supérieur
Exemple : dans la table client : on trouve un pointeur supérieur : la catégorie client

qui elle-même pointe sur un pointeur supérieur : les pays)
¾ Limites : 9 niveaux de dimensions pères
3.4.3. Paramétrage
¾ Cette table est liée à une ou plusieurs tables Sage X3 qui l’alimentent.
¾ Il est possible d’utiliser un traitement spécifique.
3.4.3.1. Onglet description
¾ Table d’origine et Filtre d’extraction : Définit la requête d’extraction de la base de production.
¾ Traitement : Il est possible de piloter par un traitement pour alimenter la table des dimensions
(par le biais d’un Point d’Entrée au début et un Point d’Entrée à la fin)
©
¾ Type de mise à jour :
Si Incrémental : la requête de mise à jour se base sur une liste de mises à jour
générées par un trigger.
3.4.3.2. Onglet champs
¾ Chaque table de dimension contient :
Des dimensions : critères d’analyse et de regroupement

Des dimensions pères : référence à une autre table de dimensions
Des informations : champs pouvant être éditées avec le détail
Des zones techniques : pour gérer des habilitations par exemple
¾ Certaines tables de dimensions sont implicites et n’ont pas besoin d’être définies dans le
dictionnaire.
Tout champ de type date fait référence à une dimension (table des dates) avec
des dimensions pères successives (mois, trimestre, année)
Tout champ de type menu local et table diverse fait référence à une dimension
stockant les choix possibles et les intitulés correspondants
Tout champ de type dossier fait référence à une dimension stockant les codes de
dossiers existants.
©
Champs
Code champ Intitulé Type Lng Date Menu Table Type objet
…
Définition champ Dimensions implicites (menus locaux, tables diverses, dates)
Formule de calcul pour alimenter

Informations liées aux dimensions le champ du datamart
Dimension liée Dimension père Nom du champ Formule alimentation Code activité
…
¾ Code champ et intitulé :
Si c’est un champ « technique » l’utilisateur ne le verra jamais.

Faire très attention à l’intitulé : il faut essayer que dans un univers tous les objets
soient différents, car l’utilisateur ne voit que l’intitulé. Par conséquent, il faut que
celui-ci soit suffisamment clair afin d’éviter toute erreur ou redondance.
Conseil : ne pas faire de doublons.
¾ Type objet :
Ex : la table BPCUSTOMER : s’il y a une dimension père : on trouve le code de la

dimension père. La dimension fils ex :
Quand c’est une information : on indique à quelle dimension elle est liée.
POSTCOD : 2 parties
POSTOD=POSTCOD et POSTCOD = POSTCTY
¾ Dimension père
On indique le nom de la dimension père + le nom de champ si la clé est à

plusieurs entrées.
¾ Attention : la formule d’alimentation : les dimensions sont des tables relativement stables. On
se base sur la date de création et de modification des dimensions.
¾ Description : Eventuellement, on peut y ajouter un filtre d’extraction.
Ex GACCOUNT. On ne veut pas les comptes de cumuls.
¾ Astuces : sur les compte=>: dimension « ACCOUNT » :
Il faut réunir numéro de compte + désignation.

Il y a création d’un champ (enfin d’une telle dimension) car BO ne sait pas réunir
le numéro de compte et la désignation.
©
3.4.3.3. Autre exemple de dimension
Onglet description
Onglet champ
©
3.5. LES HIERARCHIES
3.5.1. Définition
¾ Liste ordonnée d’objets du dictionnaire BO.
¾ Permet à BO d’explorer en regroupant ou en zoomant sur la hiérarchie.
¾ On prédéfinit les différentes hiérarchies d’analyse.
3.5.2. Paramétrage
¾ L’écran des hiérarchies est un écran de type « picking »
¾ Dans une hiérarchie on peut sélectionner des objets à partir :

D’une liste de classes (i.e. les tables de fait)
De sous classes associées (dimensions et dimensions pères)
¾ Deux boutons de type flèches permettent de déplacer les éléments de la hiérarchie = liste
d’objets (ergonomie proche de celle utilisée sous BO)
©
¾ Il permet de préciser une requête selon un ordre d’exploration prédéfini
Ex : si on fait une requête sur la somme des débits

Résultat : sera un montant global
On veut éclater ce montant par classification de compte
(par exemple, par type de compte de cumul 1, cumul2, cumul3)
Si c’est un collectif, on veut le voir par tiers.
Budget
Lignes comptables
Dimensions
Code taxe
Compte Décalage
Compte Classe Sous-classe Objet
Classification
Hiérarchie compte Picking
Compte de cumul 1
Hiérarchie compte de cumul 1
Compte de cumul 2
Hiérarchie compte de cumul 2
Devise de pièce
Ex : le chiffre d’affaire par Affaire, par client, par produit
©
3.6. LES CONDITIONS PREDEFINIES
3.6.1. Définition
¾ Ce sont des objets d’univers (ex : commande de l’année)
¾ Ce sont des filtres prédéfinis ou des restrictions « prêtes à l’emploi » crée soit par
l’intermédiaire du module BO designer soit par Sage X3.
3.6.2. Paramétrage
¾ Ces conditions sont directement exprimées dans des syntaxes SQL pour Oracle et SQL
Serveur (une seule syntaxe étant donnée si les deux sont identiques)
Attention, les champs doivent être suivis de _0,_1,_2 selon les cas)
¾ Elles sont associées à une table de fait et/ou une dimension dans un datamart.
¾ Il y a la possibilité d’utiliser la syntaxe Business Object
@prompt («???,…) où ??? est remplacé par le texte d’invite (traduisible) saisi au
préalable.
¾ Ces filtres sont directement utilisables depuis l’univers BO
¾ Contraintes : les conditions prédéfinies de type invite avec saisie de texte ne peuvent être
évaluées
Elles vont être en « … » et ceci est considéré comme une constante.
Or les constantes ne peuvent être traduites ex : les sections
©
4. LES REGLES DE SYNCHRONISATION
4.1. GENERALITES
Règles de synchronisation :
¾ Formule qui permet d’alimenter une table de fait depuis une table X3. Si une table de fait
provient de plusieurs tables X3, il faut créer plusieurs règles de synchronisation.
4.2. ALIMENTATION DES DONNEES DU DATAMART

¾ Pour les dimensions :
Formules sur les champs de la dimension

Un enregistrement de la table d’origine (et des enregistrements liés) correspond à
un enregistrement de la dimension
Une formule peut être complexe et faire appel à des expressions de type
Func PROGRAMME.LABEL(arguments)
¾ Pour les tables de faits :
Plusieurs requêtes peuvent être utilisées

Elles sont définies dans les règles de synchronisation
Chaque règle se définit en deux onglets : origine et destination
4.3. REGLES D’AFFECTATION

¾ En comptabilité :
On veut le plus détaillé possible :

La première table est donc GACCENTRYA
Puis on va descendre sur les tables GACCENTRYD et ensuite GACCENTRY
Mais on peut très bien se trouver dans un dossier où il n’y a pas d’imputation
analytique.
Donc on partira de la table GACCENTRYD pour aller sur la table GACCENTRY.
¾ Il faut donc prévoir deux règles différentes.
C’est pour cette raison que dans les règles de synchronisation, on trouve la règle
ENTRY1 et ENTRY2.
©
¾ Attention : la mise à jour se fait simultanément :
Quand on lance la resynchronisation, le traitement regarde toutes les règles de

synchronisation concernant cette table et non pas règle de synchronisation par
règle de synchronisation.
Derrière l’ETL : il y a un programme généré à chaque règle de synchronisation.
©
4.4. ONGLET ORIGINE
Code activité
Extraction
Table d’origine de la table
principale
Filtre
Clé
Traitement Cas particulier

(1,n) :
Règle de création
Champ déclenchant
(1,1) (1,n) dimensionné,
expressions de lien
Champ déclenchant
et condition
Condition ligne dépendant de la
variable indice
Liens
Jointure
Tables liées Abréviation Clé de lien Expression de lien sur des tables
complémentaires
liées (en
cascade)
à la table
principale
¾ Table origine : c’est une table Sage X3, elle sera donc auditée. (par le biais de la table
auditBI)
¾ Possibilité de faire un filtre. La clé de parcours sera utilisée en régénération totale.
Chaque modification effectuée sur cette clé sera tracée dans la table d’audit BI.
¾ Règle de création :
1,1 : un pour un
1, n : ex : les champs déclenchants sont des éléments indicés stockés dans un
tableau.
ex : les éléments de facturation. Afin de créer le nombre de lignes nécessaires, il
est possible de passer par le biais des conditions.
¾ Dossier :
Si on se trouve dans l’optique multi-dossier : si vide, on applique la règle au
dossier courant
Sinon, 1 règle ne s’applique qu’à un dossier.
Dans une première version, la Business Intelligence est mono-dossier : seul le
dossier courant est présent dans le tableau
4.5. ONGLET DESTINATION

¾ Cet onglet indique les formules de mise à jour
¾ Si le Champ est compliqué, il est possible de passer par une fonction
(ex : On peut passer par les traitements tels func.TRTACHBI ou func.TRTX3BI)
©
Table destination
Table dans
laquelle on
fait les mises
Liens à jour
Champ Intitulé
Clé de lien Formule
Tableau des
champs avec des
formules (si un
champ de même
nom existe dans
une des tables
d’origine, il est
proposé par défaut)
5. LA VALIDATION DU DATAWAREHOUSE
5.1. PARAMETRAGE
¾ Permet de créer l’user base de données et les tables correspondantes.
¾ Aussi utilisé pour faire les mises à jour en cas de changement de structure.
¾ Peut être lancé en mode forcé.
¾ 1 Datawarehouse se définit comme une collection de datamart.
©
¾ En en-tête : rien n’est saisissable à part le code intitulé et la solution BI (identifié par une
machine, une base = même structure que dans X3
ie : un dossier racine/un runtime / des dossiers (ex : 1 DTW de test / 1DTW

d’exploitation)
A l’inverse des dossiers, il n’y a pas de répertoire FIL.
¾ Il ne faut pas confondre avec la synchronisation du datawarehouse.
¾ Normalement, cette fonction se lance en batch.
©
6. LA SYNCHRONISATION DU DATAWAREHOUSE
6.1. PARAMETRAGE
¾ A faire à intervalles réguliers (habituellement en batch)
¾ Peut être fait de façon séparée sur les différentes données à synchroniser
¾ On renseigne le datawarehouse :
¾ Plusieurs options : Quelles tables mettre à jour ?
Liste ? =>si liste, il faut renseigner quel type de table BI

Toutes ? si toutes = il est préférable d’effectuer un vidage préliminaire
Incrémentale ?
¾ Type de table :
Codes accès ? =type champ ACS
©
Préconisation : ne pas mettre beaucoup de code d’accès = dans ce cas, X3 va créer des jointures en
plus Et ceci peut être couteux en terme de performance sur la requête
Calendrier
Dossier
Autorisation site
Menus locaux : autant de menus locaux (pas pour un seul menu local)
Tables diverses : autant de tables diverses (pas une seule)
Dimensions
Table de fait
Agrégats
¾ En mise à jour, on choisit les tables
¾ En exploitation, on coche : toutes.
©
7. LA GENERATION DE L’UNIVERS
7.1. DEFINITION
¾ On crée un univers pour un datamart donné
¾ Génération univers : quand on a modifie la structure, il faut recréer un univers.
7.2. PARAMETRAGE
¾ Dans le datamart : présence d’un champ abréviation. Si on ne renseigne pas le nom de

l’univers= remplit par 0001, 0002
YCO 0001
YCO 0002 et utilisé par l’abréviation.
¾ Un état BO est lié à un univers. Si on supprime un univers, l’état ne fonctionnera plus jamais.
¾ Peut être lancé en mode simulation
¾ Autorisation site et code accès : intéressant lorsque l’on veut debugger un état
¾ Mode test : détecter les erreurs ou anomalies (permet de lister les champs en doublons par
ex)
¾ Export de l’univers : en général il faut toujours le faire : l’univers on le génère sur son poste et
on l’exporte vers tout le monde.
¾ Mapping des états : possibilité de mapper les états à la génération de l’univers ou de le lancer
plus tard.
©
8. LA TRADUCTION DES ETATS
¾ Individuellement, on peut appeler les fonctions de traduction, ce qui permet de parcourir les
états et de traduite les textes.
¾ On ne sait pas traduire les constantes
¾ Par contre, si on met une variable BO avec le nom, on peut le traduire.
Traduction des états : disponible en V5.1.
Car la V5 est une version franco-française

Traduction des états : pour l’instant : mono langue. BO ne fournit aucun outil pour
être multilingue. Rien n’empêche cependant d’avoir deux Datawarehouses (un
français et un en anglais).
©
9. LE MAPPING DES ETATS
9.1. DEFINITION
¾ Mapper un état: c’est mettre en correspondance les objets et les cibles
¾ Chemin : Dossiers publics/Sage/Nom de solution
¾ Répertoire ALL : états standards livrés.
Le mapping : lors de la génération de l’univers, le mapping est le fait de recopier le

répertoire ALL vers le répertoire FRA
¾ Répertoire FRA : états « mappés »
¾ Répertoire ENG : états mappés et traduits
¾ Si les objets proviennent d’un spécifique =
Soit on le fait dans le répertoire FRA et on ne les touche pas et ensuite on les
supprime,
Soit on les met dans le répertoire ALL et ils seront pris en compte dans le mapping.
¾ Possibilité de faire soit
Mapping auto : intéressant quand on enrichit l’état

Mapping manuel
¾ On n’écrase jamais un univers sauf si on change manuellement le nom de l’univers.
¾ Limite avec le mapping : ne fonctionne pas très bien avec les hiérarchies (au maximum avec 3
niveaux au lieu de 5)
¾ En cas d’état spécifique : le mapping auto ne donne pas forcement de bons résultats (peut y
avoir des écarts)
¾ Il faut générer un nouvel univers au lieu de l’écraser puis par le mapping, créer le lien vers le
nouvel univers puis casser le lien avec le premier univers.
©
10. LES ETATS BUSINESS OBJECT
10.1. PROCESSUS DANS SAGEX3 ET BO

¾ Création d’un fichier séquentiel
¾ Processus VB
¾ Création de l’univers
¾ L’univers est exporté par la CMC
¾ Déclenchement du mapping
¾ Processus JAVA afin de récupérer les caractéristiques de chaque objet.
¾ Cependant, on utilise les exécutable X3 à partir de VB et JAVA d’après une librairie BO (tout
ce qui touche l’univers est en VB, tout ce qui touche les états est en JAVA
10.2. IMPRESSIONS
¾ Un dictionnaire des états BO existe (avec définition des paramètres)
¾ Une impression peut désormais être un état Crystal Reports, un état Business Objects, un
export, une requête, une requête SQL.
¾ La connexion BO et le lancement de se fait de façon transparente, l’état apparaissant dans

une fenêtre SageX3.
Impression /impressions /Etats BO

Paramétrage/Destinations/codes impressions : Rajout de deux codes : AREPORT :
BO et ABIMP : BO
Soit par infoview
¾ Des zooms vers des fiches liées sont possibles depuis l’état BO
¾ Les états livrés en standard dans Sage X3 sont des points de départ. Ils ne sont pas destinés
à être utilisés tels quels.
On attend les différentes remontées des clients et des partenaires sur ces points
¾ Il existe un produit BO en mode client serveur : Desktop.
Les états clients serveurs peuvent être transformés en états webi par le biais d’une
moulinette.
Pas l’inverse.
©
¾ Un état n’est utilisable qu’avec son univers. Donc n’est transportable qu’avec son univers
Pas de possibilité de transporter l’état seul

On peut patcher les tables de fait, les dimensions, etc.
Par contre, on ne peut pas mettre un univers dans un patch
Possibilité de passer par un export BIAR (mini base SQL)
10.3. LANCEMENT DE L’ETAT
¾ Faire attention au paramétrage des invites : l’invite n’a pas de code : c’est le texte(=le
paramètre = le seul identifiant dont on dispose.
BO va saisir les invites par ordre alphabétique.

La solution de contournement est la suivante : Il est préconisé de mettre un préfixe
devant =001 – date début par exemple
¾ Ces textes ne peuvent pas être évalués
¾ Type invite simple ou multiple
¾ Tout ceci n’est pas très grave si on passe par X3 car on saisit les invites au niveau X3 donc
comme elles ont été définies dans X3.On reste dans la fenêtre X3 et on arrive ensuite dans la
fenêtre BO.
¾ Si tunnel Objet : et format HTML, on a la possibilité de retourner dans X3
¾ Si on passe par INFOVIEW
1 classe par univers ex : CPT001

1 classe par table de fait
1 classe par lignes comptables
1 classe par dimensions
©
©

Langue

SX302-Safe X3 BI v5

Transféré par

Informations du document

Description :

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

SX302-Safe X3 BI v5

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Sage X3

2. PRINCIPE GENERAL ............................................................................................................................... 5

3. LES ELEMENTS DU DICTIONNAIRE SAGE X3.............................................................................. 12

4. LES REGLES DE SYNCHRONISATION ............................................................................................. 32

5. LA VALIDATION DU DATAWAREHOUSE ....................................................................................... 35

8. LA TRADUCTION DES ETATS............................................................................................................. 40

9. LE MAPPING DES ETATS ..................................................................................................................... 41

10. LES ETATS BUSINESS OBJECT...................................................................................................... 42

Qu’est ce que la Business Intelligence ?

Les 4 grandes étapes de la chaine ou du processus décisionnel sont :

¾ Etape 1 : extraction des données

2.1. OBJECTIFS DE LA SOLUTION SAGEX3

¾ Intégrer une solution de Business Intelligence dans l’offre Sage X3 :

 Pré-packagée (incluant des états prêts à l’emploi)

¾ Les choix faits :

2.1.1. Une solution complètement intégrée, pilotée depuis X3

Données de gestion Serveur BO (WebI)

Serveur batch Business Intelligence

¾ Pour se connecter à Business Objects Enterprise : cela implique de :

 Soit passer par Sage X3 (Impressions/Exécution BO)

¾ Valeurs Paramètres superviseurs : groupe BI dans lequel on renseigne 9 pyramides

 Valeurs paramètres SUP groupe BI

¾ Le déroulement du processus dans Sage X3 s’effectue de la manière suivante :

¾ La base Business Object est différente de la base X3.

¾ Préconisation : 2 serveurs distincts et deux machines.

¾ L’architecture complète de la BI se déclare dans X3. Le superviseur gère ensuite l’ensuite

2.1.3. Paramétrage du profil utilisateur (Paramétrage/Utilisateur

 A réaliser dans Business Object

 Dans cette zone, on associe le code utilisateur BO et le code utilisateur X3.

¾ En effet Sage X3 ne sait pas créer d’utilisateurs dans BO

> Un datawarehouse qui contient

¾ Le Datawarehouse ou Entrepôt de données correspond à une instance de base de données.

¾ L'entrepôt de données, ou datawarehouse, est une méthode spécifique de l'informatique

¾ On va le subdiviser en plusieurs parties. Ces parties seront appelées un DATAMART.

 Mais sur son utilisation, le datawarehouse s’avère complètement centralisé et

¾ Il est alimenté par un dossier (à terme par plusieurs)

¾ La plateforme de Business Intelligence de BO isole l’utilisateur final de la complexité et de la

¾ La visualisation des documents Web Intelligence au format HTML interactif permet de

 Les calculs simples de type somme, moyenne

¾ On peut mixer les environnements Oracle, SQL.

¾ Dans la fiche Datawarehouse : on renseigne

¾ Zone Format : Unicode ou ascii

¾ On renseigne les datamarts les dossiers

¾ Univers : c’est la représentation métier de données permettant aux utilisateurs d’interroger

Exemples : Ressources Humaines, Contrôle de gestion, Gestion commerciale.

 Il est possible de faire des états multi –univers.

 Exemple : pour un univers de type gestion commerciale : la date de commande, le

¾ Un Datamart contient un ensemble de table de fait reliés à des dimensions.

 Les tables de fait : ce sont des tables de mouvement.

¾ Il existe plusieurs structures dans les datamarts :

¾ Zone Abréviation : faire attention à l’unicité sur les abréviations.

¾ Zone autorisation site : certaines fonctions ont des autorisations sites

 Par exemple : la saisie du code client sur un site.

¾ Limiter la taille du résultat : si « 0 » pas de limite.

¾ Limiter l’exécution : si « 0 » pas de limite

¾ Les tables de fait : contiennent 4 types de données

 Dimensions : ce sont des critères d’analyse et de regroupement qui peuvent pointer

 Informations : Ce sont des précisions sur le fait (exemple : le commentaire, le

 Zones techniques : pour gérer les habilitations par exemple

¾ Exemple : dans une table de fait

Pré-packagée (incluant des états prêts à l’emploi)

Soit passer par Sage X3 (Impressions/Exécution BO)

Valeurs paramètres SUP groupe BI

A réaliser dans Business Object

Dans cette zone, on associe le code utilisateur BO et le code utilisateur X3.

Mais sur son utilisation, le datawarehouse s’avère complètement centralisé et

Les calculs simples de type somme, moyenne

Il est possible de faire des états multi –univers.

Exemple : pour un univers de type gestion commerciale : la date de commande, le

Les tables de fait : ce sont des tables de mouvement.

Par exemple : la saisie du code client sur un site.

Dimensions : ce sont des critères d’analyse et de regroupement qui peuvent pointer

Informations : Ce sont des précisions sur le fait (exemple : le commentaire, le

Zones techniques : pour gérer les habilitations par exemple

Dimensions (zone en gris)

Par défaut, le champ ACCDAT est proposé.

ex : si on lance une requête sur une commande de vente : on veut le nombre de

En V.5 .1 =possibilité d’avoir un intitulé « évalué » : par exemple : les messages

Si c’est un champ « technique » l’utilisateur ne le verra jamais.

Si le champ est alpha ou numérique = longueur.

Ex : pour la comptabilité - Agrégat : la balance

Le premier tableau définit la liste des agrégats

Exemple : dans la table client : on trouve un pointeur supérieur : la catégorie client

Des dimensions : critères d’analyse et de regroupement

Si c’est un champ « technique » l’utilisateur ne le verra jamais.

Ex : la table BPCUSTOMER : s’il y a une dimension père : on trouve le code de la

On indique le nom de la dimension père + le nom de champ si la clé est à

Ex GACCOUNT. On ne veut pas les comptes de cumuls.

Il faut réunir numéro de compte + désignation.

Ex : si on fait une requête sur la somme des débits

Ex : le chiffre d’affaire par Affaire, par client, par produit

Formules sur les champs de la dimension

Plusieurs requêtes peuvent être utilisées

On veut le plus détaillé possible :

Quand on lance la resynchronisation, le traitement regarde toutes les règles de

(ex : On peut passer par les traitements tels func.TRTACHBI ou func.TRTX3BI)

ie : un dossier racine/un runtime / des dossiers (ex : 1 DTW de test / 1DTW

Liste ? =>si liste, il faut renseigner quel type de table BI

Codes accès ? =type champ ACS