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

N° d’Ordre :

ECOLE NATIONALE DES SCIENCES UNIVERSITE ABDELMALEK
APPLIQUEES - 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

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 2
Rapport du projet de fin d’études HAMLI Marouane

Remerciements

Le présent rapport reflète le fruit des efforts conjugués de plusieurs personnes. Il
m’est alors agréable d’exprimer ma reconnaissance auprès de toutes ces personnes, dont
l’intervention au cours de ce projet, a favorisé son aboutissement.

Aussi je tiens à rendre grâce à mes parents, ma famille et mes amis qui, avec leur
soutien et encouragement, j’ai pu arriver à terme de ce travail.

Je souhaite remercier aussi mon encadrant d’entreprise, pour m’avoir accordé cette
chance de travailler à ses cotés, et qui m’a été d’une aide très utile durant ma période de
stage, Mr ELKAFIL Abdrahman pour ses directives précieuses et ses conseils judicieux qui
m’ont été d’un appui considérable dans ma démarche.

Je remercie particulièrement Mr Mohamed HASSOUN EL ALAMI pour son
encadrement, son soutien, ainsi que pour ses conseils instructifs durant toute la période de ce
travail.

Mes remerciements aussi à Mr ELHADDAD Mohamed, chef de la filière informatique,
ainsi qu’à l’ensemble des professeurs de l’ENSA-Tanger pour les efforts fournis pour notre
bonne formation.

Que les membres de jury trouvent ici l’expression de mes reconnaissances pour avoir
accepté de juger notre travail. Que tous ceux et celles qui ont contribué de près ou de loin à
l’accomplissement de ce travail trouvent l’expression de mes remerciements les plus
chaleureux.

Page 3

Résumé

Les technologies de l’information ont connu une importante évolution durant ces
dernières années, ce qui a donné comme résultat l’émergence de plusieurs solutions
informatiques pour remédier aux différentes problématiques réelles.

Les Progiciels de Gestion Intégré, appelés PGI ou ERP, sont l’une des solutions les
plus pratiques à ce jour, ils intègrent les principales composantes fonctionnelles de
l'entreprise: gestion de production, gestion commerciale, logistique, ressources humaines,
comptabilité, contrôle de gestion.

A l'aide de ce système unifié, les utilisateurs de différents métiers travaillent dans un
environnement applicatif identique qui repose sur une base de données unique. Ce modèle
permet d'assurer l'intégrité des données, la non-redondance de l'information, ainsi que la
réduction des temps de traitement.

Le travail présenté dans ce rapport concerne l’analyse du besoin, l’adaptation et
l’intégration du PGI Open-Source « OpenERP » pour la gestion d’officine pharmaceutique.

Pour y arriver, il a fallut d’abord se rendre sur les lieux, une pharmacie, pour prendre
notes des différents processus métier, pour ensuite pouvoir élaborer une liste des différents
besoins requis. L’étape qui a suivit était de se familiariser avec ce nouvel outil et découvrir les
options qu’il offre, puis apprendre comment développer un module pour ce progiciel. Ensuite
faire quelques simulations pour s’assurer que le travail a bien été fait, et corriger les bugs qui
peuvent arriver, si jamais il y en a.

Les PGI sont connus pour leur structure « modulaire », ainsi il a fallut développer un
module spécial pour les officines, lequel fonctionne en relation avec d’autres modules
existants, comme le module des achats, ou celui du point de vente.

Page 4

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 5

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 6

Table des figures

Figure 1: Logo Nextma ............................................................................................................ 13
Figure 2: Nextma sur la carte ................................................................................................... 13
Figure 3: Clients Nextma ......................................................................................................... 15
Figure 4: Cycle de développement en Y .................................................................................. 21
Figure 5: Planning du projet ..................................................................................................... 22
Figure 6: Interface d'Ubuntu 11.10 .......................................................................................... 34
Figure 7 : Logo PostgreSQL .................................................................................................... 35
Figure 8 : Interface Web d'OpenERP ....................................................................................... 36
Figure 9: Architecture d'OpenERP ........................................................................................... 38
Figure 10 : Dépendences du module officine ........................................................................... 45
Figure 11: Connexion ............................................................................................................... 47
Figure 12: Accueil OpenERP - client web ............................................................................... 48
Figure 13: Liste des modules OpenERP .................................................................................. 48
Figure 14: Gestion des utilisateurs ........................................................................................... 51
Figure 15: Gestion des groupes ............................................................................................... 51
Figure 16: Liste des médecins .................................................................................................. 52
Figure 17: Formulaire médecin ................................................................................................ 52
Figure 18:Formulaire patient .................................................................................................... 52
Figure 19: Bons de commande fournisseur .............................................................................. 53
Figure 20: Liste des réceptions................................................................................................. 54
Figure 21: Formulaire client ..................................................................................................... 54
Figure 22: Gestion des inventaires physiques .......................................................................... 55
Figure 23: Liste des mouvements de stock ............................................................................. 55
Figure 24: Liste des règles de stock minimum ......................................................................... 56
Figure 25: Formulaire produit – I............................................................................................. 56
Figure 26: Formulaire produit - II ............................................................................................ 57
Figure 27: Produit en stock d'alerte .......................................................................................... 57
Figure 28: Analyse des mouvements de stocks ........................................................................ 57
Figure 29: Liste des factures clients ......................................................................................... 58
Figure 30: Détails facture client ............................................................................................... 58
Figure 31: Paiements clients .................................................................................................... 59
Figure 32: Point de vente ......................................................................................................... 60
Figure 33: Paiement en espèces ............................................................................................... 60
Figure 34: Assistant d'ouverture des caisses ............................................................................ 61
Figure 35: Liste des méthodes de paiement ............................................................................. 61
Figure 36: Formulaire de création/modification d'une méthode de paiement .......................... 61
Figure 37: Liste des caisses ...................................................................................................... 62
Figure 38: Journal des ventes ................................................................................................... 62
Figure 39: Ordre de vente......................................................................................................... 62
Figure 40: Renseignement des informations d'ordonnance...................................................... 63

Page 7

Figure 41: Catégories des produits - point de vente ................................................................. 63
Figure 42: Analyse du point de vente par produit .................................................................... 64
Figure 43: Analyse des enregistreuses par utilisateur .............................................................. 64

Diagrammes
Diagramme 1: Gestion basique ................................................................................................ 26
Diagramme 2: Vente au comptoir ............................................................................................ 27
Diagramme 3: Gestion des achats ............................................................................................ 28
Diagramme 4: Gestion des ventes ............................................................................................ 29
Diagramme 5 : Gestion du stock .............................................................................................. 30
Diagramme 6: Cas d'utilisations - Statistiques et alertes.......................................................... 31
Diagramme 7: Diagramme des classes - fonctionnel ............................................................... 32

Tableaux

Tableau 1 : Comparaison des méthodes de développement ..................................................... 20
Tableau 2: Liste des fonctionnalités requises ........................................................................... 25
Tableau 3: Description des modules OpenERP en relation avec l'officine .............................. 44
Tableau 4 : attributs du produit ................................................................................................ 49
Tableau 5: Attributs de la méthode de paiement ...................................................................... 50

Page 8

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 9

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 10

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 11

Partie I : Contexte général du projet

Chapitres :

- Présentation de l’organisme d’accueil
- Cadre général du projet

Page 12

1 Chapitre I : Présentation de l’organisme d’accueil
1.1 Présentation de Nextma

Figure 1: Logo Nextma

Nextma est une Société de Services en Logiciels Libres (SSLL) qui accompagne les
entreprises et institutions dans le choix des solutions open source ainsi que dans l'intégration,
le développement, l'adaptation aux besoins spécifiques, la maintenance et le support. Afin de
bénéficier des meilleures solutions libres dans la gestion des systèmes d'information.

Figure 2: Nextma sur la carte

Nextma a développé une expertise autour d’OpenERP depuis 2006 (premier partenaire
officiel OpenERP au Maroc en 2007) et a contribué à faire connaître cet ERP open source au
Maroc à travers plusieurs déploiements réussis dans les PME marocaines et des conférences
dans les universités et adapte celui-ci à la législation marocaine et aux besoins spécifiques des
entreprises.

Page 13

1.2 Prestations et services
Nextma offre une large palette de prestations et de services basés sur des composants
libres adaptés aux systèmes et aux réseaux des clients. La principale tâche de cette société est
d’offrir des solutions sur mesure, en matière de formation et d’assistance, concernant les
problématiques relevant des systèmes d’informations, moyennant des outils libres.

La gamme de services de Nextma est articulée autour de quatre axes majeurs qui
permettent d'accompagner les clients durant toutes les phases d'un projet afin d'en assurer sa
réussite en :

Formation : L’offre des formations, techniques et fonctionnelles, permet
d'accompagner les organisations qui disposent d’équipes opérationnelles capables de mener à
bien des projets. Ces formations peuvent être établies sous forme de transferts de
compétences, en phases avals des projets.

Support : En plus des offres de formations, la société propose aux équipes dédiées
au développement, des prestations de support d’aide à la maintenance, afin de réduire le
temps de résolution des interrogations ou des difficultés que les entreprises pourraient
rencontrer lors de la mise en œuvre de certains logiciels.

Conseil : Nextma possède une équipe formée de consultants techniques et
fonctionnels qui assure soit dans le cadre de projets, soit en amont, des missions de conseil
dans les domaines suivants: gestion de contenu, travail collaboratif, dématérialisation des
procédures, migration vers le libre, architecture et dimensionnement d'applications basées sur
OpenERP…etc.

Développement : le cœur métier de Nextma et comprend le développement sur la
base de logiciels libres, de portails collaboratifs internet ou intranet, avec des composantes de
publication web, de travail collaboratif, de gestion électronique de documents et de workflow.

1.3 Secteurs d’activité
De par les multiples projets que Nextma a mené, elle a acquis un savoir-faire
susceptible de lui permettre l’implantation de logiciels libres dans les différents secteurs:

Enterprise Ressource Planning (ERP) : la solution adoptée par Nextma est
OpenERP, un PGI Open-Source.

Customer Relationship Management (CRM) : 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 s'appuie sur le système de gestion du
contenu « Joomla ».

Page 14

Gestion électronique des documents : Il s’agit d’un système informatisé
d'acquisition, classement, stockage et archivage des documents. La solution proposée est
Alfresco.

1.4 Références
Nextma compte plusieurs déploiements réussît d’OpenERP dans des PME marocaines
dont je cite quelques références :

Figure 3: Clients Nextma

Page 15

2 Chapitre II : Cadre général du projet

2.1 Présentation générale de l’officine

La pharmacie d'officine est la branche la plus connue de la pharmacie. C'est la branche
regroupant les pharmaciens qui travaillent dans les pharmacies de ville, appelées aussi
officines, où les médicaments sont délivrés au public.

Le rôle du pharmacien d'officine est la délivrance des ordonnances prescrites par les
médecins, les conseils associés à la prise des médicaments, à l'hygiène, à la nutrition ou, plus
globalement, à la santé publique.

Le travail du pharmacien d'officine est aussi l'analyse de l'ordonnance, la vérification
des posologies, des interactions médicamenteuses et des contre-indications existantes en
fonction de l'état du patient. Le pharmacien, étant au bout de la chaîne de la prescription
médicale, est responsable des médicaments délivrés, même en cas d'erreur ou négligence de la
part du médecin prescripteur.

À ce titre, il peut refuser de délivrer l'ordonnance, ou bien modifier les posologies ou
médicaments, le plus souvent après accord avec le médecin prescripteur. Il peut également
faire le suivi du traitement et aider à l'établissement d'un plan pharmacothérapique.

Le pharmacien d'officine a aussi un rôle social, il est en mesure d'indiquer aux
personnes en difficulté les organismes ou les structures compétentes en matière de Santé
Publique et d'aides sociales.

2.2 Problématique

Les officines marocaines souhaitent s’ouvrir sur les nouvelles technologies et les
utiliser pour avoir un meilleur rendement, et ainsi intégrer des solutions de gestion complètes,
paramétrables et flexibles pour la gestion de tout ce qui se rapporte au domaine de la
pharmacie.

Certes il existe des solutions sur le marché, mais elles sont payantes, en plus du fait
qu’il est difficile de communiquer entre ces applications avec d’autres solutions « externes »
(le cas d’automatiser les commandes de médicaments), et leur support est bien limité vu
qu’elles ont été codées à la demande, à noter aussi qu’elles ne sont pas flexibles.

Avec ces outils, le pharmacien se retrouve obligé d’effectuer lui-même un bon nombre
de tâches qui normalement, avec ces solutions, doivent être automatisées, je cite comme
exemple envoyer des bons de commande vers le grossiste (fournisseur) : le pharmacien (agent
ou administrateur) crée un bon de commande avec une liste des produits demandés ainsi que

Page 16

leur quantités, ce bon devra être transmis automatiquement vers un fournisseur parmi ceux
enregistrés dans la liste, après sa validation, cette option était opérationnelle avant, mais
nécessitait une installation matérielle particulière (modems 56k..etc) qui n’était pas disponible
chez tous les partenaires, et a été abandonnée plus tard, donc le pharmacien est obligé de
passer par la méthode classique qui est passer sa commande par téléphone. Les bons de
commande sont donc temporaires, et se trouvent dans la plupart des cas supprimés après avoir
effectué la réception des produits.

Autre problème que le pharmacien rencontre, est quand l’application plante, et qu’il
n’a plus accès à certaines données, comme ce cas dont j’étais témoin lors de ma visite à
l’officine du client, la liste des fournisseurs a été endommagée et n’était plus accessible, ce
qui empêchait d’établir des bons de commande ou effectuer des réceptions dans le logiciel,
ainsi les bons de livraisons des grossistes s’entassaient les uns sur les autres, en attendant que
la service support du logiciel envoie un technicien pour rétablir la base de données. Ceci avait
d’autres conséquences, le pharmacien était habitué à faire une sauvegarde quotidienne de ses
transactions, cette sauvegarde n’était plus possible depuis que la liste des fournisseurs est
perdue, ce qui représente un grand risque pour ces données, surtout qu’il était en période de
garde et avait effectué plusieurs ventes et réceptions. En plus, les quantités des produits au
stock sont devenues toutes fausses.

L’éditeur du logiciel proposait une assistance instantanée, via un logiciel d’assistance
à distance, qui n’a pas été fourni à tous ses clients, et la seule solution pratique était d’envoyer
les techniciens réparer les machines ne fonctionnant plus.

Résultat : près de 5 jours d’attente, sans aucune sauvegarde, avec des données
erronées, et encore faut-il du temps pour saisir toutes ces réceptions effectuées pendant la
panne, après la réparation du logiciel.

2.3 Objectifs du projet

Le travail demandé est d’adapter un progiciel libre, OpenERP, aux besoins des
officines, en essayant de rajouter de nouvelles fonctionnalités que les autres solutions ne
peuvent offrir.

Afin de garantir une modernisation des services des officines, il est indispensable
d’adopter les nouvelles technologies et les exploiter pour en tirer le meilleur profit.

Les PGI sont connus pour leur intégration des principales fonctions nécessaires à la
gestion des flux et procédures de l’entreprise (comptabilité, achats, ventes…), tous ces outils
accèdent à des ressources communes, en particulier des bases de données.

Parmi les autres avantages des PGI, c’est qu’ils sont conçus de telle sorte qu'un
"simple" paramétrage suffit à les adapter à l'organisation de l'entreprise. Il n'est normalement
pas nécessaire d'effectuer des développements spécifiques, sauf en cas de nécessité, lorsque ce

Page 17

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 18

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 19

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 20

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 21

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 22

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 23

Partie II : Etude fonctionnelle et technique

Chapitres :

- Analyse et conception du projet
- Technologies mises en œuvre
- Développement du module « officine »

Page 24

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 25

3.2 Conception
L’étape de conception est très importante pour la réussite d’un projet informatique car
elle vise à définir une feuille de route du projet, le concevoir et le valider avant de passer au
développement du système. Elle permet aussi d’avoir une bonne réflexion avant de passer à
l’action, une bonne organisation du travail et une bonne communication entre les différents
intervenants dans le projet.

J’ai utilisé des diagrammes UML pour cette étape, vu qu’il est le plus approprié pour les
projets informatiques orientés objet, et aussi car ses diagrammes facilitent la lisibilité et la
compréhension des modèles même pour les ceux qui sont loin du domaine informatique.

Le principal avantage d'UML est qu'il est devenu le standard en termes de modélisation
objet, son caractère polyvalent et performant et sa souplesse en fait un langage universel.

3.2.1 Diagramme des cas d’utilisations :
Dans ce projet, j’ai six grands cas d’utilisations, ces cas sont détaillés dans les
diagrammes suivants :

1. Gestion basique :

Diagramme 1: Gestion basique

La gestion basique veut dire l’ajout, modification et suppression des objets
élémentaires dans une officine, à savoir les médicaments, les fournisseurs, les clients, les
médecins, les patients, les DCI (Dénomination Commune Internationale, nom du composant
chimique principal d’un médicament), les utilisateurs et leurs groupes.

Cette gestion est limitée aux administrateurs, qui n’auront la main pour effectuer leurs
modifications qu’après s’être connecté.

Page 26

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 27

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 28

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 29

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 30

Diagramme 6: Cas d'utilisations - Statistiques et alertes

Ce volet est autour de tout ce qui est statistiques utiles pour le pharmacien, afin d’avoir
une idée claire de ses ventes et ses achats, comme la distribution des ventes par produit ou par
client, la distribution des achats par produit ou par fournisseur, la distribution détaillée des
ventes ou achats.

Le pharmacien pourra consulter les produits en stock d’alerte afin de pouvoir les
commander à nouveau.

3.2.2 Diagramme des classes :
Le diagramme suivant est le diagramme de classes « fonctionnel » que j’ai réalisé
avant de me lancer dans le développement.

Page 31

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 32

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 33

4 Chapitre IV : Technologies mises en œuvre

Ce chapitre décrit les différentes technologies adoptées par Nextma, et utilisées pour la
réalisation de ce projet, à commencer par le système d’exploitation Ubuntu, tout en passant
par le PGI OpenERP, le système de gestion de bases de données PostgreSQL, et en fin les
langages nécessaires pour le développement, à savoir le langage Python et XML.

4.1 Ubuntu
Ubuntu est un système d’exploitation libre commandité par la société Canonical et une
marque déposée par cette même société.

Fondé sur la distribution Linux Debian et utilisant le bureau Unity, Ubuntu se veut
« convivial, intuitif et sûr ». Il est constitué de logiciels libres, est disponible gratuitement y
compris pour les entreprises, et bénéficie d'une nouvelle version (appelée « mise à niveau »)
tous les six mois.

Avec une utilisation globale estimée à plus de 25 millions d'utilisateurs, il est
principalement conçu pour une utilisation sur des ordinateurs personnels (portables et fixes),
bien que d'autres versions consacrées aux netbooks et aux serveurs existent aussi. Depuis
Ubuntu 11.04, la version Netbook a fusionné avec la version Desktop. Cette dernière étant
passée à l'interface Unity, il n'y avait plus de raison de maintenir deux branches distinctes.

Figure 6: Interface d'Ubuntu 11.10

La version d’Ubuntu utilisée pour ce projet est la 11.10, ayant pour nom de code « The
Oneiric Ocelot », cette version est la quinzième version d'Ubuntu. Son développement s'est
échelonné sur six mois, jusqu'à sa publication en tant que version stable le 13 octobre 2011.

Page 34

Elle profitera des mises à jour de sécurité pendant une durée de 18 mois, soit jusqu'en avril
2013.

4.2 PostgreSQL
PostgreSQL est un système de gestion de base de données relationnelle et objet
(SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD.

Ce système est concurrent d'autres systèmes de gestion de base de données, qu'ils
soient libres (comme MySQL et Firebird), ou propriétaires (comme Oracle, Sybase, DB2,
Informix et Microsoft SQL Server). Comme les projets libres Apache et Linux, PostgreSQL
n'est pas contrôlé par une seule entreprise, mais est fondé sur une communauté mondiale de
développeurs et d'entreprises.

PostgreSQL peut stocker plus de types de données que les types traditionnels entier,
caractères, etc. L'utilisateur peut créer des types, des fonctions, utiliser l'héritage de type etc.

PostgreSQL est pratiquement conforme (de plus en plus conforme) aux normes ANSI
SQL 89, SQL 92 (SQL 2), SQL 99 (SQL 3), SQL:2003 et SQL:2008. Il fonctionne sur
diverses plates-formes matérielles et sous différents systèmes d'exploitation.

Figure 7 : Logo PostgreSQL

PostgreSQL fonctionne sur Solaris, SunOS, Mac OS X, HP-UX, AIX, Linux, IRIX,
Digital Unix, BSD, NetBSD, FreeBSD, OpenBSD, SCO unix, NeXTSTEP, UnixWare et
toutes sortes d'Unix. Depuis la version 8.0, PostgreSQL fonctionne également nativement sur
Windows. Avant la version 8, il fallait un émulateur de type cygwin pour faire fonctionner
PostgreSQL sur ce système d'exploitation.

PostgreSQL est largement reconnu pour son comportement stable, proche de Oracle.
Mais aussi pour ses possibilités de programmation étendues, directement dans le moteur de la
base de données, via PL/pgSQL. Le traitement interne des données peut aussi être couplé à
d'autres modules externes compilés dans d'autres langages.

Page 35

4.3 OpenERP
Anciennement connu sous le nom Tiny ERP, signifiant la fourmi de l’Enterprise
resource planning) est un progiciel intégré de gestion ouvert, libre de droits comprenant les
ventes, la gestion de relation client (CRM), la gestion de projet, la gestion d'entrepôt, la
production, la comptabilité et les ressources humaines. OpenERP a trois composants séparés :
le serveur openerp-server qui stocke ses données dans une base postgresql, le client openerp-
client qui s'installe sur le poste de l'utilisateur et le serveur web openerp-web qui permet une
utilisation depuis un navigateur. Ces trois composants communiquent par les protocoles xml-
rpc et net-rpc.

Figure 8 : Interface Web d'OpenERP

Le logiciel est basé sur une forte architecture MVC, des flux de travail flexibles, une
interface-utilisateur graphique dynamique, une interface XML-RPC, et un système
personnalisable de comptes-rendus avec une intégration pratique d'OpenOffice.org.

Dans la classification des logiciels, OpenERP, comme tout autre PGI sur le marché est
un package destiné, a priori, à tous les secteurs, à toutes les fonctions, les adaptations
nécessaires se faisant par paramétrage.

Il dispose de forts arguments commerciaux pour séduire les dirigeants (il propose de
mettre un terme au désordre du système d’information, et aussi de régler des problèmes
d’organisation sans effort politique). Cette offre séduisante par sa qualité et sa cohérence se
révèle à l’usage plus risquée que l’on avait pu l’imaginer : elle ne peut être efficace que si l’on
accepte les contraintes qu’elle impose. Sa mise en œuvre comporte des difficultés et des
pièges.

Implanter un PGI a ses avantages, parmi lesquels je cite :

o Optimisation des processus de gestion
o Cohérence et homogénéité des informations
o Intégrité et unicité du Système d’information

Page 36

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 d'applications (contenant les objets de gestion, le moteur de
workflow, le générateur d'édition, etc.)
3. Un serveur de présentation (appelé OpenERP Web) qui permet à l'utilisateur de
se connecter à OpenERP avec n'importe quel navigateur internet (avec le
lecteur Flash installé pour l'affichage des graphiques). Ce serveur n'est pas
nécessaire si l'utilisateur utilise le client lourd mais qui nécessitera une
installation physique sur le poste de l'utilisateur (cette application se nomme
Client GTK).

Page 37

Figure 9: Architecture d'OpenERP

Ses fonctions de veille économique intégrées permettent à des utilisateurs multiples de
traiter tous les aspects du logiciel. Ainsi, les rapports et les flux de travail peuvent être
personnalisés.

La partie serveur est écrite en langage Python. Les différentes briques sont organisées
en «modules». Un module est un dossier avec une structure pré-définie contenant du code
Python et des fichiers XML. Un module définit la structure de données, formulaires, rapports,
menus, procédures, flux de travail, etc.

Le client est léger car il ne contient pas de logique d'entreprise (l'ensemble est
embarqué dans le serveur d'application). Ainsi, l'ajout de nouveaux objets, comme les menus
ou formulaires, le rend accessible à tout type de client graphique (GTK+, Web, Qt, ou Texte).

Le client GTK+ est par défaut et est basé sur la plateforme PyGTK (Python).

Le client-web est écrit en langage Python. Il utilisait la plate-forme turboGears jusqu'à
la version 5.0.1. Bien que concernant le contenu, les clients GTK + et -web soient équivalents,
il existe certaines différences dans la fonctionnalité de l'interface. Par exemple le client-web
peut avoir un lien de personnalisation sur chaque formulaire, mais le client GTK+ n'a pas de
fonction comparable.

Pour ce projet, la version d’OpenERP qui m’a été conseillée pour l’utiliser est la 6.1,
parue en février 2012, cette version comporte plusieurs nouveautés :

- Un meilleur partage des informations : Des fonctionnalités de partage des
informations à des tiers ont été ajoutées. Il est par exemple possible de permettre
l'accès aux données d'un projet en cours à un sous-traitant ou de permettre à un client
de consulter les factures qui lui correspondent et de les imprimer. La refonte de
l'interface Web riche en javascript permet en outre d'intégrer n'importe quelle partie de
l'interface d'OpenERP à site Web tiers.

Page 38

- Fonctions d'échanges EDI : Des fonctions d'Échange de données informatisé font leur
apparition, permettant à un partenaire d'importer des données (par exemple une
facture) le concernant dans son propre système OpenERP ou progiciel tiers (au format
JSON), et même d'effectuer le paiement en ligne.
- Une interface mobile : Une nouvelle interface conçue pour l'utilisation sur les
terminaux mobiles de type smartphone fait son apparition. Basée sur le framework
JQuery Mobile, elle ne permet pour l'instant que la consultation en lecture seule des
informations.
- Une interface destinée aux points de ventes : Une nouvelle interface dédiée aux points
de ventes à écran tactiles, tablettes et autre dispositifs de caisse interactifs est
inaugurée dans cette version d'OpenERP. Cette fonctionnalité très demandée permet
d'utliser un lecteur de codes à barres, de sélectionner des produits par catégorie/sous
catégorie, la recherche par nom de produits et peut fonctionner hors-ligne et se
synchroniser automatiquement lorsque la connexion avec le serveur est rétablie.

Et ce ne sont pas que les nouveautés qu’a apporté cette version, mais aussi des
améliorations :

o Une configuration plus simple : De nouveaux boutons de raccourcis font leur
apparition, permettant de créer plus intuitivement de nouveaux documents et
de nouveaux enregistrements directement à partir de leur saisie dans les
champs de données. De même, une installation fraîche d'OpenERP inclut
dorénavant une configuration minimale des modules, basée sur les bonnes
pratiques et les utilisations les plus courantes observées chez les utilisateurs.
o Un effort sur l'utilisabilité : L'installateur et l'assistant de configuration ont été
repensés afin de faciliter la compréhension par les nouveaux utilisateurs, en
demandant moins de détails sur la société à gérer et en se focalisant sur les
informations absolument nécessaires. La page d'installation des modules
propose par défaut une installation sous forme de « thèmes ». Par exemple, un
clic sur le thème « Ventes » installera tous les modules nécessaires à la gestion
des ventes, et vous dirigera ensuite automatiquement vers ce module configuré
et prêt à l'emploi.
o Importation des données facilitée : L'importation des données dans OpenERP à
partir de sources tierces a été améliorée. En effet, un assistant fait son
apparition permettant de facilement faire correspondre un fichier de données
au format csv au schéma de données OpenERP. À noter aussi l’existence de
fonctions d'importation automatisée des données depuis SugarCRM et Google
Calendar.
o Sous-système de courriels unifié : La configuration des paramètres de
connexions pour l'envoi et la réception de courriels est maintenant unifiée, ce
qui met fin à la duplication des configurations pour les modules tirant partie de
ces fonctions de courriels.

Page 39

o Refonte du module de paie : Le module de gestion de paie a été repensé, afin
d'être plus flexible et s'adapter ainsi plus aisément aux spécificités de chaque
pays et de chaque entreprise.
o Ré-écriture de l'interface Web : L'interface Web d'OpenERP a été entièrement
ré-écrite et fait dorénavant la part belle à la technologie Javascript, sans non
plus bouleverser son apparence et l'expérience utilisateur. Parmi les
conséquences, on peut noter qu'elle offre plus de fonctionnalités avec moins de
code, et est plus rapide que l'ancienne implémentation de la 6.0. Au niveau des
améliorations se trouve aussi la possibilité de personnaliser les tableaux de
bord directement depuis l'interface avec de simples glisser-déposer, ainsi que
l'arrivée d'une nouvelle forme de présentation des données, la vue « kanban ».
o Compatibilité WSGI : De gros efforts ont été fait afin de rendre OpenERP
compatible avec Web Server Gateway Interface qui permet de recourir à des
serveurs d'application python tels que Gunicorn et uWSGI facilitant une
implémentation extrêmement robuste d'OpenERP sur les serveurs, un bien
meilleur contrôle de l'assignation des ressources matérielles et une
simplification de la mise en place de mécanismes de réplication et de
répartition de charge (les serveurs d'applications proposant souvent de telles
fonctionnalités).

4.4 Python

Python est un langage de programmation multi-paradigme. Il favorise la
programmation impérative structurée, et orientée objet. Il est doté d'un typage dynamique fort,
d'une gestion automatique de la mémoire par ramasse-miettes et d'un système de gestion
d'exceptions ; il est ainsi similaire à Perl, Ruby, Scheme, Smalltalk et Tcl.

Le langage Python est placé sous une licence libre proche de la licence BSD et
fonctionne sur la plupart des plates-formes informatiques, des supercalculateurs aux
ordinateurs centraux, de Windows à Unix en passant par Linux et Mac OS, avec Java ou
encore .NET. Il est conçu pour optimiser la productivité des programmeurs en offrant des
outils de haut niveau et une syntaxe simple à utiliser. Il est également apprécié par les
pédagogues qui y trouvent un langage où la syntaxe, clairement séparée des mécanismes de
bas niveau, permet une initiation plus aisée aux concepts de base de la programmation.

Python est un langage :

Page 40

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 41

4.5 XML
XML (eXtensible Markup Language) est en quelque sorte un langage HTML amélioré
permettant de définir de nouvelles balises. Il s'agit effectivement d'un langage permettant de
mettre en forme des documents grâce à des balises (markup).

Contrairement à HTML, qui est à considérer comme un langage défini et figé (avec un
nombre de balises limité), XML peut être considéré comme un métalangage permettant de
définir d'autres langages, c'est-à-dire définir de nouvelles balises permettant de décrire la
présentation d'un texte (Qui n'a jamais désiré une balise qui n'existait pas ?).
La force de XML réside dans sa capacité à pouvoir décrire n'importe quel domaine de
données grâce à son extensibilité. Il va permettre de structurer, poser le vocabulaire et la
syntaxe des données qu'il va contenir.

En réalité les balises XML décrivent le contenu plutôt que la présentation
(contrairement À HTML). Ainsi,XML permet de séparer le contenu de la présentation, ce qui
permet par exemple d'afficher un même document sur des applications ou des périphériques
différents sans pour autant nécessiter de créer autant de versions du document que l'on
nécessite de représentations !

XML a été mis au point par le XML Working Group sous l'égide du World Wide Web
Consortium (W3C) dès 1996. Depuis le 10 février 1998, les spécifications XML 1.0 ont été
reconnues comme recommandations par le W3C, ce qui en fait un langage reconnu. (Tous les
documents liés à la norme XML sont consultables et téléchargeables sur le site web du
W3C, http://www.w3.org/XML/)

XML est un sous ensemble de SGML (Standard Generalized Markup Language),
défini par le standard ISO8879 en 1986, utilisé dans le milieu de la Gestion Electronique
Documentaire (GED). XML reprend la majeure partie des fonctionnalités de SGML, il s'agit
donc d'une simplification de SGML afin de le rendre utilisable sur le web !

XML fait partie du code des modules composants OpenERP, les vues par lesquelles
sont représentés les différents objets sont écrites en XML, ainsi nous y trouvons la description
détaillée de l’affichage des arbres, formulaires, menus et autres actions.

Page 42

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 d'entrepô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 43

- 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 d'achat
produits - Carnet d'adresses
- 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 l'officine

Page 44

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 45

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 46

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE

Ähnlich wie ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE (20)

Mehr von HORIYASOFT

Mehr von HORIYASOFT (20)

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