SX302 - Sage ERP X3 Outils Avancés - V6 1 - Support de Cours

Sage ERP X3
Sage ERP X3
Outils Avancés
Support de Formation
A partir de la version 6
Sage X3 Outils avancés Sage 2010 Page 1

« Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ».
Sage ERP X3
Sommaire
1. GESTION DES SESSIONS .................................................................................... 6
1.1. CONNEXION A UN DOSSIER SAGE X3 ...................................................................................................... 6
1.1.1. Définition des paramètres d’un dossier ....................................................................................... 7
1.1.2. Aide en ligne ................................................................................................................................ 9
1.2. Définition d’une session X3 .............................................................................................................. 11
1.2.1. Sessions primaires et sessions secondaires ............................................................................ 11
1.2.2. Autres sessions ......................................................................................................................... 11
1.2.3. La licence .................................................................................................................................. 12
1.3. Contrôle des sessions autorisées..................................................................................................... 13
1.3.1. Visualisation des sessions actives ............................................................................................ 13
1.3.2. Désactivation d’une session ...................................................................................................... 14
1.4. Client « terminal mobile » ................................................................................................................. 15
1.4.1. Généralités ................................................................................................................................ 15
1.4.2. Possibilités fonctionnelles ......................................................................................................... 16
1.4.3. Pré requis .................................................................................................................................. 16
2. CODES D’ACTIVITE ............................................................................................ 17
2.1. Différences entre le paramétrage et le développement. .................................................................. 17
2.2. Notion de vertical et de spécifique.................................................................................................... 17
2.3. Gestion des codes activité ................................................................................................................ 17
2.3.1. Les types ................................................................................................................................... 19
2.3.2. Cas de dépendance entre codes .............................................................................................. 19
2.3.3. Tables mises en œuvre ............................................................................................................. 19
3. PARAMETRAGE DES FONCTIONS ................................................................... 20
3.1. Gestion des objets : navigation ........................................................................................................ 20
3.1.1. Navigation : principes de base .................................................................................................. 20
3.1.2. Navigation : définition détaillée.................................................................................................. 22
3.1.3. Navigation : cas particulier ........................................................................................................ 23
4. LA GESTION DES PATCHS ET DES VERSIONS .............................................. 24
4.1. Introduction ....................................................................................................................................... 24
4.1.1. Qu’est ce qu’un patch ? ............................................................................................................. 24
4.1.2. Gestion des versions ................................................................................................................. 24
4.1.3. Limites des patchs ..................................................................................................................... 25
4.1.4. Les précautions à prendre......................................................................................................... 25
4.2. La gestion des patch......................................................................................................................... 26
4.2.1. L’intégration d’un patch ............................................................................................................. 26
4.2.2. Quels dossiers « patcher » ?..................................................................................................... 27
4.2.3. Tester un patch.......................................................................................................................... 28
4.2.4. Consulter un patch .................................................................................................................... 28
4.2.5. La création d’un patch ............................................................................................................... 28
4.2.6. Création automatique de patch ................................................................................................. 29
5. LE SERVEUR BATCH ......................................................................................... 31
5.1. Caractéristiques du serveur batch .................................................................................................... 31
5.1.1. Mise en service du serveur batch.............................................................................................. 31
5.1.2. Arrêt du serveur : ....................................................................................................................... 31
5.1.3. Paramètres superviseur associés ............................................................................................. 31
5.2. Principes de fonctionnement ............................................................................................................ 32
5.2.1. Définition d’une tâche ................................................................................................................ 32
5.2.2. Définition d’un groupe de tâches ............................................................................................... 34
5.2.3. Soumission d’une requête ......................................................................................................... 35

Sage ERP X3
5.2.4. Contraintes horaires & calendrier .............................................................................................. 36

5.2.5. Les abonnements ...................................................................................................................... 37
5.3. Surveillance des tâches .................................................................................................................... 38
5.4. Soumission de tâche par fichier ....................................................................................................... 40
5.5. Paramètres du serveur batch ........................................................................................................... 43
5.6. Notes techniques .............................................................................................................................. 44
5.7. La tâche batch comptable ................................................................................................................ 46
6. GESTION DES ETATS ........................................................................................ 49
6.1. Principes de base ............................................................................................................................. 49
6.2. Le dictionnaire des états ................................................................................................................... 50
6.3. Lancement d’un état ......................................................................................................................... 56
6.3.1. Lancement d’un état : cinématique ........................................................................................... 57
6.3.2. Résultat de l’édition sous Crystal Reports ................................................................................ 57
6.3.3. Mémorisation des paramètres ................................................................................................... 58
6.3.4. Surveillance de l’impression ...................................................................................................... 58
6.4. Affectation des codes internes à des états ....................................................................................... 59
6.5. Valeurs par défaut des paramètres d’états ...................................................................................... 60
6.6. Gestion des destinations d’impression ............................................................................................. 61
6.6.1. Gestion des destinations par utilisateur .................................................................................... 62
6.6.2. Affectation des destinations ...................................................................................................... 63
6.7. Serveurs d’édition ............................................................................................................................. 64
6.7.1. Fenêtre de surveillance X3........................................................................................................ 64
6.8. Notes techniques .............................................................................................................................. 65
6.8.1. Tables associées ....................................................................................................................... 65
6.8.2. Points d’entré............................................................................................................................. 65
6.8.3. Le principe des es fichiers « reportjobstatus » .......................................................................... 65
6.9. Analyse des performances des éditions Crystal Report................................................................... 67
7. EPURATION ET HISTORISATION ...................................................................... 69
7.1. Principes de base ............................................................................................................................. 69
7.2. Création d’un dossier d’historisation................................................................................................. 71
7.3. Définition des règles d’épuration et d’historisation ........................................................................... 73
7.4. Paramètres d’épuration / historisation .............................................................................................. 74
7.5. Exécution de l’historisation / épuration ............................................................................................. 75
7.6. Visualisation des données historisées.............................................................................................. 76
8. LE WORKFLOW MANUEL .................................................................................. 77
8.1. Introduction ....................................................................................................................................... 77
8.1.1. Principes de base du Workflow V5 et supérieur ....................................................................... 77
8.1.2. Les paramètres superviseur ...................................................................................................... 78
8.2. Les modèles de données ................................................................................................................. 80
8.3. Paramétrage des règles de workflow ............................................................................................... 83
8.3.1. Evènement déclenchant ............................................................................................................ 83
8.3.2. 0nglet destinataire ..................................................................................................................... 86
8.3.3. Onglet Message ........................................................................................................................ 87
8.3.4. Le suivi des signatures .............................................................................................................. 93
8.3.5. Onglet Suivi ............................................................................................................................... 93
8.3.6. Onglet action ............................................................................................................................. 96
8.4. Les règles d’affectation ..................................................................................................................... 99
8.4.1. Définition des règles d’affectation ............................................................................................. 99
8.4.2. Affectation des utilisateurs ...................................................................................................... 101
8.4.3. Utilisateurs délégués ............................................................................................................... 102
8.5. Moniteur de Workflow & Plans de travail ........................................................................................ 104
8.5.1. Paramétrage des plans de travail............................................................................................ 104
8.6. Le moniteur de Workflow ................................................................................................................ 113
8.6.1. Entête ...................................................................................................................................... 113

Sage ERP X3
8.6.2. Consultation............................................................................................................................. 113

8.6.3. Signature ................................................................................................................................. 114
8.7. Ergonomie du plan de travail .......................................................................................................... 116
8.7.1. Boutons de navigation ............................................................................................................. 116
8.7.2. Gestion des droits des utilisateurs .......................................................................................... 116
8.8. Workflow – Points divers ................................................................................................................ 117
8.8.1. Workflow manuel ..................................................................................................................... 117
8.8.2. Méthodologie de mise en œuvre ............................................................................................. 117
8.9. Workflow livrés en standard ........................................................................................................... 120
8.9.1. Workflow de sécurité ............................................................................................................... 120
8.9.2. Tracabilité ................................................................................................................................ 124
8.9.3. Suivi des signatures ................................................................................................................ 131
8.10. Fonctions dédiées à la CRM ................................................................................................... 135
8.10.1. Paramétrage des signatures ................................................................................................... 135
8.10.2. Règles de signature ................................................................................................................ 135
8.10.3. Rectification des signatures .................................................................................................... 135
8.11. Notes techniques ..................................................................................................................... 136
8.11.1. Les points d’entrée .................................................................................................................. 136
8.11.2. Epuration des tables ................................................................................................................ 136
8.11.3. L’exécutable meladx ................................................................................................................ 137
8.11.4. Appel d’un Workflow dans un spécifique ................................................................................ 138
8.12. Les liens de workflow .............................................................................................................. 140
8.12.1. Fonctionnement ....................................................................................................................... 140
8.12.2. L'action à déclencher............................................................................................................... 142
8.12.3. La règle de Workflow ............................................................................................................... 143
8.12.4. Les liens dans le workflow ....................................................................................................... 144
9. LA GESTION DE LA DOCUMENTATION ......................................................... 145
9.1. Introduction ..................................................................................................................................... 145
9.1.1. Outils de base.......................................................................................................................... 145
9.1.2. Les prérequis de mise en œuvre............................................................................................. 145
9.2. L’organisation de la documentation ................................................................................................ 145
9.2.1. Les paragraphes de documentation ........................................................................................ 146
9.2.2. Attributs d’une documentation ................................................................................................. 147
9.2.3. Les types de documentation ................................................................................................... 148
9.3. L’aide sur les champs ..................................................................................................................... 151
9.4. L’éditeur HTML ............................................................................................................................... 152
9.4.1. Fonctionnement ....................................................................................................................... 152
9.4.2. Boutons boîte de dialogue....................................................................................................... 153
9.4.3. Les raccourcis clavier .............................................................................................................. 153
9.4.4. Import des textes HTML .......................................................................................................... 154
9.5. Les liens de documentation ............................................................................................................ 155
9.5.1. Relations autorisées pour une fonction ................................................................................... 156
9.6. La génération de la documentation ................................................................................................ 157
9.6.1. Les répertoires des documents générés ................................................................................. 158
9.7. Publication de la documentation..................................................................................................... 158
10. LES OUTILS DU SUPERVISEUR ...................................................................... 160
10.1. Introduction .............................................................................................................................. 160
10.2. Outils de maintenance ............................................................................................................. 161
10.2.1. Maintenance par enregistrement............................................................................................. 161
10.2.2. Maintenance en colonnes ....................................................................................................... 162
10.3. Outils de vérification ................................................................................................................ 163
10.3.1. Infos version ............................................................................................................................ 163
10.3.2. Surveillance des services ........................................................................................................ 164
10.3.3. Vérification de cohérence ........................................................................................................ 164
10.3.4. Symboles et traitements verrouillés ........................................................................................ 166

Sage ERP X3
10.3.5. Symboles verrouillés ............................................................................................................... 166

10.3.6. Traitements verrouillés ............................................................................................................ 167
10.3.7. Analyse des mémos ................................................................................................................ 167
10.3.8. Etat des tables ......................................................................................................................... 169
10.3.9. Recherche des index ............................................................................................................... 170
10.4. Optimisation base de données ................................................................................................ 172
10.4.1. Propriété de la base de données ............................................................................................ 172
10.4.2. Processus Base de données................................................................................................... 172
10.5. Optimisation base de données ................................................................................................ 174
10.5.1. Statistiques base de données ................................................................................................. 175
10.6. Utilitaires dictionnaire .............................................................................................................. 176
10.6.1. Validation ................................................................................................................................. 176
10.6.2. Copie dictionnaire .................................................................................................................... 176
10.6.3. Différence d’objets ................................................................................................................... 178
10.6.4. Validation des fonctions .......................................................................................................... 179
10.6.5. Validation des menus .............................................................................................................. 180
10.6.6. Génération des transactions ................................................................................................... 181
10.6.7. Gestion des traitements .......................................................................................................... 181
10.6.8. Mise à jour des menus locaux ................................................................................................. 182
10.6.9. Synchronisation des fenêtres .................................................................................................. 183
10.7. Utilitaires de recherche ............................................................................................................ 186
10.8. Utilitaires divers ....................................................................................................................... 188
10.8.1. Ordre système ......................................................................................................................... 188
10.8.2. Exécution traitement ................................................................................................................ 189
10.8.3. Copie des valeurs paramètres ................................................................................................ 189
10.8.4. Re synchronisation des liaisons .............................................................................................. 190
11. LES TRANSACTIONS SYSTEME ..................................................................... 192
11.1. Création d’une transaction ...................................................................................................... 193
11.2. L’exécution d’une transaction système ................................................................................... 195

Sage ERP X3
1. GESTION DES SESSIONS
1.1. CONNEXION A UN DOSSIER SAGE X3

On se connecte sur un dossier Sage X3 :
- qui utilise un ensemble de modules
- qui intègre un référentiel (paramétrage, développement spécifiques) commun
- qui gère des données (statiques, mouvements)
On s’identifie comme un utilisateur X3, ce qui définit, dossier par dossier :

- les habilitations
- des valeurs par défaut
- La langue de connexion peut varier d’un utilisateur à l’autre
En mode client serveur
En mode Web, la mire de connexion est similaire sauf que le code de l’application n’est pas
saisissable car il est implicitement définit par l’URL d’accès à la mire de connexion.
Il est important de noter qu’un paramétrage est fait dans un dossier (et un seul), que des outils de
copie permettront de le propager, qu’un développement peut être partagé par N dossiers

Sage ERP X3
Les langues de connexion possibles sont définies lors de la création d’un dossier. A ce jour, les
langues suivantes sont gérées par l’éditeur :
- Anglais US
- Anglais british
- Espagnol
- Italien
- Français
- Portugais
- Allemand
- Chinois moderne
- Chinois simplifié
- Russe pour GEODE GX
- …
D’autres langues sont mises en œuvre par des partenaires.
On verra plus loin (en gestion des licences) comment sont définies les connexions possibles. La boîte
de connexion permet de saisir :
Les 3 principaux éléments de la connexion (dossier, utilisateur, langue)

Un mot de passe applicatif authentifiant l’utilisateur dans le dossier
Une date logique de connexion
1.1.1. Définition des paramètres d’un dossier

On regroupe les 3 éléments identifiant un dossier :
Stocké, en client-serveur, dans un fichier de configuration local accessible via le bouton
« Configuration »

Sage ERP X3
Avec quelques paramètres complémentaires :

- code utilisateur réseau de connexion par défaut,
- serveur de traitement s’il est différent,
- informations de connexion système.
Il est ici possible d’ajouter des informations de connexion vers d’autres dossiers
Chargement :

Sage ERP X3
Le bouton Avancé donne accès à des paramètres complémentaires

Format de l’aide CHM ou HTML
Source ODBC pour Crystal Reports (si « Valeur par défaut » est sélectionné, on utilise les valeurs
définies lors de l’installation)
Remarque :
La case à cocher Application par défaut proposera ce dossier par défaut à la connexion.
L’activation thème graphique permet d’utiliser le thème standard de type XP. Si cette case n’est pas
cochée, on se retrouve avec une apparence des écrans plus proche des écrans Windows NT.
Attention, en connexion via Citrix, il faut décocher la case en question.
1.1.2. Aide en ligne

L’aide en ligne se présente sous forme HTML ou sous forme d’archive (chm)
Intérêt du chm
Onglet sommaire
Onglet recherche
Impression directe par bouton
Inconvénients du format chm
Un très gros fichier

Inutilisable en mode Web

Sage ERP X3
L’aide en ligne fonctionnelle est liée aux autres aides par des liens hypertextes.

Sage ERP X3
1.2. DEFINITION D’UNE SESSION X3
1.2.1. Sessions primaires et sessions secondaires

Une session primaire correspond à une connexion depuis la boîte de connexion.
Plusieurs sessions primaires peuvent être ouvertes depuis un même poste.
Ces sessions peuvent être connectées à des dossiers différents, sous des langues différentes, et
avec des codes utilisateurs différents.
Une session secondaire est une session ouverte à partir d’une session primaire depuis un poste
client-serveur ou un poste en mode Web.
Fichier / Session secondaire

Appel d’une touche de fonction (Shift F5 à Shift F12) paramétrable par utilisateur
Utilisation de l’icône
Par conséquent une session secondaire permet de travailler sur le même dossier que la session
primaire, avec le même utilisateur, et dans la même langue.
Le nombre de sessions primaires et secondaires est limité au niveau global, par la licence, au niveau
utilisateur ou groupe d’utilisateurs par les paramètres définis dans le dossier.
Une connexion à Sage X3 provoque l’ouverture d’une session identifiée de façon unique pour un
serveur d’application donné d’un type donné.
Une session secondaire possède les caractéristiques suivantes :

Forcément ouverte sur le même dossier, et pour le même utilisateur
Automatiquement fermée (avec une confirmation) si la session primaire dont elle dépend est elle-
même fermée
1.2.2. Autres sessions

Il existe d’autres types de connexion dans l’application :
- Session batch (déclenchée par le serveur batch)

- Session WEB Services
- Session terminal VT
Remarque :
La fonction adxuid(1) donne l’identificateur unique (pour un serveur d’application donné)

La fonction adxuid(2) donne un identificateur unique pour une connexion à un dossier donné
La fonction adxpid donne quant à elle le numéro de processus (au sens du système d’exploitation) du
processus Sage X3 en cours d’exécution. Dans un contexte multi-tiers, ce numéro de processus ne
peut bien évidemment pas être garanti unique.
La fonction adxtyp permet de connaître le type de connexion :

1 Session mode Client / serveur
2 Session secondaire en mode Client / serveur.
3 Session Batch
9 Session Client mode web

Sage ERP X3
10 Session secondaire en mode Client web

12 Session Client web services. Communication synchrone avec des applications tierces.
1.2.3. La licence
Développement > Utilitaires > Vérifications > Visualisation licence
Le nombre de licence par type est définie par le fichier serial_adonix installé dans le répertoire de la
solution Sage sur le serveur d’application. En cas de mise à jour de ce fichier, il est conseillé de
sauvegarder l’ancien fichier serial_adonix avant d’installer le nouveau.

Sage ERP X3
1.3. CONTROLE DES SESSIONS AUTORISEES

Il est possible de contrôler le nombre de sessions ouvertes :
Pour un utilisateur donné, par les paramètres utilisateur MAXSES1 (nombre maxi de sessions
primaires) et MAXSES2 (nombre maxi de sessions secondaires)
Globalement, en passant un dossier en mode mono-utilisateur (personne d’autre ne peut alors se
connecter)
Pour un type de profil menu donné dans un dossier donné (paramètres USR1, USR2, USR3)
Il est possible de provoquer une déconnexion automatique d’un utilisateur :
En cas d’inactivité clavier/souris au bout de TIMEHGUP1 ou TIMHEHGUP3 secondes (valeur de
paramètres utilisateurs pour sessions primaires / secondaires)
Avec un avertissement et un délai de grâce de TIMEHGUP2 secondes (idem)
Si ces paramètres sont nuls, il n’y a pas de déconnexion automatique
Remarque :
L’utilisateur ADMIN n’est jamais limité en nombre de connexions (par contre, le verrouillage mono-
utilisateur lui est opposable).
1.3.1. Visualisation des sessions actives

Développement > Utilitaires > Vérification > Surveillance > Utilisateurs

Sage ERP X3
Cette fonction permet de :

- Visualiser les connexions en cours (tableau supérieur) sur un serveur d’application et un
service donné (machine:service)
- Visualiser les processus correspondants et les interrompre si on est habilité
Dans l’écran ci-dessus, Ident1 et Ident 2 correspondent au résultat que donnerait adxuid(1) et
adxuid(2) lancés dans la session correspondante, Fonction est le nom de la fonction exécutée (cette
valeur est vide si l’utilisateur se trouve au niveau du menu). Pour la ligne courante, la colonne numéro
de processus correspond au numéro donné par le système d’exploitation sur le serveur (ou le poste
client).
On remarquera ainsi, pour avoir le droit d’interrompre un processus, il faut soit avoir les droits d’un
super-utilisateur au niveau du système d’exploitation (i.e. être connecté comme root sous Unix,
comme administrateur sous Windows), soit être connecté sous la même identité que le propriétaire
des processus. Par ailleurs, une habilitation définie au niveau de l’accès de cette fonction est aussi
nécessaire
Par défaut, quand on entre dans la fonction, c’est le serveur d’application courant qui est proposé, et
si le service n’est pas donné, c’est le service courant qui est affiché.
1.3.2. Désactivation d’une session

Sage ERP X3
Pour suspendre une session à partir du tableau des sessions actives, positionner le focus sur la ligne
du Poste client à suspendre. La liste des processus actifs pour la session sélectionnée est alors
affichée dans le tableau des processus actifs. A l’aide d’un clic droit sur ce tableau ou ouvre la fenêtre
permettant d’accéder à la fonction d’Arrêt des processus de cette session.
A une session Sage X3 correspond au minimum les processus suivants

Adonix -> Processus Sage X3 de gestion de la session, Ce processus adonix
correspond à l’exécution du code applicatif. Il est exécuté sur un serveur de traitement
sadora ou sadsql -> Processus de gestion des accès à la base de donnée pour la session. Il est
aussi exécuté sur un serveur de traitement
Les processus sadfsq correspondent aux accès par la session à des fichiers de type séquentiels. Ils
peuvent être présents sur plusieurs serveurs (y compris sur le poste client, par exemple si on écrit un
fichier séquentiel en local).
Cette fonction permet d'arrêter le processus correspondant (par kill sous UNIX, par la fonction killadx
sous NT). L'arrêt d'un processus signifie, du point de vue de la base de données, l'arrêt propre de la
transaction en cours, mais également la perte des données en cours de saisie. Il importe donc d'être
très prudent dans l'utilisation de cette fonction réservée à la résolution d'incidents d'exploitation.
Les scripts de purge d’une session peuvent être activés par un processus externe à Sage X3
1.4. CLIENT « TERMINAL MOBILE »

Ce nouveau type de terminal est dédié aux fonctions logistiques de l’offre Sage GEODE.
1.4.1. Généralités
Ce type de terminaux permet de créer des documents, le mode mise à jour n’est pas disponible.
Les champs présentés permettent d’identifier les lignes de stock. L’affichage des champs n’est pas
paramétrable par transaction.
Le site utilisé est affiché sur chaque mouvement. Par défaut c’est le site lié à l’utilisateur connecté. Ce
site est modifiable via une fonction « Définir le site ».

Sage ERP X3
Les principales touches fonctions sont :
F1 OK. Cette touche permet le passage à la ligne suivante

F3 Select
F4 Fin
F2 Créer
Une ligne de document = 1 mouvement de stock
Le paramètre utilisateur VTMEN permet de définir le profil menu de l’utilisateur connecté via ce type
de terminal. En cas d’absence c’est le profil menu VT qui est utilisé par défaut.
1.4.2. Possibilités fonctionnelles
- Gestion des entrées et sorties diverses

- Réception
- Transferts intersites
- Transferts sous–traitants
- Changement de stocks
- Rangement sur liste
- Réapprovisionnement d’un emplacement
- Inventaires
- Sorties matières
- Déclaration de fabrication
- Suivi des temps
1.4.3. Pré requis

La mise en œuvre de ce type de connexion nécessite l’utilisation d’un serveur http Sage X3.
Les terminaux radio fréquence communiqueront via Telnet avec ce serveur.
Ces points dont abordés dans un cours dédié à la mise en œuvre de ce type de matériel.

Sage ERP X3
2. CODES D’ACTIVITE
2.1. DIFFERENCES ENTRE LE PARAMETRAGE ET LE DEVELOPPEMENT.

Le paramétrage est pérenne, il est conservé lors des changements de version et n’est pas modifié
par une mise à jour de patch
Les développements spécifiques doivent être protégés pour être pérennes, chaque élément modifié
doit être marqué par un code que nous désignons par le terme code activité spécifique.
- un patch standard ne modifiera pas le spécifique et le vertical si ils sont protégés
- un patch vertical ne modifiera pas le spécifique si il est protégé
- un patch spécifique peut le modifier
Certaines fonctions résultent d’une combinaison de paramétrage et de développement. Une partie est
alors du développement, une autre de la personnalisation. Par exemple le paramétrage des
consultations.
Ces différences peuvent paraître subtiles, mais elles n’en sont pas moins fondamentales. Dans la
suite de ce cours 90% des fonctions qui seront vues sont du paramétrage.
Pour un développement, lorsqu’un champ est modifié par rapport au standard, une marque doit signer
la modification. Cette marque est désignée dans X3 par le terme code activité.
Si ceci n’est pas fait, la modification n’est pas pérenne, et peut disparaître inopinément à la faveur
d’un patch qui toucherait l’élément en question, ou de façon certaine en cas de revalidation de
dossier.
2.2. NOTION DE VERTICAL ET DE SPECIFIQUE

Au niveau des objets et des écrans Sage X3, des traitements dédiés peuvent être affectés aux objets
et/ou écrans.
Par exemple dans Sage Entreprise lors de la saisie du code devise d’une facture, le traitement
standard effectue un traitement sur ces champs permettant de trouver le taux de conversion en
fonction de la date de comptabilisation de la facture. Il est possible de surcharger ce traitement par un
traitement spécifique qui gère une contrainte complémentaire. Dans notre exemple on désire
rechercher le taux de change mensuel.
Lorsque les traitements spécifiques mis en place sont réutilisables pour plusieurs dossiers
indépendants, la standardisation des spécifiques devient un vertical.
Si un traitement vertical est déclaré, pour une même action X3, celui-ci sera exécuté après le
traitement spécifique et avant le traitement standard.
De même au niveau des actions sur les champs de l’écran, l’enchaînement des traitements sera :
- SPE : Action spécifique
- SPV : Action verticale
- STD : Action standard
Cette notion de vertical possède des impacts importants sur les développements et les patchs. Ce qui
nécessite la mise en place d’une normalisation des composants de la solution Sage X3.
2.3. GESTION DES CODES ACTIVITE

La gestion des codes activité concerne à la fois les opérations de développement et celles de
paramétrage. La séparation entre les deux domaines peut être la suivante :

Sage ERP X3
La création d’un code activité est une opération de développement.

La mise en œuvre dans un dossier (activation / désactivation) est une opération de paramétrage.
Par exemple le nombre d’axes analytiques est une opération de paramétrage, ce nombre est prévu
dans une fourchette de 1 à 9 par le développement. C’est pourquoi nous présentons cette gestion
dans ce document.
Le rôle des codes activité est de rendre actifs ou inactifs des éléments du dictionnaire Sage X3, par
exemple :
- tables
- index
- onglets
- blocs
- champs d'écran
- etc
Le fait de rendre actif ou non un code activité donné permet de désactiver, dans les écrans, certains
champs optionnels en fonction des règles de gestion choisies.
Conventions sur la codification du premier caractère des codes activité

- Lettre K : identifie les éléments développés pour les localisations standards,
- Lettre X : identifie les développements verticaux,
- Lettre Y Z : identifie les développements spécifiques.
Développement > Dictionnaire données > Ouverture au paramétrage > Code activité
A la génération d’un dossier, les codes activités peuvent être initialisés comme étant actifs ou inactifs
en fonction du paramétrage réalisé sur la fiche de description du dossier. Ce point sera présenté dans
le chapitre de gestion des dossiers.

Sage ERP X3
Après la génération d’un dossier, il est possible de modifier le statut d’un code activité. En fonction
des caractéristiques du code activité des opérations de revalidation peuvent être nécessaires. Par
exemple la modification du nombre d’axes analytiques nécessite de revalider les écrans, fenêtre et
tables contenant des données dépendantes de ce code activité.
2.3.1. Les types

Fonctionnel : Ce type de code activité permet de rendre actif / inactif une fonction sage X3, par
exemple le code ABI permet d’activer les fonctions BI dans l’application.
Dimensionnement : Ce type de code activité décrit une règle de dimensionnement qui permettra de
définir le nombre d’occurrences dans les tables, les écrans. Par exemple Le code ANA définit le
nombre d’axes analytiques gérés. Les codes activité de type dimensionnement possèdent des
attributs complémentaires suivants.
- Dimension maximum : Cette valeur est la taille maximum gérée par les traitements
Dimension écran : Cette valeur est la taille utilisée pour générer les écrans et les tables.
Localisation : Ce type de code activité est lié à une règle de gestion liée à une législation. Par
exemple KPA décrit comment gérer les relevés bancaires dans la législation portugaise.
2.3.2. Cas de dépendance entre codes

Le bloc dépendance permet de décrire des relations entre les codes activité. Ce point est abordé dans
le cours développement. Au niveau paramétrage ce bloc ne doit pas être modifié.
Inverse : Le code activité prend la valeur inverse du code activité saisi en regard; il sera actif si le
code activité correspondant est inactif, et inactif s'il est actif.
Dimensionnement : le code activité est alors composé d'une racine, suivi d'un nombre M (de 1 à 9),
et il est associé à un code activité qui peut prendre des valeurs numériques de 1 à N. Le code activité
est actif si la valeur du code associé est supérieure ou égale à M; sinon, il est inactif. On peut prendre
l'exemple du code ANA, associés par des liens de dimensionnement aux codes AX1 à AX9. Si ANA
vaut 5, les codes AX1 à AX5 seront actifs, les codes AX6 ç AX9 seront inactifs.
Formule : permet de calculer la valeur d'un code activité en fonction d'une formule saisie. Cette
expression calculée peut intégrer des constantes, des fonctions, et des variables sous la forme
d'autres codes activité. Ces codes activité peuvent être des codes saisis, ou des codes calculés
antérieurement. L'ordre de calcul des codes activités dépendant de codes antérieurs est défini par le
rang. Un code activité non porteur d'une dimension vaut 1 s'il est actif, et 0 s'il est inactif.
2.3.3. Tables mises en œuvre
Tables Contenu
ACTIV ACV Définition des codes activité et des valeurs associées
ADOVAL ADW Intitulé des codes activité (Cette table étant utilisée dans de nombreux
contexte, ne sera plus citée dans la suite de ce document)

Sage ERP X3
3. PARAMETRAGE DES FONCTIONS
Ce chapitre présente les outils permettant de modifier par paramétrage des fonctions existantes dans
la solution X3. Nous limitons ces modifications aux adaptations qui ne nécessitent pas la mise en
œuvre des codes activité pour protéger ces personnalisations.
Les modèles de fonctions induisent des paramétrages particuliers :
- Modèle Objet
- Propriétés
- Personnalisation
- Liaisons automatiques
- Navigation
- Transaction
- Modèle consultation
- Paramétrage des écrans
- Tout modèle utilisant des écrans

- Tables de contrôle
- Affectation de codes d’accès (pour rappel)
3.1. GESTION DES OBJETS : NAVIGATION

C’est une fonction située dans le développement
Des navigations standard sont fournies (essentiellement pour la CRM)
Toute modification et toute création de nouvelle navigation doit être signée par un code activité
spécifique (commençant par X, Y, ou Z)
Elle suppose une bonne connaissance du contexte d’exécution
Elle peut produire des dysfonctionnements dans l’objet modifié si la définition est mal faite
Néanmoins elle a la facilité de mise en œuvre d’un paramétrage
3.1.1. Navigation : principes de base
Une fonction X3 dispose de

possibilités de navigation
vers d’autres fonctions
Quand la fonction arrivante

est un objet, on peut vouloir
tenir compte du contexte
appelant pour :
 Proposer des valeurs par

défaut en création
 Imposer des filtres de sélection
Via l’explorateur
de liaisons
Via des menus

SagedX3
ansOutils
la baravancés
re Sage 2010 Page 20
d’outils « Tous droits réservés. Toute reproduction, même partielle, est interdite sans notre autorisation ».
Par tunnel
Via des boutons
Sage ERP X3
Remarque
Ces navigations sont toujours des navigations avec un retour à la fonction appelante.

Sage ERP X3
3.1.2. Navigation : définition détaillée

Développement / Dictionnaire traitements / Navigation
Sur le premier onglet, on paramètre les filtres sur l’objet
Code identifiant
la navigation
Contexte :
Fonction de départ
Objet d’arrivée
Filtres sur la liste gauche :

Condition d’activation
Navigation : définition Filtre détaillée
Sur le second onglet, on paramètre les valeurs par défaut
Champs des écrans
Formules des
valeurs par défaut

Sage ERP X3
Remarque :
Ces valeurs par défaut s’appliquent en création de fiche, et pas en duplication
3.1.3. Navigation : cas particulier

Cas particulier important
si le code fonction de départ correspond à l’objet d’arrivée (c’est à dire GESXXX  XXX)
par convention, on est dans le cas où on part d’un menu
Il est donc possible par ce biais, sur des objets appelés directement
- de créer des filtres complémentaires génériques ou contextuels
- de proposer des valeurs par défaut contextuelles
Interface utilisateur :
Un code de navigation actif est indiqué par l’icône en bas de l’écran

Sage ERP X3
4. LA GESTION DES PATCHS ET DES VERSIONS
4.1. INTRODUCTION
4.1.1. Qu’est ce qu’un patch ?
Un patch est un fichier d’archives :
- Numéroté à partir du début d’une version majeure (X.Y) de 1 à N

- Contenant une correction : code applicatif, description de structure de données, données, une
demande d’exécution d’un utilitaire…
- Apportant des évolutions fonctionnelles
Un patch peut contenir un ou plusieurs éléments tels que des écrans, des déclarations de tables, des
codes activités, des types de données, des objets, des menus locaux, des chapitres de messages,
des traitements, des demandes d’exécution de traitements, des données...
Des éléments de paramétrage sont patchables (requêtes, requêtes SQL…)

Typologie de patches : standard, spécifique, vertical, superviseur.
4.1.2. Gestion des versions
Les versions sont numérotées sur 3 chiffres X.Y.Z :

X = génération majeure (1 pour le moment)
Y = version majeure (0,1,2,3,4)
Z = version mineure
Pour plus de facilité, les patchs sont organisés en liste, numérotées à partir du début d’une version
majeure (X.Y) de 1 à M.
Une version mineure correspond à une liste donnée de patchs.
Ces dépendances sont visibles dans un fichier nommé X3PATCHXY0, livré avec toute liste de patchs
Historique des versions à ce jour :

100 : version alpha, 12/1998
110 : première version officielle, 06/1999
120 : première version distribuée, 04/2000 (120 à 126)
130 : première version Web, 06/2001 (130 à 138)
140 : dernière version majeure (145), 01/2007
V5 : été 2007

Sage ERP X3
4.1.3. Limites des patchs

Les patchs doivent être installés séquentiellement. C’est-à-dire que cela suppose que les précédents
soient installés (Il peut être avantageux d’installer une version intermédiaire quand on est très en
amont du numéro de patch à installer.)
Lorsqu’un patch nécessite de mettre à niveau l’un des moteurs, une procédure dédiée est précisée.
Généralement, la mise à jour d’un moteur s’effectue en exécutant le fichier sur le serveur à mettre à
jour.
Les patchs ne permettent pas de mettre un jour les différents moteurs de l’application (client, serveur
de données, serveur web, l’aide en ligne…).
Les patchs ne permettent pas de remettre à jour les données de paramétrage situées dans le dossier
de référence Sage X3.
4.1.4. Les précautions à prendre

Lire le fichier X3PATCHVxxx : Il précise les pré-requis, les points particuliers (changement de
structure pouvant nécessiter de la place disque, par exemple), les actions à effectuer avant ou après
l’intégration du patch.
Il est hautement recommandé d’être le seul connecté sur le dossier à « patcher » :
C’est obligatoire si une table change de structure

C’est préférable dans les autres cas (pour éviter une persistance de code en mémoire)
Lorsque des spécifiques ont été réalisés, il est conseillé d’utiliser le testeur de patchs pour vérifier
d’éventuels conflits.
Avant intégration manuelle, s’assurer :

- que les tâches comptables sont arrêtées,
- que le serveur batch est inactif

Sage ERP X3
4.2. LA GESTION DES PATCH
4.2.1. L’intégration d’un patch

Développement > Utilitaires > Patch > Intégration de patch
A partir de la zone « Répertoire des fichiers patchs », il est nécessaire de situer le répertoire
contenant les patchs « FILPATCH » ou le fichier lui-même « PP_00760_140.dat ».
Par défaut l’ensemble des dossiers se trouvant dans l’environnement est proposé.
Il est possible d’en supprimer de la liste.
Si la case à cocher Intégration de patch n’est pas cochée, les fichiers patchs sont simplement lus.
L’intégration n’est effective que lorsque la case est cochée.
Tables mises en œuvre
Nom de la table Abréviation Contenu

APATCH APT Suivi des patchs intégrés

Sage ERP X3
4.2.2. Quels dossiers « patcher » ?

Un patch s’installe dossier par dossier :
Lorsqu’on veut tester un patch, on peut l’installer sur un dossier de test dédié (paramètre Dossier de
test égal à Oui).
Lorsque l’installation est définitive, il doit être installé à la fois sur le dossier Sage X3 et les dossiers
d’exploitation (ou autrement dit le dossier de référence et le(s) dossier(s) d’exploitation ou encore le
dossier mère et le(s) dossier(s) fille).
On peut choisir d’intégrer un fichier unique ou l’ensemble des fichiers contenus dans un répertoire
(c’est le cas d’une liste) En ne cochant pas la case Intégration de patch, on lit le contenu des fichiers
de patch
Si un dossier n’est pas mis à niveau des patchs, il risque de ne plus fonctionner correctement, car un
traitement présent uniquement dans le dossier superviseur peut s’appuyer sur une structure de
données modifiée dans le même patch. Or un traitement de dossier superviseur sera
automatiquement hérité dans tous les autres dossiers, alors que la structure de données sur laquelle il
s’appuie n’aura pas été intégrée dans le dossier en question, ce qui provoquera une incohérence.
Des cas particuliers existent :
Si un dossier est de type Test (ce flag est défini dans les paramètres de gestion du dossier), les
traitements seront intégrés dans le dossier lui-même. Ainsi, si l’on désire réaliser un test de
fonctionnement d’un patch (par exemple sur un dossier intégrant beaucoup de spécifiques) sans
perturber l’environnement d’exploitation, il est possible de n’intégrer le patch que sur ce dossier : les
traitements et le dictionnaire seront alors « patchés », ce qui permettra de réaliser un test complet.
Attention toutefois, le fait d’installer des traitements standards sur un dossier rend ensuite ce dossier
particulier : l’application uniforme d’un autre patch sur l’ensemble des dossiers y compris celui-ci
risque de ne pas être opérant sur le dossier de test (car les traitements existants dans le dossier de
test ne sont pas hérités du dossier superviseur).
Si un patch intègre des traitements spécifiques (commençant par X, Y, ou Z, ou encore par SPE), ces
traitements ne seront intégrés dans le dossier que s’ils existent déjà ; sinon, ils seront intégrés dans le
ou les dossiers de type Développement (flag défini dans les paramètres de gestion du dossier)
Si une mise à jour sur tous les dossiers est faite (ce qui est le cas le plus fréquent), les dossiers qui
auraient un niveau de patch inférieur à celui du dossier superviseur devront être revalidés pour être
en adéquation avec l’environnement.

Sage ERP X3
4.2.3. Tester un patch
Développement > Utilitaires > Patch > Test de patch
Il permet de vérifier l’intégrité référentielle en anticipant tous conflits potentiels lors de l’installation du
patch :
Traitement standard ou état standard dupliqué dans un dossier « patché » et présent dans le patch
Présence de spécifique sur un des éléments « patchés » (le programme signale ce qui a été protégé
par un code activité spécifique).
Particulièrement utile lors de l’installation d’une nouvelle version dite mineure
4.2.4. Consulter un patch

Cette fonction permet de voir les patchs intégrés dans le dossier.
Développement > Utilitaires > Patch > Consultation de patchs
Numéro : Clé (numérotation automatique)
Fichier : Nom complet du fichier. Le préfixe PX est caractéristique des patches standards sur X3
Version : Les fichiers patches standard ont des noms constitués sur le modèle PX_nnnn_vvv.dat, où :
- PX est le caractère définissant un patch standard (il est conseillé aux intégrateurs d’utiliser
l’une des lettres X,Y, ou Z pour nommer leurs fichiers de petch).
- nnnn est un numéro chronologique sur lequel une vérification de séquence est faite
- vvv caractérise la version majeure sur laquelle s’applique le patch (110, 120, 130, 140, 150).
Maintenance : Numéro de maintenance. Utilisé, à préfixe égal, pour le contrôle de séquence
Définit le numéro chronologique nnnn relatif au fichier de patch. C’est sur cette caractéristique, et sur
le champ Type, que le contrôle de séquence des patches est réalisé.
Patch : Numéro de liste de patch, ce numéro identifie la liste de patch concernée.
4.2.5. La création d’un patch

Cette fonction permet de créer une archive contenant des développements spécifiques créés ainsi
que des éléments de paramétrage modifiés entre deux dates du dossier courant.
Création manuelle
Développement > Utilitaire > Patch > Création de patchs
Indiquer le chemin et le nom du fichier (ex : E:\Patch\ZmyPatch_140_001.dat)
Codes activité : Ce tableau permet de saisir une liste de codes activités commençant par X, Y ou Z.
Dès lors que l’on désire créer un patch intégrant des développements spécifiques, il est obligatoire de
définir ici les codes activités concernés. En effet, si cela n’est pas fait, les éléments du dictionnaire

Sage ERP X3
portant des codes activités spécifiques non listés ici seront ignorés à l’intégration du patch. Cette
précaution est obligatoire, car sinon un patch standard serait en mesure de mettre à jour un objet
marqué par un code activité spécifique. C’est précisément le fait qu’aucun code activité spécifique ne
soit donné en tête dans un patch standard qui permet de gérer ce fait.
Ces codes activités ne sont pas un moyen de filtrer l’extraction des objets du patch, mais un moyen
d’indiquer quels codes d’activités spécifiques ne seront pas respectés à l’intégration du patch. Il existe
par contre une fonction qui permettra ensuite de pré-charger le tableau avec les objets marqués par
les codes activités saisis ici.
Objets : Ce tableau permet de saisir une liste d’objets à « patcher ». Cette liste est identifiée par un
type d’objet et un nom.
Langues : Ce tableau permet de définir les langues que l’on désire « patcher ». En effet, tous les
textes du dictionnaire de données (définis par le code type ATX) sont stockés dans une table séparée
(la table ATEXTE) et sont identifiés par un numéro (inférieur à 50.000 pour les textes standards, et
supérieur au delà). Ces textes sont transmis via patch sous leur forme littérale (le numéro n’a pas de
sens puisqu’il peut varier) dans différentes langues. La liste des langues utilisées pour inclure les
textes est donc donnée par ce tableau.
Type de patch :
- Standard : intégration du standard dans tous les dossiers ; spécifique et vertical sont conservés.
- Superviseur : intégration dans le dossier mère uniquement (documentation, modèles import-export,
pièces automatiques, workflow, etc.).
- Vertical : intégration dans tous les dossiers ; spécifique conservé, et suppression des SPV
obsolètes.
- Spécifique : intégration dans tous les dossiers ; suppression des actions SPE obsolètes.
4.2.6. Création automatique de patch
Développement > Utilitaire > Patch > Création de patchs
Cette fonction permet de créer une archive contenant des développements spécifiques créés dans le
dossier courant, ainsi qu’un certain nombre d’éléments de paramétrage modifiés entre deux dates.
Une fois cette fenêtre de sélection préliminaire saisie et validée, le traitement de sélection s’exécute
(une fenêtre de progression affiche la sélection en cours), puis une deuxième fenêtre s’ouvre.
Cette fenêtre de validation présente un tableau listant, pour chacun des types d’éléments susceptibles
d’être « patchés », le nombre d’éléments concernés. La fonction Détail, accessible par clic droit,
permet alors de visualiser les éléments sélectionnés. Il est encore possible (par le champ Oui / Non)
de désélectionner globalement un type d’élément.
Lorsque cette dernière fenêtre est validée, l’extraction se fait dans le fichier de patch, et la fonction se
termine.

Sage ERP X3
Notes sur la « Génération directe »
Si la case « Génération directe » est cochée, l’extraction va se faire sur la liste des éléments restés
sélectionnés sans autre filtre possible Si cette case n’est pas cochée, le fichier de patch qui sera créé
ne contiendra qu’un en-tête avec la liste des éléments à « patcher ». Il suffira, pour générer
effectivement le fichier avec son contenu, de rappeler ce fichier en création manuelle de patch. La
question Chargement d’objet sera alors posée. En répondant Oui à cette question, on rechargera
l’intégralité de l’en-tête du patch. Il sera alors possible de modifier manuellement la liste détaillée des
objets à « patcher », de la compléter, et de lancer finalement l’extraction des éléments du patch pour
réécrire le fichier de patch avec à la fois l’en-tête listant les éléments et leur contenu.

Sage ERP X3
5. LE SERVEUR BATCH
Un traitement batch est un processus exécuté sans interaction avec un utilisateur. En général ce
processus est dédié aux traitements sur un ensemble de données qui peut être volumineux.
Ils sont surtout utilisés pour des processus automatisés, déclenchés périodiquement.
Exploitation > Serveur batch > …
En informatique, un traitement batch est un traitement à déclenchement automatisé. Ils sont surtout
utilisés pour des tâches automatisées, notamment pour la gestion des comptes sur le parc
informatique d'une entreprise, université,...
5.1. CARACTERISTIQUES DU SERVEUR BATCH

Dans Sage X3, le serveur batch est un processus fonctionnant en arrière-plan sur le serveur
d’application. Il gère le lancement de tâches batch (des traitements Sage X3 ou des commandes OS)
et il est exploité dans un environnement dédié. Il utilise les ressources définies dans le répertoire
..\Runtime\ SERVX3.
Les tâches soumises au serveur batch s'appellent des requêtes.
5.1.1. Mise en service du serveur batch

Il est possible d’activer les services selon les modes suivant :
- au lancement du système : adonix -a -l lang SERVX3
- à partir de Sage X3 : Exploitation / Serveur batch / Activation serveur
- automatiquement à la connexion d'un utilisateur (paramètre DEMSRV).
5.1.2. Arrêt du serveur :

Il est possible d’arrêter le serveur selon :
- à partir de Sage X3 : Exploitation / Serveur batch / Désactivation serveur
- en créant un fichier stop dans le répertoire FIL du dossier SERVX3 (sur une application en
local C:\Sagex3\X3V5T\runtime\SERVX3)
- en arrêtant la base (par exemple pour une sauvegarde)
5.1.3. Paramètres superviseur associés

NIVBATCH Paramètre modifiable par utilisateur permettant de définir un filtre sur les
tâches qu’il peut utiliser (chapitre superviseur, groupe habilitations)
EXTBATCH Paramètre modifiable par utilisateur permettant d’autoriser ou non le
lancement de tâches par un processus externe. (chapitre superviseur, groupe habilitations),
DEMSRV Paramètre modifiable par utilisateur permettant d’activer le serveur batch à sa
première connexion. (chapitre superviseur, groupe Performance)

Sage ERP X3
5.2. PRINCIPES DE FONCTIONNEMENT

Le serveur batch fonctionne par "polling" c’est-à-dire en interrogeant périodiquement la table des
requêtes « ABATRQT ».
Lorsque l'heure de démarrage d'une requête est arrivée ou dépassée, la requête est lancée (sauf si
elle est trop en retard, ou si le nombre maximum de tâches simultanément en cours est dépassé).
Lorsque le temps maximum (time-out) d’exécution alloué à une tâche est dépassé, la tâche est
interrompue.
Une requête est une demande d’exécution d’une ou plusieurs tâches soumises au serveur :
Par la fonction de soumission des requêtes : Exploitation > Serveur batch > Soumission des requêtes.
Depuis la fonction de surveillance des requêtes à l’aide d’un clic droit sur le tableau des requêtes
Exploitation > Serveur batch > Gestion des requêtes.
En déposant un fichier dans un répertoire du serveur de traitement, à l’aide d’un automate externe
(Pilote d’exploitation).
Par le biais d'un abonnement, c'est à dire une requête à lancer périodiquement.
Exploitation > Serveur batch > Gestion des abonnements.
Note technique :
Polling : Examen répété de l'état d'un ou plusieurs éléments d'un système pour y détecter un
changement d’état éventuel.
5.2.1. Définition d’une tâche

Une tâche est définie en spécifiant une fonction, un traitement Sage X3, un shellscript (sous UNIX™)
ou un script (Windows™).
Exploitation > Serveur batch > Gestion des tâches

Sage ERP X3
Code tâche : Code identifiant le processus qui sera activé par le serveur batch. A un instant
T une seule tache ayant ce code peut être active.
Actif : Ce témoin doit être à Oui pour que la tâche soit exécutée.
Module : Une tâche doit être rattachée à un module.
Type tâche : Traitement c’est un processus écrit dans le langage X3, sinon ce peut être un
script écrit dans le langage de la plate forme du serveur de traitement.
Time-out : Durée en minutes au-delà de laquelle le serveur batch interrompra la tâche.
Retard admissible : Si la tâche n’a pas pu être lancée au-delà de ce délai, elle ne sera pas
exécutée.
Niveau autorisation : Niveau minimal que doit avoir l'utilisateur pour lancer la tâche (paramétrage
utilisateur)
Priorité : Paramètre transmis au système d’exploitation

Service : Numéro de service (par défaut c’est le service adonix)
Contraintes horaires : Identifiant de la contrainte horaire à utiliser pour activer la tâche
Fonction : Code de la fonction X3 correspondant au traitement à activer
Traitement : Code du Shellscript ou du .bat à activer dans le cas ou le type de tâche est un
script.
Multi-dossiers : Si ce témoin est à Oui, la tâche est utilisable pour des traitements réalisés sur
les données de différents dossiers X3 de la solution.
Mono Utilisateur : Si ce témoin est à Oui, la tâche est activée que si aucun processus batch ou
transactionnel n’est actif sur le dossier.
Message Utilisateur : Si ce témoin est à Oui, un avertissement sera envoyé à l’utilisateur à la fin de
l’exécution de la tâche.
Notes techniques
Un processus x3 peut être exploité à l’aide d’une tache batch si :

Il ne gère pas pendant l’exécution du processus un dialogue utilisateur
L’action associée à la fonction X3 exécutée est marquée comme étant autorisée à être exploitée en
mode batch. Ce point est vu dans le cours développement.
Un processus exploité en mode batch génère automatiquement une trace.

Sage ERP X3
Une tâche est identifiée dans X3 par son code, vu du système d’exploitation son identifiant est son
PID (Processus Identification). L’activation d’une tâche liée à une fonction X3 provoque l’ouverture
d’une session X3 avec entre autre l’initialisation des variables globales liées au couple dossier
utilisateur.
5.2.2. Définition d’un groupe de tâches

Un groupe de tâche est une suite de tâches exécutées en séquence. Cette suite est activée en une
fois (soit par soumission du groupe, soit par abonnement).
Les tâches du groupe sont exécutées séquentiellement dans le temps (chaque tâche s'exécute
lorsque la précédente se termine) en créant chacune leur propre trace. L’enchaînement de la tache
suivante est effectif à la condition que la tâche précédente se termine sans erreur.
Exploitation > Serveur batch > Groupe de tâches
Niveau d’autorisation : Niveau minimal que doit avoir l'utilisateur pour lancer le groupe de tâches
(paramètre utilisateur)
Contrainte horaires : Table définissant les horaires admissibles
Code tâches : Liste des tâches à enchaîner
Remarque :
A la saisie d’une requête sur le groupe, tous les paramètres des tâches liées sont saisis.
Un point d’entrée permet, grâce à une variable nommée GERRBATCH, de définir des statuts d’erreur
arrêtant un enchaînement de tâches (il faut que GERRBATCH soit supérieur ou égal à 100).

Sage ERP X3
5.2.3. Soumission d’une requête

La soumission d’une requête se fait par la saisie :
- du dossier où elle doit être exécutée

- du code utilisateur
- de la tâche ou du groupe
- de l’heure demandée d’exécution
- par la saisie des paramètres de la fenêtre de validation
Exploitation > Serveur batch > Soumission des requetes
Remarque :
Le dossier par défaut est le dossier courant. Il peut s’agir d’un autre dossier à condition que la tâche
soit cochée Multi-dossiers.
Si le code utilisateur n’est pas celui de l’utilisateur courant, la saisie du mot de passe est obligatoire.
La case à cocher Modèle permet de créer un fichier modèle pouvant ensuite être utilisé pour une
soumission de tâches. Dans ce cas, la tâche n’est pas exécutée. Ce fichier modèle s’appelle
MATACHE.mod (MATACHE étant le code de la tâche).

Sage ERP X3
5.2.4. Contraintes horaires & calendrier

Les transactions suivantes sont à mettre en œuvre si l’on désire planifier les processus d’exploitation
des Traitements batch. Ce paramétrage est utilisable par l’ensemble des processus batch quelque
soit le dossier X3 contenant les données exploitées. Ce paramétrage est à utiliser si l’on met en place
des abonnements de tâche ou groupe de tâches.
Les contraintes horaires permettent de définir les jours de la semaine et les horaires admissibles pour
lancer le batch associé à une tâche ou à un groupe de tâches.
Paramétrage > Exploitation > Serveur batch > Contraintes horaires
Le calendrier est une table contenant les dates des jours fériés. Pour ces dates les processus batch
ne seront pas activés.
Remarque :
Deux types de jours : ouvrés et non ouvrés / fériés, chacun avec des plages horaires possibles
Seule l’heure de lancement définie est contrôlée. Si la tâche ne peut pas être lancée à l’heure prévue
et peut l’être dans une plage horaire qui n’est plus la bonne. Pour éviter qu’une tâche soit lancée dans
une plage horaire inadéquate, il faudra utiliser le paramètre définissant le retard admissible.

Sage ERP X3
5.2.5. Les abonnements

Cette fonction permet de définir un traitement périodique qui sera activé par le serveur batch en
fonction des paramètres de l’abonnement.
Exploitation > Serveur batch > Gestion des abonnements
Code dossier : Code du dossier X3 sur lequel les données seront exploitées.
Code utilisateur : Code de l’utilisateur X3 pour le compte duquel le traitement sera effectué
Groupe: Code du groupe de tâches ou
Tâche : Code de la tâche.
Périodicité : Type de périodicité attribué à l’abonnement
Hebdomadaire : dans ce cas on indique dans le tableau les jours de la semaine pour lesquels
le traitement sera à exécuter
Mensuel : dans ce cas on indique les quantièmes du mois pour lesquels le traitement
sera exécuter. Le témoin fin de mois permet d’activer le traitement le dernier
jour du mois.
Jours exclus : Code du calendrier à utiliser pour déterminer les jours ouvrés.
Si la tâche doit être activée de manière répétitive il faut renseigner :
Heure de début : Heure de lancement de la première exécution de la tâche

&
Heure de fin : Heure de lancement de la dernière exécution de la tâche
&
Fréquence : Fréquence de lancement du traitement en minutes
Une seule requête : Cette case peut être cochée si l'abonnement est défini en fréquence. Si elle
est cochée, une seule requête est lancée par jour et dès que le traitement est
terminé, la tâche se met en veille pendant le nombre de minutes définies par
la fréquence, pour reprendre ensuite son exécution, ce jusqu'à ce que l'heure
de fin soit dépassée. La requête est alors affichée dans l'état En cours
pendant tout l'intervalle d'exécution. On garantit ainsi que la requête est
toujours présente en mémoire une fois qu'elle aura été lancée, ce qui peut
être au détriment d'autres tâches si le nombre maximum de tâches lancées
simultanément est atteint.
Epuration : Cette case ne peut être cochée que pour un abonnement défini en fréquence.
Dans ce cas, on ne garde pas trace des exécutions successives de la tâche
dans la fonction de gestion des requêtes. Seule la requête en cours et la
précédente requête sont conservées.
Sinon, la tache peut être activée trois fois au maximum à heure fixe et il faut
renseigner
Heure : Heure d’activation de la tâche
Exécution forcée Cet indicateur ne peut être coché que si l'on donne des heures fixes
d'exécution pour un abonnement. Il garantit la création de la demande
d'exécution même si l'heure est dépassée au moment où le serveur batch
traite les abonnements de la journée.
Remarque, un groupe de taches ne peut pas être répétitif.

Sage ERP X3
5.3. SURVEILLANCE DES TACHES

La gestion des requêtes permet de surveiller les requêtes en attente, les tâches en cours d'exécution
ou terminées, voir de les modifier.
Il est possible de visualiser les différents fichiers traces, de soumettre une nouvelle requête, de
supprimer une requête en attente ou d'en modifier les paramètres.
Exploitation > Serveur batch > Gestion des requêtes
Remarque :
Fonctions accessibles par clic droit :
- Supprimer la requête, Cette action permet de supprimer une requête en attente.

- Modifier la date et l’heure de lancement, ainsi que les paramètres sur des tâches non encore
lancées.
- Consulter la trace des tâches en cours, avortées ou terminées.
- Relancer des tâches terminées ou avortées, ce qui ajoute une ligne dupliquant la ligne choisie
(avec un décalage d’une minute pour permette de modifier ses caractéristiques avant qu’elle
soit lancée)
- Interrompre une requête en cours d’exécution.
Note : l’habilitation à cette fonction permet de préciser si la personne a accès à toutes ces requêtes
ou uniquement à celles qui lui appartiennent.
Pour chaque requête les informations du tableau importantes sont :
Numéro : C’est le compteur des requêtes X3. Chaque requête se voit attribué un numéro i
ncrémenté séquentiellement par pas de un.
Dossier : Code du dossier X3 sur lequel le traitement est exécuté
Util : Code de l’utilisateur X3 lié à la session batch du traitement
Mono : Indicateur précisant si la tache est déclarée mono utilisateur
Etat : Statut de la requête
- Attente : le traitement n’a pas encore démarré
- Encours : le traitement est en cours d’exécution
- Terminé : le traitement est terminé sans erreur
- Erreur : le traitement est terminé avec des erreurs
- Aborté : le traitement a été interrompu soit volontairement soit à cause d’une erreur
non récupérable.

Sage ERP X3
N° Processus : C’est l’identifiant du traitement vu du système d’exploitation (PID)
Structure du fichier log du serveur batch
Le serveur batch possède une trace dédiée dans laquelle figure pour chaque processus activé:
La date et l’heure de démarrage
Le code du dossier sur lequel s’applique le processus
Le PID (Processus Identification Windows)
Le Numéro du processus X3
Le code de la fonction X3 correspondant au traitement
Validation des factures d’achat (FUNPIH)
Calcul des pyramides (PYRAMID)
etc..
Le serveur batch possède une trace dédiée dans laquelle figure pour chaque processus terminé lLa
date et l’heure de fin du traitement, le numéro du processus X3 et le code retour de la fonction X3
Exemple
=1000 00000004 07/11/07 12:27:46 Activation requête (DEMOFRA ACCBATCH T BATCHCPT 5600) (51000)
>2000 00000004 07/11/07 12:31:03 Requête interrompue par ADMIN pour le motif "RLV" (DEMOFRA ACCBATCH T BATCHCPT)
(32000)
=6000 00000000 07/11/07 12:38:10 ADMIN : Ordre d'arrêt transmis au serveur (56000)
=5000 00000000 07/11/07 12:38:11 Désactivation du serveur (55000)
=0000 00000000 07/11/07 12:38:36 Activation du serveur (PID=4048 ,USR=ADMIN ,SRV=1801) (50000)
=0000 00000000 07/11/07 12:38:41 Le serveur est activé \ Processus numéro 4048 (50000)
<1000 00000005 07/11/07 13:00:25 Délai dépassé (DEMOFRA FUNPIH T ) (21000)
=1000 00000006 07/11/07 13:09:40 Activation requête (DEMOFRA FUNPIH T 5888) (51000)
=1000 00000007 07/11/07 13:10:49 Activation requête (DEMOFRA ACCBATCH T BATCHCPT 5872) (51000)
Le caractère en première position de chaque ligne peut être utilisé comme filtre pour rechercher les
erreurs. Il faut filtrer les lignes qui débutent par le caractère inférieur.

Sage ERP X3
5.4. SOUMISSION DE TACHE PAR FICHIER
La soumission de tâche par fichier permet le déclenchement de tâches X3 par des processus
externes. Ce mécanisme est à mettre en œuvre si l’on désire que l’activation des processus batch X3
soit pilotée par un superviseur d’exploitation ou si l’on désire synchroniser un processus externe avec
un traitement X3. Par exemple activer un import X3 après l’extraction des données d’une application
partenaire.
Pour activer cette fonctionnalité le paramètre superviseur EXTBATCH du chapitre habilitation (AUZ)
doit être positionné à Oui.
De plus il faut définir les répertoires de communication avec le serveur batch

Paramétrage / Exploitation / Paramètres du serveur batch
Principe de fonctionnement
La présence d’un fichier XXXX.job permet au serveur batch d’identifier un processus à activer. Le
fichier XXXX présent dans le répertoire job contient les codes et valeurs des paramètres nécessaires
à la soumission de la requête.
Dès que le serveur batch à pris en compte ce type de demande un fichier de même nom que le fichier
job est créé dans le répertoire req, ici XXXX.req Le processus peut être en attente.

Sage ERP X3
Dès que le traitement devient actif, un fichier XXXX.run est créé dans le répertoire run. Le fichier
XXXX.req est copié dans le répertoire old pour conserver les paramètres de la demande de
traitement.
Lorsque le processus est terminé un fichier XXXX.sta est créé dans le répertoire sta. Ce dernier
contient entre autre le statut de fin du traitement.
Remarque :
Si des erreurs sont détectées dans les paramètres de lancement de la tâche (exemple : utilisateur
incorrect), le fichier passe directement du statut de .job à celui de .old et un fichier .sta est créé : la
tâche n’aura pas eu le temps d’être exécutée.
Si un fichier est dans l’état .req et qu’un fichier .kil est déposé, il passe directement en statut .old et
un fichier .sta est créé. S’il était déjà dans l’état .old (parce qu’un fichier .run existe), la tâche est
interrompue puis le fichier .sta est créé.
Dans tous les cas, le fichier .kil est effacé lorsque la demande d’interruption a été prise en compte
Un fichier de requête se présente sous la forme suivante :
DOSSIER=MONDOSS
UTIL=TOTO
PASSE=WXTYSF La première partie correspond aux informations génériques de
GRP= lancement (dossier, utilisateur, mot de passe crypté, tâche ou
TACHE=VALSTA groupe de tâches, date et heure de lancement).
DATE=20030929
HEURE=0752
CODSTA=CA
DATDEB=19990601
La seconde aux paramètres saisis lors du lancement de la tâche.
DATFIN=20030930
SOCIETE=APN
TYPMAJ=2
ZSOCIETE=Société NEGOCE

Sage ERP X3
Le fichier de statut (requete.sta) est normalisé pour faciliter l’exploitation :
Une ligne de longueur fixe, codage ascii 7 bits, séparateur entre deux champs (le « : »), Fin de ligne :
CR/LF ou LF selon le système
Statut normalisé sur 5 chiffres FSXXX, avec :
F=0 : fin normale, SXXX=nombre d’avertissements
F=1 : fin sur erreur de traitement, S=sous-cas, XXX=détails
F=2 : traitement non lancé, S=sous-cas, XXX=détails
F=3 : traitement interrompu, S=sous-cas
Le fichier de trace du serveur utilise la même présentation

La trace détaillée est dans un fichier nommé RQTnnnnnnnn.tra (nnnnnnnn=no requête sur 8
caractères)
Note : date/heure correspond à AAAAMMJJhhmmss
Remarque :
Consulter la documentation technique détaillée (RQT_FILE.htm).

Sage ERP X3
5.5. PARAMETRES DU SERVEUR BATCH

Paramétrage > Exploitation > Serveur batch >Paramètres serveur batch
Temps entre 2 scrutations : Définit le temps entre deux lectures successives de la table des requêtes.
Influe sur le délai de prise en compte d'une requête et inversement sur la charge du système.
Influe sur le temps d'entrée dans la fonction de surveillance des tâches.
Influe sur le temps d'arrêt d'une tâche trop longue. La scrutation time-out est consommatrice de
ressources.
Nombre maximum de requêtes actives : Le nombre maximum de requêtes simultanées dépend de la

licence Sage X3.
Utilisation des fichiers batchs : Si cette case est cochée, il sera possible de lancer des tâches par la
création de fichiers dans un répertoire dédié. Ceci suppose que les utilisateurs aient le paramètre
EXTBATCH égal à Oui.
Listes des répertoires avec les extensions (.job … .old) :Définit les différents répertoires utilisés pour la
gestion des requêtes soumis par fichier. Ces répertoires sont supposés être par défaut sur le serveur
d’application (un autre serveur du réseau est envisageable, avec la syntaxe serveur@répertoire, mais
en aucun cas un répertoire sur le poste client).

Sage ERP X3
5.6. NOTES TECHNIQUES

Les fichiers stratégiques du serveur batch
Ils sont situés sur le serveur d’application au niveau du répertoire …\Runtime\SERVX3/FIL :
la présence d’un fichier .run indique normalement que le serveur est en fonctionnement
la présence d’un fichier .stop indique qu’une demande d’arrêt a été transmise au serveur (mais que
les tâches lancées par le serveur ne doivent pas être interrompues)
la présence d’un fichier .kill indique qu’une demande d’arrêt a été transmise au serveur (avec
demande d’interruption des tâches lancées)
et au niveau du répertoire SERVX3/TRA :
le fichier serveur.tra contient la trace du serveur

les fichiers RQTnnnnnnnn.tra contiennent la trace des tâches
Les traces des requêtes sont purgées avec le bouton Epuration de la fonction de consultation des
requêtes.
Les tables du serveur batch
Table Intitulé de la table

ABATABT [ABA] Définition des abonnements
ABATABTD [ABD] Paramètres des abonnements
ABATCAL [ABC] Calendrier du serveur batch
ABATGRP [ABG] Définition des groupes de tâches
ABATPAR [ABP] Paramètres du serveur batch
ABATRQT [ABR] Table des requêtes batch
ABATTAC [ABT] Définition des tâches
ADOSSIER [ADS] Table des dossiers
Epuration des requêtes et des traces
Dans le répertoire …\Runtime\ServX3\TRA on trouve les fichiers trace des requêtes exécutées par le
serveur batch. Ces traces sont épurées lors de l’activation du bouton Epuration présent dans la
fenêtre de la fonction de gestion des requêtes.

Sage ERP X3
Les points d’entrée
Point d’entré Traitement Objet

REQUETE SERVEUR Permet de compléter les paramètres au démarrage d'une tâche
abonnée ou d’empêcher son démarrage.
Le point d’entrée REQUETE est appelé avant chaque écriture sur la
table ABATRQT. La classe [F:ABR] est en ligne. La variable GPE
permet, si elle est différente de 0, de ne pas créer l’enregistrement.
Le contenu de l’enregistrement ABATRQT est significatif
SETREQ SERVJOB Ce point d’entré permet de récupérer le numéro de requête pour
synchroniser des processus. Le contenu de la table ABATRQT
n’est pas significatif.
Ce point d'entrée SETREQ est positionné dans le traitement
SERVJOB après la création de la requête dans la table ABATRQT.
Toutes les variables globales de l'application ne sont pas encore
définies.
Le nom de la trace du serveur batch est contenu dans la variable
FICTRA et il est possible d'écrire dans cette trace en utilisant le sous-
programme STRACE du traitement SERVEUR. Les arguments de ce
sous-programme sont dans l'ordre :
FICTRA (Alpha),
Numéro d'erreur (Integer),
Numéro de requête (Integer),
Commentaires (Alpha).
FICTRA contient le nom de la trace ouverte
JOB contient le nom du fichier job
APPLI contient le nom de l'application sur laquelle la requête est
créée
FINREQ REQUETES Ce point d'entrée FINREQ est placé après l'exécution d'une tâche
batch, si la requête n'a pas été interrompue volontairement ou par le
serveur batch.
Il est positionné dans le traitement REQUETES juste après la mise à
jour du flag de la requête et avant le déclenchement des autres
requêtes du même groupe.
Si dans la tâche batch, une trace n'a pas été ouverte, la trace ouverte
courante est dans le fichier
"RQT"_numéro_requête.tra. du répertoire TRA du serveur batch
FICTRQ contient le nom de la trace ouverte
GERRTRACE contient le nombre d'erreurs dans la trace
OKRQT contient le GOK éventuellement gérée dans la tâche.
ERRREQ REQUETES Le point d'entrée ERRREQ est placé dans les sous-programmes de
gestion des erreurs du traitement REQUETES. Il permet de récupérer
la main suite à un abort de la tâche pour permettre en autre d’envoyer
une alerte au processus externe qui à activer la tâche via un fichier
job.
Ce point d'entrée permet de gérer une gestion plus fine des erreurs.
FICTRQ contient le nom de la trace ouverte
GERRTRACE contient le nombre d'erreurs dans la trace
OKRQT contient le GOK éventuellement gérée dans la tâche

Sage ERP X3
5.7. LA TACHE BATCH COMPTABLE

La tâche comptable est un cas particulier de tâche batch :
- elle a pour code ACCBATCH et doit être lancée en permanence dans chaque dossier
d'exploitation de la solution X3 entreprise
- elle met à jour les écritures comptables créées depuis les autres modules (ventes, achats,
stocks, gestion de production, immobilisations, comptabilité tiers, comptabilité générale)
On ne peut lancer qu'une seule tâche comptable par dossier.
Elle possède une fonction de surveillance particulière
Exploitation > Serveur batch > Tache comptabilité
Remarque :
Les écritures automatiques de la comptabilité sont également passées par cette tâche. Seules les
écritures saisies directement (OD) sont enregistrées directement.
Pour consulter les écritures comptables réalisées par les modules partenaires, utiliser le bouton trace.
Le lancement de cette tâche peut être abonné (ACCBAT)
Son arrêt peut être aussi abonné (ACCSTOP)

Sage ERP X3
Fonctionnement de la tâche comptable
Les écritures automatiques de la comptabilité sont également passées par cette tâche. Seules les
écritures saisies directement (OD) sont enregistrées directement.
Tables associées
Table Intitulé de la table

GACCTMP Entête des pièces comptables temporaires *2
GACCTMPD Lignes des pièces comptables temporaires
GACCTMPA Lignes analytiques des pièces comptables temporaires
MTCBATCH Lettrage temporaire *2
GACCENTRY Entête des pièces comptables définitives
GACCENTRYD Lignes des pièces comptables
GACCENTRYA Lignes analytiques des pièces comptables
GACCDUDATE Echéances
BALANCE Balances
BALANA Balances analytiques
BATCH Mémorisation du statut de la tache comptable *1
*1 La table BATCH mémorise le statut de la tache comptable batch. Suite à un arrêt du serveur ou un
incident du même type. Cette tâche peut être dans un état instable ne permettant pas son
redémarrage. Il faut alors intervenir sur cette table avec les outils de maintenance pour réinitialiser
dans l’enregistrement ACCENTRY les champs PID, RQT et STA

Sage ERP X3
*2 Dans les tables GACCTMP & MTCBATCH un champ identifie les pièces qui n’on pas été prise en
compte suite à une erreur lors de la création des pièces définitives (problème de paramétrage des
pièces automatiques par exemple)
Traces
La trace des pièces comptables est dans le fichier ACCENTRY.tra dans le répertoire TRA du dossier.
Une trace VALPIECE.TRA contient les références des pièces en anomalie.

Sage ERP X3
6. GESTION DES ETATS
Ce chapitre présente les opérations permettant de mettre en production des états dans le contexte de
Sage X3. Il se limite à la présentation des principes de fonctionnement des éditions, aux techniques
de passage des paramètres d’édition de l’environnement de l’utilisateur X3 à celui des outils d’édition,
aux mécanismes possible d’automatisation de la production des éditions et enfin il présente une aide
au diagnostic des incidents.
- Principes de base
- Le dictionnaire des états
- Lancement des états
- Affectation des codes internes
- Valeurs par défaut des paramètres
6.1. PRINCIPES DE BASE

Les états sont :
Définis à l’aide du générateur d’états « Crystal Reports ™». (fichiers d’extension .rpt ). Actuellement
c’est la version V10 de ce logiciel qui est supportée dans le contexte X3.
Répertoriés dans un dictionnaire d’états qui pointe sur un état et référence en outre leurs paramètres
Les états sont téléchargés depuis le serveur, puis exécutés :

- Directement sur le poste client via une librairie (DLL) Crystal Reports
- Sur un serveur d’impression quand l’état est lancé depuis un poste Web
- Sur un serveur d’impression quand l’état est lancé depuis une tâche batch
Un serveur d’impression est un serveur Windows sur lequel sont installées, outre des composants
SAGE X3, les librairies Crystal Reports idoines.
Les éditions relatives aux données de l’application sont gérées avec le logiciel tiers « Crystal
Reports ™».
La fonction « Impression » déclenche l’édition d’un état (standard ou personnalisé) du progiciel en

deux étapes :
La saisie de valeurs de critères
Le lancement du module d’édition (DLL Crystal Reports ™).
6.1.1.1. Notion de destination

Avec Sage X3, le terme destination désigne le support du résultat d’une édition. En effet Crystal
Reports ™ permet d’adresser ce résultat soit à une imprimante physique soit à un convertisseur
permettant de conserver ce résultat sous la forme d’un fichier PDF XLS ou Doc par exemple. Nous
verrons dans la suite de ce chapitre les différents supports disponibles et le paramétrage nécessaire à
chaque cas.

Sage ERP X3
6.2. LE DICTIONNAIRE DES ETATS

Le rôle du dictionnaire des états est de faire le lien avec le programme Crystal Reports ™, contenu
dans un fichier rpt et X3. C’est une fonction située dans les outils de développement
Il est donc nécessaire, lorsqu’on produit de nouveaux états :

De respecter des règles de nommage (noms commençant par X, Y, ou Z)
De marquer dans le dictionnaire X3 ces états par un code activité spécifique
De même, il faut, si on modifie des états standards :

Renommer les fichiers Crystal Reports ™ d’extension .rpt
Modifier la fiche de l’état pour le faire pointer sur l’état modifié
Certains champs du dictionnaire des états sont considérés comme du paramétrage

Leur modification est sauvegardée
Il ne faut donc pas utiliser de code activité si seuls ces champs sont modifiés
Pour pouvoir déclarer un nouvel état dans le dictionnaire X3, la présence du fichier programme .rpt est
nécessaire dans le répertoire REPORT. Dans le cas d’un dossier multi langues les répertoires des
fichiers .rpt sont organisés de la manière suivante :
Dans chaque dossier X3 de la solution on trouve un répertoire REPORT. Dans ce répertoire un sous
répertoire est créé par code langue utilisé dans le dossier X3. Les fichiers Crystal Reports ™ sont à
déposer dans les répertoires correspondants à la version de la langue pour laquelle l’état est produit.
6.2.1.1. Le dictionnaire des états : premier onglet

Développement > Dictionnaire des traitements > Etats

Sage ERP X3
Actif : Témoin permettant d’utiliser un état si cette valeur est à Oui
Intitulé court : Désignation de l’état utilisée dans les fenêtres de sélection proposée aux utilisateurs
dans le cas ou un choix est possible
Module : Code du module X3 auquel l’état est rattaché.
Groupe : Code du groupe de rattachement de l’état permettant de gérer des habilitations. Les
groupes dont déclarés dans le Menu local 97 qui est personnalisable.
Muti langues : Si cette case est cochée, cela indique que l'état a été généré dans toutes les langues
gérées par le dossier, sinon l'état est uniquement dans la langue de conception
Langue origine : Cette zone permet de réserver l'état à une langue. La langue dans laquelle à été
conçu l'état.

Sage ERP X3
6.2.1.2. Bloc Caractéristiques de la sortie

Ce bloc permet de définir le support sur lequel l’édition est exploitée après sa production par le moteur
Crystal Report.
Type : Le type sert à déterminer une destination dans le cas ou la formule complément et la
destination ne sont pas renseignées. Au lancement de l'impression, le superviseur détermine la
destination en fonction de la valeur de ce paramètre superviseur.
Normal : paramètre PRT1

Fax : paramètre PRT2
Thermique : paramètre PRT3
Couleur : paramètre PRT4
Ces paramètres sont déclarés dans le chapitre superviseur Groupe impression IMP. Ils contiennent
une valeur définissant une destination d’impression.
Destination : Contient le code de la destination d’impression à utiliser pour produire l’édition. Ce

code doit être déclaré dans le dictionnaire des destinations.
Obligatoire : Si cette case est cochée, l’utilisateur ne peut pas modifier la destination au lancement
de l'impression de l'état.
Formule complément : Ce champ sert à la recherche d'une destination par utilisateur et par état.
Cette destination, si elle est trouvée, sera prioritaire par rapport à celle précisée au-dessus. Cette
formule est évaluée au lancement de l’impression.
Exemple: Si pour l'état X, on a défini un complément avec la valeur "PAR" correspondant à
l'imprimante Y et que la formule de l'état X contient l'expression "PARAM(site)", alors, au moment
d'imprimer l'état, si le paramètre "site" est égal à PAR, l'imprimante sera initialisée à Y.
Non exécutable : Ce champ permet d’interdire l’utilisation de l’état directement à partir du

menu impression de l’utilisateur. Il permet de laisser l’état disponible pour d’autres contextes.
Batch obligatoire : Ce témoin permet de réserver l’utilisation de l’état aux processus batch.
Contraintes horaires : Code d’une contrainte horaire batch. Voir le chapitre sur le serveur batch.
6.2.1.3. Bloc Crystal Report

Ce bloc permet d’identifier les fichiers programmes Crystal Reports ™ à associer au code état X3.
On peut associer de un à cinq états à un même code X3. Ces éditions seront exécutées l’une après
l’autre dans des fichiers séparés. Pour pouvoir regrouper plusieurs états Crystal Reports ™, la valeur
d’un même paramètre doit être identique au moment du lancement. Le traitement d'initialisation est
exécuté pour chaque état de ce tableau
Nom état : Nom du fichier programme Crystal Reports ™ sans son extension rpt.
Orientation : Format de l’édition portrait ou paysage. Cette information doit être en

cohérence avec celle saisie sur l'état Crystal Report ™.
6.2.1.4. Bloc Traitements

Ce bloc permet de déclarer les traitements qui seront exécutés après la saisie des paramètres et
avant l’activation des programmes Crystal Report ™.

Sage ERP X3
Traitement standard Nom du traitement standard X3. Il permet d'initialiser des variables définies
dans le paramétrage de l'état ou éventuellement de préparer des fichiers avant l'impression, ou même
de mettre à jour des champs dans la base de données (ex: flag d'édition).
Un traitement est réservé au développement standard, et l'autre aux spécifiques
6.2.1.5. Bloc autorisations

Ce bloc contient de fixer des restrictions à l’utilisation de l’état.
Autorisation site : Ce témoin permet d’indiquer que le code site est un critère de définition du droit
d’usage de l’état. Si ce témoin est positionné à Oui, il faut indiquer le code de la fonction à utiliser pour
vérifier les droits de l’utilisateur.
Code d'accès : Ce code d'accès permet l'autorisation ou l'interdiction d'exécution de l'état par un
utilisateur.
Remarque :
Le menu local permet d’étendre les groupes d’états (une habilitation globale par groupe existe dans la
définition des utilisateurs). On retrouve ensuite l’habilitation plus fine par code activité (c’est bien sûr le
droit d’exécution qui est utilisé pour avoir le droit d’imprimer).
La gestion des autorisations par site fonctionne de la façon suivante :

Si une autorisation par site ou par société existe, on vérifie quels sont les sites autorisés à l’utilisateur
pour la fonction mentionnée.
Si aucune fonction n’est mentionnée, on reprend les droits par site sur la fonction RPTnn, nn étant le
numéro du groupe auquel appartient l’état
On fait alors un contrôle sur les paramètres sociétés et sites de la façon suivante :
Si un paramètre de type société est présent dans les paramètres de l’état, on vérifie que la totalité des
sites de la société est accessible à l’utilisateur; s’il s’agit d’un paramètre de type site, on vérifie qu’il
est accessible à l’utilisateur
Si un paramètre de type bornes de société ou bornes de sites est présent dans les paramètres de
l’état, on vérifie que tous les sites compris dans ces bornes sont accessibles.
Si une erreur quelconque se produit, on refuse l’édition de l’état en signalant la liste des sites
auxquels l’utilisateur n’a pas accès.
Attention, il s’agit uniquement d’un contrôle de bornes. On ne contrôle pas (et on ne peut pas le faire)
que la logique de l’état ne va pas rechercher des données liées à des sites non accessibles.
6.2.1.6. Onglet Paramètres
Cet onglet contient le tableau des paramètres qui seront envoyés au programme Crystal Report ™.
Ce tableau peut contenir un maximum de 100 paramètres.
Pour chaque paramètre on définit
Paramètre La valeur de ce code est transmise à Crystal Report. Une fenêtre de sélection
permet de proposer l'ensemble des paramètres déjà existants dans les états
du dictionnaire X3. Pour une même notion, il est donc conseiller de réutiliser
les mêmes noms de paramètre.
Convention pour les paramètres exprimant une borne début et fin :
Ne saisir que la borne de début. Son code doit se terminer par le suffixe
« deb » ou « str ».
Le paramètre pour la borne de fin est généré avec la même racine que
la borne début et le suffixe « fin » ou « end ».
Il n'apparaît pas dans le tableau mais est passé à Crystal Report.

Sage ERP X3
Intitulé paramètre Destiné notamment à figurer sur les états et les écrans dans lesquels le code
de la fiche peut être saisi ou sélectionné. Ce texte permet de donner une
description en clair du paramètre.
Type Ce champ défini le format du paramètre. Les principaux types génériques sont
:
A: Alphanumérique
C: Entier court
L: Entier long
DCB : Décimal
D: Date
M: Menu local
D'autres types peuvent être utilisés, basés sur le dictionnaire des types des
données. La touche fonction F12 permet d'en obtenir la liste.
Longueur Permet de définir la longueur d'un champ lorsque ce champ utilise un type de
données générique dont la longueur n'est pas fixée par le dictionnaire des
types de données.
Menu Définit le numéro de menu local associée au champ défini sur la ligne.
D/F Ce témoin indique s'il faut saisir une fourchette de valeur. Le paramètre est
donc suffixé par « deb » ou « str ».
Sai Ce témoin indique si le paramètre est saisissable ou pas au lancement de

l'état.
Valeur par défaut (début) Cette zone contient la valeur par défaut du paramètre. Il est possible
de saisir une expression qui sera évaluée avant la saisie pour initialiser cette
valeur.
Valeur par défaut (fin) Cette zone contient la valeur par défaut de fin du paramètre.
Contrôle Cette zone contient une règle de contrôle de la saisie de la valeur du

paramètre. Il est possible de saisir une formule pour contrôler la saisie de ce
paramètre. La variable VALEUR représente la valeur saisie du paramètre.
Table de contrôle Une table de contrôle peut être utilisée pour vérifier la valeur du paramètre
saisie. Dans ce cas c’est la référence de cette table de contrôle qui figure
dans ce champ.
Paramètre objet/dépendance Permet de définir le premier élément de clé d'un objet, si cet objet a
une clé à deux composantes. Exemple : n° table pour une table diverse.
Particularité pour une table diverse dépendante : ce champ permet de saisir l'élément maître de
la table diverse "maître"; dans ce cas, le numéro de la table diverse est à saisir dans la colonne
"menu".
Options Saisissable si le type de donnée est lié à un objet. Ce champ permet de

définir une ou plusieurs options de filtre définies dans l'objet. Le superviseur contrôle la valeur saisie
dans le paramètre en fonction des filtres positionnés. De même, la fenêtre de sélection, tient compte
des filtres.
Paramètre de segmentation Cette zone contient un argument permettant de découper une édition.
Cette information doit être une donnée importante de l’édition. Par exemple le code société ou le code
site. Cette possibilité de segmentation est à mettre en œuvre pour les éditions volumineuses
contenant plusieurs dizaines de milliers de pages.

Sage ERP X3
6.2.1.7. Onglet Données
Intitulé Si l'état s'appuie sur au moins une table d'un autre dossier, on aura l'obligation
d'indiquer la source de données liée à chaque dossier supplémentaire sous la
forme « solution;dossier ». Il faut que le dossier soit un dossier lié dans la
gestion dossier.
Le nombre de sources de données est limité à 5. Le dossier saisi n'est, en fait,
qu'une valeur par défaut, puisque la source est modifiable au lancement de
l'impression. Si la solution n'est pas indiquée, le superviseur prend la solution
courante; il en est de même pour le dossier. Pour atteindre les tables du dossier
mère, on peut utiliser la variable GDOSX3, disponible pour tout produit. Pour
atteindre les tables du dossier d'exploitation X3, depuis un autre produit (géode
GX, Abel X3, Paie), les variables GSOLCPT et GDOSCPT contiennent
respectivement la solution et le dossier X3.
Dossier par
Table Tables associées à l'une des sources de donnée ci-dessus pour accéder à un
autre dossier. Une limite de 10 tables est à respecter. Le nom d'une table est
limité à 200 caractères.
Intitulé
Numéro numéro identifiant l'une des sources de données du tableau ci-dessus.
Source de données Destiné notamment à figurer sur les états et les écrans dans lesquels le code de
la fiche peut être saisi ou sélectionné. Ce texte permet de donner une
description en clair de la fiche concernée.
Si l'état s'appuie sur au moins une table d'un autre dossier, on aura l'obligation d'indiquer la source de
données liée à chaque dossier supplémentaire sous la forme « solution;dossier ». Il faut que le
dossier soit un dossier lié dans la gestion dossier. Le nombre de sources de données est limité à 5. Le
dossier saisi n'est, en fait, qu'une valeur par défaut, puisque la source est modifiable au lancement de
l'impression. Si la solution n'est pas indiquée, le superviseur prend la solution courante; il en est de
même pour le dossier. Pour atteindre les tables du dossier mère, on peut utiliser la variable GDOSX3,
disponible pour tout produit. Pour atteindre les tables du dossier d'exploitation X3, depuis un autre
produit (géode GX, Abel X3, Paie), les variables GSOLCPT et GDOSCPT contiennent respectivement
la solution et le dossier X3.
Ensuite, on indiquera pour chaque source de données, les tables utilisées dans l'état. Si une table
n'est pas référencée, elle sera automatiquement associée à la source de donnée du dossier
courant. De ce fait, les tables du dossier courant n'ont pas à être référencées ici. Le nom de la table
doit être celui utilisé dans Crystal ; cela peut être le nom de pseudonyme, s’il en existe dans
Crystal. Une limite à 10 tables est à respecter ici, limite due le serveur d’impression. Le nom d'une
table est limité à 200 caractères.

Sage ERP X3
6.3. LANCEMENT D’UN ETAT

L’activation d’un état est réalisée par plusieurs méthodes :
Par l’entrée de la barre de menu Fichier / Impression (ou Fichier / Liste) on lance alors un état
prédéfini (éventuellement une liste).
Par la fonction Impressions / Impressions

On visualise alors l’ensemble des états dans la liste gauche et on choisit celui qui doit être lancé en
saisissant les critères de sélection.
Par la fonction Impressions / Impression groupe / xxxx / yyyy

On choisit alors un état dans une liste d’états rattachés à un groupe (équivalent à un module), puis un
sous-groupe.
Depuis le dictionnaire des états via le bouton Impression
On doit alors saisir :
Les critères d’édition de l’état :
Soit ce sont des éléments simples de type numérique, alphanumérique, date ou menu local
Soit ce sont des bornes : valeur de début et valeur de fin
Exceptionnellement, sous forme
d’une liste de valeurs (pour segmenter l’état selon des bornes)
La destination de l’état :
Soit par un code destination défini dans une table avec la possibilité d’avoir une destination par défaut
en fonction du contexte
Soit par des paramètres tels le type de sortie (pré-visualisation, Imprimante, Message, Fichier,
Imprimante/fichier)
Imprimante (sélection par une fenêtre Windows), Serveur pour une impression via un serveur
d’impression
Les caractéristiques d’impression (Orientation, copies, bornes de pages… La langue est saisie pour
les états multilingues)
Remarque :
Les valeurs par défaut proposées pour les paramètres viennent de l’état, mais peuvent aussi venir du
contexte de lancement (cf. plus loin)
Lorsque les destinations sont répertoriées (cf. plus loin), la valeur par défaut proposée pour la
destination peut être définie en fonction du contexte
Le choix Imprimante / Fichier permet de créer un fichier d’extension .prn (en général très
volumineux) qui stocke le résultat tel qu’il aurait été envoyé à l’imprimante.

Sage ERP X3
6.3.1. Lancement d’un état : cinématique
A partir d’une fonction X3 on détermine le code état après une première étape qui utilise la notion de
code interne d’un état. Cette notion permet de regrouper plusieurs codes état du dictionnaire sous un
même code
Par exemple l’impression de la fiche d’un bon de livraison offre en standard les choix suivants
L’utilisateur après la sélection d’un code état dans la liste se retrouve dans le contexte du lancement
de l’état sélectionné. Si le code impression ne propose qu’une seule solution, l’utilisateur se retrouve
sur la fiche de lancement de l’état.
Rappel :
Les affectations d’états réalisées par Fichier / Impression et Fichier / Liste sont paramétrables
(Paramètres / Paramètres généraux / Personnalisation objets)
6.3.2. Résultat de l’édition sous Crystal Reports
Lorsque l’impression est lancée en mode local, l’icône signale que l’édition est en cours.
Lors d’une prévisualisation, une fenêtre Crystal s’ouvre.

Sage ERP X3
Il est alors possible :

Visualiser les pages au fur et à mesure
Parcourir des groupes de données sur le volet de gauche (selon les ruptures de l’état)
Envoyer le résultat dans un message
Exporter dans un fichier (formats PDF, HTML, Excel, Word…)
Rediriger le résultat vers une imprimante
6.3.3. Mémorisation des paramètres

La plupart des états disposent d’un grand nombre de paramètres. Ainsi, par exemple, l’état Grand-
livre comptable peut être édité en fonction de la combinaison de multiples critères de sélection
(écritures lettrées, non lettrées, de simulation…), tri variable, bornes (sites/sociétés, dates, comptes),
des paramètres complémentaires (devise d’impression, détail des à-nouveaux), des cumuls
optionnels…
Pour cette raison, il est intéressant de disposer d’un couple « code état » et « paramètres » que l’on
obtient grâce au « mémo ».
6.3.4. Surveillance de l’impression
Un double clic sur l’icône animée permet d’ouvrir la fenêtre suivante :

Sage ERP X3
Cette fenêtre permet de visualiser les impressions en cours sur les différents serveurs d’édition, de les
réordonner, voir de les supprimer.
6.4. AFFECTATION DES CODES INTERNES A DES ETATS

Paramétrage > Destination > Codes impressions
Trois cas sont possibles :

1. Le code interne pointe sur plusieurs états du dictionnaire. Un choix sera proposé à l’utilisateur,
exemple BONLIV.
2. Le code interne pointe sur un état unique, Pas de choix pour l’utilisateur. Exemple
BOREMTRR
3. Dans la fiche de la fonction d’appel on définit directement le code de l’état et nom le code
impression.
Remarque :
La table des codes impression est du paramétrage, dans la mesure où :

Les affectations relatives à des états spécifiques (dont le code commence par X,Y ou Z) ne sont pas
touchées par une mise à jour
Lorsqu’aucune règle d’affectation n’existe pour un état standard donné, on crée les règles
d’affectation si elles sont livrées dans une version mineure. Sinon, on respecte les règles d’affectation
existantes.

Sage ERP X3
6.5. VALEURS PAR DEFAUT DES PARAMETRES D’ETATS

Cette fonction permet de paramétrer la façon dans le contexte d’appel, d’alimenter les valeurs des
paramètres d’impression. Par impression il faut entendre l'impression d'un état Crystal Reports, le
lancement d'une requête, d'une requête SQL, ou d'un export.
Paramétrage > Destinations > Valeurs par défaut
Pour paramétrer correctement des règles d’alimentation des valeurs paramètre d’un état, il faut se
mettre dans le contexte de la fonction et vérifier le contenu des classes [M] . Celles-ci correspondent
au contenu des onglets qui composent la fenêtre à partir de laquelle la demande d’impression sera
activée.
Des constantes et des variables globales peuvent êtres utilisées dans ce contexte.
L’appel du code état alimente la colonne Paramètres.

Sage ERP X3
6.6. GESTION DES DESTINATIONS D’IMPRESSION

Cette fonction permet de définir les codes destination avec les valeurs des paramètres à utiliser pour
produire les impressions.
Paramétrage > Destinations > Destinations
Le progiciel permet d'envoyer un état vers un ensemble de destinations, en particulier vers toute
imprimante Windows(TM) visible sur le réseau du poste client, mais aussi vers des fichiers ou d'autres
destinations. Afin de faciliter le choix et l'affectation des destinations par défaut, il est possible - et
recommandé - de centraliser la description de ces destinations accessibles globalement dans cette
table.
On retrouve dans cette table les destinations, identifiées par un code, avec des caractéristiques
permettant d'en sophistiquer le processus de choix et d'affectation par défaut, et aussi de définir si un
serveur d'édition Crystal Reports est utilisé plutôt qu'une utilisation de Crystal Reports(TM) en local.
La table des destinations permet de définir des destinations de sortie d’états:

- supposées partageables entre les utilisateurs (chemin réseau accessible)
- avec un type discriminant vis à vis des états
- utilisables comme valeur par défaut
Elle n’empêche pas l’utilisation, au lancement de l’état, d’une imprimante non répertoriée par le choix
classique d’une imprimante sous Windows TM
Code d’accès : S’il est renseigné, l’utilisateur doit avoir les droits d’exécution pour utiliser
l’imprimante
Serveur : Si on passe par un serveur d’impression
Type d’imprimante : Menu local 22 (intitulés modifiables) Le premier type est un type par défaut
Format export Lorsque la sortie se fait sur fichier, il existe différents formats possibles que
l'on peut sélectionner ici. Cette liste de formats dépend de la version courante
de Crystal Reports, elle est susceptible d'évoluer dans le temps.

Sage ERP X3
Serveur On peut définir le serveur d'impression à partir duquel sera imprimé l'état. Si
cette zone est vide, l'impression sera réalisée localement sur le poste client.
Imprimante Le nom d'imprimante défini ici sera proposé à l'impression de l'état. Il doit
correspondre au chemin réseau de l'imprimante, tel qu'il est défini dans le
panneau de configuration Windows.
Type Ce champ permet d'affecter un type à la destination. Ce type, défini par le

menu local 22, possède les caractéristiques suivantes :
- le premier est un type passe-partout (tout état est susceptible d'être envoyé à des destinations
de ce type).
- les autres types permettent d'établir des catégories particulières (imprimantes code-barres,
fax, etc.) qui ne peuvent être utilisées que par certains états. En effet, dans le dictionnaire des
états, il est possible de définir un type de sortie dédié à un état en utilisant le même menu
local. Là encore, si ce type n'est pas le premier, il doit y avoir correspondance entre le type
affecté à l'état et le type de la destination utilisée.
Nombre de copies Permet, lorsque la sortie se fait sur imprimante, de donner une valeur par
défaut au nombre de copies à réaliser.
Copies assemblées Si plusieurs copies sont demandées, et si la case est cochée, on assemble
les pages avant d'éditer l'exemplaire suivant. Sinon, on répète chaque page.
Par exemple, dans le cas d'une impression de 3 pages en deux exemplaires :
- si la case est cochée, on obtient l'ordre des pages 1, 2, 3, 1, 2, 3
- si la case n'est pas cochée, on obtient l'ordre des pages 1, 1, 2, 2, 3, 3
6.6.1. Gestion des destinations par utilisateur

Lorsqu'un utilisateur lance un état, des règles d'affectation permettent de définir la destination de
sortie proposée par défaut. Ces règles peuvent être plus ou moins globales, mais elles peuvent être
définies de façon très fine, en allant jusqu'au niveau de détail constitué par le triplet (code état, code
utilisateur, plus un code complémentaire).
La table des destinations par utilisateur définit les règles les plus fines d'affectation de destination par
défaut. Les règles définies pour un utilisateur peuvent être utilisées par d'autres utilisateurs. En effet,
un utilisateur peut être considéré comme utilisateur modèle du point de vue de l'affectation des états :
un code utilisateur servant à définir les destinations par défaut existe à cette fin sur la fiche utilisateur
(rubrique Destinations utilisateur).
Paramétrage > Destinations > Destinations par utilisateur
Remarque :
Le premier type de destination désigne des destinations « passe-partout » utilisables pour tous les
états même si ceux-ci exigent un type d’imprimante particulier.

Sage ERP X3
Même si dans la plupart cas la notion de destination peut être associée à une imprimante physique,
elle permet plus généralement d’envoyer un message, de créer un fichier, ou de pré-visualiser
uniquement à l’écran.
6.6.2. Affectation des destinations
Les règles données ici permettent, lorsqu’on lance un état, de proposer une imprimante par défaut à
l’utilisateur. Dans tous les cas le type défini sur la fiche de l’état est respecté.
Si l’imprimante est protégée par un code d’accès, l’utilisateur doit avoir les droits d’exécution sur cette
imprimante (sinon, on recherche une autre imprimante par l’algorithme).
Si la règle finalement utilisée porte une information Obligatoire (oui/non) et si sa valeur est Oui,
l’utilisateur ne pourra pas la modifier. Dans tous les autres cas, ce n’est qu’une valeur par défaut.
Les priorités d’affectation sont les suivantes :

La table des imprimantes par utilisateur est la plus prioritaire. Elle est explorée en premier pour la
bonne valeur du complément évalué s’il existe, et à défaut avec un complément vide.
Si rien n’est trouvé, on prend l’imprimante par défaut définie sur l’état.
Si l’on ne trouve pas d’imprimante par défaut , on prendra l’imprimante par défaut de l’utilisateur
Il existe un niveau 4 de priorité non présenté ci-dessus : ce sont les variables PRT1, PRT2, PRT3,
PRT4… associées au site de l’utilisateur, pour le module dont dépend l’état
Si rien n’est trouvé :
- la première imprimante du bon type en mode batch est sélectionnée,
- la première imprimante de type pré-visu en mode interactif
La formule de complément est une expression pouvant faire appel à toute variable disponible dans
l’environnement, y compris les valeurs de paramètres sous la forme PARAM(NOM_PARAMETRE).
Par exemple, PARAM(SOCIETE)
Si l’imprimante est modifiable, et si l’utilisateur supprime le code imprimante, il se retrouve en choix
d’imprimante Windows. Ceci suppose que le paramètre utilisateur WINIMP soit égal à Oui (sinon, ceci
n’est pas possible).

Sage ERP X3
6.7. SERVEURS D’EDITION

Les serveurs d’éditions correspondent à des serveurs accessibles par le réseau sur lequel un run-time
d’impression AdxSrvImp.exe et Crystal Reports ont été installés
Les serveurs d’éditions sont définis par le biais de la console de configuration.
Le serveur d’impression est normalement exécuté sous la forme d’un service Windows. Il permet
- De gérer une file d’attente des demandes d’impression déposées par les fonctions X3
- De lancer plusieurs Editions Crystal Report en parallèle
L’utilisation d’un serveur d’impression est nécessaire dans les cas suivants :
- Editions lancées par un processus batch
- Editions lourdes risquant de monopoliser les ressources du poste client dans le cas d’une
exécution interactive
6.7.1. Fenêtre de surveillance X3

Pour afficher cette fenêtre, il faut se connecter avec un client lourd ou un navigateur Internet à un
dossier Sage X3, et ouvrir la fonction « Impressions/Surveillance Impressions ».
Une fois dans cette fonction, il suffit de renseigner le nom réseau du serveur d’édition qu’on souhaite
surveiller (serveur:port), et les données relatives à ce serveur s’affichent automatiquement dans la
fenêtre.
Depuis cette fenêtre il est possible :

- de visualiser les paramètres de démarrage du serveur (bloc Configuration)
- de visualiser les sessions TCP/IP courantes (bloc Clients connectés)
- de visualiser et éventuellement modifier les paramètres associés aux demandes empilées ou
en cours d’exécution (bloc Tâche).

Sage ERP X3
6.8.1. Tables associées
APRINTER [AIM] Définition des destinations

AREPORT [ARP] Dictionnaire des Etats
AREPORTD [ARD] Paramètres des états
AREPORTS [ARO] Etats - Sources de données
AREPORTV [ARV] Valeurs des paramètres d’impressions
AREPORTX [ARX] Définition des codes impression
APRINTDES [AID] Description imprimantes
APRTAUS [AIA] Destinations par utilisateur
AREPORTM [ARM] Table de travail standard pour les éditions
6.8.2. Points d’entré
Traitement Point d’entré Objet

AIMP1 FIN Le point d’entrée FIN permet d’enchaîner plusieurs éditions en
positionnant les variables GPE et ETAT. Le contenu de la table AREPORT
est significatif.
## Exemple d'utilisation du point d'entrée du traitement AIMP1
$ACTION
Case ACTION
When "FIN" : Gosub FIN
Endcase
Return
$FIN
If [F:ARP]RPTCOD="ETAT1" : # ETAT1 on enchaîne sur ETAT2
GPE = 1
ETAT = "ETAT2"
Endif
Return
AIMP3 IMPRIME Ce point d’entrée est appelé juste avant le choix de l’imprimante. La seule
chose qu’il est possible de faire est de positionner la variable GPE qui, si
elle différente de 0, inhibe la saisie de l’imprimante.
AIMP3 PARAM Permet de modifier la valeur d’un paramètre de l'état
AIMP3 REPORT Le point d’entrée permet de lancer un traitement après l'impression
de l’état. Ce point d'entrée est exécuté juste après l'ordre
d'impression envoyé au client (ou au serveur). Dans le cas d'une
impression/fichier, il peut servir à lancer un traitement sur le fichier
généré.
Dans un contexte batch il permet de récupérer le n° de la
demande d‘impression envoyée au serveur d’édition.
6.8.3. Le principe des es fichiers « reportjobstatus »

Lors du lancement d’une demande d’édition à Crystal Report par l’instruction X3 Report, une variable
numérique contient en retour de cette instruction un numéro de séquence. Ce numéro correspond au
rang de la demande renvoyée par le serveur d’impression X3 AdxSrvImp.exe

Sage ERP X3
Lorsque l’édition est terminée (Le processus Crystal Report s’est arrêter) un fichier séquentiel est créé
dans le répertoire ..\Temp du serveur d’impression.
Ce fichier est nommé reportjobstatus.nnnn, avec nnnn=numéro de séquence reçu en retour de

l’instruction Report.
Si Crystal Report à terminé l’édition sans erreur ce fichier est vide, sinon il contient le(s) code(s)
Erreur(s) généré(s) par le moteur Crystal Report.

Sage ERP X3
6.9. ANALYSE DES PERFORMANCES DES EDITIONS CRYSTAL REPORT

La production des états Crystal Report peut être longue et consommatrice de ressources. Ce
paragraphe rappelle les points à contrôler si dans une configuration Sage X3 on observe ce type de
problème.
6.9.1.1. Mise en œuvre des statistiques :

Que ce soit avec une base Oracle ou SQL Server, la mise en place des statistiques sur les accès aux
données est un pré requis. Il faut vérifier que ces statistiques sont calculées à une fréquence
régulière. Le paramétrage à effectuer sur la base de données est vu lors de l’installation et expliqué
dans le cours « installation »
6.9.1.2. Analyse du serveur d’impression

Que ce soit directement à partir du moteur d’impression du poste client AdxImp.exe ou à partir d’un
serveur d’impression AdxSrvImp.exe ce sont les même composants Crystal Report qui sont activés
pour produire les éditions.
En standard le serveur d’impression est déclaré sous la forme d’un service Windows. Celui-ci peut
être désactivé et relancé en mode trace pour analyser les points de contentions. Pour cela il faut
saisir le paramètre de démarrage /d
Ainsi configurer le serveur d’impression produit une trace dans le répertoire Windows nommée
AdxSrvImp_Trace.Log.
Cette trace contient entre autre :

- La version du serveur
Sage ERP X3
- Adonix® Edition Server full Path : e:\adonix\v140\AdxImp\AdxSrvImp.exe

- File Version : 14i.006
- Les paramètres reçus par le serveur pour exécuter l’édition

_ExportFile= e:\temp\DICOX3.pdf
_FormatExport= 29
__REPORT= DICOX3.rpt
__DESTINATION= 3
__TYPDBA= 1
__DBDATABASE= X3V14
__DBUSER= FIATIHF
__DBPASSWORD=***
__WSTATION= DEMOADONIX
__CDUSER= RLV
__ADXSOL= X3V140
__APPLICATION= FIATIHF;AS504P.sagefr.adinternal.com;1840
__APPRPT= X3;AS504P.sagefr.adinternal.com;1840
__RPTLAN= FRA
X3DOS= FIATIHF;AS504P.sagefr.adinternal.com;1840;140;FRA
__REQUETE= 37315
_PreVisuOptions=11111111111111111111
X3CLI= For programmer's usage
X3EDT= Etat Adonix Copyright Adonix
X3ETA= DICOX3
X3TIT= Dictionnaire des tables
X3OPE= Raymond LE VAN
X3USR= RLV
X3LAN= FRA
X3SIT1= *
X3SIT2= z
codficdeb= ATABLE
codficfin= ATABLE
impselection= 0
trizones= 0
tousmod= 1
module= 1
Les dates Heures démarrage et de fin du processus Crystal d’édition

- [12/20 13:48:24:277] Activation Impression pour le JobId : 1 [1180-DICOX3.rpt-
FIATIHF;AS504P.sagefr.adinternal.com;1840]
- Ouverture rapport jobId 1 [1180-DICOX3.rpt-FIATIHF;AS504P.sagefr.adinternal.com;1840]
OK.
- Définition des options d'export.
- Soumission du job 1 au Print Engine - [Start : 12/20 13:48:28:984]
- Le job d'impression 1 est terminé - fermeture du Print Engine - [Stop : 12/20 13:48:32:95]
- [12/20 13:48:32:189] L'impression du JobId 1 [1180-DICOX3.rpt-
FIATIHF;AS504P.sagefr.adinternal.com;1840] est terminée

Sage ERP X3
7. EPURATION ET HISTORISATION
7.1. PRINCIPES DE BASE

Les fonctions d'épuration ou d’historisation traitent les données :
- De type mouvement uniquement (on n’épure ou on n’archive pas les clients ou les articles,
mais les factures, les commandes, les écritures)
- Définies sous la forme de groupes de tables liées.
- Satisfaisant certaines conditions de cohérence (formules d'épuration) fournies en standard
mais modifiables en spécifique.
- Ayant atteint ou dépassé une période de conservation prédéfinie (paramètres d'épuration et
d’archivage).
Les fonctions d’historisation supposent la création d’un dossier dans lequel les données archivées
vont être stockées et se définissent par groupe de tables.
L’historisation transfère définitivement les données archivables (i.e. répondant aux critères), datées de
plus de N1 jours ou mois, dans le dossier archive.
L’épuration épure définitivement les données non archivables, datées de plus de N’1 jours ou mois, et
les données archivées datées de plus de N2 jours ou mois.

Sage ERP X3
Une sauvegarde est indispensable, car ces opérations sont irréversibles et l’épuration conduit à une
suppression de données.
Le paramétrage des règles d'épuration permet de définir les durées de vie à partir desquelles des
mouvements peuvent être épurés ou archivés, en suivant des règles de cohérence par groupes de
table définis par ailleurs.
L'archivage se fait par transfert des données d'une table du dossier vers une table de même structure
(à deux champs près, CREHISDAT et CREHISUSR, qui permettent de connaître les dates et
opérateurs ayant historisé la donnée). Cette table est définie dans un dossier dédié, qui utilise par
ailleurs le dossier courant comme dossier mère, et dont la création est faite automatiquement lors du
premier archivage.
L'intérêt de cette façon de faire réside dans le fait que les fonctions de consultation sur les données de
l'historique fonctionnent alors par simple connexion sur ce dossier, de la même façon qu'elles
fonctionnent sur le dossier en cours.

Sage ERP X3
7.2. CREATION D’UN DOSSIER D’HISTORISATION

Les progiciels Sage sont susceptibles de gérer, par le biais de fonctions d'épuration / archivage, le
transfert vers des archives ou la purge de mouvements qui n'évoluent plus, et qui sont considérés
comme suffisamment anciens pour ne plus être consultés fréquemment.
Développement > Utilitaire > Dossiers > Création dossier historisé
Un dossier historisé est un dossier particulier, associé au dossier d’exploitation, qui se définit par :
- Un nom (HDOSSIER par défaut).
- Des paramètres de taille globale.
- Des paramètres base de données.
- Un coefficient exprimant la taille des tables historisées par rapport aux tailles des tables
d’origine.
- Un profil menu, donnant accès à des fonctions de consultation, qui sera le profil par défaut
quand on entrera dans ce dossier.
Remarque :
Il est en général intéressant de définir ce dossier historisé sur d’autres volumes disques, pour des
raisons de performance.
Il peut même être intéressant de l’installer sur un autre serveur, pourvu que Sage X3 ait été installé
sur le serveur en question. Il est à noter que la création d’un dossier historisé sur un autre serveur
n’est pas automatisée, mais il est parfaitement possible, une fois que ce dossier est créé avec des
tailles qui peuvent être minimales, de le déplacer sur un autre serveur.
Pour que ceci fonctionne ensuite, il faudra :
- Modifier le paramètre HISDOS et y mettre le chemin d’accès au dossier avec la syntaxe
serveur@DOSSIER
- Modifier le cas échéant le paramètre HISCOE (coefficient d’augmentation de tables)
Il est à noter qu’à partir du moment où les tables d’un groupe sont déclarées historisées, le traitement
d’historisation va les créer, les dimensionnant en appliquant à la table d’origine le coefficient

Sage ERP X3
multiplicateur défini à la création et stocké dans HISCOE. Ce paramètre ne sert donc que s’il n’y a pas
encore eu d’historisation.

Sage ERP X3
7.3. DEFINITION DES REGLES D’EPURATION ET D’HISTORISATION

Ces règles sont fournies en standard dans le progiciel, leur modification relève de développement
spécifique.
Développement > Dictionnaire données > Ouverture au paramétrage > Historisation / Epuration
On associe à un code :
- Un groupe de tables liées
- Des informations de sélection
- Société
- Site
- Date de référence
- Des formules qui doivent être vérifiées pour que l’épuration soit possible
Un traitement de contrôle standard, personnalisable par un traitement spécifique complémentaire
Remarque :
Dans cet exemple, la date de référence utilisée pour savoir quels contrats d’achat peuvent être épurés
est la date DAT (date de calcul de la statistique). Ainsi, on épurera les contrats datés de plus de N
jours.
Tables mises en œuvre
Nom de la table Abréviation Contenu

AHISTO AHI Règles d’historisation et d’épuration
AHISTOD AHD Formules d’épuration

Sage ERP X3
7.4. PARAMETRES D’EPURATION / HISTORISATION

On définit, pour chaque groupe de données :
- Si on épure et/ou si on historise
- La durée minimale (en jours) de conservation des données
- La fréquence de lancement pour le groupe (i.e. le nombre minimum de jours à attendre depuis
la dernière épuration ou historisation)
- La date de lancement de la dernière opération est affichée
Paramétrage > Exploitation > Données > Paramètres épurations
Remarque :
Selon l’opération d’épuration ou d’historisation envisagée, les dates peuvent être ramenées à des
périodes ou à des exercices.

Sage ERP X3
7.5. EXECUTION DE L’HISTORISATION / EPURATION

Cette fonction peut être lancée en direct et en batch (tâche AHISTO).
Exploitation > Historique / Epuration
Les paramètres à saisir sont :

- Le groupe de tables concerné
- L’opération désirée (historisation, épuration, ou les deux)
- Une sélection société
- Un flag simulation (seule une trace de ce qui serait traité est alors créée)
- Un flag détail (s’il est actif, la liste détaillé des clés des lignes purgées est écrite dans la trace
Remarque :
Selon l’opération d’épuration ou d’historisation envisagée, les dates peuvent être ramenées à des
périodes ou à des exercices.
IL EST IMPORTANT DE FAIRE DES SAUVEGARDES AVANT DE LANCER CETTE FONCTION

Sage ERP X3
7.6. VISUALISATION DES DONNEES HISTORISEES

La visualisation se fait en se connectant sur le dossier historisé.
Les données accessibles sont :
- Les données historisées sur les tables historisées (les données non historisées ne sont pas visibles)
- Les données présentes dans le dossier d’exploitation sur toutes les tables non historisées (par
héritage)
Remarque :
On ne sait par réunir les données archivées et les données d’exploitation; par contre, on peut utiliser,
dans le dossier archive, potentiellement toutes les fonctions de gestion de X3, automatiquement
bridées en consultation.
Une contrainte existante est que les données archivées doivent avoir la même structure que les
données en cours d’exploitation; ceci signifie que le passage d’un patch induisant des modifications
de données provoque les modifications sur les tables du dossier archive.
Enfin, les états standards Crystal Reports ne gèrent que les données issues d’un seul dossier. Il faut
donc créer des états spécifiques si on désire éditer des données qui sont issues à la fois de tables
présentes dans le dossier d’archive et le dossier courant.

Sage ERP X3
8. LE WORKFLOW MANUEL
8.1. INTRODUCTION
Les mécanismes de gestion des processus Workflow ont été complètement réécrits. Ils permettent de
gérer un ensemble d’événements déclenchants plus important, et les règles d’affectation sont plus
riches.
Les principales évolutions portent sur :

- La saisie du paramétrage du texte des messages au kilomètre.
- La gestion des signatures répond à un plan prédéfini qui peut être à plusieurs niveaux.
- La gestion des destinataires peut être externe au paramétrage des règles de Workflow et
permet la gestion des absences.
- Des Workflow peuvent être exploités par des processus batch.
- Le Workflow peut être couplé avec les fonctions d’audit des tables.
- L’intégration dans le mécanisme de Workflow de processus pré-paramétrés (actions).
Des actions simples de gestion des réponses au message envoyé à l’utilisateur peuvent être
exécutées au travers du serveur http déclaré dans la solution Sage X3.
Des actions de type traitement peuvent être ajoutées au processus de Workflow lors de la génération
du message ou lors du processus de signature.
Pour assurer la compatibilité avec les versions antérieures du mécanisme de gestion des signatures
des demandes d’achat (DA) et des commandes, les fonctions de paramétrage de ces objets reste
disponible.
- Paramétrage des signatures
- Règles de signatures
- Rectification des signatures
Ces fonctions ne sont à utiliser que pour gérer les signatures des commandes et des demandes
d’achat.
8.1.1. Principes de base du Workflow V5 et supérieur

Le Workflow Sage X3 est composé des éléments suivants :
- Production des messages ou notification
- Gestion des actions de retour paramétrées dans le message via une connexion X3 Cette
gestion est réservée au mode client serveur.
- Gestion des actions de signature à partir du message reçu via une réponse simple de type
Oui/Non.
- Gestion de traitements annexes (action X3) pendant le processus de Workflow ou de
signature. Le Workflow permet de définir l’exécution d’un certain nombre d’actions lorsque des
évènements paramétrés sont réalisés dans le contexte Sage X3. Ces actions peuvent être :
- L’envoi d’un message via la messagerie de l’entreprise
- La gestion de notifications dans des plans de travail
- La mise à jours de données par l’exécution de traitements Sage X3 soit immédiatement
lorsque l’événement se produit soit postérieurement lorsque le(s) destinataire(s) des
messages réagiront.
- Gestion du suivi des évènements de Workflow et des signatures (Plan de travail)

Sage ERP X3
L’envoi des messages est conditionné par l’utilisation d’une messagerie acceptant l’interface MAPI
lors de l’envoi par le client Sage X3 ou SMTP POP3 lors de l’envoi par le serveur X3.
Dans le cas ou le processus de Workflow inclus une action de retour ou de signature, les destinataires
sont nécessairement des utilisateurs X3.
La gestion des actions de signature passe par un serveur http qui active un processus batch
permettant la mise à jour des tables.
8.1.2. Les paramètres superviseur
Les processus de Workflow utilisent les paramètres superviseur du groupe WRK suivants:
TYPMES : Envoi des messages via les postes clients ou le serveur de traitement.
SERMES : Nom du serveur de messagerie ou adresse IP de ce serveur. Ce paramètre est obligatoire

si la valeur du paramètre TYPMES est égale à Serveur.
WRKDAY : Nombre de jours permettant de définir la fenêtre de consultation des notifications dans un
plan de travail.
Exemples
- valeur 0 : date début = date fin = date$
- valeur 5 : date début = dates$ - 5 jours ; date fin = date$
Il existe d’autres paramètres superviseur définis pour la gestion des liens de workflow (cf. chapitre
dédié) qui peuvent être associés à des codes activité associés
8.1.2.1. Fonctionnel
AUDIT : Ce code permet de rendre optionnel la gestion de l'audit des modifications sur les tables de
la base. Cette fonction, définie via l'onglet Audit du dictionnaire des tables, permet de tracer, par des
triggers de base de données générés automatiquement, les insertions, suppressions, et modifications
faites sur une table, en stockant si nécessaire des valeurs avant et après sur des champs particuliers.
Pour mettre en place un Workflow manuel sur les évolutions des données d’une table, il faut rendre
actif ce code activité.
8.1.2.2. Dimensionnement
AWR : Ce code permet de définir le nombre maximum de signataires qu'il est possible de déclarer
dans une règle d'affectation. Ce nombre ne doit pas être supérieur à 10.
8.1.2.3. Les tables dédiées au Workflow
Table Abréviation
Désignation
AWRKLNK [AWM] Modèles de données
AWRKPAR [AWA] Règles de Workflow (définition)
AWRKPARC [AWC] Règles de Workflow (actions)
AWRKPARF [AWF] Règles de Workflow (signature)
AWRKPARH [AWH] Règles de Workflow (destinataire)

Sage ERP X3
AWRKPARX [AWX] Règles de Workflow simplifiées (notifications)

AWRKREG [AWR] Règles d'affectation des destinataires
AWRKREGVAL [AWV] Affectation des utilisateurs
AWRKTRN [AWW] Plan de travail workflow
AWRKTRND [AWD] Plan de travail workflow
AWRKUSR [AWU] Utilisateurs délégués
AWRKHISDES [AWO] Historique des Workflow (destinataires)
AWRKHISJOI [AWJ] Historique des Workflow (pièces jointes)
AWRKHISMES [AWG] Historique des Workflow (messages)
AWRKHISSUI [AWS] Historique de suivi des évènements de Workflow
8.1.2.4. Différences avec le Workflow V140

On ne gère plus les boucles locales sur les tableaux. La variable de boucle entre double parenthèses.
Pour contourner ce point, il faut utiliser les modèles de données en-tête ligne. Il n’y a pas
d’automatisme de reprise de ce type de paramétrage.
On ne dispose plus des 5 couples natures/information dans le moniteur Workflow. Pour contourner ce
point, il faut utiliser les variables de contexte. Ces variables peuvent être utilisées dans les données
affichées des plans de travail et comme critère de sélection des évènements de Workflow. Il n’y a pas
d’automatisme de reprise de ce type de paramétrage.

Sage ERP X3
8.2. LES MODELES DE DONNEES
Afin de disposer d’un ensemble d’informations cohérentes pour construire un processus de Workflow,
une fonction permet de définir un modèle de données. Celui-ci est constitué d’un ensemble de tables
qui seront ouvertes lors du déclenchement du Workflow avec la définition des liens entre ces tables.
Cette fonction permet de définir un groupe de tables liées soit directement, soit en cascade, par des
liens de type (1,1) ou (1,N) à une table principale supposée être en ligne.
Un tel modèle de données peut être utilisé :

- dans une règle de Workflow, soit parce que c'est le seul contexte disponible pour décrire les
tables à parcourir (cas d'une règle de type Manuel, où le modèle est obligatoire), soit pour
enrichir le contexte de déclenchement (cas des autres types).
- dans une règle d'affectation, où le modèle est obligatoire. Il définit le groupe de tables dans
lequel se trouvent les champs utilisés par la règle d'affectation des utilisateurs. Le modèle de
données associé à une règle de Workflow et celui associé à la règle d'affectation sont
obligatoirement identiques.
Développement > Dictionnaire données > Ouverture que paramétrage > Modèles de données
Le champ Code modèle est l’identifiant du modèle de données.
Le champ Intitulé est un libellé documentaire associé au code modèle.
Le champ Actif permet d'activer ou de désactiver la fiche courante sans pour autant perdre son
contenu. Une fiche désactivée ne peut pas être utilisée (par appel de son code) dans d'autres fiches
(documents, paramétrages...), ou lors de traitements de masse.
Le champ Module définit le module X3 d'appartenance du modèle.
Le champ Code activité permet de protéger le modèle décrit. En effet cette notion de modèle est
considérée comme une fonction de développement.

Sage ERP X3
Il est fortement conseillé de créer un code activité dédié et d’affecter celui-ci sur tous les modèles de
données qui seront créés dans un dossier afin de ne pas perdre le paramétrage de ces modèles lors
de la revalidation du dossier.
Le champ Table principale identifie la table principale à partir de laquelle on lit d'autres tables par des
liens directs ou en cascade. Cette table est supposée être en ligne si le modèle est utilisé dans une
règle Workflow de type différent de Manuel. Dans le cas d'un Workflow de type Manuel, elle fait partie
de la jointure qui est ouverte et parcourue à l'exécution du Workflow.
Bloc Liens
Pour chaque table dépendante de la table principale devant être ouverte dans le contexte du
Workflow, une ligne doit être déclarée.
Le champ Table liée contient le code de la table liée. Le nombre de tables liées est limité à 30.
Le champ Abrév correspond à l'abréviation sous laquelle la table liée sera ouverte. Si ce champ n'est
pas saisi, on utilise l'abréviation par défaut de la table.
Le champ Table origine contient le code de la table à l'origine du lien décrit dans la ligne courante.
Ce peut être le code de la table principale ou celui d’une des tables déclarées dans des lignes
précédentes.
Le champ Clé de lien définit le code de la clé de la table utilisée pour réaliser la lecture des lignes
liées. Par défaut, la première clé de la table est utilisée.
Le champ Type de lien indique la cardinalité du lien. Il prend l'une des deux valeurs suivantes :
1,1 : signifie que pour chaque ligne de la table d'origine, une seule ligne de la table liée est lue.
1,n : dans ce cas, plusieurs lignes de la table liée peuvent être lues. Elles sont définies par
l'expression de clé, qui peut être incomplète si elle est en plusieurs parties (les lignes dont les
éléments de clés renseignés correspondent à la valeur donnée sont parcourues).
Le champ Expression de lien contient les éléments constitutifs de la clef de lecture. Il est défini
comme une ou plusieurs expressions calculées séparées par un point-virgule. Chaque expression est
évaluée, et le résultat permet de connaître la valeur de la clé utilisée pour réaliser la jointure. Lorsque
les jointures multiples sont autorisées, on peut ne donner que les premiers éléments de la clé.
Dans les expressions, on peut utiliser des constantes, et des champs issus des tables précédemment
définies dans la liste des liens.
Le Champ société contient le code du champ à utiliser pour déterminer le code de la société lors de
l’exécution du Workflow. La valeur de ce champ permet de déterminer la règle d'affectation à utiliser.
Le Champ site contient le code du champ à utiliser pour déterminer le code du site l’exécution du
Workflow. Il permet d'en déduire la société courante, si celle-ci n'est pas définie par le champ société.
Les tables suivantes sont mises en œuvre par la fonction :
Table Abréviation Intitulé Table

ATABIND [ATI] Dictionnaire des index
ATABLE [ATB] Dictionnaire des tables
ATABZON [ATZ] Dictionnaire des champs
ATEXTRA [AXX] Textes à traduire
AWRKLNK [AWM] Modèles de données
AWRKPAR [AWA] Règles de Workflow
AWRKREG [AWR] Règles d'affectation

Sage ERP X3

Sage ERP X3
8.3. PARAMETRAGE DES REGLES DE WORKFLOW

Les Workflow sont gérées par des transactions de paramétrage permettant de définir :
- Les règles de déclenchement du processus de Workflow,
- Les règles de définition des destinataires des messages générés,
- Les règles de génération des textes des messages,
- Les règles de suivi des évènements de Workflow (signatures),
- Les actions à exécuter au déclenchement du Workflow ou pendant le processus de signature.
8.3.1. Evènement déclenchant
Paramétrage > Workflow > Règles workflow
Cet onglet permet de définir les conditions de déclenchement du processus de Workflow. Ces
conditions sont identifiées par un type et un code événement. Les valeurs du champ type
d’événement sont déclarées dans le menu local 988.
Le champ type d’évènement est l’attribut principal d’identification du processus de Workflow qui sera
exécuté. Les autres paramètres sont dépendants de cette valeur.
Nu Code Message Code évènement

1 D Divers Voir le menu local 908
2 O Objet Code de l’objet sur lequel l’événement est réalisé
3 E Entrée fonction Code de la fonction
4 R Edition Code de l’état déclaré dans le dictionnaire des états
5 F Fin de tâche Code de la tâche batch
6 A Arrêt de tâche Code de la tâche batch
8 I Import/export Code du modèle d’import / export
Code de l’événement à l’origine de l’action de signature.
9 S Signature Si non renseigné l’événement est générique.
10 M Manuel Sans objet
L’événement Objet regroupe les boutons et les opérations réalisées sur l’objet.
L’événement Signature correspond à l’action de signature d’un utilisateur sur un Workflow précédent.
Le contexte de l’événement de Workflow d’origine est alors en ligne.

Sage ERP X3
L’événement Manuel est lié à un Workflow déclenché manuellement par un utilisateur ou par un
processus batch. Ce type d’événement peut être utilisé pour gérer les audits paramétrés sur les tables
X3.
Un code événement : La valeur de ce champ est dépendante du type d’événement. Il est utilisé
comme critère dans les transactions de consultation des évènements de Workflow.
Pour les évènements de type divers, le menu local 908 contient les évènements autorisés. Cette table
ne doit pas être personnalisée
Code Intitulé Observations

BUT Bouton Workflow Permet de gérer l’action Fichier / Envoyer vers…
CAN Annulation Annulation de signature, permet à un utilisateur de

revenir sur sa décision.
CON Connexion Connexion d’un utilisateur
COV Couverture commerciale Fonctionnel X3 entreprise
CSD Flux trésorerie - échéances Fonctionnel X3 entreprise
CSL Export balance consolidation Fonctionnel X3 entreprise
CSP Flux trésorerie - règlements Fonctionnel X3 entreprise
DEC Déconnexion Déconnexion d’un utilisateur
KIL Arrêt processus Arrêt d’un processus Sage X3
MSG Retour Workflow Workflow
PBI
PWD Mot de passe Remise à zéro du mot de passe d’un utilisateur
Si le paramètre superviseur SUP/PASSWD égal à Oui :
Un mot de passe temporaire est attribué
Si l’événement Workflow existe, il est temporairement
stocké dans la variable GMESSAGE et peut être envoyé à
l’utilisateur par mail (sinon il est affiché)
TIM Time-out Time-out

TO1 Crédit de jetons (Clients) Jetons
TO2 Crédit de jetons (Commandes) Jetons
TO3 Crédit de jetons (Factures) Jetons
TRA Trace Gestion des Trace
Un code opération qui n’est significatif que pour les Workflow de type Objet, Signature et
Import/Export, il permet de préciser de manière plus fine les conditions de déclenchement du
Workflow. Les valeurs autorisées sont dépendantes du contexte.
Exemple sur l’objet commande

Sage ERP X3
A ces attributs de déclenchement sont rattachés des informations complémentaires permettant de

préciser :
Le modèle de données : Permet de définir un ensemble cohérent de tables qui sont utilisées dans le
contexte d’exécution du Workflow. Cette notion de modèle est rendue nécessaire pour gérer des
règles complexes de signature et pour produire des textes de messages complets.
Cette notion de modèle est obligatoire pour les Workflow de type Manuel, car il permet de définir la
requête à exécuter pour réaliser l’action de Workflow. Voir le chapitre concernant le paramétrage d’un
modèle de données.
L’indicateur de fin de transaction : Utilisé pour un Workflow de type objet, pour préciser quand le
Workflow sera déclenché. Pendant ou après la transaction de mise à jour des tables liées à l’objet.
Le code Règle d’affectation : Ce code permet de ne pas gérer de destinataires en dur au niveau de
la règle de Workflow. Il permet de définir une table de ligne multi critères qui renvoie une ou plusieurs
valeurs. Cette règle d’affectation renvoie dans une variable dimensionnée [L]USER(1..N) la liste des
destinataires. Ces destinataires sont de type utilisateurs X3. Le nombre maximum de signataires est
définit par la variable de dimensionnement AWR qui est initialisée à 6 et dont le maximum est de 10.
Le type de Workflow : Cette information permet de préciser lorsque le Workflow est lié à un modèle
de type entête / lignes, le niveau pour lequel il sera déclenché.
Le code de la Table Ligne : Cette information est à renseigner si et seulement si le Workflow est
déclenché sur une table de lignes détail (Ligne des factures liées à un règlement par exemple).
Le critère de regroupement des lignes : Cette zone permet de définir une règle de regroupement afin
de ne générer qu’un seul événement de Workflow par rupture sur ce critère. Ce critère est une
expression séparée par des points virgules.
8.3.1.1. Le bloc Conditions

Le champ Type est modifiable si l'événement de Workflow est de type Ligne, les conditions peuvent
porter soit sur l'en-tête, soit sur la ligne. Sinon les conditions seront appliquées sur l’en-tête.

Sage ERP X3
Le champ Conditions permet d’exprimer des conditions complémentaires sous la forme

d'expressions logiques (Formule de calcul) incluant des variables en ligne au moment de l'exécution
de la règle (contenus de masques d'écrans ou de tables en ligne, selon la description du contexte...).
Si ces conditions sont toutes vraies, le message sera envoyé et/ou la trace écrite dans le fichier log.
Lorsque le contexte est de type en-tête et lignes, on peut filtrer une partie des lignes reliées à un en-
tête en définissant des conditions s’appliquant sur les lignes. S'il reste au moins une ligne concernée
et que les conditions de l'en-tête sont vraies, le déclenchement sera réalisé.
Si plusieurs lignes de conditions sont paramétrées, c’est l’ensemble de ces conditions qui détermine
le déclenchement de l’événement.
8.3.1.2. Le bloc Gestion

Activation mail : Un message est généré et envoyé aux destinataires renseignés dans l’onglet
destinataires.
Activation suivi : Une notification est gérée dans le plan de travail et les circuits de signature
associés sont activés.
Activation action : Ce témoin permet de prendre en compte les actions déclarées dans l’onglet
action.
Mise au point : L’affichage du message au déclenchement du Workflow pour contrôle et mise au

point. C’est le mode test.
8.3.2. 0nglet destinataire

Si les messages sont destinés à des destinataires qui sont aussi des acteurs de l’application
(utilisateurs Sage X3), alors dans une règle de Workflow les destinataires peuvent être :
- soit déclarés explicitement dans la règle de Workflow,
- soit déterminés à l’aide d’une règle d’affectation.
Le champ Condition permet d’exprimer une règle pour que le message soit envoyé au(x)
destinataire(s) déclaré(s) dans la ligne.
La notation not[L]COND(1) permet de définir la condition inverse de la ligne renseignée sous forme
d’indice (valeur 1 dans l’exemple).
La notation [L]NBUSR=0 correspond à une règle d’affectation qui ne renvoie aucun destinataire et
permet de définir un destinataire par défaut.
Le champ Type permet de préciser si le destinataire est un utilisateur Sage X3 défini dans la table
AUTILIS ou un tiers défini dans la table BPARTNER. Il est nécessaire que l’adresse mail soit
paramétrée sur la fiche correspondante du destinataire.

Sage ERP X3
Le champ Destinataires contient soit une formule évaluée lors de la construction du message, soit
une adresse de messagerie. Si le type de destinataire est un utilisateur X3, le code du destinataire
sera soit définit par une formule évaluée lors de la construction du message (exemple [V]GUSER),
soit définit à l’aide d’une règle d’affectation. Dans ce dernier cas, c’est le tableau [L]USER qui contient
les codes des destinataires.
Le champ Fonction permet pour les destinataires qui sont des tiers, de filtrer dans la liste des
contacts liés au code tiers, ceux dont la fonction correspond à la valeur saisie. Dans la fiche contact
l’attribut fonction est défini par une valeur du menu local 233. Si, dans cet écran, la valeur du champ
«Fonction » n’est pas renseignée, tous les contacts déclarés dans la fiche tiers et ayant une adresse
mail renseignée recevront le message.
Le champ Envoi mail permet de préciser si les destinataires déclarés dans la ligne recevront:
- Non : Aucun message,
- Oui : Un message à chaque destinataire,
- Copie : Une copie du message.
Le champ Suivi précise si les destinataires de la ligne vont recevoir une notification dans leur plan de
travail, selon la valeur saisie :
- Non : dans ce cas, aucune notification ne sera disponible dans le plan de travail.
- Oui : une notification leur sera envoyée, elle pourra être simplement visée, pour
signaler que l'utilisateur l'a lue.
- Avec signature : cette notification devra être signée par un des destinataires de la ligne.
Le champ Nature permet de définir un critère de regroupement dans les fonctions de suivi.
Le champ Option délégué permet de préciser la façon dont est géré le fait que l’absence du
destinataire identifié dans la ligne. Cette absence est gérée par l’intermédiaire de la transaction
« Utilisateurs délégués » présentée dans un chapitre spécifique.
- Non, seul le destinataire d’origine recevra le message.
- Tous, le destinataire et tous les utilisateurs définis comme délégués du destinataire recevront
le message.
- Cascade, le destinataire, ses délégués, les délégués de ses délégués, etc. recevront le
message.
- Premier libre, le premier destinataire présent recevra le message.
8.3.3. Onglet Message

Cet onglet permet de définir les règles de génération du texte des messages.

Sage ERP X3
Le champ Objet : permet de définir le contenu du champ Objet du message envoyé, sous la forme
d'une expression calculée qui est évaluée au moment du déclenchement de l'événement. Comme par
exemple :
"La tâche"+[F:ABR]TACHE+" est terminée"
Le champ Texte permet de définir le contenu principal du message. Son écriture se fait sous la forme
de texte libre incluant des expressions logiques (Formule de calcul) entre deux barres verticales qui
tiennent lieu de séparateur. Ainsi, par exemple, on pourra écrire des contenus tels que :
|"Il y a eu des erreurs"|

|"en nombre"-num$(GERRTRACE)|
|[F:ABR]TACHE|
|"Message d'erreur" +-GMESSBATCH|
Le texte des messages peut contenir des libellés issus de la table des textes ATEXTE. Ces textes
sont alors déclarés avec l’instruction mess.
Exemple
############################
| mess(00306,00183,1)+":"- [F:PIH]NUM |
| mess(00017,00007,1)+":"- [F:PIH]BPRPAY |
| mess(00425,00183,1)+":"- format$('N:9.2',[F:PIH]AMTATI) -[F:PIH]CUR |
| mess(00048,00110,1)+":"- format$('N9.2',[M]CUMLINAMT2) -[V]GLOCALDEV |
| mess(00021,00129,1)+": 1"-[V]GLOCALDEV+"="+format$("N7.5", [F:TCH]CHGRAT)-
[F:PIH]CUR |
A la saisie, ces textes sont visualisés par l’utilisation d’un clic droit avec l’option affichage des
messages
###############################

Sage ERP X3
| Numéro de facture:- [F:PIH]NUM |

| Fournisseur:- [F:PIH]BPRPAY |
| Montant facturé:- format$('N:9.2',[F:PIH]AMTATI)-[F:PIH]CUR |
| Montant devise locale:- format$('N9.2',[M]CUMLINAMT2)-[V]GLOCALDEV |
| Cours devise:- "1"-[V]GLOCALDEV +"="+format$("N07.5",[F:TCH]CHGRAT)-[F:PIH]CUR |
De même la description des tables est accessible par l’utilisation d’un clic droit avec l’option assistant
de formule.
Nota : Dans le cas où le texte du message contiendrait du texte issu de la table ATEXTE, le texte
envoyé est dans la langue de l’émetteur.
Dans le corps du message, on peut insérer des données issues de la table des lignes détails, si le
modèle de données ou l’objet gère des lignes détails. Pour définir l’emplacement dans le corps du
message où doivent être insérées les données extraites des lignes détails on utilise la codification
|LIG|. Dans ce cas, le champ suivant doit être renseigné.
Le champ Ligne permet lorsque l’événement est de type ligne d’insérer dans le corps du message
des informations issues des lignes détails. Ces informations sont exprimées sous la forme d’une
formule qui est évaluée lors du déclenchement de l’événement
Exemple historique des connexions

Texte :
|mess(13,154,1)|
============================================
|LIG|
Ligne :
format$("K:10X",[AES]ESP1)-format$(GFMDAT,[AES]ESPDAT)-[AES]ESPTIM
Définition des arguments d’une signature
Les balises SIG permettent de définir les réponses attendues

Une réponse est identifiée par la balise SIG et un mot clef VAL ou REJ qui doit être en
correspondance avec les réponses définies la colonne réponse de l’onglet suivi
###############################
# |SIG/VAL/"Pour valider, cliquez sur :"|
# |SIG/REJ/"Pour refuser, cliquez sur :"|
###############################
Ces réponses seront transformées dans le message par un lien http vers le serveur WEB habilité à
gérer ces réponses.
###############################
# Pour valider, cliquez sur : http://action.jsp?C=0700000398-
OK&K=zt4ddjr5Ud&L=FRA&D=DIAMONDTESTV5
# Pour refuser, cliquez sur : http://action.jsp?C=0700000398-
KO&K=zt4ddjr5Ud&L=FRA&D=DIAMONDTESTV5
###############################
Les réponses autorisées sont déclarées dans la table diverse 54

Sage ERP X3
8.3.3.1. Bloc gestion
Le champ Envoi permet de préciser si l'envoi doit être fait localement par le poste client, depuis le
serveur de traitement, ou indifféremment depuis l'un ou l'autre. Dans le cas des événements liés à un
processus batch, c’est le serveur de traitement qui est à activer.
Le champ Icône de retour permet d’insérer sous la forme d’une pièce jointe, une icône permettant
d’accéder à Sage X3 sur la fiche à l’aide d’un double clic. Cette gestion d’un accès X3 via cette icône
est réservée au mode client Serveur.
Le champ Fonction de retour est à utiliser si le champ Icône de retour est actif et si le retour doit être
effectué sur une fonction différente de celle ayant déclenché l’événement.
En Workflow objet, dans le cas de la création ou de la modification d'une fiche, ceci permet, plutôt que
de se connecter sur la fiche par défaut, d'aller sur une fiche liée (la fiche de l'utilisateur ayant créé ou
modifié l'information qui a déclenché le Workflow, par exemple).
Dans le cas du Workflow Manuel, si l’icône de retour est actif, le code de la fonction de retour est
obligatoire.
Le champ Retour Menu permet de préciser si le retour de Workflow est limité à la fonction définie
(lorsqu'on la quitte, la fenêtre se ferme) ou si on revient au menu en sortant de la fonction appelée.
Le champ Clé de lien permet de définir la clef d’accès à la fiche qui sera visualisée via l’icône de
retour.
Le champ Message modifiable permet dans le cadre d’un Workflow interactif de rendre le message
généré modifiable par l’utilisateur ayant déclenché l’événement.
Le champ Accusé de lecture permet s’il est actif d’envoyer le message avec une demande d’accusé
de réception. Cette gestion d’un accusé de réception ne fonctionne que pour les messages envoyés
via le poste client (Interface MAPI).
Le champ Groupage par destinataire permet si un événement de Workflow crée plusieurs

notifications, de regrouper les messages créés par l'événement.
Il y a plusieurs notifications si le Workflow est de type Ligne ou s'il s'agit de l'évènement spécial ANU
déclenché lors de l'annulation d’une signature.
Les notifications sont regroupées entre elles, si elles ont les caractéristiques suivantes en commun :
- l'émetteur
- le type de serveur
- le contexte de retour
- l'objet du message
- l'accusé de réception
- les destinataires
- le flag signataire
Voir l’exemple de Workflow Escalade par défaut.
8.3.3.2. Bloc Pièces jointes
Il est nécessaire que le paramètre général TYPMES soit égal à Serveur pour que des pièces jointes
puissent être envoyées. Si ce n'est pas le cas, seule la première pièce jointe est envoyée (ceci est
signalé par un message d'avertissement lorsqu'on impose un envoi par Client).

Sage ERP X3
Par ailleurs, les pièces jointes doivent être accessibles depuis le serveur d'application par un chemin
réseau si elles ne sont pas stockées dans la base X3.
Fichier Trace lié : Cette case ne peut être cochée que si l'événement déclenchant correspond à la fin
d'une tâche batch. Dans ce cas, si elle est cochée, le fichier trace associé à la tâche batch va être
joint au message envoyé.
Pièce à joindre : Ce champ permet d'associer une pièce jointe au message, en donnant un chemin
d'accès réseau sous la forme d'une expression calculée qui sera évaluée au moment du
déclenchement de l'événement.

Sage ERP X3
Pièce jointe : Quand cette case est cochée, sur un Workflow de type objet, les pièces jointes à la
fiche peuvent être envoyées en pièces jointes du message. (Exemple pièce jointe de l’entête et du
pied des factures)
Tous types : Ce champ permet d'envoyer toutes les pièces jointes à la fiche.
Type pièce jointe : Ce champ permet de préciser le type des pièces jointes à sélectionner si le
champ précédent Tous type n’est pas actif.
Toutes catégories : Cette case n'est saisie que pour un Workflow de type objet pour lequel la case
Pièce jointe est cochée. Si cette case est cochée, toutes les catégories de pièces jointes à la fiche
déclenchant le Workflow sont envoyées comme des documents joints au message. Sinon, on doit
saisir la catégorie concernée.
Catégorie : Ce champ permet, lorsque des documents joints à une fiche doivent être envoyés en
pièce jointe au message, de filtrer ces documents en fonction de leur catégorie définie par le menu
local 96.
- Confidentiel
- Interne
- Externe 1
- Externe 2

Sage ERP X3
8.3.4. Le suivi des signatures

Cet onglet permet de définir la façon dont les notifications de type Suivi sont faites dans les plans de
travail des utilisateurs destinataires, et également les conditions de signature associées, s'il y en a.
Ces conditions de signature ne sont applicables que si dans le tableau des destinataires, ces
destinataires sont suivis Avec signature.
On définit alors, sous la forme d'expressions évaluées, le message à faire apparaître dans le plan de
travail, et la date limite attendue de signature si une signature est attendue.
On trouve ensuite un tableau permettant de préciser les réponses que l'utilisateur pourra faire lors de
sa signature, avec la possibilité de mettre directement à jour un champ de la fiche courante lorsque le
Workflow est de type Objet.
Il est à noter que les éléments évalués dans le tableau des réponses le sont au moment de la
signature, alors que les éléments relatifs à la notification ou au message associé le sont au moment
du déclenchement du Workflow d'origine. Ceci signifie que le contexte n'est plus exactement le même.
Ainsi, dans un contexte Workflow de type objet

lors du déclenchement, on dispose de l'ensemble des variables des écrans et des tables liées à
l'objet, ainsi que les tables complémentaires liées à un modèle de données et à une règle d'affectation
éventuelle et les variables globales liées au contexte du signataire. Par exemple GUSER
représente le code de l'utilisateur ayant déclenché l'événement.
lors de la signature, on a en ligne l'enregistrement de la table principale de l'objet, ainsi que les tables
décrites dans un modèle de données et une règle d'affectation éventuelles, mais on ne dispose plus
des écrans en ligne, et les variables globales sont celles du contexte de la signature. Dans
notre exemple GUSER représente alors le code de l'utilisateur qui signe le document.
Pour permettre de transmettre des valeurs du contexte de déclenchement vers le contexte de

signature, on dispose d'un tableau nommé Contexte. Les expressions qui y sont décrites sont
évaluées et transmises au moment de la signature sous la forme d'un tableau de variables locales
nommées [L]CTX. Ces variables peuvent alors être utilisées dans le paramétrage des plans de travail,
dans les conditions et valeurs liées à la signature, et également dans les valeurs et variables liées aux
Actions de l'onglet suivant, lorsqu'il s'agit d'actions déclenchées lors de la signature.
8.3.5. Onglet Suivi

Sage ERP X3
Les réponses sont déclarées dans la table diverse 54. Elles doivent au minimum contenir celles
déclarées dans les balises SIG du message.
8.3.5.1. Bloc Signature
Texte suivi Ce champ contient une expression évaluée au moment du déclenchement du

Workflow. Le résultat de cette évaluation est une chaîne alphanumérique stockée dans la table de
suivi des évènements Workflow AWRKHISSUI.
C'est cette valeur qui est normalement présentée dans le moniteur Workflow pour qualifier
l'événement à signer.
Signature Si cette case est cochée, le suivi donne lieu à un processus de signature : on retrouve
alors, dans le tableau situé en bas de l'écran, un certain nombre de choix de signature possibles.
Date limite Dès lors que la case Signature est cochée, il est possible de définir une expression de
type date définissant la date au-delà de laquelle on considère qu'il y a retard si la signature n'a pas été
faite.
La valeur du champ correspondant est stockée dans la table de suivi des évènements Workflow
AWRKHISSUI (Champ DATREL).
Ce champ peut être exploité dans le moniteur Workflow, pour définir un ordre de classement. Mais il
peut aussi être exploité pour une gestion de relance des événements en attente de signature, sachant
que le champ [AWS]NBREL permet de compter les relances éventuelles faites.

Sage ERP X3
8.3.5.2. Bloc Contexte
Ce tableau contient des expressions évaluées au moment du déclenchement d'un Workflow. Ces
variables sont stockées dans l'historique des Workflow (variables VALCTX1 à VALCTX15).
Elles sont utilisables dans le contexte de la signature (tableau de variables CTX(1) à CTX(15))
associé à l'événement originel, ou à un événement de Workflow consécutif à la signature.
L'intérêt de ces variables est qu'elles permettent de transmettre des informations qui ne sont pas
situées dans les tables à l'origine du contexte déclencheur, et donc qui ne sont pas transmises
automatiquement d'un événement à la signature ou à l'événement suivant.
En effet, les tables de l'objet ou celles de la règle d'affectation sont transmises automatiquement. Par
contre, ne sont pas transmises
- les variables globales comme GUSER, GFONCTION, GABREV, CLEOBJ, qui définissent
respectivement l'utilisateur courant, la fonction courante, le code de l'objet, et la clé
courante au moment du déclenchement d'un Workflow objet.
- les variables liées aux écrans.
- les variables issues des expressions telles que date$, time$... qui qualifient le contexte du
déclenchement.
C'est donc pour ces variables qu'il est intéressant de paramétrer un contexte pour les transmettre de
l’événement déclenchant à celui de la signature. Les variables transmissent via ce contexte sont
exploitables par le moniteur de Workflow.
8.3.5.3. Bloc Réponse
Ce bloc permet de définir les réponses possibles, à choisir par le destinataire. On déclare une ligne
par réponse autorisée.
Le champ Réponse définit un choix possible pour le récepteur du message. Les choix autorisés sont
déclarés dans la table diverse numéro 54, qui définit des choix possibles à la signature.
Dans le plan de travail des signatures, un clic droit sur la ligne à signer permettra de proposer parmi la
liste des choix issus de cette liste, ceux pour lesquels la condition est vérifiée.
Le champ Opération est le code qualifiant la signature réalisée. Il correspond au code opération
utilisé dans un événement de type Signature consécutif à l'événement signé.
Il est à noter que plusieurs lignes peuvent porter le même code opération. Les valeurs autorisées sont
déclarées dans la table diverse numéro 55.
Ce code n'est pas stocké dans l'historique des Workflow à l'issue de la signature. C'est en effet la
valeur du champ Réponse, qui n'admet pas d'homonymes entre les différentes lignes, qui est stocké.
Le champ Condition contient une expression logique évaluée au moment de la signature. Si la

condition est réalisée, alors la réponse définie sur la ligne, est proposée parmi les choix possibles.
Ceci permet, par exemple, de disposer de plusieurs niveaux de signature, en fonction du nombre de
signataires ayant déjà signé (seul le dernier signataire ayant accès à une signature qui déclenche une
mise à jour finale). De même, il est possible de définir un choix apparemment impossible (par une
condition toujours fausse de type 1=0). Ce choix pourra être forcé par une action de signature
déclenchée par un autre événement de Workflow. C'est ainsi que sont traités, dans des paramétrages
standards, des escalades dans les processus de signature.
Motif : Permet de prévoir une saisie d’un motif lors de la signature de la règle.
Ce champ permet de préciser le numéro d’une table diverse où sont gérés les motifs des réponses.
La table historique AWRKHISSUI stocke le numéro de la table diverse, le code saisi, et son intitulé.

Sage ERP X3
La zone Champ mis à jour définit le nom d'un champ qui sera mis à jour par le processus de
signature. Ce champ est issu d'une des tables du contexte déclencheur.
La valeur de ce champ après la mise à jour sera celle calculée à partir de l'expression définie dans le
champ Valeur, lors du processus de signature. Ainsi on peut, par exemple, mettre à jour un champ tel
que ENAFLG (indicateur Actif) de l'objet courant lors d'un processus de signature.
Le champ Valeur définit l’expression d'une valeur calculée au moment de la signature. La valeur
correspondant à la ligne de réponse choisie sera utilisée, en cas de signature :
- soit pour mettre à jour le champ défini dans la colonne précédente.
- soit lors du déclenchement d'éventuelles actions définies dans l'onglet Action. Dans ce cas,
on retrouve cette valeur dans la variable alphanumérique [L]RESULT.
Le champ Modifiable permet de modifier la valeur renvoyée par l’expression calculée définie dans le
champ valeur, si cet indicateur est actif. La valeur résultant de la saisie sera utilisée pour réaliser la
mise à jour s'il y en a une, et transmise à la variable [L]RESULT pour exploitation par une action
complémentaire.
8.3.6. Onglet action

Cet onglet décrit une liste d'actions qui peuvent être déclenchées soit lors du déclenchement de
l'événement, soit lors de la phase de signature.
Il permet d'exécuter soit des actions standards prédéfinies à cette fin, soit des actions spécifiques.
Chaque action paramétrée n'est appelée que si la condition d'exécution est réalisée. A chaque action
est associée la liste des paramètres de l'action, afin de permettre de saisir la liste d'expressions
évaluées dans le contexte et transmises au traitement de gestion de l’action.

Sage ERP X3
8.3.6.1. Bloc action

Le champ Code action contient un code action X3 dont l'exécution peut être déclenchée si les
conditions sont remplies.
Au niveau du dictionnaire des actions, la case Workflow doit être active. Ce type d’action ne doit pas
interagir avec l'interface utilisateur. Du point de vue technique, le traitement ne doit pas avoir de
fenêtre associée. Les actions destinées au mécanisme de Workflow sont donc de type Traitement
divers.
Le champ Déclenchement définit les conditions de déclenchement de l’action.

Les conditions autorisées sont déclarées dans le menu local 2923.
Les valeurs suivantes sont utilisables :
Début Workflow : l'action est déclenchée en début de constitution du texte du message. Lorsque le
Workflow est de type ligne, elle n'est exécutée qu'une fois par en-tête, avant la constitution du texte
d'en-tête. Les variables retournées par l'action peuvent être utilisées dans le texte du mail, mais pas
pour définir les destinataires ou les conditions de l'envoi, qui sont déjà évalués à ce stade.
Fin Workflow : l'action est déclenchée après l'envoi du message. Lorsque le Workflow est de type
ligne, cette action n'est exécutée qu'une fois par groupe de lignes.
Avant Ligne : l'action est déclenchée avant la lecture de la première ligne, lorsqu'on a un Workflow de
type en-tête et lignes. Ceci permet par exemple d'initialiser des variables de cumul pour obtenir un
total des lignes, le cumul étant réalisé dans une action ligne.
Ligne : l'action est déclenchée juste avant la constitution de chaque ligne de message, dans le cas
d'un Workflow de type ligne. Les variables retournées par l'action peuvent donc être utilisées dans le
texte ligne.
Avant Groupe : l'action est déclenchée à la détection d’une rupture sur un groupe de lignes détails.
Signature : l'action est déclenchée après la saisie de la signature. La variable [L]RESULT issue de
cette saisie est donc connue, mais avant la mise à jour des tables. On peut modifier cette valeur
durant l'action. Dans le cas d'une signature, toutes les mises à jour sont réalisées dans une seule
transaction. Ainsi, si un rollback est réalisé dans une des actions déclenchées par l'événement, on
revient à la situation de départ pour toutes les mises à jour effectuées.
Dans le cas général, du point de vue transactionnel, il faut noter que l'action fait partie de la
transaction de Workflow du message, si un rollback est fait lors de la constitution du message, les
mises à jour faites dans l'action ne seront pas réalisées.
Dans le cas particulier du Workflow sur un objet, tout est fait dans une seule transaction. Autrement
dit, si la création ou la modification d'une fiche échoue, un Rollback est fait sur l'ensemble des mises à
jour déclenchées par les actions.
Il en est de même pour le suivi : la transaction qui suit la saisie du suivi inclut le déclenchement des
actions.
Pour résumer les actions appelées par les fonctions de Workflow ne doivent pas ouvrir de transaction.
Le champ Condition d'exécution définit la condition de déclenchement de l’action. Cette condition

est une expression logique, évaluée dans le contexte de déclenchement de l'action. Si le résultat de
l'évaluation
- est vrai (non nul), l'action est déclenchée,
- est faux, l'action n'est pas déclenchée,
- si aucune expression n'est saisie, l'action est toujours déclenchée.

Sage ERP X3
8.3.6.2. Bloc Paramètres

Ce bloc contient pour chaque action déclarée dans le bloc action, la liste des paramètres héritée du
dictionnaire des actions X3.
Le champ Paramètre contient le code du paramètre

Le champ Type contient le format du paramètre
Le champ Retour définit le mode de transfert de la valeur du paramètre.
Le champ Valeur paramètre définit une expression évaluée qui est transmise comme argument à
l'action ou le code d'une variable qui contiendra une valeur de retour si l'argument est de type
Pointeur.
Toutes les variables du contexte de Workflow peuvent être utilisées dans l’expression qui sera
évaluée.
Exemple d’actions standards utilisables par le Workflow fournis par le progiciel :
AWRKUPDFLD Mise à jour de 1 à 4 champs dans l'enregistrement courant d'une table avec gestion
de transaction.
Cette action permet de mettre à jour les champs FLD1 à FLD4 de la table
d'abréviation ABREV avec les valeurs respectives VALEUR1 à VALEUR4.
Si une transaction est en cours, l'action fait partie de la transaction; sinon, une
transaction unitaire est réalisée pour l'opération.
La variable GOK globale est renseignée comme pour une transaction normale.
AWRKUPDOBJ Mise à jour de 1 à 4 champs dans l'enregistrement courant d'un objet avec gestion
d’un verrou objet.
Cette action permet de mettre à jour les champs FLD1 à FLD4 de la table liée à
l'objet OBJET avec les valeurs respectives VALEUR1 à VALEUR4 uniquement si
c'est objet n'est pas verrouillé sur la clé CLE.
La variable GOK est mise à 0 en cas d'erreur.
SIGWRK Signature automatique d'un événement de Workflow.

Cette action permet de déclencher la signature d'un événement de Workflow dont
l'identifiant (chrono) est connu.
Elle peut notamment être utilisée dans des actions de Workflow lancées en batch,
pour signer par défaut des événements en attente depuis trop longtemps
(procédures d'escalade).
Le code action passé en paramètre correspond à la signature faite par défaut sur
l'événement en question (ce peut être une signature par défaut, un refus par défaut,
voire une action spécifique d'escalade).
Paramètres de l'action
CHRONO Chrono Char
USER Code utilisateur Char
ACTION Action Char
Ces actions sont de type Superviseur, c'est-à-dire qu'elles sont génériques et ne concernent pas un
module particulier. D'autres actions liées à des modules fonctionnels existent également.

Sage ERP X3
8.4. LES REGLES D’AFFECTATION

Les règles d’affection consistent à réaliser un paramétrage permettant de parcourir un ensemble de
données issues des tables X3 afin de construire une liste d’utilisateurs destinataires des messages.
Ce paramétrage permet de ne pas figer les destinataires dans les règles de Workflow.
Les règles d’affectation sont paramétrées en deux étapes.

1. La première étape décrit les règles de parcours des tables et de constitution d’un tableau de
critères. Le résultat de l'évaluation des critères est stocké dans un tableau de variables
nommé [L]VALEXP, l'indice variant de 1 au nombre de colonnes de critères
2. La seconde permet d’affecter à chaque valeur du tableau de critère les destinataires du

message qui sera créé. La liste des utilisateurs ainsi constituée est mémorisée dans un
tableau de valeur nommé [L]USER. La dimension de ce tableau de valeur est dépendante du
code activité AWR.
Chaque liste de destinataires est déterminée par des critères dépendant du contexte. L'utilisateur
chargé de définir les circuits de signature pourra alors saisir les combinaisons de valeurs de critère et
leur affecter les destinataires correspondants.
Cette fonction de paramétrage permet de créer et de mettre à jour les règles d'affectation, en
définissant le nombre maximum de signataires que renvoient une règle, et les critères dont la
combinaison définit les signataires.
A l'exécution de la règle d'affectation :

- Les critères sont calculés par simple évaluation ou par agrégation sur un ensemble de lignes
par un opérateur tel que la somme, la moyenne, le minimum, le maximum... Chacun des
critères ainsi calculé est comparé à l’aide d’un opérateur aux valeurs saisies dans la règle.
- Ceci permet leur exploitation dans la suite de la règle de Workflow. Il est intéressant de noter
que certains critères, dont la valeur est intéressante pour la suite du processus de
Workflow, peuvent ne pas déterminer de destinataire. Dans ce cas, on leur associera
l'opérateur Indifférent.
En fonction de la combinaison obtenue, le tableau [L]USER est transmis et peut être utilisé par la
règle de Workflow.
8.4.1. Définition des règles d’affectation
Paramétrage > Workflow > Règle d’affectation utilisateur
Le champ Règle d'affectation définit de façon unique les fiches créées.
Le champ Société permet d'affecter une règle à une société particulière. Si ce code est non
renseigné, il est définit pour toutes les sociétés.
Le champ Intitulé est une désignation associée à la fiche.
Le champ Code d’accès permet d'interdire l'accès à la fiche courante pour certains utilisateurs.

Sage ERP X3
Le champ Modèle de données définit le modèle de données dont les tables sont accessibles lors de
l'évaluation de la règle d'affectation. Ce modèle est obligatoire. Le code de ce modèle doit être
identique à celui déclaré dans la règle de Workflow qui utilise la règle d'affectation.
Le champ Table ligne ne peut être saisi que si le modèle de données contient des tables de lignes
associées à un en-tête. Si on saisit alors une des tables lignes, c'est cette table qui sera parcourue
pour déterminer les destinataires du Workflow. Un Workflow utilisant la règle d'affectation
correspondante sera forcément de type Ligne.
Le champ Nb de signataires définit le nombre maximum d'utilisateurs que renvoie la règle dans le
tableau USER. L'écran généré par la validation de la règle contiendra, outre les colonnes de critères,
autant de colonnes Utilisateur que de valeurs renvoyées. Ce nombre peut être compris entre 1 et un
maximum défini par le code activité AWR.
8.4.1.1. Bloc des tables à analyser

Une règle d’affectation peut utiliser 10 champs maximum pour définir les critères qui permettront
d’affecter les destinataires d’un événement de Workflow.
Le champ Table à parcourir définit la table à utiliser pour l'évaluation du critère de la ligne. Si cette
table est liée avec un lien de type 1,n avec la table ligne de la règle (ou avec la table principale du
modèle en l'absence de table ligne), un opérateur de synthèse sera saisi pour définir comment les n
valeurs contenues dans les lignes seront agrégées.
Le champ Op. synthèse est saisi lorsque le champ utilisé comme critère se trouve dans une table liée
avec un lien 1,n à la table principale du modèle.
Dans ce cas, la valeur obtenue pour le critère correspond à l'agrégation d'un ensemble de lignes, et
l'opérateur saisi ici permet de préciser comment le calcul est effectué.
Les opérateurs d'agrégation Somme et Moyenne ne peuvent être utilisés que si le critère est
numérique. Les opérateurs Minimum et Maximum peuvent être utilisés dans tous les cas.
Le champ Critère contient une expression qui sera évaluée lors de l'exploitation des règles
d'affectation. La valeur résultante est comparée à la liste des valeurs saisies dans la règle afin de
déterminer quelle est l’utilisateur destinataire du message.
Le champ Opérateur sert à comparer la valeur du critère avec les champs saisis dans les valeurs de
règle. Outre les opérateurs d'égalité et d'inégalité classiques, on retrouve l'opérateur Comme, qui
permet de saisir des valeurs caractères avec des jokers, et l'opérateur Indifférent, qui signifie que la
valeur n'est pas utilisée comme critère d'affectation des utilisateurs, mais transmise à la règle de
Workflow appelante pour être utilisée par ailleurs.
Le champ Intitulé permet de donner un titre à la colonne de saisie du critère correspondant de la

règle d'exploitation. Elle est donc évaluée au moment de la saisie des valeurs de règle.
Si ce champ est vide, et si le critère est un champ extrait d'une des tables de la base, le titre repris est
automatiquement celui du dictionnaire (il est repris dans la langue de connexion de l'utilisateur).
Le champ Type de données définit le type de données associé à la saisie du critère. Lorsqu'un
champ extrait d'une des tables de la base est choisi comme critère, son type est proposé par défaut.
Le champ Longueur est à saisir si le type de données est une chaîne de caractères ou un nombre.
Le champ No menu local est à saisir si le type de données est un menu local.
Le champ Paramètre est à saisir si le champ associé au critère est contrôlé par une table ayant une
clé en plusieurs parties (par exemple, les tables diverses, les textes traduisibles), on saisit ici le
composant de clé complémentaire pour établir le lien avec la table.

Sage ERP X3
Le champ Lien est utilisé si le champ associé aux critères est contrôlé par une autre table. On peut
alors choisir l’intitulé associé à valeur saisie. Les choix possibles sont :
- Non pas d'affichage
- Long affichage de l'intitulé long
- Court affichage de l'intitulé court.
Le champ Valeur par défaut permet de saisir une expression qui est évaluée lors de l’affectation des
utilisateurs pour permettre de donner une valeur par défaut. Les données constituantes des règles
d’affectation sont mémorisées dans la table AWRREG.
Note :
La validation d’une règle d’affectation réinitialise les affectations des utilisateurs.

La validation d’une règle d’affection génère un traitement X3 nommé WMRXXXX avec XXXX=code de
la règle d’affectation.
8.4.2. Affectation des utilisateurs

Le paramétrage des règles d’affectation permet de générer des écrans de saisie ayant cette
ergonomie. La transaction générée permet de saisir pour chaque critère défini par la règle
d’affectation, les valeurs pouvant être renvoyées lors de l’exécution de la règle. Pour chaque valeur,
on doit définir les codes des utilisateurs devant recevoir la notification.
Le nombre de critères affiché dans le tableau est égal au nombre de lignes déclarées dans la règle
d’affectation et dont l’opérateur a une valeur autre que indifférent. Pour l’exemple ci dessus on a
déclaré au minimum P critères.
Le nombre d’utilisateurs par ligne est égal au nombre de signataires saisi dans la règle d’affectation.
8.4.2.1. Bloc Utilisateur par défaut

Ce bloc contient les codes des utilisateurs auxquels le message sera envoyé, si les critères ne
permettent pas définir un utilisateur. Le nombre d’utilisateurs par défaut est égal au nombre de
signataires déclarés dans la règle d’affectation.
8.4.2.2. Bloc Valeurs

Une ligne doit contenir les P valeurs des critères pouvant être renvoyées par la règle d’affectation
auxquels on associe les N utilisateurs.

Sage ERP X3
Les données saisies dans cette transaction sont mémorisées dans la table AWRREGVAL. Pour un
couple Règle d’affectation / Code société, on peut saisir un maximum de 99 affectations.
8.4.3. Utilisateurs délégués

Cette transaction permet de gérer pour une fourchette de dates et pour une nature d’événement ou
pour tous les événements des utilisateurs délégués qui recevront les messages. Le nombre de lignes
de délégations pour un utilisateur est limité à 99.
Paramétrage > Workflow > Utilisateurs délégués
Le champ Code utilisateur contient le code utilisateur X3 pour lequel des délégations sont
paramétrées.
Le champ Utilisateur délégué contient le code X3 des utilisateurs qui reçoivent une délégation.
Le champ Nature contient le code nature des Workflow pour lesquels une délégation est déclarée. Si
ce code est non renseigné, la délégation est effective pour tous les Workflow à destination de
l’utilisateur d’origine.
Le champ type de délégation décrit les droits associés à l’utilisateur délégué. :

Copie pour info : l'utilisateur recevra les notifications adressées à l'utilisateur principal, mais sans
pouvoir de signature.
Avec pouvoir : un délégué de ce type peut signer à la place de l'utilisateur principal. Il est à noter que
si plusieurs délégués de ce type existent, et si la règle prévoit d'envoyer une notification de Workflow
à tous les délégués, seul le premier ayant décidé de signer pourra le faire (les autres seront prévenus
que la notification a déjà été signée).
Exceptionnel : un délégué de ce type ne reçoit pas les notifications de l'utilisateur principal, mais il a
la possibilité d'afficher les notifications de l'utilisateur dont il est délégué en entrant dans le plan de
travail et en sélectionnant, le code de l'utilisateur principal. Il aura alors la possibilité de signer à sa
place. En général, un délégué exceptionnel est un supérieur hiérarchique qui a le droit d'aller
visualiser les éléments en attente chez ses subordonnés pour signer à leur place.
Les champs dates de début et fin de validité indiquent la période pour laquelle la règle de
délégation s’applique. S’ils sont non renseignés, la délégation est permanente.
Ces données sont mémorisées dans la table AWRKUSR.
Impact du champ Option délégué dans l’onglet Destinataires des règles de workflow
Pour chaque ligne de destinataire déclarée dans une règle de Workflow, l’attribut Option délégué
détermine le comportement du processus de Workflow pour définir les destinataires délégués.
Par exemple
Un message doit être envoyé à un utilisateur U001 dont les délégations sont les suivantes ;
Délégué de U001  U010 période 01/08/07 au 31/08/07

Sage ERP X3

Le message est envoyé le 10/08/07.
Ce champ peut avoir les valeurs suivantes
- Non, seul le destinataire d’origine recevra le message quelque soit les délégués affectés à ce
destinataire. Dans l’exemple ci-dessus, seul U001 reçoit le message.
- Tous, le destinataire et tous les utilisateurs définis comme délégués du destinataire recevront
le message. Dans l’exemple ci-dessus, U001 / U010 / U020 recevront le message.
- Cascade, le destinataire, ses délégués, les délégués de ses délégués, etc. recevront le
message. Dans l’exemple ci-dessus, U001 / U010 / U020 / U011 / U012 recevront le
message.
- Premier libre, le premier destinataire présent recevra le message. U001 et U010 recevront le
message.

Sage ERP X3
8.5. MONITEUR DE WORKFLOW & PLANS DE TRAVAIL

Les plans de travail sont des transactions de consultation et/ou de mise à jour des événements de
Workflow exploitées par le moniteur de Workflow.
Ces transactions permettent de mettre à disposition des utilisateurs des informations fonctionnelles
sur les évènements de Workflow. Par exemple, liste des commandes à valider triées par date de
commande, code fournisseur et numéro de commande.
La conception des plans de travail doit donc être analysée lors du paramétrage des règles de
Workflow. Dans l’exemple, il est nécessaire de prévoir la conservation dans les tables de suivi du
Workflow des données date de commande / code fournisseur et numéro de commande.
Les variables de contexte [L]CTX paramétrées dans la règle de Workflow sont prévues à cet effet.
Pour assurer la confidentialité, des codes d’accès peuvent être affectés à ces transactions.
8.5.1. Paramétrage des plans de travail

Le moteur de Workflow intégré au progiciel permet de paramétrer des notifications à des utilisateurs,
sous la forme d'une ligne contenant un ensemble d'informations relatives à l'événement d'origine.
Ces lignes peuvent être présentées dans un plan de travail paramétrable afin de :
- visualiser les informations qui ont été paramétrées pour apparaître dans le plan.
- réaliser un zoom vers un contexte d'origine, le cas échéant.
- viser des lignes qui ne demandent pas de processus de signature élaboré.
- signer (en exerçant un choix parmi un ensemble de réponses) lorsqu’un processus de
signature a été paramétré.
Le paramétrage d’un plan de travail génère des transactions de consultation et de mise à jour des
tables de suivi des évènements de Workflow. Ces transactions sont accessibles aux utilisateurs via
des fenêtres générées par la fonction de paramétrage et gérées par le moniteur de Workflow.
Paramétrage > Workflow > Paramétrage plan de travail

Sage ERP X3
L'écran de paramétrage est présenté sous la forme de 8 onglets identiques.
Le paramétrage consiste à définir le nombre d’onglets de chaque transaction et pour chaque onglet à
définir ses composants et ses caractéristiques.
Puis on décrit les conditions permettant de filtrer les lignes qui doivent apparaître sur l'onglet en cours
de paramétrage. Cela permet par exemple de répartir les lignes en fonction du sujet, de l'urgence, ou
de tout autre critère entre onglets. Puis les informations qui doivent être présentées, les champs
définissant l'ordre d'apparition, et des conditions de mise en relief de certaines lignes.
8.5.1.1. Entête
Le champ Code transaction identifie l'écran associé à la consultation ou à la saisie, c’est aussi ce
code qui est la clef de la transaction. A l'exécution des transactions et des consultations, la liste des
codes accessibles à l'utilisateur est présentée, si l'entrée dans une transaction par défaut n'est pas
forcée.
Le champ Intitulé est le libellé de la transaction, qui peut être décliné par langue, est affiché dans la
fenêtre de sélection de la transaction.
Le champ Code d'accès permet de définir des filtres pour limiter l’utilisation des transactions. Si ce
champ est renseigné, l'écran de consultation ou la transaction de saisie de mouvements sont
accessibles si l'utilisateur a les droits liés à ce code.
Par ailleurs, la modification (respectivement la visualisation) des caractéristiques de la transaction
n'est possible que si l'utilisateur courant a le droit de modification (respectivement de consultation) sur
le code.

Sage ERP X3
Le champ Nb d'onglets définit le nombre d'onglets présents dans le plan de travail.
Le champ Nb de lignes définit le nombre maximum de lignes affichées dans chaque onglet.
Pour chaque onglet de la transaction, on doit définir :
- Le champ Intitulé court définit l'intitulé de l'onglet tel qu'il apparaîtra sur le plan de travail.
- Le champ Titre est un libellé documentaire.
- Le champ Filtre contient une formule qui sera évaluée à l’exécution de la transaction ou de la
consultation pour filtrer les données présentées dans l’onglet. On peut ainsi ne présenter
qu'une partie des lignes à traiter en les répartissant sur chacun des onglets. Par exemple
o le premier onglet contient les éléments à signer [F:AWS]FLGSIG=3
o le second onglet contient ceux déjà signés [F:AWS]FLGSIG=5
8.5.1.2. Bloc colonnes

La zone Champ contient le code du champ issu de la table de suivi AWRKHISSUI. Le nombre
maximum de champs dans un onglet est limité à 70.
Le champ Ordre contient le rang du champ qui sera affiché dans l’onglet généré. Si ce rang est nul,
le champ ne sera pas présent dans l’onglet généré. Ces champs sont présents en mémoire mais pas
affichés.
Le champ Intitulé est affiché à titre documentaire. Sa valeur par défaut est issue du dictionnaire des
données, mais il est possible, par un clic droit, de modifier cette valeur. Cette option permet de
personnaliser les entêtes des colonnes affichées dans l’onglet. Elle est intéressante pour définir les
variables génériques qui dépendent du contexte comme VALCTX1.
Par clic droit sur le tableau, on dispose des choix suivants :

- Tous : Alimentation automatique de tous les rangs par incrément de 5.
- Aucun : Remet à zéro tous les rangs dans le tableau.
8.5.1.3. Bloc Styles

Ce tableau permet de mettre en valeur certaines lignes affichées dans l’onglet généré.
Le champ Style contient le code du style à utiliser. Ce sont les styles gérés par l’objet ASY qui sont
utilisés. Pour chaque onglet, le nombre maximum de styles est limité à 5.
Le champ Condition contient le critère permettant d’appliquer le style. Ces critères sont définis sous
forme d'expressions calculées, sont évalués pour chaque ligne du plan de travail. Si aucune condition
n'est vérifiée, la ligne reste dans la couleur par défaut.
8.5.1.4. Bloc Ordre de tri

Ce tableau permet de déclarer les champs utilisés pour définir l’ordre de présentation des données.
Le nombre maximum de champs déclaré pour définir cette clef de tri est limité à 3.
La zone Champ contient le code du champ à utiliser pour le tri. Les lignes du plan de travail sont
présentés triées selon la valeur des donnés affichées dans ce champ. A égalité sur un champ, on trie
selon les valeurs du champ suivant.
Le champ Sens définit si le tri se fait en ordre croissant ou décroissant des valeurs.

Sage ERP X3
Les attributs de tri définis dans ce bloc sont concaténés pour exprimer la valeur de l’instruction
ORDER BY exécutée lors de l’utilisation du plan de travail. La longueur totale de ces attributs ne doit
pas dépasser 100 caractères.
Le bouton validation permet la génération des onglets et de la fenêtre constituant la transaction de

gestion du plan de travail.
Les écrans générés ont pour code WMIxxxxxn

La fenêtre générée à pour code WMIxxxxx
Avec xxxxx= code de la transaction et n rang de l’écran dans la fenêtre.
8.5.1.5. Les champs du plan de travail

Ce tableau présente le contenu des champs de la table de suivi des évènements de Workflow
AWRKHISSUI à partir de laquelle les plans de travail sont paramétrés.
CHRONO Numéro chronologique attribué lorsqu'un Workflow est déclenché.

Dans le cas d'un Workflow manuel, un numéro est attribué pour chaque
enregistrement déclencheur.
Dans tous les autres cas, un seul numéro chronologique est attribué par
déclenchement.
Ainsi, lorsqu'une notification est envoyée à plusieurs utilisateurs à partir d'un même
événement, le numéro de chrono est identique et permet de retrouver tous les
destinataires de la notification.
DEST Contient le code du destinataire de la notification.

Si un visa ou une signature est attendue, c'est normalement lui qui effectue cette
opération.
Ce destinataire n'est pas forcément le destinataire qui était défini dans la règle
d'origine. En effet, si la règle prévoit une délégation au premier destinataire libre, et
que le destinataire de départ a défini un délégué avec pouvoir pour les dates
concernées, c'est le délégué qui est destinataire de la notification (ou son délégué
si lui-même a délégué...).
EMAIL Contient l’adresse Email du destinataire.
NUMGRP Ce numéro de chrono est attribué pour chaque ligne traitée. il y en a donc plusieurs
numéros lorsqu'on a des Workflow de type en-tête/ligne avec des regroupements.
CPY Lorsqu'un modèle de données est attaché à la règle, et que ce modèle définit une
société courante en fonction du contexte (directement ou par l'intermédiaire d'un
site), on stocke dans l'événement le code de la société correspondante.
Ce code société peut être utilisé pour définir dans la règle d'affectation les
destinataires de la notification.
DELEGUE Contient la valeur :

Non si l'utilisateur est le premier destinataire de la notification.
Oui si l'utilisateur reçoit la notification en tant que délégué non remplaçant (options
Tous ou Cascade), et que par ailleurs il a pouvoir de signer. S'il n'a pas de pouvoir
de signer, la notification n'apparaît pas dans le plan de travail.
Si la valeur de ce champ est Oui, au moins une autre ligne portant le même numéro
de chrono avec la valeur Non existe dans la table des données du plan de travail.
Si la notification à été envoyée à plusieurs délégués avec pouvoir de signature, on

Sage ERP X3
trouvera une ligne avec la valeur Oui avec le même numéro de chrono.
La première signature sur l'une des lignes concernées met automatiquement à jour
l'ensemble des lignes portant le même numéro de chrono en les considérants
comme signées.
ENVOI Ce champ a comme valeur Oui si un message a été envoyé lors de l'exécution de
la règle.
EMETTEUR Ce champ contient le code utilisateur émetteur de la notification.

Dans un Workflow de type Signature, l'émetteur est celui qui a signé la notification
précédente.
Dans les autres type de Workflow, l'émetteur est l'utilisateur dont l'action à l’origine
de l’envoi de la notification.
MAIENV Lorsqu'une ligne du plan de travail a été signée par le déclenchement d'un lien http
depuis un message, ce champ stocke l'adresse de messagerie de l'utilisateur ayant
signé de cette manière.
DATENV Ce champ contient la date de création de l’événement de Workflow, cette date

correspond à la date système issue du serveur de traitement.
TIMENV Ce champ contient l’heure de création de l’événement de Workflow. Elle

correspond à l'heure système calculée sur le serveur de traitement.
NATURE Ce champ contient la valeur du code Nature défini sur l'événement déclencheur.
C’est un critère important pour trier et sélectionner les lignes.
TEXSUI Ce champ contient le texte évalué à partir de la rubrique Texte suivi définie dans
l'onglet Suivi de la règle; usuellement un commentaire est paramétré expliquant les
circonstances du déclenchement de Workflow.
TYPEVT Ce champ contient le type d'événement de la règle de Workflow à l'origine de la

ligne de notification dans le plan de travail.
CODEVT Ce champ contient le code événement à l'origine du Workflow, c'est à dire le code:
de l'objet dans le cas d'un Workflow objet.
de l'état dans le cas d'un Workflow de type impression.
du modèle dans le cas d'un import ou d'un export.
de la fonction dans le cas d'une entrée sur fonction.
de la règle de Workflow ayant déclenché la demande de signature dans le cas
d'une signature.
du code identifiant un Workflow de type divers.
CODWRK Contient le code de la règle de Workflow.
OPERATION Contient le code de l’opération dans le contexte déclenchant:

pour un événement objet, ce peut être C (création), M (modification) ou le code du
bouton.
pour un événement signature, le code de la règle à l'origine de la signature
pour un import/export, les combinaisons I/E et D/F(import/export, début/fin), par
exemple ID.
pour une entrée sur une fonction, ce champ est vide.
pour une impression, il est égal à C.

Sage ERP X3
pour la fin d'une tâche batch, il vaut "0" si la tâche s'est terminée sans erreur; sinon,
on y trouve le numéro de statut suivi du début du message d'erreur.
DATMAXSIG Ce champ contient la date à laquelle le Workflow devra avoir été signé. Il contient la
date de déclenchement du Workflow si aucun processus de signature n'a été mis
en œuvre, ou si aucune date limite n'a été définie.
En effet, lorsque l'événement de Workflow suppose une signature, on peut gérer
une date limite de signature et ensuite déclencher des relances basées sur cette
date limite.
Ces relances se font par des règles de Workflow batch nommées WRKREM1,
WRKREM2, et WRKREM2E.
Lorsqu'une relance de ce type est faite :
le champ Nombre de relances, est incrémenté ce qui permet de savoir combien de
fois la signature a été relancée.
le champ Dernière date de relance, est modifié ce qui permet de connaître la date à
laquelle la dernière signature a eu lieu.
Si ces règles batch ne sont pas utilisées, et si aucune autre règle n'a été définie
pour mouvementer ces champs, le nombre de relance reste égal à 0 et la date de
relance reste vide, car aucun traitement standard du Workflow ne modifie cette
valeur
FLGSIG Ce champ définit le niveau de signature correspondant à la notification de la ligne.

Les valeurs suivantes, définies par le menu local 2922 sont possibles :
A lire (valeur 2) : un accusé de lecture est demandé, mais la notification n'a pas
encore été lue.
A signer (valeur 3) : une signature est demandée, mais la notification n'a pas
encore été signée.
Lu (valeur 4): un accusé de lecture a été demandé, il a été saisi.
Signé (valeur 5): une signature a été demandée, elle a été accordée.
Annulé (valeur 1): une signature a été accordée, puis elle a fait l'objet d'une
annulation de signature.
ACTSIG Ce champ est vide tant que l'événement n'a pas été signé. Si est signé, le champ
contient le code de la réponse qui a été saisi, tel qu'il est défini dans la table diverse
numéro 54.
USRSIG Lorsque la notification a été signée, ce champ contient le code de l'utilisateur qui a
signé. Il ne s'agit pas forcément du destinataire d'origine, puisqu'un autre utilisateur
peut avoir le pouvoir pour signer.
MAISIG Lorsqu'un message incluant une demande de suivi par activation d'un lien http a été
envoyé, ce champ permet de connaître l'adresse de messagerie de l’utilisateur qui
a signé.
DATSIG Si la notification de Workflow suppose un suivi (simple visa ou signature), ce champ

contient la date de l’opération. Il reste vide tant que l’opération n'a pas été réalisée.
TIMSIG Si la notification de Workflow suppose un suivi (visa ou signature), ce champ

permet de savoir à quelle heure le suivi a été fait. Il reste vide tant qu'il n'a pas été
réalisé.
REASON Ce champ contient l'intitulé associé au code motif saisi à la signature de la règle,
lorsque cette saisie est possible au moment de la signature. Ceci suppose qu’une
liste de motifs possibles est définie par l'intermédiaire d'un numéro de table diverse

Sage ERP X3
sur la ligne de signature correspondante.
REACOD Ce champ contient le code motif saisi à la signature de la règle, lorsque cette saisie
est possible au moment de la signature. Ceci suppose que l'on définisse une liste
de motifs possibles par l'intermédiaire d'un numéro de table diverse sur la ligne de
signature correspondante.
REANUM Lorsqu'une saisie de code motif a été prévue à la signature de la règle, on trouve
dans ce champ le numéro de table diverse qui définit les motifs possibles sur la
ligne de signature correspondante.
CELOBJ Dans le cas d'un Workflow objet, on retrouve dans ce champ la clé de l'objet (c'est
le champ Clé déclenchante d'origine).
Dans le cas d'un Workflow de type signature, on retrouve dans ce champ le numéro
chrono à l'origine de la signature.
Dans tous les autres cas, cette zone n'est pas renseignée.
IDENTREF Ce champ technique contient le code de la table déclenchante et le code de la clé

correspondante, exactement de la même façon que pour le champ Identifiant ligne.
Par contre, en cas d'événement de type signature, il reste vide, c'est-à-dire qu'il
n'est pas transmis depuis la notification d'origine.
IDENTERT Lorsqu'une icône de retour est associée au Workflow, ce champ contient le code de
la fonction sur laquelle le retour se fait.
Si la fonction est de type objet, on retrouve ensuite, séparé par un "/"
Le code de la table,
La clé correspondante. Les composants de la clé, pour une clé en plusieurs parties,
sont séparés par le caractère "~".
IDENTGRP Ce champ technique contient, dans l'ordre :

Le nom de la table dans laquelle se trouve l'événement déclenchant d'origine,
La clé courante liée au groupe qui a provoqué le déclenchement.
Le séparateur entre table et clé est "/", le séparateur entre les segments de la clé
(lorsqu'elle est composée de plusieurs champs) est "~".
Le contenu est défini de la façon suivante :
dans le cas d'un événement de type Signature, le contenu de la notification d'origine
est repris.
dans le cas où l'événement est de type Objet, le code de la table principale de l'objet
est repris, si elle peut être déterminée dans les attributs de l’objet. La clé
correspond à la clé courante lors du déclenchement du Workflow.
dans tous les autres cas, la table est définie uniquement si un modèle de données
est attaché au Workflow. Dans ce cas, c'est la table principale qui est renvoyée. La
clé correspond à l'enregistrement courant lors du déclenchement.
NUMORG Ce numéro chrono est renseigné uniquement sur les notifications liées à un
événement de type Signature. Il permet de connaître le numéro chronologique de
l'événement d'origine, celui dont la signature a déclenché la ligne courante.
USRORG Ce champ n'est renseigné que sur les lignes associées à un événement de type
Signature. Il permet de connaître le destinataire du Workflow d'origine (celui qui a
effectivement reçu la notification après application éventuelle des règles de
délégation : ce n'est pas forcément celui qui a signé).

Sage ERP X3
DATREL Ce champ contient la date à laquelle la dernière relance de signature a été faite sur
la notification.
Il n'est pas renseigné si aucun processus de signature n'a été mis en œuvre.
Lorsque l'événement de Workflow suppose une signature, on peut gérer une date
limite de signature et ensuite déclencher des relances basées sur cette date limite.
Ces relances se font par des règles de Workflow batch nommées WRKREM1,
WRKREM2, et WRKREM2E.
Lorsqu'une relance de ce type est faite :
le champ Nombre de relances, est incrémenté ce qui permet de savoir combien de
fois la signature a été relancée.
le champ Dernière date de relance, est modifié ce qui permet de connaître la date à
laquelle la dernière signature a eu lieu.
Si ces règles batch ne sont pas utilisées, et si aucune autre règle n'a été définie
pour mouvementer ces champs, le nombre de relance reste égal à 0 et la date de
relance reste vide, car aucun traitement standard du Workflow ne modifie cette
valeur.
NBREL Ce champ contient le nombre de relances de signatures faites sur l'événement de

Workflow.
LEVSIG Ce champ correspond au niveau des signatures, lorsque des événements de

signature s'enchaînent :
il vaut 0 sur l'événement d'origine.
il vaut 1 sur l'événement déclenché par la première signature.
à chaque événement qui s'enchaîne, il est incrémenté de 1.
La variable LEVSIG correspondante est fréquemment utilisée dans les règles de

Workflow lorsque la règle d'affectation de l'événement d'origine donne l'ensemble
des signataires (1 à 9 maximum). Il suffit alors, dans l'événement d'origine comme
dans les événements de signature qui s'enchaînent, de donner comme formule de
destinataire USER(LEVSIG+1) pour avoir l'utilisateur numéro N dans la liste. Ceci
permet notamment d'avoir des règles de signature récursives, exécutées tant qu'il
reste des signataires.
CONTXT Lorsqu'un Workflow envoie un message avec une icône de retour, le contexte de
connexion (dossier, serveur, service, fonction...) est défini sous forme d'un champ
alphanumérique.
Ce champ technique contient la valeur de ce contexte.
Les différents segments de ce champ sont séparés par le caractère "/".
CLEDEC Ce champ contient la clé à l'origine du circuit de Workflow.

Cette clé, lorsqu'elle est composée de plusieurs parties, se présente comme une
concaténation des parties de clés séparées par le caractère tilde (~).
Les valeurs de clé dépendent du contexte :
sur un Workflow de type objet : c’est la valeur de la clé de la fiche à l'origine du
déclenchement.
sur un Workflow de type manuel : c’est la valeur de la clé de la table principale sur
laquelle s'appuie le modèle de données du Workflow.
sur un Workflow de type import/export ou sur une entrée dans une fonction, rien
n'est renseigné dans cette zone.
sur un Workflow de type édition, rien n'est renseigné si l'édition est lancée depuis
une fonction d'impression (impression, ou impression par groupe). Par contre, si
l'édition est lancée par Fichier/Impression ou Fichier/Liste depuis un objet, la clé de
la fiche est renseignée dans cette zone.
sur un Workflow de type signature : c’est la valeur de la clé héritée du Workflow

Sage ERP X3
d’origine.
ABROBJ Lorsque le premier événement à l'origine d'un circuit de signature est un objet, ce
champ identifie le code de l'objet. Dans les autres cas, il est vide.
Il est ensuite transmis aux différents événements de signature qui pourraient
s'enchaîner au premier.
NBRUSR Ce champ définit le nombre d'utilisateurs destinataires renvoyés par la règle
d'affectation, lorsqu'il y en a une.
S'il n'y en a pas, mais que la règle est de type Signature, le nombre de signataires
défini par la règle d'origine est repris.
Si aucune règle d'affectation n'existe, la valeur retournée est 0.
USRTOP Ce champ définit le premier destinataire de l'événement de Workflow. Un
événement peut envoyer une notification à plusieurs séries de destinataires,
chacun d'entre eux étant défini par une ligne dans le tableau des destinataires.
Ce champ contient le code du destinataire évalué par la première ligne Si l'option
de délégation est Non, Tous, ou Cascade.
Si l'option est Le premier libre, et si l'utilisateur n'est effectivement pas présent, et a
donné délégation, le champ l'utilisateur délégué est renseigné.
VALCTX1 Ces quinze champs contiennent les valeurs contextuelles évaluées au moment du
à déclenchement du Workflow à partir des formules saisies dans le tableau nommé
VALCTX15 Contexte de l'onglet Suivi du Workflow.
Les valeurs stockées dans ce tableau peuvent être utilisées :
pour transmettre à un événement de type Signature des informations utiles au
traitement de la suite du processus
pour faire apparaître des informations utiles dans les plans de travail exploités par
le moniteur de Workflow. Dans ce cas, en paramétrage de la transaction, on définir
un libellé particulier plus parlant.
Quelque soit le format de l’information d’origine, les valeurs mémorisées dans ce
tableau sont de type alphanumérique.
USRSIG1 Ce tableau de valeur contient les codes des signataires successifs, lorsqu'une règle
à d'affectation de destinataires renvoie plusieurs signataires pour la règle de
USRSIG9 Workflow.
Cette information est utilisée pour permettre de gérer correctement les annulations
de signature
Sur les événements de type Signature pour lesquels aucune règle d'affectation
n'est définie, les signataires associés à la règle déclenchante sont présents.
Ainsi, lorsque plusieurs signataires en cascade ont été définis dans la règle
d'origine, et que toutes les règles de signature qui suivent n'ont pas de règle
d'affectation, le circuit complet de signature à chaque niveau est défini dans ce
tableau.
C’est la liste des utilisateurs définis par la règle avant l'application éventuelle de
règles de délégation.
Par exemple, si le premier destinataire de la règle de signature est absent, et qu'il
est remplacé :
le champ Signataire 1 contiendra le signataire d'origine
le champ Premier destinataire contient le code du remplaçant à qui la demande de
signature a effectivement été envoyée.

Sage ERP X3
8.6. LE MONITEUR DE WORKFLOW

Le moniteur Workflow permet de présenter les événements en attente de signature ou de visa pour un
utilisateur donné. Cette présentation est paramétrable par transaction. Elle est issue des écrans et
des fenêtres générées à l’aide des plans de travail.
Les champs affichés dans les onglets sont dépendants de ces paramétrages. Les plans de travail
doivent donc être définis en fonction des natures et des données nécessaires aux opérations qui
seront gérées à partir du moniteur de Workflow par les utilisateurs.
Les fenêtres générées sont constituées

- d’un en-tête commun à toutes les transactions
- des onglets générés spécifiques à chaque transaction, présentant les évènements de
Workflow sélectionnés.
- des boutons accessibles sur chaque ligne affichée dans les onglets qui dépendent
- des droits de l’utilisateur
- du statut de l’événement de Workflow affiché.
8.6.1. Entête
Le champ délégué exceptionnel : cette case à cocher est saisissable s’il existe des évènements
mémorisés dans la table de suivi qui sont affectés à l’utilisateur X3 connecté avec un statut de
délégation exceptionnelle.
Dans ce cas seulement, si l’utilisateur active ce flag, les évènements affichés dans les onglets seront
ceux pour lesquelles la délégation est exceptionnelle.
Le champ destinataire contient le code de l’utilisateur X3 destinataire des événements de Workflow.

Si ce champ est non renseigné, tous les évènements sont affichés.
Les champs date début et date fin définissent la fourchette de dates de sélection des évènements. Si
ces dates sont renseignées, seules les données dont la date de dernière modification ou la date de
création est dans la fourchette saisie.
Par défaut, la valeur de la date de début proposée est la date du jour, diminuée d'un nombre de jours
égal à la valeur du paramètre superviseur WRKDAY. Celle de la date de fin est la date du jour.
Les éléments affichés dans les tableaux des onglets de la transaction dépendent du paramétrage des
plans de travail. En fonction des droits de l’utilisateur connecté et du statut des évènements les
actions ligne peuvent être utilisées pour :
8.6.2. Consultation
8.6.2.1. Visualiser l’opération déclenchante
Cette action permet de revenir en zoom sur la fonction et le contexte à l'origine de l’événement de
Workflow. Dans le cas d'un Workflow sur objet, cette fonction affiche la fiche correspondante de
l’objet.
8.6.2.2. Visualiser l’Opération déclenchante d'origine

Sage ERP X3
Cette fonction est accessible lorsque l'événement à l'origine de l’événement est de type Signature.
Dans ce cas, l’action permet de remonter à l'événement d'origine (si besoin de façon récursive) pour
retrouver la fonction et la fiche qui ont déclenché le début du processus.
8.6.2.3. Visualiser par Retour la fonction associée à l’icône retour

Cette action permet de revenir sur la fonction et dans le contexte décrit par l'icône de retour du
paramétrage de Workflow. Si rien n'a été défini de particulier, c'est l'opération d'origine qui est
proposée.
8.6.2.4. Visualiser les Mails du groupe

Cette action permet de faire apparaître, dans une fenêtre de sélection, la liste des messages envoyés
à tous les utilisateurs destinataires de la notification.
Il y a une ligne pour chaque ensemble de destinataires définis par une ligne dans le tableau de
paramétrage des destinataires de Workflow.
A l’aide d’un double clique sur une des lignes, une fenêtre s'ouvre pour faire apparaître le détail du
message envoyé et la liste des destinataires.
Les champs suivants sont présents dans cette fenêtre :

Destinataires : Définit la liste des adresses de messageries auxquelles la notification a été
envoyée en tant que destinataires principaux.
Copie : Définit la liste des adresses de messageries auxquelles la notification a été
envoyée en tant que destinataires en copie.
Objet : Contient le champ Objet du message tel qu'il a été envoyé.
Accusé lecture : Contient la valeur du témoin accusé de lecture.
Message : Contient le texte du message tel qu'il a été envoyé
8.6.2.5. Visualiser l’historique mail

Cette action permet de faire apparaître, dans une fenêtre de sélection, la liste des messages envoyés
aux utilisateurs successifs ayant signé la notification d'origine et les notifications suivantes (lorsque le
processus de signature se fait à plusieurs niveaux).
Les lignes apparaissent dans l'ordre chronologique inverse (les signatures les plus récentes d'abord).
A l’aide d’un double clique sur une des lignes, une fenêtre s'ouvre pour faire apparaître le détail du
message envoyé et la liste des destinataires comme indiqué précédemment.
8.6.3. Signature
8.6.3.1. Effectuer la Signature de la notification

Cette action permet de déclencher le processus de signature de la ligne. Elle n'est disponible que si
l'utilisateur a le pouvoir de signature, et si la ligne n'est pas déjà signée.
Une fenêtre s'ouvre alors pour proposer un choix de réponses possibles, en fonction du paramétrage.
Un motif supplémentaire peut également être saisi selon le paramétrage, voire un texte libre pour
motiver un refus par exemple.
8.6.3.2. Enregistrer l’accusé de Lecture

Cette fonction permet de donner un accusé de lecture sur la ligne. Cette fonction n'est disponible que
si la ligne n'est pas lue. Aucune autre saisie n'est demandée, la ligne passant à l'état Lu à partir du
moment où cette opération a été faite.

Sage ERP X3
8.6.3.3. Annuler une signature

Cette fonction permet d'annuler une signature déjà accordée. Elle permet de revenir à l'état antérieur
à la signature.
Elle n'est disponible que si les conditions suivantes sont toutes remplies :
- La ligne a été signée
- L'utilisateur en est le signataire
- Le droit d'annulation a été accordé à l'utilisateur, c'est une des options de la fonction.
- Il existe, dans le processus de signature, une réponse associée au code opération CAN. Ce
code motif déclenchera l'action d'annulation de signature en remettant la ligne dans l'état
d'avant la signature. Un autre Workflow de type signature, basée sur la règle d'origine et le
code motif CAN, peut alors être déclenché si nécessaire.
Cette opération est différente d'une opération de rejet de la demande ou de refus, qui sera traitée de
façon tout à fait classique par paramétrage standard.

Sage ERP X3
8.7. ERGONOMIE DU PLAN DE TRAVAIL
8.7.1. Boutons de navigation
Les boutons de navigation permettant de parcourir les lignes du plan de travail.
Premier événement sélectionné dans l’onglet actif.
Dernier événement sélectionné dans l’onglet actif
Evènement précédent
Evènement suivant
Saisie de critères de sélection complémentaires.
Ce bouton permet d'ouvrir un écran de saisie d'un critère de sélection des lignes sous la forme d'une
expression logique. Ce critère sera pris en compte à l’aide du bouton Rechercher
En en-tête de critères de filtrage globaux sur les événements à traiter sont saisissables, sachant que
des filtres plus fins peuvent exister sur chaque onglet de la fonction
8.7.2. Gestion des droits des utilisateurs

Pour définir les droits des utilisateurs sur les opérations de signature dans les plans de travail. Il
faut utiliser les habilitations fonctionnelles via Paramétrage \ Utilisateurs \ Habilitation fonctionnelle
Pour la fonction SAIWRKPLN Moniteur de Workflow, les options disponibles sont :
A : Annulation L’utilisateur peut annuler une signature

G : Signature L’utilisateur peut signer les évènements dont il est destinataire ou délégué
U : Tous utilisateurs L’utilisateur à les droits de signature pour tous les utilisateurs du dossier.
Mettre en place des codes d’accès sur les plans de travail.

Sage ERP X3
8.8. WORKFLOW – POINTS DIVERS
8.8.1. Workflow manuel
Paramétage > Workflow > Workflow manuel
Cette fonction permet de lancer un Workflow manuel, c'est-à-dire de parcourir la structure de données
définie par le modèle associé à l'événement de Workflow et de déclencher les actions
correspondantes : exécution d'actions, envois de notifications via la messagerie ou par un plan de
travail.
Cette fonction peut être lancée en batch. La tâche standard SAIWRKMAN est prévue à cet effet.
Les paramètres d’exécution sont :
Le code Règle Workflow qui identifie la règle de Workflow manuelle à exécuter.
Le champ Filtre qui permet de saisir un filtre sous la forme d'une expression logique évaluée pour
chaque ligne parcourue lors de l'exécution du modèle de données. Si cette expression est fausse, la
règle n'est pas déclenchée pour la ligne en question. Ceci permet par exemple de borner l'exécution.
Si ce champ est non renseigné, aucun critère de filtrage n'est appliqué.
Le champ Simulation permet lorsque cette case est cochée, d ‘obtenir une trace détaillée décrivant
les éléments sélectionnés l'opération n'est pas réellement exécutée, mais simplement simulée. Une
trace détaillée qui décrit ce qui aurait été fait si l'opération n'avait pas été exécutée dans ce mode est
produite.
8.8.2. Méthodologie de mise en œuvre
8.8.2.1. Choix de paramétrage

Avant de paramétrer un nouveau processus de Workflow, quelques questions doivent être posées
afin de choisir la meilleure approche de paramétrage.
Quel sont les acteurs du processus de Workflow ?

Utilisateurs X3 uniquement  Utilisation des règles d’affectation possible
Partenaires X3  Utilisation des règles d’affection impossible
Niveau de suivi des évènements de Workflow ?

Gestion des processus de signature -> utilisation des notifications impossible
Gestion de l’appel d’action associées -> utilisation des notifications impossible
Typologie des évènements à gérer :

- Si les évènements de Workflow sont liés à des objets X3, des fonctions, des éditions ou des
processus batch et que les informations gérées par ces entités sont suffisantes pour
construire les messages, alors l’utilisation des notifications répond au besoin.
- Sinon les possibilités gérées par les règles de Workflow permettent des paramétrages
beaucoup plus riches. Voir le chapitre sur les notifications, il est toujours possible de
paramétrer une notification, de tester cette notification, et de transformer la notification en
règle de Workflow.
Dès que des notions de suivi, de plan de travail fonctionnel, sont exprimées il faut utiliser les règles de
Workflow.
Inventaire des données fonctionnelles à gérer dans les plans de travail

Sage ERP X3
Cet inventaire permet de définir la liste des variables de contexte à paramétrer dans les règles de
Workflow. Ce paramétrage doit être effectué avant la mise en service d’un Workflow. Les évènements
pré existants dans la table de suivi, à une évolution des variables de contexte ne pouvant pas être
modifiés par l’évolution de paramétrage.
En standard, il est possible de gérer 15 données de contexte et chaque donnée étant limitée à 250
octets.
La gestion des contextes est réservée aux règles de Workflow.
8.8.2.2. Tests et diagnostics

Les causes de dysfonctionnement d’un processus de Workflow peuvent être multiples. Ce paragraphe
est une approche pour faciliter la recherche des causes des anomalies.
Utilisation du mode test, cette option n’est disponible qu’avec le paramétrage des règles de Workflow.
Il faut mettre le flag mise au point de l’onglet général à oui.
A l’exécution du Workflow une trace est affichée permettant de vérifier que les conditions de
déclenchement du Workflow sont remplies.
Puis de contrôler si les conditions de déclenchement sont valides le message produit et les
paramètres utilisés pour communiquer avec l’interface de messagerie.
Table de référence
Compteur groupe 0700000322
No chrono 0700000377
Envoi du message
- Ordre système : meladx -v -s smtpasn -r Raymond.le-6:6+A1+B:B+A:A
</devx3/DIAMOND/dossiers/TESTHTLV5/tmp/M0700000377.txt"
#NOM?
From: R.xxxx@sage.com
To: R.yyyy@sage.com
Subject: Edition liste des patch
“Test d’un workflow"

#NOM?
220 : aydaix03.sagefr.adinternal.com ESMTP Sendmail Mon, 27 Aug 2007 15:34:13 +0200
HELO aydaix03.sagefr.adinternal.com
250 : aydaix03.sagefr.adinternal.com Hello aydaix03 [172.28.20.103], pleased to meet you
MAIL FROM:<R.xxxx@sage.com>
250 : 2.1.0 <R.xxxx@sage.com>... Sender ok
RCPT TO:<R.yyyy@sage.com>
250 : 2.1.5 <R.yyyy@sage.com>... Recipient ok
DATA
354 : Enter mail, end with ." on a line by itself"
From: R.xxxx@sage.com
To: R.yyyy@sage.com
Subject: Edition liste des patch
Date: 27 Aug 2007 15:34:13 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary = ----- =_aaaaaaaaaa0""
Content-ID: <39560.1188221653.0@aydaix03.sagefr.adinternal.com>
------- =_aaaaaaaaaa0

Sage ERP X3
Date: 27 Aug 2007 15:34:13 +0100

Content-Type: text/plain; charset = iso-8859-1""
Content-ID: <39560.1188221653.1@aydaix03.sagefr.adinternal.com>
“Test d’un workflow"

------- =_aaaaaaaaaa0--
. 250 : 2.0.0 l7RDYDb37430 Message accepted for delivery
QUIT
221 : 2.0.0 aydaix03.sagefr.adinternal.com closing connection
Envoi mail
- R.yyyy@sage.com RLE""
Suivi signature
#NOM?
Fin normale de trace 27/08/07 15:34:14
Dans cette trace les informations importantes sont :
- Le N° de chrono généré par le processus de Workflow

- L’adresse E_mail de l’émetteur
- L’adresse E_mail du(es) destinataire(s)
- Le texte du message généré (en vert dans l’exemple ci dessus) . Cet affichage permet de
vérifier que le paramétrage du texte à été correctement interprété.
- L’ordre système X3 exécuté pour adresser la demande à l’interface meladx (en mode serveur)
avec le nom du fichier texte généré par la fonction pour transmettre le texte et les paramètres
du message à envoyer. M0700000377.txt dans l’exemple ci dessus. Ce fichier est un fichier
temporaire qui est purgé après l’envoi du message.
- Le niveau de suivi de l’événement de Workflow.
Si le message Message accepted for delivery est présent dans la trace et que celui-ci ne parvient pas
à son destinataire, il faut effectuer une analyse au niveau du serveur de messagerie.
Note sur les pièces jointes : Le paramétrage effectué au niveau d’un serveur de messagerie peut
transformer et supprimer un message avec des pièces jointes en fonction du niveau de sécurité
implémenté sur ce serveur.

Sage ERP X3
8.9. WORKFLOW LIVRES EN STANDARD

Ce chapitre présente des Workflow paramétrés et livrés en standard dans le dossier de référence
DEMOFRA. Ils peuvent servir d’exemple pour voir les différents cas de mise en œuvre.
Les valeurs des catégories de Workflow qui sont gérées dans la table diverse 51 doivent être
complétées avant d’activer ces Workflow.
8.9.1. Workflow de sécurité
PSWNEW : Notification de réinitialisation du mot de passe

Cette règle Workflow se déclenche sur l'événement divers PSW "Mot de passe" . La nature de
l’événement est SEC (sécurité). Elle produit un message à destination de l’utilisateur et un suivi. Le
message contient la valeur du nouveau mot de passe de l’utilisateur et un texte lui demandant de se
connecter pour le modifier dans un délai imparti (2 jours/défaut).
Pour que cette règle de Workflow soit opérationnelle, on doit rendre obligatoire la saisie d’un mot de
passe à la connexion à l’aide du paramètre superviseur PASSWD géré dans le groupe sécurité
(SEC). C’est un paramètre géré au niveau dossier valable pour tous les utilisateurs.
Cette règle est utilisée lors de la création d’un nouvel utilisateur, ou en cas de modification de son mot
de passe par une personne autorisée (via Fonctions/Mot de passe), si un mot de passe est obligatoire
pour le dossier. Le paramètre PASSWD du chapitre superviseur (SUP) contenu dans le groupe
sécurité (SEC) doit être égal à Oui.
Le système attribue alors un mot de passe provisoire calculé aléatoirement, et déclenche

automatiquement les événements de Workflow de type Divers basés sur le code PSW (attribution d’un
mot de passe).
Si un tel événement n’existe pas, le mot de passe provisoire est affiché à l’écran, afin que la personne
puisse le noter et le transmettre à l’utilisateur concerné. Mais si un tel événement existe, rien n’est
affiché à l’écran, et c’est l’événement en question qui est chargé de transmettre le mot de passe en
question. Il va alors envoyer le mot de passe (qui est stocké temporairement dans la variable
GMESSAGE) à l’utilisateur en question (sous réserve que son adresse de messagerie soit
renseignée).
La seule condition au déclenchement est que le champ ADDEML soit non vide dans l’écran de saisie
des utilisateurs. C’est à cette adresse qu’est envoyé le message de confirmation, qui contient :

Sage ERP X3
L’objet du message est :

Un mot de passe temporaire a été attribué au compte utilisateur XXXX sur le dossier YYYY
dans le texte, la confirmation du compte utilisateur et du mot de passe, ainsi qu’un texte l’avertissant
que ce mot de passe est temporaire (il doit être changé dans les deux jours).
En parallèle, un suivi sans signature est envoyé à l’administrateur général (qui est obtenu par la
recherche de la valeur du paramètre ADMUSR) pour lui signaler qu’un mot de passe a été attribué.
Aucune table n'est mise en œuvre par cette fonction.
BLKPSW : Verrouillage des mots de passe périmés

Workflow de type manuel, basé sur le modèle de donné AUTILIS
Il permet de verrouiller l’accès au dossier pour les utilisateurs n’ayant pas modifié le mot de passe
dans les délais impartis (2 jours par défaut).
La gestion des mots de passe doit être active pour le dossier.
Il utilise l’action de Workflow AWRKUPDFLD pour affecter la valeur 1 au champ USRCONNECT de

la table des utilisateurs AUTILIS.
Cette règle permet de verrouiller les utilisateurs dont le mot de passe a été attribué de façon aléatoire
par le système sans avoir été modifié ensuite dans un délai donné.
Cette règle de Workflow, qui parcourt la table des utilisateurs en vérifiant leurs caractéristiques, a
vocation à être lancée en batch avec une périodicité en rapport avec le délai de grâce (tous les jours
si le délai est exprimé en jours).
Les critères complémentaires de déclenchement sont les suivants :

Le modèle de données AUTILIS (qui déclare simplement la table AUTILIS) pour parcourir la table des
utilisateurs est utilisé.
Si le code de l’utilisateur correspond à la valeur ADMUSR, On ne fait rien pour des raisons de
sécurité. Ce code est celui de l’administrateur général du dossier.
Détection des mots de passe attribués automatiquement, ils sont datés par le système au premier
janvier 1970. Champ PASSDAT de la table AUTILIS.
Vérification que le maximum de la date de création et de modification, plus deux jours, est inférieur à
la date du jour, ce pour traiter le cas de la création (date de modification nulle) et la modification (date
de modification supérieure à la date de création). Il est en effet à noter que tout changement de mot
de passe met à jour cette date.
Vérification que le compte de l’utilisateur n’est pas déjà verrouillé.
Si toutes ces conditions sont vérifiées, alors le mot de passe n’a pas été modifié depuis son
attribution. La règle déclenche l’envoi d’un message et d’une action.

Sage ERP X3
C'est l'administrateur général qui reçoit un message lorsque les conditions de verrouillage du compte
sont réalisées.
L'événement de Workflow déclenche l'action AWRKUPDFLD de mise à jour d’un champ dans une
table. Cette action modifie le champ USRCONNECT (autorisation de connexion), qui est forcé à la
valeur 1 (Non).
BLKUSR : Verrouillage des utilisateurs inactifs

Utilisant le même principe que la règle BLKPSW, cette règle à lancer en batch parcourt la table des
utilisateurs. Elle permet de verrouiller les utilisateurs qui ne se sont pas connectés depuis un délai
donné (fixé par défaut dans la règle à 120 jours).
Cette règle de Workflow est de type manuel (le Workflow est lancé soit en direct, soit en batch).

Le compte n’est pas celui de l’administrateur général (Valeur du paramètre superviseur ADMUSR).
Le maximum des dates de création et de dernière connexion, plus 120, est inférieur à la date du jour.
Le compte n’est pas déjà verrouillé.
Si ces conditions sont vérifiées, un message est envoyé à l’administrateur général pour le prévenir et
l’action AWRKUPDFLD est déclenchée.
Cette action met le champ USRCONNECT à 1, ce qui interdit toute connexion à l'utilisateur en
question.
Seule la table AUTILIS est utilisée
CONHIST : Historique des connexions et déconnexions par

utilisateur
Workflow de type manuel basé sur le modèle de donnés CONHIST.
Celui-ci utilise les tables AESPION [AES] et AUTILIS [AUS].
Il donne la liste des connexions, déconnexions sur une période de 20 jours sur le dossier courant.
Ce Workflow produit un message et il utilise la règle d'affectation CONHIST (Historique des

connexions).
Attention, cet événement ne peut fonctionner que si la trace des utilisateurs est activée. C'est le
paramètre superviseur TABTRA du groupe sécurité qui doit être égal à Oui pour les utilisateurs
concernés.
Il se base sur le parcours de la table AESPION par l'intermédiaire du modèle de données CONHIST,
qui lit en même temps la table des utilisateurs.

Sage ERP X3

Sélection des événements sur la période de 20 jours. La condition mise par défaut limite aux dates à
partir du début du mois défini par la date courante moins cinq jours.
Recherche les événements de type connexion et déconnexion (identifiés par leur code).
Regroupement des lignes par code utilisateur

On envoie un message soit à une personne destinataire définie en fonction de l'utilisateur connecté
dans la règle d'affectation CONHIST,
soit au responsable de premier niveau déclaré dans la fiche de l'utilisateur et trouvé par le biais de la
fonction AFNC CHEF(utilisateur,niveau)
soit au destinataire issu de la règle d’affectation CONHIST (valeurs à paramétrer)
L'objet du message donne le code utilisateur concerné, et le corps est composé d'un en-tête et d'une
ligne par connexion ou déconnexion.
CONNECT : Alerte sur connexion infructueuse

Cette règle permet de tracer les connexions de tous types (en principe, ce sont plutôt les connexions
infructueuses qui sont tracées).
Le contexte de déclenchement est l’événement de Workflow de type Divers nommé CON
(Connexion), qui est activé dans tous les cas (connexion réussie ou refusée).

Des tests sur la valeur de la variable GERR peuvent être réalisés. Cette variable prend des valeurs
non nulles en cas d’erreur de connexion. On peut rechercher un code d'erreur particulier à l'aide de la
fonction find, qui permet de donner une liste des codes que l'on souhaite tracer. La liste de codes
d'erreur donnée dans le paramétrage par défaut est indicative, et sera modifiée en fonction de ce que
l'on désire tracer.
On envoie un message à l’administrateur général, identifié par son code défini par le paramètre
ADMUSR, qui est accessible par la fonction func AFNC.PARAM("ADMUSR","")
Le message contient le code utilisateur concerné, le numéro d’erreur et le message en clair envoyé à
l’utilisateur, ainsi que la date et l’heure à laquelle la connexion ou la tentative de connexion a été faite.
On utilise pour ce faire la variable GMESSAGE, qui donne un message clair expliquant les raisons du
refus de la connexion. Différentes erreurs existent, elles sont précisées dans le tableau ci-dessous.
Dans la règle fournie en standard, on propose de ne tracer que les connexions échouant pour cause
de mot de passe incorrect.
1 Mot de passe incorrect (connexion automatisée)

2 Code langue incorrect
3 Code utilisateur inexistant ou inactif
4 Nombre maximum de sessions par utilisateur dépassé
5 Compte utilisateur verrouillé (trop de tentatives de connexion)
6 Mot de passe incorrect
7 Pas de menu de départ
8 Connexion refusée par point d’entrée
9 Nombre d’utilisateurs dépassé pour le profil
10 Dossier verrouillé (en mode mono-utilisateur, en cours de sauvegarde, de revalidation, de remise
à zéro, de resynchronisation…
11 Menu inexistant
12 Erreur de verrouillage durant la phase de connexion
13 Refus de saisie de mot de passe (sur demande de modification)

Sage ERP X3
DECONNECT : Alerte des déconnexions sur time-out

Cet événement permet de tracer les déconnexions sur time-out. Il s'agit de déconnexions
automatiques gérées par le superviseur suite à une inactivité clavier supérieure à une valeur en
secondes donnée par le paramètre superviseur du groupe session TIMEHGUP1.
Il peut être intéressant d'activer temporairement cet événement lors de la mise en place de
déconnexions automatiques, afin de régler au mieux ce temps de déconnexion pour éviter les
déconnexions trop fréquentes.
Cette règle de Workflow se déclenche sur l'événement divers "Time-out" et gère un suivi.
Cet événement se déclenche sur le code événement TIM qui trace précisément ce type de
déconnexion.
Le super-utilisateur qui est défini par le paramètre superviseur ADMUSR, mais également par la
variable globale GSUPER.
Par défaut, on a défini à la fois un message et un intitulé pour le suivi, mais seule la case à cocher
Suivi a été activée. Si on veut envoyer le message qui est déjà prédéfini, il suffit de cocher à nouveau
la case correspondante.
Le message, s'il est envoyé, donne le code de l'utilisateur, la date et l'heure de déconnexion, la
fonction en cours (variable GFONCTION, qui est vide si l'utilisateur se trouvait au niveau du menu),
ainsi que la valeur du paramètre de time-out.
8.9.2. Tracabilité
UPDFLD : Traçabilité de la base

Cet événement est prévu pour gérer des alertes sur la modification de champs jugés sensibles dans
les tables de la base. Ceci s’appuie sur l’onglet Audit défini dans le dictionnaire des tables. Celui-ci
permet, sur des tables du dictionnaire, de tracer les modifications de champs jugés sensibles.
Pour que la règle de Workflow puisse être utilisée, on doit au préalable :

Préciser, pour chacune des tables concernées, les opérations (Création, Modification, Suppression)
qui doivent être tracées. Ceci se fait dans l'onglet Audit de la gestion des tables. Une écriture dans la
table principale d’audit AUDITH est gérée à chaque opération.
Préciser les champs qui doivent être suivis sur modification, et pour quelles valeurs : il est possible de
préciser un opérateur (inférieur, inférieur ou égal, supérieur, supérieur ou égal, égal, différent, comme,
ou indifférent), et une valeur constante.
Si la condition est réalisée et le champ modifié, on aura également une ligne dans la table AUDITL
pour le champ, ligne reliée à l’en-tête de modification AUDITH, et contenant l’ancienne et la nouvelle
valeur.
Indiquer que les données d’audit sont gérées par un processus de Workflow à l’aide de la case à
cocher « Workflow »
Cette règle de Workflow est de type manuel, le Workflow est lancé soit en direct, soit en batch. Elle
produit un message.
La règle d'affectation UPDFLD (maj. champs dans la base) est utilisée par cette règle de Workflow.
L'exécution de cette règle provoque alors le parcours de la table des lignes d’audit, pour retrouver les
champs sensibles modifiés. Son déclenchement se faisant à la demande, il est conseillé de le lancer
en batch avec une périodicité à définir.

Sage ERP X3
La règle d’affectation est prévue pour associer à chaque table auditée, un utilisateur invariant. Des
règles plus sophistiquées peuvent être mises en œuvre. Le modèle de données utilise la table
AUDITL qui est liée à la table AUDITH par le champ SEQ (numéro de séquence unique).
La règle parcourt et regroupe les lignes sur les champs de la table ([AUD]TBL) et champ ([AUL]COL),
pour afficher dans un seul message pour toutes les modifications d'un même champ d’une table.
Les conditions du déclenchement de cette règle sont :

Recherche des événements pour lesquels STA=2 (éléments non encore notifiés à l’utilisateur : la
règle va par ailleurs modifier cet indicateur pour le passer à 3).
Recherche de l’utilisateur [L]USER obtenu par l’utilisation de la règle d’affectation. Il faut définir un
utilisateur par table dans la règle d’affectation.
Le message est composé d’un en-tête et d’une ligne itérative. La formule |LIB| présente dans le corps
du texte utilise la formule déclarée dans le champ Ligne.
Func
AFNC.F3C("20X",[F:AUD]ID1+string$([F:AUD]ID2<>"",";"+[F:AUD]ID2),[F:AUL]OVAL,[F:AUL]NVAL)
+" "+func AFNC.FDH([F:AUD]DAT,[F:AUD]HOU) +" "+format$("K:10X",[F:AUD]ADOUSR)
La formule de la ligne fait appel à des fonctions dédiées définies dans le traitement AFNC,
qui sont:
La fonction F3C formate trois champs avec le format donné en tête. Elle permet ici de formater sur 20
caractères, avec le format "20X", les champs ID1 et ID2 concaténés identifiant la clé de la ligne
modifiée, et les valeurs avant et après (champs OVAL et NVAL).
La fonction FDH formate une date et une heure. Les paramètres étant les champs présents dans la
table d’audit.
Enfin, l’onglet action permet la mise à jour de l’indicateur STA dans la table d’audit AWRKHISSUI,
d’abréviation AUD avec la valeur "3". Cette valeur correspond au statut Traité et évitera de traiter à
nouveau cette modification.
On utilise pour ce faire l’action standard AWRKUPDFLG, dont les arguments sont :
ABREV = « AUD » -> abréviation de la table à mettre à jour
FLD = « STA » -> code du champ à modifier
VALEUR= 3 -> valeur du champ après modification
Cette action est prévue pour permettre la modification de 4 champs d’une même table.
UPDPAR : Traçabilité des paramètres généraux

Cet événement permet d’alerter des utilisateurs en cas de modification de paramètres généraux. Il
nécessite l’activation d’un audit sur la table ADOPAR
C’est un Workflow de type manuel exploitable en mode batch et interactif, basé sur les lignes d’audit
conservées dans la table AUDITL.
Les lignes notifiées ne le sont qu’une fois (le flag est modifié)
Les modifications de paramètres au niveau utilisateur (table ADOVALAUS) ne sont pas tracées. Les
modifications sont tracées uniquement pour les modifications de paramètre à un niveau global
(dossier, société, législation ou site).
Pré-requis

Sage ERP X3
Un audit doit être paramétré sur la table ADOVAL, dans l’onglet Audit du dictionnaire des tables. Le
paramétrage indique les conditions de trace des modifications. Les opérations suivantes sont tracées,
la modification, la création et la suppression.
La case Workflow est positionnée à oui.
La clé de suivi est la clé ADW1 (dont le premier segment contient le code du paramètre). Ce code est
présent dans le champ ID1 de la table de suivi AUDITH.
Le champ à tracer est le champ VALEUR. C’est lui qui stocke la valeur du paramètre.
Fonctionnement
A ce workflow sont associés :

- La règle d'affectation UPDPAR (maj. paramètres)
- Le modèle de données UPDPAR qui contient
- en table principale AUDTIL (lignes d’audit)
- AUDITH entête d’une opération sur la table
- ADOVAL valeur des paramètres généraux
Cette règle parcourt la table d’audit et renvoie un message à un utilisateur défini par défaut par
chapitre de paramètres (table diverse 911). Les modifications de paramètre sont regroupées par
chapitre.
Le paramétrage est basé sur les éléments suivants :
A partir des données de la table AUDITL, les opérations suivantes sont réalisées :
Une jointure de type (1,1) vers la table d’en-tête AUDITH, avec le champ [F:AUL]SEQ qui contient la
clef primaire de la table AUDITH (numéro de chrono)
Une jointure de type (1,1) vers la table des paramètres ADOVAL. Le code du paramètre modifié étant
contenu dans le champ ID1 de la table AUDTIH. Le champ ID2 de cette dernière table permet
d’identifier le niveau du paramètre modifié, est l’une des trois formes :
" ~SITE"
"SOCIETE~ "
"*~LEGISLATION"
La règle d’affectation UPDPAR, basée sur le champ chapitre permet de définir, par chapitre un
destinataire de message.
Un Workflow Manuel est toujours considéré comme un Workflow Ligne, même s’il n’y a pas plusieurs
niveaux de table dans le modèle de données. On définit dans le champ Regroupement le ou les
champs sur lesquels doivent se faire la rupture (champs séparés par un point-virgule). Ici, on regroupe
par le champ [ADP]CHAPITRE, ce qui correspond exactement au champ sur lequel on définit le
routage à l’utilisateur.
Les conditions d’envoi sont les suivantes :
Le champ STA de la table AUDITH vaut 2, traitement de Workflow à effectuer sur l’enregistrement.
La table concernée par l’audit est dans le champ TBL de la table AUDITH. La valeur de ce champ doit
être égale à ADOVAL.
La variable MODIF de la table ADOPAR doit être égale à 2. Ce test permet de ne pas voir apparaître
les changements de valeur d’un paramètre nommé MONO, qui est modifié pour des raisons
techniques de façon transparente pendant la transaction de modification de paramètres.
Le champ [L]USER, qui correspond au code utilisateur renvoyé par la règle d’affectation, est non vide.
Ainsi, pour ne pas tracer les modifications de paramètres d’un chapitre, il suffit de ne pas le déclarer
dans la table d’affectation.

Sage ERP X3
Il est à noter que cette dernière condition est de type En-tête, et pas de type Ligne. Ici les conditions
de ligne sont utilisées pour filtrer les lignes directement dans la base. Ces conditions ne peuvent donc
pas utiliser un champ qui est n’est évalué que lorsqu’un premier regroupement de lignes est détecté.
C’est le regroupement qui détermine les attributs de l’ en-tête.
Le destinataire est défini par la variable [L]USER précédemment évoquée.
Le message comprend une partie objet et en-tête :
La ligne de détail (insérée dans le texte par le biais de la formule |LIG|) formate dans l’ordre
le code utilisateur
l’opération,
la date et l’heure,
les valeurs avant et après du paramètre.
A l’aide de la formule suivante :

func AFNC.F2C("5X",[AUD]ADOUSR,func AFNC.OPR([AUD]EVT))+" "
+func AFNC.FDH([AUD]DAT,[AUD]HOU)+" "
+func AFNC.F2C("10X",[ADP]PARAM,vireblc(ctrans([AUD]ID2,"~*"," "),4))+" "
+func AFNC.F2P([ADP]TYPVAL,[ADP]NOLIB,[AUL]OVAL,[AUL]NVAL)

Sage ERP X3
Les fonctions utilisées sont les suivantes :

- La fonction F2C formate deux champs avec le format donné en tête. Elle est utilisée deux fois
:
o La première fois pour formater sur 5 caractères, avec le format "5X", les champs
ADOUSR et une expression calculée à partir de la fonction OPR définie ci-dessous.
o La seconde pour formater sur 10 caractères, avec le format "10X", le code du
paramètre trouvé dans la table ADOPAR et le code site ou société, obtenu en
supprimant les caractères "~" et "*" (fonction ctrans, pour remplacer par des espaces,
puis fonction vireblc, pour supprimer les espaces).
- La fonction OPR permet de transformer le code opération (INSERT, UPDATE, DELETE) en
un intitulé plus parlant dans la langue de connexion de l’utilisateur. L’argument utilisé est bien
entendu le champ EVT présent dans la table d’audit. La fonction FDH formate une date et une
heure (les paramètres étant les champs correspondants dans la table d’audit).
- La fonction F2P formate deux valeurs de paramètres dont on donne le type et le numéro de
menu local.
L'événement de Workflow déclenche l'action AWRKUPDFLD qui met à jour l’indicateur STA dans la
table d’audit AUDITH, avec la valeur "3" pour indiquer que l’événement est Traité.
Les tables suivantes sont utilisées par la règle:
ADOPAR [ADP] Paramètres

AUDITH [AUD] Audit - En-tête
AUDITL [AUL] Audit - Lignes
TRACE : Envoi de trace

Permet de déclencher l’envoi d’une trace en pièce jointe d’un message, par la fonction Option / Envoi
qui n’est active que si un événement de ce type existe
Cet événement, lorsqu'il existe, permet à l'utilisateur qui affiche une trace dans le progiciel de
provoquer un envoi de cette trace en pièce jointe d'un message.
L’utilisateur utilise la fonction Option / Trace accessible depuis le menu de la fonction de visualisation
des traces.
Cette fonction n'est utilisable que si au moins un Workflow associé à l'événement divers TRA existe et
est actif.
Le message est modifiable, ce qui permet d'en changer le texte et les destinataires.
Par défaut, c'est l'utilisateur ayant déclenché la visualisation de la trace qui reçoit le message.
ENDREQ : Fin de requête

Cet événement permet d’alerter un utilisateur de la fin d’exécution d’une tâche batch qu’il a lancée.
OBJCRE : Création d’une fiche

Ce Workflow générique est de type objet, il s’applique aux objets lors de la création d’une fiche. Il est
à utiliser si la table principale ne possède pas le champ ENAFLG. Il est prévu pour notifier la création
d’une fiche. Il ne gère pas de signature.
La règle d'affectation OBJCRE (Création objet générique) est utilisée, pour affecter un destinataire par
code objet. Le caractère générique de cette règle peut devenir complexe, si le nombre d’objet est
important.

Sage ERP X3
Le code modèle associé n’utilise pas la table principale de l’objet ! Ce ne serait pas le cas pour une
règle de signature «simple» liée à un objet bien déterminé.
Comme on a besoin de tester des informations issues de la structure de l’objet et de la table, le code
modèle associé à la règle d’affectation a pour table principale la table ATEXTE.
A cette table est liée, par un lien artificiel, la table des objets (lien 1,1). La clé de lien est ""+GABREV.
La variable [V]GABREV est une variable globale qui permet, dans un contexte objet, de connaître le
code de l’objet courant. Le contrôle d’existence dans la table d’origine est inhibé en mettant une
expression résultant de la concaténation d’un champ vide et de la variable GABREV.
Ainsi, dans l’événement OBJCRE, on dispose en ligne de la table AOBJET (structure de l’objet), et de
la table ATABLE (table principale de l’objet). Ceci permet ensuite de tester l’existence du champ
ENAFLG dans le dictionnaire de la table principale.
On est en gestion d’objet (sans code objet précisé), en création de fiche.

Le champ [ABV]ENAFLG n’existe pas (ABV étant l’abréviation de la table associée à l’objet, ce qui
explique que l’on passe par une fonction evalue).
La règle d’affectation des destinataires doit avoir rendu une valeur ([L]USER non vide).
Un champ Intitulé doit exister dans la table principale de l’objet, pour permettre de renvoyer un intitulé
dans le message. Cet intitulé ne peut pas être dépendant de la langue. De ce fait, ce Workflow ne
pourra pas être utilisé pour des objets qui présentent cette particularité. Si nécessaire, une règle de
Workflow non générique plus simple sera préférée.
Le destinataire du message et du suivi est l’utilisateur contenu dans la variable [L]USER, alimentée
par la règle d’affectation.
L'exemple de message donné ci-dessous s'appuie sur la création d'une fiche tiers. Dans ce cas,
l’objet du message envoyé suivrait le modèle suivant :
Fiche Tiers MARTIN créée
Pour obtenir ce modèle, utilise la formule suivante :

mess(61,154,1)-func AFNC.TEXTE([AOB]LIBEL)-CLEOBJ-mess(62,154,1)
L’intitulé de l’objet en partant du champ LIBEL de la table objet. Ce champ est de type « texte
dictionnaire », il faut donc utiliser la fonction AFNC.TEXTE pour avoir le texte dans la langue courante
de l’utilisateur envoyant le mail.
La clé courante de l’objet est donnée par la variable CLEOBJ, qui est toujours renseignée dans un
contexte objet.
Le corps du message suivra alors le modèle suivant :

Désignation : MARTIN et Associés
Créé par : DOE ( John DOE )
A l’aide des formules

|mess(63,154,1)-":"-evalue("["+[ATB]ABRFIC+"]"+[ATB]INTIT)|
|mess(64,154,1)-":"-GUSER-"("+GNOMUSER+")"| s
La désignation est obtenue en évaluant le champ intitulé de la table associée à l’objet.
Les variables GUSER et GNOMUSER donnent le code et le nom de l’utilisateur courant (celui qui a
créé la fiche).
Le suivi réalisé dans cet exemple est minimal, puisqu’il n’y a pas de processus de signature. Il permet
d’envoyer une ligne dans le moniteur de Workflow, avec l’intitulé :
Fiche créée : Tiers MARTIN (Martin et associés)
Avec la formule suivante :
mess(65,154,1)-":"-funcAFNC.TEXTE([AOB]LIBEL)-CLEOBJ-
"("+evalue("["+[ATB]ABRFIC+"]"+[ATB]INTIT)+")"

Sage ERP X3
Cet exemple concatène le nom de l’objet, la clé créée, et l’intitulé entre parenthèses.
La case Suivi étant cochée, l’utilisateur pourra simplement mettre un visa sans signature pour
indiquer qu’il a lu la ligne en question.
OBJCRES : Création d’une fiche objet avec signature

Ce Workflow générique de type objet est à utiliser avec les objets dont la table principale contient le
champ ENAFLG. Cet événement déclenché par la création d'une fiche, est à l'origine d'un flux de
signature qui permettra de mettre à jour l'indicateur Actif de la fiche.
Si l’utilisateur n’a pas ce droit, un circuit de Workflow permet :

De demander une signature qui rend la fiche active.
De faire un retour au demandeur en cas de rejet (règle OBJREJ).
De faire un retour au demandeur en cas d’acceptation (règle OBJVAL).
Cet événement est générique, et est relativement similaire à l’événement OBJCRE, mais il diffère,
dans ces cas d’utilisation, par les points suivants :
Les conditions de déclenchement (création d’objet, nécessité d’avoir défini un destinataire pour l’objet
dans la règle d’affectation OBJCRE) sont identiques.
Le champ ENAFLG existe dans la table, et que la fiche a été créée avec le statut « Non actif »
(ENAFLG=1). Ceci va permettre de compléter le circuit par une signature dont l’objet va être :
soit de valider la fiche en positionnant ENAFLG à 2,
soit de refuser et donc de positionner ENAFLG à 1.
Le paramétrage de l’événement diffère donc de celui de l’événement précédent, puisqu’on va décrire

à la fois l’événement à l’origine de la signature, et le processus de signature lui-même.
Cette règle de Workflow se déclenche en gestion d'objet, uniquement sur les opérations de création.
Elle utilise la règle d'affectation OBJCRE (Création objet générique)
Les critères de déclenchement sont analogues à ceux de la règle OBJCRE (à ceci près que cette fois
on teste l'existence et non l'inexistence du champ ENAFLG). La valeur de la variable ENAFLG, dans
la table dont l'abréviation est donnée par le dictionnaire, doit être égale à 1.
Un seul destinataire, celui renvoyé par la règle d’affectation.
Les différents choix de signatures possibles sont :

VAL : validation, qui va entraîner la mise à jour de l'indicateur Actif à Oui.
REJ : rejet, qui va entraîner la mise à jour de l'indicateur Actif à Non.
ESC : un dernier choix nommé Escalade, qui ne sera utilisable que si la date de signature est
dépassée. Ce choix pourra être déclenché automatiquement par la règle WRKREM2.
Actions déclenchées par l'événement

L'événement de Workflow déclenche l'action AWRKUPDOBJ.
Cette action est déclenchée au traitement de la réponse que si celle-ci à pour valeur :
VAL --> RESULT=1
REJ --> RESULT+2

Sage ERP X3
L’action met à jour l'indicateur ENAFLG avec la valeur correspondante grâce aux variables de
contexte
OBJET : code de l’objet --> CTX(3)
CLE1 : Clef courante de l’objet --> CTX(4)
FLD : Champ à mettre à jour --> ENAFLG
VALEUR : Valeur après mise à jour --> RESULT
Les événements OBJREJ et OBJVAL vont permettre de signifier un retour au créateur de la fiche.
Nota : le Workflow ne s’applique pas sur les objets suivants :

AWM Définition d’un modèle de données
AWR Règles d’affectation
AWV Affectation des utilisateurs
AWO Historique des Workflow
AWA Règles de Workflow
ANM Gestion des compteurs de document
8.9.3. Suivi des signatures
WRKREM1 : Première relance Workflow

Cette règle de Workflow est de type manuel, elle est lancée soit en direct, soit en batch.
Elle est basée sur la liste des notifications en retard de signature ou de visa de plus de 1 jour ou de
plus de trois jours si le niveau de relance est supérieur à 1.
Les notifications à lire ne sont relancées qu’une fois
Les notifications à signer le sont N fois
Le niveau de relance et la date de relance sont mis à jour
Cette règle parcourt l'historique des notifications AWRKHISSUI envoyées pour traiter celles qui sont
en retard.
Le texte géré dans l'onglet Suivi est rempli par défaut avec les données suivantes :
Le numéro de chrono de la notification d'origine
Le nombre de jours de retard.
Il faut que la case à cocher correspondante soit activée dans l’onglet Général de la règle de Workflow
pour que le suivi soit actif.
L'indicateur FLGSIG, qui définit l'état de la demande, doit être égal soit à 2 (A viser), soit à 3 (A
signer). ->
find([F:AWS]FLGSIG,2,3)<>0
La notification ne doit jamais avoir été relancée si elle doit être visée.
[F:AWS]NBRREL=0 or [F:AWS]FLGSIG=3
La date limite de signature demandée doit être dépassée de 1 jours et si la relance concerne une
notification A signer, celle-ci sera relancée tous les 3 jours.
date$-[F:AWS]DATMAXSIG>1+3*[F:AWS]NBRREL
Le destinataire est celui à qui la notification originelle a été envoyée. Il est identifié par le code
utilisateur défini dans la ligne d'historique [F:AWS]DEST. Si ce code est non renseigné, l'adresse
email qui est renseignée [F:AWS]EMAIL dans la ligne d'historique est utilisée. Ceci peut notamment
être le cas si la notification a été envoyée à un destinataire non utilisateur X3.
L’événement de Workflow déclenche l'action AWRKUPDFLD qui permet la mise à jour des champs
suivants de la table AWRKHISSUI :

Sage ERP X3
DATREL : la dernière date de relance (avec la date du jour),

NBREL : le nombre de relances réalisées sur l’événement (incrémentant de 1).
Les tables suivantes sont utilisées par la règle WRKREM1 :

AWRKHISSUI [AWS] Historique suivi Workflow
AWRKPARF [AWF] Règles de Workflow (signature)
WRKREM2 Escalade automatique

Cette règle permet de déclencher une escalade automatique sur les notifications pour lesquelles une
signature n'a pas été faite en temps et en heure. Le principe de l'escalade est de provoquer la
signature automatique de la notification d'origine avec le code ESC.
Ceci suppose bien entendu que la règle d'origine autorise une réponse de type ESC. Ce type de
réponse peut ne jamais apparaître comme un choix possible au signataire, en mettant une condition
impossible du genre 1=0.
Cette règle permet de répondre en remplacement du destinataire et en gardant une trace (Réponse
ESC) de l’automatisme. Elle permet d’exécuter les actions prévues dans le processus de signature de
l’événement d’origine.
Cette règle de Workflow est de type manuel, elle est lancée soit en direct, soit en batch. Elle utilise le
modèle de données WRKREM.
Cette règle parcourt l'historique des suivis WRKHISSUI et utilise la table des règles de Workflow pour
vérifier la présence de la réponse ESC.
Les critères de déclenchement sont les suivants :

La notification doit être dans l'état A signer
Une relance est déjà effectuée
La date de la dernière relance doit être dépassée d'au moins 1 jour.
Dans le tableau des réponses possibles à la règle, le choix ESC escalade doit être paramétré.
Le destinataire est le responsable hiérarchique au niveau 1 de l'utilisateur déclaré dans l’onglet

« Rôles » de sa fiche. Le code de ce responsable est obtenu via la formule
func AFNC.CHEF([AWS]DEST,1)
Si la demande de signature n'est pas adressée à un utilisateur, mais directement à une adresse de
messagerie, le champ n'est pas renseigné, donc aucune escalade ne sera envoyée.
L'événement de Workflow déclenche l'action SIGWRK de signature d’un Workflow en lui transmettant
les paramètres suivants
[F:AWS]CHRONO : Numéro de chrono de l’évènement à signer
[F:AWS]DEST : Code destinataire de l’évènement
"ESC" : Code de la réponse liée à la signature.
Les tables suivantes sont concernées par la règle WRKREM2 :

AWRKHISSUI [AWS] Historique suivi des évènements de Workflow
AWRKPARF [AWF] Règles des signatures des Workflow

Sage ERP X3
WRKREM2E Escalade par défaut

Cette règle permet de définir une action d'escalade par défaut lorsqu'il n'existe pas de signature de
type ESC proposée dans la règle de Workflow d'origine. C'est une alternative à la règle de Workflow
WRKREM2.
Cette règle de Workflow est de type manuel, elle est basée sur la liste des notifications. Elle utilise le
modèle WRKREM qui permet d'avoir en ligne les suivis de Workflow et le paramétrage associé.

La notification doit être dans l'état A signer
Une relance est déjà effectuée
La date de la dernière relance doit être dépassée d'au moins 1 jour.
Dans le tableau des réponses possibles à la règle, , le choix ESC escalade ne doit pas être déclaré.
Le destinataire est le responsable hiérarchique au niveau 1 de l'utilisateur déclaré dans l’onglet

« Rôles » de sa fiche. Le code de ce responsable est obtenu via la formule
func AFNC.CHEF([AWS]DEST,1)
Si la demande de signature n'est pas adressée à un utilisateur, mais directement à une adresse de
messagerie, le champ n'est pas renseigné, donc aucune escalade ne sera envoyée.
L'événement de Workflow déclenche l'action AWRLUPDFLD pour signer l’événement d’origine avec
les paramètres suivants:
FLGSIG : Etat de l’événement : 5= signé
ACTSIG : Code à l'origine de la signature : ESC=Escalade
USRSIG : Utilisateur ayant signé : GSUPER=le super-utilisateur du dossier
DATSIG : Date de signature : date$=la date du jour

Sage ERP X3
Les tables suivantes sont utilisées par cette règle:

AWRKHISSUI [AWS] Historique suivi des évènements de Workflow
AWRKPARF [AWF] Règles des signatures des Workflow
ESCALA : Escalade générique

Cet événement est de type signature, il est à utiliser s’il n’existe pas de procédure particulière. Il est
déclenché par toute signature de type ESC (escalade) pour prévenir les autres acteurs lié à
l’événement de la signature automatique.
Il permet d’envoyer un message d’escalade :

[L]USER(2) :Soit au prochain destinataire, si plusieurs destinataires sont définis par une règle
d’affectation au niveau de la règle d’origine.
func AFNC.CHEF([AWS]USRSIG,1) : Soit au chef du premier destinataire.
Le message envoyé contient le texte suivant :
L'événement-[AWS]CODWRK-aurait du être signé il y a-num$([AWS]DATMAXSIG-date$)-jours-"!"

Emetteur-":"-[AWS]EMETTEUR-"("+Func AFNC.NOMUSER([AWS]EMETTEUR)+")"
Signataire attendu-":"[AWS]USRSIG-"("+Func AFNC.NOMUSER([AWS]USRSIG)+")"
Date limite prévue-":"-Format$("DD2:",[AWS]DATMAXSIG)|
string$([AWS]TEXSUI<>"",Information sur le contexte d'origine-":"-[AWS]TEXSUI
string$([AWS]IDENTRET<>"",L'icône jointe renvoie sur le contexte déclenchant)
Il n’y a pas d’action associée, ni de suivi de ce message.

Sage ERP X3
8.10. FONCTIONS DEDIEES A LA CRM

Pour plus d’informations sur ces fonctions se reporter aux cours V140
8.10.1. Paramétrage des signatures

Cette fonction permet de déterminer les critères de signature pour chaque couple Société - Type de
document. Le type de document peut être une demande d'achat, une commande ou un contrat de
commande ouverte. Les critères, au nombre de cinq maximum, sont paramétrables et peuvent être
choisis parmi les rubriques des principales tables en ligne pour le type de document concerné.
8.10.2. Règles de signature

Cette fonction permet de sélectionner pour une société et pour un type de document Achats
(demandes d'achats, Commandes d'achats ou Commandes ouvertes d'achat) l'écran permettant de
saisir les règles de signatures.
8.10.3. Rectification des signatures

Cette fonction est un utilitaire permettant de rectifier des enregistrements concernant des documents
à signer qui sont en anomalie. Ces anomalies peuvent être consécutives à un oubli de création de
règles de signature ou à des modifications ou suppressions de paramétrage intempestives.
En effet, lors de la création de demandes d’achats, de commandes ou de contrats (commande
ouverte) et si la gestion des signatures est active, des enregistrements sont automatiquement créés
dans la table des signatures notamment pour diriger automatiquement le document vers le premier
signataire du circuit, qui est recherché dans la règle de signature correspondant au contexte. Lorsque
cette règle n'existe pas, un message apparaît lors de la saisie du document lui-même et
l'enregistrement est tout de même créé sans signataire. Tous ces enregistrements devront être traités
par une personne responsable, de manière à régulariser la situation en créant les règles manquantes.

Sage ERP X3
8.11.1. Les points d’entrée

Constitution des messages par le Workflow : Traitement AWRK
MESSAGE : Ce point d’entrée permet de prendre la main à chaque envoi automatique de message
par la fonction de Workflow. Il est ainsi possible de supprimer l’envoi du message et/ou d’exécuter un
autre traitement à la place.
Les tables suivantes sont en ligne :

Table Contenu significatif Intitulé Table
AWRKPAR [AWA] Non Règles de Workflow
AWRKPARC [AWC] Non Règles de Workflow (actions)
AWRKPARF [AWF] Non Règles de Workflow (signature)
AWRKPARH [AWH] Non Règles de Workflow (destinataire)
L’appel du point d’entrée MESSAGE est fait juste avant l’envoi effectif du message.
La variable GPE est testée au retour du point d’entrée. Si sa valeur est différente de 0, le message
n’est pas envoyé.
Les tables AWRK* sont ouvertes mais seules les classes des tables concernant les règles de
Workflow sont renseignées.
Envoi des messages : Traitement AWRKMEL :
EMAIL : Ce point d’entrée permet de modifier l’expéditeur d’un message envoyé par le serveur de
message, Interface SMTP POP3.
Il n’est pas possible de modifier l’expéditeur d’un message envoyé par un poste client X3. En effet,
c’est l’instruction Send qui est utilisée dans ce contexte.
L’appel du point d’entrée EMAIL est utilisé juste après l’ouverture du fichier texte de commande qui
sert d’interface avec la fonction meladx. Ce fichier de commande est encore vide.
La variable EXP_MAIL contient le nom de l'expéditeur.

La variable USR_EMAIL(1..) contient les codes des destinataires.
La variable USR_ENVOI(1..) permet de distinguer les destinataires principaux des destinataires en
copies.
8.11.2. Epuration des tables

Dans un environnement de production Sage X3, la mise en place des audits et des Workflow doit
s’accompagner d’une mise en œuvre des procédures d’épuration.
Pour les Workflows
Deux règles d’épuration des tables liées aux processus de Workflow sont livrées en standard. Ces
règles seront à adapter en fonction du contexte.
La formule ASUIVI permet de purger la table AWRKHISSUI qui contient le suivi des évènements de
Workflow.
Il faut modifier la formule d’épuration pour ne pas purger les évènements non signés ou non lu
[F:AUS]FLGSIG =>4

Sage ERP X3
La formule AMESSAGE permet l’épuration des tables :

- AWRKHISMES Historique des messages Workflow
- AWRKHISJOI Historique des pièces jointes liées aux messages
- AWRKHISDES Destinataires des messages
Nota : Avec le paramétrage livré en standard, les évènements à signer sont purgés.
Pour les audits, la formule d’épuration à utiliser est AUDIT, pour les audits liés à un processus de
Workflow modifier la formule d’épuration pour que les éléments à épurer vérifient la règle « Audit traité
par le Workflow » [F :AUD]STA>2
8.11.3. L’exécutable meladx

Le programme binaire « meladx.exe » qui se trouve dans le répertoire $ADXDIR\bin est utilisé par X3
pour envoyer un message à un serveur de messagerie. Il sert dès que le Workflow est paramétré
avec l’option d’envoi depuis le serveur. La valeur du paramètre TYPMES dans le chapitre SUP égal à
Serveur.
Un message Sage X3 est constitué d’un entête suivi par une ligne vide et d’un corps de message.
L'entête est constitué par une suite de lignes du type : nom_du_champ : champ
La variable nom_du_champ peut être :

From --> émetteur ,
To --> destinataire
Cc --> Copie à
Bcc --> Copie cachée
Subject --> Objet du message
Tout autre nom de champ est accepté sans interprétation, un nom de champ ne devant pas contenir
les caractères : ()<>@,;:"\/.?= et bien sur chr$(32).
Le corps du message est constitué de lignes de texte libre limité au jeu de caractères ascii 7bits, ainsi
que de lignes de directives commençant par le caractère #. Si une ligne de texte doit commencer par
le caractère #, il faut doubler ce premier caractère #.
Une directive se traduit dans le message envoyé par un fichier joint. Il y a 2 types de directives : si la
directive commence par <, le contenu du fichier sera pris dans le texte qui suit la directive, sinon la
directive se terminera par le nom du fichier à joindre.
La directive doit préciser le type et le sous-type (au sens mime des termes) du contenu du fichier, soit
:
image/gif ou image/jpeg, ...
audio/... (basic,...)
video/... (mpeg,...)
text/... (plain,...)
application/... (PostScript,octet-stream,...)
Une description du fichier, entre crochets peut être ajoutée.
Exemple de 'message X3' :

From: sender@Sage.fr
To: receiver@Sage.com
cc: Copyto@Sage.com
Subject: Test d'envoi de message via le binaire meladx

Sage ERP X3
Test envoi x3
#<application/x3 ; name="_Msg0001.x3" [Regarde si ca marche]

0,1,3,0/tournesol/1801/X3BUG/GESAOB/1/OBJAOB/B/ACV~
# image/gif [La photo de Charlie] "/home/usrlocal/gepsi/images.gif/ngirl1.gif"
En ligne de commande DOS ou UNIX se positionner dans le répertoire /runtime/bin de
l'environnement avant de saisir la ligne de commande suivante :
Meladx -v -s « nom_serveur_messagerie » < « chemin + nom de fichier mail »
Le programme 'meladx' sera exécuté en mode trace et affichera les différentes étapes du processus
d’envoi du mail. Si le résultat est égal à : « connect : Erreur No 25 » cela veut dire que le port 25 n'est
pas ouvert. (Ou que le paramètre « nom_serveur_messagerie » n'est pas valide)
* Le chemin + nom de fichier mail correspond au nom du fichier généré par le Workflow Adonix. Son
nom est égal à Mxxx.txt, où xxx est un numéro d'ordre. Le fichier se trouve en standard dans le
répertoire /tmp du dossier.
Attention pour que le mécanisme de Workflow fonctionne avec le protocole SMPTP, le port 25 doit
être ouvert sur le serveur de messagerie.
8.11.4. Appel d’un Workflow dans un spécifique

Pour appeler le moteur de Workflow dans un programme spécifique deux modes sont disponibles :
Mode normal
Call WORKFLOW(TYPEVT,CODEVT,OPERAT,CLEOBJ) From AWRK
Avec
TYPEVT Integer Code de l’évènement de Workflow, valeur présente dans le menu
local 988. Correspond au champ type d’événement de l’onglet
général dans la définition des règles de Workflow.
CODEVT Char Code de l’événement. La valeur de ce champ est dépendante du
type d’événement. Cette valeur répond aux mêmes règles que
celles appliquées au champ code événement dans la définition
d’une règle de Workflow.
OPERA Char Code de l’opération. La valeur de ce code répond aux mêmes
règles que celles appliquées au champ Opérations dans la
définition d’une règle de Workflow.
CLEOBJ Char Clef de l’objet si le type d’événement est égal à Objet
Mode différé ou simulation

Call
WORKPLUS(TYPEVT,CODEVT,OPERAT,CLEOBJ,CODE,SIMUL,DIFFERE,TYPDEC,GRPDEB)
Avec
TYPEVT Integer Code de l’évènement de Workflow, valeur présente dans le menu
local 988
CODEVT Char Code de l’événement
OPERA Char Code de l’opération
CLEOBJ Char Clef de l’objet si TYPEVT = Objet
CODE char Code Workflow (cas du bouton W et du Workflow manuel
SIMUL Integer Réservé aux Workflow de type manuel

Sage ERP X3
Permet de simuler OU de générer un Workflow manuel

DEFFERE Integer Envoi du message en différé (transactions de
création/modification d'un objet)
TYPDEC Integer Type de déclenchement en modification d’un objet
Avant : 0
après mise à jour de la classe [F] : 1
GRPDEB Char Premier chrono groupe (utilisé pour l'envoi différé)
Dans les deux cas, le fichier trace doit être ouvert.

Sage ERP X3
8.12. LES LIENS DE WORKFLOW
8.12.1. Fonctionnement
L’action de signature peut être déclenchée par l’activation d’une URL présente dans le corps du
message qui est émis par le moteur de WorkFlow. Cela permet donc de signer un évènement de
Worlfow hors du contexte Sage X3. Ce Paragraphe présente les composants mis en œuvre, pour que
ce mécanisme fonctionne, ainsi que les prés requis de paramétrage.
Action de
l’utilisateur dans
sa Serveur WEB
Messagerie Sage X3
Serveur Batch
Sage X3
Tâche
Table de suivi AWRKSIG
des Workflow
L’URL présente dans le message reçu par l’utilisateur, pointe sur un serveur WEB Sage X3. Celui-ci
dépose dans un répertoire un fichier séquentiel contenant le N° de processus de Workflow à signer et
la réponse de l’utilisateur.
Ce fichier sera pris en compte par la tâche batch AWRKSIG qui effectue la mise à jour de
l’enregistrement de suivi du Workflow avec la réponse choisie par l’utilisateur.
Si le serveur WEB n’est pas actif l’utilisateur est avertit.

Si le serveur Batch ou la tâche de gestion des signatures AWRKSIG ne sont pas actifs. Les réponses
sont conservées dans un répertoire dédié qui sera exploité à la prochaine exécution de la tâche
AWRKSIG.

Sage ERP X3
Pré-requis
Pour utiliser les liens Workflow, un serveur X3 Web doit être mis en place et la solution utilisée doit
être publiée sur ce serveur. En effet le serveur de liens Workflow est un composant du serveur web
X3.
Les valeurs paramètres
WRKRMTDIR Répertoire Liens Workflow. Ce répertoire doit être accessible en écriture, par le
serveur WEB et par le serveur batch.
C:\Sagex3\WEBV5\WebData\WORKFLOW\
Conseil : Utiliser un répertoire de la solution comme WebData qui permet de

partager les données entre les deux composants serveur WEB & Batch.
WRKRMTHTTP Adresse Http Liens Workflow
Ce paramètre définit le serveur http utilisé pour recevoir des événements liés à
un clic sur un lien inclus dans un message envoyé par le Workflow.
Ce serveur http, configuré au préalable par la console d'administration, va

ensuite créer un fichier récupéré par la tâche batch AWRKLNKACT, qui traitera
l'action de retour.
Le fichier est défini sur un serveur identifié la variable WRKRMTMAC, dans un

répertoire dont la racine est donnée par le paramètre WRKRMTDIR
A partir de cette racine, on retrouve un répertoire par solution (défini par la
variable GINSTID), et un sous-répertoire par dossier.
Exemple : sagex3v5:18880/AdxWfC
Pour définir les attributs ce paramètre, il faut utiliser la console
Le premier attribut de cette URL étant le nom du serveur sur lequel la solution
X3 est publiée. Dans notre exemple c’est sagex3v5
Le second est numéro de port du serveur Apache, visible dans l’onglet

configuration des serveurs WEB de la console.
Le troisième est actuellement invariant avec la valeur AdxWfC.

Sage ERP X3
WRKRMTMAC Machine:Port Liens Workflow
Ce paramètre permet de définir le serveur et le numéro de port sur lequel un

service adonix est présent (par défaut, c'est le port courant), afin d'accéder au
répertoire ou sont stockées les fichiers réponse.
La syntaxe à utiliser est adresse_serveur:num
Par défaut, si aucun serveur n'est précisé, c'est le serveur d'application de la
solution Sage X3 qui est utilisé
Conseil : Laisser dans une première approche la valeur par défaut.
WRKSINTER Retour de workflow via internet. Ce paramètre permet de construire à l’émission

du message, L’URL qui pointera sur le serveur WEB chargé de traiter la
réponse.
Exemple : http://sagex3v5:18880
Pour définir ce paramètre, il faut utiliser la console
Le premier attribut de cette URL étant le nom du serveur sur lequel la solution
X3 est publiée. Dans notre exemple c’est sagex3v5
Le second est numéro de port du serveur Apache, visible dans l’onglet

configuration des serveurs WEB de la console.
WRKSINTRA Retour de workflow via intranet. Ce paramètre permet de construire à l’émission

du message, L’URL qui pointera sur le serveur WEB chargé de traiter la
réponse.
Remarques identiques à celles du paramètre WRKSINTER.
8.12.2. L'action à déclencher
On définit ensuite l'action à déclencher (Dictionnaire des actions). Cette dernière doit obéir à un
certain nombre de critères:
Elle doit être de type Traitements divers, c'est à dire qu'elle renvoie simplement vers un sous-
programme AGL qui ne contient aucune instruction d'affichage.
La case à cocher Workflow doit être activée.
L'action doit posséder 4 paramètres:

Sage ERP X3
Un paramètre de type Integer représentant un code retour, passé par adresse.

Un paramètre de type Char représentant un message de retour, passé par adresse.
Deux paramètres libres de type Char, passés par valeur.
Un exemple de liste de paramètres valide:
Dans cet exemple, une action XACTUSR est définie, de type Traitements divers
Action XACTUSR: Activation ou désactivation d'un utilisateur (flag Actif Oui/Non)

Paramètre Nom Type Type d'argument
RET Code retour Integer Par adresse
MES Message de retour Char Par adresse
CODUSR Code utilisateur Char Par valeur
ACTFLG Actif Oui/Non Char Par valeur
Cette action est utilisée pour donner la valeur 'Oui' (2) ou 'Non' (1) au flag 'Actif' (ENAFLG) d'un
utilisateur X3. C'est une action de type Traitements Divers qui exécute le sous-programme suivant:
###########################################################
# XACTAUS.src - Action XACTAUS
###########################################################
Subprog ACTAUS(RET, MES, COD, OPT)
Variable Integer RET
Variable Char MES
Value Char COD
Value Char OPT
Local File AUTILIS [AUS]

Trbegin [AUS]
Readlock [AUS]CODUSR = COD
[AUS]ENAFLG = val(OPT)
[AUS]UPDUSR = GUSER
[AUS]UPDDAT = date$
Rewrite [AUS]
Commit
If val(OPT) = 2
Call ECR_TRACE("User"-COD-"activated by"-GUSER, 0) From GESECRAN
Else
Call ECR_TRACE("User"-COD-"de-activated by"-GUSER, 0) From GESECRAN
Endif
End
8.12.3. La règle de Workflow
Pour insérer un lien action dans un message de Workflow, une ligne de texte (onglet Message) devra
être associée à l'action définie, et les deux paramètres libres (type Char, par valeur), devront être
renseignés.
On active un lien en donnant la valeur Oui à la colonne Lien Action.
Exemple:
Dans cet exemple, on crée une règle de Workflow sur l'objet AUS (Utilisateurs) pour l'événement
"Création". Lorsqu'un nouvel utilisateur X3 est créé, un e-mail est envoyé à l'administrateur du
système.
Texte Lien Action Param. 1 Param. 2

Action
"Utilisateur"-[M:AUS0]USR-"créé par"- Non

Sage ERP X3
GUSER
"Cliquer ici pour activer cet utilisateur": Oui XACTAUS [M:AUS0]USR "2"
"Cliquer ici pour désactiver cet utilisateur": Oui XACTAUS [M:AUS0]USR "1"
Dans cet exemple renseigne les deux paramètres "libres" de l'action (les deux derniers) par les
valeurs suivantes:
Le code utilisateur créé ([M:AUS0]USR) pour le paramètre CODUSR
La valeur 2 (Oui) ou 1 (Non) pour le flag 'Actif' de l'utilisateur (paramètre ACTFLG).
ATTENTION: Pour qu'une règle de Workflow puisse utiliser les liens action, elle doit obligatoirement
avoir un unique destinataire et ce dernier doit obligatoirement être un code utilisateur X3. On ne peut
envoyer de Workflow avec lien à un contact tiers externe ou à une adresse e-mail fixe (e.g.
"john.doe@sage.com").
La tâche batch à lancer
Du côté de l'application X3, une tâche batch, AWRKLNKACT, sera chargée de traiter les demandes
générées par le serveur Web lorsque les utilisateurs activent des liens Workflow.
Il faut définir un abonnement de cette tâche AWRKLNKACT, avec une fréquence à définir selon le
degré de synchronisation que l'on désire.
La tâche AWRKLNKACT ne requiert aucun paramètre, mais utilise les paramètres généraux décrits ci-
dessus (section 2).
8.12.4. Les liens dans le workflow
Lorsqu'un nouvel utilisateur X3 est créé, la règle de Workflow est déclenchée et un message de ce
type est envoyé au destinataire:
Utilisateur NEWUSR créé par JDOE
Cliquer ici pour activer l'utilisateur:
http://appsrv/AdxWfC/action.jsp?C=161&K=5S2jvu&L=FRA&D=V140X3DEMO
Cliquer ici pour désactiver l'utilisateur:
http://appsrv/AdxWfC/action.jsp?C=162&K=xIfIPp&L=FRA&D=V140X3DEMO
Lorsque l'utilisateur destinataire clique sur l'un des liens, un fichier est créé par le serveur web dans le
répertoire de travail (défini par le paramètre WRKRMTDIR, cf. section 2).
Ce fichier est ensuite traité par la tâche AWRKLNKACT, qui va générer la trace suivante:
16/03/07 17:23:06 Activation requête (51000)
Nombre de fichiers action à traiter: 1
Traitement fichier lien: 161

User NEWUSR activated by ADMIN
16/03/07 17:23:06 Requête terminée (00000)
Cette action va valider l'utilisateur NEWUSR en activant le flag ENAFLG lié à l'enregistrement de cet
utilisateur. Elle sera signée (via les champs UPDUSR, UPDDAT) par l'utilisateur destinataire du mail
de Workflow (ADMIN).
D'autre part, le mécanisme de trace peut être attaché à la règle (tout comme à toute règle de
Workflow). Lors de la visualisation des éléments dans le moniteur de Workflow, la colonne 'Liens'
sera cochée pour les événements de Workflow ayant déclenché une action de lien.

Sage ERP X3
9. LA GESTION DE LA DOCUMENTATION
9.1. INTRODUCTION
Cette nouvelle fonctionnalité permet de personnaliser la documentation livrée en standard ou de
développer la documentation sur les développements spécifiques. Cette fonction est intégrée au
progiciel et est basée sur l’organisation des entités X3.
L’entité de départ d’une documentation est la fonction X3 (AFC) à laquelle la documentation est
rattachée. Les principaux composants d’une fonction peuvent faire l’objet d’une documentation
particulière (Action, Ecran, Table etc..)
L’organisation de la documentation est basée sur celle du dictionnaire X3. Une documentation peut
être basée sur une table de liens permettant d’associer des compléments documentaires.
Les éléments structurants d’une documentation sont :

- Le code de la langue
- Le type d’entité X3 documenté
- Les composants associés.
9.1.1. Outils de base

Les outils de base permettent la génération d’un squelette de documentation et une gestion
automatique des paragraphes.
Une utilisation des textes du dictionnaire
Un éditeur HTML générant du XHTML
Une gestion des documentations spécifiques avec des codes activité
L’aide en ligne décrit précisément les différentes structures de documentation qui peuvent être
produites. Avant de débuter l’écriture d’une documentation, consultez cette aide, afin de choisir la
structure adaptée à la documentation à mettre en œuvre.
9.1.2. Les prérequis de mise en œuvre

Dans la fiche utilisateur X3 du développeur de la documentation, les deux paramètres du groupe DOC
lié au chapitre Superviseur doivent être renseignés.
DIRDOC : Nom du répertoire destinataire de la documentation qui sera générée. Si ce répertoire est
situé sur le poste client préfixer le chemin d’accès des caractères #@. Si le chemin d’accès contient le
caractère % celui-ci est remplacé par la valeur du code de la langue dans laquelle la documentation
est générée.
DOCDOSS : Nom du dossier de référence documentaire. Le générateur de documentation parcourt le

dictionnaire des données pour produire automatiquement la documentation. Cette variable permet de
différencier le dossier contenant la documentation du dossier contenant les éléments documentés.
9.2. L’ORGANISATION DE LA DOCUMENTATION

L’organisation d’une documentation doit respecter celle des entités X3. Par exemple pour documenter
l’ensemble des composants d’une nouvelle fonction (AFC) on doit documenter les nouveaux
composants utilisés ou rattacher la documentation existante des composants utilisés par la nouvelle
fonction.

Sage ERP X3
- Les actions
- Les écrans
- Les codes activité
- Les tables
- Etc..
Une attention particulière doit être portée aux éléments communs à plusieurs fonctions.
9.2.1. Les paragraphes de documentation

La documentation X3 est organisée en paragraphes. Un paragraphe est composé d’un squelette
décrivant l’organisation hiérarchique des textes élémentaires qui le constituent. La description de la
structure du paragraphe est mémorisée dans la table ADOCUMENT. Un paragraphe est accessible
directement par l’aide en ligne. Exemple de paragraphe
- Aide sur une fonction
- Aide sur une édition
C’est la compilation de cette structure hiérarchique avec les textes associés qui permet au générateur
de documentation de produire les textes XHTML.
Ces paragraphes peuvent être générés automatiquement en fonction de la typologie qui lui est
associée (fonction / code activité …)
Conseil : Pour générer les paragraphes d’une fonction accéder au dictionnaire des fonctions, et utiliser
dans la barre des menus « Documentation »
Développement > Dictionnaire traitements > Fonctions
Développement > Dictionnaire données > Documentation > Documentation

Sage ERP X3
La clef de la fiche d’un paragraphe est constituée du code langue, du type de documentation et du
code, ainsi que d'un niveau et d'un sous-niveau qui permettent d'organiser des tables des matières
intermédiaires dans la documentation
9.2.2. Attributs d’une documentation
Le code langue
Le type de document. En général le type de document est identifié par le type de l’objet X3
documenté.
Le code qui correspond à ce qui est documenté : le code de la fonction, le code du paramètre, le code
activité, le code de la pièce automatique...
Un niveau et un sous-niveau, qui décrivent les imbrications de paragraphes. Le titre du premier
paragraphe de chaque niveau est repris dans une table des matières qui permet de pointer
directement sur des sections de documentation. Lorsque plus d'un paragraphe existe dans un sous-
niveau donné, une sous-table des matières est créée pour les niveaux correspondants. La génération
automatique depuis le dictionnaire crée les fiches avec des niveaux et sous-niveaux.
Un code paragraphe qui détermine la façon dont le texte HTML va être généré. Cette génération
peut se faire par simple copie du texte saisi dans la fiche, ou par une mise en page plus élaborée
(inclusion d'éléments du dictionnaire sous forme de tableaux avec des liens hypertextes, par
exemple).
Un code écran, qui définit si on doit insérer, dans le bandeau du paragraphe correspondant, une
icône permettant de déplier l'aide sur champ relative à l'écran donné.
Un code activité, hérité du dictionnaire lors de la régénération, qui permet de faire notamment la
distinction entre fiches standard et spécifiques, mais aussi de créer des documentations adaptées à
des dossiers donnés en ne générant que les paragraphes et les documentations correspondant aux
codes activité activés sur le dossier. Il est à noter que le code activité FAL (toujours faux) est pris en
compte de façon particulière : un paragraphe marqué de ce code n'est jamais pris en compte par le
traitement de génération, même si on demande une génération complète. Ceci permet de désactiver
des paragraphes générés que l'on ne désire pas trouver dans une documentation.

Sage ERP X3
9.2.3. Les types de documentation
Type Elément documenté Génération Source du dictionnaire X3 Accès

ACN Consultation Oui Dictionnaire des consultations
ACT Code action Oui Dictionnaire des actions
ACV Code activité Oui Table des codes activité Alt F1
ADC Points d'entrée Oui Dictionnaire des traitements Alt F1
ADM Variable de dimensionnement Oui Table des variables Alt F1
ADP Paramètres Oui Dictionnaire des paramètres Alt F1
ADV Tables diverses Non Dictionnaire des tables diverses
AD Langage Non Mots-clés du langage
AFC Fonctions du progiciel Oui Table des fonctions F1
AM Modèles de développement Non
AML Menus locaux Oui Table des messages
AOE Modèle d'import/export Oui Table des modèles Alt F1
APM Menus Oui Table des fonctions
ARP Etats Oui Dictionnaire des états Alt F1
ATB Tables Oui Dictionnaire des tables
ATY Types de données Oui Table des types de données
AWA Règles de Workflow Oui Table des règles de Workflow Alt F1
CDA Destinations comptables Oui Table des destinations Alt F1
CDE Sections par défaut Oui Table des sections par défaut Alt F1
DI Documentations diverses Non *1
DL Delta développement Non *1
FI Fichiers liés Non Marqueur de fichiers liés
GAU Pièces automatiques Oui Table des pièces automatiques Alt F1
PS1 Déclencheurs statistiques Oui Table des déclencheurs Alt F1
*1 : Les types de documents DI et DL sont prévus pour documenter les personnalisations des
fonctions standard ou gérer les documentations techniques.

Sage ERP X3
9.2.3.1. Squelette de la documentation d’une fonction (AFC)
La documentation d’une fonction est la plus complète car elle englobe l’ensemble des entités.
Paragraphe Niveau / sous Niveau Intitulé

TIT 10,10 Titre
PRE 10,20 Présentation
PRQ 30,10 Pré-requis
ACV 30,20 Codes activité
ADP 30,30 Paramètres concernés
ANM 30,40 Compteurs
GAU 30,50 Pièces automatiques
CDE 30,60 Sections par défaut
HAB 30,70 Habilitations
TRS 30,80 Transactions de saisie
GTC 30,80 Ecrans de consultation
PRD 30,90 Pré-requis divers
ECR 40,50 Gestion de l'écran
ENT 40,100 En-tête
ON1... 40,200*rang Onglet no 1...
40,suivant
BOT... Clics droits sur ligne de tableau
précédant.+5...
BOU 70,10 Introduction boutons
BOU 70,10+10*no Boutons sur fenêtre
BME 80,10 Introduction items de menus
BME 80,10+10*no Items de menus dans la barre
Item de menu pour gérer la documentation. Si la fonction
est de type objet et le code de l'objet présent dans la table
diverse 910, une entrée de menu Documentation est
INC 80,500 / 80,510 / 80,520 créée automatiquement. Pour tenir compte de la présence
de cette entrée, on réalise un lien vers les 3 paragraphes
correspondants, tels qu'ils sont définis dans la
documentation annexe ADO_FCT
ARP 50,10 Etats
ABT 60,10 Tâche batch
ERR 90,10 Erreurs
ATB 100,10 Tables mises à jour
La fonction de génération peut être utilisée lors de la définition d’une nouvelle documentation pour
générer son squelette. L’aide en ligne présente pour chaque type de documentation les squelettes
générés par défaut.
Pour inhiber la génération d’un élément du squelette d’une documentation, il faut utiliser le code
activité FAL.
Pour un document paragraphe TIT doit être unique, en cas de doublon c’est le dernier lu qui est utilisé
lors de la génération.

Sage ERP X3
Les intitulés des premiers paragraphes des différents niveaux sont utilisés pour générer le sommaire
de la documentation. La documentation des onglets d’une fenêtre est liée au rang des onglets dans la
fenêtre de l’onglet qui varie de 1 à 15.
Les différents codes des paragraphes sont déclarés dans la table diverse 911. Le squelette sera
généré en fonction des entités trouvées dans le dictionnaire.

Sage ERP X3
9.3. L’AIDE SUR LES CHAMPS

Les aides sur les champs sont saisies dans un environnement dédié et mémorisées dans la table
ADOCFLD. Cette séparation de ce type documentation permet la réutilisation de cette documentation
quelque soit la fonction X3 qui utilise le champ.
Développement > Dictionnaire données > Documentation > Documentation sur champs
Les documents HTML liés à ce type de documentation sont générés par la fonction de génération
documentaire, en utilisant la case à cocher Aide sur champ et en précisant la fourchette des champs
concernés.

Sage ERP X3
9.4. L’EDITEUR HTML
9.4.1. Fonctionnement
Un éditeur spécifique est disponible pour permettre la saisie des textes de la documentation qui sont
conservés dans la table ADOCCLB.
Icône Fonction Exemple

Création d'un paragraphe Texte.
Création d'un titre Texte
Création d'un sous-titre Texte

Texte gras ou normal Texte
Texte italique ou normal Texte
Texte souligné ou normal Texte
Alignement gauche Texte
Alignement centre Texte
Justification Texte
Alignement droit Texte

Sage ERP X3
Icône Fonction Exemple

Texte 1
Liste
Texte 2
Décalage droit Texte
Annulation d'une action décalage droit Texte
Création d'un lien hypertexte Texte
Image
Bouton
Texte Texte
1 2
Tableau
Texte Texte
3 4
Nettoyage sélectif du HTML
Affichage et modification de la source HTML
Alerte indiquant un problème dans le html. Permet de visualiser et de
modifier le code html produit.
9.4.2. Boutons boîte de dialogue
Enregistrer la saisie
Annuler la saisie
9.4.3. Les raccourcis clavier
Enter Création d'un paragraphe

Shift/Enter Création d'une nouvelle ligne
Ctrl/c Copier
Ctrl/v Coller
Ctrl/x Supprimer
Ctrl/a Sélectionner tous les éléments
Ctrl/z Annule l'action précédente
Double clic suivant objet

Sage ERP X3
9.4.4. Import des textes HTML

Par copier / coller, il est possible d’importer le contenu d’une page WEB dans la documentation X3.
Après l’opération coller, il est indispensable d’effectuer une opération de nettoyage du code HTML
importé à l’aide du bouton .
Il est possible de saisir directement le code HTML à l’aide de l’éditeur accessible par le bouton
Les balises autorisées sont :

<P> Paragraphe
<UL> Début de liste
<LI> Ligne de liste
<TABLE> Tableau
<TR> Ligne de tableau
<TD> Cellule de tableau
<IMG> Image
<A> Lien hypertexte
<H4> Titre
<H5> Sous-titre
<STRONG> Gras
<EM> Souligné
<DIV> Conteneur
<TBODY> Conteneur de ligne de tableau
<BR> Ligne suivante d'un paragraphe
<CODE> Paragraphe de type code source

Sage ERP X3
9.5. LES LIENS DE DOCUMENTATION

Pour enrichir une documentation, une fonction permet de gérer des liens de documentation entre cette
documentation et des éléments du dictionnaire. Ces liens sont conservés dans la table ADOCFNC et
sont utilisés lors de la génération de la documentation HTML.
Les liens possibles sont dépendants du type de document auquel on désire rattacher des éléments du
dictionnaire.
Développement > Dictionnaire données > Documentation > Liens de documentation
Un lien possède les attributs suivants :
- Type de l’élément du dictionnaire rattaché (Exemple Table, Code activité …)

- Description du type de lien
- Clef du lien

Sage ERP X3
9.5.1. Relations autorisées pour une fonction

La documentation d’une fonction peut être enrichie par les liens suivants :
Lien Signification Utilisation lors de la génération de documentation compl.

ACV Code activité Liste des codes activités concernés dans les pré-requis. Oui
Paramètres concernés dans les pré-requis.
Il est à noter que ce lien est aussi utilisé pour alimenter la section
ADP Paramètre Non
Fonctions concernées dans l'aide décrivant le paramètre. Il n'est donc
pas utile de renseigner le lien réciproque si le lien direct est défini.
ANM Compteurs Liste des compteurs associés à la fonction dans les pré-requis. Non
Pièces Liste des pièces automatiques associées à la fonction dans les pré-
GAU Non
automatiques requis.
CDE Codes section Liste des codes section associés à la fonction dans les pré-requis. Non
Liste des fonctions permettant de définir des transactions pour la
TRS Transactions Non
fonction documentée.
Tables
ADI Liste des tables diverses dans les pré-requis fonction. Non
diverses
AML Menus locaux Liste des menus locaux à paramétrer dans les pré-requis. Non
ARP Etats Etats lancés depuis la fonction. Oui
ABT Tâches batch Annexe des tâches batch permettant de lancer la fonction. Oui
ATB Tables Tables mises en œuvre dans la fonction. Oui
Les relations autorisées sont déclarées dans la table diverse 913

Sage ERP X3
9.6. LA GENERATION DE LA DOCUMENTATION
Cette fonction est utilisée :

- pour générer le squelette d’une documentation
- pour générer les aides sur champs
- pour générer une documentation
Développement > Dictionnaire données > Documentation > Documentation

Bouton « Génération »
Toutes langues :
Langue : Choix de la langue dans laquelle la documentation doit être générée
Type : Type du document à générer
Code de à : Fourchette de sélection des entités documentaires à générer
Génération ADOCUMENT : menu de sélection du squelette de la documentation

Non : pas de génération
Toutes : Tous les paragraphes liés au type de document sont générés
Documentation existante :

Sage ERP X3
Génération document final

Non : pas de génération
Complètes: Génération de l’ensemble de la documentation
Selon code activité
Aides sur champs liés

Cette option permet de générer les aides sur les champs liées aux masques inclus dans la fonction
ou l’action dont on génère la documentation. Les codes des aides sur les champs sont déclarés dans
l’objet de définition des masques (colonne aide).
Aide sur champs

Option de génération des aides sur les champs, indépendamment des liens avec les masques.
9.6.1. Les répertoires des documents générés

FCT Documentation sur les fonctions
FLD Documentation sur les aides sur champs
MCD Documentation sur les tables

Documentation sur les menus locaux
OBJ Documentation sur :

- les actions (ACT),
- les types de données (ADP),
- les états (ARP),
- les sous programmes (ASU),
- les codes activité (ACV),
- les points d’entré (ADC),
- les variables de dimensionnement (ADM)
- les variables globales (AGB)
- les modèles d’import export (AOE)
- Etc..
MODEL Documentation technique sur les modèles Sage X3
L4G Documentation technique sur le langage Sage X3
INSTALLATION Documentation sur la mise en œuvre d’un dossier Sage X3
CONSOLE Documentation sur l’utilisation de la console SAGE X3
9.7. PUBLICATION DE LA DOCUMENTATION

Les éléments de documentation peuvent être transférés dans un nouveau dossier soit à l’aide de la
fonction de copie disponible sur les trois fenêtres de gestion des objets documentaires, soit par
l’intermédiaire d’un patch en utilisant les entités ADO et ADF.
Les éléments de documentation générés (les pages HTML) doivent être transférés dans le répertoire
de publication de la documentation. Ce répertoire est déclaré lors de l’installation dans la console
Sage X3.

Sage ERP X3

Sage ERP X3
10. LES OUTILS DU SUPERVISEUR
10.1. INTRODUCTION
Ce chapitre présente plusieurs ensembles de fonctions permettant d’administrer à partir d’X3 les
éléments d ‘un dossier. Certaines permettent de se substituer à des fonctions techniques et
nécessitent des connaissances d’administrateur Base de données ou Système. Ils font pour la plupart
partie du développement
Ces fonctions peuvent avoir des incidences sur la cohérence de la base ou du dossier. Elles sont
donc à manipuler avec précaution.
- Maintenance (mode fiche, maintenance en colonne, transactions système)
- Vérifications (Infos version, Vérification cohérence, Symboles et traitements verrouillés)
- Utilitaires dictionnaire (copies, génération et validations, comparaisons)
- Remise à zéro dossier
- Gestion mono/multi, déverrouillage
- Recherches
- Extraction / Intégration
- Optimisations de la base (Etat des tables, Recherche index, Analyse mémos, Optimisation
base de données)

Sage ERP X3
10.2. OUTILS DE MAINTENANCE

Ces outils permettent d'accéder aux données contenues dans la base X3 :
- sans aucune forme de contrôle
- Maintenance en lignes : Accès aux enregistrements d'une table un par un.
- Maintenance en colonnes : Accès aux enregistrements sous forme de tableaux.
- Transaction système : Mise à jour massive des données d’une table
Ces fonctions sont des outils dangereux, dont l’usage doit être réservé à l'installateur du logiciel.
Remarque :
Une trace des champs modifiés par les maintenances en ligne, en colonne la trace des transactions
système lancées est gardée dans le fichier espion.tra. Ce fichier contient également d’autres lignes
numérotées afin de permettre la vérification de son intégrité. En cas de gros problème, il est
recommandé de le tenir à la disposition de la hot-line, qui pourra, par son analyse, mieux comprendre
ce qui a pu se passer sur un dossier.
Dans le cas d’une transaction système, on retrouvera dans cette trace un numéro séquentiel, le code
utilisateur, la date et l’heure, le code transaction, le nombre d’enregistrements touchés, le détail des
formules de sélection et des formules de modification.
Dans le cas d’une modification par une fonction de maintenance, on retrouvera dans cette trace un
numéro séquentiel, le code utilisateur, la date et l’heure, la table concernée, la clé, la nature de
l’opération Création / Modification /Suppression…) et, en cas de modification, une ligne par champ
modifié, avec la valeur avant et après modification.
10.2.1. Maintenance par enregistrement

Cette fonction permet d’accéder en création, modification ou suppression à un enregistrement d’une
table de la base de données.
Développement > Utilitaires > Maintenance > En ligne
Le choix de la table permet de visualiser et de modifier un ou plusieurs champs de l’enregistrement

affiché
Aucun contrôle n’est effectué sur les opérations réalisées. Une trace de ces opérations est mémorisée
dans la table AESPION

Sage ERP X3
10.2.2. Maintenance en colonnes

Cette fonction est similaire à la précédente. Elle se décompose en étapes.
Développement > Utilitaires > Maintenance > En colonne
La première colonne permet de sélectionner les rubriques de la table qui seront :

- Affichées
- Saisissables
- Invisibles
Et de définir un éventuel critère de sélection.
L’utilisateur peut effectuer une saisie sur plusieurs colonnes puis enregistrer ses modifications dans
une seule transaction.

Sage ERP X3
10.3. OUTILS DE VERIFICATION
10.3.1. Infos version

Cette fonction est accessible à partir de l’aide en ligne dans la barre de menu avec le choix
? / A propos
Elle donne les numéros de version du poste client, de serveur d’application et du serveur de
traitement.
Le bouton informations techniques permet de visualiser les informations concernant la licence Sage
X3.
Remarque :
Les informations techniques et les niveaux de version des composants de la solution sont
nécessaires à la Hot Line ainsi que le niveau exact de patch

Sage ERP X3
10.3.2. Surveillance des services
Les services nécessaires au bon fonctionnement des composants de la solution Sage X3 sont gérés à
l’aide de la console. Le cours sur l’installation présente ce composant. A partir de l’application Sage
X3 une fonction de surveillance permet de visualiser les principaux chemins d’accès permettant de
gérer le serveur de traitement Sage X3.
10.3.3. Vérification de cohérence

Cet utilitaire parcourt toutes les tables du dictionnaire et vérifie l'intégrité référentielle des liens
(existence des enregistrements liés pour chaque ligne de la table).
L'exécution de cet utilitaire peut être très longue : il est conseillé d'utiliser les bornes de tables et/ou de
limiter par module.
Développement > Utilitaire > Vérification > Données > Cohérences

Sage ERP X3
Cet utilitaire est en général lancé de façon très ciblée, par exemple après une opération de
maintenance. Il produit une trace pour chaque table à analyser.

Sage ERP X3
10.3.4. Symboles et traitements verrouillés
Le message d’erreur en gestion d’objet se produit lorsqu’une fiche déjà en cours de modification par
ailleurs est modifiée par un autre utilisateur. La clé apparaît alors en bas de l’écran. Un double clic sur
la clé affiche le détail (utilisateur et poste).
Les symboles applicatifs sont gérés par les instructions Lock et Unlock dans la table APLLCK contient
les informations suivantes :
- Un symbole qui est défini par la concaténation du code objet et de la clé
- Un indice qui vaut toujours 0
- Un numéro qui identifie la session (c’est la valeur de adxuid(2) pour la session qui verrouille
le symbole).
Le message d’erreur en gestion de traitements apparaît lorsqu’on saisit un nom de traitement qui est
déjà en cours de modification. Le traitement est quand même affiché, le symbole de verrouillage étant
affiché en haut du texte.
10.3.5. Symboles verrouillés

Des verrous logiques sont posés par les traitements avant de d’effectuer un verrou de type base de
données. Cette fonction permet de consulter les verrous logiques actifs. (table APLLCK)
Développement > Utilitaires > Vérifications > Symboles vérouillés
Un zoom est possible de cette fonction vers la gestion des sessions

Sage ERP X3
En gestion d’objet, le symbole verrouillé correspond au code de l’objet, suivi de la clé courante (dans
l’exemple ci-dessus, la facture d’achat (PIH) AVF0904ASN00001 est verrouillée par l’utilisateur
ADMIN
10.3.6. Traitements verrouillés
Développement > Utilitaire > Vérification > Verrous > Traitement verrouillés
Cette fonction concerne les traitements source verrouillés par un développeur.
Une suppression du verrou est possible (par clic droit)
10.3.7. Analyse des mémos
Développement > Utilitaire > Vérifications > Analyse mémos
En gestion d'objet, chaque utilisateur peut poser, par l'intermédiaire du menu Sélection / Sélection
avancée, des filtres destinés à sélectionner dans la liste gauche une partie seulement de la table. Une
telle sélection peut ensuite être mémorisée, et réutilisée régulièrement.
Cette fonctionnalité intéressante est néanmoins source de problèmes potentiels de performance

lorsque les tables ainsi filtrées sont très volumineuses (plusieurs centaines de milliers de lignes). Elle
l'est d'autant plus que ces mémos peuvent être standard (chargés dès que l'utilisateur entre dans la
fonction), et globaux (Utilisés par un ensemble d'utilisateurs).
La fonction d'analyse permet, a posteriori, de détecter des problèmes potentiels de performance

compte tenu des mémos posés par les utilisateurs dans un dossier. Attention, elle ne donne que des
indications, une analyse effective des mémos incriminés doit être réalisée avant de les modifier.
Il est néanmoins prudent de vérifier, pour chaque ligne de trace ainsi trouvée, la pertinence du
message d'erreur, en prenant des mesures correctives. Ces mesures peuvent être:

Sage ERP X3
- suppression du mémo correspondant ou avertissement à l'utilisateur

- ajout d'un index d'optimisation si celui-ci paraît adapté
- restriction sur un mémo public
Le paramètre superviseur SELWARN du groupe PRF, définit un nombre de lignes limite dans une
table. Au-dessus de ce nombre de lignes, l’enregistrement d’une sélection non performante est refusé
ou provoque un avertissement selon la valeur du paramètre superviseur AUZMEMO
Il est à noter que deux paramètres, mentionnés ci-dessous, permettent de contrôler a priori les
mémos créés par les utilisateurs. Mais ces mémos ne sont contrôlés qu'à leur création. Or des mémos
jugés performants à l'origine peuvent très bien ne plus l'être quelques mois après, si la volumétrie de
la base les rend lourds à l'exécution. C'est pourquoi il est intéressant de lancer cet utilitaire même si
les deux paramètres ci-dessous sont correctement renseignés.*
Afin d'obtenir ce résultat, le traitement lit tous les fichiers mémos présents sur le dossier, rapproche
les critères utilisés des différents index existant sur la table (y compris les index d'optimisation), et
pose un diagnostic en tenant compte du nombre de lignes présents dans la table.
Après la saisie des critères d’analyse une trace est affichée avec les mémos à analyser
Si AUZMEMO vaut Oui, il y a juste un avertissement à la création du mémo.

Il est à noter qu’un utilisateur ayant le profil de l’administrateur ne se verra pas interdire une sélection,
mais recevra un message d’avertissement.
Sont considérées comme posant potentiellement des problèmes de performance les sélections
suivantes :
- Celles pour lesquelles aucun champ n’est présent en première partie d’un index
- Celles qui font intervenir plusieurs tables liées
- Celles qui intègrent des opérateurs ou
- Celles qui intègrent des expressions
Les paramètres de taille permettent de classer les problèmes potentiels dans un ordre de gravité
décroissant. Dans l’exemple donné dans l’écran ci-dessus, au-dessus de 50.000 lignes dans une

Sage ERP X3
table, un problème est considéré comme critique, en dessous de 5.000 lignes aucun avertissement
n’est donné, entre 50.000 et 20.000 le problème est considéré comme un problème de performance
réel, entre 20.000 et 5.000 il est considéré comme mineur.
10.3.8. Etat des tables

Cet outil permet de vérifier les caractéristiques de chaque table de la base de données. Il permet de
constater si des tables ont été mal dimensionnées lors de la création du dossier. Avec les dernières
versions de moteurs de base de données Oracle et SQL Server, les problèmes de dimensionnement
sont plus rares.
Cet outil peut être utile pour vérifier le contenu des tables et estimer la durée d’un patch avant de
l’exécuter et alerter le DBA d’une demande d’extension des tablespaces
Développement > Utilitaires > Vérifications > Base de données > Etat des tables
Remarque :
Il est utile de lancer cet utilitaire de temps en temps pour vérifier l’état de la base, tout particulièrement
si des variations de volumétrie importantes ont été faites sur la base, ou si les temps de réponse ont
subi des variations à la baisse.
On retrouve les tables pouvant poser des problèmes en couleur dans l’écran ci-dessous :
En rouge le nombre de lignes réel de la table supérieur à 3 fois le nombre prévu à l’origine
En vert le nombre de lignes réel de la table inférieur ou égal à 3 fois la taille prévue, mais plus de 30
extents sur les données ou sur les index (oracle).
Il est ensuite du ressort de l’administrateur de base de prendre les mesures nécessaires

- Redimensionnement de la table,
- Extension de tablespaces,
- Mise en place de fichiers de configuration pour certaines tables
- …

Sage ERP X3
10.3.9. Recherche des index

Le dictionnaire des tables décrit des index dont Sage X3 se sert fréquemment. Ils définissent des
ordres de recherche et des critères de sélection privilégiés. Ils sont utilisés par les programmes
standards.
A l’exécution des requêtes :
- La base reçoit les critères de sélection et de tri
- Elle se sert des index s’ils existent réellement
- Mais est tout de même capable de répondre à la requête si les index n’existent pas… au
détriment de la charge machine et des temps de réponse…
Il arrive que des index soient déclarés, mais non créés, si une revalidation de la table n’a pas été faite
ou si un incident (pas assez de place sur un tablespace) empêche leur création
Cet utilitaire permet de vérifier si les index sont bien présents
Remarque :
Cet utilitaire est l’un des premiers à lancer en cas de dégradation brutale et importante des
performances de la base, particulièrement à la suite de passage de patchs ayant changé la structure
d’une table, ou après revalidation de dossier. En effet, si les traces d’erreur n’ont pas été
soigneusement vérifiées, il est possible qu’un message d’erreur non bloquant de type Création d’index
impossible n’ait pas été relevé.
Le résultat de cette trace donne non seulement les index définis dans le dictionnaire, mais non
présents sur la base, mais aussi les index présents sur la base non décrits dans le dictionnaire
(notamment les index d’optimisation utilisés), et les index définis selon une norme différente de celle
utilisée par le moteur Sage X3. Ces deux dernières catégories ne posent pas de problème de
performance.

Sage ERP X3
Ci dessus un exemple de trace généré par le traitement

Sage ERP X3
10.4. OPTIMISATION BASE DE DONNEES

Sage X3 crée automatiquement la base de données en :
- Dimensionnant les tables à partir d’une taille prévue à l’origine
- Tenant compte de fichiers de configuration
- Créant les index nécessaires à un fonctionnement normal
Mais, dans le temps, les performances peuvent être affectées :

- Par une évolution de la volumétrie différente de ce qui était prévu
- Par l’utilisation de sélections mémorisées sur des tables importantes
- Par la mise en place de filtres rôle sur des tables importantes
- Par des incidents d’exploitation (non création d’un index standard)
Des outils de diagnostic et de paramétrage vont permettre d’y remédier
10.4.1. Propriété de la base de données

Développement > Utilitaire > Vérifications > Base de données > Propriétés
Cette fonction permet, par des requêtes sur des tables et vues du système, de donner des
informations techniques sur la base de données. L'interprétation des résultats donnés par cette
fonction est du ressort d'un administrateur de bases de données, et peut dépendre de la version de
base de données utilisée.
10.4.2. Processus Base de données

Cet outil est à utiliser si l’on constate des disfonctionnements de l’application. Il permet de consulter
les processus d’accès à la base de données actifs et les verrous posés sur des ressources de la base
de données.
Développement > Utilitaire > Vérifications > Base de données > Processus

Sage ERP X3

Sage ERP X3
10.5. OPTIMISATION BASE DE DONNEES

Des filtrages de données peuvent être définis par paramétrage sur des tables importantes :
- Par des sélections mémorisées
- Par des filtres
- Par l’utilisation de codes d’accès
- Les requêtes liées peuvent être d’autant plus lourdes :
- Qu’elles sont fréquemment lancées
- Qu’aucun index standard n’est adapté pour leur optimisation
- On peut alors créer des index supplémentaires dans la base :
- Activables ou désactivables à la demande
- Sur des champs indicés (ce qui est impossible dans le standard)
Remarque :
Le mieux étant l’ennemi du bien, il faut créer ce type d’index avec mesure, et de préférence après
avoir pris l’avis d’un administrateur de base de données.
Paramétrage > Exploitation > Données > Optimisation base de données
Les index d’optimisation standard sont livrés lorsque des cas de paramétrage connus mais peu
fréquents peuvent poser des problèmes de performances (un index standard pour tous serait trop
pénalisant).
Il s’agit bel et bien de paramétrage (pérenne). Ceci signifie que de nouveaux index d’optimisation ne
sont livrés, au cours des versions, que dans le dossier de référence (et en aucun cas par voie de
patch).
Le fait d’activer un index de ce type ne suffit pas. Il faut :

Soit utiliser le bouton Exécuter
Soit revalider les tables sur lesquelles un tel index a été mis en place (ou supprimé).
Développement > Utilitaire > Vérifications > Base de données > Processus

Sage ERP X3
10.5.1. Statistiques base de données

Cet utilitaire permet de vérifier si les statistiques de la Base de données sont actives pour une table ou
un ensemble de table.
Développement > Utilitaire > Vérifications > Base de données > Statistique
Pour une table, la modification de la colonne A traiter et l’activation du bouton GENERER active le
script base de données prévu pour générer les statistiques.
Dans certains cas pour les éditions Crystal Report l’absence de statistiques Oracle dégrade fortement
le traitement d’édition. Il peut donc être nécessaire de recalculer les statistiques sur les tables utilisées
par ces éditions.
Attention, ce type de fonction facilite, via une interface utilisateur homogène avec le progiciel, le
lancement de procédures d'exploitation dévolues à un administrateur de base de données.
Pour être utilisée avec profit, elle suppose donc une connaissance préalable du fonctionnement des
bases de données et de leur optimisation.
A contrario, une utilisation inappropriée de la fonction peut poser de sérieux problèmes de

performances et mettre en péril la sécurité de l'exploitation du progiciel.
Selon la base de données utilisée, se reporter à l'aide correspondante:

- Statistiques Oracle
- Statistiques Sql Server
Attention, ce type de fonction est dévolu à un administrateur de base de données. Elle est faite pour
être lancée par un DBA.

Sage ERP X3
10.6. UTILITAIRES DICTIONNAIRE
10.6.1. Validation
Cette fonction permet de valider en masse un ensemble d'éléments du dictionnaire. C'est-à-dire de
générer le code ou de mettre à jour la base de données conformément aux informations du
dictionnaire. Ces éléments du dictionnaire peuvent être définis par des cases à cocher et par des
bornes de noms.
Cet utilitaire permet donc de réaliser les opérations identiques à la fonction de validation de dossier,
mais de façon plus sélective et donc plus rapidement.
Développement > Utilitaire > Dictionnaire > Validation > Dictionnaire
La validation du dictionnaire permet de s’assurer que les éléments techniques issus des différentes
générations de code sont en phase avec le dictionnaire. Par exemple, si un type de données a été
modifié, on peut s’assurer que tous les écrans, fenêtres, tables l’utilisant vont être remis à jour.
La validation forcée duplique temporairement les tables et les recopie avant de les renommer, en
appliquant les règles de dimensionnement définies soit par défaut, soit dans le fichier de configuration.
Il est en outre possible de filtrer uniquement les éléments concernés par leur appartenance à un
module, par un type de données (si celui-ci a changé, par exemple), ou un code activité donné. Enfin,
contrairement à la validation de dossier, qui va réaliser le travail dans toutes les langues dans
lesquelles le dossier est géré, il est ici possible de ne choisir qu'une seule langue.
Il est fortement conseillé aux utilisateurs connectés sur le dossier de se déconnecter. Cet utilitaire
peut être amené à modifier la structure des tables, ou à modifier des écrans qui sont en mémoire d'un
processus encore actif.
L’exécution de cette fonction peut être long, et peut être réalisé en batch à l’aide de la tâche standard
VALDICO. Un fichier trace est créé dans tous les cas. On y retrouve le détail des opérations
effectuées, et des erreurs éventuelles. Il est conseillé de lire attentivement ce fichier lorsque
l'opération est terminée
10.6.2. Copie dictionnaire
Développement > Utilitaire > Dictionnaire > Copie > Dictionnaire

Sage ERP X3
Cette fonction permet de copier en masse un ensemble d'éléments du dictionnaire d'un dossier vers
un autre. Ces éléments du dictionnaire peuvent être définis par des cases à cocher, par des bornes
de nom, et par une date (éléments mis à jour plus récemment qu'une date donnée).
Il est en outre possible de filtrer uniquement les éléments à copier concernés par leur appartenance à
un module, par un code activité donné.
Enfin, le transfert d'un élément peut s'accompagner de la copie des traitements associés, et phase de
la validation du dictionnaire sur les éléments copiés dans le dossier d'arrivée peut également être
lancée.
Lorsqu'on référence un autre dossier, pour des opérations de copie ou de comparaison, par exemple,
il est possible d'utiliser les syntaxes suivantes :
DOSSIER (le nom du dossier directement : dans ce cas, le dossier est censé être accessible
directement sur le même serveur et le même service)
serveur@DOSSIER (le nom réseau du serveur où se trouve le dossier doit être indiqué : un service
adxd doit fonctionner sur le numéro de service courant pour permettre la connexion)
serveur:service@DOSSIER (même principe que ci-dessus, mais le numéro de service peut être
différent. Ceci donne, par exemple, la syntaxe serveur_01:1802@DEMO)
Si la copie se fait d'un dossier de même type (par exemple de type X3 vers un autre dossier de type
X3), cette condition est toujours remplie lorsqu'on part du dossier superviseur (X3 dans le cas
présent), puisque toute installation d'un progiciel en technologie Sage X3 suppose qu'un dossier
superviseur soit installé au minimum sur les serveurs où des dossiers sont présents. Il est donc
conseillé d'utiliser la copie depuis le dossier superviseur (X3 si c'est X3 Entreprise) dans ce cas : il est
en effet parfaitement possible de copier un élément depuis un dossier qui n'est pas le dossier courant
(même si le dossier courant est proposé par défaut), vers un autre dossier qui n'est pas non plus le
dossier courant.
Si la copie se fait entre deux progiciels différents de la gamme SAGE X3 (par exemple X3 Entreprise,
Geode GX, Abel X3, Sage RH), cette condition n'est plus remplie. Il est alors recommandé de
référencer les dossiers sur lesquels on désire faire des copies dans l'onglet de définition des liens de
la fiche dossier.
Par ailleurs, lorsqu'un traitement est associé à l'élément du dictionnaire à copier, ce traitement n'est
pas copié. Il sera nécessaire de le faire manuellement. De même, les éléments dictionnaire comme un
type de donnée, un code activité etc…définis dans l'élément à copier, ne sont pas copiés.
Enfin, lorsque des opérations de copie induisent des validations (génération de code), elles ne sont en
général pas réalisées lorsque le dossier d'arrivée est sur un serveur différent . Il vaut alors mieux
passer par des validations de dictionnaire sur le dossier d'arrivée.
La copie de et la génération de transactions sont de nouveaux utilitaires en 140, qui sont rendus
possibles par le fait qu’un dictionnaire des transactions existe désormais dans Sage X3.

Sage ERP X3
Remarque :
La copie permet le transfert des dictionnaires d’un dossier à l’autre. Par défaut, le dossier d’origine
proposé est le dossier courant.
Elle peut être limitée aux éléments marqués par un code activité, ou aux éléments modifiés depuis
une date donnée. C’est une des façons (avec l’outil de patch) de transférer des éléments résultant
d’un développement d’un dossier à l’autre, mais ceci suppose que l’un soit accessible à partir de
l’autre : la syntaxe serveur@DOSSIER:service permet d’accéder à un dossier situé sur un autre
serveur, accessible par un autre numéro de service.
La phase de validation (i.e. de génération de code) peut être enchaînée à la copie.
10.6.3. Différence d’objets
Développement > Utilitaire > Dictionnaire > Analyseur de différence > Objets
Cette fonction permet de comparer globalement des éléments du dictionnaire entre deux dossiers. Le
résultat est obtenu sous la forme d'un fichier trace plus ou moins détaillé, selon les options de
lancement.
Ainsi qu'on le remarquera, on retrouve, dans la trace, l'identification de l'élément et des sous-éléments
(écran, champ, action, par exemple), ainsi que le nom du champ du dictionnaire sur lequel se trouve
la différence. Les noms des champs n'apparaissent pas si la case à cocher Technique n'est pas
cochée.
Cet utilitaire est très long à l'exécution s'il est lancé sur la totalité du dictionnaire. Dans ce cas il est
conseillé de l’exécuter en mode batch à l’aide de la tâche standard ACOMPOBJ.

Sage ERP X3
Ces outils permettent de réaliser

les opérations suivantes :
Génération du code associé aux transactions
applicatives paramétrables
Copie de transactions applicatives

paramétrables vers un autre dossier
10.6.4. Validation des fonctions
Développement > Utilitaire > Dictionnaire > Validation > Fonction
Cette fonction permet de mettre globalement à jour les informations des tables stockant les
informations d'habilitation croisées utilisateurs / fonctions. Elle est essentiellement utile lorsqu'on a mis
à jour le dictionnaire des fonctions, la table des sociétés et/ou des sites, ou la table des habilitations
fonctionnelles par des copies ou transferts (dans le cas de saisie manuelle, la mise à jour se fait
automatiquement).
En effet, pour des raisons de performance et de facilité d'utilisation dans les états, les habilitations
sont gérées en détail dans une table croisée dont la clé est (code site, code profil, fonction). Cette
table est mise à jour à chaque fois que des profils, des sites, des groupes de sites, ou des fonctions
sont mises à jour. Lorsque des transferts par copie sont faits, il est donc nécessaire de remettre à jour
ces informations.
Attention, cette table peut être volumineuse, et les données à mettre à jour importantes. En effet, si on
a 5 profils fonctions différents, et 20 sites, sachant que le progiciel intègre plusieurs centaines de
fonctions, on a au minimum dans cette table N*100*5*20 lignes (car le profil du super-utilisateur a
accès à toutes les fonctions sur tous les sites), plus une ligne pour chaque combinaison utilisateur,
site, fonction autorisée.

Sage ERP X3
10.6.5. Validation des menus
Développement > Utilitaire > Dictionnaire > Validation > Menus
L’utilitaire de mise à jour des menus locaux réalise les opérations suivantes, pour chaque langue :
Dans le répertoire de publication des menus locaux (X3_PUB/DOSSIER/GEN/LAN/MENL, il réécrit
les fichiers Mnnnn.xml des menus locaux modifiés
Il met à jour les tables d’horodatage pour forcer la revalidation des écrans Web où le menu est utilisé
lors de leur prochaine utilisation
Il met à jour les fichiers menulan qui servent à l’interface client/serveur et à l’impression via Crystal
Reports.
Il est automatiquement lancé lorsqu’un utilisateur modifie un menu local et sort de la fonction de
gestion des menus locaux. Mais si on veut enchaîner un ensemble de modifications et ne pas perdre
de temps à réaliser cette génération à un moment donné, l’utilitaire de mise à jour permet de
déclencher cette opération après coup.
Cette fonction permet de mettre à jour le fichier d'extension .mnu, situé dans le répertoire des menus
du dossier (sous-répertoire MLAN, où LAN est le code langue de connexion), associé à une profil
menu, et décrivant l'arborescence des menus et sous-menus, ainsi que des fichiers XML qui décrivent
l'arborescence pour l'interface utilisateur. Ces fichiers sont automatiquement rafraîchis sur les postes
(en client-serveur et en Web) à la connexion.
La revalidation se fait uniquement dans toutes les langues utilisées dans le dossier.
Cette phase de validation est automatiquement réalisée pour un profil utilisateur normal dès lors que
celui-ci est modifié par la gestion des profils utilisateurs. Il existe par contre un profil menu particulier,
nommé ADMIN par défaut, qui est associé à un utilisateur privilégié, et qui contient automatiquement
toutes les fonctions définies dans le progiciel. La revalidation de ce profil est rendue nécessaire par
cette fonction dès lors que l'on a mis à jour la table des fonctions du progiciel, par exemple en ajoutant
de nouvelles fonctions créées par des développements spécifiques. Tant que cette phase n'aura pas
été faite, les nouvelles fonctions ne seront pas accessibles par le menu de l'administrateur (elles le
seront pour les autres profils si on désire l'inclure au profil menu en le modifiant).

Sage ERP X3
10.6.6. Génération des transactions
Développement > Utilitaire > Dictionnaire > Génération transaction
La plupart des écrans de saisie de mouvements du progiciel sont paramétrables par l'utilisateur, par le
biais de transactions. Ces transactions permettent de définir, parmi un ensemble de champs
standards, quels sont ceux qui doivent apparaître dans l'écran de l'utilisateur. Cette génération de
transaction se fait par duplication, puis modification d'écrans modèles.
De même, certaines fonctions de paramétrage provoquent la génération de code à partir d'éléments

de paramétrage (c'est le cas pour les statistiques, les variables associées aux paramètres, par
exemple).
Cette génération de code se fait normalement au cours de chaque opération de paramétrage, mais il
arrive, parce qu'un écran modèle a été modifié, que la régénération du code soit nécessaire pour
toutes les transactions d'un type donné. Cette fonction permet de déclencher cette régénération.
Il est à noter que les transactions sont désormais définies dans un dictionnaire dédié.
10.6.7. Gestion des traitements

Ces fonctions sont dédiées aux développeurs utilisant la technologie Sage X3
10.6.7.1. Copie des traitements

Développement > Utilitaire > Dictionnaire > Copie > Traitement
Permet de copier la source d’un traitement (.src) vers un autre dossier.

Sage ERP X3
10.6.7.2. Génération archive traitements

Développement > Utilitaire > Dictionnaire > Archives > Archive traitement
A partir de la version 5 les exécutables issu de la compilation des sources X3, autrement dit les .adx
sont présent dans le répertoire TRT et dans un fichier archive
10.6.7.3. Copie fichiers

Développement > Utilitaire > Dictionnaire > Copies > Fichiers
Utilitaire de copie de fichiers séquentiels.
10.6.8. Mise à jour des menus locaux
Développement > Utilitaire > Dictionnaire > Archives > Mise à jour Menus Locaux

Sage ERP X3
Les menus locaux qui sont utilisés pour la saisie des données organisées en combo-box sont définis
dans la table APLSTD, par une opération de paramétrage dédiée. Mais il est aussi nécessaire que
les valeurs de ces menus, et l'association entre les champs du dictionnaire et les menus, soient
localement stockés sur le poste client, afin de permettre leur utilisation par des fonctions dédiées de
Crystal Report.
Pour cela, il existe des fichiers sur le poste clients, dont le nom est menus (affectation champs-menus
locaux), et menuXXX (liste des valeurs des menus locaux pour la langue XXX). Ces fichiers sont
stockés dans le sous-répertoire Report\DOSSIER_serveur_service, DOSSIER étant le code du
dossier, serveur le nom du serveur, et service le numéro du service.
Ces fichiers sont automatiquement téléchargés depuis le serveur, à partir de fichiers de référence
portant le même nom, dès lors que les fichiers de référence sont plus récents que les fichiers situés
sur le poste client.
La fonction de génération des menus locaux permet de réaliser cette opération. Il est nécessaire de la
lancer dès lors que l'on désire rendre visible dans les données éditées par des états, les intitulés de
menus locaux ayant changé.
Le lancement de cette fonction est proposé automatiquement lorsque des menus locaux ont été
modifiés ; il n'est donc nécessaire de lancer cette fonction que si on a répondu Non à la question
posée, par exemple après avoir fait des modifications en masse ou par maintenance des menus
locaux.
10.6.9. Synchronisation des fenêtres
Développement > Utilitaire > Dictionnaire > Synchronisation des fenêtres
Au niveau technique, l'interface utilisateur des progiciels en technologie Sage X3 est décrite au format
XML. Une fenêtre XML est décrite sous la forme d'un premier fichier décrivant sa structure, et d'un

Sage ERP X3
ensemble de fichiers décrivant les éléments qui la composent : écrans, listes de gauche, menus
locaux. Tous ces éléments sont multilingues et indépendants du poste client sous-jacent, et leur
génération est issue d'une validation du dictionnaire.
Ainsi, par exemple :
Lorsqu’une fenêtre est modifiée, par exemple par l'ajout d'un bouton, le XML correspondant à la
fenêtre est réécrit.
Lorsqu’un écran est modifié (par exemple par rajout d'un champ), le XML correspondant à l'écran est
réécrit.
Lorsqu’une liste gauche est créée et ajoutée à une fenêtre, le fichier XML correspondant est créé, et
le fichier XML de la fenêtre est remis à jour.
A partir de ces fichiers élémentaires, une phase d'assemblage permet, dans un contexte donné (type
de client, langue), de générer un fichier XML optimisé, ne contenant plus que les informations utiles à
l'interface considérée. C'est ce fichier assemblé qui est stocké dans le cache du poste client. Il en
existe une version différente pour les interfaces client-serveur, Web, et terminaux portables, les
informations nécessaires n'étant pas strictement les mêmes.
Tous les fichiers XML sont horodatés, ce qui permet à tout moment de vérifier la cohérence entre les
éléments.
Pour des raisons d'optimisation, lorsqu'un écran est modifié, on ne relance pas l'assemblage des
fichiers XML optimisés pour toutes les fenêtres qui l'utilisent; par contre, on met à jour un indicateur
pour invalider les fenêtres. Ainsi, cet assemblage est fait à la volée lors de la première utilisation de la
fenêtre dans un contexte donné.
Cette fonction permet de forcer cet assemblage, mais il permet aussi de régénérer les fichiers XML
décrivant les fenêtres, pour permettre de gérer des cas tels que la mise à jour des générateurs XML.
Utilitaires dossiers
o Changement de dossier : permet une reconnexion sur un autre dossier
o Remise à zéro dossier

o Cet utilitaire remet à zéro les mouvements dans
la base de données, sans remettre à zéro les
données permanentes.
o Attention, utilitaire irréversible !
o Les mouvements sont identifiés dans le dictionnaire :
o Une table marquée Raz est vidée
o Un champ marqué Raz reçoit une valeur nulle
o Les compteurs marqués Raz sont remis à zéro
o Utile en cas de démarrage réel après un démarrage test, par exemple
Remarque :
L‘écran de saisie de dossier est proposé dans le cas des 2 utilitaires, mais une confirmation est
demandée avant remise à zéro effective.

Sage ERP X3
Déverrou dossier : supprime le verrou empêchant la

connexion à un dossier lors de sa revalidation de
dossier (ce verrou peut rester en place en cas
d’arrêt brutal lors d’une revalidation)
Import dossier : crée la fiche Dossier à partir d’un fichier se

trouvant dans le répertoire du dossier (utile en cas de transport
d’un dossier d’un serveur à un autre, correspond à l’item de menu
Option / Importer en gestion de dossier)
Passage en mode mono : Cet utilitaire met le dossier dans un

mode où :
Un seul utilisateur peut être connecté à la fois
Cet utilisateur a forcément le profil fonction de l’administrateur
Passage en mode multi : sortie du mode mono-utilisateur
Remarque :
Si la connexion est impossible sur un dossier donné, le message affiché étant Dossier en cours de
validation, et si la validation n’est plus en cours, il est conseillé d’aller d’abord voir la trace de
validation, accessible en gestion de dossier, et, si la trace laisse entrevoir que le dossier devrait être
utilisable, de déverrouiller le dossier pour y entrer et faire des vérifications. Il faudra, sur un dossier
d’exploitation, revenir dans une situation normale où le dossier est correctement revalidé.

Sage ERP X3
10.7. UTILITAIRES DE RECHERCHE

Les outils décrits dans ce chapitre sont destinés :
- Aux développeurs pour analyser les impacts d’une modification
- Aux fonctionnels pour rechercher les entités impactées par une modification d’un code activité
- A l’administrateur pour analyser les changements sur les codes d’accès ou les habilitations
Les types de recherche disponibles sont :

 Recherche par code activité
Développement > Utilitaire > Recherches > Codes activités
Cette recherche est nécessaire avant de modifier un code activité de type dimensionnement pour
disposer de la liste des entités impactées.
 Recherche par type de données
Développement > Utilitaire > Recherches > Type de données
 Recherche par code d’accès
Développement > Utilitaire > Recherches > Code d’accès
 Recherche par code action
Développement > Utilitaire > Recherches > Action
 Recherche par message
Développement > Utilitaire > Recherches > Message
Cette recherche permet de trouver tous les messages utilisant un mot comme par exemple « facture »
 Recherche par texte
Développement > Utilitaire > Recherches > Texte
Cette recherche permet de trouver le numéro d’un texte et les entités qui utilisent ce numéro.

Sage ERP X3
Résultat de la recherche du mot Facture
 Recherche diverses
Développement > Utilitaire > Recherches > Divers
Cette fonction permet de rechercher dans toutes les tables du dictionnaire une valeur donnée pour un
champ de type donné, pourvu que ce type soit associé à un objet du progiciel. Par exemple, on peut
rechercher les endroits où un code état est utilisé, où un code pays est utilisé, etc.
On peut également rechercher des traitements (type ADC), bien que ce type ne soit pas associé à un
objet par défaut. Ceci permet de vérifier dans quels écrans, fenêtres, actions… un traitement donné
est utilisé.
Chaque fonction de recherche produit une trace sur laquelle l’utilisateur peut réaliser son analyse.

Sage ERP X3
10.8. UTILITAIRES DIVERS
10.8.1. Ordre système
Développement > Utilitaire > Divers > Ordres système
Cette fonction permet de lancer un ordre système sur le serveur d'application du dossier. Vu d’un
dossier X3 un ordre système est l’activation d’un exécutable ou d’une commande liée à l’Operating
System qui héberge le serveur.
On peut aussi lancer des ordres systèmes sur l'une quelconque des machines où un autre serveur
d'application sur lequel les processus adxd et sadsys tournent, et également sur le poste client.
Les syntaxes sont alors les suivantes :

serveur@ordre_sys (le nom réseau du serveur où se trouve le dossier doit être indiqué : un service
adxd doit fonctionner sur le numéro de service courant pour permettre la connexion)
serveur:service@ordre_sys (même principe que ci-dessus, mais le numéro de service peut être
différent. Ceci donne, par exemple, la syntaxe serveur_01:1802@lsadx -a DOSSIER TRT src)
Attention : les deux dernières syntaxes supposent qu'il existe sur le serveur distant un dossier ayant le
même nom que le dossier d'où est lancée la fonction (même si ce n'est pas sur ce dossier que l'on
lance l'opération). Cette condition est toujours remplie lorsqu'on part du dossier X3, puisque toute
installation X3 suppose qu'un dossier X3 soit installé au minimum. Il est donc conseillé de n'utiliser
cette syntaxe que dans ce cas. Par ailleurs, selon les configurations réseau, la saisie d'un nom réseau
incorrect peut provoquer une attente assez longue après la saisie du champ (le contrôle d'existence
du serveur se faisant sur le réseau, il peut y avoir un délai de l'ordre de la minute, parfois même de
plusieurs minutes avant qu'un message d'erreur n'arrive).
Le lancement de l'ordre système sur le client se fait en donnant # comme nom de serveur.
En Mode Web, l'exécution directe d'un ordre système sur le poste client (syntaxe #@ordre) est
impossible, pour des raisons de sécurité.

Sage ERP X3
10.8.2. Exécution traitement
Développement > Utilitaire > Divers > Exécution traitements
Ce type de fonction est une fonction de développement dont l'utilisation est interdite dans le cadre
d'une exploitation normale
10.8.3. Copie des valeurs paramètres
Développement > Utilitaire > Divers > Copie valeurs paramètres
Cette fonction permet de copier les valeurs de paramètres (Table ADOVAL) définis à un niveau donné
(société, site, utilisateur, législation) pour un code donné, vers un ensemble de codes de destination
(société, site, utilisateur, législation, selon le choix de copie fait) définis par borne de valeurs, par
l'utilisation d'un modèle, ou donnés sous la forme d'une liste.
Cette copie peut être faite en mode simulation dans un premier temps (avec ou sans le détail des
paramètres copiés).

Sage ERP X3
10.8.4. Re synchronisation des liaisons
Développement > Utilitaire > Divers > Resynchronisation des liaisons
Au niveau des listes gauche d’un objet, un browser nommé Explorateur de liens qui permet de définir
des liens vers d'autres fiches issues d'autres objets. Ces liens peuvent être établis manuellement,
grâce à la fonction Fichier / Liaisons, mais également de façon automatique.
Ce paramétrage fait, les liaisons automatiques sont mises à jour à chaque fiche créée ou modifiée,
mais bien entendu pas sur les fiches antérieurement créées.
Cette fonction permet de lancer la mise à jour des liaisons automatiques. Elle peut être faite sur un
objet, ou tous objets confondus.
Développement > Utilitaire > Divers > Activation des liaisons
Les liaisons entre les fiches des objets de gestion, sont définies par une fiche de départ, une fiche
d'arrivée, un groupe de liaison lié aux utilisateurs, et une désignation déclarée par un code dans une
table. Chaque liaison peut être saisie manuellement ou créée automatiquement d'après un
paramétrage lié à l'objet. Enfin, chaque liaison est datée, et dispose d'un indicateur actif (Oui/Non) : le
champ ENAFLG est utilisé à cette fin.
Les liaisons attachées à une fiche sont présentées dans un volet de la liste gauche : l'explorateur de
liaisons, dont la présence est optionnelle et dépend du paramétrage de l'objet. Seules les liaisons
actives sont présentées dans l'explorateur de liaison. Par défaut, lorsqu'une liaison est créée, elle est
active, et la seule fonction susceptible de faire passer des liaisons de l'état Actif à l'état Inactif et vice-
versa est la fonction Activation des liaisons présentée ici.
Les paramètres généraux suivants ont une influence sur le comportement de la fonction :
GRPLIAISON (défini au niveau Utilisateur) : Groupe de liaison
LIAISAUTO (défini au niveau Utilisateur) : Liaisons autos

Sage ERP X3
La table diverse numéro 61 doit être renseignée : Sémantique liaisons
Il faut que la gestion des liaisons ait été paramétrée au départ. Ceci suppose, outre l'activation des
paramètres utilisateurs, que le volet des liaisons apparaisse dans les fonctions dans lesquelles il est
jugé utile. Ceci se définit par la fonction de personnalisation d'objet.

Sage ERP X3
11. LES TRANSACTIONS SYSTEME
Une transaction système permet sur les données d’une table :
 la création,
 la mise à jour
 la suppression
Par conséquent, la fonction de paramétrage des transactions est une fonction potentiellement
dangereuse. Les ordres SQL associés impactent les données de la base sans que la cohérence liée à
l’applicatif ne soit contrôlée.
Il convient donc, après analyse, de :
 Réaliser une sauvegarde des tables impactées avant toute modification.
 Effectuer un test du résultat obtenu par la transaction sur une sélection réduite et identifiée,
avant de lancer la transaction sur l’intégralité des données à mettre à jour.
 Ne donner accès à cette fonction qu’à certains utilisateurs (protéger par un code d’accès
chaque transaction système pour bien filtrer celles qui peuvent être accessibles aux
utilisateurs).
Remarques relatives aux habilitations et droits d’accès
 Cette fonction étant de type objet, les opérations de création, modification, et suppression de
fiche peuvent être activées ou désactivées pour un utilisateur donné.
 Des filtres par rôles peuvent également être mis en place sur cette fonction. Un filtrage par
code d'accès est effectué grâce au champ nommé ACS. S’il y a un code d'accès, les droits de
visualisation et de modification sont accordés conformément aux droits de lecture et d'écriture
associés au code pour l'utilisateur, via son profil fonction.
L’accès en exécution d’une transaction système peut être contrôlé par un code d’accès. A la définition
des profils menus, on peut aussi imposer une transaction système (paramètre de la fonction AMIEXE),
mais ceci ne dispense pas de protéger les autres transactions système par un code d’accès.

Sage ERP X3
11.1. CREATION D’UNE TRANSACTION

La création d’une transaction se fait à l’aide de 2 onglets :
 l’onglet général de définition de la transaction

 l’onglet comprenant les formules de sélection des enregistrements à traiter et les tables à
mettre à jour.
1
2 3
4
Dans l'en-tête de l’écran, on donne le code identifiant la transaction et un intitulé.
 Module d’appartenance de la transaction.

 Code activité protège la transaction de tout changement de version.
 Code accès permet de protéger chaque transaction système, accordant des droits
d’exécution ou pas aux utilisateurs.
 Table à mettre à jour.

 Tables liées rassemble la liste des tables à ouvrir, soit pour les mettre à jour, soit parce qu’on
a besoin de filtrer les enregistrements de la table principale, en fonction de champs de ces tables
liées. On peut déclarer jusqu’à 5 tables liées.

Sage ERP X3
 Variables regroupe les variables pouvant ensuite être utilisées dans les formules de sélection,
et dans les formules de mise à jour de champs. Ces variables sont nommées V1, V2, V3,… V6.
On peut déclarer jusqu’à 6 variables.
Mise à jour d’une ou plusieurs tables. On peut effectuer pour chacune d’elle :
 soit une modification de la valeur d’un ou plusieurs champs (il faudra paramétrer une ligne par
champ).
 soit une création d’enregistrements à partir d’un enregistrement sélectionné (il faudra
paramétrer une ligne pour le champ clé). C’est l’équivalent d’une duplication d’enregistrement.
Pour modifier certains champs de cet enregistrement, il faudra intervenir par une autre
transaction système.
 soit une suppression d’enregistrements (on ne précise rien pour les champs).
En modification d’enregistrements, la formule permet d’affecter une nouvelle valeur au champ
Formules permettent de faire une sélection des enregistrements à traiter. Ces formules peuvent faire
appel aux valeurs de paramètres.
On peut déclarer jusqu’à 5 formules.
La validation permet de générer le traitement automatique, nommé WMAMIxxxxx. (xxxxx étant le

code transaction). Il contient tout le traitement personnalisé de la transaction.
Exec permet d’exécuter directement la transaction. Il correspond à la fonction « transactions

système ».
Copie permet de recopier la définition de la transaction vers un autre dossier. Il faudra valider la
transaction dans le dossier de destination.

Sage ERP X3
11.2. L’EXECUTION D’UNE TRANSACTION SYSTEME

Développement / Utilitaires / Divers / Transactions système
Outre l’exécution par le biais du bouton « Exec » dans la fonction de création de la transaction
système, il existe une fonction dédiée présentant des options supplémentaires.
Saisir le code de la transaction à effectuer.
Cocher Test permet de lancer la transaction uniquement en test. Dès lors, on saisit le nombre
d’enregistrements sur lequel porte la trace de test (10 par défaut) : la trace présentant les lignes qui
seraient modifiées si la fonction était lancée en mode réel.
Cette saisie faite, on voit apparaître, le cas échéant, des paramètres dont la valeur doit être saisie
dans le tableau situé ci-dessus.
Une trace sera affichée lorsque cette fonction sera terminée pour donner la liste des lignes modifiées.


SX302 - Sage ERP X3 Outils Avancés - V6 1 - Support de Cours

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 - Sage ERP X3 Outils Avancés - V6 1 - Support de Cours

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Sage ERP X3

Sage X3 Outils avancés Sage 2010 Page 1

Sage X3 Outils avancés Sage 2010 Page 2

5.2.4. Contraintes horaires & calendrier .............................................................................................. 36

Sage X3 Outils avancés Sage 2010 Page 3

8.6.2. Consultation............................................................................................................................. 113

Sage X3 Outils avancés Sage 2010 Page 4

10.3.5. Symboles verrouillés ............................................................................................................... 166

Sage X3 Outils avancés Sage 2010 Page 5

1. GESTION DES SESSIONS

1.1. CONNEXION A UN DOSSIER SAGE X3

On s’identifie comme un utilisateur X3, ce qui définit, dossier par dossier :

En mode client serveur

Sage X3 Outils avancés Sage 2010 Page 6

D’autres langues sont mises en œuvre par des partenaires.

Les 3 principaux éléments de la connexion (dossier, utilisateur, langue)

1.1.1. Définition des paramètres d’un dossier

Sage X3 Outils avancés Sage 2010 Page 7

Avec quelques paramètres complémentaires :

Sage X3 Outils avancés Sage 2010 Page 8

Le bouton Avancé donne accès à des paramètres complémentaires

Attention, en connexion via Citrix, il faut décocher la case en question.

1.1.2. Aide en ligne

Inconvénients du format chm

Un très gros fichier

Sage X3 Outils avancés Sage 2010 Page 9

Sage X3 Outils avancés Sage 2010 Page 10

1.2. DEFINITION D’UNE SESSION X3

1.2.1. Sessions primaires et sessions secondaires

Plusieurs sessions primaires peuvent être ouvertes depuis un même poste.

Fichier / Session secondaire

Une session secondaire possède les caractéristiques suivantes :

1.2.2. Autres sessions

- Session batch (déclenchée par le serveur batch)

La fonction adxuid(1) donne l’identificateur unique (pour un serveur d’application donné)

La fonction adxtyp permet de connaître le type de connexion :

Sage X3 Outils avancés Sage 2010 Page 11

10 Session secondaire en mode Client web

Sage X3 Outils avancés Sage 2010 Page 12

1.3. CONTROLE DES SESSIONS AUTORISEES

1.3.1. Visualisation des sessions actives

Sage X3 Outils avancés Sage 2010 Page 13

Cette fonction permet de :

1.3.2. Désactivation d’une session

Sage X3 Outils avancés Sage 2010 Page 14

A une session Sage X3 correspond au minimum les processus suivants

1.4. CLIENT « TERMINAL MOBILE »

Sage X3 Outils avancés Sage 2010 Page 15

Les principales touches fonctions sont :

F1 OK. Cette touche permet le passage à la ligne suivante

Une ligne de document = 1 mouvement de stock

1.4.2. Possibilités fonctionnelles

- Gestion des entrées et sorties diverses

1.4.3. Pré requis

Sage X3 Outils avancés Sage 2010 Page 16

2.1. DIFFERENCES ENTRE LE PARAMETRAGE ET LE DEVELOPPEMENT.

2.2. NOTION DE VERTICAL ET DE SPECIFIQUE

2.3. GESTION DES CODES ACTIVITE

Sage X3 Outils avancés Sage 2010 Page 17

La création d’un code activité est une opération de développement.

Conventions sur la codification du premier caractère des codes activité