ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE

on

  • 14,479 views

ADAPTATION

ADAPTATION
ET INTEGRATION D’OPENERP POUR
LA GESTION D’OFFICINE

Statistics

Views

Total Views
14,479
Views on SlideShare
14,468
Embed Views
11

Actions

Likes
4
Downloads
1,678
Comments
1

4 Embeds 11

http://www.linkedin.com 6
https://twitter.com 3
http://twitter.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • comment faire pour lire les diapositives en mode plein écran?
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE Document Transcript

  • 1. N° d’Ordre :ECOLE NATIONALE DES SCIENCES UNIVERSITE ABDELMALEKAPPLIQUEES - TANGER ESSAÂDI 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
  • 2. 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. Page 2Rapport du projet de fin d’études HAMLI Marouane
  • 3. 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. Page 3Rapport du projet de fin d’études HAMLI Marouane
  • 4. 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 lentreprise: gestion de production, gestion commerciale, logistique, ressources humaines, comptabilité, contrôle de gestion. A laide 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 dassurer lintégrité des données, la non-redondance de linformation, 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. Page 4Rapport du projet de fin d’études HAMLI Marouane
  • 5. 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 : info@nextma.com 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. Page 5Rapport du projet de fin d’études HAMLI Marouane
  • 6. 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 Page 6Rapport du projet de fin d’études HAMLI Marouane
  • 7. 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 dUbuntu 11.10 .......................................................................................... 34 Figure 7 : Logo PostgreSQL .................................................................................................... 35 Figure 8 : Interface Web dOpenERP ....................................................................................... 36 Figure 9: Architecture dOpenERP ........................................................................................... 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 dalerte .......................................................................................... 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 douverture des caisses ............................................................................ 61 Figure 35: Liste des méthodes de paiement ............................................................................. 61 Figure 36: Formulaire de création/modification dune 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 dordonnance...................................................... 63 Page 7Rapport du projet de fin d’études HAMLI Marouane
  • 8. 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 dutilisations - 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 lofficine .............................. 44 Tableau 4 : attributs du produit ................................................................................................ 49 Tableau 5: Attributs de la méthode de paiement ...................................................................... 50 Page 8Rapport du projet de fin d’études HAMLI Marouane
  • 9. 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 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 2 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 Diagramme des cas d’utilisations :..................................................................... 26 1. Gestion basique : .................................................................................................... 26 3.2.2 Diagramme des classes : .................................................................................... 31 4 Chapitre IV : Technologies mises en œuvre .................................................................... 34 4.1 Ubuntu ....................................................................................................................... 34 4.2 PostgreSQL ................................................................................................................ 35 Page 9Rapport du projet de fin d’études HAMLI Marouane
  • 10. 4.3 OpenERP ................................................................................................................... 36 4.4 Python ........................................................................................................................ 40 4.5 XML .......................................................................................................................... 42 5 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 Page 10Rapport du projet de fin d’études HAMLI Marouane
  • 11. 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. Page 11Rapport du projet de fin d’études HAMLI Marouane
  • 12. Partie I : Contexte général du projet Chapitres : - Présentation de l’organisme d’accueil - Cadre général du projet Page 12Rapport du projet de fin d’études HAMLI Marouane
  • 13. 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 lintégration, le développement, ladaptation aux besoins spécifiques, la maintenance et le support. Afin de bénéficier des meilleures solutions libres dans la gestion des systèmes dinformation. 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. Page 13Rapport du projet de fin d’études HAMLI Marouane
  • 14. 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 daccompagner les clients durant toutes les phases dun projet afin den assurer sa réussite en : Formation : L’offre des formations, techniques et fonctionnelles, permet daccompagner 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 dapplications 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) : Nextma propose l’offre SUGARCRM qui permet la gestion de la relation client. 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 sappuie sur le système de gestion du contenu « Joomla ». Page 14Rapport du projet de fin d’études HAMLI Marouane
  • 15. Gestion électronique des documents : Il s’agit d’un système informatisé dacquisition, 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 Page 15Rapport du projet de fin d’études HAMLI Marouane
  • 16. 2 Chapitre II : Cadre général du projet 2.1 Présentation générale de l’officine La pharmacie dofficine est la branche la plus connue de la pharmacie. Cest 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 dofficine est la délivrance des ordonnances prescrites par les médecins, les conseils associés à la prise des médicaments, à lhygiène, à la nutrition ou, plus globalement, à la santé publique. Le travail du pharmacien dofficine est aussi lanalyse de lordonnance, 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 derreur ou négligence de la part du médecin prescripteur. À ce titre, il peut refuser de délivrer lordonnance, 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 dun plan pharmacothérapique. Le pharmacien dofficine a aussi un rôle social, il est en mesure dindiquer aux personnes en difficulté les organismes ou les structures compétentes en matière de Santé Publique et daides 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 Page 16Rapport du projet de fin d’études HAMLI Marouane
  • 17. 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 quun "simple" paramétrage suffit à les adapter à lorganisation de lentreprise. Il nest normalement pas nécessaire deffectuer des développements spécifiques, sauf en cas de nécessité, lorsque ce Page 17Rapport du projet de fin d’études HAMLI Marouane
  • 18. 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 Page 18Rapport du projet de fin d’études HAMLI Marouane
  • 19. 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) Page 19Rapport du projet de fin d’études HAMLI Marouane
  • 20. Description Points forts Points faibles Rational -Méthodologie centrée -Itératif -Coûteux à personnaliser Unified Process sur l’architecture et -Spécifie le dialogue -Très axé processus, au (RUP) couplée aux entre les différents détriment du diagrammes UML intervenants du projet : développement -Concerne des projets les livrables, plannings -Lourd, largement étendu, il de +10 personnes et prototypes… peut être difficile à mettre -Processus complet -Propose des modèles en œuvre de façon assisté par des outils de documents, et des spécifique exhaustifs canevas pour des -Convient pour les grands projets types projets qui générent -Rôles bien définis, beaucoup de documentation modélisation eXtreme -Développement guidé -Itératif -Ne couvre pas les phases Programming par les besoins du client -Simple à mettre en en amont et en aval du (XP) -Equipes réduites, œuvre développement centrées sur les -Laisse une large place -Assez flou dans sa mise en développeurs aux aspects techniques œuvre : quels intervenants ? -Builds journaliers Quels livrables ? -Amélioration -Focalisé sur l’aspect constante adaptation individuel du aux modifications développement, au détriment d’une vue globale et des pratiques de management ou de formalisation. Two Track -Articulé autour de -Itératif, laisse une -Superficiel sur les phases Unified Process l’architecture large partie à la en amont et en aval du (2TUP) -Cycle de technologie et à la développement développement en Y gestion du risque -Aucune proposition de -Convient aux projets de -Définit les profils des document type toutes tailles intervenants, les livrables, les prototypes 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. Page 20Rapport du projet de fin d’études HAMLI Marouane
  • 21. 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 Page 21Rapport du projet de fin d’études HAMLI Marouane
  • 22. 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 Page 22Rapport du projet de fin d’études HAMLI Marouane
  • 23. 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. Page 23Rapport du projet de fin d’études HAMLI Marouane
  • 24. Partie II : Etude fonctionnelle et technique Chapitres : - Analyse et conception du projet - Technologies mises en œuvre - Développement du module « officine » Page 24Rapport du projet de fin d’études HAMLI Marouane
  • 25. 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 Fonctionnalités Gestion de base - Gestion des médicaments - Gestion des clients - Gestion des fournisseurs - Gestion des patients - Gestion des médecins - Gérer les DCIs Vente au comptoir - 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 Gestion des achats - 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 Gestion des ventes - Consulter la liste des clients - Gestion des avoirs clients - Suivi des règlements clients - Consulter le journal des ventes - Edition des devis Gestion de stock - 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 Statistiques - 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 Page 25Rapport du projet de fin d’études HAMLI Marouane
  • 26. 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 dUML est quil 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é. Page 26Rapport du projet de fin d’études HAMLI Marouane
  • 27. 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 ci- dessus, 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 ». Page 27Rapport du projet de fin d’études HAMLI Marouane
  • 28. 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. Page 28Rapport du projet de fin d’études HAMLI Marouane
  • 29. 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. Page 29Rapport du projet de fin d’études HAMLI Marouane
  • 30. 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 : Page 30Rapport du projet de fin d’études HAMLI Marouane
  • 31. Diagramme 6: Cas dutilisations - 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. Page 31Rapport du projet de fin d’études HAMLI Marouane
  • 32. 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 contre- indications 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. Page 32Rapport du projet de fin d’études HAMLI Marouane
  • 33. 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. Page 33Rapport du projet de fin d’études HAMLI Marouane
  • 34. 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 dune nouvelle version (appelée « mise à niveau ») tous les six mois. Avec une utilisation globale estimée à plus de 25 millions dutilisateurs, il est principalement conçu pour une utilisation sur des ordinateurs personnels (portables et fixes), bien que dautres 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 à linterface Unity, il ny avait plus de raison de maintenir deux branches distinctes. Figure 6: Interface dUbuntu 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 dUbuntu. Son développement sest échelonné sur six mois, jusquà sa publication en tant que version stable le 13 octobre 2011. Page 34Rapport du projet de fin d’études HAMLI Marouane
  • 35. Elle profitera des mises à jour de sécurité pendant une durée de 18 mois, soit jusquen avril 2013. 4.2 PostgreSQL PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO). Cest un outil libre disponible selon les termes dune licence de type BSD. Ce système est concurrent dautres systèmes de gestion de base de données, quils 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 nest pas contrôlé par une seule entreprise, mais est fondé sur une communauté mondiale de développeurs et dentreprises. PostgreSQL peut stocker plus de types de données que les types traditionnels entier, caractères, etc. Lutilisateur peut créer des types, des fonctions, utiliser lhé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 dexploitation. 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 dUnix. 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 dexploitation. 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é à dautres modules externes compilés dans dautres langages. Page 35Rapport du projet de fin d’études HAMLI Marouane
  • 36. 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 dentrepô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 openerp- client qui sinstalle sur le poste de lutilisateur et le serveur web openerp-web qui permet une utilisation depuis un navigateur. Ces trois composants communiquent par les protocoles xml- rpc et net-rpc. Figure 8 : Interface Web dOpenERP 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 dOpenOffice.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 Page 36Rapport du projet de fin d’études HAMLI Marouane
  • 37. 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 CRM ; gestion de la relation client o Comptabilité analytique et financière (Conforme aux exigences françaises) o Gestion des stocks o Gestion de production (GPAO) o Gestion de projets et des activités de services o Norme qualité : ISO 9001 version 2000 o Gestion des ventes o Gestion des achats o Marketing o Logistique o Ressources humaines o 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 dapplications (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 à lutilisateur de se connecter à OpenERP avec nimporte quel navigateur internet (avec le lecteur Flash installé pour laffichage des graphiques). Ce serveur nest pas nécessaire si lutilisateur utilise le client lourd mais qui nécessitera une installation physique sur le poste de lutilisateur (cette application se nomme Client GTK). Page 37Rapport du projet de fin d’études HAMLI Marouane
  • 38. Figure 9: Architecture dOpenERP 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 dentreprise (lensemble est embarqué dans le serveur dapplication). Ainsi, lajout 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 linterface. Par exemple le client-web peut avoir un lien de personnalisation sur chaque formulaire, mais le client GTK+ na 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 laccès aux données dun 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 linterface Web riche en javascript permet en outre dintégrer nimporte quelle partie de linterface dOpenERP à site Web tiers. Page 38Rapport du projet de fin d’études HAMLI Marouane
  • 39. - Fonctions déchanges EDI : Des fonctions dÉchange de données informatisé font leur apparition, permettant à un partenaire dimporter des données (par exemple une facture) le concernant dans son propre système OpenERP ou progiciel tiers (au format JSON), et même deffectuer le paiement en ligne. - Une interface mobile : Une nouvelle interface conçue pour lutilisation sur les terminaux mobiles de type smartphone fait son apparition. Basée sur le framework JQuery Mobile, elle ne permet pour linstant 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 dOpenERP. Cette fonctionnalité très demandée permet dutliser 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 dOpenERP 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 lutilisabilité : Linstallateur et lassistant 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 dinstallation 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 à lemploi. o Importation des données facilitée : Limportation 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 dimportation 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 lenvoi 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. Page 39Rapport du projet de fin d’études HAMLI Marouane
  • 40. o Refonte du module de paie : Le module de gestion de paie a été repensé, afin dêtre plus flexible et sadapter ainsi plus aisément aux spécificités de chaque pays et de chaque entreprise. o Ré-écriture de linterface Web : Linterface Web dOpenERP a été entièrement ré-écrite et fait dorénavant la part belle à la technologie Javascript, sans non plus bouleverser son apparence et lexpérience utilisateur. Parmi les conséquences, on peut noter quelle offre plus de fonctionnalités avec moins de code, et est plus rapide que lancienne implémentation de la 6.0. Au niveau des améliorations se trouve aussi la possibilité de personnaliser les tableaux de bord directement depuis linterface avec de simples glisser-déposer, ainsi que larrivée dune 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 dapplication python tels que Gunicorn et uWSGI facilitant une implémentation extrêmement robuste dOpenERP sur les serveurs, un bien meilleur contrôle de lassignation 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 dapplications 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é dun typage dynamique fort, dune gestion automatique de la mémoire par ramasse-miettes et dun système de gestion dexceptions ; 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 : Page 40Rapport du projet de fin d’études HAMLI Marouane
  • 41. 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. Page 41Rapport du projet de fin d’études HAMLI Marouane
  • 42. 4.5 XML XML (eXtensible Markup Language) est en quelque sorte un langage HTML amélioré permettant de définir de nouvelles balises. Il sagit effectivement dun 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 dautres langages, cest-à-dire définir de nouvelles balises permettant de décrire la présentation dun texte (Qui na jamais désiré une balise qui nexistait pas ?). La force de XML réside dans sa capacité à pouvoir décrire nimporte quel domaine de données grâce à son extensibilité. Il va permettre de structurer, poser le vocabulaire et la syntaxe des données quil 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 dafficher 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 lon 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 sagit donc dune 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. Page 42Rapport du projet de fin d’études HAMLI Marouane
  • 43. 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 Nom Description Fonctionnalités technique Gestion de base Ce module est en fait le noyau Gestion des : base 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 Gestion de stock Ce module sert de base pour la - Gestion dentrepôt Stock gestion de/des entrepôt(s) d’une - Les bons de livraison entreprise dans OpenERP - Traçabilité - Produits - Règles du Stock - Reporting Gestion des sale Permet la gestion des ventes et - Gestion et suivi des ventes 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. Page 43Rapport du projet de fin d’études HAMLI Marouane
  • 44. - Gestion des incoterms. Gestion des purchase Ce module concerne tout ce qui est - Demande de devis achats en relation avec l’achat de - Les commandes dachat produits - Carnet dadresses - Contrôle des stocks - Contrôle de facture Comptabilité account Ce module concerne la - Ecritures dans journaux comptabilité dans l’entreprise. 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. Comptabilité Account_acco Ce module permet à - Gestion des journaux & finance untant l’administrateur d’accéder à toutes - Gestion des registres de les options de la comptabilité caisse comme les journaux et le plan comptable Paiement Account_vouc Ce module est utilisé pour Rajoute le bouton « paiement » her effectuer le paiement des aux factures des clients et des différentes factures établies fournisseurs pour pouvoir effectuer les paiements Point de vente Point_of_sale 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. Tableau 3: Description des modules OpenERP en relation avec lofficine Page 44Rapport du projet de fin d’études HAMLI Marouane
  • 45. 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 Purchase countant Account_vo Base Officine ucher Sale Account Stock Figure 10 : Dépendences du module officine Page 45Rapport du projet de fin d’études HAMLI Marouane
  • 46. 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 Page 46Rapport du projet de fin d’études HAMLI Marouane
  • 47. (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 openerp- server.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 Page 47Rapport du projet de fin d’études HAMLI Marouane
  • 48. 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 Page 48Rapport du projet de fin d’études HAMLI Marouane
  • 49. (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 Fonction Name Nom du produit reference Code du produit Ean13 Code à barre du produit Categ_id Catégorie du produit, utile pour le calcul de son prix public sur la base de liste de prix Standard_price Prix d’achat List_price Prix public State Etat du produit Pos_categ_id Forme du produit, utile pour le classement des produits dans le point de vente, ce qui facilite leur recherche posologie Posologie du produit Dcis Liste des DCIs du produit Cis 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) Page 49Rapport du projet de fin d’études HAMLI Marouane
  • 50. Attribut Fonction Name Nom de la méthode Code Code de la méthode Type Type sur lequelle se base la méthode : liquidité, ventes, banques et chèques… Default_credit_account_id Indique le journal de crédit utilisé pour cette méthode Default_debit_account_id Indique le journal de débit utilisé par défaut View_id Indique la vue à utiliser pour afficher les entrées dans le journal Tableau 5: Attributs de la méthode de paiement Page 50Rapport du projet de fin d’études HAMLI Marouane
  • 51. 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 Page 51Rapport du projet de fin d’études HAMLI Marouane
  • 52. 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 Page 52Rapport du projet de fin d’études HAMLI Marouane
  • 53. 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. Page 53Rapport du projet de fin d’études HAMLI Marouane
  • 54. 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. Page 54Rapport du projet de fin d’études HAMLI Marouane
  • 55. 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é. Page 55Rapport du projet de fin d’études HAMLI Marouane
  • 56. 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 Page 56Rapport du projet de fin d’études HAMLI Marouane
  • 57. 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 dalerte 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 Page 57Rapport du projet de fin d’études HAMLI Marouane
  • 58. 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. Page 58Rapport du projet de fin d’études HAMLI Marouane
  • 59. 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. Page 59Rapport du projet de fin d’études HAMLI Marouane
  • 60. 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 Page 60Rapport du projet de fin d’études HAMLI Marouane
  • 61. 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 douverture 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 dune méthode de paiement Page 61Rapport du projet de fin d’études HAMLI Marouane
  • 62. 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 Page 62Rapport du projet de fin d’études HAMLI Marouane
  • 63. 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 dordonnance 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. Page 63Rapport du projet de fin d’études HAMLI Marouane
  • 64. 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). Page 64Rapport du projet de fin d’études HAMLI Marouane
  • 65. 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, cest-à-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. Page 65Rapport du projet de fin d’études HAMLI Marouane
  • 66. 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-on- ubuntu-10-04-lts - http://www.easyopenerp.com/principales-nouveautes-de-la-version-6-1/ - http://www.ibcscorp.com/application-integration-customization/erp/openerp- 2/openerp-custom-module-development-quick-start-guide/ - http://planet.domsense.com/docs/openerp-web/en/addons.html - https://code.launchpad.net/~guerrerocarlos/openobject- addons/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 Page 66Rapport du projet de fin d’études HAMLI Marouane
  • 67. Annexe A Introduction au développement de modules OpenERP avec le framework « Open Object » Page 67Rapport du projet de fin d’études HAMLI Marouane
  • 68. INTRODUCTION AUX OBJETS Toutes les données dOpenERP sont accessibles par les objets: c’est à dire pour la création dun 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 dOpenERP via « ORM » (Object Relational Mapping). Par exemple: il existe dans le module de base dOpenERP, lobjet res.partner qui permet daccéder aux informations concernant les partenaires. Aussi il ya dans le module de base account, lobjet dOpenERP account.invoice pour accéder aux données relatives à la facture. Tous ces objets se trouvent dans des fichiers dextension .py. On signale quil ya un objet pour chaque type de ressource et non un objet pour une ressource, ainsi un il ya un unique objet res.partner pour manipuler tous les partenaires (dans ce cas les ressources) et on ne peut pas avoir lobjet res.partner pour chaque partenaire: parlons aux termes dorienté objet pour bien assimiler cette notion, on peut dire que lobjet dOpenERP 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 dOpenERP sont les tables de la BD et les lignes des tables sont les ressources. Donc une table (un objet dOpenERP) comprend plusieurs lignes (Ressources dopenErp). 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 sappliquera: précisément ce paramètre contient une liste des identificateurs des ressources (ids) sur laquelle la méthode sappliquera. 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 à lobjet qui manipule ces ressources) et aussi nous voulons appeler la méthode dobjet 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 dobjets et les quelques méthodes propres dOpenERP. Un rappel important pour les programmeurs : - Les objets dOpenERP sont appelés classes si on parle au terme de la programmation orientée objet - Et une ressource est appelée objet, linstance de la classe. Definition des objets en OpenERP Pour définir un nouvel objet, on définit une nouvelle classe et après on linstancie, cette classe doit hériter de la clase OSV du module OSV dOpenERP. Page 68Rapport du projet de fin d’études HAMLI Marouane
  • 69. Ainsi, la première ligne de la définition de lobjet sera toujours comme suivant: class nom_objet(osv.osv): _name = nom de lobjet _columns = {...} ... nom_objet() Donc, lobjet 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 dorienté objet) de lobjet - _constraints: on y détermine des restrictions sur lobjet (on en parlera ultérieurement) - _defaults: on définit les valeurs par défaut pour quelques champs de lobjet. - _inherit: on met lobjet père que lactuel objet hérite. On va le détailler dans deux types: o ORM - Object Declaration - _inherit (1) : Réalise un héritage dun 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 dun objet existant, ajoute des caractéristiques à lobjet dont nous héritons, exemple : class res_partner_add_langs(osv.osv): _name = res.partner _inherit = res.partner Page 69Rapport du projet de fin d’études HAMLI Marouane
  • 70. _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 lobjet, la valeur par défaut est None - _order: on met le nom du champ de lobjet 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 lexécuter dans la création de lobjet (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 sarticulent 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 quils ne sont pas enregistrés dans la base de données mais plutôt sont calculables à partir dautres champs dans le temps réel. La signature de la méthode dinitialisation 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 à lutilisateur 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, lutilisateur peut programmer que le programme remplit automatiquement le champ city à Barcelone si le code postale prend la valeur 08000. - help: montre un message daide lorsque la souris est au-dessus de ce champ. Exemple: name: fields.char(name, help=le nom saffiche.), Page 70Rapport du projet de fin d’études HAMLI Marouane
  • 71. - 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 denregistrer une ressource si un champ obligatoire est vide. Donc il est obligatoire de remplir tous les champs obligatoires avant denregistrer 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 lattribut, 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: cest 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 sil prend 2, le champ apparaît seulement dans la recherche avancée qui se manifeste lorsquon clique sur le symbole + - on_change: lance une fonction (définit sur lobjet 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). Page 71Rapport du projet de fin d’études HAMLI Marouane
  • 72. Syntaxe: fields.float(Nom du champs [, Parametres optionnels]), Note: il ya 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 lheure dans le même champ. Syntaxe : fields.datetime(Nom du champs [paramétres optionnels, ]), - Binary: pour limage, Exemple : image: fields.binary(Image) - selection: ce champ permet à lutilisateur 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é senregistre dans la ligne de la table (correspondante à lobjet 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 senregistrer 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 sagit dune méhode dinstance dopenErp, 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) Page 72Rapport du projet de fin d’études HAMLI Marouane
  • 73. fnct: cest la fonction qui calcule la valeur du champs avec une méthode dopenErp 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: lobjet (one) possède plusieurs (many) enfants Page 73Rapport du projet de fin d’études HAMLI Marouane
  • 74. 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 dun enregistrement - write: Mise à jour dun enregistrement - unlink: Suppression dun enregistrement - read: Lecture de champs dun enregistrement - copy : Duplication dun enregistrement - search: Recherche denregistrement - browse: Récupération denregistrement via critères de recherche - name_get: Retourne uniquement que le nom et lidentifiant du record - name_search: Réalise une recherche du nom sur base dun 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 Page 74Rapport du projet de fin d’études HAMLI Marouane