N° d’Ordre: UNIVERSITE ABDELMALEK ESSAÂDI ECOLE NATIONALE DES SCIENCES APPLIQUEES - TANGER PROJET DE FIN D’ETUDES Présenté à l’école pour obtenir le diplôme D’INGENIEUR D’ETAT Spécialité: Génie informatique Option: Génie des systèmes d’informations Titre ANALYSE DE BESOIN, ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE Réalisé par HAMLI Marouane Encdré par ELKAFIL Abdrahman (NEXTMA) EL ALAMI Mohamed (ENSAT) SOUTENU LE 27 juin 2012 Dédicace Au Dieu tout puissant, mon créateur. A ma mère, ma raison d’être, ma raison de vivre, la lanterne qui éclaire mon chemin et m’illumine de douceur et d’amour. A mon père, en signe d’amour, de reconnaissance et de gratitude pour tous les soutiens et les sacrifices dont il a fait preuve à mon égard. A mes sœurs. A mes grands-parents. Aux familles EL KHAZRAJI et HAMLI. A mes amis, et à tous mes proches. Rapport du projet de fin d’études Page 2 HAMLI Marouane Remerciements Le présent rapport reflète le fruit des efforts conjugués de plusieurs personnes. Il m’est alors agréable d’exprimer ma reconnaissance auprès de toutes ces personnes, dont l’intervention au cours de ce projet, a favorisé son aboutissement. Aussi je tiens à rendre grâce à mes parents, ma famille et mes amis qui, avec leur soutien et encouragement, j’ai pu arriver à terme de ce travail. Je souhaite remercier aussi mon encadrant d’entreprise, pour m’avoir accordé cette chance de travailler à ses cotés, et qui m’a été d’une aide très utile durant ma période de stage, Mr ELKAFIL Abdrahman pour ses directives précieuses et ses conseils judicieux qui m’ont été d’un appui considérable dans ma démarche. Je remercie particulièrement Mr Mohamed HASSOUN EL ALAMI pour son encadrement, son soutien, ainsi que pour ses conseils instructifs durant toute la période de ce travail. Mes remerciements aussi à Mr ELHADDAD Mohamed, chef de la filière informatique, ainsi qu’à l’ensemble des professeurs de l’ENSA-Tanger pour les efforts fournis pour notre bonne formation. Que les membres de jury trouvent ici l’expression de mes reconnaissances pour avoir accepté de juger notre travail. Que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement de ce travail trouvent l’expression de mes remerciements les plus chaleureux. Rapport du projet de fin d’études Page 3 HAMLI Marouane Résumé Les technologies de l’information ont connu une importante évolution durant ces dernières années, ce qui a donné comme résultat l’émergence de plusieurs solutions informatiques pour remédier aux différentes problématiques réelles. Les Progiciels de Gestion Intégré, appelés PGI ou ERP, sont l’une des solutions les plus pratiques à ce jour, ils intègrent les principales composantes fonctionnelles de l'entreprise: gestion de production, gestion commerciale, logistique, ressources humaines, comptabilité, contrôle de gestion. A l'aide de ce système unifié, les utilisateurs de différents métiers travaillent dans un environnement applicatif identique qui repose sur une base de données unique. Ce modèle permet d'assurer l'intégrité des données, la non-redondance de l'information, ainsi que la réduction des temps de traitement. Le travail présenté dans ce rapport concerne l’analyse du besoin, l’adaptation et l’intégration du PGI Open-Source « OpenERP » pour la gestion d’officine pharmaceutique. Pour y arriver, il a fallut d’abord se rendre sur les lieux, une pharmacie, pour prendre notes des différents processus métier, pour ensuite pouvoir élaborer une liste des différents besoins requis. L’étape qui a suivit était de se familiariser avec ce nouvel outil et découvrir les options qu’il offre, puis apprendre comment développer un module pour ce progiciel. Ensuite faire quelques simulations pour s’assurer que le travail a bien été fait, et corriger les bugs qui peuvent arriver, si jamais il y en a. Les PGI sont connus pour leur structure « modulaire », ainsi il a fallut développer un module spécial pour les officines, lequel fonctionne en relation avec d’autres modules existants, comme le module des achats, ou celui du point de vente. Rapport du projet de fin d’études Page 4 HAMLI Marouane Avant-propos Nom : HAMLI Prénom : Marouane Intitulé du travail : Analyse du besoin, adaptation et intégration d’OpenERP pour la gestion d’Officine. Etablissement d’accueil : Nextma 452, Boulevard Mohamed V, Casablanca Tel : +212 (0) 5 22 30 00 55 Fax : +212 (0) 5 22 45 17 30 Email :
[email protected] Encadrant dans l’établissement d’accueil : M. ELKAFIL Abdrahman Encadrant à l’ENSA : M. EL ALAMI Ahmed Date de début et de fin du stage : du 5 Mars au 31 Mai 2012. Rapport du projet de fin d’études Page 5 HAMLI Marouane Liste des abréviations Abréviation Désignation PGI Progiciel de Gestion Intégré ERP Enterprise Resource Planning SSLL Sociétés de Services en Logiciels Libres PME Petites et Moyennes Entreprises CRM Client Relationship Management UML Unified Modeling Language RUP Rational Unified Process XP eXtreme Programming 2TUP Two Track Unified Process DCI Dénomination Commune Internationale XML eXtended Markup Language BSD Berkeley Software Distribution SGBDRO Système de Gestion de Base de Données Relationnelle et Objet SQL Structured Query Language MVC Modèle Vue Contrôleur GPAO Gestion de Production Assistée par Ordinateur GTK The Gimp ToolKit WSGI Web Server Gateway Interface SGML Standard Generalized Markup Language GED Gestion Electronique Documentaire TVA Taxe sur la Valeur Ajoutée Rapport du projet de fin d’études Page 6 HAMLI Marouane Table des figures Figure 1: Logo Nextma ............................................................................................................ 13 Figure 2: Nextma sur la carte ................................................................................................... 13 Figure 3: Clients Nextma ......................................................................................................... 15 Figure 4: Cycle de développement en Y .................................................................................. 21 Figure 5: Planning du projet ..................................................................................................... 22 Figure 6: Interface d'Ubuntu 11.10 .......................................................................................... 34 Figure 7 : Logo PostgreSQL .................................................................................................... 35 Figure 8 : Interface Web d'OpenERP ....................................................................................... 36 Figure 9: Architecture d'OpenERP ........................................................................................... 38 Figure 10 : Dépendences du module officine ........................................................................... 45 Figure 11: Connexion ............................................................................................................... 47 Figure 12: Accueil OpenERP - client web ............................................................................... 48 Figure 13: Liste des modules OpenERP .................................................................................. 48 Figure 14: Gestion des utilisateurs ........................................................................................... 51 Figure 15: Gestion des groupes ............................................................................................... 51 Figure 16: Liste des médecins .................................................................................................. 52 Figure 17: Formulaire médecin ................................................................................................ 52 Figure 18:Formulaire patient .................................................................................................... 52 Figure 19: Bons de commande fournisseur .............................................................................. 53 Figure 20: Liste des réceptions................................................................................................. 54 Figure 21: Formulaire client ..................................................................................................... 54 Figure 22: Gestion des inventaires physiques .......................................................................... 55 Figure 23: Liste des mouvements de stock ............................................................................. 55 Figure 24: Liste des règles de stock minimum ......................................................................... 56 Figure 25: Formulaire produit – I............................................................................................. 56 Figure 26: Formulaire produit - II ............................................................................................ 57 Figure 27: Produit en stock d'alerte .......................................................................................... 57 Figure 28: Analyse des mouvements de stocks ........................................................................ 57 Figure 29: Liste des factures clients ......................................................................................... 58 Figure 30: Détails facture client ............................................................................................... 58 Figure 31: Paiements clients .................................................................................................... 59 Figure 32: Point de vente ......................................................................................................... 60 Figure 33: Paiement en espèces ............................................................................................... 60 Figure 34: Assistant d'ouverture des caisses ............................................................................ 61 Figure 35: Liste des méthodes de paiement ............................................................................. 61 Figure 36: Formulaire de création/modification d'une méthode de paiement .......................... 61 Figure 37: Liste des caisses ...................................................................................................... 62 Figure 38: Journal des ventes ................................................................................................... 62 Figure 39: Ordre de vente......................................................................................................... 62 Figure 40: Renseignement des informations d'ordonnance...................................................... 63 Rapport du projet de fin d’études Page 7 HAMLI Marouane Figure 41: Catégories des produits - point de vente ................................................................. 63 Figure 42: Analyse du point de vente par produit .................................................................... 64 Figure 43: Analyse des enregistreuses par utilisateur .............................................................. 64 Diagrammes Diagramme 1: Gestion basique ................................................................................................ 26 Diagramme 2: Vente au comptoir ............................................................................................ 27 Diagramme 3: Gestion des achats ............................................................................................ 28 Diagramme 4: Gestion des ventes ............................................................................................ 29 Diagramme 5 : Gestion du stock .............................................................................................. 30 Diagramme 6: Cas d'utilisations - Statistiques et alertes.......................................................... 31 Diagramme 7: Diagramme des classes - fonctionnel ............................................................... 32 Tableaux Tableau 1 : Comparaison des méthodes de développement ..................................................... 20 Tableau 2: Liste des fonctionnalités requises ........................................................................... 25 Tableau 3: Description des modules OpenERP en relation avec l'officine .............................. 44 Tableau 4 : attributs du produit ................................................................................................ 49 Tableau 5: Attributs de la méthode de paiement ...................................................................... 50 Rapport du projet de fin d’études Page 8 HAMLI Marouane Table des matières Dédicace ..................................................................................................................................... 2 Remerciements ........................................................................................................................... 3 Résumé ....................................................................................................................................... 4 Avant-propos .............................................................................................................................. 5 Liste des abréviations ................................................................................................................. 6 Table des figures ........................................................................................................................ 7 Diagrammes ............................................................................................................................... 8 Tableaux ..................................................................................................................................... 8 Introduction générale ................................................................................................................ 11 Partie I : Contexte général du projet......................................................................................... 12 1 2 Chapitre I : Présentation de l’organisme d’accueil .......................................................... 13 1.1 Présentation de Nextma ............................................................................................. 13 1.2 Prestations et services ................................................................................................ 14 1.3 Secteurs d’activité...................................................................................................... 14 1.4 Références ................................................................................................................. 15 Chapitre II : Cadre général du projet ................................................................................ 16 2.1 Présentation générale de l’officine ............................................................................ 16 2.2 Problématique ............................................................................................................ 16 2.3 Objectifs du projet ..................................................................................................... 17 2.4 Conduite du projet ..................................................................................................... 19 2.4.1 Processus du développement .............................................................................. 19 2.4.2 Planification du projet ........................................................................................ 22 Partie II : Etude fonctionnelle et technique .............................................................................. 24 3 Chapitre III : Analyse et Conception du projet ................................................................ 25 3.1 Analyse du projet ....................................................................................................... 25 3.2 Conception ................................................................................................................. 26 3.2.1 1. Gestion basique : .................................................................................................... 26 3.2.2 4 Diagramme des cas d’utilisations :..................................................................... 26 Diagramme des classes : .................................................................................... 31 Chapitre IV : Technologies mises en œuvre .................................................................... 34 4.1 Ubuntu ....................................................................................................................... 34 4.2 PostgreSQL ................................................................................................................ 35 Rapport du projet de fin d’études Page 9 HAMLI Marouane 5 4.3 OpenERP ................................................................................................................... 36 4.4 Python ........................................................................................................................ 40 4.5 XML .......................................................................................................................... 42 Chapitre IV : Développement du module « officine » ..................................................... 43 5.1 Analyse fonctionnelle des modules OpenERP .......................................................... 43 5.2 Module « Officine » .................................................................................................. 46 5.3 Installation ................................................................................................................. 47 5.4 Paramétrage ............................................................................................................... 48 5.4.1 Général ............................................................................................................... 48 5.4.2 Plan comptable ................................................................................................... 49 5.4.3 Produit ................................................................................................................ 49 5.4.4 Méthodes de paiements : .................................................................................... 49 5.5 Simulation .................................................................................................................. 51 5.5.1 Gestion de base ................................................................................................... 51 5.5.2 Gestion des achats .............................................................................................. 53 5.5.3 Gestion des ventes .............................................................................................. 54 5.5.4 Gestion du stock ................................................................................................. 55 5.5.5 Comptabilité ....................................................................................................... 58 5.5.6 Point de vente ..................................................................................................... 60 5.6 Problèmes rencontrés ................................................................................................. 64 Conclusion ................................................................................................................................ 65 Bibliographie & webographie .................................................................................................. 66 Bibliographie ........................................................................................................................ 66 Webographie ........................................................................................................................ 66 Annexe A.................................................................................................................................. 67 Rapport du projet de fin d’études Page 10 HAMLI Marouane Introduction générale Le présent rapport est le fruit de mon travail effectué au sein de la société Nextma à Casablanca, ce stage de 3 mois est le couronnement de ma formation pour obtenir le diplôme d’Ingénieur d’Etat, en génie informatique, à l’ENSA Tanger. Durant ces trente dernières années, l’informatique de gestion a subi des bouleversements considérables. Les avancées technologiques du traitement de l’information ont eu des conséquences capitales sur le rôle de l’outil informatique. Si les premières applications ont permis d’automatiser les activités opérationnelles des organisations (gestion de production, gestion commerciale et financière, ressources humaines), aujourd’hui les systèmes d’information prennent en charge des niveaux de gestion de plus en plus stratégiques. Les ERP (Enterprise Resource Planning) ou PGI (Progiciels de Gestion Intégrés), ont connu leur essor en profitant de l’évolution nécessaire des systèmes d’information pour le passage de l’an 2000 puis pour la mise en place de l’euro. En effet, il était séduisant de remplacer tous les logiciels de gestion de l’entreprise par un intégré offrant « l’état de l’art » plutôt que d’engager des corrections des programmes existants plus ou moins anciens. Mon Projet de Fin d’Etudes est autour d’OpenERP, un PGI open-source extrêmement modulaire, et a pour but d’adapter puis intégrer cette solution pour permettre la gestion des officines pharmaceutiques. Le travail consiste à effectuer d’abord une analyse du besoin, afin de bien souligner les différentes fonctionnalités requises, ensuite à chercher parmi ces fonctionnalités celles qui sont déjà offertes par OpenERP, comme ça je pourrai entamer le développement des fonctionnalités restantes qui n’existent pas encore, pour enfin faire des tests de simulation, détecter et corriger les bugs si jamais il y en a. Ce rapport est scindé en deux grandes parties : la première, composée de deux chapitres, définit le contexte général du projet ; Le premier chapitre présente l’organisme d’accueil, tandis que le second concerne le cadre général du projet, et la démarche suivie pour assurer son bon déroulement. Quant à la seconde partie, composée de trois chapitres, concerne à tout ce qui est étude fonctionnelle et technique, ainsi le troisième chapitre est autour de l’analyse et la conception du projet, le suivant décrit les choix des technologies mises en œuvre, alors que le dernier explique l’étape du développement, ainsi que la simulation et les différents problèmes rencontrés. En fin, ce rapport est terminé par une conclusion sur l’apport du travail réalisé et des perspectives futurs où il peut déboucher. Rapport du projet de fin d’études Page 11 HAMLI Marouane Partie I : Contexte général du projet Chapitres : - Rapport du projet de fin d’études Page 12 Présentation de l’organisme d’accueil Cadre général du projet HAMLI Marouane 1 Chapitre I : Présentation de l’organisme d’accueil 1.1 Présentation de Nextma Figure 1: Logo Nextma Nextma est une Société de Services en Logiciels Libres (SSLL) qui accompagne les entreprises et institutions dans le choix des solutions open source ainsi que dans l'intégration, le développement, l'adaptation aux besoins spécifiques, la maintenance et le support. Afin de bénéficier des meilleures solutions libres dans la gestion des systèmes d'information. Figure 2: Nextma sur la carte Nextma a développé une expertise autour d’OpenERP depuis 2006 (premier partenaire officiel OpenERP au Maroc en 2007) et a contribué à faire connaître cet ERP open source au Maroc à travers plusieurs déploiements réussis dans les PME marocaines et des conférences dans les universités et adapte celui-ci à la législation marocaine et aux besoins spécifiques des entreprises. Rapport du projet de fin d’études Page 13 HAMLI Marouane 1.2 Prestations et services Nextma offre une large palette de prestations et de services basés sur des composants libres adaptés aux systèmes et aux réseaux des clients. La principale tâche de cette société est d’offrir des solutions sur mesure, en matière de formation et d’assistance, concernant les problématiques relevant des systèmes d’informations, moyennant des outils libres. La gamme de services de Nextma est articulée autour de quatre axes majeurs qui permettent d'accompagner les clients durant toutes les phases d'un projet afin d'en assurer sa réussite en : Formation : L’offre des formations, techniques et fonctionnelles, permet d'accompagner les organisations qui disposent d’équipes opérationnelles capables de mener à bien des projets. Ces formations peuvent être établies sous forme de transferts de compétences, en phases avals des projets. Support : En plus des offres de formations, la société propose aux équipes dédiées au développement, des prestations de support d’aide à la maintenance, afin de réduire le temps de résolution des interrogations ou des difficultés que les entreprises pourraient rencontrer lors de la mise en œuvre de certains logiciels. Conseil : Nextma possède une équipe formée de consultants techniques et fonctionnels qui assure soit dans le cadre de projets, soit en amont, des missions de conseil dans les domaines suivants: gestion de contenu, travail collaboratif, dématérialisation des procédures, migration vers le libre, architecture et dimensionnement d'applications basées sur OpenERP…etc. Développement : le cœur métier de Nextma et comprend le développement sur la base de logiciels libres, de portails collaboratifs internet ou intranet, avec des composantes de publication web, de travail collaboratif, de gestion électronique de documents et de workflow. 1.3 Secteurs d’activité De par les multiples projets que Nextma a mené, elle a acquis un savoir-faire susceptible de lui permettre l’implantation de logiciels libres dans les différents secteurs: Enterprise Ressource Planning (ERP) : la solution adoptée par Nextma est OpenERP, un PGI Open-Source. Customer Relationship Management (CRM) SUGARCRM qui permet la gestion de la relation client. : Nextma propose l’offre Intranet des entreprises et gestion des contenus : Création d’identités visuelles et sites internet institutionnels et e-Commerce. La solution proposée est Virtuemart, une solution libre de e-commerce (Commerce électronique) qui s'appuie sur le système de gestion du contenu « Joomla ». Rapport du projet de fin d’études Page 14 HAMLI Marouane Gestion électronique des documents : Il s’agit d’un système informatisé d'acquisition, classement, stockage et archivage des documents. La solution proposée est Alfresco. 1.4 Références Nextma compte plusieurs déploiements réussît d’OpenERP dans des PME marocaines dont je cite quelques références : Figure 3: Clients Nextma Rapport du projet de fin d’études Page 15 HAMLI Marouane 2 Chapitre II : Cadre général du projet 2.1 Présentation générale de l’officine La pharmacie d'officine est la branche la plus connue de la pharmacie. C'est la branche regroupant les pharmaciens qui travaillent dans les pharmacies de ville, appelées aussi officines, où les médicaments sont délivrés au public. Le rôle du pharmacien d'officine est la délivrance des ordonnances prescrites par les médecins, les conseils associés à la prise des médicaments, à l'hygiène, à la nutrition ou, plus globalement, à la santé publique. Le travail du pharmacien d'officine est aussi l'analyse de l'ordonnance, la vérification des posologies, des interactions médicamenteuses et des contre-indications existantes en fonction de l'état du patient. Le pharmacien, étant au bout de la chaîne de la prescription médicale, est responsable des médicaments délivrés, même en cas d'erreur ou négligence de la part du médecin prescripteur. À ce titre, il peut refuser de délivrer l'ordonnance, ou bien modifier les posologies ou médicaments, le plus souvent après accord avec le médecin prescripteur. Il peut également faire le suivi du traitement et aider à l'établissement d'un plan pharmacothérapique. Le pharmacien d'officine a aussi un rôle social, il est en mesure d'indiquer aux personnes en difficulté les organismes ou les structures compétentes en matière de Santé Publique et d'aides sociales. 2.2 Problématique Les officines marocaines souhaitent s’ouvrir sur les nouvelles technologies et les utiliser pour avoir un meilleur rendement, et ainsi intégrer des solutions de gestion complètes, paramétrables et flexibles pour la gestion de tout ce qui se rapporte au domaine de la pharmacie. Certes il existe des solutions sur le marché, mais elles sont payantes, en plus du fait qu’il est difficile de communiquer entre ces applications avec d’autres solutions « externes » (le cas d’automatiser les commandes de médicaments), et leur support est bien limité vu qu’elles ont été codées à la demande, à noter aussi qu’elles ne sont pas flexibles. Avec ces outils, le pharmacien se retrouve obligé d’effectuer lui-même un bon nombre de tâches qui normalement, avec ces solutions, doivent être automatisées, je cite comme exemple envoyer des bons de commande vers le grossiste (fournisseur) : le pharmacien (agent ou administrateur) crée un bon de commande avec une liste des produits demandés ainsi que Rapport du projet de fin d’études Page 16 HAMLI Marouane leur quantités, ce bon devra être transmis automatiquement vers un fournisseur parmi ceux enregistrés dans la liste, après sa validation, cette option était opérationnelle avant, mais nécessitait une installation matérielle particulière (modems 56k..etc) qui n’était pas disponible chez tous les partenaires, et a été abandonnée plus tard, donc le pharmacien est obligé de passer par la méthode classique qui est passer sa commande par téléphone. Les bons de commande sont donc temporaires, et se trouvent dans la plupart des cas supprimés après avoir effectué la réception des produits. Autre problème que le pharmacien rencontre, est quand l’application plante, et qu’il n’a plus accès à certaines données, comme ce cas dont j’étais témoin lors de ma visite à l’officine du client, la liste des fournisseurs a été endommagée et n’était plus accessible, ce qui empêchait d’établir des bons de commande ou effectuer des réceptions dans le logiciel, ainsi les bons de livraisons des grossistes s’entassaient les uns sur les autres, en attendant que la service support du logiciel envoie un technicien pour rétablir la base de données. Ceci avait d’autres conséquences, le pharmacien était habitué à faire une sauvegarde quotidienne de ses transactions, cette sauvegarde n’était plus possible depuis que la liste des fournisseurs est perdue, ce qui représente un grand risque pour ces données, surtout qu’il était en période de garde et avait effectué plusieurs ventes et réceptions. En plus, les quantités des produits au stock sont devenues toutes fausses. L’éditeur du logiciel proposait une assistance instantanée, via un logiciel d’assistance à distance, qui n’a pas été fourni à tous ses clients, et la seule solution pratique était d’envoyer les techniciens réparer les machines ne fonctionnant plus. Résultat : près de 5 jours d’attente, sans aucune sauvegarde, avec des données erronées, et encore faut-il du temps pour saisir toutes ces réceptions effectuées pendant la panne, après la réparation du logiciel. 2.3 Objectifs du projet Le travail demandé est d’adapter un progiciel libre, OpenERP, aux besoins des officines, en essayant de rajouter de nouvelles fonctionnalités que les autres solutions ne peuvent offrir. Afin de garantir une modernisation des services des officines, il est indispensable d’adopter les nouvelles technologies et les exploiter pour en tirer le meilleur profit. Les PGI sont connus pour leur intégration des principales fonctions nécessaires à la gestion des flux et procédures de l’entreprise (comptabilité, achats, ventes…), tous ces outils accèdent à des ressources communes, en particulier des bases de données. Parmi les autres avantages des PGI, c’est qu’ils sont conçus de telle sorte qu'un "simple" paramétrage suffit à les adapter à l'organisation de l'entreprise. Il n'est normalement pas nécessaire d'effectuer des développements spécifiques, sauf en cas de nécessité, lorsque ce Rapport du projet de fin d’études Page 17 HAMLI Marouane paramétrage ne permet pas de prendre en compte des particularités liées au métier des officines. Donc, le système d’information à développer aura pour objectifs : - - Objectifs globaux : o Disposer d’un outil de gestion complet, qui contribuera à l’évolution des officines o Disposer d’un outil dont le support ne nécessite pas trop de ressources, et qui pourra communiquer avec d’autres applications sans complication Objectifs spécifiques : o Permettre une gestion des éléments de bases, comme les clients, patients, médecins et fournisseurs o Permettre une « vente au comptoir » aisée, avec une interface ergonomique qui facilite la recherche des produits, et supporte plus qu’une méthode de paiement. o Permettre d’effectuer des achats auprès des fournisseurs, où il est possible d’éditer des devis, de créer des bons de commande et de recevoir les produits o Permettre une gestion de stock efficace, avec la possibilité de faire des inventaires physiques et de voir l’état des stocks n’importe quand. o Permettre le suivi des clients, voir leur situation en tout moment, et régler leur crédit s’ils en ont. o Enfin, avoir des statistiques concernant ces points cités auparavant Rapport du projet de fin d’études Page 18 HAMLI Marouane 2.4 Conduite du projet 2.4.1 Processus du développement Introduction La complexité croissante des systèmes informatiques a conduit les concepteurs à s’intéresser aux méthodes. On a comptabilisé en 1994 jusqu’à 50 méthodes. Chaque méthode se définit par une notation et un processus spécifique. UML a ouvert le terrain en fusionnant la notation. Il reste cependant à définir le processus pour réellement capitaliser des règles dans le domaine du développement logiciel. Les groupes de travail UML ont donc travaillé à unifier non pas les processus, mais plus exactement les meilleures pratiques de développement objet. Ces processus ce distingueront par le générique « UNIFIED PROCESS ». Un processus définit une séquence d’étapes, en partie ordonné, qui concoure à l’obtention d’un système logiciel ou à l’évolution d’un système existant. Pour produire des logiciels de qualité, qui répondent aux besoins des utilisateurs dans des temps et des coûts prévisibles. On découpe le processus en deux axes : - L’axe de développement technique, qui de concentre principalement sur la qualité de production. - L’axe de gestion du développement, qui permet la mesure et la prévision des coûts et des délais. Choix de la méthodologie de conception Avant d’adopter une méthode, il faut d’abord faire une comparaison entre les différentes méthodes existantes, voir les points forts et les points faibles de chacune, puis déterminer celle qui va mieux dans le contexte du projet. Ci-dessous un tableau qui résume cette comparaison (la liste est non exhaustive, voir la page suivante) Rapport du projet de fin d’études Page 19 HAMLI Marouane Rational Unified Process (RUP) Description -Méthodologie centrée sur l’architecture et couplée aux diagrammes UML -Concerne des projets de +10 personnes -Processus complet assisté par des outils exhaustifs eXtreme Programming (XP) -Développement guidé par les besoins du client -Equipes réduites, centrées sur les développeurs Two Track Unified Process (2TUP) -Articulé autour de l’architecture -Cycle de développement en Y -Convient aux projets de toutes tailles Points forts -Itératif -Spécifie le dialogue entre les différents intervenants du projet : les livrables, plannings et prototypes… -Propose des modèles de documents, et des canevas pour des projets types -Rôles bien définis, modélisation -Itératif -Simple à mettre en œuvre -Laisse une large place aux aspects techniques -Builds journaliers -Amélioration constante adaptation aux modifications -Itératif, laisse une large partie à la technologie et à la gestion du risque -Définit les profils des intervenants, les livrables, les prototypes Points faibles -Coûteux à personnaliser -Très axé processus, au détriment du développement -Lourd, largement étendu, il peut être difficile à mettre en œuvre de façon spécifique -Convient pour les grands projets qui générent beaucoup de documentation -Ne couvre pas les phases en amont et en aval du développement -Assez flou dans sa mise en œuvre : quels intervenants ? Quels livrables ? -Focalisé sur l’aspect individuel du développement, au détriment d’une vue globale et des pratiques de management ou de formalisation. -Superficiel sur les phases en amont et en aval du développement -Aucune proposition de document type Tableau 1 : Comparaison des méthodes de développement Pour atteindre les objectifs, j’ai suivi la méthode 2TUP (2Track Unified Process), qui sera plus détaillée dans ce qui suit. Rapport du projet de fin d’études Page 20 HAMLI Marouane Cycle de vie du modèle 2TUP Le modèle 2TUP repose sur cinq principes fondamentaux : o Séparer les aspects fonctionnels et les aspects techniques o Travailler selon deux points de vue qui se complètent et s’enrichissent mutuellement ; celui de l’entreprise, celui des applications. o Modéliser l’activité de l’entreprise et des applications aux moyens d’objets en utilisant UML. o Faire des maquettes et des prototypes pour affiner les besoins fonctionnels et les aspects techniques. o Effectuer la réingénierie des applications dans le sens de la réutilisation. Le schéma suivant montre bien le cycle en « Y » caractéristique de 2TUP. Figure 4: Cycle de développement en Y Rapport du projet de fin d’études Page 21 HAMLI Marouane 2.4.2 Planification du projet Le diagramme de GANT ci-dessous présente les différentes tâches nécessaires pour réaliser le projet : Figure 5: Planning du projet Rapport du projet de fin d’études Page 22 HAMLI Marouane Pour bien mener ce projet, je me suis déplacé, dans un premier temps, à l’officine du client, afin de découvrir les différentes activités et processus métier de ce domaine, des notes concernant ceci ont été prises, et des explications ont été fournies pour chaque question concernant un processus plus ou moins compliqué. Après cette visite des lieux, je suis passé à l’étape suivante qui est de reformuler les différents points pour bien limiter les besoins requis et ensuite élaborer un cahier des charges que le client devra consulter, et validera si tous les points cités correspondent à ceux qu’il cherche. Les PGI sont un nouveau monde pour moi, il est donc évident de prendre un peu de temps pour se familiariser avec, comprendre leur coté technique d’abord, puis comprendre leur coté fonctionnel. Et comme OpenERP est écrit en Python, combiné à XML pour générer les différentes vues, j’ai eu à lire quelques livres sur le développement avec python, et aussi avec le framework « Open Object », dédié au développement sous OpenERP. Une fois familiarisé un peu avec l’outil, je suis passé à écrire quelques modules simples pour s’assurer que j’ai bien assimilé sa technique de développement, comme ça je pourrais me lancer dans la découverte fonctionnelle du PGI, car c’est à travers elle que je déterminerai les modules déjà existants et qui répondent en partie aux exigences du client. Cette découverte m’a permis de fixer les fonctionnalités non existantes et qui devront être ajoutées, en plus du paramétrage à mettre en place. Après avoir créé les objets manquants, et après avoir paramétré l’application, j’ai commencé à faire des simulations, afin de s’assurer que le paramétrage suivi est le bon, et aussi chercher si il y a des bugs dans le module que je viens de créer, ou dans les autres modules auxquels il est lié, puis je suis parti à la recherche de solutions pour les différentes anomalies détectées. Rapport du projet de fin d’études Page 23 HAMLI Marouane Partie II : Etude fonctionnelle et technique Chapitres : - Rapport du projet de fin d’études Page 24 Analyse et conception du projet Technologies mises en œuvre Développement du module « officine » HAMLI Marouane 3 Chapitre III : Analyse et Conception du projet 3.1 Analyse du projet Le but du projet est d’adapter OpenERP pour qu’il puisse permettre une gestion d’officine. Il est donc nécessaire de faire une visite des lieux, une pharmacie, afin de bien cadrer son contexte, et de faire une liste des différentes fonctionnalités requises pour une telle gestion, avant de développer cette liste en un cahier des charges pour le valider avec le client. Les fonctionnalités requises sont présentées dans le tableau ci-dessous : Objectif Gestion de base Vente au comptoir Gestion des achats Gestion des ventes Gestion de stock Statistiques - Fonctionnalités Gestion des médicaments Gestion des clients Gestion des fournisseurs Gestion des patients Gestion des médecins Gérer les DCIs Recherche de produits multicritère (nom, code ou code à barre) Paiement supportant différentes méthodes de paiement (espèces, chèques, crédit, ou carte de crédit) Impression du ticket de vente Gestion de l’ordonnancier (vente sur ordonnance) Consulter le journal du comptoir Consulter la liste des fournisseurs Créer des devis de fournisseurs Créer des bons de commandes Effectuer des réceptions de médicaments Suivi des règlements fournisseurs Consulter la liste des clients Gestion des avoirs clients Suivi des règlements clients Consulter le journal des ventes Edition des devis Consulter la liste de produit Effectuer des inventaires physiques Voir les mouvements de stock Calcul des écarts entre stock initial et stock actuel Afficher le stock réel Consulter les produits en stock d’alerte (quantité insuffisante) Distribution mensuelle des ventes par client Distribution mensuelle des achats par fournisseur Distribution détaillée des achats par produit / fournisseur Distribution détaillée des ventes par produit / client Tableau 2: Liste des fonctionnalités requises Rapport du projet de fin d’études Page 25 HAMLI Marouane 3.2 Conception L’étape de conception est très importante pour la réussite d’un projet informatique car elle vise à définir une feuille de route du projet, le concevoir et le valider avant de passer au développement du système. Elle permet aussi d’avoir une bonne réflexion avant de passer à l’action, une bonne organisation du travail et une bonne communication entre les différents intervenants dans le projet. J’ai utilisé des diagrammes UML pour cette étape, vu qu’il est le plus approprié pour les projets informatiques orientés objet, et aussi car ses diagrammes facilitent la lisibilité et la compréhension des modèles même pour les ceux qui sont loin du domaine informatique. Le principal avantage d'UML est qu'il est devenu le standard en termes de modélisation objet, son caractère polyvalent et performant et sa souplesse en fait un langage universel. 3.2.1 Diagramme des cas d’utilisations : Dans ce projet, j’ai six grands cas d’utilisations, ces cas sont détaillés dans les diagrammes suivants : 1. Gestion basique : Diagramme 1: Gestion basique La gestion basique veut dire l’ajout, modification et suppression des objets élémentaires dans une officine, à savoir les médicaments, les fournisseurs, les clients, les médecins, les patients, les DCI (Dénomination Commune Internationale, nom du composant chimique principal d’un médicament), les utilisateurs et leurs groupes. Cette gestion est limitée aux administrateurs, qui n’auront la main pour effectuer leurs modifications qu’après s’être connecté. Rapport du projet de fin d’études Page 26 HAMLI Marouane 2. Vente au comptoir : Diagramme 2: Vente au comptoir La vente au comptoir est l’activité principale dans une officine, dans ce cas, un simple agent, reçoit la demande du client, ensuite recherche les médicaments demandées, puis renseigne les quantités de chaque produit, les ajoute à la liste, comme il peut retirer des produits de la liste, selon la demande du client, après il calcule le total du ticket, applique une remise s’il y en a et informe le client du montant. Vient ensuite l’étape du paiement, là le client déclare la méthode de paiement qu’il souhaite, et l’agent la choisit parmi sa liste de méthodes disponibles, si le client opte pour un crédit, alors l’ordre de vente se transforme en facture ouverte au client jusqu’à son paiement. Une fois payé, l’agent livre les médicaments au client, et peut lui imprimer le ticket de vente et le lui remettre. Si le client amène une ordonnance, l’agent suit une procédure similaire à celle décrite cidessus, avec la particularité qu’il doit renseigner dans cette vente le nom du médecin l’ayant établi, en plus du patient à qui elle est destinée. Il est possible que dans cette vente se trouvent des produits n’ayant pas de relations avec l’ordonnance, ce cas est connu comme « vente libre ». Rapport du projet de fin d’études Page 27 HAMLI Marouane 3. Gestion des achats : Diagramme 3: Gestion des achats La gestion des achats permet au pharmacien de se procurer des médicaments auprès de ses fournisseurs. Il lui est possible de créer des devis des grossistes, convertir ces devis en bons de commande, choisir la méthode de facturation de ces derniers, et les valider. Une fois ces bons validés, des réceptions de produits, correspondants chacune à un bon de commande, sont générées automatiquement et passent au statut « en attente de traitement ». Le traitement des réceptions peut être partiel ou total, c’est-à-dire que lors d’une réception le pharmacien peut recevoir la totalité des produits commandés, traiter la réception et passer à la facturation, ou recevoir une partie des produits seulement, dans ce cas il ne renseigne que la quantité reçue et valide la réception, cette dernière est dupliquée, et le duplicata est une nouvelle réception contenant le reste des produits à recevoir, en statut « en attente de traitement ». Après la réception des produits, le pharmacien passe à la facturation des produits reçus, pour payer le fournisseur. Il pourra par la suite consulter les factures établies et voir leurs situations. Les factures payées sont écrites dans le journal des achats. Rapport du projet de fin d’études Page 28 HAMLI Marouane 4. Gestion des ventes : Diagramme 4: Gestion des ventes Les ventes se font toutes au niveau du point de vente, la gestion des ventes ici concerne le suivi des clients qui se procurent des produits par crédit, car dans cette partie l’agent peut consulter les factures des clients et voir celle qui sont toujours ouvertes, aussi il pourra consulter la liste de ses clients et voir le montant des crédits de chacun. Cette gestion permet aussi de gérer les avoirs, produits retournés par les clients pour différentes raisons, une mauvaise commande par exemple. A travers ce volet, le pharmacien peut aussi éditer des devis pour des clients qui viennent se renseigner sur les prix de certains médicaments. Enfin, le pharmacien a la possibilité de consulter le journal des ventes, où se trouvent les écritures comptables des ventes par crédit. Rapport du projet de fin d’études Page 29 HAMLI Marouane 5. Gestion du stock : Diagramme 5 : Gestion du stock La gestion du stock concerne la gestion des produits, où il est possible de voir la liste de produits, voir les mouvements du stock, effectuer des inventaires physiques, voir l’état réel du stock, et même voir les écarts entre stock actuel et stock initial. 6. Statistiques et alertes : Rapport du projet de fin d’études Page 30 HAMLI Marouane Diagramme 6: Cas d'utilisations - Statistiques et alertes Ce volet est autour de tout ce qui est statistiques utiles pour le pharmacien, afin d’avoir une idée claire de ses ventes et ses achats, comme la distribution des ventes par produit ou par client, la distribution des achats par produit ou par fournisseur, la distribution détaillée des ventes ou achats. Le pharmacien pourra consulter les produits en stock d’alerte afin de pouvoir les commander à nouveau. 3.2.2 Diagramme des classes : Le diagramme suivant est le diagramme de classes « fonctionnel » que j’ai réalisé avant de me lancer dans le développement. Rapport du projet de fin d’études Page 31 HAMLI Marouane Diagramme 7: Diagramme des classes - fonctionnel Ce diagramme représente les classes nécessaires pour assurer un bon fonctionnement du système à mettre en œuvre, les utilisateurs de l’application sont regroupés dans des groupes, chaque groupe possédant des privilèges qui permettent à ses utilisateurs inscrits d’accéder à certaines fonctionnalités. Les utilisateurs peuvent effectuer des achats de produits auprès des fournisseurs, chaque achat se compose des lignes d’achat, chacune de ces lignes contient un médicament désigné, avec la quantité à acheter. Un médicament est lié à la classe DCI de deux façons : la première concerne sa composition, car un médicament est composé d’une ou plusieurs DCI, avec en général une seule DCI connue, qui est sa composante principale. La deuxième liaison concerne les contreindications d’un médicament, qui ne sont autres que des DCI qui risquent de causer des complications si elles sont combinées ensemble. Les médicaments sont ensuite vendus au public, chaque vente, liée à un utilisateur, comporte des lignes de ventes, qui regroupent le médicament vendu, sa quantité, sa remise, et indique si elle fait partie d’une ordonnance ou non. Si la ligne fait partie d’une ordonnance alors l’utilisateur devra renseigner le nom du médecin qui a écrit cette dernière, en plus du nom du patient concerné. Si le client souhaite payer par crédit, le vendeur devra renseigner dans ce cas le nom de ce client, afin que le montant de cette vente s’ajoute à son crédit. Rapport du projet de fin d’études Page 32 HAMLI Marouane Evidemment, des changements ont eu lieu sur ce diagramme, surtout après la recherche des modules OpenERP existants qui répondent en partie aux besoins du cahier des charges, ce qui a imposé ces modifications. Rapport du projet de fin d’études Page 33 HAMLI Marouane 4 Chapitre IV : Technologies mises en œuvre Ce chapitre décrit les différentes technologies adoptées par Nextma, et utilisées pour la réalisation de ce projet, à commencer par le système d’exploitation Ubuntu, tout en passant par le PGI OpenERP, le système de gestion de bases de données PostgreSQL, et en fin les langages nécessaires pour le développement, à savoir le langage Python et XML. 4.1 Ubuntu Ubuntu est un système d’exploitation libre commandité par la société Canonical et une marque déposée par cette même société. Fondé sur la distribution Linux Debian et utilisant le bureau Unity, Ubuntu se veut « convivial, intuitif et sûr ». Il est constitué de logiciels libres, est disponible gratuitement y compris pour les entreprises, et bénéficie d'une nouvelle version (appelée « mise à niveau ») tous les six mois. Avec une utilisation globale estimée à plus de 25 millions d'utilisateurs, il est principalement conçu pour une utilisation sur des ordinateurs personnels (portables et fixes), bien que d'autres versions consacrées aux netbooks et aux serveurs existent aussi. Depuis Ubuntu 11.04, la version Netbook a fusionné avec la version Desktop. Cette dernière étant passée à l'interface Unity, il n'y avait plus de raison de maintenir deux branches distinctes. Figure 6: Interface d'Ubuntu 11.10 La version d’Ubuntu utilisée pour ce projet est la 11.10, ayant pour nom de code « The Oneiric Ocelot », cette version est la quinzième version d'Ubuntu. Son développement s'est échelonné sur six mois, jusqu'à sa publication en tant que version stable le 13 octobre 2011. Rapport du projet de fin d’études Page 34 HAMLI Marouane Elle profitera des mises à jour de sécurité pendant une durée de 18 mois, soit jusqu'en avril 2013. 4.2 PostgreSQL PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD. Ce système est concurrent d'autres systèmes de gestion de base de données, qu'ils soient libres (comme MySQL et Firebird), ou propriétaires (comme Oracle, Sybase, DB2, Informix et Microsoft SQL Server). Comme les projets libres Apache et Linux, PostgreSQL n'est pas contrôlé par une seule entreprise, mais est fondé sur une communauté mondiale de développeurs et d'entreprises. PostgreSQL peut stocker plus de types de données que les types traditionnels entier, caractères, etc. L'utilisateur peut créer des types, des fonctions, utiliser l'héritage de type etc. PostgreSQL est pratiquement conforme (de plus en plus conforme) aux normes ANSI SQL 89, SQL 92 (SQL 2), SQL 99 (SQL 3), SQL:2003 et SQL:2008. Il fonctionne sur diverses plates-formes matérielles et sous différents systèmes d'exploitation. Figure 7 : Logo PostgreSQL PostgreSQL fonctionne sur Solaris, SunOS, Mac OS X, HP-UX, AIX, Linux, IRIX, Digital Unix, BSD, NetBSD, FreeBSD, OpenBSD, SCO unix, NeXTSTEP, UnixWare et toutes sortes d'Unix. Depuis la version 8.0, PostgreSQL fonctionne également nativement sur Windows. Avant la version 8, il fallait un émulateur de type cygwin pour faire fonctionner PostgreSQL sur ce système d'exploitation. PostgreSQL est largement reconnu pour son comportement stable, proche de Oracle. Mais aussi pour ses possibilités de programmation étendues, directement dans le moteur de la base de données, via PL/pgSQL. Le traitement interne des données peut aussi être couplé à d'autres modules externes compilés dans d'autres langages. Rapport du projet de fin d’études Page 35 HAMLI Marouane 4.3 OpenERP Anciennement connu sous le nom Tiny ERP, signifiant la fourmi de l’Enterprise resource planning) est un progiciel intégré de gestion ouvert, libre de droits comprenant les ventes, la gestion de relation client (CRM), la gestion de projet, la gestion d'entrepôt, la production, la comptabilité et les ressources humaines. OpenERP a trois composants séparés : le serveur openerp-server qui stocke ses données dans une base postgresql, le client openerpclient qui s'installe sur le poste de l'utilisateur et le serveur web openerp-web qui permet une utilisation depuis un navigateur. Ces trois composants communiquent par les protocoles xmlrpc et net-rpc. Figure 8 : Interface Web d'OpenERP Le logiciel est basé sur une forte architecture MVC, des flux de travail flexibles, une interface-utilisateur graphique dynamique, une interface XML-RPC, et un système personnalisable de comptes-rendus avec une intégration pratique d'OpenOffice.org. Dans la classification des logiciels, OpenERP, comme tout autre PGI sur le marché est un package destiné, a priori, à tous les secteurs, à toutes les fonctions, les adaptations nécessaires se faisant par paramétrage. Il dispose de forts arguments commerciaux pour séduire les dirigeants (il propose de mettre un terme au désordre du système d’information, et aussi de régler des problèmes d’organisation sans effort politique). Cette offre séduisante par sa qualité et sa cohérence se révèle à l’usage plus risquée que l’on avait pu l’imaginer : elle ne peut être efficace que si l’on accepte les contraintes qu’elle impose. Sa mise en œuvre comporte des difficultés et des pièges. Implanter un PGI a ses avantages, parmi lesquels je cite : o Optimisation des processus de gestion o Cohérence et homogénéité des informations o Intégrité et unicité du Système d’information Rapport du projet de fin d’études Page 36 HAMLI Marouane o Mise à disposition d’un outil multilingue et multidevises (très adapté aux multi-nationales) o Communication interne et externe facilitée par le partage du même système d’information o Meilleure coordination des services et donc meilleur suivi des processus (meilleur suivi de commande ou meilleure maîtrise des stocks par exemple) o Normalisation de la gestion des ressources humaines (pour les entreprises gérant de nombreuses entités parfois géographiquement dispersées) o Minimisation des coûts (formation et maintenance) o Maîtrise des coûts et des délais de mise en œuvre et de déploiement o Mise à disposition, des cadres supérieurs, d’indicateurs nettement plus fiables que lorsqu’ils étaient extraits de plusieurs systèmes différents Toutefois, cela peut avoir quelques inconvénients, comme la lourdeur et la rigidité de la mise en œuvre, ou encore les difficultés d’appropriation par le personnel de l’entreprise. OpenERP comporte plusieurs modules fonctionnels, je cite les exemples suivants : o o o o o o o o o o o o CRM ; gestion de la relation client Comptabilité analytique et financière (Conforme aux exigences françaises) Gestion des stocks Gestion de production (GPAO) Gestion de projets et des activités de services Norme qualité : ISO 9001 version 2000 Gestion des ventes Gestion des achats Marketing Logistique Ressources humaines Gestion documentaire Coté architecture, OpenERP est basé sur une architecture 3 tiers: 1. Un serveur de base de données PostgreSQL (qui peut contenir plusieurs bases de données) 2. Un serveur d'applications (contenant les objets de gestion, le moteur de workflow, le générateur d'édition, etc.) 3. Un serveur de présentation (appelé OpenERP Web) qui permet à l'utilisateur de se connecter à OpenERP avec n'importe quel navigateur internet (avec le lecteur Flash installé pour l'affichage des graphiques). Ce serveur n'est pas nécessaire si l'utilisateur utilise le client lourd mais qui nécessitera une installation physique sur le poste de l'utilisateur (cette application se nomme Client GTK). Rapport du projet de fin d’études Page 37 HAMLI Marouane Figure 9: Architecture d'OpenERP Ses fonctions de veille économique intégrées permettent à des utilisateurs multiples de traiter tous les aspects du logiciel. Ainsi, les rapports et les flux de travail peuvent être personnalisés. La partie serveur est écrite en langage Python. Les différentes briques sont organisées en «modules». Un module est un dossier avec une structure pré-définie contenant du code Python et des fichiers XML. Un module définit la structure de données, formulaires, rapports, menus, procédures, flux de travail, etc. Le client est léger car il ne contient pas de logique d'entreprise (l'ensemble est embarqué dans le serveur d'application). Ainsi, l'ajout de nouveaux objets, comme les menus ou formulaires, le rend accessible à tout type de client graphique (GTK+, Web, Qt, ou Texte). Le client GTK+ est par défaut et est basé sur la plateforme PyGTK (Python). Le client-web est écrit en langage Python. Il utilisait la plate-forme turboGears jusqu'à la version 5.0.1. Bien que concernant le contenu, les clients GTK + et -web soient équivalents, il existe certaines différences dans la fonctionnalité de l'interface. Par exemple le client-web peut avoir un lien de personnalisation sur chaque formulaire, mais le client GTK+ n'a pas de fonction comparable. Pour ce projet, la version d’OpenERP qui m’a été conseillée pour l’utiliser est la 6.1, parue en février 2012, cette version comporte plusieurs nouveautés : - Un meilleur partage des informations : Des fonctionnalités de partage des informations à des tiers ont été ajoutées. Il est par exemple possible de permettre l'accès aux données d'un projet en cours à un sous-traitant ou de permettre à un client de consulter les factures qui lui correspondent et de les imprimer. La refonte de l'interface Web riche en javascript permet en outre d'intégrer n'importe quelle partie de l'interface d'OpenERP à site Web tiers. Rapport du projet de fin d’études Page 38 HAMLI Marouane - - - Fonctions d'échanges EDI : Des fonctions d'Échange de données informatisé font leur apparition, permettant à un partenaire d'importer des données (par exemple une facture) le concernant dans son propre système OpenERP ou progiciel tiers (au format JSON), et même d'effectuer le paiement en ligne. Une interface mobile : Une nouvelle interface conçue pour l'utilisation sur les terminaux mobiles de type smartphone fait son apparition. Basée sur le framework JQuery Mobile, elle ne permet pour l'instant que la consultation en lecture seule des informations. Une interface destinée aux points de ventes : Une nouvelle interface dédiée aux points de ventes à écran tactiles, tablettes et autre dispositifs de caisse interactifs est inaugurée dans cette version d'OpenERP. Cette fonctionnalité très demandée permet d'utliser un lecteur de codes à barres, de sélectionner des produits par catégorie/sous catégorie, la recherche par nom de produits et peut fonctionner hors-ligne et se synchroniser automatiquement lorsque la connexion avec le serveur est rétablie. Et ce ne sont pas que les nouveautés qu’a apporté cette version, mais aussi des améliorations : o Une configuration plus simple : De nouveaux boutons de raccourcis font leur apparition, permettant de créer plus intuitivement de nouveaux documents et de nouveaux enregistrements directement à partir de leur saisie dans les champs de données. De même, une installation fraîche d'OpenERP inclut dorénavant une configuration minimale des modules, basée sur les bonnes pratiques et les utilisations les plus courantes observées chez les utilisateurs. o Un effort sur l'utilisabilité : L'installateur et l'assistant de configuration ont été repensés afin de faciliter la compréhension par les nouveaux utilisateurs, en demandant moins de détails sur la société à gérer et en se focalisant sur les informations absolument nécessaires. La page d'installation des modules propose par défaut une installation sous forme de « thèmes ». Par exemple, un clic sur le thème « Ventes » installera tous les modules nécessaires à la gestion des ventes, et vous dirigera ensuite automatiquement vers ce module configuré et prêt à l'emploi. o Importation des données facilitée : L'importation des données dans OpenERP à partir de sources tierces a été améliorée. En effet, un assistant fait son apparition permettant de facilement faire correspondre un fichier de données au format csv au schéma de données OpenERP. À noter aussi l’existence de fonctions d'importation automatisée des données depuis SugarCRM et Google Calendar. o Sous-système de courriels unifié : La configuration des paramètres de connexions pour l'envoi et la réception de courriels est maintenant unifiée, ce qui met fin à la duplication des configurations pour les modules tirant partie de ces fonctions de courriels. Rapport du projet de fin d’études Page 39 HAMLI Marouane o Refonte du module de paie : Le module de gestion de paie a été repensé, afin d'être plus flexible et s'adapter ainsi plus aisément aux spécificités de chaque pays et de chaque entreprise. o Ré-écriture de l'interface Web : L'interface Web d'OpenERP a été entièrement ré-écrite et fait dorénavant la part belle à la technologie Javascript, sans non plus bouleverser son apparence et l'expérience utilisateur. Parmi les conséquences, on peut noter qu'elle offre plus de fonctionnalités avec moins de code, et est plus rapide que l'ancienne implémentation de la 6.0. Au niveau des améliorations se trouve aussi la possibilité de personnaliser les tableaux de bord directement depuis l'interface avec de simples glisser-déposer, ainsi que l'arrivée d'une nouvelle forme de présentation des données, la vue « kanban ». o Compatibilité WSGI : De gros efforts ont été fait afin de rendre OpenERP compatible avec Web Server Gateway Interface qui permet de recourir à des serveurs d'application python tels que Gunicorn et uWSGI facilitant une implémentation extrêmement robuste d'OpenERP sur les serveurs, un bien meilleur contrôle de l'assignation des ressources matérielles et une simplification de la mise en place de mécanismes de réplication et de répartition de charge (les serveurs d'applications proposant souvent de telles fonctionnalités). 4.4 Python Python est un langage de programmation multi-paradigme. Il favorise la programmation impérative structurée, et orientée objet. Il est doté d'un typage dynamique fort, d'une gestion automatique de la mémoire par ramasse-miettes et d'un système de gestion d'exceptions ; il est ainsi similaire à Perl, Ruby, Scheme, Smalltalk et Tcl. Le langage Python est placé sous une licence libre proche de la licence BSD et fonctionne sur la plupart des plates-formes informatiques, des supercalculateurs aux ordinateurs centraux, de Windows à Unix en passant par Linux et Mac OS, avec Java ou encore .NET. Il est conçu pour optimiser la productivité des programmeurs en offrant des outils de haut niveau et une syntaxe simple à utiliser. Il est également apprécié par les pédagogues qui y trouvent un langage où la syntaxe, clairement séparée des mécanismes de bas niveau, permet une initiation plus aisée aux concepts de base de la programmation. Python est un langage : Rapport du projet de fin d’études Page 40 HAMLI Marouane o conçu pour produire du code de qualité, portable et facile à intégrer : grâce à sa syntaxe claire, cohérente et concise, Python permet aux développeurs de produire du code de qualité, lisible et maintenable. Écrire du code Python est un exercice agréable, même en respectant les conventions de codage. Fourni dès le départ avec des modules de tests, Python est un langage agile. Le terme agile est originellement issu de la méthodologie de programmation agile (Beck et Al.), très proche de la programmation itérative. Cette méthodologie, qui réduit les risques liés à la conception de logiciels, introduit entre autres des principes de tests continus du code. o De haut niveau, orienté objet et totalement libre : même si elle n’est pas imposée, Python permet la programmation orientée objet. Tous les mécanismes objet essentiels sont implémentés et toutes les données manipulées sont des instances de classes, comme pour les langages SmallTalk ou Ruby. Enfin, le code peut être structuré en modules (fichiers) qui sont ensuite importables dans l’interpréteur. Ce découpage, permet d’organiser le code et son utilisation par des espaces de noms, et aussi de faciliter l’extension du langage par des bibliothèques tierces compilées dans d’autres langages. o Hautement productif : La conception d’applications en Python est très rapide car certains aspects de programmation sont gérés automatiquement, comme la gestion des ressources mémoire et le typage des données. Grâce à des types de base très puissants et des primitives de haut niveau, un programme Python est simple à concevoir et concis. Un programme Python est en général 3 à 5 fois plus court qu’un programme C++ équivalent. Ces qualités font de Python un langage idéal dans beaucoup de domaines. Enfin, la bibliothèque standard de Python est très complète, et permet de répondre aux besoins communs de programmation. Grâce au modèle Open Source, la communauté des développeurs Python est en outre très productive et de nombreuses extensions gravitent autour du langage. o Dynamique : dans la plupart des implémentations, le code source n’est pas compilé contrairement à des langages comme C ou Pascal, mais exécuté à la volée. On parle alors de langage interprété. Ce mode de fonctionnement rend la programmation beaucoup plus souple puisqu’il est possible de changer un programme en cours d’exécution, ou de tester du code en mode interactif sans disposition particulière. L’interprétation rend aussi l’exécution plus lente, mais ce défaut est surmontable grâce à de bonnes pratiques de programmation et des techniques d’optimisation. Rapport du projet de fin d’études Page 41 HAMLI Marouane 4.5 XML XML (eXtensible Markup Language) est en quelque sorte un langage HTML amélioré permettant de définir de nouvelles balises. Il s'agit effectivement d'un langage permettant de mettre en forme des documents grâce à des balises (markup). Contrairement à HTML, qui est à considérer comme un langage défini et figé (avec un nombre de balises limité), XML peut être considéré comme un métalangage permettant de définir d'autres langages, c'est-à-dire définir de nouvelles balises permettant de décrire la présentation d'un texte (Qui n'a jamais désiré une balise qui n'existait pas ?). La force de XML réside dans sa capacité à pouvoir décrire n'importe quel domaine de données grâce à son extensibilité. Il va permettre de structurer, poser le vocabulaire et la syntaxe des données qu'il va contenir. En réalité les balises XML décrivent le contenu plutôt que la présentation (contrairement À HTML). Ainsi,XML permet de séparer le contenu de la présentation, ce qui permet par exemple d'afficher un même document sur des applications ou des périphériques différents sans pour autant nécessiter de créer autant de versions du document que l'on nécessite de représentations ! XML a été mis au point par le XML Working Group sous l'égide du World Wide Web Consortium (W3C) dès 1996. Depuis le 10 février 1998, les spécifications XML 1.0 ont été reconnues comme recommandations par le W3C, ce qui en fait un langage reconnu. (Tous les documents liés à la norme XML sont consultables et téléchargeables sur le site web du W3C, http://www.w3.org/XML/) XML est un sous ensemble de SGML (Standard Generalized Markup Language), défini par le standard ISO8879 en 1986, utilisé dans le milieu de la Gestion Electronique Documentaire (GED). XML reprend la majeure partie des fonctionnalités de SGML, il s'agit donc d'une simplification de SGML afin de le rendre utilisable sur le web ! XML fait partie du code des modules composants OpenERP, les vues par lesquelles sont représentés les différents objets sont écrites en XML, ainsi nous y trouvons la description détaillée de l’affichage des arbres, formulaires, menus et autres actions. Rapport du projet de fin d’études Page 42 HAMLI Marouane 5 Chapitre IV : Développement du module « officine » Dans ce chapitre, je présente les modules existants dans OpenERP et qui répondent partiellement aux besoins requis dans le cahier des charges, pour ensuite limiter les fonctionnalités restantes à mettre en œuvre. Une fois le développement terminé, il ne reste que le paramétrage à faire, pour assurer un bon fonctionnement du système. 5.1 Analyse fonctionnelle des modules OpenERP Avant de commencer l’étape du développement, il m’a fallut d’abord chercher parmi les modules existants sous OpenERP, ceux qui offrent des fonctionnalités exigées précédemment dans le cahier des charges fonctionnel. Après une analyse des différents modules, je peux décrire les modules utiles à mon système comme suit : Module Gestion de base Nom technique base Gestion de Stock stock Gestion des ventes sale Description Fonctionnalités Ce module est en fait le noyau Gestion des : d’OpenERP, il est nécessaire pour - Clients toute installation de nouveau - Workflow module. - Devises de monnaie En effet, dans ce module sont - Langues définis les objets de base, qui sont - Pays essentiels pour le bon - Sécurité de base fonctionnement du PGI Ce module sert de base pour la - Gestion d'entrepôt gestion de/des entrepôt(s) d’une - Les bons de livraison entreprise dans OpenERP - Traçabilité - Produits - Règles du Stock - Reporting Permet la gestion des ventes et Gestion et suivi des leur facturation. achats/ventes pour produits stockable/services. Relances. Gestion des listes de prix. Création automatique des bons de livraison. Facturation à partir des livraisons. Calcul automatique des prix en fonction des quantités et des délais de livraison. Proposition automatique de réapprovisionnement. Gestion des ristournes et promotions. Gestion des livraisons partielles et retours fournisseurs. Rapport du projet de fin d’études Page 43 HAMLI Marouane - Gestion des incoterms. Gestion des achats purchase Ce module concerne tout ce qui est en relation avec l’achat de produits Comptabilité account Ce module concerne comptabilité dans l’entreprise. Comptabilité & finance Account_acco untant Paiement Account_vouc her Point de vente Point_of_sale Ce module permet à l’administrateur d’accéder à toutes les options de la comptabilité comme les journaux et le plan comptable Ce module est utilisé pour Rajoute le bouton « paiement » effectuer le paiement des aux factures des clients et des différentes factures établies fournisseurs pour pouvoir effectuer les paiements Ce module, qui a été - Gestion des ventes complètement rénové, permet - Analyse des caisses d’avoir un point de vente et de - Analyse du point de vente vendre des produits dans une - Configuration des approche plus sociale que la vente méthodes de paiement des produits classiques dans - Configuration des caisses OpenERP. - Inscription des ventes dans Le point de vente tactile OpenERP les journaux… permet de gérer les ventes dans une boutique très facilement. Il est entièrement basé sur le Web et ne nécessite aucune installation ou déploiement de logiciel tiers et tous les commerces de vente peuvent être facilement consolidés. Il fonctionne en mode connecté et déconnecté de sorte qu’on puisse continuer à vendre si on n’est plus connecté à Internet. la - Demande de devis Les commandes d'achat Carnet d'adresses Contrôle des stocks Contrôle de facture - Ecritures dans journaux avec automatisation des contreparties. - Génération automatique des pièces comptables. - Automatisation complète : calculs de TVA, date d'échéance, équilibrage. - Gestion des conditions de paiement. - Rapprochement manuel ou automatique des écritures bancaires, avec gestion des ajustements. - Edition des documents : balance, grand livre, bilan, compte de résultat, déclaration TVA… - Gestion budgétaire. - Gestion des journaux - Gestion des registres de caisse Tableau 3: Description des modules OpenERP en relation avec l'officine Rapport du projet de fin d’études Page 44 HAMLI Marouane Malgré la variété de fonctionnalités satisfaites par ces modules, il reste à créer certains objets qui n’existent pas encore sur OpenERP, en créant un nouveau module qui les regroupera, le schéma suivant montre comment seront intégrés ces modules listés ci-dessus et comment ils seront liés avec le nouveau module que je vais créer : Point_of_sale Account_ac countant Purchase Account_vo ucher Officine Base Sale Account Stock Figure 10 : Dépendences du module officine Rapport du projet de fin d’études Page 45 HAMLI Marouane 5.2 Module « Officine » Après avoir analysé les différents modules, j’ai constaté qu’il faut créer les objets suivants : - Médecin : cet objet est nécessaire dans le cas d’une vente par ordonnance, car il faut renseigner le nom du médecin qui l’a établit Patient DCI : « Dénomination Commune Internationale », représente le nom du composant chimique d’un médicament, ici au Maroc la DCI joue un rôle secondaire pour déterminer les produits car on se base sur leur nom commercial. Ces nouveaux objets sont regroupés dans un nouveau module à ajouter, qui n’est autre que « officine ». Le module est un dossier composé de fichiers python (.py) contenants les définitions des classes et d’autres XML contenants les détails des vues de ces dernières, en plus de certains dossiers comme les wizards (assistants se lançant dans certaines conditions) ou report (contient les modèles de rapport du module). En plus j’ai eu à étendre certains objets déjà créés pour qu’ils répondent aux besoins, ces objets sont : - - - Produit : ajout des attributs propres au médicament à la classe produit, comme la posologie, la/les DCIs composant le produit (un médicament peut se composer de plusieurs DCI, mais seul une est considérée principale), ainsi que les DCIs listées comme contre indication. Ligne de vente : ajout d’un attribut « ordonnance » afin de préciser si la ligne fait partie d’une ordonnance ou non, car après discussion avec le client, il s’est avéré qu’il est possible de faire une vente sur ordonnance en plus d’autres produits non prescrits dans cette dernière, tout ceci en une seule vente. Ordre de vente : cette classe déjà créée par le module point de vente, nécessite d’avoir des liens avec un médecin et un patient, lorsqu’on souhaite réaliser une vente sur ordonnance, car il faudra dans ce cas renseigner le nom du médecin ayant établi l’ordonnance, et le patient à laquelle elle est destinée. Je lui ai ajouté aussi un champ qui calcul le montant total des produits achetés sur ordonnance. Après avoir créé et étendu les classes citées ci-dessus (voir l’annexe A qui contient des détails quant au développement de classes avec le framework « Open Object »), il fallait passer à créer les vues pour les représenter graphiquement et les utiliser, les vues sont des fichiers XML dans lesquelles on définit la structure d’affichage des nouveaux objets créés, et on peut aussi hériter des vues déjà existantes, et soit les modifier, ou y ajouter de nouveaux champs à afficher. L’avantage de coder ces nouveaux objets sous « Open Object » réside dans le fait qu’il suffit de renseigner une nouvelle classe, mentionner ses attributs, pour qu’ensuite Open Object lui crée une table dans la base de données et lui associe ses méthodes élémentaires Rapport du projet de fin d’études Page 46 HAMLI Marouane (ajout, modification, suppression), les méthodes spécifiques à une classe doivent être écrites dans cette dernière. Après la création des différentes classes nouvelles et classes filles, nous devons créer deux fichiers spéciaux pour OpenERP afin de pouvoir installer le module. Le premier fichier est « __init__.py » où on importe tous les fichiers python qu’il nous faut pour faire fonctionner le module. Le deuxième est « __openerp__.py » (anciennement appelé __terp__.py), dans ce fichier se trouve la fiche technique du module, à savoir son nom, sa description, le nom de l’auteur, les noms des modules auxquels il dépend, et les fichiers des vues XML à inclure pour pouvoir afficher nos objets créés ou étendus. 5.3 Installation Maintenant que le codage est terminé, on peut passer à l’installation du module « officine », qui installera d’abord les modules auxquels il est lié, ensuite ajoutera ses propres fonctionnalités. Avant de lancer le serveur d’OpenERP, on doit copier le dossier du module « officine » dans le dossier « Addons » d’OpenERP, ensuite on lance le serveur (fichier openerpserver.py), et nous pourrons à ce stade, installer notre nouveau module. Bien évidemment, on doit d’abord se connecter puis accéder aux paramètres. Figure 11: Connexion Rapport du projet de fin d’études Page 47 HAMLI Marouane Figure 12: Accueil OpenERP - client web Une fois connecté, on se rend aux paramètres, puis dans le menu modules, on lance une mise à jour de la liste des modules, afin qu’on puisse trouver celui qu’on vient d’ajouter parmi la liste, là on lance l’installation du module officine. Figure 13: Liste des modules OpenERP 5.4 Paramétrage Maintenant que j’ai installé mon module, je peux commencer à paramétrer le PGI et démarrer une simulation pour s’assurer de son bon fonctionnement. 5.4.1 Général Avant de se lancer dans le paramétrage de l’application, je commence par un paramétrage général, où il faut saisir le nom de l’officine, son adresse, et autres coordonnées Rapport du projet de fin d’études Page 48 HAMLI Marouane (compte bancaire…), aussi il faut changer la devise vers le Dirham, pour que les prix et les factures soient bien affichés ultérieurement, selon le contexte marocain. 5.4.2 Plan comptable Toute application fonctionnant sous OpenERP, il faut spécifier un plan comptable à utiliser pour la génération des différentes écritures comptables et journaux de comptabilité. Pour le plan comptable de ce projet, j’ai choisi le plan comptable général d’OpenERP par défaut pour enregistrer les différentes écritures comptables dans leurs journaux respectifs, en raison de sa simplicité d’utilisation. Il existe bien sûr un plan comptable marocain pour OpenERP, mais il y a eu beaucoup d’erreur lors des tests avec ce dernier, ce qui m’a poussé à revenir vers le plan par défaut. 5.4.3 Produit Les produits contiennent un bon nombre d’attributs qui facilitent le paramétrage, ainsi j’ai utilisé les attributs suivants : Attribut Name reference Ean13 Categ_id Standard_price List_price State Pos_categ_id posologie Dcis Cis Fonction Nom du produit Code du produit Code à barre du produit Catégorie du produit, utile pour le calcul de son prix public sur la base de liste de prix Prix d’achat Prix public Etat du produit Forme du produit, utile pour le classement des produits dans le point de vente, ce qui facilite leur recherche Posologie du produit Liste des DCIs du produit Liste des contre indications du produit Tableau 4 : attributs du produit 5.4.4 Méthodes de paiements : Avant de pouvoir passer au point de vente, il faut d’abord configurer les méthodes de paiements qu’on souhaite mettre à disposition, puis ensuite ouvrir les caisses, on peut ouvrir toutes les caisses à la fois, ou choisir d’ouvrir que quelques unes, dans le cas où il n’est pas possible d’effectuer un certain type de paiement, du à une panne matérielle par exemple. Pour créer les méthodes de paiements il faut se connecter en tant qu’administrateur puis se rendre au backend du point de vente, là on pourra configurer les méthodes de paiement qu’il nous faut. Une méthode de paiement est caractérisée par : (voir la page suivante) Rapport du projet de fin d’études Page 49 HAMLI Marouane Attribut Name Code Type Default_credit_account_id Default_debit_account_id View_id Fonction Nom de la méthode Code de la méthode Type sur lequelle se base la méthode : liquidité, ventes, banques et chèques… Indique le journal de crédit utilisé pour cette méthode Indique le journal de débit utilisé par défaut Indique la vue à utiliser pour afficher les entrées dans le journal Tableau 5: Attributs de la méthode de paiement Rapport du projet de fin d’études Page 50 HAMLI Marouane 5.5 Simulation Dans cette partie je présente quelques captures d’écran de l’application pour montrer les fonctionnalités qu’elle offre. Les captures ci-dessous ont été faites sur une nouvelle base de données, avec un produit exemple. Je travaille maintenant sur l’importation d’une liste de produits fournie par le client à cette base pour ensuite livrer une base de données complète, ne nécessitant ni nouveau paramétrage ni nouvelle importation de données. 5.5.1 Gestion de base La gestion de base concerne les objets élémentaires, comme les utilisateurs, les produits, les médecins… Figure 14: Gestion des utilisateurs Figure 15: Gestion des groupes Rapport du projet de fin d’études Page 51 HAMLI Marouane Figure 16: Liste des médecins Pour faciliter l’utilisation de l’application, des info-bulles s’affichent lorsqu’on survole les champs, fournissant des explications concernant la fonction du champ pour aider à bien le renseigner. Figure 17: Formulaire médecin Figure 18:Formulaire patient Rapport du projet de fin d’études Page 52 HAMLI Marouane 5.5.2 Gestion des achats Les figures suivantes montrent la gestion des achats, qui comprend l’édition et validation de bons de commande, effectuer des réceptions de produit. Figure 19: Bons de commande fournisseur En créant un bon de commande, on sélectionne un fournisseur auquel il est adressé, ensuite on ajoute les produits qu’on souhaite commander auprès de lui, on peut aussi choisir la méthode de facturation si elle doit être basée sur le bon de commande ou sur les réceptions des produits. Les réceptions peuvent se faire sur bons de commande, ou tout simplement sans origine. Si une réception est basée sur un bon de commande validé, et qu’elle contient une quantité inférieure à celle demandée, la réception est dupliquée, avec comme origine le même bon de commande, mais cette fois elle contient la différence entre la quantité demandée et celle reçue. Rapport du projet de fin d’études Page 53 HAMLI Marouane Figure 20: Liste des réceptions 5.5.3 Gestion des ventes Dans ce volet nous pouvons consulter la liste des clients, voir les détails de chaque client et autres actions en relation. Figure 21: Formulaire client Comme le montre la figure ci-dessus, nous pouvons voir, en plus des informations de base du client, la situation du crédit de ce client, comme il nous est possible d’afficher ses factures, bons de commandes ou chiffre d’affaire mensuel. Rapport du projet de fin d’études Page 54 HAMLI Marouane 5.5.4 Gestion du stock Dans cette partie on trouve tout ce qui concerne la gestion des produits, les inventaires physiques par exemple : Figure 22: Gestion des inventaires physiques On peut aussi voir le mouvement de stocks en cliquant sur le menu « mouvements de stocks » : Figure 23: Liste des mouvements de stock On peut aussi définir les règles de stock minimum des produits, à condition qu’on ait spécifié le fournisseur dans la fiche du produit, pour qu’ensuite dès qu’un produit franchit la limite définie, un bon de commande est automatiquement créé et est envoyé au fournisseur quand le planificateur est lancé. Rapport du projet de fin d’études Page 55 HAMLI Marouane Figure 24: Liste des règles de stock minimum Le formulaire du produit, après extension, devient comme le montre la figure suivante Figure 25: Formulaire produit – I Rapport du projet de fin d’études Page 56 HAMLI Marouane Figure 26: Formulaire produit - II Quand la quantité d’un produit descend en dessous de celle définie dans les règles de stock minimum (par défaut 0), le produit s’affiche en rouge dans la liste des produits, voir la figure ci-dessous. Figure 27: Produit en stock d'alerte Il nous est possible de faire une analyse des mouvements de stocks, on peut aussi personnaliser cette analyse, en y ajoutant quelques filtres et groupements. Figure 28: Analyse des mouvements de stocks Rapport du projet de fin d’études Page 57 HAMLI Marouane 5.5.5 Comptabilité Ce module concerne tout ce qui est facture, paiements et écritures dans les journaux. Figure 29: Liste des factures clients A travers ce module nous pouvons suivre de près les règlements de factures des clients, voir les factures qui n’ont pas encore été validés, comptabiliser les factures payées… Figure 30: Détails facture client Ces factures client sont utiles lorsqu’on effectue une vente par crédit, car la facture reste ouverte tant qu’elle n’est pas payée, son montant s’ajoute au crédit du client concerné, et ne sera comptabilisée qu’après son paiement. Rapport du projet de fin d’études Page 58 HAMLI Marouane Figure 31: Paiements clients OpenERP considère les clients et fournisseurs comme étant une seule entité : partenaire, avec un attribut qui désigne si ce dernier est client ou fournisseur, donc les factures et paiements pour les fournisseurs ont la même présentation que celle des clients. Autres fonctionnalités possibles dans ce module, c’est la gestion des méthodes de paiements, différents journaux de comptabilités, on peut même changer de plan comptable et utiliser un autre. Ce volet de comptabilités offre aussi la possibilité de générer des rapports et des analyses des écritures comptables, journaux et factures, comme le grand livre ou le bilan, il offre aussi une analyse générale de la société, donnant ainsi des idées plus claires sur la situation financière de l’officine. Rapport du projet de fin d’études Page 59 HAMLI Marouane 5.5.6 Point de vente La version 6.1 d’OpenERP a apporté de grands changements pour le module du point de vente, résultant en une meilleure ergonomie et une grande interactivité et support des différents outils communs dans les petits commerces. Figure 32: Point de vente Cette nouvelle interface, complètement écrite en javascript, offre plusieurs façons de rechercher un produit : à partir du nom, code, ou code à barre, la recherche avec code à barre est plus pratique en utilisant la douchette qui lit ce dernier directement sur le médicament. Elle permet d’effectuer plusieurs types de paiements à la fois, comme payer la moitié d’un ticket en espèces, l’autre moitié avec une carte de crédit… Figure 33: Paiement en espèces Rapport du projet de fin d’études Page 60 HAMLI Marouane Le lancement du point de vente vérifie s’il existe des méthodes de paiement enregistrées, ensuite il vérifie s’il y a des caisses basées sur ces méthodes qui sont ouvertes, le cas échéant un assistant demande si on souhaite ouvrir les caisses, si on confirme, de nouvelles caisses sont créées, et nous pouvons nous lancer dans la vente. Figure 34: Assistant d'ouverture des caisses Si aucune méthode de paiement n’est enregistrée, on ne pourra pas effectuer de ventes, nous aurons donc à retourner au backend pour créer les méthodes qui nous conviennent. Figure 35: Liste des méthodes de paiement Figure 36: Formulaire de création/modification d'une méthode de paiement Rapport du projet de fin d’études Page 61 HAMLI Marouane Une fois nos méthodes définies, nous pouvons ouvrir les caisses automatiquement à l’aide de l’assistant, nous aurons dans ce cas de nouvelles caisses vides, chacune correspondante à une méthode de paiement déjà enregistrée, sinon nous pouvons les créer manuellement et les ouvrir ensuite. Figure 37: Liste des caisses Une des fonctionnalités ajoutées à ce module est l’ordonnancier, où on effectue des ventes sur ordonnance, pour y accéder, il faut aller dans le backend du point de vente, puis créer une nouvelle vente. Figure 38: Journal des ventes Figure 39: Ordre de vente Rapport du projet de fin d’études Page 62 HAMLI Marouane L’onglet « ordonnance » ajouté, permet de renseigner le nom du médecin ayant rédigé l’ordonnance, ainsi que le patient à qui elle est destinée. Les lignes de vente peuvent correspondre à l’ordonnance elle-même, ou seulement des lignes de vente « libre ». Ce qui explique l’ajout d’une case à cocher si la ligne correspond à une ordonnance ou non, et l’ajout du champ « total ordonnance » qui calcule le total des lignes d’ordonnance. Figure 40: Renseignement des informations d'ordonnance Les produits dans le point de vente sont classés par catégorie, ce qui facilite leur recherche. Une catégorie du point de vente peut avoir une catégorie mère, on obtient donc une hiérarchie de catégorie. Figure 41: Catégories des produits - point de vente Le module « point de vente » offre aussi des statistiques et des analyses concernant ses ventes. Rapport du projet de fin d’études Page 63 HAMLI Marouane Figure 42: Analyse du point de vente par produit Il est aussi possible de voir ces analyses par utilisateur : Figure 43: Analyse des enregistreuses par utilisateur 5.6 Problèmes rencontrés Lors de la simulation, quelques bugs ont été rencontrés, comme par exemple la recherche multi critère des médicaments dans le point de vente où seule la recherche par nom était possible. Après plusieurs lectures et relectures du code, et après plusieurs recherches sur internet, notamment sur le launchpad, site où la communauté des chercheurs et développeurs d’OpenERP signalent les différents problèmes des versions publiées, j’ai pu trouver des correctifs à appliquer au module pour profiter de ces fonctionnalités. Le problème a été du au fait que le module a été complètement rénové, et que sa date de publication était très récente (février 2012). Rapport du projet de fin d’études Page 64 HAMLI Marouane Conclusion Ce stage de fin d’études a été, encore une fois, une occasion pour moi pour côtoyer le monde de l’entreprise, mais avec plus de responsabilités cette fois-ci. Coté technique, le travail réalisé jusqu’ici permet une gestion interne d’une officine, et peut être étendu en développant le concept d’ « échanges » entre confrères pharmaciens, ou encore en intégrant OpenERP chez les grossistes, fournisseurs de produits aux pharmaciens, et lier ces deux solutions pour automatiser les commandes de médicaments par exemple. Le module développé pourra maintenant subir des tests plus importants que ceux réalisés par moi-même pendant son développement, c'est-à-dire passer à une phase béta, où une liste de produits contenant toutes les informations nécessaires des médicaments sera importée, ensuite il sera installé dans une officine, et sera utilisé en parallèle avec le logiciel de gestion existant déjà, pour juger de son efficacité et de sa facilité d’utilisation. Coté personnel, travailler dans le monde de l’open source, et plus précisément sur un PGI tel que OpenERP m’a permis d’apprendre plus sur ces domaines, notamment le langage python et l’utilisation du framework « OpenObject », et de rejoindre une communauté mondiale de plus de 1500 individus impliqués eux aussi dans la recherche et le développement de nouveaux modules, afin de faciliter l’intégration d’une telle solution dans tous les domaines professionnels et sociaux. A travers ce projet, j’ai pu voir l’importance des logiciels libres pour les PME marocaines, surtout leur capabilité à satisfaire un bon nombre de besoins fonctionnels, tout ceci à faibles coûts, ce qui permet leur croissance dans leur marché et garantir leur durabilité face à la concurrence. Rapport du projet de fin d’études Page 65 HAMLI Marouane Bibliographie & webographie Bibliographie - Rapport du projet de fin d’études de MOUNIR Majid, ENSA de Tanger OpenERP, pour une gestion d’entreprise efficace et intégrée (Eyrolles) Open Object Developer Book (Tiny SPRL) OpenERP : a modern approach to integrated business management based on a free Open Source software system (Geoffrey S. Gardiner and Fabien Pinckaers) Programmation python (édition 2), (Eyrolles) Webographie - - http://www.theopensourcerer.com/2012/02/22/how-to-install-openerp-6-1-onubuntu-10-04-lts http://www.easyopenerp.com/principales-nouveautes-de-la-version-6-1/ http://www.ibcscorp.com/application-integration-customization/erp/openerp2/openerp-custom-module-development-quick-start-guide/ http://planet.domsense.com/docs/openerp-web/en/addons.html https://code.launchpad.net/~guerrerocarlos/openobjectaddons/point_of_sale_6.1_barcode__merge/+merge/99129 (fix pr recherche ac code à barre) http://mohsinpage.wordpress.com http://www.docstoc.com/docs/21264701/OpenERP-User-Manual http://blip.tv/openerp-support Rapport du projet de fin d’études Page 66 HAMLI Marouane Annexe A Introduction au développement de modules OpenERP avec le framework « Open Object » Rapport du projet de fin d’études Page 67 HAMLI Marouane INTRODUCTION AUX OBJETS Toutes les données d'OpenERP sont accessibles par les objets: c’est à dire pour la création d'un module, on ne manipule pas les données directement car les objets sont eux qui créent les tables de base de données contenant les données d'OpenERP via « ORM » (Object Relational Mapping). Par exemple: il existe dans le module de base d'OpenERP, l'objet res.partner qui permet d'accéder aux informations concernant les partenaires. Aussi il y'a dans le module de base account, l'objet d'OpenERP account.invoice pour accéder aux données relatives à la facture. Tous ces objets se trouvent dans des fichiers d'extension .py. On signale qu'il y'a un objet pour chaque type de ressource et non un objet pour une ressource, ainsi un il y'a un unique objet res.partner pour manipuler tous les partenaires (dans ce cas les ressources) et on ne peut pas avoir l'objet res.partner pour chaque partenaire: parlons aux termes d'orienté objet pour bien assimiler cette notion, on peut dire que l'objet d'OpenERP est considéré comme la classe et les ressources sont les instances de cette classe c’est à dire les objets. Et si on parle du coté de la base de données les objets d'OpenERP sont les tables de la BD et les lignes des tables sont les ressources. Donc une table (un objet d'OpenERP) comprend plusieurs lignes (Ressources d'openErp). Une conséquence directe de cette notion objet-ressources est que toutes les méthodes des objets ont un paramètre commun : le paramètre ids. Il spécifie sur quelles ressources la méthode s'appliquera: précisément ce paramètre contient une liste des identificateurs des ressources (ids) sur laquelle la méthode s'appliquera. Par exemple, si on a deux ressources partenaires avec les identificateurs 1et 2 (les identificateurs de ressources sont les id des lignes de la table qui correspond à l'objet qui manipule ces ressources) et aussi nous voulons appeler la méthode d'objet res.partner qui est send_email, nous procédons comme suit: res_partner.send_email(..., [1, 2], ...) Ultérieurement dans ce support, nous verrons comment appeler les méthodes d'objets et les quelques méthodes propres d'OpenERP. Un rappel important pour les programmeurs : - Les objets d'OpenERP sont appelés classes si on parle au terme de la programmation orientée objet Et une ressource est appelée objet, l'instance de la classe. Definition des objets en OpenERP Pour définir un nouvel objet, on définit une nouvelle classe et après on l'instancie, cette classe doit hériter de la clase OSV du module OSV d'OpenERP. Rapport du projet de fin d’études Page 68 HAMLI Marouane Ainsi, la première ligne de la définition de l'objet sera toujours comme suivant: class nom_objet(osv.osv): _name = 'nom de l'objet' _columns = {...} ... nom_objet() Donc, l'objet se définit en déclarant quelques attributs avec des noms prédéfinis dans la classe, deux de ces attributs sont obligatoires à savoir _columns et _name, les autres sont optionnels. Les attributs prédéfinis sont: - - _auto: Prend True /False et détermine si la table correspondante dans postgres doit se générer automatiquement à partir de cet objet. Mettre _auto=False pourra être utile dans les cas ou on veut créer objets basés sur des vues de postgresql sans créer des tables. _columns(obligatoire): on y définit les champs(les attributs de la classe si on parle au terme d'orienté objet) de l'objet _constraints: on y détermine des restrictions sur l'objet (on en parlera ultérieurement) _defaults: on définit les valeurs par défaut pour quelques champs de l'objet. _inherit: on met l'objet père que l'actuel objet hérite. On va le détailler dans deux types: o ORM - Object Declaration - _inherit (1) : Réalise un héritage d'un objet existant, mais crée un nouvel objet, exemple : class formateur(osv.osv): _name = 'formateur' _inherit = 'res.partner' _columns = { 'lang_ids' : fields.many2many('res.lang', 'res_lang_partner_rel', 'partner_id', 'lang_id', 'Languages')} formateur() o ORM - Object Declaration - _inherit (2) : Réalise un héritage d'un objet existant, ajoute des caractéristiques à l'objet dont nous héritons, exemple : class res_partner_add_langs(osv.osv): _name = 'res.partner' _inherit = 'res.partner' Rapport du projet de fin d’études Page 69 HAMLI Marouane _columns = { 'lang_ids' : fields.many2many('res.lang','res_lang_partner_rel', 'partner_id', 'lang_id', 'Languages')} res_partner_add_langs() - _name(obligatoire): le nom de l'objet, la valeur par défaut est None _order: on met le nom du champ de l'objet actuel qui sera comme critère de tri des résultats des méthodes search et read. Sa valeur par défaut est 'id' _sql: on met le code sql pour l'exécuter dans la création de l'objet (seulement si _auto=True) _table: nom de la table sql correspondante a cet objet, sa valeur par défaut est celle de _name en remplaçant les points (.) par des tirets (_) Les champs des objets Les objets peuvent contenir différents types de champs. Ces types s'articulent dans trois catégories: types simples, types relationnelles et champs fonctionnels. Les types simples englobent les entiers, les réels, les booléens et les chaines de caractère…, les champs de type relationnel permettent de représenter les relations entre les objets (one2one, many2one, many2many). Les champs fonctionnels sont des champs spéciaux parce qu'ils ne sont pas enregistrés dans la base de données mais plutôt sont calculables à partir d'autres champs dans le temps réel. La signature de la méthode d'initialisation de la classe dont hérite tout champ déclaré dans OpenERP( ..... /osv/fields.py). def init (self, string='unknown', required=False, readonly=False, domain=[], context="", states={}, priority=0, change_default=False, size=None, ondelete="set null", translate=False, select=False, **args) : Ainsi les paramètres optionnels communs pour tous les types de champs sont comme suit: - - - change_default: (True/False) quand ce champ prend la valeur booléenne True, le programme permet à l'utilisateur d'établir des valeurs par défaut dans autres champs qui dépendent de la valeur de ce champ. Sa valeur par défaut est: False. Exemple:(dans res.partner.adress) 'zip': fields.char('Zip', change_default=True, size=24), dans ce cas, les utilisateurs peuvent mettre des valeurs par défaut dans les champs de la vue qu dépendent du champs 'Zip'(code postale). Par exemple, l'utilisateur peut programmer que le programme remplit automatiquement le champ 'city' à Barcelone si le code postale prend la valeur '08000'. help: montre un message d'aide lorsque la souris est au-dessus de ce champ. Exemple: 'name': fields.char('name', help='le nom s'affiche.'), Rapport du projet de fin d’études Page 70 HAMLI Marouane - - - Readonly:(True/False) détermine si le champ sera éditable ou non. Valeur par défaut=False required: (True/False) détermine si le champ est obligatoire ou non, signalons que OpenERP refuse d'enregistrer une ressource si un champ obligatoire est vide. Donc il est obligatoire de remplir tous les champs obligatoires avant d'enregistrer une ressource. Valeur par défaut=False states: ce paramètre permet de définir des autres attributs pour ce champs qui seront disponibles selon des états déterminés de la ressource. Format: states= {'état de la ressource': [liste des attributs]} Avec liste des attributs est une liste de tuples de la forme: [('nom de l'attribut', valeur), ...]. Valeur par défaut ={} Exemple: (dans account.transfer) 'partner_id': fields.many2one('res.partner', 'Partner', states={'posted [('readonly',True)]}), Dans cet exemple, lorsque l'état de la ressource est 'posted', l’attribut ‘partner_id’ sera en lecture seule. String: c'est l’étiquette du champ. Valeur par defaut=unknown translate: (True/False) détermine si ce champ doit être traduit.(géré par le système de traduction). Valeur par défaut=False Finalement, voici les paramètres optionnels spécifiques pour quelques types de champs : - - - domain: sert a restreindre le domaine des ressources, ce paramètre est valide seulement pour les champs de type relationnel. Valeur par défaut=[] Exemple: domain=[('nom','=',valeur)]) invisible: (True/False) pour cacher la valeur du champ dans les formulaires (mots de passes…). Valeur par défaut=False selection: sert à sélectionner le niveau de recherche par défaut dans les vues.si ce paramètre prend la valeur '1', ceci signifie que le champs toujours apparaît dans le filtre de recherche dans la vue qui manifeste ce champs. Et s'il prend '2', le champ apparaît seulement dans la recherche avancée qui se manifeste lorsqu'on clique sur le symbole + on_change: lance une fonction (définit sur l'objet ORM qui contient ce champ) quand la valeur de ce champ change dans une vue. Exemple: on_change = "onchange_shop_id(shop_id)” Types de champs : - Champs simples: boolean: le champ boolean prend deux valeurs (True/False) Syntaxe: fields.boolean('Nom du champs' [, Parametres optionnels]), integer : si la valeur voulue est un entier. Syntaxe: fields.integer('Nom du champs' [, Parametres optionnels]) Float : si la valeur voulue est un nombre flottant (réel). Rapport du projet de fin d’études Page 71 HAMLI Marouane Syntaxe: fields.float('Nom du champs' [, Parametres optionnels]), Note: il y'a un paramètre spécifique digit pour le champ de type float, ce paramètre précise le nombre de chiffres après la virgule et précise le nombre des chiffres significatif c’est à dire le nombre de chiffres après et avant la virgule. Exemple: 'rate' : fields.float('le taux', digits=(12,6) [, Parametres optionnels]) - - char: Une chaine de caractères de longueur limitée. Le paramètre obligatoire size détermine sa longueur Syntaxe : fields.char('Nom du champs', size=n [, Parametres optionnels]), ou n est un entier. text: un texte de longueur illimitée Syntaxe : fields.text('Nom du champs' [, Parametres optionnels]), Date : ce champs détermine la date . Syntaxe : fields.date('Nom du champs' [paramétres optionnels, ]), datetime : Permet l'édition de la date et l'heure dans le même champ. Syntaxe : fields.datetime('Nom du champs' [paramétres optionnels, ]), Binary: pour l'image, Exemple : 'image': fields.binary('Image') selection: ce champ permet à l'utilisateur de sélectionner plusieurs valeurs prédéfinis. Syntaxe:fields.selection([('n','non confirmé'), ('c','Confirmé')], 'Nom du champs' [, paramètres optionnels]), Remarque: le format du paramètre de sélection est une liste de tuples:[('clé', 'chaine de caractère à montrer'), ...] ou la clé s'enregistre dans la ligne de la table (correspondante à l'objet qui contient le champ) comme une valeur prédéfinie. Champs fonctionnels: Le champ fonctionnel est un champ dont la valeur est calculée par une fonction (au lien de s'enregistrer dans la base de données). Dans les cas spéciales (pour faciliter la recherche ou la consultation) les champs de type fonctionnel peuvent être sauvegardés dans la base de données avec le paramètre STORE (il va prendre la valeur booléenne True). Ils sont actualisés par les fonctions et non par les utilisateurs. Paramétres: fnct, arg=None, fnct_inv=None, fnct_inv_arg=None, type="float, fnct_search=None, obj=None, method=False, - fcnt_inv: Fonction inverse pour écrire fcnt_search: Fonction permettant de réaliser une recherche sur le champ method: Si True, il s'agit d'une méhode d'instance d'openErp, sinon, fonction type: Indique le type d'élément (char, integer, float, boolean, date, datetime) store: Si True, stocke dans la base de données la valeur du champ(par défaut False) Rapport du projet de fin d’études Page 72 HAMLI Marouane fnct: c'est la fonction qui calcule la valeur du champs avec une méthode d'openErp ou une fonction globale,Si method=True,la signature de méthode sera comme suit: def fnct(self, cr, uid, ids, field_name, arg, context) Exemple: _columns = { 'avg': fields.function(_get_average_value, fcnt_inv=_something_write, fcnt_search = _something_search, method=True, string="Fields", type="float", store=True) } CHAMPS relationnels ORM - Champs - Relationnel - one2many, exemple : Un instructeur donne plusieurs formations class openacademy_instructor(osv.osv): _name = 'openacademy.instructor' _columns = { 'training_ids' : fields.one2many('openacademy.training', 'instructor_id', 'Trainings') } ORM - Champs - Relationnel - many2one, exemple : plusieurs formations sont données par un instructeur _columns = { 'instructor_id' : fields.many2one('openacademy.instructor', 'Instructor') } ORM - Champs - Relationnel - many2one & one2many Comment retenir la différence ? - Champ many2one: plusieurs (many) de ces objets sont possèdés par un (one) objet parent Champ one2many: l'objet (one) possède plusieurs (many) enfants Rapport du projet de fin d’études Page 73 HAMLI Marouane ORM - Champs - Relationnel - many2many, exemple : _columns = { 'participant_ids' : fields.many2many('openacademy.participant', 'openacademy_training_participant_rel', 'training_id', 'participant_id', 'Participants') } - Un participant peut suivre plusieurs formations Une formation est donnée à plusieurs participants ORM – Méthodes spéciales – Méthodes prédéfinies Méthodes prédéfinies : - create: Création d'un enregistrement write: Mise à jour d'un enregistrement unlink: Suppression d'un enregistrement read: Lecture de champs d'un enregistrement copy : Duplication d'un enregistrement search: Recherche d'enregistrement browse: Récupération d'enregistrement via critères de recherche name_get: Retourne uniquement que le nom et l'identifiant du record name_search: Réalise une recherche du nom sur base d'un domaine init : Permet de créer une vue si _auto = False _auto_init : Permet de créer un index ou un objet SQL si nécessaire Rapport du projet de fin d’études Page 74 HAMLI Marouane