Vous êtes sur la page 1sur 74

N dOrdre :

UNIVERSITE ABDELMALEK
ESSADI

ECOLE NATIONALE DES SCIENCES


APPLIQUEES - TANGER

PROJET DE FIN DETUDES


Prsent lcole pour obtenir le diplme
DINGENIEUR DETAT
Spcialit: Gnie informatique
Option: Gnie des systmes dinformations

Titre
ANALYSE DE BESOIN, ADAPTATION
ET INTEGRATION DOPENERP POUR
LA GESTION DOFFICINE

Ralis par
HAMLI Marouane
Encdr par
ELKAFIL Abdrahman (NEXTMA)
EL ALAMI Mohamed (ENSAT)
SOUTENU LE 27 juin 2012

Ddicace
Au Dieu tout puissant, mon crateur.
A ma mre, ma raison dtre, ma raison de vivre, la lanterne qui claire mon
chemin et millumine de douceur et damour.
A mon pre, en signe damour, de reconnaissance et de gratitude pour tous les
soutiens et les sacrifices dont il a fait preuve mon gard.
A mes surs.
A mes grands-parents.
Aux familles EL KHAZRAJI et HAMLI.
A mes amis, et tous mes proches.

Rapport du projet de fin dtudes

Page 2

HAMLI Marouane

Remerciements
Le prsent rapport reflte le fruit des efforts conjugus de plusieurs personnes. Il
mest alors agrable dexprimer ma reconnaissance auprs de toutes ces personnes, dont
lintervention au cours de ce projet, a favoris son aboutissement.
Aussi je tiens rendre grce mes parents, ma famille et mes amis qui, avec leur
soutien et encouragement, jai pu arriver terme de ce travail.
Je souhaite remercier aussi mon encadrant dentreprise, pour mavoir accord cette
chance de travailler ses cots, et qui ma t dune aide trs utile durant ma priode de
stage, Mr ELKAFIL Abdrahman pour ses directives prcieuses et ses conseils judicieux qui
mont t dun appui considrable dans ma dmarche.
Je remercie particulirement Mr Mohamed HASSOUN EL ALAMI pour son
encadrement, son soutien, ainsi que pour ses conseils instructifs durant toute la priode de ce
travail.
Mes remerciements aussi Mr ELHADDAD Mohamed, chef de la filire informatique,
ainsi qu lensemble des professeurs de lENSA-Tanger pour les efforts fournis pour notre
bonne formation.
Que les membres de jury trouvent ici lexpression de mes reconnaissances pour avoir
accept de juger notre travail. Que tous ceux et celles qui ont contribu de prs ou de loin
laccomplissement de ce travail trouvent lexpression de mes remerciements les plus
chaleureux.

Rapport du projet de fin dtudes

Page 3

HAMLI Marouane

Rsum

Les technologies de linformation ont connu une importante volution durant ces
dernires annes, ce qui a donn comme rsultat lmergence de plusieurs solutions
informatiques pour remdier aux diffrentes problmatiques relles.
Les Progiciels de Gestion Intgr, appels PGI ou ERP, sont lune des solutions les
plus pratiques ce jour, ils intgrent les principales composantes fonctionnelles de
l'entreprise: gestion de production, gestion commerciale, logistique, ressources humaines,
comptabilit, contrle de gestion.
A l'aide de ce systme unifi, les utilisateurs de diffrents mtiers travaillent dans un
environnement applicatif identique qui repose sur une base de donnes unique. Ce modle
permet d'assurer l'intgrit des donnes, la non-redondance de l'information, ainsi que la
rduction des temps de traitement.
Le travail prsent dans ce rapport concerne lanalyse du besoin, ladaptation et
lintgration du PGI Open-Source OpenERP pour la gestion dofficine pharmaceutique.
Pour y arriver, il a fallut dabord se rendre sur les lieux, une pharmacie, pour prendre
notes des diffrents processus mtier, pour ensuite pouvoir laborer une liste des diffrents
besoins requis. Ltape qui a suivit tait de se familiariser avec ce nouvel outil et dcouvrir les
options quil offre, puis apprendre comment dvelopper un module pour ce progiciel. Ensuite
faire quelques simulations pour sassurer 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 dvelopper un
module spcial pour les officines, lequel fonctionne en relation avec dautres modules
existants, comme le module des achats, ou celui du point de vente.

Rapport du projet de fin dtudes

Page 4

HAMLI Marouane

Avant-propos

Nom : HAMLI
Prnom : Marouane
Intitul du travail : Analyse du besoin, adaptation et intgration dOpenERP pour la gestion
dOfficine.
Etablissement daccueil : 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 ltablissement daccueil : M. ELKAFIL Abdrahman
Encadrant lENSA : M. EL ALAMI Ahmed
Date de dbut et de fin du stage : du 5 Mars au 31 Mai 2012.

Rapport du projet de fin dtudes

Page 5

HAMLI Marouane

Liste des abrviations


Abrviation

Dsignation

PGI

Progiciel de Gestion Intgr

ERP

Enterprise Resource Planning

SSLL

Socits 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

Dnomination Commune Internationale

XML

eXtended Markup Language

BSD

Berkeley Software Distribution

SGBDRO

Systme de Gestion de Base de Donnes Relationnelle et Objet

SQL

Structured Query Language

MVC

Modle Vue Contrleur

GPAO

Gestion de Production Assiste 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 Ajoute

Rapport du projet de fin dtudes

Page 6

HAMLI Marouane

Table des figures


Figure 1: Logo Nextma ............................................................................................................ 13
Figure 2: Nextma sur la carte ................................................................................................... 13
Figure 3: Clients Nextma ......................................................................................................... 15
Figure 4: Cycle de dveloppement 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 : Dpendences 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 mdecins .................................................................................................. 52
Figure 17: Formulaire mdecin ................................................................................................ 52
Figure 18:Formulaire patient .................................................................................................... 52
Figure 19: Bons de commande fournisseur .............................................................................. 53
Figure 20: Liste des rceptions................................................................................................. 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 rgles 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: Dtails facture client ............................................................................................... 58
Figure 31: Paiements clients .................................................................................................... 59
Figure 32: Point de vente ......................................................................................................... 60
Figure 33: Paiement en espces ............................................................................................... 60
Figure 34: Assistant d'ouverture des caisses ............................................................................ 61
Figure 35: Liste des mthodes de paiement ............................................................................. 61
Figure 36: Formulaire de cration/modification d'une mthode de paiement .......................... 61
Figure 37: Liste des caisses ...................................................................................................... 62
Figure 38: Journal des ventes ................................................................................................... 62
Figure 39: Ordre de vente......................................................................................................... 62
Figure 40: Renseignement des informations d'ordonnance...................................................... 63

Rapport du projet de fin dtudes

Page 7

HAMLI Marouane

Figure 41: Catgories 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 mthodes de dveloppement ..................................................... 20
Tableau 2: Liste des fonctionnalits 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 mthode de paiement ...................................................................... 50

Rapport du projet de fin dtudes

Page 8

HAMLI Marouane

Table des matires


Ddicace ..................................................................................................................................... 2
Remerciements ........................................................................................................................... 3
Rsum ....................................................................................................................................... 4
Avant-propos .............................................................................................................................. 5
Liste des abrviations ................................................................................................................. 6
Table des figures ........................................................................................................................ 7
Diagrammes ............................................................................................................................... 8
Tableaux ..................................................................................................................................... 8
Introduction gnrale ................................................................................................................ 11
Partie I : Contexte gnral du projet......................................................................................... 12
1

Chapitre I : Prsentation de lorganisme daccueil .......................................................... 13


1.1

Prsentation de Nextma ............................................................................................. 13

1.2

Prestations et services ................................................................................................ 14

1.3

Secteurs dactivit...................................................................................................... 14

1.4

Rfrences ................................................................................................................. 15

Chapitre II : Cadre gnral du projet ................................................................................ 16


2.1

Prsentation gnrale de lofficine ............................................................................ 16

2.2

Problmatique ............................................................................................................ 16

2.3

Objectifs du projet ..................................................................................................... 17

2.4

Conduite du projet ..................................................................................................... 19

2.4.1

Processus du dveloppement .............................................................................. 19

2.4.2

Planification du projet ........................................................................................ 22

Partie II : Etude fonctionnelle et technique .............................................................................. 24


3

Chapitre III : Analyse et Conception du projet ................................................................ 25


3.1

Analyse du projet ....................................................................................................... 25

3.2

Conception ................................................................................................................. 26

3.2.1
1.

Gestion basique : .................................................................................................... 26

3.2.2
4

Diagramme des cas dutilisations :..................................................................... 26

Diagramme des classes : .................................................................................... 31

Chapitre IV : Technologies mises en uvre .................................................................... 34


4.1

Ubuntu ....................................................................................................................... 34

4.2

PostgreSQL ................................................................................................................ 35

Rapport du projet de fin dtudes

Page 9

HAMLI Marouane

4.3

OpenERP ................................................................................................................... 36

4.4

Python ........................................................................................................................ 40

4.5

XML .......................................................................................................................... 42

Chapitre IV : Dveloppement du module officine ..................................................... 43


5.1

Analyse fonctionnelle des modules OpenERP .......................................................... 43

5.2

Module Officine .................................................................................................. 46

5.3

Installation ................................................................................................................. 47

5.4

Paramtrage ............................................................................................................... 48

5.4.1

Gnral ............................................................................................................... 48

5.4.2

Plan comptable ................................................................................................... 49

5.4.3

Produit ................................................................................................................ 49

5.4.4

Mthodes 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

Problmes rencontrs ................................................................................................. 64

Conclusion ................................................................................................................................ 65
Bibliographie & webographie .................................................................................................. 66
Bibliographie ........................................................................................................................ 66
Webographie ........................................................................................................................ 66
Annexe A.................................................................................................................................. 67

Rapport du projet de fin dtudes

Page 10

HAMLI Marouane

Introduction gnrale
Le prsent rapport est le fruit de mon travail effectu au sein de la socit Nextma
Casablanca, ce stage de 3 mois est le couronnement de ma formation pour obtenir le diplme
dIngnieur dEtat, en gnie informatique, lENSA Tanger.
Durant ces trente dernires annes, linformatique de gestion a subi des
bouleversements considrables. Les avances technologiques du traitement de linformation
ont eu des consquences capitales sur le rle de loutil informatique. Si les premires
applications ont permis dautomatiser les activits oprationnelles des organisations (gestion
de production, gestion commerciale et financire, ressources humaines), aujourdhui les
systmes dinformation prennent en charge des niveaux de gestion de plus en plus
stratgiques.
Les ERP (Enterprise Resource Planning) ou PGI (Progiciels de Gestion Intgrs),
ont connu leur essor en profitant de lvolution ncessaire des systmes dinformation pour le
passage de lan 2000 puis pour la mise en place de leuro. En effet, il tait sduisant de
remplacer tous les logiciels de gestion de lentreprise par un intgr offrant ltat de lart
plutt que dengager des corrections des programmes existants plus ou moins anciens.
Mon Projet de Fin dEtudes est autour dOpenERP, un PGI open-source extrmement
modulaire, et a pour but dadapter puis intgrer cette solution pour permettre la gestion des
officines pharmaceutiques.
Le travail consiste effectuer dabord une analyse du besoin, afin de bien souligner les
diffrentes fonctionnalits requises, ensuite chercher parmi ces fonctionnalits celles qui
sont dj offertes par OpenERP, comme a je pourrai entamer le dveloppement des
fonctionnalits restantes qui nexistent pas encore, pour enfin faire des tests de simulation,
dtecter et corriger les bugs si jamais il y en a.
Ce rapport est scind en deux grandes parties : la premire, compose de deux
chapitres, dfinit le contexte gnral du projet ; Le premier chapitre prsente lorganisme
daccueil, tandis que le second concerne le cadre gnral du projet, et la dmarche suivie pour
assurer son bon droulement. Quant la seconde partie, compose de trois chapitres, concerne
tout ce qui est tude fonctionnelle et technique, ainsi le troisime chapitre est autour de
lanalyse et la conception du projet, le suivant dcrit les choix des technologies mises en
uvre, alors que le dernier explique ltape du dveloppement, ainsi que la simulation et les
diffrents problmes rencontrs.
En fin, ce rapport est termin par une conclusion sur lapport du travail ralis et des
perspectives futurs o il peut dboucher.

Rapport du projet de fin dtudes

Page 11

HAMLI Marouane

Partie I : Contexte gnral du projet


Chapitres :
-

Rapport du projet de fin dtudes

Page 12

Prsentation de lorganisme daccueil


Cadre gnral du projet

HAMLI Marouane

1 Chapitre I : Prsentation de lorganisme daccueil


1.1 Prsentation de Nextma

Figure 1: Logo Nextma

Nextma est une Socit de Services en Logiciels Libres (SSLL) qui accompagne les
entreprises et institutions dans le choix des solutions open source ainsi que dans l'intgration,
le dveloppement, l'adaptation aux besoins spcifiques, la maintenance et le support. Afin de
bnficier des meilleures solutions libres dans la gestion des systmes d'information.

Figure 2: Nextma sur la carte

Nextma a dvelopp une expertise autour dOpenERP depuis 2006 (premier partenaire
officiel OpenERP au Maroc en 2007) et a contribu faire connatre cet ERP open source au
Maroc travers plusieurs dploiements russis dans les PME marocaines et des confrences
dans les universits et adapte celui-ci la lgislation marocaine et aux besoins spcifiques des
entreprises.

Rapport du projet de fin dtudes

Page 13

HAMLI Marouane

1.2 Prestations et services


Nextma offre une large palette de prestations et de services bass sur des composants
libres adapts aux systmes et aux rseaux des clients. La principale tche de cette socit est
doffrir des solutions sur mesure, en matire de formation et dassistance, concernant les
problmatiques relevant des systmes dinformations, moyennant des outils libres.
La gamme de services de Nextma est articule autour de quatre axes majeurs qui
permettent d'accompagner les clients durant toutes les phases d'un projet afin d'en assurer sa
russite en :
Formation : Loffre des formations, techniques et fonctionnelles, permet
d'accompagner les organisations qui disposent dquipes oprationnelles capables de mener
bien des projets. Ces formations peuvent tre tablies sous forme de transferts de
comptences, en phases avals des projets.
Support : En plus des offres de formations, la socit propose aux quipes ddies
au dveloppement, des prestations de support daide la maintenance, afin de rduire le
temps de rsolution des interrogations ou des difficults que les entreprises pourraient
rencontrer lors de la mise en uvre de certains logiciels.
Conseil : Nextma possde une quipe forme 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, dmatrialisation des
procdures, migration vers le libre, architecture et dimensionnement d'applications bases sur
OpenERPetc.
Dveloppement : le cur mtier de Nextma et comprend le dveloppement 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 dactivit


De par les multiples projets que Nextma a men, elle a acquis un savoir-faire
susceptible de lui permettre limplantation de logiciels libres dans les diffrents secteurs:
Enterprise Ressource Planning (ERP) : la solution adopte par Nextma est
OpenERP, un PGI Open-Source.
Customer Relationship Management (CRM)
SUGARCRM qui permet la gestion de la relation client.

Nextma

propose

loffre

Intranet des entreprises et gestion des contenus : Cration didentits visuelles et


sites internet institutionnels et e-Commerce. La solution propose est Virtuemart, une solution
libre de e-commerce (Commerce lectronique) qui s'appuie sur le systme de gestion du
contenu Joomla .

Rapport du projet de fin dtudes

Page 14

HAMLI Marouane

Gestion lectronique des documents : Il sagit dun systme informatis


d'acquisition, classement, stockage et archivage des documents. La solution propose est
Alfresco.

1.4 Rfrences
Nextma compte plusieurs dploiements russt dOpenERP dans des PME marocaines
dont je cite quelques rfrences :

Figure 3: Clients Nextma

Rapport du projet de fin dtudes

Page 15

HAMLI Marouane

2 Chapitre II : Cadre gnral du projet


2.1 Prsentation gnrale de lofficine
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, appeles aussi
officines, o les mdicaments sont dlivrs au public.
Le rle du pharmacien d'officine est la dlivrance des ordonnances prescrites par les
mdecins, les conseils associs la prise des mdicaments, l'hygine, la nutrition ou, plus
globalement, la sant publique.
Le travail du pharmacien d'officine est aussi l'analyse de l'ordonnance, la vrification
des posologies, des interactions mdicamenteuses et des contre-indications existantes en
fonction de l'tat du patient. Le pharmacien, tant au bout de la chane de la prescription
mdicale, est responsable des mdicaments dlivrs, mme en cas d'erreur ou ngligence de la
part du mdecin prescripteur.
ce titre, il peut refuser de dlivrer l'ordonnance, ou bien modifier les posologies ou
mdicaments, le plus souvent aprs accord avec le mdecin prescripteur. Il peut galement
faire le suivi du traitement et aider l'tablissement d'un plan pharmacothrapique.
Le pharmacien d'officine a aussi un rle social, il est en mesure d'indiquer aux
personnes en difficult les organismes ou les structures comptentes en matire de Sant
Publique et d'aides sociales.

2.2 Problmatique
Les officines marocaines souhaitent souvrir sur les nouvelles technologies et les
utiliser pour avoir un meilleur rendement, et ainsi intgrer des solutions de gestion compltes,
paramtrables 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
quil est difficile de communiquer entre ces applications avec dautres solutions externes
(le cas dautomatiser les commandes de mdicaments), et leur support est bien limit vu
quelles ont t codes la demande, noter aussi quelles ne sont pas flexibles.
Avec ces outils, le pharmacien se retrouve oblig deffectuer lui-mme un bon nombre
de tches qui normalement, avec ces solutions, doivent tre automatises, je cite comme
exemple envoyer des bons de commande vers le grossiste (fournisseur) : le pharmacien (agent
ou administrateur) cre un bon de commande avec une liste des produits demands ainsi que

Rapport du projet de fin dtudes

Page 16

HAMLI Marouane

leur quantits, ce bon devra tre transmis automatiquement vers un fournisseur parmi ceux
enregistrs dans la liste, aprs sa validation, cette option tait oprationnelle avant, mais
ncessitait une installation matrielle particulire (modems 56k..etc) qui ntait pas disponible
chez tous les partenaires, et a t abandonne plus tard, donc le pharmacien est oblig de
passer par la mthode classique qui est passer sa commande par tlphone. Les bons de
commande sont donc temporaires, et se trouvent dans la plupart des cas supprims aprs avoir
effectu la rception des produits.
Autre problme que le pharmacien rencontre, est quand lapplication plante, et quil
na plus accs certaines donnes, comme ce cas dont jtais tmoin lors de ma visite
lofficine du client, la liste des fournisseurs a t endommage et ntait plus accessible, ce
qui empchait dtablir des bons de commande ou effectuer des rceptions dans le logiciel,
ainsi les bons de livraisons des grossistes sentassaient les uns sur les autres, en attendant que
la service support du logiciel envoie un technicien pour rtablir la base de donnes. Ceci avait
dautres consquences, le pharmacien tait habitu faire une sauvegarde quotidienne de ses
transactions, cette sauvegarde ntait plus possible depuis que la liste des fournisseurs est
perdue, ce qui reprsente un grand risque pour ces donnes, surtout quil tait en priode de
garde et avait effectu plusieurs ventes et rceptions. En plus, les quantits des produits au
stock sont devenues toutes fausses.
Lditeur du logiciel proposait une assistance instantane, via un logiciel dassistance
distance, qui na pas t fourni tous ses clients, et la seule solution pratique tait denvoyer
les techniciens rparer les machines ne fonctionnant plus.
Rsultat : prs de 5 jours dattente, sans aucune sauvegarde, avec des donnes
errones, et encore faut-il du temps pour saisir toutes ces rceptions effectues pendant la
panne, aprs la rparation du logiciel.

2.3 Objectifs du projet


Le travail demand est dadapter un progiciel libre, OpenERP, aux besoins des
officines, en essayant de rajouter de nouvelles fonctionnalits que les autres solutions ne
peuvent offrir.
Afin de garantir une modernisation des services des officines, il est indispensable
dadopter les nouvelles technologies et les exploiter pour en tirer le meilleur profit.
Les PGI sont connus pour leur intgration des principales fonctions ncessaires la
gestion des flux et procdures de lentreprise (comptabilit, achats, ventes), tous ces outils
accdent des ressources communes, en particulier des bases de donnes.
Parmi les autres avantages des PGI, cest quils sont conus de telle sorte qu'un
"simple" paramtrage suffit les adapter l'organisation de l'entreprise. Il n'est normalement
pas ncessaire d'effectuer des dveloppements spcifiques, sauf en cas de ncessit, lorsque ce

Rapport du projet de fin dtudes

Page 17

HAMLI Marouane

paramtrage ne permet pas de prendre en compte des particularits lies au mtier des
officines.
Donc, le systme dinformation dvelopper aura pour objectifs :
-

Objectifs globaux :
o Disposer dun outil de gestion complet, qui contribuera lvolution des
officines
o Disposer dun outil dont le support ne ncessite pas trop de ressources, et qui
pourra communiquer avec dautres applications sans complication
Objectifs spcifiques :
o Permettre une gestion des lments de bases, comme les clients, patients,
mdecins et fournisseurs
o Permettre une vente au comptoir aise, avec une interface ergonomique qui
facilite la recherche des produits, et supporte plus quune mthode de
paiement.
o Permettre deffectuer des achats auprs des fournisseurs, o il est possible
dditer des devis, de crer 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 ltat des stocks nimporte quand.
o Permettre le suivi des clients, voir leur situation en tout moment, et rgler leur
crdit sils en ont.
o Enfin, avoir des statistiques concernant ces points cits auparavant

Rapport du projet de fin dtudes

Page 18

HAMLI Marouane

2.4 Conduite du projet


2.4.1 Processus du dveloppement

Introduction
La complexit croissante des systmes informatiques a conduit les concepteurs
sintresser aux mthodes. On a comptabilis en 1994 jusqu 50 mthodes. Chaque mthode
se dfinit par une notation et un processus spcifique. UML a ouvert le terrain en fusionnant
la notation. Il reste cependant dfinir le processus pour rellement capitaliser des rgles dans
le domaine du dveloppement logiciel. Les groupes de travail UML ont donc travaill
unifier non pas les processus, mais plus exactement les meilleures pratiques de
dveloppement objet. Ces processus ce distingueront par le gnrique UNIFIED
PROCESS .
Un processus dfinit une squence dtapes, en partie ordonn, qui concoure
lobtention dun systme logiciel ou lvolution dun systme existant. Pour produire des
logiciels de qualit, qui rpondent aux besoins des utilisateurs dans des temps et des cots
prvisibles. On dcoupe le processus en deux axes :
- Laxe de dveloppement technique, qui de concentre principalement sur la qualit de
production.
- Laxe de gestion du dveloppement, qui permet la mesure et la prvision des cots et
des dlais.

Choix de la mthodologie de conception


Avant dadopter une mthode, il faut dabord faire une comparaison entre les diffrentes
mthodes existantes, voir les points forts et les points faibles de chacune, puis dterminer
celle qui va mieux dans le contexte du projet.
Ci-dessous un tableau qui rsume cette comparaison (la liste est non exhaustive, voir la
page suivante)

Rapport du projet de fin dtudes

Page 19

HAMLI Marouane

Rational
Unified Process
(RUP)

Description
-Mthodologie centre
sur larchitecture et
couple
aux
diagrammes UML
-Concerne des projets
de +10 personnes
-Processus
complet
assist par des outils
exhaustifs

eXtreme
Programming
(XP)

-Dveloppement guid
par les besoins du client
-Equipes
rduites,
centres
sur
les
dveloppeurs

Two Track
Unified Process
(2TUP)

-Articul autour de
larchitecture
-Cycle
de
dveloppement en Y
-Convient aux projets de
toutes tailles

Points forts
-Itratif
-Spcifie le dialogue
entre les diffrents
intervenants du projet :
les livrables, plannings
et prototypes
-Propose des modles
de documents, et des
canevas
pour
des
projets types
-Rles bien dfinis,
modlisation
-Itratif
-Simple mettre en
uvre
-Laisse une large place
aux aspects techniques
-Builds journaliers
-Amlioration
constante
adaptation
aux modifications

-Itratif, laisse une


large partie la
technologie et la
gestion du risque
-Dfinit les profils des
intervenants,
les
livrables, les prototypes

Points faibles
-Coteux personnaliser
-Trs ax processus, au
dtriment
du
dveloppement
-Lourd, largement tendu, il
peut tre difficile mettre
en
uvre
de
faon
spcifique
-Convient pour les grands
projets
qui
gnrent
beaucoup de documentation
-Ne couvre pas les phases
en amont et en aval du
dveloppement
-Assez flou dans sa mise en
uvre : quels intervenants ?
Quels livrables ?
-Focalis
sur
laspect
individuel
du
dveloppement,
au
dtriment dune vue globale
et
des
pratiques
de
management
ou
de
formalisation.
-Superficiel sur les phases
en amont et en aval du
dveloppement
-Aucune proposition de
document type

Tableau 1 : Comparaison des mthodes de dveloppement

Pour atteindre les objectifs, jai suivi la mthode 2TUP (2Track Unified Process), qui sera
plus dtaille dans ce qui suit.

Rapport du projet de fin dtudes

Page 20

HAMLI Marouane

Cycle de vie du modle 2TUP


Le modle 2TUP repose sur cinq principes fondamentaux :
o Sparer les aspects fonctionnels et les aspects techniques
o Travailler selon deux points de vue qui se compltent et senrichissent mutuellement ;
celui de lentreprise, celui des applications.
o Modliser lactivit de lentreprise et des applications aux moyens dobjets en utilisant
UML.
o Faire des maquettes et des prototypes pour affiner les besoins fonctionnels et les
aspects techniques.
o Effectuer la ringnierie des applications dans le sens de la rutilisation.
Le schma suivant montre bien le cycle en Y caractristique de 2TUP.

Figure 4: Cycle de dveloppement en Y

Rapport du projet de fin dtudes

Page 21

HAMLI Marouane

2.4.2

Planification du projet
Le diagramme de GANT ci-dessous prsente les diffrentes tches ncessaires pour raliser le projet :

Figure 5: Planning du projet

Rapport du projet de fin dtudes

Page 22

HAMLI Marouane

Pour bien mener ce projet, je me suis dplac, dans un premier temps, lofficine du
client, afin de dcouvrir les diffrentes activits et processus mtier 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.
Aprs cette visite des lieux, je suis pass ltape suivante qui est de reformuler les
diffrents 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 cits correspondent ceux quil
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 dabord, puis comprendre
leur cot fonctionnel. Et comme OpenERP est crit en Python, combin XML pour gnrer
les diffrentes vues, jai eu lire quelques livres sur le dveloppement avec python, et aussi
avec le framework Open Object , ddi au dveloppement sous OpenERP.
Une fois familiaris un peu avec loutil, je suis pass crire quelques modules
simples pour sassurer que jai bien assimil sa technique de dveloppement, comme a je
pourrais me lancer dans la dcouverte fonctionnelle du PGI, car cest travers elle que je
dterminerai les modules dj existants et qui rpondent en partie aux exigences du client.
Cette dcouverte ma permis de fixer les fonctionnalits non existantes et qui devront tre
ajoutes, en plus du paramtrage mettre en place.
Aprs avoir cr les objets manquants, et aprs avoir paramtr lapplication, jai
commenc faire des simulations, afin de sassurer que le paramtrage suivi est le bon, et
aussi chercher si il y a des bugs dans le module que je viens de crer, ou dans les autres
modules auxquels il est li, puis je suis parti la recherche de solutions pour les diffrentes
anomalies dtectes.

Rapport du projet de fin dtudes

Page 23

HAMLI Marouane

Partie II : Etude fonctionnelle et technique


Chapitres :
-

Rapport du projet de fin dtudes

Page 24

Analyse et conception du projet


Technologies mises en uvre
Dveloppement du module officine

HAMLI Marouane

3 Chapitre III : Analyse et Conception du projet


3.1 Analyse du projet
Le but du projet est dadapter OpenERP pour quil puisse permettre une gestion
dofficine. Il est donc ncessaire de faire une visite des lieux, une pharmacie, afin de bien
cadrer son contexte, et de faire une liste des diffrentes fonctionnalits requises pour une telle
gestion, avant de dvelopper cette liste en un cahier des charges pour le valider avec le client.
Les fonctionnalits requises sont prsentes dans le tableau ci-dessous :
Objectif
Gestion de base

Vente au comptoir

Gestion des achats

Gestion des ventes

Gestion de stock

Statistiques

Fonctionnalits
Gestion des mdicaments
Gestion des clients
Gestion des fournisseurs
Gestion des patients
Gestion des mdecins
Grer les DCIs
Recherche de produits multicritre (nom, code ou code barre)
Paiement supportant diffrentes mthodes de paiement (espces,
chques, crdit, ou carte de crdit)
Impression du ticket de vente
Gestion de lordonnancier (vente sur ordonnance)
Consulter le journal du comptoir
Consulter la liste des fournisseurs
Crer des devis de fournisseurs
Crer des bons de commandes
Effectuer des rceptions de mdicaments
Suivi des rglements fournisseurs
Consulter la liste des clients
Gestion des avoirs clients
Suivi des rglements clients
Consulter le journal des ventes
Edition des devis
Consulter la liste de produit
Effectuer des inventaires physiques
Voir les mouvements de stock
Calcul des carts entre stock initial et stock actuel
Afficher le stock rel
Consulter les produits en stock dalerte (quantit insuffisante)
Distribution mensuelle des ventes par client
Distribution mensuelle des achats par fournisseur
Distribution dtaille des achats par produit / fournisseur
Distribution dtaille des ventes par produit / client
Tableau 2: Liste des fonctionnalits requises

Rapport du projet de fin dtudes

Page 25

HAMLI Marouane

3.2 Conception
Ltape de conception est trs importante pour la russite dun projet informatique car
elle vise dfinir une feuille de route du projet, le concevoir et le valider avant de passer au
dveloppement du systme. Elle permet aussi davoir une bonne rflexion avant de passer
laction, une bonne organisation du travail et une bonne communication entre les diffrents
intervenants dans le projet.
Jai utilis des diagrammes UML pour cette tape, vu quil est le plus appropri pour les
projets informatiques orients objet, et aussi car ses diagrammes facilitent la lisibilit et la
comprhension des modles mme pour les ceux qui sont loin du domaine informatique.
Le principal avantage d'UML est qu'il est devenu le standard en termes de modlisation
objet, son caractre polyvalent et performant et sa souplesse en fait un langage universel.
3.2.1 Diagramme des cas dutilisations :
Dans ce projet, jai six grands cas dutilisations, ces cas sont dtaills dans les
diagrammes suivants :
1. Gestion basique :

Diagramme 1: Gestion basique

La gestion basique veut dire lajout, modification et suppression des objets


lmentaires dans une officine, savoir les mdicaments, les fournisseurs, les clients, les
mdecins, les patients, les DCI (Dnomination Commune Internationale, nom du composant
chimique principal dun mdicament), les utilisateurs et leurs groupes.
Cette gestion est limite aux administrateurs, qui nauront la main pour effectuer leurs
modifications quaprs stre connect.

Rapport du projet de fin dtudes

Page 26

HAMLI Marouane

2. Vente au comptoir :

Diagramme 2: Vente au comptoir

La vente au comptoir est lactivit principale dans une officine, dans ce cas, un simple
agent, reoit la demande du client, ensuite recherche les mdicaments demandes, puis
renseigne les quantits de chaque produit, les ajoute la liste, comme il peut retirer des
produits de la liste, selon la demande du client, aprs il calcule le total du ticket, applique une
remise sil y en a et informe le client du montant.
Vient ensuite ltape du paiement, l le client dclare la mthode de paiement quil
souhaite, et lagent la choisit parmi sa liste de mthodes disponibles, si le client opte pour un
crdit, alors lordre de vente se transforme en facture ouverte au client jusqu son paiement.
Une fois pay, lagent livre les mdicaments au client, et peut lui imprimer le ticket de vente
et le lui remettre.
Si le client amne une ordonnance, lagent suit une procdure similaire celle dcrite cidessus, avec la particularit quil doit renseigner dans cette vente le nom du mdecin layant
tabli, en plus du patient qui elle est destine. Il est possible que dans cette vente se trouvent
des produits nayant pas de relations avec lordonnance, ce cas est connu comme vente
libre .

Rapport du projet de fin dtudes

Page 27

HAMLI Marouane

3. Gestion des achats :

Diagramme 3: Gestion des achats

La gestion des achats permet au pharmacien de se procurer des mdicaments auprs de


ses fournisseurs. Il lui est possible de crer des devis des grossistes, convertir ces devis en
bons de commande, choisir la mthode de facturation de ces derniers, et les valider. Une fois
ces bons valids, des rceptions de produits, correspondants chacune un bon de commande,
sont gnres automatiquement et passent au statut en attente de traitement . Le traitement
des rceptions peut tre partiel ou total, cest--dire que lors dune rception le pharmacien
peut recevoir la totalit des produits commands, traiter la rception et passer la facturation,
ou recevoir une partie des produits seulement, dans ce cas il ne renseigne que la quantit reue
et valide la rception, cette dernire est duplique, et le duplicata est une nouvelle rception
contenant le reste des produits recevoir, en statut en attente de traitement .
Aprs la rception des produits, le pharmacien passe la facturation des produits
reus, pour payer le fournisseur. Il pourra par la suite consulter les factures tablies et voir
leurs situations. Les factures payes sont crites dans le journal des achats.

Rapport du projet de fin dtudes

Page 28

HAMLI Marouane

4. Gestion des ventes :

Diagramme 4: Gestion des ventes

Les ventes se font toutes au niveau du point de vente, la gestion des ventes ici
concerne le suivi des clients qui se procurent des produits par crdit, car dans cette partie
lagent 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 crdits de chacun.
Cette gestion permet aussi de grer les avoirs, produits retourns par les clients pour
diffrentes 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 mdicaments.
Enfin, le pharmacien a la possibilit de consulter le journal des ventes, o se trouvent
les critures comptables des ventes par crdit.

Rapport du projet de fin dtudes

Page 29

HAMLI Marouane

5. Gestion du stock :

Diagramme 5 : Gestion du stock

La gestion du stock concerne la gestion des produits, o il est possible de voir la liste
de produits, voir les mouvements du stock, effectuer des inventaires physiques, voir ltat rel
du stock, et mme voir les carts entre stock actuel et stock initial.

6. Statistiques et alertes :

Rapport du projet de fin dtudes

Page 30

HAMLI Marouane

Diagramme 6: Cas d'utilisations - Statistiques et alertes

Ce volet est autour de tout ce qui est statistiques utiles pour le pharmacien, afin davoir
une ide 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 dtaille des
ventes ou achats.
Le pharmacien pourra consulter les produits en stock dalerte afin de pouvoir les
commander nouveau.
3.2.2 Diagramme des classes :
Le diagramme suivant est le diagramme de classes fonctionnel que jai ralis
avant de me lancer dans le dveloppement.

Rapport du projet de fin dtudes

Page 31

HAMLI Marouane

Diagramme 7: Diagramme des classes - fonctionnel

Ce diagramme reprsente les classes ncessaires pour assurer un bon fonctionnement du


systme mettre en uvre, les utilisateurs de lapplication sont regroups dans des groupes,
chaque groupe possdant des privilges qui permettent ses utilisateurs inscrits daccder
certaines fonctionnalits.
Les utilisateurs peuvent effectuer des achats de produits auprs des fournisseurs, chaque
achat se compose des lignes dachat, chacune de ces lignes contient un mdicament dsign,
avec la quantit acheter.
Un mdicament est li la classe DCI de deux faons : la premire concerne sa
composition, car un mdicament est compos dune ou plusieurs DCI, avec en gnral une
seule DCI connue, qui est sa composante principale. La deuxime liaison concerne les contreindications dun mdicament, qui ne sont autres que des DCI qui risquent de causer des
complications si elles sont combines ensemble.
Les mdicaments sont ensuite vendus au public, chaque vente, lie un utilisateur,
comporte des lignes de ventes, qui regroupent le mdicament vendu, sa quantit, sa remise, et
indique si elle fait partie dune ordonnance ou non. Si la ligne fait partie dune ordonnance
alors lutilisateur devra renseigner le nom du mdecin qui a crit cette dernire, en plus du
nom du patient concern.
Si le client souhaite payer par crdit, le vendeur devra renseigner dans ce cas le nom de
ce client, afin que le montant de cette vente sajoute son crdit.

Rapport du projet de fin dtudes

Page 32

HAMLI Marouane

Evidemment, des changements ont eu lieu sur ce diagramme, surtout aprs la recherche
des modules OpenERP existants qui rpondent en partie aux besoins du cahier des charges, ce
qui a impos ces modifications.

Rapport du projet de fin dtudes

Page 33

HAMLI Marouane

4 Chapitre IV : Technologies mises en uvre


Ce chapitre dcrit les diffrentes technologies adoptes par Nextma, et utilises pour la
ralisation de ce projet, commencer par le systme dexploitation Ubuntu, tout en passant
par le PGI OpenERP, le systme de gestion de bases de donnes PostgreSQL, et en fin les
langages ncessaires pour le dveloppement, savoir le langage Python et XML.

4.1 Ubuntu
Ubuntu est un systme dexploitation libre commandit par la socit Canonical et une
marque dpose par cette mme socit.
Fond sur la distribution Linux Debian et utilisant le bureau Unity, Ubuntu se veut
convivial, intuitif et sr . Il est constitu de logiciels libres, est disponible gratuitement y
compris pour les entreprises, et bnficie d'une nouvelle version (appele mise niveau )
tous les six mois.
Avec une utilisation globale estime plus de 25 millions d'utilisateurs, il est
principalement conu pour une utilisation sur des ordinateurs personnels (portables et fixes),
bien que d'autres versions consacres aux netbooks et aux serveurs existent aussi. Depuis
Ubuntu 11.04, la version Netbook a fusionn avec la version Desktop. Cette dernire tant
passe l'interface Unity, il n'y avait plus de raison de maintenir deux branches distinctes.

Figure 6: Interface d'Ubuntu 11.10

La version dUbuntu utilise pour ce projet est la 11.10, ayant pour nom de code The
Oneiric Ocelot , cette version est la quinzime version d'Ubuntu. Son dveloppement s'est
chelonn sur six mois, jusqu' sa publication en tant que version stable le 13 octobre 2011.

Rapport du projet de fin dtudes

Page 34

HAMLI Marouane

Elle profitera des mises jour de scurit pendant une dure de 18 mois, soit jusqu'en avril
2013.

4.2 PostgreSQL
PostgreSQL est un systme de gestion de base de donnes relationnelle et objet
(SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD.
Ce systme est concurrent d'autres systmes de gestion de base de donnes, qu'ils
soient libres (comme MySQL et Firebird), ou propritaires (comme Oracle, Sybase, DB2,
Informix et Microsoft SQL Server). Comme les projets libres Apache et Linux, PostgreSQL
n'est pas contrl par une seule entreprise, mais est fond sur une communaut mondiale de
dveloppeurs et d'entreprises.
PostgreSQL peut stocker plus de types de donnes que les types traditionnels entier,
caractres, etc. L'utilisateur peut crer des types, des fonctions, utiliser l'hritage 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 matrielles et sous diffrents systmes 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 systme d'exploitation.
PostgreSQL est largement reconnu pour son comportement stable, proche de Oracle.
Mais aussi pour ses possibilits de programmation tendues, directement dans le moteur de la
base de donnes, via PL/pgSQL. Le traitement interne des donnes peut aussi tre coupl
d'autres modules externes compils dans d'autres langages.

Rapport du projet de fin dtudes

Page 35

HAMLI Marouane

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

Figure 8 : Interface Web d'OpenERP

Le logiciel est bas sur une forte architecture MVC, des flux de travail flexibles, une
interface-utilisateur graphique dynamique, une interface XML-RPC, et un systme
personnalisable de comptes-rendus avec une intgration 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
ncessaires se faisant par paramtrage.
Il dispose de forts arguments commerciaux pour sduire les dirigeants (il propose de
mettre un terme au dsordre du systme dinformation, et aussi de rgler des problmes
dorganisation sans effort politique). Cette offre sduisante par sa qualit et sa cohrence se
rvle lusage plus risque que lon avait pu limaginer : elle ne peut tre efficace que si lon
accepte les contraintes quelle impose. Sa mise en uvre comporte des difficults et des
piges.
Implanter un PGI a ses avantages, parmi lesquels je cite :
o Optimisation des processus de gestion
o Cohrence et homognit des informations
o Intgrit et unicit du Systme dinformation

Rapport du projet de fin dtudes

Page 36

HAMLI Marouane

o Mise disposition dun outil multilingue et multidevises (trs adapt aux


multi-nationales)
o Communication interne et externe facilite par le partage du mme systme
dinformation
o Meilleure coordination des services et donc meilleur suivi des processus
(meilleur suivi de commande ou meilleure matrise des stocks par exemple)
o Normalisation de la gestion des ressources humaines (pour les entreprises
grant de nombreuses entits parfois gographiquement disperses)
o Minimisation des cots (formation et maintenance)
o Matrise des cots et des dlais de mise en uvre et de dploiement
o Mise disposition, des cadres suprieurs, dindicateurs nettement plus fiables
que lorsquils taient extraits de plusieurs systmes diffrents
Toutefois, cela peut avoir quelques inconvnients, comme la lourdeur et la rigidit de
la mise en uvre, ou encore les difficults dappropriation par le personnel de lentreprise.
OpenERP comporte plusieurs modules fonctionnels, je cite les exemples suivants :
o
o
o
o
o
o
o
o
o
o
o
o

CRM ; gestion de la relation client


Comptabilit analytique et financire (Conforme aux exigences franaises)
Gestion des stocks
Gestion de production (GPAO)
Gestion de projets et des activits de services
Norme qualit : ISO 9001 version 2000
Gestion des ventes
Gestion des achats
Marketing
Logistique
Ressources humaines
Gestion documentaire

Cot architecture, OpenERP est bas sur une architecture 3 tiers:


1. Un serveur de base de donnes PostgreSQL (qui peut contenir plusieurs bases
de donnes)
2. Un serveur d'applications (contenant les objets de gestion, le moteur de
workflow, le gnrateur d'dition, etc.)
3. Un serveur de prsentation (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
ncessaire si l'utilisateur utilise le client lourd mais qui ncessitera une
installation physique sur le poste de l'utilisateur (cette application se nomme
Client GTK).

Rapport du projet de fin dtudes

Page 37

HAMLI Marouane

Figure 9: Architecture d'OpenERP

Ses fonctions de veille conomique intgres permettent des utilisateurs multiples de


traiter tous les aspects du logiciel. Ainsi, les rapports et les flux de travail peuvent tre
personnaliss.
La partie serveur est crite en langage Python. Les diffrentes briques sont organises
en modules. Un module est un dossier avec une structure pr-dfinie contenant du code
Python et des fichiers XML. Un module dfinit la structure de donnes, formulaires, rapports,
menus, procdures, flux de travail, etc.
Le client est lger 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 dfaut 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 diffrences 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 dOpenERP qui ma t conseille pour lutiliser est la 6.1,
parue en fvrier 2012, cette version comporte plusieurs nouveauts :
-

Un meilleur partage des informations : Des fonctionnalits de partage des


informations des tiers ont t ajoutes. Il est par exemple possible de permettre
l'accs aux donnes 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'intgrer n'importe quelle partie de
l'interface d'OpenERP site Web tiers.

Rapport du projet de fin dtudes

Page 38

HAMLI Marouane

Fonctions d'changes EDI : Des fonctions d'change de donnes informatis font leur
apparition, permettant un partenaire d'importer des donnes (par exemple une
facture) le concernant dans son propre systme OpenERP ou progiciel tiers (au format
JSON), et mme d'effectuer le paiement en ligne.
Une interface mobile : Une nouvelle interface conue pour l'utilisation sur les
terminaux mobiles de type smartphone fait son apparition. Base sur le framework
JQuery Mobile, elle ne permet pour l'instant que la consultation en lecture seule des
informations.
Une interface destine aux points de ventes : Une nouvelle interface ddie aux points
de ventes cran tactiles, tablettes et autre dispositifs de caisse interactifs est
inaugure dans cette version d'OpenERP. Cette fonctionnalit trs demande permet
d'utliser un lecteur de codes barres, de slectionner des produits par catgorie/sous
catgorie, la recherche par nom de produits et peut fonctionner hors-ligne et se
synchroniser automatiquement lorsque la connexion avec le serveur est rtablie.

Et ce ne sont pas que les nouveauts qua apport cette version, mais aussi des
amliorations :
o Une configuration plus simple : De nouveaux boutons de raccourcis font leur
apparition, permettant de crer plus intuitivement de nouveaux documents et
de nouveaux enregistrements directement partir de leur saisie dans les
champs de donnes. De mme, une installation frache d'OpenERP inclut
dornavant une configuration minimale des modules, base sur les bonnes
pratiques et les utilisations les plus courantes observes chez les utilisateurs.
o Un effort sur l'utilisabilit : L'installateur et l'assistant de configuration ont t
repenss afin de faciliter la comprhension par les nouveaux utilisateurs, en
demandant moins de dtails sur la socit grer et en se focalisant sur les
informations absolument ncessaires. La page d'installation des modules
propose par dfaut une installation sous forme de thmes . Par exemple, un
clic sur le thme Ventes installera tous les modules ncessaires la gestion
des ventes, et vous dirigera ensuite automatiquement vers ce module configur
et prt l'emploi.
o Importation des donnes facilite : L'importation des donnes dans OpenERP
partir de sources tierces a t amliore. En effet, un assistant fait son
apparition permettant de facilement faire correspondre un fichier de donnes
au format csv au schma de donnes OpenERP. noter aussi lexistence de
fonctions d'importation automatise des donnes depuis SugarCRM et Google
Calendar.
o Sous-systme de courriels unifi : La configuration des paramtres de
connexions pour l'envoi et la rception de courriels est maintenant unifie, ce
qui met fin la duplication des configurations pour les modules tirant partie de
ces fonctions de courriels.

Rapport du projet de fin dtudes

Page 39

HAMLI Marouane

o Refonte du module de paie : Le module de gestion de paie a t repens, afin


d'tre plus flexible et s'adapter ainsi plus aisment aux spcificits de chaque
pays et de chaque entreprise.
o R-criture de l'interface Web : L'interface Web d'OpenERP a t entirement
r-crite et fait dornavant la part belle la technologie Javascript, sans non
plus bouleverser son apparence et l'exprience utilisateur. Parmi les
consquences, on peut noter qu'elle offre plus de fonctionnalits avec moins de
code, et est plus rapide que l'ancienne implmentation de la 6.0. Au niveau des
amliorations se trouve aussi la possibilit de personnaliser les tableaux de
bord directement depuis l'interface avec de simples glisser-dposer, ainsi que
l'arrive d'une nouvelle forme de prsentation des donnes, 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
implmentation extrmement robuste d'OpenERP sur les serveurs, un bien
meilleur contrle de l'assignation des ressources matrielles et une
simplification de la mise en place de mcanismes de rplication et de
rpartition de charge (les serveurs d'applications proposant souvent de telles
fonctionnalits).

4.4 Python

Python est un langage de programmation multi-paradigme. Il favorise la


programmation imprative structure, et oriente objet. Il est dot d'un typage dynamique fort,
d'une gestion automatique de la mmoire par ramasse-miettes et d'un systme 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 conu pour optimiser la productivit des programmeurs en offrant des
outils de haut niveau et une syntaxe simple utiliser. Il est galement apprci par les
pdagogues qui y trouvent un langage o la syntaxe, clairement spare des mcanismes de
bas niveau, permet une initiation plus aise aux concepts de base de la programmation.
Python est un langage :

Rapport du projet de fin dtudes

Page 40

HAMLI Marouane

o conu pour produire du code de qualit, portable et facile intgrer : grce


sa syntaxe claire, cohrente et concise, Python permet aux dveloppeurs de
produire du code de qualit, lisible et maintenable. crire du code Python est
un exercice agrable, mme en respectant les conventions de codage.
Fourni ds le dpart avec des modules de tests, Python est un langage agile. Le
terme agile est originellement issu de la mthodologie de programmation agile
(Beck et Al.), trs proche de la programmation itrative. Cette mthodologie,
qui rduit les risques lis la conception de logiciels, introduit entre autres des
principes de tests continus du code.
o De haut niveau, orient objet et totalement libre : mme si elle nest pas
impose, Python permet la programmation oriente objet. Tous les mcanismes
objet essentiels sont implments et toutes les donnes manipules 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 linterprteur. Ce dcoupage, permet dorganiser le code et
son utilisation par des espaces de noms, et aussi de faciliter lextension du
langage par des bibliothques tierces compiles dans dautres langages.
o Hautement productif : La conception dapplications en Python est trs rapide
car certains aspects de programmation sont grs automatiquement, comme la
gestion des ressources mmoire et le typage des donnes.
Grce des types de base trs puissants et des primitives de haut niveau, un
programme Python est simple concevoir et concis. Un programme Python est
en gnral 3 5 fois plus court quun programme C++ quivalent. Ces qualits
font de Python un langage idal dans beaucoup de domaines.
Enfin, la bibliothque standard de Python est trs complte, et permet de
rpondre aux besoins communs de programmation.
Grce au modle Open Source, la communaut des dveloppeurs Python est en
outre trs productive et de nombreuses extensions gravitent autour du langage.
o Dynamique : dans la plupart des implmentations, le code source nest pas
compil contrairement des langages comme C ou Pascal, mais excut la
vole. On parle alors de langage interprt.
Ce mode de fonctionnement rend la programmation beaucoup plus souple
puisquil est possible de changer un programme en cours dexcution, ou de
tester du code en mode interactif sans disposition particulire.
Linterprtation rend aussi lexcution plus lente, mais ce dfaut est
surmontable grce de bonnes pratiques de programmation et des techniques
doptimisation.

Rapport du projet de fin dtudes

Page 41

HAMLI Marouane

4.5 XML
XML (eXtensible Markup Language) est en quelque sorte un langage HTML amlior
permettant de dfinir de nouvelles balises. Il s'agit effectivement d'un langage permettant de
mettre en forme des documents grce des balises (markup).
Contrairement HTML, qui est considrer comme un langage dfini et fig (avec un
nombre de balises limit), XML peut tre considr comme un mtalangage permettant de
dfinir d'autres langages, c'est--dire dfinir de nouvelles balises permettant de dcrire la
prsentation d'un texte (Qui n'a jamais dsir une balise qui n'existait pas ?).
La force de XML rside dans sa capacit pouvoir dcrire n'importe quel domaine de
donnes grce son extensibilit. Il va permettre de structurer, poser le vocabulaire et la
syntaxe des donnes qu'il va contenir.
En ralit les balises XML dcrivent le contenu plutt que la prsentation
(contrairement HTML). Ainsi,XML permet de sparer le contenu de la prsentation, ce qui
permet par exemple d'afficher un mme document sur des applications ou des priphriques
diffrents sans pour autant ncessiter de crer autant de versions du document que l'on
ncessite de reprsentations !
XML a t mis au point par le XML Working Group sous l'gide du World Wide Web
Consortium (W3C) ds 1996. Depuis le 10 fvrier 1998, les spcifications XML 1.0 ont t
reconnues comme recommandations par le W3C, ce qui en fait un langage reconnu. (Tous les
documents lis la norme XML sont consultables et tlchargeables sur le site web du
W3C, http://www.w3.org/XML/)
XML est un sous ensemble de SGML (Standard Generalized Markup Language),
dfini par le standard ISO8879 en 1986, utilis dans le milieu de la Gestion Electronique
Documentaire (GED). XML reprend la majeure partie des fonctionnalits 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 reprsents les diffrents objets sont crites en XML, ainsi nous y trouvons la description
dtaille de laffichage des arbres, formulaires, menus et autres actions.

Rapport du projet de fin dtudes

Page 42

HAMLI Marouane

5 Chapitre IV : Dveloppement du module


officine
Dans ce chapitre, je prsente les modules existants dans OpenERP et qui rpondent
partiellement aux besoins requis dans le cahier des charges, pour ensuite limiter les
fonctionnalits restantes mettre en uvre.
Une fois le dveloppement termin, il ne reste que le paramtrage faire, pour assurer
un bon fonctionnement du systme.

5.1 Analyse fonctionnelle des modules OpenERP


Avant de commencer ltape du dveloppement, il ma fallut dabord chercher parmi
les modules existants sous OpenERP, ceux qui offrent des fonctionnalits exiges
prcdemment dans le cahier des charges fonctionnel. Aprs une analyse des diffrents
modules, je peux dcrire les modules utiles mon systme comme suit :
Module
Gestion de
base

Nom
technique
base

Gestion de
Stock

stock

Gestion des
ventes

sale

Description

Fonctionnalits

Ce module est en fait le noyau Gestion des :


dOpenERP, il est ncessaire pour
- Clients
toute installation de nouveau
- Workflow
module.
- Devises de monnaie
En effet, dans ce module sont
- Langues
dfinis les objets de base, qui sont
- Pays
essentiels
pour
le
bon
- Scurit de base
fonctionnement du PGI
Ce module sert de base pour la
- Gestion d'entrept
gestion de/des entrept(s) dune
- Les bons de livraison
entreprise dans OpenERP
- Traabilit
- Produits
- Rgles du Stock
- Reporting
Permet la gestion des ventes et Gestion
et
suivi
des
leur facturation.
achats/ventes pour produits
stockable/services.
Relances.
Gestion des listes de prix.
Cration automatique des
bons de livraison.
Facturation partir des
livraisons.
Calcul automatique des prix
en fonction des quantits et
des dlais de livraison.
Proposition automatique de
rapprovisionnement.
Gestion des ristournes et
promotions.
Gestion
des
livraisons
partielles
et
retours
fournisseurs.

Rapport du projet de fin dtudes

Page 43

HAMLI Marouane

Gestion des incoterms.

Gestion des
achats

purchase

Ce module concerne tout ce qui est


en relation avec lachat de
produits

Comptabilit

account

Ce
module
concerne
comptabilit dans lentreprise.

Comptabilit
& finance

Account_acco
untant

Paiement

Account_vouc
her

Point de vente

Point_of_sale

Ce
module
permet

ladministrateur daccder toutes


les options de la comptabilit
comme les journaux et le plan
comptable
Ce module est utilis pour Rajoute le bouton paiement
effectuer
le
paiement
des aux factures des clients et des
diffrentes factures tablies
fournisseurs pour pouvoir effectuer
les paiements
Ce
module,
qui
a
t
- Gestion des ventes
compltement rnov, permet
- Analyse des caisses
davoir un point de vente et de
- Analyse du point de vente
vendre des produits dans une
- Configuration
des
approche plus sociale que la vente mthodes de paiement
des produits classiques dans
- Configuration des caisses
OpenERP.
- Inscription des ventes dans
Le point de vente tactile OpenERP les journaux
permet de grer les ventes dans
une boutique trs facilement. Il est
entirement bas sur le Web et ne
ncessite aucune installation ou
dploiement de logiciel tiers et
tous les commerces de vente
peuvent
tre
facilement
consolids. Il fonctionne en mode
connect et dconnect de sorte
quon puisse continuer vendre si
on nest plus connect Internet.

la

Demande de devis
Les commandes d'achat
Carnet d'adresses
Contrle des stocks
Contrle de facture
- Ecritures dans journaux
avec
automatisation
des
contreparties.
- Gnration
automatique
des pices comptables.
- Automatisation complte :
calculs de TVA, date d'chance,
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 rsultat, dclaration TVA
- Gestion budgtaire.
- Gestion des journaux
- Gestion des registres de
caisse

Tableau 3: Description des modules OpenERP en relation avec l'officine

Rapport du projet de fin dtudes

Page 44

HAMLI Marouane

Malgr la varit de fonctionnalits satisfaites par ces modules, il reste crer certains
objets qui nexistent pas encore sur OpenERP, en crant un nouveau module qui les
regroupera, le schma suivant montre comment seront intgrs ces modules lists ci-dessus et
comment ils seront lis avec le nouveau module que je vais crer :

Point_of_sale

Account_ac
countant

Purchase

Account_vo
ucher

Officine

Base

Sale

Account

Stock

Figure 10 : Dpendences du module officine

Rapport du projet de fin dtudes

Page 45

HAMLI Marouane

5.2 Module Officine


Aprs avoir analys les diffrents modules, jai constat quil faut crer les objets
suivants :
-

Mdecin : cet objet est ncessaire dans le cas dune vente par ordonnance, car
il faut renseigner le nom du mdecin qui la tablit
Patient
DCI : Dnomination Commune Internationale , reprsente le nom du
composant chimique dun mdicament, ici au Maroc la DCI joue un rle
secondaire pour dterminer les produits car on se base sur leur nom
commercial.

Ces nouveaux objets sont regroups dans un nouveau module ajouter, qui nest autre
que officine . Le module est un dossier compos de fichiers python (.py) contenants les
dfinitions des classes et dautres XML contenants les dtails des vues de ces dernires, en
plus de certains dossiers comme les wizards (assistants se lanant dans certaines conditions)
ou report (contient les modles de rapport du module).
En plus jai eu tendre certains objets dj crs pour quils rpondent aux besoins, ces
objets sont :
-

Produit : ajout des attributs propres au mdicament la classe produit, comme


la posologie, la/les DCIs composant le produit (un mdicament peut se
composer de plusieurs DCI, mais seul une est considre principale), ainsi que
les DCIs listes comme contre indication.
Ligne de vente : ajout dun attribut ordonnance afin de prciser si la ligne
fait partie dune ordonnance ou non, car aprs discussion avec le client, il sest
avr quil est possible de faire une vente sur ordonnance en plus dautres
produits non prescrits dans cette dernire, tout ceci en une seule vente.
Ordre de vente : cette classe dj cre par le module point de vente, ncessite
davoir des liens avec un mdecin et un patient, lorsquon souhaite raliser une
vente sur ordonnance, car il faudra dans ce cas renseigner le nom du mdecin
ayant tabli lordonnance, et le patient laquelle elle est destine. Je lui ai
ajout aussi un champ qui calcul le montant total des produits achets sur
ordonnance.

Aprs avoir cr et tendu les classes cites ci-dessus (voir lannexe A qui contient des
dtails quant au dveloppement de classes avec le framework Open Object ), il fallait
passer crer les vues pour les reprsenter graphiquement et les utiliser, les vues sont des
fichiers XML dans lesquelles on dfinit la structure daffichage des nouveaux objets crs, et
on peut aussi hriter des vues dj existantes, et soit les modifier, ou y ajouter de nouveaux
champs afficher.
Lavantage de coder ces nouveaux objets sous Open Object rside dans le fait quil
suffit de renseigner une nouvelle classe, mentionner ses attributs, pour quensuite Open
Object lui cre une table dans la base de donnes et lui associe ses mthodes lmentaires

Rapport du projet de fin dtudes

Page 46

HAMLI Marouane

(ajout, modification, suppression), les mthodes spcifiques une classe doivent tre crites
dans cette dernire.
Aprs la cration des diffrentes classes nouvelles et classes filles, nous devons crer
deux fichiers spciaux pour OpenERP afin de pouvoir installer le module. Le premier fichier
est __init__.py o on importe tous les fichiers python quil nous faut pour faire
fonctionner le module. Le deuxime 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 lauteur, les noms des modules auxquels il dpend, et les fichiers des
vues XML inclure pour pouvoir afficher nos objets crs ou tendus.

5.3 Installation
Maintenant que le codage est termin, on peut passer linstallation du module
officine , qui installera dabord les modules auxquels il est li, ensuite ajoutera ses propres
fonctionnalits.
Avant de lancer le serveur dOpenERP, on doit copier le dossier du module officine
dans le dossier Addons dOpenERP, ensuite on lance le serveur (fichier openerpserver.py), et nous pourrons ce stade, installer notre nouveau module.
Bien videmment, on doit dabord se connecter puis accder aux paramtres.

Figure 11: Connexion

Rapport du projet de fin dtudes

Page 47

HAMLI Marouane

Figure 12: Accueil OpenERP - client web

Une fois connect, on se rend aux paramtres, puis dans le menu modules, on lance
une mise jour de la liste des modules, afin quon puisse trouver celui quon vient dajouter
parmi la liste, l on lance linstallation du module officine.

Figure 13: Liste des modules OpenERP

5.4 Paramtrage
Maintenant que jai install mon module, je peux commencer paramtrer le PGI et
dmarrer une simulation pour sassurer de son bon fonctionnement.
5.4.1 Gnral
Avant de se lancer dans le paramtrage de lapplication, je commence par un
paramtrage gnral, o il faut saisir le nom de lofficine, son adresse, et autres coordonnes

Rapport du projet de fin dtudes

Page 48

HAMLI Marouane

(compte bancaire), aussi il faut changer la devise vers le Dirham, pour que les prix et les
factures soient bien affichs ultrieurement, selon le contexte marocain.
5.4.2 Plan comptable
Toute application fonctionnant sous OpenERP, il faut spcifier un plan comptable
utiliser pour la gnration des diffrentes critures comptables et journaux de comptabilit.
Pour le plan comptable de ce projet, jai choisi le plan comptable gnral dOpenERP
par dfaut pour enregistrer les diffrentes critures comptables dans leurs journaux respectifs,
en raison de sa simplicit dutilisation. Il existe bien sr un plan comptable marocain pour
OpenERP, mais il y a eu beaucoup derreur lors des tests avec ce dernier, ce qui ma pouss
revenir vers le plan par dfaut.
5.4.3 Produit
Les produits contiennent un bon nombre dattributs qui facilitent le paramtrage, ainsi
jai utilis les attributs suivants :
Attribut
Name
reference
Ean13
Categ_id
Standard_price
List_price
State
Pos_categ_id
posologie
Dcis
Cis

Fonction
Nom du produit
Code du produit
Code barre du produit
Catgorie du produit, utile pour le calcul de son prix public sur la base de
liste de prix
Prix dachat
Prix public
Etat du produit
Forme du produit, utile pour le classement des produits dans le point de
vente, ce qui facilite leur recherche
Posologie du produit
Liste des DCIs du produit
Liste des contre indications du produit
Tableau 4 : attributs du produit

5.4.4 Mthodes de paiements :


Avant de pouvoir passer au point de vente, il faut dabord configurer les mthodes de
paiements quon souhaite mettre disposition, puis ensuite ouvrir les caisses, on peut ouvrir
toutes les caisses la fois, ou choisir douvrir que quelques unes, dans le cas o il nest pas
possible deffectuer un certain type de paiement, du une panne matrielle par exemple.
Pour crer les mthodes de paiements il faut se connecter en tant quadministrateur puis
se rendre au backend du point de vente, l on pourra configurer les mthodes de paiement
quil nous faut.
Une mthode de paiement est caractrise par : (voir la page suivante)

Rapport du projet de fin dtudes

Page 49

HAMLI Marouane

Attribut
Name
Code
Type
Default_credit_account_id
Default_debit_account_id
View_id

Fonction
Nom de la mthode
Code de la mthode
Type sur lequelle se base la mthode : liquidit, ventes, banques et
chques
Indique le journal de crdit utilis pour cette mthode
Indique le journal de dbit utilis par dfaut
Indique la vue utiliser pour afficher les entres dans le journal
Tableau 5: Attributs de la mthode de paiement

Rapport du projet de fin dtudes

Page 50

HAMLI Marouane

5.5 Simulation
Dans cette partie je prsente quelques captures dcran de lapplication pour montrer les
fonctionnalits quelle offre. Les captures ci-dessous ont t faites sur une nouvelle base de
donnes, avec un produit exemple. Je travaille maintenant sur limportation dune liste de
produits fournie par le client cette base pour ensuite livrer une base de donnes complte, ne
ncessitant ni nouveau paramtrage ni nouvelle importation de donnes.
5.5.1 Gestion de base
La gestion de base concerne les objets lmentaires, comme les utilisateurs, les
produits, les mdecins

Figure 14: Gestion des utilisateurs

Figure 15: Gestion des groupes

Rapport du projet de fin dtudes

Page 51

HAMLI Marouane

Figure 16: Liste des mdecins

Pour faciliter lutilisation de lapplication, des info-bulles saffichent lorsquon survole


les champs, fournissant des explications concernant la fonction du champ pour aider bien le
renseigner.

Figure 17: Formulaire mdecin

Figure 18:Formulaire patient

Rapport du projet de fin dtudes

Page 52

HAMLI Marouane

5.5.2 Gestion des achats


Les figures suivantes montrent la gestion des achats, qui comprend ldition et validation
de bons de commande, effectuer des rceptions de produit.

Figure 19: Bons de commande fournisseur

En crant un bon de commande, on slectionne un fournisseur auquel il est adress,


ensuite on ajoute les produits quon souhaite commander auprs de lui, on peut aussi choisir
la mthode de facturation si elle doit tre base sur le bon de commande ou sur les rceptions
des produits.
Les rceptions peuvent se faire sur bons de commande, ou tout simplement sans origine.
Si une rception est base sur un bon de commande valid, et quelle contient une quantit
infrieure celle demande, la rception est duplique, avec comme origine le mme bon de
commande, mais cette fois elle contient la diffrence entre la quantit demande et celle
reue.

Rapport du projet de fin dtudes

Page 53

HAMLI Marouane

Figure 20: Liste des rceptions

5.5.3 Gestion des ventes


Dans ce volet nous pouvons consulter la liste des clients, voir les dtails 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 crdit de ce client, comme il nous est possible dafficher ses
factures, bons de commandes ou chiffre daffaire mensuel.

Rapport du projet de fin dtudes

Page 54

HAMLI Marouane

5.5.4 Gestion du stock


Dans cette partie on trouve tout ce qui concerne la gestion des produits, les inventaires
physiques par exemple :

Figure 22: Gestion des inventaires physiques

On peut aussi voir le mouvement de stocks en cliquant sur le menu mouvements de


stocks :

Figure 23: Liste des mouvements de stock

On peut aussi dfinir les rgles de stock minimum des produits, condition quon ait
spcifi le fournisseur dans la fiche du produit, pour quensuite ds quun produit franchit la
limite dfinie, un bon de commande est automatiquement cr et est envoy au fournisseur
quand le planificateur est lanc.

Rapport du projet de fin dtudes

Page 55

HAMLI Marouane

Figure 24: Liste des rgles de stock minimum

Le formulaire du produit, aprs extension, devient comme le montre la figure suivante

Figure 25: Formulaire produit I

Rapport du projet de fin dtudes

Page 56

HAMLI Marouane

Figure 26: Formulaire produit - II

Quand la quantit dun produit descend en dessous de celle dfinie dans les rgles de
stock minimum (par dfaut 0), le produit saffiche en rouge dans la liste des produits, voir la
figure ci-dessous.

Figure 27: Produit en stock d'alerte

Il nous est possible de faire une analyse des mouvements de stocks, on peut aussi
personnaliser cette analyse, en y ajoutant quelques filtres et groupements.

Figure 28: Analyse des mouvements de stocks

Rapport du projet de fin dtudes

Page 57

HAMLI Marouane

5.5.5 Comptabilit
Ce module concerne tout ce qui est facture, paiements et critures dans les journaux.

Figure 29: Liste des factures clients

A travers ce module nous pouvons suivre de prs les rglements de factures des
clients, voir les factures qui nont pas encore t valids, comptabiliser les factures payes

Figure 30: Dtails facture client

Ces factures client sont utiles lorsquon effectue une vente par crdit, car la facture reste
ouverte tant quelle nest pas paye, son montant sajoute au crdit du client concern, et ne
sera comptabilise quaprs son paiement.

Rapport du projet de fin dtudes

Page 58

HAMLI Marouane

Figure 31: Paiements clients

OpenERP considre les clients et fournisseurs comme tant une seule entit : partenaire,
avec un attribut qui dsigne si ce dernier est client ou fournisseur, donc les factures et
paiements pour les fournisseurs ont la mme prsentation que celle des clients.
Autres fonctionnalits possibles dans ce module, cest la gestion des mthodes de
paiements, diffrents journaux de comptabilits, on peut mme changer de plan comptable et
utiliser un autre.
Ce volet de comptabilits offre aussi la possibilit de gnrer des rapports et des analyses
des critures comptables, journaux et factures, comme le grand livre ou le bilan, il offre aussi
une analyse gnrale de la socit, donnant ainsi des ides plus claires sur la situation
financire de lofficine.

Rapport du projet de fin dtudes

Page 59

HAMLI Marouane

5.5.6 Point de vente


La version 6.1 dOpenERP a apport de grands changements pour le module du point de
vente, rsultant en une meilleure ergonomie et une grande interactivit et support des
diffrents outils communs dans les petits commerces.

Figure 32: Point de vente

Cette nouvelle interface, compltement crite en javascript, offre plusieurs faons 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 mdicament.
Elle permet deffectuer plusieurs types de paiements la fois, comme payer la moiti
dun ticket en espces, lautre moiti avec une carte de crdit

Figure 33: Paiement en espces

Rapport du projet de fin dtudes

Page 60

HAMLI Marouane

Le lancement du point de vente vrifie sil existe des mthodes de paiement enregistres,
ensuite il vrifie sil y a des caisses bases sur ces mthodes qui sont ouvertes, le cas chant
un assistant demande si on souhaite ouvrir les caisses, si on confirme, de nouvelles caisses
sont cres, et nous pouvons nous lancer dans la vente.

Figure 34: Assistant d'ouverture des caisses

Si aucune mthode de paiement nest enregistre, on ne pourra pas effectuer de ventes,


nous aurons donc retourner au backend pour crer les mthodes qui nous conviennent.

Figure 35: Liste des mthodes de paiement

Figure 36: Formulaire de cration/modification d'une mthode de paiement

Rapport du projet de fin dtudes

Page 61

HAMLI Marouane

Une fois nos mthodes dfinies, nous pouvons ouvrir les caisses automatiquement
laide de lassistant, nous aurons dans ce cas de nouvelles caisses vides, chacune
correspondante une mthode de paiement dj enregistre, sinon nous pouvons les crer
manuellement et les ouvrir ensuite.

Figure 37: Liste des caisses

Une des fonctionnalits ajoutes ce module est lordonnancier, o on effectue des


ventes sur ordonnance, pour y accder, il faut aller dans le backend du point de vente, puis
crer une nouvelle vente.

Figure 38: Journal des ventes

Figure 39: Ordre de vente

Rapport du projet de fin dtudes

Page 62

HAMLI Marouane

Longlet ordonnance ajout, permet de renseigner le nom du mdecin ayant rdig


lordonnance, ainsi que le patient qui elle est destine. Les lignes de vente peuvent
correspondre lordonnance elle-mme, ou seulement des lignes de vente libre . Ce qui
explique lajout dune case cocher si la ligne correspond une ordonnance ou non, et lajout
du champ total ordonnance qui calcule le total des lignes dordonnance.

Figure 40: Renseignement des informations d'ordonnance

Les produits dans le point de vente sont classs par catgorie, ce qui facilite leur
recherche. Une catgorie du point de vente peut avoir une catgorie mre, on obtient donc une
hirarchie de catgorie.

Figure 41: Catgories des produits - point de vente

Le module point de vente offre aussi des statistiques et des analyses concernant ses
ventes.

Rapport du projet de fin dtudes

Page 63

HAMLI Marouane

Figure 42: Analyse du point de vente par produit

Il est aussi possible de voir ces analyses par utilisateur :

Figure 43: Analyse des enregistreuses par utilisateur

5.6 Problmes rencontrs


Lors de la simulation, quelques bugs ont t rencontrs, comme par exemple la recherche
multi critre des mdicaments dans le point de vente o seule la recherche par nom tait
possible.
Aprs plusieurs lectures et relectures du code, et aprs plusieurs recherches sur internet,
notamment sur le launchpad, site o la communaut des chercheurs et dveloppeurs
dOpenERP signalent les diffrents problmes des versions publies, jai pu trouver des
correctifs appliquer au module pour profiter de ces fonctionnalits.
Le problme a t du au fait que le module a t compltement rnov, et que sa date de
publication tait trs rcente (fvrier 2012).

Rapport du projet de fin dtudes

Page 64

HAMLI Marouane

Conclusion
Ce stage de fin dtudes a t, encore une fois, une occasion pour moi pour ctoyer le
monde de lentreprise, mais avec plus de responsabilits cette fois-ci.
Cot technique, le travail ralis jusquici permet une gestion interne dune officine, et
peut tre tendu en dveloppant le concept d changes entre confrres pharmaciens, ou
encore en intgrant OpenERP chez les grossistes, fournisseurs de produits aux pharmaciens,
et lier ces deux solutions pour automatiser les commandes de mdicaments par exemple.
Le module dvelopp pourra maintenant subir des tests plus importants que ceux
raliss par moi-mme pendant son dveloppement, c'est--dire passer une phase bta, o
une liste de produits contenant toutes les informations ncessaires des mdicaments sera
importe, ensuite il sera install dans une officine, et sera utilis en parallle avec le logiciel
de gestion existant dj, pour juger de son efficacit et de sa facilit dutilisation.
Cot personnel, travailler dans le monde de lopen source, et plus prcisment sur un
PGI tel que OpenERP ma permis dapprendre plus sur ces domaines, notamment le langage
python et lutilisation du framework OpenObject , et de rejoindre une communaut
mondiale de plus de 1500 individus impliqus eux aussi dans la recherche et le
dveloppement de nouveaux modules, afin de faciliter lintgration dune telle solution dans
tous les domaines professionnels et sociaux.
A travers ce projet, jai pu voir limportance des logiciels libres pour les PME
marocaines, surtout leur capabilit satisfaire un bon nombre de besoins fonctionnels, tout
ceci faibles cots, ce qui permet leur croissance dans leur march et garantir leur durabilit
face la concurrence.

Rapport du projet de fin dtudes

Page 65

HAMLI Marouane

Bibliographie & webographie


Bibliographie
-

Rapport du projet de fin dtudes de MOUNIR Majid, ENSA de Tanger


OpenERP, pour une gestion dentreprise efficace et intgre (Eyrolles)
Open Object Developer Book (Tiny SPRL)
OpenERP : a modern approach to integrated business management based on a
free Open Source software system (Geoffrey S. Gardiner and Fabien Pinckaers)
Programmation python (dition 2), (Eyrolles)

Webographie
-

http://www.theopensourcerer.com/2012/02/22/how-to-install-openerp-6-1-onubuntu-10-04-lts
http://www.easyopenerp.com/principales-nouveautes-de-la-version-6-1/
http://www.ibcscorp.com/application-integration-customization/erp/openerp2/openerp-custom-module-development-quick-start-guide/
http://planet.domsense.com/docs/openerp-web/en/addons.html
https://code.launchpad.net/~guerrerocarlos/openobjectaddons/point_of_sale_6.1_barcode__merge/+merge/99129 (fix pr recherche ac
code barre)
http://mohsinpage.wordpress.com
http://www.docstoc.com/docs/21264701/OpenERP-User-Manual
http://blip.tv/openerp-support

Rapport du projet de fin dtudes

Page 66

HAMLI Marouane

Annexe A
Introduction au dveloppement de modules OpenERP avec le framework Open Object

Rapport du projet de fin dtudes

Page 67

HAMLI Marouane

INTRODUCTION AUX OBJETS


Toutes les donnes d'OpenERP sont accessibles par les objets: cest dire pour la
cration d'un module, on ne manipule pas les donnes directement car les objets sont eux qui
crent les tables de base de donnes contenant les donnes d'OpenERP via ORM (Object
Relational Mapping).
Par exemple: il existe dans le module de base d'OpenERP, l'objet res.partner qui
permet d'accder aux informations concernant les partenaires. Aussi il y'a dans le module de
base account, l'objet d'OpenERP account.invoice pour accder aux donnes relatives la
facture. Tous ces objets se trouvent dans des fichiers d'extension .py.
On signale qu'il y'a un objet pour chaque type de ressource et non un objet pour une
ressource, ainsi un il y'a un unique objet res.partner pour manipuler tous les partenaires
(dans ce cas les ressources) et on ne peut pas avoir l'objet res.partner pour chaque partenaire:
parlons aux termes d'orient objet pour bien assimiler cette notion, on peut dire que l'objet
d'OpenERP est considr comme la classe et les ressources sont les instances de cette classe
cest dire les objets. Et si on parle du cot de la base de donnes les objets d'OpenERP sont
les tables de la BD et les lignes des tables sont les ressources. Donc une table (un objet
d'OpenERP) comprend plusieurs lignes (Ressources d'openErp).
Une consquence directe de cette notion objet-ressources est que toutes les mthodes
des objets ont un paramtre commun : le paramtre ids. Il spcifie sur quelles ressources la
mthode s'appliquera: prcisment ce paramtre contient une liste des identificateurs des
ressources (ids) sur laquelle la mthode s'appliquera.
Par exemple, si on a deux ressources partenaires avec les identificateurs 1et 2 (les
identificateurs de ressources sont les id des lignes de la table qui correspond l'objet qui
manipule ces ressources) et aussi nous voulons appeler la mthode d'objet res.partner qui est
send_email, nous procdons comme suit: res_partner.send_email(..., [1, 2], ...)
Ultrieurement dans ce support, nous verrons comment appeler les mthodes d'objets
et les quelques mthodes propres d'OpenERP.
Un rappel important pour les programmeurs :
-

Les objets d'OpenERP sont appels classes si on parle au terme de la


programmation oriente objet
Et une ressource est appele objet, l'instance de la classe.

Definition des objets en OpenERP


Pour dfinir un nouvel objet, on dfinit une nouvelle classe et aprs on l'instancie,
cette classe doit hriter de la clase OSV du module OSV d'OpenERP.

Rapport du projet de fin dtudes

Page 68

HAMLI Marouane

Ainsi, la premire ligne de la dfinition de l'objet sera toujours comme suivant:


class nom_objet(osv.osv):
_name = 'nom de l'objet'
_columns = {...}
...
nom_objet()
Donc, l'objet se dfinit en dclarant quelques attributs avec des noms prdfinis dans
la classe, deux de ces attributs sont obligatoires savoir _columns et _name, les autres sont
optionnels. Les attributs prdfinis sont:
-

_auto: Prend True /False et dtermine si la table correspondante dans postgres


doit se gnrer automatiquement partir de cet objet. Mettre _auto=False
pourra tre utile dans les cas ou on veut crer objets bass sur des vues de
postgresql sans crer des tables.
_columns(obligatoire): on y dfinit les champs(les attributs de la classe si on
parle au terme d'orient objet) de l'objet
_constraints: on y dtermine des restrictions sur l'objet (on en parlera
ultrieurement)
_defaults: on dfinit les valeurs par dfaut pour quelques champs de l'objet.
_inherit: on met l'objet pre que l'actuel objet hrite. On va le dtailler dans
deux types:
o ORM - Object Declaration - _inherit (1) : Ralise un hritage d'un objet
existant, mais cre 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) : Ralise un hritage d'un objet
existant, ajoute des caractristiques l'objet dont nous hritons,
exemple :
class res_partner_add_langs(osv.osv):
_name = 'res.partner'
_inherit = 'res.partner'

Rapport du projet de fin dtudes

Page 69

HAMLI Marouane

_columns = {
'lang_ids' :
fields.many2many('res.lang','res_lang_partner_rel',
'partner_id', 'lang_id', 'Languages')}
res_partner_add_langs()
-

_name(obligatoire): le nom de l'objet, la valeur par dfaut est None


_order: on met le nom du champ de l'objet actuel qui sera comme critre de tri
des rsultats des mthodes search et read. Sa valeur par dfaut est 'id'
_sql: on met le code sql pour l'excuter dans la cration de l'objet (seulement si
_auto=True)
_table: nom de la table sql correspondante a cet objet, sa valeur par dfaut est
celle de _name en remplaant les points (.) par des tirets (_)

Les champs des objets


Les objets peuvent contenir diffrents types de champs. Ces types s'articulent dans
trois catgories: types simples, types relationnelles et champs fonctionnels.
Les types simples englobent les entiers, les rels, les boolens et les chaines de
caractre, les champs de type relationnel permettent de reprsenter les relations entre les
objets (one2one, many2one, many2many). Les champs fonctionnels sont des champs
spciaux parce qu'ils ne sont pas enregistrs dans la base de donnes mais plutt sont
calculables partir d'autres champs dans le temps rel.
La signature de la mthode d'initialisation de la classe dont hrite tout champ dclar
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 paramtres optionnels communs pour tous les types de champs sont comme
suit:
-

change_default: (True/False) quand ce champ prend la valeur boolenne


True, le programme permet l'utilisateur d'tablir des valeurs par dfaut dans
autres champs qui dpendent de la valeur de ce champ. Sa valeur par dfaut
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 dfaut dans les champs de la vue qu
dpendent du champs 'Zip'(code postale). Par exemple, l'utilisateur peut
programmer que le programme remplit automatiquement le champ 'city'
Barcelone si le code postale prend la valeur '08000'.
help: montre un message d'aide lorsque la souris est au-dessus de ce champ.
Exemple: 'name': fields.char('name', help='le nom s'affiche.'),

Rapport du projet de fin dtudes

Page 70

HAMLI Marouane

Readonly:(True/False) dtermine si le champ sera ditable ou non. Valeur par


dfaut=False
required: (True/False) dtermine si le champ est obligatoire ou non,
signalons que OpenERP refuse d'enregistrer une ressource si un champ
obligatoire est vide. Donc il est obligatoire de remplir tous les champs
obligatoires avant d'enregistrer une ressource. Valeur par dfaut=False
states: ce paramtre permet de dfinir des autres attributs pour ce champs qui
seront disponibles selon des tats dtermins de la ressource. Format: states=
{'tat de la ressource': [liste des attributs]} Avec liste des attributs est une
liste de tuples de la forme: [('nom de l'attribut', valeur), ...]. Valeur par
dfaut ={}
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', lattribut
partner_id sera en lecture seule.
String: c'est ltiquette du champ. Valeur par defaut=unknown
translate: (True/False) dtermine si ce champ doit tre traduit.(gr par le
systme de traduction). Valeur par dfaut=False

Finalement, voici les paramtres optionnels spcifiques pour quelques types de


champs :
-

domain: sert a restreindre le domaine des ressources, ce paramtre est valide


seulement pour les champs de type relationnel. Valeur par dfaut=[]
Exemple: domain=[('nom','=',valeur)])
invisible: (True/False) pour cacher la valeur du champ dans les formulaires
(mots de passes). Valeur par dfaut=False
selection: sert slectionner le niveau de recherche par dfaut dans les vues.si
ce paramtre prend la valeur '1', ceci signifie que le champs toujours apparat
dans le filtre de recherche dans la vue qui manifeste ce champs. Et s'il prend
'2', le champ apparat seulement dans la recherche avance qui se manifeste
lorsqu'on clique sur le symbole +
on_change: lance une fonction (dfinit sur l'objet ORM qui contient ce champ)
quand la valeur de ce champ change dans une vue. Exemple: on_change =
"onchange_shop_id(shop_id)

Types de champs :

Champs simples:
boolean: le champ boolean prend deux valeurs (True/False)
Syntaxe: fields.boolean('Nom du champs' [, Parametres optionnels]),
integer : si la valeur voulue est un entier.
Syntaxe: fields.integer('Nom du champs' [, Parametres optionnels])
Float : si la valeur voulue est un nombre flottant (rel).

Rapport du projet de fin dtudes

Page 71

HAMLI Marouane

Syntaxe: fields.float('Nom du champs' [, Parametres optionnels]),


Note: il y'a un paramtre spcifique digit pour le champ de type float, ce paramtre prcise le
nombre de chiffres aprs la virgule et prcise le nombre des chiffres significatif cest dire le
nombre de chiffres aprs et avant la virgule.
Exemple:
'rate' : fields.float('le taux', digits=(12,6) [, Parametres optionnels])
-

char: Une chaine de caractres de longueur limite. Le paramtre obligatoire


size dtermine sa longueur
Syntaxe : fields.char('Nom du champs', size=n [, Parametres optionnels]), ou n
est un entier.
text: un texte de longueur illimite
Syntaxe : fields.text('Nom du champs' [, Parametres optionnels]),
Date : ce champs dtermine la date .
Syntaxe : fields.date('Nom du champs' [paramtres optionnels, ]),
datetime : Permet l'dition de la date et l'heure dans le mme champ.
Syntaxe : fields.datetime('Nom du champs' [paramtres optionnels, ]),
Binary: pour l'image, Exemple : 'image': fields.binary('Image')
selection: ce champ permet l'utilisateur de slectionner plusieurs valeurs
prdfinis.
Syntaxe:fields.selection([('n','non confirm'), ('c','Confirm')], 'Nom du
champs' [, paramtres optionnels]),

Remarque: le format du paramtre de slection est une liste de tuples:[('cl', 'chaine de


caractre montrer'), ...]
ou la cl s'enregistre dans la ligne de la table (correspondante
l'objet qui contient le champ) comme une valeur prdfinie.

Champs fonctionnels:

Le champ fonctionnel est un champ dont la valeur est calcule par une fonction (au
lien de s'enregistrer dans la base de donnes). Dans les cas spciales (pour faciliter la
recherche ou la consultation) les champs de type fonctionnel peuvent tre sauvegards dans la
base de donnes avec le paramtre STORE (il va prendre la valeur boolenne True). Ils sont
actualiss par les fonctions et non par les utilisateurs.
Paramtres: 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 raliser une recherche sur le champ
method: Si True, il s'agit d'une mhode d'instance d'openErp, sinon, fonction
type: Indique le type d'lment (char, integer, float, boolean, date, datetime)
store: Si True, stocke dans la base de donnes la valeur du champ(par dfaut
False)

Rapport du projet de fin dtudes

Page 72

HAMLI Marouane

fnct: c'est la fonction qui calcule la valeur du champs avec une mthode d'openErp ou
une fonction globale,Si method=True,la signature de mthode 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 donnes


par un instructeur
_columns = {
'instructor_id' : fields.many2one('openacademy.instructor',
'Instructor')
}

ORM - Champs - Relationnel - many2one & one2many


Comment retenir la diffrence ?
-

Champ many2one: plusieurs (many) de ces objets sont possds par un (one)
objet parent
Champ one2many: l'objet (one) possde plusieurs (many) enfants

Rapport du projet de fin dtudes

Page 73

HAMLI Marouane

ORM - Champs - Relationnel - many2many, exemple :


_columns = {
'participant_ids' : fields.many2many('openacademy.participant',
'openacademy_training_participant_rel', 'training_id',
'participant_id', 'Participants')
}
-

Un participant peut suivre plusieurs formations


Une formation est donne plusieurs participants

ORM Mthodes spciales Mthodes prdfinies


Mthodes prdfinies :
-

create: Cration d'un enregistrement


write: Mise jour d'un enregistrement
unlink: Suppression d'un enregistrement
read: Lecture de champs d'un enregistrement
copy : Duplication d'un enregistrement
search: Recherche d'enregistrement
browse: Rcupration d'enregistrement via critres de recherche
name_get: Retourne uniquement que le nom et l'identifiant du record
name_search: Ralise une recherche du nom sur base d'un domaine
init : Permet de crer une vue si _auto = False
_auto_init : Permet de crer un index ou un objet SQL si ncessaire

Rapport du projet de fin dtudes

Page 74

HAMLI Marouane