Participation à différents développements sur le progiciel de gestion

Participation à différents développements sur le progiciel de gestion

Participation à différents développements sur le progiciel de
gestion intégrée Précix pour des clients de Méga Informatique en
Suisse
Rapport technique
Stage IFI 3
6 mai - 30 août 2002
Xavier MOGHRABI
IFI 2003
Gland - SUISSE
Participation à différents développements sur le progiciel de
gestion intégrée Précix pour des clients de Méga Informatique en
Suisse
Rapport technique
Stage IFI 3
6 mai – 30 août 2002
Elève : Xavier MOGHRABI
Promotion : IFI 2003
Tuteur école : Emmanuel Otton
Tuteur entreprise : Gérald TÉDÉSCHI
MÉGA INFORMATIQUE S.A.
Rue du Borgeaud 10B
1196 GLAND
SUISSE
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
REMERCIEMENTS
Tout d’abord, je tiens à remercier Gérald TÉDÉSCHI et Jean-Noël VIPREY, co-directeurs de
Méga Informatique, pour avoir accepté ma proposition de stage.
Je remercie Philippe MÉNONI, développeur pour la maintenance, pour m’avoir encadré à mes
débuts. Il m’a également fait visiter une partie de la Suisse lors de déplacements à la Neuveville et à
Bulle.
Je remercie Florent BLANDIN, responsable de la maintenance et du module SAV, de m’avoir
fourni du travail sur son module.
Je remercie Sébastien PAROISSE, développeur pour la comptabilité, d’avoir été mon voisin de
bureau. Il m’a par ailleurs aidé pour certains problèmes avec les outils de développement.
Je remercie Chistophe COULAN, responsable du module Comptabilité, de ses critiques des
logiciels qui m’ont permis d’éviter des pièges.
Je remercie Pierre Yves BRUNET, développeur spécialiste de Datastage, d’égayer nos repas
grâce à son humour et pour ses conseils sur Informix.
Je remercie Alexandre BRAMAZ, développeur spécialiste des langages objets, de m’avoir
enseigné efficacement les bases de CI-Builder.
Je remercie Rodolphe BINDLER, développeur spécialiste CI-Builder, de ses conseils pour les
programmes spécifiques et de m’avoir amené plusieurs fois à Annecy.
Je remercie Christophe CHARMOT, responsable des bases de données, de m’avoir aidé lors de
problème avec Informix et ma connexion au réseau.
Je remercie Jean Bernard BUSQUET, commercial et consultant, de m’avoir proposé d’aller à Albi
pour les Journées Utilisateurs de Précix.
Je remercie Valérie PETER, secrétaire, de m’avoir accueilli tous les matins avec un grand
sourire.
Je remercie Jolivette MUKABYAGAJU, assistante de direction, d’avoir organisé la sortie à la
manifestation Expo 02.
Je remercie Serenella VIPREY, responsable de la comptabilité de la société, de s’être occupée
mes documents administratifs.
Je tiens à remercier l’ensemble du personnel pour l’accueil qu’il mont réservé et le cadeau de
départ. Je remercie l’ensemble de l’équipe pour l’expérience enrichissante dont j’ai bénéficié.
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
RÉSUMÉ
La société de services d’ingénierie informatique Méga Informatique distribue et intègre le progiciel
Précix en Suisse Romande. En tant qu’intégrateur, elle développe des modules et des programmes
spécifiques à ses clients. Le stage 3ème année a ainsi consisté à participer à ces développements. Le
nouvel arrivant a ainsi dû s’adapter à cet environnement de développement peu commun.
Les travaux ont consisté à personnaliser les documents des clients, puis à améliorer le module
du service après vente et finalement à travailler sur des programmes spécifiques à des clients, propres
à leur gestion.
Ce stage a permis de voir les différentes responsabilités confiées au développeurs. Tout d’abord,
ils s’occupent de l’installation du progiciel et de la maintenance. Ensuite ils doivent suivre un plan de
développement pour mener à bien la programmation. Le stagiaire fera part d’un certain de constats sur
cette expérience comme la difficulté de programmer avec des outils contenant des défauts.
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
SOMMAIRE
INTRODUCTION .......................................................................................... 8
I. Le programmeur de Méga Informatique travaille sur un
environnement de développement peu répandu............................................. 9
1.
2.
3.
II.
1.
2.
3.
a.
b.
c.
a.
b.
a.
b.
c.
d.
La société Méga Informatique, une petite structure qui s’agrandit ......................... 9
Depuis sa création, la société ne fait que s’agrandir...................................................... 9
Le sujet de stage........................................................................................................... 9
L’activité et le progiciel de gestion intégrée Précix ...................................................... 10
Précix est structuré autour d’une base de données ............................................. 12
INFORMIX, le SGBD adopté par Précix ...................................................................... 12
Le langage SQL convient aussi bien aux débutants qu’aux développeurs confirmés .. 12
Les outils de développement de la version Eclipse.............................................. 14
La complémentarité des produits CI-SOFT ................................................................. 14
L’outil graphique CI-Builder, de bonnes idées pénalisées par des bugs ...................... 14
Le générateur d’états CI-Query, simple mais très limité .............................................. 16
Le logiciel intermédiaire CI-Link, un langage plus classique ........................................ 18
La diversification du travail de développement............................... 19
a.
b.
a.
b.
c.
d.
a.
b.
c.
Les documents CI-Query personnalisés pour des clients .................................... 19
La création et les retouches de documents ................................................................. 19
Les difficultés rencontrées principalement dues aux limites de l’outil........................... 19
L’amélioration du module SAV ............................................................................. 21
Le module SAV et son fonctionnement........................................................................ 21
Les petites améliorations ou corrections...................................................................... 21
La création d’un nouveau projet de statistiques des interventions ............................... 23
La reconstruction de la palette de modification des devis............................................ 25
Le travail sur des spécifications pour des clients ................................................. 28
L’impression des caractéristiques de template horloger .............................................. 28
Le spécifique des retours de consignation................................................................... 30
Le spécifique pour l’annulation des retours de consignation........................................ 31
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
III.
Des développeurs polyvalents sont indispensables à une petite
structure telle que Méga Informatique ........................................................... 33
1.
2.
3.
a.
b.
c.
a.
b.
c.
a.
b.
c.
d.
L’installation des logiciels ..................................................................................... 33
L’installation de la base de données Informix, un travail d’administration .................... 33
L’installation de Précix, un procédure simple mais qui peut réserver des surprises..... 34
La télémaintenance évite certains déplacements ........................................................ 35
Le travail sur un projet en informatique ................................................................ 35
L’analyse du projet, pour démarrer sur de bonnes bases ............................................ 35
Le développement, une course contre la montre......................................................... 36
La phase de test garantit la qualité du produit ............................................................. 36
Un bilan de stage très satisfaisant et enrichissant ............................................... 37
Un travail de développement intéressant mais avec des outils capricieux ................... 37
Les résultats obtenus ont-ils constitué un gain pour la société ? ................................. 38
Les compétences multiples des informaticiens, la force de l’entreprise ....................... 38
Les leçons du stage .................................................................................................... 39
CONCLUSION ........................................................................................... 40
Table des illustrations.............................................................................. 41
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
INTRODUCTION
L’entreprise suisse qui a proposé le stage a pris l’habitude depuis trois ans de prendre un
stagiaire de l’École des Mines d’Albi. La société est spécialisée dans les services d’ingénierie
informatique dispensés aux entreprises. Son activité principale concerne la distribution et l’intégration
d’un progiciel de gestion intégrée Précix développé par une société albigeoise Sylob. La société
propose de participer à des développements pour ses clients. Ce stage peut être considéré comme un
défi pour un élève de l’École des Mines puisqu’il n’est en aucun cas spécialisé dans l’informatique.
D’autant plus que l’environnement de développement n’est pas du tout répandu. Cependant le
stagiaire, qui choisit un tel sujet, possède déjà une expérience dans la programmation et part avec le
souhait de se perfectionner.
Ainsi ce rapport montra quelles missions ont été confiées à un stagiaire développeur et comment
celui-ci s’est pris pour réaliser les développements demandés. Le nouvel arrivant dans la petite
structure de Méga Informatique se retrouve au cœur du développement de modules Précix.
L’environnement de développement lui est alors inconnu. La première mission consiste ainsi à devenir
opérationnel pour honorer le sujet de stage. Ainsi en regardant les missions confiées, on se rend
compte que les langages de développement permettent au programmeur de vite progresser et
d’apprendre chaque jour de nouvelles possibilités.
Tout d’abord, il convient de présenter l’entreprise, le produit Précix et son environnement de
développement. Dans un second temps, le lecteur pourra prendre connaissance d’une partie du travail
de développement réalisé par le stagiaire. Avant de conclure, le rapport s’attachera à montrer le travail
annexe qui entoure le développement et tirera quelques constats de ce stage.
8
Xavier MOGHRABI
IFI 2003
I.
Rapport technique
Stage IFI 3
Le programmeur de Méga Informatique travaille sur un
environnement de développement peu répandu
1. La société Méga Informatique, une petite structure qui s’agrandit
Méga Informatique est une petite société de services d’ingénierie informatique basée en Suisse
Romande. Son activité principale concerne la distribution et l’intégration d’un progiciel de gestion
intégrée, appelé également ERP, Précix. Elle complète le réseau de distribution de l’éditeur Sylob basé
à Cambon d’Albi. Le stage consiste alors à participer à des petits développements pour ce progiciel.
a. Depuis sa création, la société ne fait que s’agrandir
Méga Informatique a été créée en 1985 par Jean Noël VIPREY, actuellement codirecteur, et son
activité constituait à faire des développements sur un module de comptabilité pour un seul client
Nixdorf. Ce début peut rappeler que Jean Marie VIGROUX, créateur de la société Sylob, travaillait à
ses débuts en 1987 comme sous-traitant de NIXDORF sur un module de Gestion de Production
Assistée par Ordinateur (G.P.A.O). Pourtant à cette époque, les deux hommes ne se savaient pas
encore qu’ils travailleront ensemble.
En 1991, Nixdorf se fait racheter par Siemens et le groupe allemand abandonne peu à peu ses
offres d’ERP. Ainsi le directeur de Méga Informatique cherche une nouvelle opportunité, s’offre alors
Précix, un ERP jeune, édité depuis 1991 par Sylob. Le progiciel ne comporte pas de module de
comptabilité. Il est à l’époque compatible avec les logiciels de comptabilité et de paye SAGE. Méga
Informatique accepte en 1995 un contrat d’intégrateur de Précix en Suisse Romande et édite un
module de comptabilité pour Précix.
Ce statut d’intégrateur lui confère le droit de développer des programmes spécifiques de
n’importe quel module de l’application Précix pour ses clients en Suisse Romande (en respectant bien
sûr les normes de développement de Sylob), et lui donne droit à un pourcentage de 50 % sur la vente
de Précix. De plus, par la suite, la société suisse crée un module pour la gestion du service après
vente.
Actuellement Méga Informatique devrait être considérée comme le meilleur des partenaires de
Sylob puisque la société a vendu grâce à son équipe marketing, dirigée par Gérald TÉDÉSCHI une
cinquantaine de licences. La société réalise un chiffre d’affaires annuel d’environ 2'
300'
000 . Ainsi le
nombre de clients de Sylob s’élève a environ 150. Le partenaire suisse a ainsi apporté à Sylob une
aide importante pour vendre le progiciel.
La société a, selon les dires du Directeur, atteint sa taille optimale avec une quinzaine
d’employés. La société a déménagé depuis ses débuts. En décembre 2000, Méga Informatique a
emménagé dans ses nouveaux locaux de 370m2 à Gland, une ville de 10’000 âmes dans le canton de
Vaud et au bord du lac Léman. Les locaux s’étendent sur deux étages. Au premier étage, se trouvent
les bureaux de l’administration et ceux de la partie technique. A l’étage se trouvent les bureaux des
commerciaux et la cafétéria. Le regroupement de tous les développeurs dans une même partie
améliore les relations entre les employés et permet facilement de demander des conseils entres
développeurs.
b. Le sujet de stage
Le sujet du stage devait initialement consister à exploiter sous un logiciel E.I.S. (Executive
Information System) appelé Crystal Reports et de travailler sur le développement de l’ERP Précix. Les
9
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
E.I.S. sont des ensembles d’outils qui permettent aux différents niveaux de management d’accéder aux
informations essentielles de leur organisation, de les analyser et de les présenter de façon élaborée sur
une interface conviviale. Cependant le sujet du stage s’est vite transformé en développements de
programmes pour Précix.
En fait une petite structure telle que Méga Informatique ne peut pas proposer à un stagiaire un
sujet de stage à l’avance. Le travail réalisé dépend de la charge de travail de l’entreprise. Comme
Crystal Report est un logiciel qui est utilisé par peu de clients de Méga Informatique, il n’y a pas eu
beaucoup de travaux à réaliser avec. Le stagiaire s’est ainsi concentré sur des tâches de
développement de Précix.
Le sujet s’est finalement révélé vaste. En effet, les programmes développés ont été assez divers
et ont permis de découvrir les trois outils de développement, de la société stéphanoise CI-Soft, utilisés
pour la version en Eclipse de Précix. La dernière version a été éditée l’année précédente et est en
mode totalement fenêtrée à l’instar de Windows de Microsoft. Au cours du stage quatre thématiques
ont été rencontrées. La première tâche a consisté à participer à la traduction du module de comptabilité
en Anglais. Cette étape ne sera pas décrite car elle ne comporte pas d’intérêt technique. Ensuite la
seconde avait pour but de développer des documents pour être imprimés à partir des données de
Précix. La troisième étape a mené le stagiaire à participer à l’amélioration du module de Service Après
Vente. Puis la dernière tâche fut le développement de programmes spécifiques pour des clients.
Le stage a permis de travailler sur divers projets. Le principe consistait toujours à décharger les
développeurs de leur surcharge de travail pour toujours être dans les délais. Dans cet optique, le
stagiaire se devait être vite productif et surtout autonome. L’adaptation aux logiciels de programmation
s’est faite assez vite en raison de la connaissance du langage SQL, utilisé pour travailler avec des
bases de données, et de l’utilisation antérieure d’autres langages de programmation.
c. L’activité et le progiciel de gestion intégrée Précix
Précix est appelé progiciel de gestion intégrée ou ERP (de l’anglais Enterprise Ressources
Planning) parce qu’il propose la gestion de différents services d’une entreprise. Le terme intégré
signifie que chaque module partage des données avec d’autres et ainsi évite de saisir plusieurs la
même information. L’ensemble des modules permet de disposer d’un E.R.P. complet.
• Le module Administration Système concerne le logiciel, l’attribution des droits, les déclarations
des programmes, le paramétrage des menus…
• Le module Données Techniques contient les données de base de l’entreprise. Par exemple, ce
module contient les références des articles, des familles d’articles… Lorsqu’un client décide de
démarrer sa gestion avec Précix, il saisit ces données pour paramétrer l’application.
• Le module Données Administratives est lui un module de paramétrage pour saisir les données de
base comme la saisie des codes taxes, des modes de livraison…
• Le module Commercial concerne la gestion des clients ou des prospects. Ce module propose de
maîtriser tous les processus de la saisie d’une offre de vente jusqu’à la facture. Comme le progiciel
est de type intégré, les données n’ont pas besoin d’être saisies plusieurs fois. Pour créer une
commande, le logiciel utilise les lignes de l’offre de vente.
• Le module Affaires s’occupe de la gestion à l’affaire, c’est-à-dire que pour une affaire ponctuelle,
on gère l’état d’avancement du projet, l’amortissement des investissements, et ce module permet
de regrouper plusieurs lignes issues de plusieurs commandes, afin d’obtenir une affaire.
• Le module Gestion des Achats est relatif aux fournisseurs, il ressemble à celui du commercial
sauf que les rôles sont inversés.
• Le module Besoins élabore le plan industriel et commercial (PIC) et le plan de production (PDP) à
court terme et moyen terme et génère automatiquement des propositions de réapprovisionnement.
• Le module Production est un module de GPAO pour le suivi de la production. Il permet de définir
le plan de charge, de s’occuper de la planification et de la gestion des ordres de fabrication (OF)…
10
Xavier MOGHRABI
IFI 2003
•
•
•
•
•
Rapport technique
Stage IFI 3
Le module Stock, comme son nom l’indique, concerne la gestion des stocks. Il propose de faire
l’inventaire, de connaître les quantités disponibles des articles.
Le module Qualité répond aux normes de qualité ISO et permet la traçabilité du produit ainsi que la
gestion des coûts de non qualité…
Le module Paye s’intéresse aux ressources humaines. Une fonctionnalité intéressante est la
possibilité de générer des virements magnétiques (en norme ETEBAC) que l’on fournit à la banque
pour payer les salariés.
Le module Archivage propose de conserver les données de l’année écoulée dans une seconde
base de données pour créer une nouvelle année.
Le module Analyse de Gestion permet d’avoir différents états importants de la société provenant
d’autres modules. Par exemple, il est possible d’interroger la valorisation des stocks de la finance,
les coûts de qualité, de faire une simulation des besoins…
À ces modules de Sylob, Méga Informatique a ajouté deux modules relatifs à ses compétences :
•
•
Le module Service après Vente a un intitulé relativement explicite. Il crée un article SAV qui est un
duplicatif d’un article de référence et lui associe une fiche de réparation, réclamation, un éventuel
devis, puis un Ordre de fabrication de réparation. Il propose aussi des statistiques par l’analyse des
contrôles ou par les coûts des interventions en SAV.
Le module Comptabilité qui a sa place logique dans un ERP accélère le travail des comptables
puisqu’une partie des données provient des autres modules de Précix. Ce module est assez
stratégique pour Méga Informatique et connaît de nombreuses évolutions et améliorations.
Depuis mon précédent stage, les fonctionnalités de Précix ont évolué. Maintenant le progiciel est
multilingue, multidevise et multi site. Les modules existant ont été complétés par de nouvelles
fonctionnalités comme e-Precix. Son but de ce module est d’améliorer les relations entre les clients et
l’entreprise. Ce module permet d’un site Internet de proposer une solution de commerce électronique
sécurisée et de fournir des informations sur les produits. Ce module est en fait un site Internet dont les
informations proviennent de la base de données de Précix.
Une nouvelle fonctionnalité dénommée Workflow propose de gérer les flux d’informations de
l’entreprise. L’application permet de définir l’ensemble des tâches d’un processus et de gérer leur
réalisation. Par exemple avec ce module si une commande est reçue, celle-ci passe en production et le
programme pourrait générer automatiquement un message à destination du service de la production
pour lui signaler de lancer les pièces commandées en production.
Ensuite le module comptabilité développé a été refait avec les nouveaux outils de
développement en Eclipse et amélioré par rapport à l’ancienne version en 4GL. Ces modifications ont
été nécessaires pour le passage à l’euro.
Pour finir, en Suisse Méga Informatique vend Précix E03 CH, certains modules ont été
spécialement modifiés pour les clients suisses. Par exemple comme une partie des clients sont des
horlogers, ces derniers produisent des pièces de montres aux caractéristiques différentes. Ainsi dans le
module des données techniques des articles, il est possible de configurer 60 caractéristiques
spécifiques à une famille d’articles (telles que la taille, la couleur, le poids...)
11
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
2. Précix est structuré autour d’une base de données
Le progiciel propose aux utilisateurs une gestion en temps réel grâce à l’utilisation d’une base de
données. Le système de gestion de bases de données le plus répandu avec Précix est Informix. Ce
dernier propose la gestion de bases relationnelles. Le développeur doit ainsi connaître le langage SQL
pour accéder aux informations.
a. INFORMIX, le SGBD adopté par Précix
Informix est un système de gestion de bases de données (désigné par la suite par l’acronyme
SGBD) relationnelles qui peut s’adapter aussi bien sur les plateformes de types Unix, Linux ou
Windows. Le noyau du SGBD possède une architecture baptisée Dynamic Scalable Architecture basée
sur le principe du « multi enfilement » (de l’anglais multi-threading) qui parallélise les traitements
d’accès aux données. La puissance de ce moteur réside ainsi sur la possibilité de proposer des
connexions simultanément.
Chaque requête SQL utilisateur est analysée et décomposée en tâches élémentaires. Le serveur
devient performant et supporte de plus grands volumes simultanés. De par sa conception, cette
architecture permet une extensibilité linéaire du système, au fur et à mesure que de nouvelles
ressources sont ajoutées. Le SGBD a initialement été choisi par Sylob grâce à ses performances et à
ses outils de développement Informix 4GL et 4J’s qui lui ont permis de développer la première version
de Précix en mode texte. Bien qu’avec les outils de développement sous Eclipse, Précix peut s’adapter
au SGBD d’Oracle, leader dans la matière, Informix reste la référence pour fonctionner avec ce
progiciel. En effet, le développement de l’ensemble de l’ERP se fait à l’appui de bases de données
sous Informix et certaines instructions sont ainsi propres à ce SGBD. De plus, Méga Informatique est
un distributeur officiel d’Informix et dispose des compétences pour cette application.
Comme il a été précité, Informix est système de gestion de bases de données relationnelles et
ces systèmes sont de très loin les plus utilisés. Les données sont représentées en tables, sont
structurées et accessibles par un langage déclaratif basé sur l’algèbre relationnel (SQL pour Structured
Query Language). Une base de données contient donc plusieurs tables qui possèdent des liens entre
elles avec une gestion cohérente des données et sans contenir des informations redondantes. De plus
chacune de ces tables contient des champs spécifiques au domaine auquel elle se rapporte. La figure
1 illustre les relations entre les tables avec l’exemple d’une commande. Les champs soulignés
représentent la clef des tables, c'
est-à-dire qu’ils caractérisent un l’unicité de l’enregistrement.
Figure 1 : Schéma relationnel simplifié dans le cas d'une commande vente
Les données du client sont séparées de l’entête de la commande. Cela permet de changer
l’adresse du client sans avoir besoin de le faire au niveau de la commande. La structure des données
est ainsi optimisée puisque le nombre d’enregistrements est limité.
b. Le langage SQL convient aussi bien aux débutants qu’aux développeurs confirmés
SQL est le langage unique qui permet de décrire, manipuler, contrôler l'
accès et interroger les
bases de données relationnelles. C'
est un langage déclaratif, qui s'
adresse à la fois aux utilisateurs
"novices" et aux programmeurs confirmés. Il est régi par une norme (ANSI/ISO) qui assure la portabilité
du langage sur différentes plateformes aussi bien matérielles que logicielles. Une commande SQL
12
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
écrite dans un environnement Windows sous ACCESS peut, souvent sans modification, être utilisée
directement dans un environnement INFORMIX sous Unix… Les commandes SQL se répartissent sur
trois groupent définis sur le tableau suivant.
Catégories
Commandes SQL Fonctionnalité
Description des données
(DDL : Data Definition Language)
Manipulation des données
(DML : Data Manipulation Language)
Contrôle des autorisations
(DCL : Data Control Language)
CREATE
ALTER
DROP
DESCRIBE
RENAME
SELECT
INSERT
UPDATE
DELETE
GRANT
REVOKE
COMMIT
ROLLBACK
Création de tables
Modification de tables
Suppression de tables
Description des colonnes d’une table
Renomme une table
Interrogation diverses de la base
Insertion de lignes dans une table
Mise à jour de lignes dans une table
Suppression de lignes dans une table
Attribution de droits d’accès
Suppression de droits d’accès
Prise en compte des mises à jour
Annulation des mises à jour
Chaque commande SQL possède une structure spécifique qu’il faut absolument respecter sinon
le SGBD ne reconnaîtra pas la requête. La catégorie la plus utilisée par Précix est la manipulation de
données. L’instruction SELECT est de loin la plus utilisée par l’ERP. En fait, le progiciel consiste à
cacher des instructions SQL derrière une interphase graphique facile à utiliser par les utilisateurs. Pour
créer une requête d’interrogation de la base de données, il faut ajouter des clauses. Celles utilisées par
l’instruction SELECT sont décrites dans le tableau suivant.
Clause
Attributs
SELECT
Nom colonnes
FROM
WHERE
GROUP BY
HAVING
ORDER BY
Fonctionnalité
Précise les colonnes qui vont apparaître dans la réponse. L’opérateur
DISTINCT permet d’éliminer les doublons et des fonctions peuvent
être utilisées.
Précise la (ou les) table intervenant dans l'
interrogation
Nom tables
Précise les conditions de restriction à appliquer sur les lignes. On
peut trouver :
Expression sur colonnes - Des comparateurs : =, >, <, >=, <=, <>
- Des opérateurs logiques : AND, OR, NOT
- Les prédicats : IN, LIKE, NULL, ALL, SOME, ANY, EXISTS...
Précise la (ou les) colonne de regroupement
Nom colonnes
Expression sur colonnes Précise la (ou les) conditions associées à un regroupement
Précise l'
ordre dans lequel vont apparaître les lignes de la réponse :
ASC / DESC
- ASC : En ordre ascendant (par défaut)
- DESC: En ordre descendant
Une requête SQL peut vite devenir compliquée dès que l’on commence à faire des jointures entre
des tables, des regroupements et la clause de restriction (WHERE) peut prendre des proportions
impressionnantes. Ainsi dans un souci de clarté, il est préférable de simplifier au maximum les
requêtes. Cela peut se faire parfois en séparant les requêtes de liaison et en stockant les données
dans des variables pour les traiter ensuite par le langage de développement. Plus les requêtes sont
simples, plus les temps de réponse sont courts. Il est bien évidemment primordial que les délais
d’attente soit les plus courts possibles. Une méthode pour diminuer l’accès à une table de données
consiste à indexer la table en sélectionnant les champs prioritaires. Cette opération est utile si le
nombre de lignes est très important (supérieur à 10'
000) sinon elle produira l’effet inverse. De même à
chaque création de tables, il est préférable de définir une clef primaire qui assure l’unicité des
enregistrements.
Bien que le langage SQL soit normalisé, cela garantit que les instructions normalisées
fonctionnent sur n’importe quel système de gestion de bases de données relationnelles, chaque SGBD
possède des fonctions ou des instructions qui lui sont propres. Par exemple, l’instruction LIKE dans la
13
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
clause WHERE permet de sélectionner les champs qui possèdent des caractères communs avec la
chaîne de caractères suivant l’instruction. Sous Informix, il existe une instruction similaire s’appelant
MATCHES. Elle propose la même fonctionnalité sauf que, dans la chaîne de caractère de restriction,
les champs inconnus doivent être symbolisés par des * à la place des %. Finalement l’utilisation de ces
instructions propres à Informix posera des problèmes si le programme développé s’appui sur un SGBD
d’un autre éditeur. En utilisant uniquement les instructions normalisées de la version SQL92 (normalisé
en 1992), il serait possible d’utiliser n’importe quelle base de données relationnelle adaptable au
produit de CI-Soft pour Précix.
3. Les outils de développement de la version Eclipse
La version de Précix dite sous « Eclipse » est développée à l’aide d’outils de la société CI-Soft
basée à Saint-Étienne. Ces outils sont au nombre de trois et chacun possède son propre mode de
fonctionnement et ses caractéristiques. La partie suivante permettra au lecteur de découvrir l’univers de
programmation de Précix.
a. La complémentarité des produits CI-SOFT
Hormis le système de gestion des bases de données, l’ensemble de l’application de Précix en
Eclipse fonctionne avec les produits de CI-Soft. Il existe deux déclinaisons de ces logiciels, la version
de développement et celle d’exécution dite de « runtime ». La première version est utilisée par Sylob et
Méga Informatique pour développer des programmes. Elle permet également de tester des
programmes non compilés. La version « runtime », quant à elle, ne fonctionne uniquement avec des
programmes compilés. Les produits CI-Soft sont au nombre de trois et fonctionne suivant la figure 2.
Figure 2 : Liens entre les produits CI-Soft et le SGBD
Chacun des produits CI-Soft bénéficiera par la suite d’une explication détaillée. Ces produits sont
peu répandus dans le monde du développement et les nouveaux arrivants à Méga Informatique doivent
apprendre à les utiliser. La société qui édite ses logiciels est basée à Saint Étienne et vend à ses
clients des journées de formation. Il arrive parfois que Méga Informatique loue les compétences d’un
développeur de CI-Soft pour développer des programmes fastidieux.
b. L’outil graphique CI-Builder, de bonnes idées pénalisées par des bugs
L’environnement graphique
CI-Builder est le logiciel avec lequel a été développée la version Eclipse de Précix. C’est un
environnement de programmation événementiel et visuel proche de Visual Basic de Microsoft. Il a été
choisi par Sylob pour développer les nouvelles versions de Précix pour son interface graphique plus
conviviale que le langage 4GL, anciennement utilisé. CI-Builder se définit comme un environnement de
développement d’interfaces.
L’interface graphique permet de créer une fenêtre, que nous appellerons palette. Pour regrouper
plusieurs palettes en une application, un projet doit être créé. Il existe une variante du projet, qui ne
14
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
contiendra pas de palette, les librairies. Elles permettent d’isoler des fonctionnalités de base et de les
rendre utilisables par plusieurs projets. Ensuite, des boutons de différents types (un champ de saisie,
une liste, une case à cocher…) peuvent être ajoutés sur chacune des trois entités précédentes.
Cependant uniquement ceux qui seront placé sur la partie visible de la palette seront directement
accessibles par l’utilisateur. La figure 3 représente cet environnement graphique précédemment décrit.
Figure 3 : L'environnement de CI-Builder
La figure 3 correspond à la modification d’un projet. Effectivement la partie encadrée en rouge
représente le niveau du projet. La liste affichée correspond aux différentes palettes qu’il contient.
L’onglet au-dessus permet de passer aux menus ou aux boutons du projet. Les parties en verte
représentent le niveau de la palette, celle-ci est à droite et ses propriétés à gauche. Enfin, les parties
en bleu désignent le niveau du bouton. Le bouton sélectionné, ici en haut sur la palette, a ses
propriétés affichées en bas à gauche de l’écran. Le code du bouton s’affiche dans une fenêtre
contenant du texte.
Toutes sortes d’applications peuvent être créées mais CI-Builder est particulièrement adapté à la
création d’applications pour des systèmes « Client – Serveur ». Les données sont centralisées sur un
même poste : le serveur, et tous les autres postes « client », captent ses données depuis ce poste.
Ainsi CI-Builder est destiné à s’associer à une base de données.
Le langage de programmation
Le code se trouvant derrière cette interface graphique facilite le développement car c’est un
langage basé sur le « 5Talk ». Le code possède une syntaxe très proche du langage parlé, bien
évidemment en anglais. Mais cet avantage devient vite un défaut. En effet, ce code étant très explicite,
15
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
il devient volumineux. Pour un traitement très simple, on se retrouve avec plusieurs lignes de code
d’une certaine longueur. Par exemple, pour affecter une valeur à une variable, il faut écrire : « Put
Valeur into Variable » alors qu’en Perl ou en C, il suffit de mettre un égal.
Un script correspond à l’ensemble du code sur un objet. Il peut contenir des fonctions et des
traitements de message appelés « handler ». Les fonctions et les handlers sont délimités par On
(début) et End (fin). Les scripts peuvent exister à tous les niveaux (bouton, palette et projet). Par
exemple sur une palette, peuvent figurer des fonctions utilisées par plusieurs boutons d’une palette.
Sur un projet peuvent figurer des fonctions utilisées par plusieurs boutons de différentes palettes du
projet. Pour exécuter un handler ou une fonction, on lui spécifie sont emplacement (ex :send modified
to btn "no_cde", exécution du handler « modified » sur le bouton « no_cde ») ou non (ex : do modified).
Dans ce cas, le programme va essayer de trouver le code en suivant le parcours de la figure 4. Dans le
langage courant, on dit que le code monte dans les niveaux supérieurs. Pour complémenter cette
découverte, en annexe 1 se trouve les codes basiques de CI-Builder.
Figure 4 : Parcours d'une commande sous CI-Builder
Les limites de ce langage
Le logiciel doit s’allouer de la mémoire et celle-ci malheureusement n’est pas extensible. Ainsi,
CI-Builder est limité : chaque palette ne peut contenir plus de 255 objets et le code derrière chaque
objet ne peut dépasser 32768 caractères. De même une variable quelconque ne peut pas dépasser ce
nombre fatidique ce qui peut être dangereux lorsque l’on extrait des données de la base. On comprend
vite que dans des programmes complexes, et avec un langage explicite et volumineux, on arrive vite à
la taille limite du script. Ainsi il faut parfois ruser et, lorsqu’un objet arrive presque à la limite, créer un
nouveau bouton et avec le code auquel le bouton précédent fera appel. Ces limites sont les principales
failles de CI-Builder car certains programmes de Précix présente des palettes proches des 255
boutons. Pour réaliser des modifications sur ces palettes, il faut faire de la place. Ces défauts ont été
corrigés dans la dernière version de CI-Builder mais comme la majorité des clients utilisent des
anciennes versions, les développeurs continuent de les utiliser. À cela s’ajoutent les subtilités de
certaines fonctions et quelques bugs. Par exemple, une fonction de valeur absolue existe. Cependant
elle ne fonctionne que sur les entiers. Le résultat de cette fonction sur un réel renvoie sa partie entière
positive.
c. Le générateur d’états CI-Query, simple mais très limité
Le logiciel CI-Query est appelé un générateur d’états. En effet, il offre la possibilité de créer des
documents en utilisant des données issues de la base. Les utilisateurs utilisent leur ERP pour gérer
leur entreprise. Le progiciel doit ainsi proposer la possibilité d’imprimer certains documents. Par
exemple, le module de gestion commerciale propose la génération d’offre, de commande, de bon de
livraison ou encore de facture, pour ne citer que les documents les plus connus. Ainsi le développeur
doit souvent intégrer cette possibilité lors de la création de son programme. Le programmeur utilise le
plus souvent le logiciel CI-Query pour créer ses documents. Les avantages de ce dernier sont de
16
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
s’intégrer parfaitement au logiciel de développement CI-Builder et d’utiliser facilement les bases de
données.
Les étapes de la création d’un document peuvent se résumer aux lignes suivantes :
définition des variables envoyées par CI-Builder,
création des données à partir la base à partir d’un générateur de requêtes SQL,
mise en forme du document par l’utilisation de sections, objets complexes (correspondant à une
sous-section) et cellules qui contiennent des informations,
test du document après l’avoir intégré aux programmes sources de Précix.
L’état de CI-Query peut aussi contenir des informations fixes (nom, logo et adresse de
l’entreprise). Les informations variables proviendront de la base de données. La figure 5 représente un
état en mode développement.
Figure 5 : Un état CI-Query en mode développement
17
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
L’outil met à disposition un certain nombre de fonctions et d’opérateurs. L’opérateur plus utilisé
est certainement decode (condition ; valeur1 ; valeur2) qui équivaut à : si condition alors valeur1
sinon valeur2. Cependant cet outil est loin d’être parfait. En plus d’être truffé de bugs, le logiciel ne
propose pas assez de fonctionnalités et ne permet de créer que des documents simples. Cependant il
est très simple à utiliser puisqu’il suffit de connaître le langage SQL pour créer des états.
d. Le logiciel intermédiaire CI-Link, un langage plus classique
Le logiciel CI-Link est un middleware, que l’on pourrait interpréter comme une couche logicielle
intermédiaire. Il sert d’intermédiaire entre les applications conçues sous CI-Builder et CI-Query et le
SGBD. Une interface permet de définir l’emplacement des bases à utiliser et de faire des tests de
connexion. Par la suite, ce logiciel est constamment utilisé à chaque échange avec la base de
données. Cependant ce logiciel propose de créer des programmes, appelées fonction CI-Link (à tord
car elles ne renvoient pas forcément un résultat), qui s’exécuteront directement sur le serveur
disposant du SGBD.
Les fonctions CI-Link sont des scripts qui s’exécutent à un niveau de programmation supérieur à
celui de CI-Builder. Elles sont écrites, avec un code ressemblant plus à un langage de programmation
classique avec un éditeur de texte. La fonction CI-Link une fois écrite doit être dotée de l’extension
« .cil », pour être appelée par CI-Builder à l’aide d’un handler défini par Sylob :
ExeFCT(version, module, nom_fonction, parametres)
Ces fonctions sont intéressantes du fait que les traitements sont réalisés au niveau du serveur,
sans rapatrier les données sur le poste client. Il devient ainsi utile de les utiliser lorsqu’il s’agit de faire
des modifications sur une base ou de faire des traitements avant d’envoyer des données à CI-Builder
afin qu’elles ne dépassent pas les 32768 caractères.
La création de fonction est cependant loin d’être parfaite. Même s’il existe de nombreuses
possibilités pour utiliser les bases de données, on se rend compte qu’en traitant certaines données qu’il
n’existe pas beaucoup de fonctions. Il faut ainsi rajouter des lignes de codes pour combler ces lacunes.
18
Xavier MOGHRABI
IFI 2003
II.
Rapport technique
Stage IFI 3
La diversification du travail de développement
1. Les documents CI-Query personnalisés pour des clients
Les caractéristiques d’un progiciel sont d’être paramétrable et configurable pour les clients. Pour
cela, Méga Informatique propose de personnaliser les documents, principalement commerciaux,
utilisés par la société. La plupart des documents sont réalisées avec CI-Query et le développeur se
rend vite compte des limites de ce logiciel.
a. La création et les retouches de documents
Comme précisé auparavant, le logiciel CI-Query est un générateur d’état. Il propose de créer des
documents, destinés à être imprimés, à partir des données de la base de Précix. La deuxième tâche
proposée pendant le stage consistait à retoucher des documents existants afin de les paramétrer aux
demandes précises d’un client.
La première retouche de deux documents de suggestion d’achats et d’approvisionnement
consistait à aligner les champs entre les lignes et le total pour Girard Perrigaux, un horloger prestigieux
et précis. Le problème à cette tâche était que le document était constitué d’objets complexes
permettant de réaliser une sous-section dans la section d’un document. En fait, on définit une section
pour une source de données. Pour chaque nouvel enregistrement de la source, une nouvelle ligne est
créée. Cependant si l’on souhaite rajouter à l’intérieur d’une section une autre source de données, il
faut utiliser un objet complexe. Le problème provenait de la difficulté à aligner les cellules de la section
avec celles de l’objet complexe. En effet, il est possible de positionner une cellule grâce à ses
coordonnées par rapport au bord haut gauche de la section ce qui n’est pas possible avec les objets
complexes. La seule possibilité d’être précis est d’encadrer les cellules concerner, de passer en mode
prévisualisation, de zoomer et d’aligner les cadres.
Pour seconde mission, il fallait créer les offres d’achat et de vente dans le même modèle que les
commandes d’achat et de vente. La différence notable entre ces deux types de document concerne
l’affichage du prix total pour chaque ligne d’article. Le document de l’offre doit comprendre un prix
unitaire en fonction du nombre d’articles commandés. Le plus souvent, plus ce nombre est élevé,
moins le prix unitaire est important. Pour réaliser cette tâche, les documents de commandes ont été
modifiés. Il a fallu par moment ajouter de nouvelles données en y ajoutant une source, en supprimer
d’autres et modifier les champs de certaines. En effet, lorsque Précix lance l’impression de commandes
d’achat ou de vente, une fonction CI-Link remplit une table de données qui servira de source pour
remplir l’entête du document. Cependant cette opération ne se fait pas lors du lancement de l’offre ainsi
il fallait rechercher ces données dans la base telles que les coordonnées du destinataire.
Certaines modifications de documents consistaient seulement à rajouter des champs et à aligner
des cellules. Par exemple, l’entreprise Rollomatic avaient fait une liste de modifications à réaliser pour
ses documents d’offre et de commande d’achats. Toutes ses demandes ont été corrigées. Cette
retouche de document a été vite réalisées car la liste des modifications étaient claire et que le client
nous a fournit par fax le document qu’il obtenait entourant les modifications qu’il souhaitait.
Ainsi les tâches précédentes ont été modifiées avec succès. Cependant certaines corrections de
documents ne se sont pas si bien déroulées. Le plus souvent les problèmes rencontrés provenaient de
l’outil de développement.
b. Les difficultés rencontrées principalement dues aux limites de l’outil
Un certain nombre de problèmes ont été rencontrés pour retoucher des documents de
commandes d’achat et de vente et les factures d’achat. Un collègue avait créé ces documents pour
19
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Girard Perregaux. Celui-ci n’était pas pleinement satisfait car des différences de format de texte
apparaissaient sur le document suivant l’imprimante utilisée. Ainsi pour éviter ce désagrément, le
concepteur du document a utilisé l’option « police logique » à la suite du conseil du développeur du
logiciel. Cependant un nouveau problème apparut, lors de certaines impressions les derniers
caractères des cellules contenant les prix, alignés à droite, étaient tronqués.
La première solution trouvée consista alors à ajouter un espace à la fin de chaque cellule.
Néanmoins de cette manière nous perdions l’alignement entre les prix des lignes en taille 10 et les
totaux en taille 12 puisque l’espace était plus grand. Le logiciel ne permet pas d’ajuster la taille des
caractères par ensemble de caractères, comme sous Word, mais par cellule. Ainsi sans réelle solution,
un message électronique a été envoyé au concepteur du logiciel pour lui relater le problème avec
image scannée à l’appui. Lui, non plus n’a pas trouvé une solution mais a conseillé de rajouter un
espace à la fin de chaque cellule et de les déplacer entre elles de quelques pixels afin de corriger
l’alignement. Ainsi le logiciel paraît cruellement manquer de précision.
En retouchant un document concernant le module SAV pour Clarville, un fabricant de pièces de
téléphone portable, un problème peu commun est arrivé. Dans le module SAV, il est possible de gérer
le retour d’articles défectueux. Tout d’abord, le programme crée à partir du code de l’article une copie
de cet article avec un code commençant par « SAV ». Ensuite sur cet article, il sera possible de lui
attribuer des opérations de corrections afin de remettre l’article en conformité. Ces opérations peuvent
parfois nécessiter l’ajout ou le remplacement de composants, qui seront affectés aux opérations.
Pour pouvoir réaliser cette correction, un devis doit être au préalablement créé et pourra être
édité. Il permet de choisir les opérations à réaliser et les composants à utiliser. Ensuite ce devis peu
passer en production et ainsi un ordre de fabrication est généré. Une fois les corrections effectuées, le
produit sera livré au client avec un bon de livraison. Finalement si les corrections sont facturables, dans
le cas où l’article n’est plus garanti, une facture peut être créée.
Ainsi le client souhaitait que le détail des opérations de correction figure sur trois documents : le
devis, le bon de livraison et la facture. Pour cela, les documents respectifs ont été modifiés en rajoutant
un objet complexe contenant ces champs à partir d’une table spécialement créée pour l’occasion.
Cependant ces documents sont utilisés à la fois par les modules commercial et SAV. Il fallait donc
cacher la section de l’objet complexe si le document provenait du SAV. La première idée consistait de
cacher si le numéro de fiche SAV n’est pas supérieur à 0. De cette manière, on ne cherchait pas à
savoir si, lorsque le document était lancé par le programme commercial, le champ précédant était vide
(représenté par dans la base) ou indéfini (représenté par Null).
L’expression était ainsi
cacher=(({SAV.no_fic}>0)=Faux).
En testant le document sur le poste de développement la clause fonctionnait parfaitement. Ainsi
le document fut installé chez le client. Ce dernier téléphona pour signaler que les documents ne
fonctionnaient pas, que la section ajoutée n’apparaissait jamais. En testant le programme par
télémaintenance sur le serveur du client, une solution fut trouvée en mettant la clause suivante :
Cacher =({SAV.no_fic}=Null) Ou ({SAV.no_fic}= )
Le plus étrange était le fait que formule précédente fonctionnait sur le poste de développement
mais pas sur le serveur du client alors que la version de développement était rigoureusement la même.
Ces deux exemples de développement montre en quelque sorte des défauts de CI-Query.
Cependant une fois qu’ils sont connus, le développeur connaît les méthodes pour éviter de les
reproduire. Beaucoup de défauts peuvent être reprochés à ce logiciel, d’ailleurs ces deux derniers ne
sont pas les seuls expérimentés. Le risque encouru en développant des documents sur CI-Query est
de ne pas être crédible face au client. Pour le dernier cas, par exemple, le client lorsqu‘il a essayé les
20
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
documents livrés, il n’a pas eu l’impression que le document ait été modifié. Il ne reste plus qu’à
espérer que chaque nouvelle version du logiciel corrige les bugs des précédentes.
2. L’amélioration du module SAV
Tout au long du stage, différents projets ont été proposés afin d’améliorer le module de Service
Après Vente développé par Méga Informatique. Les modifications ont vu le jour, soit à la suite d’une
demande de correction d’un client sur un programme, soit pour proposer de nouvelles fonctionnalités.
Ces travaux ont ainsi permis l’utilisation du logiciel de développement, CI-Builder.
a. Le module SAV et son fonctionnement
Ce module a été développé par Méga Informatique, dans un premier temps, suite à un besoin de
ses clients en Suisse. Cette industrie est, à l’image du pays, composée d’entreprises de petite ou
moyenne taille. Un grand nombre des clients de la société travaille dans l’industrie horlogère,
dénommée par le terme industrie mécanique de précision. La plupart du temps, les entreprises sont
spécialisées sur un type de pièces composant les montres. Par exemple, la laminerie Matthey située à
la Neuveville au dessus de Neuchâtel fabrique les aiguilles de montres, un autre client fabrique les
rondelles du mécanisme… Finalement une entreprise plus connue, telle que Girard Perregaux
assemble l’ensemble de la montre.
Ainsi comme les productions de ces entreprises se font en petites séries, il faut pouvoir repérer
les produits défectueux pour les retoucher. Dans ce genre d’industrie, les critères de qualité sont très
exigeants et ainsi pour cette raison le module SAV a connu un succès beaucoup plus important qu’en
France. Ce module a l’avantage d’exister uniquement en mode standard. Il n’existe pas de spécifiques
à des clients. Ainsi si un client demande des améliorations pour le logiciel, elles seront intégrées aux
versions suivantes.
Ainsi ce module propose de suivre les produits au delà de leur commercialisation. Le programme
met en place une fiche de vie des éléments maintenus. En fait, lorsqu’un article est retourné, Précix
crée un article spécial pour le SAV qui sera une copie de celui retourné. Ce dernier article sera rattaché
à une fiche d’intervention. La fiche permet d’attribuer des notions de garantie et de repérer l’article
retourné par son numéro de série. Ainsi la fiche propose, soit de générer un devis, puis une
commande, un ordre de fabrication, un bon de livraison et finalement une facturation (s’il y a besoin
d’être), soit de faire une proposition d’échange, puis un bon de livraison et une facture d’échange. Ce
module constitue également une base de connaissances consultable par des menus de statistiques ou
d’historiques.
b. Les petites améliorations ou corrections
Un certain nombre de petites modifications ont été réalisées la plupart du temps pour corriger des
bugs de programmation. La plupart du temps, l’analyse était au préalablement réalisée par le
responsable de la maintenance que s’occupe également du développement de ce module.
La première modification concernait le menu de paramétrage des types de garantie. Le
programme représenté en figure 6 consiste à indiquer un coût. La case doit être cochée lorsque la
garantie est payante et décochée lorsqu’elle est gratuite.
21
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Figure 6 : Fiche de saisie d'une garantie
La modification aurait du laissée le choix entre 4 cases pour le coût de garantie. Une case pour
« hors garantie », une seconde « garantie sur opération et main d’œuvre », une troisième « garantie
sur les composants » et la dernière « garantie totale ». Cependant après avoir modifié le programme, le
développement suivant a montré que cette modification était à abandonner. En effet, les codes de
garantie sont par la suite utilisés lors de la génération de devis et l’utilisateur choisit un code de
garantie pour les opérations et un second pour les composants. Ainsi le choix entre les deux types de
coût suffisait.
La seconde modification a permis de modifier la création du devis. Le module SAV permet, en
l’état actuel de gérer des codes de garantie, simplement à titre informatif. Ce mode de fonctionnement
n’a pas particulièrement gêné les utilisateurs. L’amélioration réalisée concerne ainsi le prix du devis qui
prendra en compte ces codes attribués, devenus par ailleurs obligatoires. La principale difficulté était
de se plonger dans le code du programme car le menu était beaucoup plus important que le précédent.
Le devis obtenu après modification illustre la figure 7. Pour l’utilisateur, seul le champ « coût
facturable » a été ajouté.
Figure 7 : Menu de saisie du devis
Au niveau des boutons, du code a été rajouté pour rendre obligatoire la saisie des codes de
garantie. Pour cela, lorsque le prix de l’opération ou le nombre d’opérateurs étaient modifiés et
supérieurs à 0, la couleur de la cellule du code de garantie devenait jaune. Une fonction définie dans la
22
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
librairie de Précix permet de vérifier sur une palette si tous les champs jaunes sont remplis. Le code
rajouté sur ces boutons avait la syntaxe suivante :
If me >0 then
Set the bodyColor of btn cd_garOp to 2
End if
Comme on le voit la syntaxe a l’avantage d’être facilement compréhensible. Cependant elle
devient vite gênante car elle est plus longue à écrire que celle sur d’autres langages de programmation.
Un code similaire a été placé sur le bouton du composant pour activer le code de garantie. Mais aussi
un code a été placé pour mettre les garanties non obligatoires si ces champs n’étaient pas renseignés.
Pour calculer le champ « coût facturable », les formules de calcul de la cellule « coût de
l’intervention » ont été reprises en les multipliant par le coût de garantie approprié. Pour avoir ce coût,
la requête de sélection suivante a été faite : select cout from sav_tabgar where cd_gar= (cd_gar) .
Elle a été placée au niveau d’un bouton du projet afin de regrouper toutes les requêtes. Pour appeler
cette requête, on doit utiliser une fonction définie par Sylob :
vpmSQL(id où se trouve le bouton ici projet, Nom_de_la_requete,les paramètres)
Cette fonction permet de faire du code propre car elle évite de concaténer les requêtes puis de les
exécuter. Cette modification a été l’opportunité pour découvrir certaines fonctions de Précix et les
méthodes de programmation. En ajoutant une nouvelle fonctionnalité, un bug de réaffichage des
composants a été même corrigé.
c. La création d’un nouveau projet de statistiques des interventions
À la suite de l’amélioration précédente, une nouvelle fonctionnalité a due être créée afin de
présenter des statistiques de coût concernant l’intervention. Dans le menu des statistiques, une liste
récapitulative affichera suivant le regroupement choisi les différentes interventions avec le prix réel de
l’intervention (sans la prise en compte des garanties) et celui facturable (avec les garanties).
Dans un premier temps, il a fallu s’intéresser à la structure des données dans la base. Les tables
utilisées peuvent être représentées sur la figure 8.
Figure 8 : Schéma de la structure des données
23
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Le schéma précédent montre qu’il existe une jointure externe entre la table des opérations
sav_basdefop et celle des composants sav_basdefcomp puisque que, pour une opération d’un devis, il
peut y avoir de 0 à n composants.
Nom du champ
No_fic
No_art
No_cli
Cd_pro
Cd_sav
No_dev
Ord_oper
Position
Cd_gar
Cout
Cout_op
Cout_pers
Taux_oper
Tps_fab
Cout_unit
Qte_struct
Définition
Type (Maximum ou Longueur)
Numéro de la fiche SAV d’intervention
Entier (2.109)
Identifiant de l’article dans la fiche SAV
Texte (17)
Numéro du client
Entier (2.109)
Code de provenance
Texte (5)
Code SAV
Texte (5)
Numéro du devis
Entier (2.109)
Position de l’opération dans la table
Entier (32768)
Position du composant dans la table
Entier (32768)
Code de garantie
Texte (5)
Coût de la garantie (1 : pour hors garantie, 0 pour sous- Entier (32768)
garantie)
Coût de l’opération
Réel
Coût horaire des opérateurs travaillant sur l’opération
Réel
Nombre d’opérateurs
Réel
Temps (h) de travail des opérateurs sur l’opération
Réel
Coût unitaire du composant
Réel
Nombre de composants utilisés
Réel
Ainsi le coût de l’intervention représente le coût sans la prise en compte de la garantie et celui
facturable prend en compte ce dernier champ. On obtient ainsi différentes formules.
But
Coût de l’opération
Coût du composant
Formule
Cout_op + ( cout_pers * taux_oper * tpsfab)
Cout_unit * qte_struct
Pour obtenir les coûts facturables, il suffit de multiplier ces formules par le champ cout de la table
des garanties sav_tabgar. Une fois ces formules définies, le stagiaire a donc commencé la création du
projet. Pour cela, il est parti à partir des autres menus de statistiques existants. Ainsi la palette créée a
un design similaire aux palettes existantes. Des boutons ont été ajoutés, d’autres supprimés mais le
principe reste le même. L’utilisateur ouvre la palette, il peut saisir des dates de bornage des
statistiques. Il choisit un ordre de tri et lance les calculs en cliquant sur un bouton qui remplit une liste.
La palette créée est présentée sur la figure 9.
24
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Figure 9 : Palette des statistiques sur les coûts
Tout se passe lorsque l’utilsateur clique sur le bouton “Recharger la liste”. Le code commenté de ce
bouton ainsi que la fonction CI-Link utilisée ont été mis en annexe 2. Quand l’utilisateur clique sur ce
bouton, une fonction est exécutée. Elle remplit une table, créée spécialement pour ce menu,.qui
contient des données temporaires pour remplir la liste et permettre l’impression. Cette table contient les
les couts interne et facturable des opérations et les sommes de ces coûts sur les composants par
opération. Elle contient également les données de la table sav_basvie et le code d’identification du
processus sur le serveur. Cette derniere colonne permet d’identifier le créateur des données:
L’utilisateur verra ainsi les données qu’il souhaite et les supprimera de cette table lorsqu’il quittera le
programme. En fait cette colonne est une sécurité dans le cas où plusieurs personnes utilisent ce
programme similtanément.
Ensuite, une fois la fonction exécutée, une requête SQL somme les données suivant le regroupement
choisi. Les coûts sur les opérations et les composants sont additionés pour remplir les colonnes des
totaux. Des boucles d’itération permettent finalement de remplir les cellules. L’utilisation de la fonction
CI-Link a simplifié la procédure. En fait cette fonction sélectionne, en regroupant par opération, les
coûts d’opérations interne et facturable. Ensuite pour chaque enregistrement obtenu, la fonction
somme, en regroupant par opération, les coûts de composant interne et facturable. Chaque
enregistrement est inséré dans la table sav_statcout.
Au début, le stagiaire avait l’intention de réaliser une requête directement sous CI-Builder pour
sélectionner les données. Cependant comme il est difficile de réaliser correctement une somme d’une
somme et que s’il y a des champs indéfini (dit “null”), il est impossible de faire des calculs, la méthode
précédente a été adoptée. De plus en exécutant la fonction, directement sur la serveur de données, le
temps d’éxécution est assez rapide (3s pour une quarantaine d’interventions).
d. La reconstruction de la palette de modification des devis
En conséquence à l’amélioration précédente, la palette de création du devis a donc été modifiée.
Un champ correspondant au coût facturable a été ajouté. Ce dernier est calculé selon les formules
définies précédemment. Sur cette palette, il existait déjà un bouton correspondant au coût interne de
l’opération. Le stagiaire a ainsi parcouru l’ensemble des codes des objets de la palette en recherchant
les lignes modifiant le bouton contenant le coût interne. Puis il a rajouté à la suite des lignes pour
25
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
remplir le bouton du coût facturable. Pour cela, une requête SQL a été utilisée afin de rechercher le
coût de la garantie suivant le code garantie saisi. Au passage, le stagiaire a corrigé quelques bugs
d’affichage et a rendu la saisie des codes de garantie obligatoires (les cellules sont jaunes). Le résultat
est visible sur la figure 10.
Figure 10 : Palette de la fiche de saisie du devis
Le programme présenté ci-dessus permet uniquement de créer un nouveau devis. Il est
accessible à partir du menu de la fiche de suivi d’intervention en SAV. Un autre programme avait été
créé pour modifier le devis. Cependant il ne proposait que de changer les coûts, les garanties et les
codes défaut. Au début, le responsable de ce module souhaitait que le programme puisse modifier le
coût facturable du devis dans la base de données et qu’il soit possible de rajouter et de supprimer des
composants.
En s’attaquant au code du programme le stagiaire s’est vite rendu compte que ce programme est
arrivé à ce stade à la suite de nombreuses petites améliorations. Le menu devait initialement proposer
la modification de la quantité et du coût unitaire des composants. À la suite de demandes de client, il
s’est enrichit de nouvelles fonctionnalités. Cependant cette démarche rend ainsi la modification du code
source délicate. Le stagiaire a ainsi pris l’initiative de rebâtir cette palette pour pouvoir modifier tous les
champs présents dans le programme de création du devis. Tous les codes de la palette existante ont
été supprimés hormis le « handler » commandant son ouverture « open ».
Les tables utilisées sont celles figurant sur la figure 8. La nouveauté sur ce programme provient
de l’utilisation d’objets appelés des « clusters ». Tout d’abord un cluster se connecte à une table dans
la base de données et permet d’afficher, de modifier ou d’insérer un enregistrement. Quant on crée un
cluster, on lui spécifie la table à laquelle il est associé. Ensuite on sélectionne les champs que l’on
souhaite afficher. Le logiciel propose alors de créer les boutons de type « edit control » (ou zone de
texte) qui contiendront les données de la table. Ainsi dans la palette créée, tous les boutons visibles se
rapportant aux tables suivantes : dev_dgamop, sav_basdefop, dev_dtpsgam, dev_dnom et
sav_basdefcomp sont issus de clusters. Des boutons ont été cachés car lors d’insertion d’un nouvel
enregistrement, les champs ne doivent pas être indéfinis. Ainsi cette palette contient 5 clusters.
26
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
L’avantage du cluster est la simplification du code et la vitesse d’exécution. Pour ouvrir des
données, il suffit d’envoyer sur le cluster le code suivant :
Send SQLOpen « mode d’ouverture », « la clause where » to btn « Cluster »
En fait le mode d’ouverture peut être « update » avec une clause where pour rendre accessible la
modification ou « insert » sans clause where pour ajouter un nouvel enregistrement. Pour valider les
changements, il suffit d’envoyer sur le cluster le code :
Send SQLSave to btn « Cluster »
Selon le mode d’ouverture, le programme réalise une mise à jour des données (update) ou ajoute
une nouvelle ligne à la table (insert). Il est également possible de supprimer l’enregistrement
sélectionné en remplaçant, dans le code précédent, SQLSave par SQLDelete.
Ainsi en plaçant ces commandes dans les handlers des objets adéquats, le stagiaire a mis en
place la possibilité de modifier, d’ajouter ou de supprimer des opérations ou des composants. Ensuite
le travail a consisté à améliorer la présentation. Ainsi la palette a été séparée en deux. En haut les
cellules concernant les opérations et en bas les composants. Comme précédemment un champ
représentant le prix du devis a été ajouté. Il tient compte du code de garantie et se voit modifier en
temps réel lorsque l’utilisateur modifie un devis. Les figures 11 et 12 montrent le menu respectivement
avant et après sa rénovation.
Figure 11 : Ancien menu de modification de devis
Le nouveau menu comporte un bouton assez intéressant situé au-dessus de la case du numéro
de devis. En cliquant dessus, l’utilisateur peut dupliquer le devis existant et ensuite le modifier. Cette
amélioration a été réalisée suite à une demande d’un client qui souhaitait faire plusieurs devis. Ensuite
un seul des devis similaires pourra être validé et attaché à une fiche d’intervention. Derrière ce bouton
se cache une fonction CI-Link qui duplique toutes les tables du devis selon la méthode suivante.
But
Requête ex.
But
Requête ex.
But
Requête ex.
But
Requête ex.
Insertion existant du devis dans une table temporaire
Select * from dev_dgamop where no_dev =100614 into temp tmpdgamop
Remplacer l’ancien numéro de devis par le nouveau dans la table temporaire
Update tmpdgamop set no_dev=100615 where no_dev=100614
Insérer les données de la table temporaire dans la table existante
Insert into dev_dgamop select * from tmpdgamop
Supprimer la table temporaire
Drop table tmpdgamop
27
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Le lecteur peut naturellement se poser la question pour quelle raison n’insère-t-on pas
directement les données sans passer par la table temporaire. Cette autre méthode fonctionne tout à
fait, néanmoins il faudrait spécifier dans la clause « select » le numéro de devis à modifier et écrire tous
les noms de colonnes. Ainsi si la table était ultérieurement modifiée, il faudrait toucher à la fonction.
Dans le cas adopté comme les colonnes ne sont pas spécifiées, ce problème ne se pose pas. La figure
12 montre que le nouveau module de modification de devis est beaucoup plus complet que l’ancienne
version.
Figure 12 : Nouveau menu de modification de devis
Ainsi le travail sur ce module a été l’occasion d’utiliser les clusters, ces objets qui permettent de
connecter des zones de texte directement à une table de données. Les modules ont par ailleurs été
enrichis en fonctionnalité. Maintenant il est possible de créer plusieurs devis et par la suite d’en affecter
un à la fiche de suivie d’intervention. Cependant le travail requis s’est étendu sur 10 jours. Il a fallu
quasiment recréer une nouvelle palette.
3. Le travail sur des spécifications pour des clients
La société propose à ses clients de développer des applications spécialement pour eux, afin que
le logiciel réponde parfaitement aux besoins de l’entreprise. Il faut tout d’abord savoir qu’il existe un
programme standard de Précix qui est systématiquement installé chez le client. Si celui-ci souhaite
disposer de nouvelles fonctionnalités, il peut acheter à son intégrateur des journées de développement
de programmes de spécification. Ainsi quelques missions de stage ont consisté à développer
directement pour les clients.
a. L’impression des caractéristiques de template horloger
En plus d’avoir développé les modules de la Comptabilité et du Service Après Vente, Méga
Informatique a modifié certains programmes standards exclusivement pour la Suisse. Elle a ajouté
certaines caractéristiques spécialement pour répondre aux besoins des horlogers. Ainsi, pour un article
il est possible de lui affecter jusqu’à 60 caractéristiques. Cette amélioration a été également très utile
pour les clients produisant en petites séries. La figure 13 représente le menu de sélection des
caractéristiques d’un article.
28
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Figure 13 : Menu de saisie des caractéristiques des articles
Ces caractéristiques sont par la suite imprimées sur certains documents tels que les fiches
suiveuses de production. Un client utilisant cette fonctionnalité souhaitait imprimer les caractéristiques
mais sous forme de quatre colonnes à l’image du tableau suivant.
Libellé 1
Libellé 3
Caractéristique 1
Caractéristique 3
Libellé 2
Libellé 4
Caractéristique 2
Caractéristique 4
Le générateur d’état CI-Query ne donne pas la possibilité de réaliser simplement cette mise en
forme. Il est possible d’avoir seulement deux niveaux de section en utilisant les objets complexes.
Cependant ces objets se connectent à une source de données et affiche directement leur contenu.
L’idée retenue consiste donc à obtenir une table contenant les données précédentes. La table suivante
a ainsi été définie.
Nom du champs
No_art
No_seq
Lib1
Val1
Lib2
Val2
Nom de la table : zz_edifsuiv
Description
Code de l’article possédant les caractéristiques
Compteur pour ordonner les caractéristiques
Libellé de la caractéristique sur la 1ère colonne
Caractéristique sur la 1ère colonne
Libellé de la caractéristique sur la 2ème colonne
Caractéristique sur la 2ème colonne
Type
Texte (17)
Entier (32768)
Texte (40)
Texte (30)
Texte (40)
Texte (30)
Pour remplir ces données avant l’impression de la fiche suiveuse, une fonction CI-Link sera
exécutée directement sur le serveur. Le fonctionnement de celle-ce est détaillé en annexe 3.
Le programme utilise 3 tables :
- pro_ofent : table d’entête d’un ordre de fabrication,
- zz_paramcaractart : table qui contient les libellés des caractéristiques rattachées à une famille
d’articles (comme taille, poids et couleur sur la figure 13),
- zz_caractart : table des caractéristiques (tels que 60mm, 120 mg et BLEU sur la figure 13),
- zz_libcaract : table qui contient la description de certaines caractéristiques (comme COULEUR
BLEUE sur la figure 13).
Le code d’article est issu de pro_ofent. Le libellé de la caractéristique provient donc de
zz_paramcaractart. La caractéristique est issue de zz_libcaract si ce champ existe, sinon de
zz_caractart.
29
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Juste cette petite modification a demandé trois jours de travail de conception, développement,
test et d’intégration. Cette nouvelle fonctionnalité permet d’imprimer les caractéristiques en prenant
deux fois moins de place qu’auparavant.
b. Le spécifique des retours de consignation
La société Clarville, cliente de Méga Informatique sous-traite la fabrication de téléphones
portables et d’autoradios pour de grandes sociétés. Elle distribue également ses produits et propose
leur réparation. Cette société utilise la version e02 de Précix. Autrefois un programme spécifique a été
développé pour la gestion des consignations avec les mouvements de stocks. En fait Clarville prête à
ses clients ses produits pour des démonstrations. Ce programme lui sert à déterminer les produits chez
les clients. Lorsque le client rend le matériel emprunté, le logiciel réalise un retour de consignation.
Cependant le programme propose uniquement de retourner la totalité de la consignation. Clarville a
donc demandé à Méga Informatique d’améliorer le spécifique pour remettre en stock un seul article ou
une partie des articles.
-
Le programme actuel fait appel à une fonction CI-Link à la suite d’une série de tests pour :
mettre à jour les stocks (table : sto_histmvt),
rajouter que le retour a eu lieu (table : zz_blcon),
mettre à jour la table des numéros de série (table : sav_noser).
Tout d’abord, pour pouvoir livrer des quantités de consignations, une nouvelle table a été crée. Elle
permettra d’avoir un historique des retours de lignes de consignation.
Nom du champs
No_bl
No_lig
No_retour
Date
Qte_livr
Qte_retour
Etat_lig
Nom de la table : zz_ligcon
Description
Numéro de la consignation
Numéro de ligne dans la consignation
Numéro du retour d’une ligne de consignation
Date du retour relatif au retour
Quantité livrée relative à la ligne de consignation
Quantité retournée relative au retour
État de la ligne de retour (1 : saisie, 7 : imprimée et validée)
Type
9
Entier (2.10 )
Entier (32768)
Entier (32768)
Date
Réel
Réel
Entier (32768)
Une seconde table est créée pour faire la relation entre la ligne de retour et le numéro de série. Cette
table a été volontairement séparée de la précédente car plusieurs numéros de série sont affectés à une
ligne de retour si la quantité retournée est supérieure à 1. Si un article retourné n’a pas de numéro de
série, cette table ne sera pas remplie.
Nom du champs
No_bl
No_lig
No_retour
Noser1
Etat_lig
Nom de la table : zz_retournoser
Description
Numéro de la consignation
Numéro de ligne dans la consignation
Numéro du retour d’une ligne de consignation
Premier numéro de série
État de la ligne de retour (1 : saisie, 7 : imprimée et validée, 6 : effacée)
Type
Entier (2.109)
Entier (32768)
Entier (32768)
Texte (32)
Entier (32768)
Une fois les tables créées, le stagiaire a construit la palette correspondant à la figure 14.
30
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Figure 14 : Menu des retours de consignation
La palette contient deux listes. Celle du haut correspond aux lignes de la consignation et celle du bas à
l’historique des retours. Ces deux listes sont chargées à partir des bases de données dès l’ouverture
de la palette. La quantité retournée est calculée en faisant un somme regroupée par ligne de
consignation.
Pour créer un retour de consignation, l’utilisateur doit passer en mode modification en cliquant sur le
bouton
. Ensuite les boutons d’ajout et de suppression de retour (en face de l’historique des retours)
et de validation et annulation (en face du détail des lignes) s’activent. En cliquant sur le bouton +,
l’utilisateur ajoute une nouvelle ligne de saisie et pourra saisir la date, la quantité retournée et les
numéros de série. Une fois que l’utilisateur clique sur le bouton de validation les données sont insérées
dans la base et la liste se met à jour.
Le programme dispose d’une option d’annulation des modifications en cliquant sur le bouton
. Cette
fonctionnalité est réalisable car à l’ouverture de la palette, les données relatives à la consignation
sélectionnée des tables zz_ligcon et zz_retournoser sont chargées dans deux listes cachées. Ainsi en
cliquant sur ce bouton, un handler supprime les lignes de la consignation et insère celles d’origine.
L’utilisateur valide ses changements en cliquant sur le bouton
.
Les mouvements de stocks sont réalisés lorsque les lignes de retour de consignation sont imprimées.
Un menu pour imprimer les retours a été réalisé en s’inspirant de ceux déjà existant. Dans Précix, pour
valider des documents comme les consignations, commandes ou factures, il suffit de les éditer.
L’utilisateur n’est pas obligé de les imprimer, il peut en demander un aperçu. Ainsi la même méthode a
été adoptée pour les retours de consignation. Le programme d’impression met le champ état de la ligne
à 7 lors de l’édition et lance une fonction. Cette dernière a but principal de faire les mouvements de
stocks et de libérer les numéros de série utilisés. La fonction CI-Link est décrite plus précisément en
annexe 4.
c. Le spécifique pour l’annulation des retours de consignation
Le programme créé précédemment propose de créer des retours de consignation et de les
valider. Cependant nous ne proposons pas au client de revenir sur sa décision une fois un retour
validé. Ainsi un programme permettant d’annuler les retours de consignation validés a été développé.
31
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Le stagiaire est parti sur une palette à peu près identique à la précédente. Elle a été beaucoup plus
facile à développer puisqu’il connaissait les propriétés des objets utilisés. La palette se trouve sur la
figure 15.
Figure 15 : Palette d'annulation des retours de consignation
L’utilisateur ne peut exécuter que quatre actions. Il doit au début renseigner le numéro de
consignation, soit directement, soit en cliquant sur une liste déroulante. Ensuite les lignes de la
consignation ainsi que les retours apparaîtront. Il pourra sélectionner sur la liste en bas les retours qu’il
veut annuler. Une colonne fait apparaître l’état de la ligne, l’imprimante représente une ligne validée, le
stylo une ligne saisie et la poubelle une ligne annulée. Bien évidement CI-Builder propose cet affichage
de symboles. Il faut juste définir une fonction qui renvoie le numéro du dessin suivant l’état de la ligne.
Une fois que l’utilisateur a réalisé ses changements, il peut soit les annuler, soit les valider. S’il
choisit le bouton d’annulation, le programme met seulement à jour les états de lignes qui ont été
modifiés en remplaçant l’état 6 par 7. Le code SQL est ainsi le suivant :
Update zz_ligcon set etat_lig=7 where no_bl=279 and etat_lig=6
La validation lance une fonction qui fera le mouvement de stock inverse. Elle passera les articles
du stock dans l’entreprise dans le stock de consignation. Les numéros de série libérés par le
programme précédent seront, s’ils ne sont pas affectés, réutilisés. Cette fonction est également
consultable en annexe 5.
32
Xavier MOGHRABI
IFI 2003
III.
Rapport technique
Stage IFI 3
Des développeurs polyvalents sont indispensables à une
petite structure telle que Méga Informatique
1. L’installation des logiciels
Deux procédures sont utilisées pour installer le logiciel. La première consiste à installer les
programmes directement sur le serveur du client. Cette méthode est adoptée lors de l’installation de
logiciels complets tels que le SGBD ou Précix. La seconde procédure, de télémaintenance, est utilisée
pour installer quelques programmes compilés, fonction CI-Link ou documents et pour tester les
problèmes de clients sans se déplacer.
a. L’installation de la base de données Informix, un travail d’administration
La première étape, pour mettre en place l’ERP, consiste à installer la base de donnée sur le
serveur. Généralement ce serveur sert dans un premier temps de démonstration pour que les
utilisateurs se familiarisent progressivement avec le progiciel. Pour installer Informix, le système
d’exploitation du serveur doit être destiné aux serveurs, tel que Windows 2000 Serveur, Linux ou Unix.
Le maître d’œuvre de cette installation est le spécialiste des bases de données et des réseaux de
Méga Informatique car il connaît les paramètres appropriés au bon fonctionnement.
Tout d’abord, il configure les paramètres du réseau en spécifiant une adresse IP fixe, qu’il aura
obtenu préalablement auprès du responsable informatique du client. Cette adresse permettra aux
postes clients de trouver le serveur de données. Elle commence par 192.168.1 pour spécifier qu’elle
est propre au réseau local. Le formatage du disque doit être en NTFS pour les dernières versions de
Windows car ce formatage est le plus performant et destiné aux applications du réseau.
L’installation se fait à partir du cd-rom d’Informix. Il faut spécifier le numéro d’instance du serveur
Informix puisqu’il est possible de créer plusieurs instances. Ensuite l’installateur configure le port
TCP/IP pour accéder aux bases de données, le numéro de port est 1526. Il spécifie l’espace disque.
On parle alors de disque logique, appelé DBspace, et de disque physique, désigné par Chunk. Il sera
possible de choisir dans quel disque logique les tables de données seront placées. Le disque physique
contient réellement les données, il arrive que l’espace disque arrive à saturation. Il faut soit créer un
nouveau disque logique, soit vider les sauvegardes.
La figure 16 représente la structure des différentes entités, elle montre par exemple qu’une
licence Informix possède plusieurs instances qui, elles-mêmes, comprennent plusieurs bases…
Figure 16 : Struture des entités sous Informix
Une fois l’installation d’Informix achevée, l’installateur utilise son savoir-faire pour paramétrer le
fichier de configuration (onconfig) qui s’ouvre avec un simple éditeur de texte. Cette étape permet
d’augmenter les tailles affectées au disque logique de base, au fichier permettant de réaliser les
Commit – Rollback, de configurer le type du support d’archivage (disque, cassette ou fichier)... Ce
ficher sert également à attribuer de la mémoire pour les buffers, qui accélèrent les transmission et pour
les locks qui servent à bloquer des enregistrement.
En fait, tout le travail d’installation est concentré sur le paramétrage de ce fichier car cette étape
permettra d’optimiser le fonctionnement du système. Cette tâche demande des connaissances dans
l’administration de bases de données mais également de l’expérience. Par exemple, l’installateur
33
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
choisira d’ajouter un nouveau chunk car il sait que les bases de données Précix prendront une
importante partie de la place disponible. De plus, pour pouvoir se prémunir contre les risques
informatiques, il faut disposer d’un système de sauvegarde pour pouvoir réinstaller la base si cette
dernière était abîmée
b. L’installation de Précix, un procédure simple mais qui peut réserver des surprises
L’installation du progiciel Précix se fait en deux temps. Tout d’abord, on installe une version sur le
serveur si son logiciel d’exploitation est de Microsoft. Cette étape est réalisée par un développeur. Si le
serveur est de type Unix ou Linux, il est inutile d’installer Précix puisqu’il ne fonctionne pas sur ces
systèmes. La technique consiste donc à installer Précix sur un poste de type Windows qui se
connectera à la base de données Informix. Cette version serveur de Précix contient les programmes
compilés de référence. Ainsi il sera possible de mettre à jour les programmes de tous les postes clients
à partir de ce poste. Il servira également aux opérations de télémaintenance. La seconde étape de
l’installation du progiciel se fait sur les postes clients avec lesquels les utilisateurs travailleront.
L’installation de Précix installe les logiciels d’exécution dits de runtime des outils de CI-Soft. Tout
d’abord, il faut paramétrer le service CI-Link sur le serveur en indiquant le compte qui l’utilisera. Un
écran demande un numéro de licence. Pour l’obtenir, il suffit d’appeler la société CI-Soft en lui
communiquant comme informations : le nom du client, le numéro de commande et le nombre
d’utilisateurs. Cette protection empêche la copie illégale du logiciel puisqu’une fois le numéro de licence
obtenu, le nombre de connections simultanées est limité au nombre d’utilisateurs. Ensuite il faut
déclarer les sources de données utilisées par Précix. Pour cela, il suffit de spécifier l’adresse IP du
poste qui dispose d’Informix. Il est possible de déclarer les bases de données qui seront utilisées par la
suite, puis de tester la connexion. Lorsque l’on installe la base de données de Précix, le programme
lance un fichier qui crée l’ensemble des tables puis insère des données d’exemple.
Le progiciel peut être installé sur des postes clients équipés d’un logiciel d’exploitation de
Microsoft. La manipulation est simple, il suffit de rechercher sur le cd-rom la version runtime
correspondant au système d’exploitation puis de l’exécuter. Lorsque Précix est installé, une fenêtre,
représenté sur la figure 17, s’ouvre demandant d’être paramétrée.
Figure 17 : Menu de configuration de l'installation de Précix
Sur la première ligne, l’installateur sélectionne le répertoire contenant les programmes
d’exécution de Précix. Sur la seconde ligne, il indique l’emplacement du fichier « Project.ini » qui se
trouve sur le serveur. Ce fichier est indispensable à la déclaration des fonctions CI-Link. S’il n’est pas
renseigné, les fonctions ne fonctionneront pas. L’utilisateur doit spécifier le chemin sur le serveur et
doubler les slashs. Il est possible de spécifier la version de Précix mais cette case n’a pas d’utilité. Il
faut ensuite spécifier le nom de la base système et la langue. La ligne aide HTML doit être rempli en
spécifiant l’emplacement de l’aide de Précix. L’onglet Applications Externes propose de configurer les
chemins des applications de Windows qui pourront être exécutées à partir de Précix.
34
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
L’installation de la version E03 de Précix sur les postes clients est très rapide et identique pour
tous les postes. Cependant il arrive parfois que l’installateur rencontre des problèmes lorsque les
ordinateurs sont mal configurés. La démarche face à ce type de problème mène l’utilisateur à
demander de l’aide à Sylob ou à CI-Soft. Néanmoins il arrive que ces deux dernières n’arrivent pas à
trouver une solution. L’installateur essaye ainsi toutes les idées qui lui passent par la tête pour venir à
bout de l’installation.
c. La télémaintenance évite certains déplacements
Il existe une procédure qui permet d’installer des programmes chez les clients sans se déplacer
sur son site. Cette méthode est appelée télémaintenance. En réalité, elle nécessite l’installation d’un
logiciel sur le serveur du client qui s’appelle PC-Anywhere. Ce programme permet de prendre le
contrôle du serveur à distance grâce à un modem. Il est possible alors de transférer des programmes
sur le serveur et de les tester en utilisant Précix directement sur le serveur.
Pour se connecter en télémaintenance, le développeur demande au client d’utiliser son logiciel
PC-Anywhere en se connectant en tant qu’élève, par modem, sur le poste de télémaintenance de
Méga Informatique. Le développeur, quant à lui, lance le logiciel précédent et attend une connexion en
tant que maître. Une fois la connexion établie, le développeur voit sur son écran la session du serveur
du client. Il a alors le contrôle du serveur et peut lancer Précix comme s’il était chez le client. Le
principal défaut de ce type de connexion provient de la lenteur due à la connexion par modem.
Cette méthode est utilisée pour mettre à jour des fichiers ou installer des programmes
spécifiques. Il suffit alors de transférer les fichiers sélectionnés, de les installer sur le serveur, de les
tester et de mettre à jour les postes clients à partir de Précix. Les développeurs de Méga Informatique
utilisent la télémaintenance pour visualiser les problèmes des clients. Il est ainsi possible de trouver à
quel niveau se trouve un problème et ainsi de le corriger. Cette procédure évite les déplacements
inutiles. Elle permet aux développeurs de répondre à plusieurs demandes de maintenance des clients
au cours d’une même journée.
2. Le travail sur un projet en informatique
Pour mener à bien un projet informatique comme la création d’un programme spécifique, il faut
suivre une procédure standard. Elle consiste à faire l’analyse du besoin du client, puis le développer et
le tester. Chacune de ces étapes sera ainsi explicitée pour mieux en comprendre le déroulement. Pour
achever le projet, il suffira d’installer les fichiers informatiques.
a. L’analyse du projet, pour démarrer sur de bonnes bases
Avant de commencer la programmation d’un projet, il faut réaliser l’analyse. Cette étape est
obligatoire pour fournir au client un service qui corresponde au mieux à son besoin. Une fois, que le
client a exprimé son besoin, un analyste programmeur prend le relais et étudie la faisabilité du projet.
Ensuite, il rédige dans un langage technique un document imposant les critères du programmes. Son
but est de concevoir le programme et les fonctionnalités qui sont associées à chaque bouton mais
également de chiffrer la durée du projet et de déterminer le nombre d’acteurs.
L’analyste doit impérativement connaître ou prendre connaissance de la méthode de gestion
appliquée chez le client pour que le nouveau programme s’intègre à l’ERP harmonieusement. Ce
métier demande ainsi des compétences supérieures à celles d’un développeur car le maître d’œuvre
doit à la fois connaître les méthodes de gestion et les outils informatiques. Son analyse devra par la
suite servir au développement et l’auteur doit utiliser les langages de représentation des données
comme le modèle relationnel pour décrire les relations entre les tables de la base de données.
Une fois l’analyse réalisée, le développeur peut commencer la programmation du projet.
L’analyse est comparable au squelette du projet car elle définit les bases du fonctionnement du
programme. Si cette analyse est mal réalisée, le projet cours le risque d’être un échec car il ne
35
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
répondra pas aux besoins du client. Ainsi cette étape est la plus importante pour que le projet parte sur
de bonnes bases.
b. Le développement, une course contre la montre
Cette phase fait appel au savoir-faire du programmeur. Il se base à partir de l’analyse pour créer
le programme. Le développeur doit très bien connaître l’environnement de développement et avoir de
l’expérience pour créer des programmes possédant le minimum de défauts. Ceci est d’autant plus vrai
sur les produits de CI-Soft. Les outils de développement comportent quelques bugs et des subtilités de
programmation. Ainsi un programmeur expérimenté saura passer à travers les pièges des logiciels
alors qu’un nouveau développeur, programmant selon les logiques apprises ou acquises sur d’autres
logiciels, se heurtera à des problèmes connus des autres développeurs. Il arrive même que ces
problèmes finissent par détruire le programme sur lequel le développeur travaillait. Ainsi il est préconisé
de faire une copie de sauvegarde du programme développée. L’outil CI-Builder propose une option de
faire une sauvegarde le soir des programmes modifiés dans la journée. Cette option devient utile
lorsqu’un matin le développeur place, par exemple, plus de 255 boutons sur une palette et que cette
dernière ne s’ouvre plus. Ainsi le nouvel arrivant chez Méga Informatique a beaucoup à gagner en
demandant des conseils de développement auprès des programmeurs expérimentés. Mais avant de
perturber ses collègues en plein travail, il est souhaitable qu’il cherche soit même une solution à son
problème.
Pour que le nouveau développeur soit vite productif, ce dernier doit connaître absolument le
langage SQL. Il doit bien entendu posséder les bases de l’algorithmique et si possible connaître les
langages évènementiels. Une fois ces cartes en main, rien n’est gagné. L’apprentissage des outils CISoft est long en raison des subtilités de programmation. CI-Query est un outil très facile à manier mais
il faut parfois ruser pour arriver à ses fins. Par exemple, il faut parfois afficher une variable, en la
mettant de couleur blanche, pour pouvoir l’utiliser dans des expressions. De même, il arrive que le
logiciel plante parce qu’une cellule contient une expression incorrecte. Cependant l’outil ne précise pas
l’emplacement de l’erreur et la méthode de réparation consiste à supprimer les cellules une par une
pour déterminer celle qui pose problème. Le logiciel CI-Builder est largement plus intéressant pour un
développeur. Il est facile de maîtriser les bases de programmation en connaissant les mots clefs.
Néanmoins l’outil offre une quantité impressionnante d’objets et de fonctions qui augmentent les
possibilités de programmation du logiciel. Par exemple, il existe deux manières d’utiliser les bases de
données : soit le programmeur tape ses requêtes et les exécute par une fonction de CI-Builder, soit il
connecte certains objets à une source de données et leur gestion est quasiment automatique. Ces
options proposées permettent de programmer plus vite.
Le programmeur doit impérativement respecter les délais et achever les programmes le plus
rapidement. Cette contrainte de temps, associée à un logiciel parfois capricieux, fait courir le risque de
mener le projet sur un échec. La plupart du temps, les délais accordés au développement sont
suffisants. Néanmoins il arrive parfois, à cause d’un imprévu tel qu’un problème de CI-Builder, que le
temps accordé soit dépassé. Le développeur doit donc programmer vite, tout en évitant les pièges des
outils de CI-Soft.
Le développeur apprend continuellement de CI-Builder et en plus les versions du logiciel se
succèdent à une incroyable cadence. Le logiciel présente sans cesse des nouveautés que le
programmeur doit assimiler.
c. La phase de test garantit la qualité du produit
Cette étape est primordiale pour obtenir des programmes de qualité. Le développeur, une fois
qu’il a achevé son projet, doit se mettre dans la peau d’un utilisateur. Il doit tester les fonctionnalités de
son programme de bout en bout. Pour détecter les bugs de programmation, il doit effectuer des
manipulations imprévues sur des boutons inappropriés. C’est une partie assez difficile à réaliser pour le
développeur lui-même car il a défini le fonctionnement normal de son programme dont il lui est difficile
de s’en écarter.
36
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Il existe des moyens pour éviter de créer des bugs. Le premier consiste à utiliser le logiciel de
correction de CI-Builder. En rajoutant dans l’instruction du programme le code debug true dans un
handler, une fenêtre se lance à la rencontre de ce code. Cet outil propose de confirmer ligne par ligne
l’avancée du programme. Lorsque le logiciel rencontre une erreur, il affiche un message. Ainsi le
développeur sait exactement quelle ligne du handler pose problème. L’outil fournit également l’état des
variables à chaque instant et ainsi le programmeur sait si une variable est mal affectée.
Le second moyen pour corriger des programmes est un fichier texte comparable à un rapport
établi par CI-Link. Ce fichier est appelé « fichier Log de CI-Link » car son extension est log. Il contient
toutes les instructions que CI-Link exécute. Par exemple, lorsqu’un code de CI-Builder exécute une
requête dans la base de données, celle-ci est présente car elle passe par CI-Link qui permet de relier
les produits CI-Soft à la base de données. Une ligne détaille si l’instruction exécutée contient une erreur
ou non. Ainsi en consultant ce fichier, il est possible de savoir si les requêtes ont été correctement
exécutées ou si les fonctions CI-Link ont été parfaitement bien appelées. Si la requête comporte une
erreur de syntaxe, le fichier contiendra un message d’erreur renvoyé par Informix. De cette manière, le
développeur pourra corriger la requête défectueuse. Il est en plus possible d’utiliser un fichier log pour
une fonction CI-Link. Il suffit de rajouter au début de la fonction le code « set log="nom fichier" » et à la
fin « set log="" » pour stopper l’écriture dans le fichier. Le fichier généré contient toutes les lignes du
programme. Il détaille les instructions et affiche s’il y a une erreur lors de l’exécution de la ligne de
code.
Il arrive qu’un programme ne fonctionne pas chez le client, bien qu’il ait échappé aux tests sur le
poste du développeur. Ce dysfonctionnement a pour origine les différences des versions des produits
CI-Soft. Ainsi l’étape de test s’étend jusqu’à l’installation de programmes chez le client.
3. Un bilan de stage très satisfaisant et enrichissant
Hormis l’ambiance très chaleureuse qui règne à Méga Informatique, le bilan du stage est
largement très satisfaisant. Tout d’abord, le stagiaire a découvert le travail de développement d’un
projet informatique en entreprise. Ensuite il a essayé d’apporter son aide à la société. Les autres
employés ont largement surpris les attentes du stagiaire car la plupart sont des techniciens mais ont
des responsabilités envers les clients et de larges compétences.
a. Un travail de développement intéressant mais avec des outils capricieux
Le travail réalisé par le stagiaire a principalement été du développement. Il a développé quelques
spécifiques, améliorer le module SAV et corriger quelques bugs. Le travail proposé a été intéressant
car l’environnement de développement lui était inconnu. La première phase du stage a ainsi consisté à
s’adapter le plus rapidement possible à ces outils. Cette étape a été vite surmontée par sa
connaissance du langage SQL et par la pratique d’autres langages de programmation tels que le
langage C, le Perl, le Fortran ou encore le basic. Que CI-Builder soit un langage de type évènementiel
n’a pas rajouté de difficultés car, en fait, les handlers présents sur chaque objet sont de type
procédural. Il a ainsi fallu comprendre les liens entre les objets pour disposer le code.
Le langage CI-Builder propose l’avantage pour les débutants d’être très facile à prendre en main
puisqu’il est basé sur le langage naturel en anglais. Ainsi pour trouver par exemple une fonctionnalité, il
suffit d’écrire celle-ci en anglais dans l’index de l’aide et il arrive parfois de trouver le mot clef se
rapportant à cette-ci. Le langage se veut tellement proche de l’anglais qu’il tient même en compte de
notion de grammaire. Ainsi le développeur doit être vigilent lorsqu’il écrit ses instructions et ne pas
oublier d’accorder les noms au pluriel. Sa structure devient vite pour le programmeur expérimenté un
inconvénient puisque les instructions sont longues à écrire. Il aurait sûrement aimé que le langage
comprenne beaucoup plus d’instructions raccourcies.
37
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Créer des états avec CI-Query est très simple. Les nouveaux arrivants commencent usuellement
avec cet outil. Cependant les fonctions du logiciel se révèlent vite limités face à certaines demandes de
clients. Ce logiciel n’est pas apprécié des développeurs car il possède de très nombreux défauts et de
bugs. Le développeur peut passer beaucoup de temps pour créer un document simple à cause de
problèmes qu’il rencontre. Par exemple, il arrive fréquemment que la fenêtre se ferme en affichant un
message d’erreur de mémoire. Cet évènement devient vite agaçant lorsque le document n’a pas été
récemment sauvegardé. Les clients se plaignent également de CI-Query puisqu’ils rencontrent des
problèmes.
Le dernier langage découvert au cours du stage sert à créer les fonctions CI-Link. Il est plus
proche des langages que les développeurs ont l’habitude de rencontrer. Ils possèdent des
imperfections mais globalement il pose moins de problème de programmation. Tout d’abord, comme
les fonctions sont créées par un éditeur de texte, le développeur ne rencontre pas de problèmes
caractéristiques à l’environnement de développement. Il dispose d’atouts. Tout d’abord, la manipulation
de données issues d’une base est très rapide, ensuite il est obligatoire de définir les variables. Ainsi il
n’y a pas de confusion pour cet outil ce qui n’est pas le cas pour CI-Builder. En feuilletant la
documentation, le développeur constate qu’il manque certaines fonctions et instructions présentent sur
d’autres langages.
b. Les résultats obtenus ont-ils constitué un gain pour la société ?
La fin du stage doit apporter la réponse à la question : « le stagiaire a-t-il atteint les objectifs du
stage ? ». Tout d’abord, le premier objectif consistait à s’intégrer avec les employés de la société. Le
stagiaire a même été surpris de l’agréable accueil réservé par chacun des membres de Méga
Informatique. L’ambiance conviviale au sein de la société, créée par ses employés permet aux
stagiaires de s’intégrer facilement. Les employés sont jeunes et partagent certaines activités avec les
stagiaires. De plus pour le travail, le stagiaire a du volontairement venir auprès des développeurs pour
leur demander de lui fournir un projet.
Le second objectif consiste à proposer un travail de qualité. Le développement des programmes
a été fait en s’appuyant sur les méthodes transmises par les autres développeurs. Le stagiaire a passé
une partie importante à réaliser les tests et a fait valider les programmes auprès du responsable avant
l’installation chez le client. Ainsi les programmes fonctionnaient pour les fonctionnalités souhaitées.
La société qui a accueilli le stagiaire a vraisemblablement profité momentanément d’un
développeur supplémentaire. Sa présence a permis à d’autres employés de se décharger d’une partie
de leur travail. Une amélioration du module SAV a pu ainsi être réalisée.
Le stagiaire a essayé d’être au maximum autonome pour ne pas être un fardeau pour ses
collègues. Ainsi lorsqu’il rencontrait en problème, il recherchait en priorité dans les documentations
existantes. Il demandait conseil à ses coéquipiers que si cette recherche a été infructueuse. Ainsi il
arrivait parfois que certains programmes fussent momentanément bloqués le temps de trouver une
réponse au problème.
Malencontreusement tous les objectifs n’ont pas été atteints, la proposition de stage stipulait
l’utilisation du logiciel Crystal Report. Le stagiaire n’a pas eu l’opportunité de travailler sur cet outil. En
effet, durant la période de stage il y eût très peu de documents créés par ce logiciel et le stagiaire a été
à partir du mois de juin occupé par des développements sous CI-Builder. Il s’est ainsi plus spécialisé
dans la programmation sous CI-Builder, découvrant jour à jour de nouvelles fonctionnalités.
c. Les compétences multiples des informaticiens, la force de l’entreprise
Les informaticiens de Méga Informatique se distinguent par leurs multiples compétences. Ils ont
été formés pour maîtriser les techniques de programmation. Ils maîtrisent cette tâche et savent utiliser
plusieurs langages de programmation. Il arrive parfois que certains développent des programmes sous
Visual Basic de Microsoft pour pouvoir intégrer le logiciel Crystal Report à Précix. Le responsable de la
38
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
maintenance et du module service après vente a, par exemple, développé une application performante
pour gérer les demandes de maintenance sous Windev. Un ingénieur en génie logiciel, récemment
embauché, est un spécialiste des langages objets tels que Java ou .Net…
Ces informaticiens sont devenus également des experts de Précix. Ils fournissent de précieux
conseils aux clients lorsque ces derniers les appellent pour obtenir des explications. Cependant, il est
remarquable de voir que ces programmeurs arrivent à adapter leur langage, en laissant de côté les
termes techniques, pour que les clients puissent les comprendre. Il est souvent difficile lorsque l’on
travaille dans un domaine si technique de réussir cet exercice. Ces employés utilisent leur
connaissance de Précix pour quasiment réaliser eux-mêmes leurs programmes spécifiques. Le plus
souvent les documents fournis aux développeurs font partie du besoin du client mais n’explicitent pas la
manière pour réaliser le programme. Les développeurs doivent parfois joindre le client pour obtenir des
précisions et même, parfois, pour leur dire que ce qu’il désire n’est pas réalisable.
Les développeurs ne font pas que programmer, ce sont les premiers interlocuteurs avec les
clients. Lorsqu’une demande de maintenance arrive à Méga Informatique, un développeur tentera de
dépanner le client. Ils se rendent également chez le client pour réaliser des installations, faire des
corrections qui ne peuvent être faites que sur place… Leurs compétences sont multiples car ils
interviennent pour n’importe quel problème du client. Ils doivent même jouer les commerciaux en
faisant passer certaines demandes du client pour des améliorations, et non des corrections, qui
pourront être facturées.
d. Les leçons du stage
Ce stage a permis tout d’abord de découvrir l’EPR Précix du côté de l’édition. En effet, le
stagiaire a réalisé l’année précédente son stage à Sylob et a découvert Précix mais en tant
qu’utilisateur. Il a ainsi pu voir les deux côtés du monde, celui de l’utilisateur et celui du développeur.
Lorsque l’on utilise le progiciel, on critique facilement certains programmes, exaspéré de trouver des
bugs. Cependant programmer un ERP aussi vaste que Précix n’est pas simple. Les nouveaux
programmes doivent s’insérer parfaitement dans le système d’information sans nuire à un programme
existant.
Le travail effectué a été une opportunité pour apprendre à utiliser un environnement de
programmation jusqu’alors inconnu. Le stagiaire a pu essayer le travail de programmeur et faire fasse à
des problèmes dus à ce nouvel environnement. Il été sensibilisé aux contraintes de développement
caractérisées par la durée limitée du développement, le but à atteindre et les caprices des outils de
programmation. L’articulation du système d’information a permis de découvrir un système de gestion de
bases de données de renommée, Informix et de perfectionner l’enseignement reçu à l’École des Mines.
Finalement, à travers cette expérience, le stagiaire s’est demandé où se trouve la place d’un
ingénieur sortant de l’option Gestion du Système d’Information de l’école. Il est clair qu’une le travail sur
un logiciel de gestion intégrée tel Précix fait partie de ses compétences. Cependant la place d’un tel
ingénieur n’est pas vraiment au développement puisqu’il n’est pas spécialisé dans la programmation.
Sa place est plutôt dans la conception d’un tel progiciel car il dispose de l’ensemble des cours
théoriques de gestion industriel dispensés à l’École des Mines et de l’expérience acquises au contact
du milieu industriel. La place de l’ingénieur peut être également chez les clients de Méga Informatique
comme chef du projet de la mise en place et de l’entretien de l’ERP. Son rôle sera alors de superviser
le déploiement de la solution, d’encadrer les utilisateurs et de garantir la pérennité du progiciel et du
SGBD. Grâce à sa formation, il saura prendre en compte les risques liés à un tel projet et trouver des
solutions correctives. L’expérience acquise au cours des deux stages précédents permettra à l’élève
d’intégrer l’option précitée avec déjà une certaine connaissance d’un ERP.
39
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
CONCLUSION
Méga Informatique est une petite structure de 15 personnes qui développe des modules d‘un
logiciel de gestion intégrée (ERP). Dans ce contexte, les développeurs doivent apprendre à utiliser les
moyens peu communs de programmation qui servent aux développements. Ils doivent plus ou moins
se former de manière autonome, apprendre à utiliser les différents outils et leur langage et à respecter
les procédures de programmation. Les outils de développement, élaborés par la société CI-Soft, repose
sur de bonnes idées de complémentarité mais manquent cruellement de stabilité et de fonctionnalité.
Le système de gestion de bases de données, adopté par la plupart des clients, est performant et
s’adapte facilement aux outils de CI-Soft. En réalité, développer un progiciel comme Précix consiste à
cacher du code SQL par une interface graphique.
Les travaux de développement ont permis au cours du stage d’utiliser les trois outils de
développement de Précix. Les premières missions ont concerné la création de documents
personnalisés à la demande du client. Le logiciel CI-Query permet de créer facilement ses documents
en utilisant les codes du langage SQL. Cependant les défauts de ce logiciel sont nombreux et retardent
le développement. La seconde partie technique du stage a conduit le stagiaire au sein du module SAV.
Ainsi ce dernier a été corrigé et de nouveaux programmes ont vu le jour. La dernière partie du
développement a consisté à travailler sur des développements spécifiques propres au client. Au cours
de l’utilisation de CI-Builder, le stagiaire s’est rendu compte que malgré quelques défauts ce logiciel
propose de nombreuses possibilités.
Finalement, le stage a permis de voir les activités annexes que les développeurs réalisent. Ils
s’occupent ainsi de l’installation du progiciel et assurent la maintenance. À ce juste titre, ils
représentent le premier interlocuteur du client et lui fournissent des conseils. Le travail de développeur
à Méga Informatique demande de multiples compétences. Le stagiaire n’a pas pu expérimenté tous les
rôles des développeurs mais seulement les principaux, le développement et les installations.
40
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Table des illustrations
Figure 1 : Schéma relationnel simplifié dans le cas d'
une commande vente ........................................ 12
Figure 2 : Liens entre les produits CI-Soft et le SGBD ......................................................................... 14
Figure 3 : L'
environnement de CI-Builder ............................................................................................. 15
Figure 4 : Parcours d'
une commande sous CI-Builder ......................................................................... 16
Figure 5 : Un état CI-Query en mode développement .......................................................................... 17
Figure 6 : Fiche de saisie d'
une garantie.............................................................................................. 22
Figure 7 : Menu de saisie du devis....................................................................................................... 22
Figure 8 : Schéma de la structure des données ................................................................................... 23
Figure 9 : Palette des statistiques sur les coûts ................................................................................... 25
Figure 10 : Palette de la fiche de saisie du devis ................................................................................. 26
Figure 11 : Ancien menu de modification de devis ............................................................................... 27
Figure 12 : Nouveau menu de modification de devis............................................................................ 28
Figure 13 : Menu de saisie des caractéristiques des articles................................................................ 29
Figure 14 : Menu des retours de consignation ..................................................................................... 31
Figure 15 : Palette d'
annulation des retours de consignation ............................................................... 32
Figure 16 : Struture des entités sous Informix ...................................................................................... 33
Figure 17 : Menu de configuration de l'
installation de Précix ................................................................ 34
41
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Annexe 1 : Les principaux codes CI-Builder
But
Affectation d’une variable
Affectation d’une propriété
Condition
Code
Put
Get
Set
If
Tests multiples
Switch
Boucle d’itération
Repeat
Exécution de handler
Send
do
SQLExecute
Exécution d’une requête SQL
Syntaxe
Put 5 into variable
Get 5
Put 5 into it
Set the name of btn "bouton" to “Nom”
If condition then
Instruction 1
Else
Instruction 2
End if
Switch
When condition1 then instruction1
When condition2 then instruction2 …
Otherwise instruction
End Switch
Repeat while a>0
Instruction
End Repeat
OU
Repeat with a=0 to 100
Instruction
End Repeat
Send handler to btn “bouton”
Do handler
Send handler to me
Put SQLExecute(“requête”) into resultat
Ensuite, CI-Builder propose un grand nombre de fonctions et d’objets qui disposent chacun de
leurs propres caractéristiques. Les codes précédents correspondent à ceux de base qui sont le plus
utilisés lors de la programmation.
42
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Annexe 2 : Détails des codes du projet des statistiques des
interventions en SAV
Handler du bouton de génération de la liste
Le mouseUp signifie que ce handler est exécuté lorsque l’on clique sur le bouton
On mouseUp
On défini une variable qui sera commune au projet
Global proj PID
On passe le dessin du curseur en sablier
Set the cursor of builder to 4
On vide la liste
Put empty into button 6
On vérifie que les dates sont correctes pour lancer le traitement, il faut que la date de fin sous postérieure à celle de début
Put convertdate (btn "datedebut", "DD/MM/YYYY", "YYYY/MM/DD") into dtedbt
Put convertdate (btn "datefin", "DD/MM/YYYY", "YYYY/MM/DD") into dtefin
La fonction testMinMax appartient à Sylob est renvoie « true » si la 2ème valeur est supérieure à la 1ère sinon « false »
Put testMinMax (dtedbt & tab & dtefin & tab & "D") into comparedate
Si le test de comparaison est négatif alors, un message d’erreur est affiché, le bouton d’impression devient non sélectionnable et les totaux
sont à 0
If comparedate is false then
Do vpmAlert "date$"
Set the enable of btn "Impression" to false
Put 0 into btn 23
Put 0 into btn 2
Put 0 into btn 24
Put 0 into btn 20
Put 0 into btn 26
Put 0 into btn 21
Si le test des dates est positif, le traitement continue
Else
On regarde si l'
utilisateur a changé les bornes des dates pour éviter des calculs
If ((btn 10 = btn 15) and (btn 11 = btn 16)) is false then
On envoie les dates saisies sur des boutons cachés
Put btn 10 into btn 15
Put btn 11 into btn 16
Si la variable PID qui contient l'
ID du processus de ci-link n'
est pas vide alors on efface les lignes créées par la fonction spesavstatcout
If PID is not empty then
Get SQLExecute ("delete from sav_statcout where pid=" & PID)
End if
On exécute la fonction spesavstatcout pour insérer les données dans la table sav_statcout, cette fonction renvoie l’identifiant du processus sur
le serveur
Put exeFCT ("std98", "sav", "spesavstatcout", btn 15 & "," & btn 16) into PID
End if
On crée des morceaux de requêtes SQL que l’on place dans des variables suivant le choix de regroupement que l’utilisateur a fait
Switch
When the curValue of button "ChoixListe" is 1 then
Put "Article" into btn "critere"
Set the name of btn "libelle" to "Article"
Put "sav_statcout.no_art, bas_art.design1, SUM(sav_statcout.cout_mo), SUM(sav_statcout.cout_pi),
SUM(sav_statcout.fac_mo), SUM(sav_statcout.fac_pi)" into comselect
Put "group by 1,2 order by 1" into comother
Put "sav_statcout,bas_art" into comfrom
Put "(sav_statcout.no_art=bas_art.no_art) AND " into comwhere2
When the curValue of button "ChoixListe" is 2 then
Put "Client" into btn "critere"
Set the name of btn "libelle" to "Client"
Put "sav_statcout.no_cli, bas_cli.rais_soc, SUM(sav_statcout.cout_mo), SUM(sav_statcout.cout_pi),
SUM(sav_statcout.fac_mo), SUM(sav_statcout.fac_pi)" into comselect
Put "group by 1,2 order by 1" into comother
Put "sav_statcout,bas_cli" into comfrom
Put "(sav_statcout.no_cli=bas_cli.no_cli) AND " into comwhere2
43
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
When the curValue of button "ChoixListe" is 3 then
Put "Provenance" into btn "critere"
Set the name of btn "libelle" to "Provenance"
Put
"sav_statcout.
cd_pro,
sav_tabprove.libelle,
SUM(sav_statcout.cout_pi), SUM(sav_statcout.fac_mo), SUM(sav_statcout.fac_pi)" into comselect
Put "group by 1,2 order by 1" into comother
Put
"sav_statcout
LEFT
OUTER
JOIN
sav_tabprove
sav_tabprove.cd_pro)" into comfrom
Put "" into comwhere2
SUM(sav_statcout.cout_mo),
ON
(sav_statcout.cd_pro
=
When the curValue of button "ChoixListe" is 4 then
Put "Type de SAV" into btn "critere"
Set the name of btn "libelle" to "Type de SAV"
Put
"sav_statcout.
cd_sav,
sav_tabtype.libelle,
SUM(sav_statcout.cout_mo),
SUM(sav_statcout.cout_pi), SUM(sav_statcout.fac_mo), SUM(sav_statcout.fac_pi)" into comselect
Put "group by 1,2 order by 1" into comother
Put "sav_statcout,sav_tabtype" into comfrom
Put "(sav_statcout.cd_sav=sav_tabtype.cd_sav) AND " into comwhere2
Otherwise
Put "Intervention" into btn "critere"
Set the name of btn "libelle" to "Intervention"
Put
"sav_statcout.no_fic,
sav_statcout.dte_sais,
SUM(sav_statcout.cout_pi), SUM(sav_statcout.fac_mo), SUM(sav_statcout.fac_pi)" into comselect
Put "group by 1,2 order by 1" into comother
Put "sav_statcout" into comfrom
Put "" into comwhere2
SUM(sav_statcout.cout_mo),
End switch
On complète la condition WHERE en rajoutant comme critère l’id du processus obtenu précédemment.
Put comwhere2 & "(sav_statcout.pid=" & PID & ")" into comwhere1
On crée la requête SQL en remplaçant les propriétés d’une liste connectée à la base de données. Cette liste est cachée pour y faire des
traitements.
Do SetSQLProp the name of button 8, "listselect", comselect
Do SetSQLProp the name of button 8, "listfrom", comfrom
Do SetSQLProp the name of button 8, "listOthers", comother
Do SetSQLProp the name of button 8, "listwhere", comwhere1
On affiche les données issues de la table en ouvrant la connexion
Send SQLOpen to button 8
On change le séparateur de Builder par une tabulation pour sélectionner les champs séparément dans la liste cachée
Put the chunkSeparator of builder into sepdechunk
Set the chunkSeparator of builder to tab
On rentre le nombre de lignes de la liste cachée dans une variable
Put the number of lines in btn 8 into NbLig
On passe les données de la liste cachée dans une variable
Put btn 8 into tableau
On fait une itération de 1 jusqu’au nombre de lignes pour faire des traitements sur les données
Repeat with i = 1 to NbLig
On si l’utilisateur a choisi comme regroupement intervention, on place le terme Intervention du devant la date sur le 2ème colonne de la liste
If the curValue of btn "ChoixListe" is 5 then
Put "Intervention du " & convertdate (chunk 2 of line i of tableau, "YYYY/MM/DD", "DD/MM/YYYY")
into chunk 2 of line i of tableau
End if
On rajoute la somme des colonnes 3 et 4 devant la colonne 3 et la somme des colonnes 5 et 6 devant la colonne 5
Put (chunk 3 of line i of tableau) + (chunk 4 of line i of tableau) into total1
Put (chunk 5 of line i of tableau) + (chunk 6 of line i of tableau) into total2
Put tab & "" & tab & total1 after chunk 2 of line i of tableau
Put tab & "" & tab & total2 after chunk 6 of line i of tableau
End repeat
On rentre les données de la variable tableau dans la liste affichée
Put tableau into btn 6
On initialise les cellules des TOTAUX à 0
Put 0 into somme3
Put 0 into somme4
Put 0 into somme5
Put 0 into somme6
Une boucle sur le nombre de ligne réalise les sommes des colonnes
Repeat with i = 1 to NbLig
44
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Put chunk 5 of line i of btn 6 + somme3 into somme3
Put chunk 6 of line i of btn 6 + somme4 into somme4
Put chunk 9 of line i of btn 6 + somme5 into somme5
Put chunk 10 of line i of btn 6 + somme6 into somme6
End repeat
Les résultats sont affichés sur les boutons en dessous de la liste
Put somme3 into btn 2
Put somme4 into btn 24
Put somme5 into btn 26
Put somme6 into btn 21
Put somme3 + somme4 into btn 23
Put somme5 + somme6 into btn 20
Si la liste est vide, on affiche un message d’alerte et on rend inaccessible le bouton d’impression, sinon le bouton d’impression est accessible
If NbLig = 0 then
Do vpmAlert "noEnreg$"
Set the enable of btn "Impression" to false
Else
Set the enable of btn "Impression" to true
End if
On remet l’ancien séparateur de Builder
Set the chunkSeparator of builder to sepdechunk
End if
La souris redevient une flèche
Set the cursor of builder to 0
On signale la fin du handler
End mouseUp
LA FONCTION CI-Link : savStatCout.cil
#XM 12/06/2002
#Création d'une table sav_statcout pour le cout des interventions
#Les paramètres passés sont la date de début et celle de fin
param parametres
#On renvoie les valeurs 'null' à 0
set null=0
#-------------------------------------------------------------------------# Définition des variables
#-------------------------------------------------------------------------#locales
string l_req1,l_req2,l_req3
integer i,l_no_fic
float l_cout_mo,l_fac_mo,l_cout_pi,l_fac_pi
#paramètres
string l_datedebut,l_datefin
l_datedebut = GetItem(:parametres,1)
l_datefin = GetItem(:parametres,2)
#-------------------------------------------------------------------------# Définition des requêtes et exécution
#-------------------------------------------------------------------------#Cette première requête permet de sommer les coûts des opérations en les regroupant par intervention
l_req1 = "SELECT sav_basvie.no_fic l_no_fic,sav_basvie.no_art,sav_basvie.no_cli,sav_basvie.cd_pro,
sav_basvie.cd_sav,sav_basvie.dte_sais,
SUM(dev_dgamop.taux_oper*dev_dtpsgam.tps_fab*sav_basdefop.cout_pers+sav_basdefop.cout_op) l_cout_mo,
SUM(sav_tabgar.cout*(dev_dgamop.taux_oper*dev_dtpsgam.tps_fab*sav_basdefop.cout_pers+sav_basdefop.cout_op
)) l_fac_mo"
l_req1 = l_req1+" FROM sav_basvie,sav_basdefop,dev_dgamop,dev_dtpsgam,sav_tabgar"
l_req1 = l_req1+" WHERE (sav_basdefop.cd_gar = sav_tabgar.cd_gar) and (sav_basvie.no_fic =
sav_basdefop.no_fic) and (sav_basdefop.no_dev=dev_dgamop.no_dev) and (sav_basdefop.no_lig =
dev_dgamop.no_lig) and (sav_basdefop.ord_oper = dev_dgamop.ord_oper) and (sav_basdefop.no_dev =
dev_dtpsgam.no_dev) and (sav_basdefop.no_lig = dev_dtpsgam.no_lig) and (sav_basdefop.ord_oper =
dev_dtpsgam.ord_oper) and (sav_basvie.dte_sais between "+ Quote(l_datedebut) +" and "+ Quote(l_datefin)
+")"
l_req1 = l_req1+" GROUP BY 1,2,3,4,5,6"
#On exécute la requête et récupère les données dans un curseur
45
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Declare l_curs normal Cursor for $l_req1
#Pour chaque ligne du curseur
For Each l_curs
#On fait une requête qui somme les coûts sur les composants
l_req2 = "SELECT sav_basvie.no_fic,SUM(sav_basdefcomp.cout_unit*qte_struct)
l_cout_pi,SUM(sav_tabgar.cout*sav_basdefcomp.cout_unit*qte_struct) l_fac_pi"
l_req2 = l_req2+" FROM sav_basvie LEFT OUTER JOIN sav_basdefcomp ON (sav_basdefcomp.no_fic
=sav_basvie.no_fic)"
l_req2 = l_req2+" LEFT OUTER JOIN sav_tabgar ON (sav_basdefcomp.cd_gar = sav_tabgar.cd_gar)"
l_req2 = l_req2+" LEFT OUTER JOIN dev_dnom ON (sav_basdefcomp.no_dev = dev_dnom.no_dev and
sav_basdefcomp.no_lig = dev_dnom.no_lig and sav_basdefcomp.ord_oper = dev_dnom.ord_oper and
sav_basdefcomp.position = dev_dnom.position)"
l_req2 = l_req2+" WHERE (sav_basvie.no_fic ="+ l_no_fic +")"
l_req2 = l_req2+" GROUP BY 1"
#On exécute la requête de sélection et les résultat sont en voyé dans les variables locales définies dans
la requêtes
local $l_req2
# On insère dans la table sav_statcout les résultats des 2 requêtes précédentes
l_req3 = "INSERT into sav_statcout VALUES ("+ l_no_fic +","+ Quote(no_art) +","+ no_cli +","+
Quote(cd_pro) +","+ Quote(cd_sav) +","+ Quote(dte_sais) +","+ l_cout_mo +","+ l_cout_pi +","+ l_fac_mo
+","+ l_fac_pi +","+pid +")"
# On exécute la requête d’insertion
$l_req3
# On initialise la variable l_req2
l_req2 = ""
End For
#-------------------------------------------------------------------------# Retour du ID du processus comme résultat de la fonction
#-------------------------------------------------------------------------get pid
end
46
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Annexe 3 : Fonction commentée qui permet de mettre 2
caractéristiques à côté sur le document imprimé.
# Fonction qui remplit la table zz_edifsuiv
# Parametres : no OF
Param parametres
#Definition des variables locales
String l_req, l_req1, l_req2, l_req3, l_req4
String l_noOf, l_noArt, l_lib, l_cns
Integer i, j
# Recuperation des parametres : numéro d’ordre de fabrication
l_noOf = GetItem (:parametres,1)
# On met les valeurs vides à “”
Set NullValue = ""
# Construction de la requête pour selectionner l’article de l’OF et exécution
l_req1 = "select no_art l_noArt from pro_ofent where no_of=" + Quote(l_noOf)
local $l_req1
# Suppression des précédentes données se rapportant à l’article et exécution
l_req = "delete from zz_edifsuiv where no_art="+ Quote(l_noArt)
$l_req
# Initialisation de la variable j
j = 0
# Pour chacune des 60 caractéristiques
For i = 1 to 60
# On sélectionne le champ cns correspondent àal caractéristique
l_req1 = "select cns"+i+" l_cns from zz_caractart where no_art=" + Quote(l_noArt)
local $l_req1
# si la valeur est inexistante on passé à la caractéristique suivante
If l_cns="" then continue
# On incrémente j de 1
j = j + 1
# on sélectionne le libellé de la caractéristique
l_req2 = "select libelle l_lib from zz_paramcaractart where no_cns=" + i
local $l_req2
# on sélectionne la designation de la caractéristique si elle existe (pour les
caractéristiques dont le numéro de l’unité est supérieur à 5)
l_req3 = "select libelle l_designation from zz_libcaractart where no_cns=" + i +"
and cd_lib=" + Quote(l_cns)
local $l_req3
# si j est égal à 1, on insère construit le début de la requête
If (j = 1)
If (l_designation<>"")
l_req4 = "insert into zz_edifsuiv values("+ Quote(l_noArt) +","+ i +","+
Quote(l_lib) +","+ Quote(l_designation) +","
47
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Else
l_req4 = "insert into zz_edifsuiv values("+ Quote(l_noArt) +","+ i +","+
Quote(l_lib) +","+ Quote(l_cns) +","
End If
# sinon on construit la fin de la requête
Else
If (l_designation<>"")
l_req4 = l_req4 + Quote(l_lib) +","+ Quote(l_designation) +")"
Else
l_req4 = l_req4 + Quote(l_lib) +","+ Quote(l_cns) +")"
End If
$l_req4
# on initialise j à 0
j = 0
End If
End For
# si j vaut 1, la requête n’a pas été finie, on rajoute des valeurs vides
If (j = 1)
l_req4 = l_req4 +"NULL,NULL)"
$l_req4
End If
end
48
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Annexe 4 : La fonction CI-Link réalisant les traitements pour
valider le retour de consignation
#-----------------------------------------------------# XM le 22072002 Retour des consignations
# Parametres :Numéro de consignation, login
#-----------------------------------------------------Param parametres
#--- Déclaration des variables
Integer l_noLigDeb, l_noLigFin, l_noRetDeb, l_noRetFin
Integer l_nobl, l_typorigine, l_genre_intdep, l_genre_intdep1
String l_login, l_req, l_req1, l_req2, l_curs, l_chemin, l_info, l_req3, l_req4,
l_curs2, l_curs3, l_noser1
Date l_dtemvt
String l_noorigine, l_proven, l_mode, l_modif
Integer l_numaffect, l_nbmvt, l_nbligNonRet, l_noligbl
Float l_qtelivr, l_qteretour, l_qteretourtot
# Les valeurs indéfinies sont représentées par ""
Set NullValue=""
# Récupération des parametres
l_nobl=GetItem(:parametres,1)
l_login=GetItem(:parametres,2)
l_noLigDeb=GetItem(:parametres,3)
l_noLigFin=GetItem(:parametres,4)
l_noRetDeb=GetItem(:parametres,5)
l_noRetFin=GetItem(:parametres,6)
#--- On fait un retour de consignation, on récupère le code du mouvement
l_req = "select cd_genre l_genre_intdep from sto_affectmvt where num_affect =
21"
Local $l_req
# On recherche le code du type de mouvement d'origine
l_req = "select cd_genre l_genre_intdep1 from sto_affectmvt where num_affect =
20"
Local $l_req
# Sélection des lignes de la consignation à retourner
l_req = "select com_bllig.no_lig l_noligbl, zz_ligcon.no_retour,
com_bllig.no_art l_noart,zz_ligcon.qte_retour l_qteretour,"
l_req = l_req + " com_bllig.no_lieu l_nolieu, zz_ligcon.date l_dtemvt "
l_req = l_req + " from com_bllig,zz_ligcon where com_bllig.no_bl=zz_ligcon.no_bl
and com_bllig.no_lig=zz_ligcon.no_lig"
l_req = l_req + " and zz_ligcon.etat_lig=1 and com_bllig.no_bl=" + l_nobl
If (l_noLigDeb <> 0) or (l_noLigFin <> 999)
l_req = l_req + " and com_bllig.no_lig between " + l_noLigDeb + " and " +
l_noligFin
End If
If (l_noRetDeb <> 0) or (l_noRetFin <> 999)
49
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
l_req = l_req + " and zz_ligcon.no_retour between " + l_noRetDeb + " and " +
l_noRetFin
End If
l_req = l_req + " order by com_bllig.no_lig,zz_ligcon.no_retour"
l_curs = "lignes_BL"
Declare $l_curs normal Cursor For $l_req
For Each $l_curs
#--- On récupère des champs de l'entête de la consignation
l_req2 = "select no_cli l_nocli, dte_livr l_dtelivr, type_bl l_typebl
com_blent where no_bl = " + l_nobl
Local $l_req2
from
#--- On fait un retour de consignation
l_typorigine = l_genre_intdep
l_numaffect=21
If (l_typorigine = NullValue) or (l_typorigine=0)
#--- Signifie que le type origine est indéfini
l_typorigine=99
End If
l_noorigine = l_nobl+"/"+l_noligbl
l_proven = 0
# Recherche des mouvements de stock précédent se rapportant à la consignation
l_req3 = " select no_mvtart l_mvtart,typ_art l_typart,ind_art
l_indart,champ_libre1 l_champ1,champ_libre2 l_champ2, "
l_req3 = l_req3 + " no_lieu l_nolieu, condit l_condit, qte_mvt l_qtelivr,
prix_unit l_prixunit,no_casier l_casier, no_lot l_lot,"
l_req3 = l_req3 + " proven l_proven,cert_conf l_certconf, ana_coulee
l_anacoulee, no_clifrn l_nocli, "
l_req3 = l_req3 + " num_affect l_numaffect "
l_req3 = l_req3 + " from sto_histmvt "
l_req3 = l_req3 + " where sto_histmvt.no_art=" + Quote(l_noart)
l_req3 = l_req3 + " and sto_histmvt.typ_mvt= 2 "
l_req3 = l_req3 + " and sto_histmvt.typ_origine = " + l_genre_intdep1
l_req3 = l_req3 + " and sto_histmvt.no_origine= " + Quote(l_noorigine)
l_req3 = l_req3 + " order by sto_histmvt.no_mvtart desc "
l_curs2 = "listmvt"
Declare $l_curs2 normal Cursor For $l_req3
l_nbmvt=0
For Each $l_curs2
if (l_qtelivr > 0)
if (l_qteretour > 0)
l_qteretour = - l_qteretour
end if
else
if (l_qteretour < 0)
l_qteretour = - l_qteretour
end if
end if
l_nbmvt=l_nbmvt + 1
l_req2 = "select nom_lieu l_nomlieu from tab_lstkstd where no_lieu = " +
Quote(l_nolieu)
50
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Local $l_req2
#--- Mise à jour des stocks avec un retour opposé
l_info = l_noart + "," + l_typart + "," + l_indart + ",2," + l_champ1 +
"," + l_champ2 + "," + l_dtemvt
l_info = l_info + "," + l_nolieu + "," + l_nomlieu + "," + l_condit +
"," + l_qteretour + "," + l_prixunit + ","
l_info = l_info + l_casier + "," + l_lot + "," + l_proven + "," +
l_certconf + "," + l_anacoulee + ","
l_info = l_info + l_typorigine + "," + l_noorigine + "," + l_nocli + ","
+ l_numaffect + "," + l_login
# utilisation d’une fonction pour mettre à jour les stocks
call stomajhistmvt l_info
If (l_nbmvt > 1)
Break
End If
End For
l_modif = "MODIF"
End For
# Si il y a eu des mouvements de stocks on continue les traitements
If l_modif = "MODIF"
#--- Mise à jour des lignes de zz_ligcon pour dire qu'elles sont éditées
l_req2 = "update zz_ligcon set etat_lig = 7 where etat_lig = 1 and no_bl = " +
l_nobl
If (l_noLigDeb <> 0) or (l_noLigFin <> 999)
l_req2 = l_req2 + " and no_lig between " + l_noLigDeb + " and " +
l_noligFin
End If
If (l_noRetDeb <> 0) or (l_noRetFin <> 999)
l_req2 = l_req2 + " and no_retour between " + l_noRetDeb + " and " +
l_noRetFin
End If
$l_req2
#--- On regarde si toute les lignes de ZZ_LIGCON ont été retournées
l_req2 = "select sum(com_bllig.qte_livr) l_qtelivr from com_bllig"
l_req2 = l_req2 + " where com_bllig.etat_lig = 7 and com_bllig.no_bl = " +
l_nobl
l_req2 = l_req2 + " group by com_bllig.no_bl"
Local $l_req2
l_req2 = "select sum(zz_ligcon.qte_retour) l_qteretourtot from zz_ligcon where
zz_ligcon.no_bl = " + l_nobl +" group by no_bl"
Local $l_req2
#--- On indique dans la table ZZ_BLCON que le retour a eu lieu si toutes les lignes
ont été retournées
If (l_qtelivr = l_qteretourtot)
l_req2 = "update zz_blcon set cns1 = " + Quote("RETOUR") + " where no_bl
= " + l_nobl
Local $l_req2
End If
#--- On sélectionne les numéros de série retournés
l_req = "select no_lig l_noligbl,noser1 l_noSer1 from zz_retournoser where
etat_lig = 1 and no_bl = " + l_nobl
51
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
If (l_noLigDeb <> 0) or (l_noLigFin <> 999)
l_req = l_req + " and no_lig between " + l_noLigDeb + " and " +
l_noligFin
End If
If (l_noRetDeb <> 0) or (l_noRetFin <> 999)
l_req = l_req + " and no_retour between " + l_noRetDeb + " and " +
l_noRetFin
End If
l_curs3 = "Noser1_retour"
Declare $l_curs3 normal Cursor For $l_req
For each $l_curs3
#--- Mise à jour des no de série , on passe sur les enregistrements existants en
indiquant qu’ils sont retournés (retour=1) et on crée un nouvel enregistrement
vièrge avec le lieu,lot et casier de la ligne de BL
l_req1 = "update sav_noser set retour = 1 where noser1 = " +
Quote(l_noSer1) + " and no_bl = " + l_nobl +" and no_bll = " + l_noligbl
Local $l_req1
# recherche des infos de sav_noser table des no des série
l_req3 = "select no_art l_noArt, noser2 l_noSer2, noser3
l_noSer3,no_lieu l_noLieu, no_casier l_noCasier, no_lot l_noLot from sav_noser where
noser1 = " + Quote(l_noSer1) + " and no_bl = " + l_noBl + " and no_bll = " +
l_noligbl
local $l_req3
# insertion des nouveaux enregistrements dans sav_noser
l_req4 = "insert into sav_noser values (" + quote(l_noArt) + "," +
quote(nullvalue) + "," + quote(l_noser1) + "," + quote(l_noser2) + "," +
quote(l_noser3) + "," + quote(l_noLot)
l_req4 = l_req4 + ",0,0," + quote(nullvalue) + "," + quote(nullvalue)
l_req4 = l_req4 + "," + quote(nullvalue) + "," + quote(nullvalue) + ","
+ quote(nullvalue) + "," + quote(nullvalue)
l_req4 = l_req4 + "," + quote(nullvalue) + "," + quote(nullvalue) + ","
+ quote(nullvalue) + "," + quote(nullvalue)
l_req4 = l_req4 + "," + quote(l_noLieu) + "," + quote(nullvalue) + "," +
quote(nullvalue) + "," + quote(nullvalue)
l_req4 = l_req4 + "," + quote(nullvalue) + "," + quote(nullvalue)
l_req4 = l_req4 + "," + quote(nullvalue) + "," + quote(l_noCasier) + ","
+ quote(date()) + ")"
$l_req4
End For
#--- Mise à jour de l'état des lignes de zz_retournoser
l_req2 = "update zz_retournoser set etat_lig = 7 where etat_lig = 1 and no_bl
= " + l_nobl
If (l_noLigDeb <> 0) or (l_noLigFin <> 999)
l_req2 = l_req2 + " and no_lig between " + l_noLigDeb + " and " +
l_noligFin
End If
If (l_noRetDeb <> 0) or (l_noRetFin <> 999)
l_req2 = l_req2 + " and no_retour between " + l_noRetDeb + " and " +
l_noRetFin
End If
$l_req2
End If
end
52
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
Annexe 5 : La fonction CI-Link permettant de réaliser les
traitements pour annuler les lignes de consignation retournées
#-----------------------------------------------------# XM le 29072002 Annulation de retours d'une consignation
# Parametres :Numéro de consignation, login
#-----------------------------------------------------Param parametres
#--- Déclaration des variables
Integer l_nobl, l_typorigine, l_genre_intdep, l_genre_intdep1
String l_login, l_req, l_req1, l_req2, l_curs, l_chemin, l_info, l_req3,
l_curs2, l_curs3, l_req4
Date l_dtemvt
String l_noorigine, l_proven, l_mode, l_modif
Integer l_numaffect, l_nbmvt, l_noligbl, l_compteur, l_noligblanc, l_noserlibre
Float l_qtelivr, l_qteretour, l_qtemvt, l_qteretourtot
# Variables pour le SAV
integer l_noblsav, l_nofic
# Les valeurs indéfinies sont transformées en ""
Set NullValue=""
#--- Récupération des parametres
l_nobl=GetItem(:parametres,1)
l_login=GetItem(:parametres,2)
#--- On fait un transfert du stock normal en consignation
l_req = "select cd_genre l_genre_intdep from sto_affectmvt where num_affect =
23"
Local $l_req
#--- On recherche le code du type de mouvement d'origine
l_req = "select cd_genre l_genre_intdep1 from sto_affectmvt where num_affect =
21"
Local $l_req
#--- Sélection des lignes retournées de la consignation à annuler
l_req = "select com_bllig.no_lig l_noligbl, zz_ligcon.no_retour,
com_bllig.no_art l_noart,zz_ligcon.qte_retour l_qteretour,"
l_req = l_req + " com_bllig.no_lieu l_nolieu"
l_req = l_req + " from com_bllig,zz_ligcon where com_bllig.no_bl=zz_ligcon.no_bl
and com_bllig.no_lig=zz_ligcon.no_lig"
l_req = l_req + " and zz_ligcon.etat_lig=6 and com_bllig.no_bl=" + l_nobl
l_req = l_req + " order by com_bllig.no_lig,zz_ligcon.no_retour"
Local $l_req
l_curs = "lignes_BL"
Declare $l_curs normal Cursor For $l_req
For Each $l_curs
53
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
#--- On récupère des champs de l'entête de la consignation
l_req2 = "select no_cli l_nocli, dte_livr l_dtelivr, type_bl l_typebl
com_blent where no_bl = " + l_nobl
Local $l_req2
from
#--- On fait un transfert de dépôt du stock normal au stock de consignation
l_typorigine = l_genre_intdep
l_numaffect=20
If (l_typorigine = NullValue) or (l_typorigine=0)
#--- Signifie que le type origine est indéfini
l_typorigine=99
End If
l_noorigine = l_nobl+"/"+l_noligbl
l_proven = 0
# Recherche des mouvements de stock de la ligne précédemment retournée
l_req3 = " select no_mvtart l_mvtart,typ_art l_typart,ind_art
l_indart,champ_libre1 l_champ1,champ_libre2 l_champ2, "
l_req3 = l_req3 + " no_lieu l_nolieu, condit l_condit, qte_mvt l_qtemvt,
prix_unit l_prixunit,no_casier l_casier, no_lot l_lot,"
l_req3 = l_req3 + " proven l_proven,cert_conf l_certconf, ana_coulee
l_anacoulee, no_clifrn l_nocli, "
l_req3 = l_req3 + " num_affect l_numaffect "
l_req3 = l_req3 + " from sto_histmvt "
l_req3 = l_req3 + " where sto_histmvt.no_art=" + Quote(l_noart)
l_req3 = l_req3 + " and sto_histmvt.typ_mvt= 2 "
l_req3 = l_req3 + " and sto_histmvt.typ_origine = " + l_genre_intdep1
l_req3 = l_req3 + " and sto_histmvt.no_origine= " + Quote(l_noorigine)
l_req3 = l_req3 + " and (qte_mvt=" + l_qteretour + " or qte_mvt=" + l_qteretour + ")"
l_req3 = l_req3 + " order by sto_histmvt.no_mvtart desc "
l_curs2 = "listmvt"
Declare $l_curs2 normal Cursor For $l_req3
l_nbmvt = 0
For Each $l_curs2
if (l_qtemvt > 0)
if (l_qteretour > 0)
l_qteretour = - l_qteretour
end if
else
if (l_qteretour < 0)
l_qteretour = - l_qteretour
end if
end if
l_nbmvt = l_nbmvt + 1
l_dtemvt = date
l_req2 = "select nom_lieu l_nomlieu from tab_lstkstd where no_lieu = " +
Quote(l_nolieu)
Local $l_req2
#--- Mise à jour des stocks avec une quantité opposée
l_info = l_noart + "," + l_typart + "," + l_indart + ",2," + l_champ1 +
"," + l_champ2 + "," + l_dtemvt
l_info = l_info + "," + l_nolieu + "," + l_nomlieu + "," + l_condit +
"," + l_qteretour + "," + l_prixunit + ","
54
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
l_info = l_info + l_casier + "," + l_lot + "," + l_proven + "," +
l_certconf + "," + l_anacoulee + ","
l_info = l_info + l_typorigine + "," + l_noorigine + "," + l_nocli + ","
+ l_numaffect + "," + l_login
call stomajhistmvt l_info
If (l_nbmvt > 1)
Break
End If
End For
l_modif = "MODIF"
End For
# Si on a fait des mouvements de stocks, on continue les traitements
If l_modif = "MODIF"
#--- On regarde si toutes les lignes de ZZ_LIGCON ont été retournées
l_req2 = "select sum(com_bllig.qte_livr) l_qtelivr from com_bllig"
l_req2 = l_req2 + " where com_bllig.etat_lig <> 6 and com_bllig.no_bl = " +
l_nobl
l_req2 = l_req2 + " group by com_bllig.no_bl"
Local $l_req2
l_req2 = "select sum(zz_ligcon.qte_retour) l_qteretourtot from zz_ligcon where
zz_ligcon.etat_lig<>6 and zz_ligcon.no_bl = " + l_nobl +" group by no_bl"
Local $l_req2
#--- Dans la table ZZ_BLCON on enlève "RETOUR" sur le cns1
If (l_qtelivr > l_qteretourtot)
l_req2 = "update zz_blcon set cns1 = " + Quote("") + " where no_bl = " +
l_nobl + " and cns1=" + Quote("RETOUR")
$l_req2
End If
#--- On sélectionne les numéros de série retournés
l_req = "select no_lig l_noligbl,noser1 l_noSer1 from zz_retournoser where
etat_lig = 6 and no_bl = " + l_nobl
l_curs3 = "Noser1_retour"
Declare $l_curs3 normal Cursor For $l_req
For each $l_curs3
# recherche des infos de sav_noser
l_req2 = "select no_art l_noArt, noser2 l_noSer2, noser3
l_noSer3,no_lieu l_noLieu, no_casier l_noCasier, no_lot l_noLot from sav_noser where
noser1 = " + Quote(l_noSer1) + " and no_bl = " + l_noBl + " and no_bll = " +
l_noligbl
local $l_req2
l_req3 = "select count(*) l_noserlibre from sav_noser where no_art="
+quote(l_noArt)+ " and noser1=" + Quote(l_noSer1)
l_req3 = l_req3 + " and (no_dev is null or no_dev="+Quote("")+") and
(no_cde is null or no_cde="+Quote("")+") and (no_br is null or no_br="+Quote("")+")"
l_req3 = l_req3 + " and (no_of is null or no_of="+Quote("")+") and
(no_bl is null or no_bl="+Quote("")+") and (no_fact is null or
no_fact="+Quote("")+")"
Local $l_req3
If (l_noserlibre > 0)
#--- Mise à jour des no de série, on passe sur les enregistrements qui ont été
retournés (retour=1) et si l’ancien numéro de série est libre, on met le champ
retour à 0
l_req1 = "update sav_noser set retour = null where noser1 = " +
Quote(l_noSer1) + " and no_bl = " + l_nobl +" and no_bll = " + l_noligbl
$l_req1
55
Xavier MOGHRABI
IFI 2003
Rapport technique
Stage IFI 3
# suppression des enregistrements dans sav_noser non affectés
l_req4 = "delete from sav_noser where no_art=" +quote(l_noArt)+ "
and noser1=" + quote(l_noser1)
l_req4 = l_req4 + " and (no_bl is null or no_bl="+Quote("")+")"
$l_req4
End If
End For
#--- MAJ des lignes de zz_ligcon dont l'etat est à 6
l_req2 = "update zz_ligcon set etat_lig = 1 where etat_lig = 6 and no_bl = " +
l_nobl
$l_req2
#--- MAJ des lignes de zz_retournoser dont l'etat est à 6
l_req2 = "update zz_retournoser set etat_lig = 1 where etat_lig = 6 and no_bl
= " + l_nobl
$l_req2
End If
end
56