participation à différents développements sur le progiciel

56
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

Upload: others

Post on 16-Oct-2021

1 views

Category:

Documents


0 download

TRANSCRIPT

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 MÉGA INFORMATIQUE S.A. Promotion : IFI 2003 Rue du Borgeaud 10B Tuteur école : Emmanuel Otton 1196 GLAND Tuteur entreprise : Gérald TÉDÉSCHI SUISSE

Xavier MOGHRABI Rapport technique IFI 2003 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 Rapport technique IFI 2003 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 Rapport technique IFI 2003 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. La société Méga Informatique, une petite structure qui s’agrandit ......................... 9 a. Depuis sa création, la société ne fait que s’agrandir...................................................... 9 b. Le sujet de stage........................................................................................................... 9 c. L’activité et le progiciel de gestion intégrée Précix ...................................................... 10

2. Précix est structuré autour d’une base de données ............................................. 12

a. INFORMIX, le SGBD adopté par Précix ...................................................................... 12 b. Le langage SQL convient aussi bien aux débutants qu’aux développeurs confirmés .. 12

3. Les outils de développement de la version Eclipse.............................................. 14

a. La complémentarité des produits CI-SOFT ................................................................. 14 b. L’outil graphique CI-Builder, de bonnes idées pénalisées par des bugs ...................... 14 c. Le générateur d’états CI-Query, simple mais très limité .............................................. 16 d. Le logiciel intermédiaire CI-Link, un langage plus classique........................................ 18

II. La diversification du travail de développement............................... 19

1. Les documents CI-Query personnalisés pour des clients .................................... 19 a. La création et les retouches de documents ................................................................. 19 b. Les difficultés rencontrées principalement dues aux limites de l’outil........................... 19

2. L’amélioration du module SAV............................................................................. 21

a. Le module SAV et son fonctionnement........................................................................ 21 b. Les petites améliorations ou corrections...................................................................... 21 c. La création d’un nouveau projet de statistiques des interventions ............................... 23 d. La reconstruction de la palette de modification des devis............................................ 25

3. Le travail sur des spécifications pour des clients ................................................. 28

a. L’impression des caractéristiques de template horloger .............................................. 28 b. Le spécifique des retours de consignation................................................................... 30 c. Le spécifique pour l’annulation des retours de consignation........................................ 31

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

III. Des développeurs polyvalents sont indispensables à une petite

structure telle que Méga Informatique ........................................................... 33

1. L’installation des logiciels ..................................................................................... 33 a. L’installation de la base de données Informix, un travail d’administration .................... 33 b. L’installation de Précix, un procédure simple mais qui peut réserver des surprises..... 34 c. La télémaintenance évite certains déplacements ........................................................ 35

2. Le travail sur un projet en informatique ................................................................ 35

a. L’analyse du projet, pour démarrer sur de bonnes bases ............................................ 35 b. Le développement, une course contre la montre......................................................... 36 c. La phase de test garantit la qualité du produit ............................................................. 36

3. Un bilan de stage très satisfaisant et enrichissant ............................................... 37

a. Un travail de développement intéressant mais avec des outils capricieux ................... 37 b. Les résultats obtenus ont-ils constitué un gain pour la société ? ................................. 38 c. Les compétences multiples des informaticiens, la force de l’entreprise ....................... 38 d. Les leçons du stage .................................................................................................... 39

CONCLUSION ........................................................................................... 40 Table des illustrations.............................................................................. 41

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

8

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

9

I. 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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

10

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)…

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

11

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

12

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

13

é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)

CREATE ALTER DROP DESCRIBE RENAME

Création de tables Modification de tables Suppression de tables Description des colonnes d’une table Renomme une table

Manipulation des données (DML : Data Manipulation Language)

SELECT INSERT UPDATE DELETE

Interrogation diverses de la base Insertion de lignes dans une table Mise à jour de lignes dans une table Suppression de lignes dans une table

Contrôle des autorisations (DCL : Data Control Language)

GRANT REVOKE COMMIT ROLLBACK

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 Fonctionnalité

SELECT Nom colonnes 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.

FROM Nom tables Précise la (ou les) table intervenant dans l'interrogation

WHERE Expression sur colonnes

Précise les conditions de restriction à appliquer sur les lignes. On peut trouver : - Des comparateurs : =, >, <, >=, <=, <> - Des opérateurs logiques : AND, OR, NOT - Les prédicats : IN, LIKE, NULL, ALL, SOME, ANY, EXISTS...

GROUP BY Nom colonnes Précise la (ou les) colonne de regroupement HAVING Expression sur colonnes Précise la (ou les) conditions associées à un regroupement

ORDER BY ASC / DESC Précise l'ordre dans lequel vont apparaître les lignes de la réponse : - 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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

14

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

15

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,

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

16

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

17

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

18

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

19

II. 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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

20

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

21

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

22

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

23

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

24

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 Définition Type (Maximum ou Longueur) No_fic Numéro de la fiche SAV d’intervention Entier (2.109) No_art Identifiant de l’article dans la fiche SAV Texte (17) No_cli Numéro du client Entier (2.109) Cd_pro Code de provenance Texte (5) Cd_sav Code SAV Texte (5) No_dev Numéro du devis Entier (2.109) Ord_oper Position de l’opération dans la table Entier (32768) Position Position du composant dans la table Entier (32768) Cd_gar Code de garantie Texte (5) Cout Coût de la garantie (1 : pour hors garantie, 0 pour sous-

garantie) Entier (32768)

Cout_op Coût de l’opération Réel Cout_pers Coût horaire des opérateurs travaillant sur l’opération Réel Taux_oper Nombre d’opérateurs Réel Tps_fab Temps (h) de travail des opérateurs sur l’opération Réel Cout_unit Coût unitaire du composant Réel Qte_struct 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 Formule Coût de l’opération Cout_op + ( cout_pers * taux_oper * tpsfab) Coût du composant 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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

25

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

26

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

27

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 Insertion existant du devis dans une table temporaire Requête ex. Select * from dev_dgamop where no_dev =100614 into temp tmpdgamop But Remplacer l’ancien numéro de devis par le nouveau dans la table temporaire Requête ex. Update tmpdgamop set no_dev=100615 where no_dev=100614 But Insérer les données de la table temporaire dans la table existante Requête ex. Insert into dev_dgamop select * from tmpdgamop But Supprimer la table temporaire Requête ex. Drop table tmpdgamop

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

28

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

29

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 Caractéristique 1 Libellé 2 Caractéristique 2 Libellé 3 Caractéristique 3 Libellé 4 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 de la table : zz_edifsuiv

Nom du champs Description Type No_art Code de l’article possédant les caractéristiques Texte (17) No_seq Compteur pour ordonner les caractéristiques Entier (32768) Lib1 Libellé de la caractéristique sur la 1ère colonne Texte (40) Val1 Caractéristique sur la 1ère colonne Texte (30) Lib2 Libellé de la caractéristique sur la 2ème colonne Texte (40) Val2 Caractéristique sur la 2ème colonne 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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

30

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 de la table : zz_ligcon Nom du champs Description Type No_bl Numéro de la consignation Entier (2.109) No_lig Numéro de ligne dans la consignation Entier (32768) No_retour Numéro du retour d’une ligne de consignation Entier (32768) Date Date du retour relatif au retour Date Qte_livr Quantité livrée relative à la ligne de consignation Réel Qte_retour Quantité retournée relative au retour Réel Etat_lig État de la ligne de retour (1 : saisie, 7 : imprimée et validée) 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 de la table : zz_retournoser Nom du champs Description Type No_bl Numéro de la consignation Entier (2.109) No_lig Numéro de ligne dans la consignation Entier (32768) No_retour Numéro du retour d’une ligne de consignation Entier (32768) Noser1 Premier numéro de série Texte (32) Etat_lig État de la ligne de retour (1 : saisie, 7 : imprimée et validée, 6 : effacée) Entier (32768)

Une fois les tables créées, le stagiaire a construit la palette correspondant à la figure 14.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

31

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é.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

32

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

33

III. 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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

34

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

35

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

36

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 CI-Soft 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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

37

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

38

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

39

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

40

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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

41

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

42

Annexe 1 : Les principaux codes CI-Builder

But Code Syntaxe Affectation d’une variable

Put Get

Put 5 into variable Get 5 � Put 5 into it

Affectation d’une propriété Set Set the name of btn "bouton" to “Nom” Condition If If condition then

Instruction 1 Else Instruction 2 End if

Tests multiples Switch Switch When condition1 then instruction1 When condition2 then instruction2 … Otherwise instruction End Switch

Boucle d’itération Repeat Repeat while a>0 Instruction End Repeat OU Repeat with a=0 to 100 Instruction End Repeat

Exécution de handler Send do

Send handler to btn “bouton” Do handler � Send handler to me

Exécution d’une requête SQL SQLExecute 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.

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

43

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

44

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_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 LEFT OUTER JOIN sav_tabprove ON (sav_statcout.cd_pro =

sav_tabprove.cd_pro)" into comfrom Put "" into comwhere2 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_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" into comfrom Put "" into comwhere2 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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

45

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

46

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

47

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) +","

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

48

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

49

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)

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

50

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 from com_blent where no_bl = " + l_nobl Local $l_req2 #--- 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)

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

51

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

52

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

53

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

54

#--- 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 from com_blent where no_bl = " + l_nobl Local $l_req2 #--- 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 + ","

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

55

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

Xavier MOGHRABI Rapport technique IFI 2003 Stage IFI 3

56

# 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