adaptation et integration d’openerp pour la gestion d’officine

ECOLE NATIONALE DES SCIENCES

APPLIQUEES - TANGER

N° d’Ordre :

UNIVERSITE ABDELMALEK

ESSAÂDI

PROJET DE FIN D’ETUDES

Présenté à l’école pour obtenir le diplôme

D’INGENIEUR D’ETAT

Spécialité: Génie informatique

Option: Génie des systèmes d’informations

Titre

ANALYSE DE BESOIN, ADAPTATION

ET INTEGRATION D’OPENERP POUR

LA GESTION D’OFFICINE

Réalisé par

HAMLI Marouane

Encdré par

ELKAFIL Abdrahman (NEXTMA)

EL ALAMI Mohamed (ENSAT)

SOUTENU LE 27 juin 2012

Rapport du projet de fin d’études HAMLI Marouane

Dédicace Au Dieu tout puissant, mon créateur. A ma mère, ma raison d’être, ma raison de vivre, la lanterne qui éclaire mon chemin et m’illumine de douceur et d’amour. A mon père, en signe d’amour, de reconnaissance et de gratitude pour tous les soutiens et les sacrifices dont il a fait preuve à mon égard. A mes sœurs.

A mes grands-parents.

Aux familles EL KHAZRAJI et HAMLI.

A mes amis, et à tous mes proches.


Remerciements

Le présent rapport reflète le fruit des efforts conjugués de plusieurs personnes. Il

m’est alors agréable d’exprimer ma reconnaissance auprès de toutes ces personnes, dont

l’intervention au cours de ce projet, a favorisé son aboutissement.

Aussi je tiens à rendre grâce à mes parents, ma famille et mes amis qui, avec leur

soutien et encouragement, j’ai pu arriver à terme de ce travail.

Je souhaite remercier aussi mon encadrant d’entreprise, pour m’avoir accordé cette

chance de travailler à ses cotés, et qui m’a été d’une aide très utile durant ma période de

stage, Mr ELKAFIL Abdrahman pour ses directives précieuses et ses conseils judicieux qui

m’ont été d’un appui considérable dans ma démarche.

Je remercie particulièrement Mr Mohamed HASSOUN EL ALAMI pour son

encadrement, son soutien, ainsi que pour ses conseils instructifs durant toute la période de ce

travail.

Mes remerciements aussi à Mr ELHADDAD Mohamed, chef de la filière informatique,

ainsi qu’à l’ensemble des professeurs de l’ENSA-Tanger pour les efforts fournis pour notre

bonne formation.

Que les membres de jury trouvent ici l’expression de mes reconnaissances pour avoir

accepté de juger notre travail. Que tous ceux et celles qui ont contribué de près ou de loin à

l’accomplissement de ce travail trouvent l’expression de mes remerciements les plus

chaleureux.


Résumé

Les technologies de l’information ont connu une importante évolution durant ces

dernières années, ce qui a donné comme résultat l’émergence de plusieurs solutions

informatiques pour remédier aux différentes problématiques réelles.

Les Progiciels de Gestion Intégré, appelés PGI ou ERP, sont l’une des solutions les

plus pratiques à ce jour, ils intègrent les principales composantes fonctionnelles de

l'entreprise: gestion de production, gestion commerciale, logistique, ressources humaines,

comptabilité, contrôle de gestion.

A l'aide de ce système unifié, les utilisateurs de différents métiers travaillent dans un

environnement applicatif identique qui repose sur une base de données unique. Ce modèle

permet d'assurer l'intégrité des données, la non-redondance de l'information, ainsi que la

réduction des temps de traitement.

Le travail présenté dans ce rapport concerne l’analyse du besoin, l’adaptation et

l’intégration du PGI Open-Source « OpenERP » pour la gestion d’officine pharmaceutique.

Pour y arriver, il a fallut d’abord se rendre sur les lieux, une pharmacie, pour prendre

notes des différents processus métier, pour ensuite pouvoir élaborer une liste des différents

besoins requis. L’étape qui a suivit était de se familiariser avec ce nouvel outil et découvrir les

options qu’il offre, puis apprendre comment développer un module pour ce progiciel. Ensuite

faire quelques simulations pour s’assurer que le travail a bien été fait, et corriger les bugs qui

peuvent arriver, si jamais il y en a.

Les PGI sont connus pour leur structure « modulaire », ainsi il a fallut développer un

module spécial pour les officines, lequel fonctionne en relation avec d’autres modules

existants, comme le module des achats, ou celui du point de vente.


Avant-propos

Nom : HAMLI

Prénom : Marouane

Intitulé du travail : Analyse du besoin, adaptation et intégration d’OpenERP pour la gestion

d’Officine.

Etablissement d’accueil : Nextma

452, Boulevard Mohamed V, Casablanca

Tel : +212 (0) 5 22 30 00 55

Fax : +212 (0) 5 22 45 17 30

Email : [email protected]

Encadrant dans l’établissement d’accueil : M. ELKAFIL Abdrahman

Encadrant à l’ENSA : M. EL ALAMI Ahmed

Date de début et de fin du stage : du 5 Mars au 31 Mai 2012.

mailto:[email protected]


Liste des abréviations

Abréviation Désignation

PGI Progiciel de Gestion Intégré

ERP Enterprise Resource Planning

SSLL Sociétés de Services en Logiciels Libres

PME Petites et Moyennes Entreprises

CRM Client Relationship Management

UML Unified Modeling Language

RUP Rational Unified Process

XP eXtreme Programming

2TUP Two Track Unified Process

DCI Dénomination Commune Internationale

XML eXtended Markup Language

BSD Berkeley Software Distribution

SGBDRO Système de Gestion de Base de Données Relationnelle et Objet

SQL Structured Query Language

MVC Modèle Vue Contrôleur

GPAO Gestion de Production Assistée par Ordinateur

GTK The Gimp ToolKit

WSGI Web Server Gateway Interface

SGML Standard Generalized Markup Language

GED Gestion Electronique Documentaire

TVA Taxe sur la Valeur Ajoutée


Table des figures

Figure 1: Logo Nextma ............................................................................................................ 13

Figure 2: Nextma sur la carte ................................................................................................... 13

Figure 3: Clients Nextma ......................................................................................................... 15

Figure 4: Cycle de développement en Y .................................................................................. 21

Figure 5: Planning du projet ..................................................................................................... 22

Figure 6: Interface d'Ubuntu 11.10 .......................................................................................... 34

Figure 7 : Logo PostgreSQL .................................................................................................... 35

Figure 8 : Interface Web d'OpenERP ....................................................................................... 36

Figure 9: Architecture d'OpenERP ........................................................................................... 38

Figure 10 : Dépendences du module officine ........................................................................... 45

Figure 11: Connexion ............................................................................................................... 47

Figure 12: Accueil OpenERP - client web ............................................................................... 48

Figure 13: Liste des modules OpenERP .................................................................................. 48

Figure 14: Gestion des utilisateurs ........................................................................................... 51

Figure 15: Gestion des groupes ............................................................................................... 51

Figure 16: Liste des médecins .................................................................................................. 52

Figure 17: Formulaire médecin ................................................................................................ 52

Figure 18:Formulaire patient .................................................................................................... 52

Figure 19: Bons de commande fournisseur .............................................................................. 53

Figure 20: Liste des réceptions ................................................................................................. 54

Figure 21: Formulaire client ..................................................................................................... 54

Figure 22: Gestion des inventaires physiques .......................................................................... 55

Figure 23: Liste des mouvements de stock ............................................................................. 55

Figure 24: Liste des règles de stock minimum ......................................................................... 56

Figure 25: Formulaire produit – I ............................................................................................. 56

Figure 26: Formulaire produit - II ............................................................................................ 57

Figure 27: Produit en stock d'alerte .......................................................................................... 57

Figure 28: Analyse des mouvements de stocks ........................................................................ 57

Figure 29: Liste des factures clients ......................................................................................... 58

Figure 30: Détails facture client ............................................................................................... 58

Figure 31: Paiements clients .................................................................................................... 59

Figure 32: Point de vente ......................................................................................................... 60

Figure 33: Paiement en espèces ............................................................................................... 60

Figure 34: Assistant d'ouverture des caisses ............................................................................ 61

Figure 35: Liste des méthodes de paiement ............................................................................. 61

Figure 36: Formulaire de création/modification d'une méthode de paiement .......................... 61

Figure 37: Liste des caisses ...................................................................................................... 62

Figure 38: Journal des ventes ................................................................................................... 62

Figure 39: Ordre de vente ......................................................................................................... 62

Figure 40: Renseignement des informations d'ordonnance...................................................... 63


Figure 41: Catégories des produits - point de vente ................................................................. 63

Figure 42: Analyse du point de vente par produit .................................................................... 64

Figure 43: Analyse des enregistreuses par utilisateur .............................................................. 64

Diagrammes Diagramme 1: Gestion basique ................................................................................................ 26

Diagramme 2: Vente au comptoir ............................................................................................ 27

Diagramme 3: Gestion des achats ............................................................................................ 28

Diagramme 4: Gestion des ventes ............................................................................................ 29

Diagramme 5 : Gestion du stock .............................................................................................. 30

Diagramme 6: Cas d'utilisations - Statistiques et alertes.......................................................... 31

Diagramme 7: Diagramme des classes - fonctionnel ............................................................... 32

Tableaux

Tableau 1 : Comparaison des méthodes de développement ..................................................... 20

Tableau 2: Liste des fonctionnalités requises ........................................................................... 25

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

Tableau 4 : attributs du produit ................................................................................................ 49

Tableau 5: Attributs de la méthode de paiement ...................................................................... 50


Table des matières Dédicace ..................................................................................................................................... 2

Remerciements ........................................................................................................................... 3

Résumé ....................................................................................................................................... 4

Avant-propos .............................................................................................................................. 5

Liste des abréviations ................................................................................................................. 6

Table des figures ........................................................................................................................ 7

Diagrammes ............................................................................................................................... 8

Tableaux ..................................................................................................................................... 8

Introduction générale ................................................................................................................ 11

Partie I : Contexte général du projet ......................................................................................... 12

1 Chapitre I : Présentation de l’organisme d’accueil .......................................................... 13

1.1 Présentation de Nextma ............................................................................................. 13

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

1.3 Secteurs d’activité ...................................................................................................... 14

1.4 Références ................................................................................................................. 15

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

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

2.2 Problématique ............................................................................................................ 16

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

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

2.4.1 Processus du développement .............................................................................. 19

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

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

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

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

3.2 Conception ................................................................................................................. 26

3.2.1 Diagramme des cas d’utilisations : ..................................................................... 26

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

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

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

4.1 Ubuntu ....................................................................................................................... 34

4.2 PostgreSQL ................................................................................................................ 35


4.3 OpenERP ................................................................................................................... 36

4.4 Python ........................................................................................................................ 40

4.5 XML .......................................................................................................................... 42

5 Chapitre IV : Développement du module « officine » ..................................................... 43

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

5.2 Module « Officine » .................................................................................................. 46

5.3 Installation ................................................................................................................. 47

5.4 Paramétrage ............................................................................................................... 48

5.4.1 Général ............................................................................................................... 48

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

5.4.3 Produit ................................................................................................................ 49

5.4.4 Méthodes de paiements : .................................................................................... 49

5.5 Simulation .................................................................................................................. 51

5.5.1 Gestion de base ................................................................................................... 51

5.5.2 Gestion des achats .............................................................................................. 53

5.5.3 Gestion des ventes .............................................................................................. 54

5.5.4 Gestion du stock ................................................................................................. 55

5.5.5 Comptabilité ....................................................................................................... 58

5.5.6 Point de vente ..................................................................................................... 60

5.6 Problèmes rencontrés ................................................................................................. 64

Conclusion ................................................................................................................................ 65

Bibliographie & webographie .................................................................................................. 66

Bibliographie ........................................................................................................................ 66

Webographie ........................................................................................................................ 66

Annexe A .................................................................................................................................. 67


Introduction générale

Le présent rapport est le fruit de mon travail effectué au sein de la société Nextma à

Casablanca, ce stage de 3 mois est le couronnement de ma formation pour obtenir le diplôme

d’Ingénieur d’Etat, en génie informatique, à l’ENSA Tanger.

Durant ces trente dernières années, l’informatique de gestion a subi des

bouleversements considérables. Les avancées technologiques du traitement de l’information

ont eu des conséquences capitales sur le rôle de l’outil informatique. Si les premières

applications ont permis d’automatiser les activités opérationnelles des organisations (gestion

de production, gestion commerciale et financière, ressources humaines), aujourd’hui les

systèmes d’information prennent en charge des niveaux de gestion de plus en plus

stratégiques.

Les ERP (Enterprise Resource Planning) ou PGI (Progiciels de Gestion Intégrés),

ont connu leur essor en profitant de l’évolution nécessaire des systèmes d’information pour le

passage de l’an 2000 puis pour la mise en place de l’euro. En effet, il était séduisant de

remplacer tous les logiciels de gestion de l’entreprise par un intégré offrant « l’état de l’art »

plutôt que d’engager des corrections des programmes existants plus ou moins anciens.

Mon Projet de Fin d’Etudes est autour d’OpenERP, un PGI open-source extrêmement

modulaire, et a pour but d’adapter puis intégrer cette solution pour permettre la gestion des

officines pharmaceutiques.

Le travail consiste à effectuer d’abord une analyse du besoin, afin de bien souligner les

différentes fonctionnalités requises, ensuite à chercher parmi ces fonctionnalités celles qui

sont déjà offertes par OpenERP, comme ça je pourrai entamer le développement des

fonctionnalités restantes qui n’existent pas encore, pour enfin faire des tests de simulation,

détecter et corriger les bugs si jamais il y en a.

Ce rapport est scindé en deux grandes parties : la première, composée de deux

chapitres, définit le contexte général du projet ; Le premier chapitre présente l’organisme

d’accueil, tandis que le second concerne le cadre général du projet, et la démarche suivie pour

assurer son bon déroulement. Quant à la seconde partie, composée de trois chapitres, concerne

à tout ce qui est étude fonctionnelle et technique, ainsi le troisième chapitre est autour de

l’analyse et la conception du projet, le suivant décrit les choix des technologies mises en

œuvre, alors que le dernier explique l’étape du développement, ainsi que la simulation et les

différents problèmes rencontrés.

En fin, ce rapport est terminé par une conclusion sur l’apport du travail réalisé et des

perspectives futurs où il peut déboucher.


Partie I : Contexte général du projet

Chapitres :

- Présentation de l’organisme d’accueil

- Cadre général du projet


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

1.1 Présentation de Nextma

Figure 1: Logo Nextma

Nextma est une Société de Services en Logiciels Libres (SSLL) qui accompagne les

entreprises et institutions dans le choix des solutions open source ainsi que dans l'intégration,

le développement, l'adaptation aux besoins spécifiques, la maintenance et le support. Afin de

bénéficier des meilleures solutions libres dans la gestion des systèmes d'information.

Figure 2: Nextma sur la carte

Nextma a développé une expertise autour d’OpenERP depuis 2006 (premier partenaire

officiel OpenERP au Maroc en 2007) et a contribué à faire connaître cet ERP open source au

Maroc à travers plusieurs déploiements réussis dans les PME marocaines et des conférences

dans les universités et adapte celui-ci à la législation marocaine et aux besoins spécifiques des

entreprises.


1.2 Prestations et services

Nextma offre une large palette de prestations et de services basés sur des composants

libres adaptés aux systèmes et aux réseaux des clients. La principale tâche de cette société est

d’offrir des solutions sur mesure, en matière de formation et d’assistance, concernant les

problématiques relevant des systèmes d’informations, moyennant des outils libres.

La gamme de services de Nextma est articulée autour de quatre axes majeurs qui

permettent d'accompagner les clients durant toutes les phases d'un projet afin d'en assurer sa

réussite en :

Formation : L’offre des formations, techniques et fonctionnelles, permet

d'accompagner les organisations qui disposent d’équipes opérationnelles capables de mener à

bien des projets. Ces formations peuvent être établies sous forme de transferts de

compétences, en phases avals des projets.

Support : En plus des offres de formations, la société propose aux équipes dédiées

au développement, des prestations de support d’aide à la maintenance, afin de réduire le

temps de résolution des interrogations ou des difficultés que les entreprises pourraient

rencontrer lors de la mise en œuvre de certains logiciels.

Conseil : Nextma possède une équipe formée de consultants techniques et

fonctionnels qui assure soit dans le cadre de projets, soit en amont, des missions de conseil

dans les domaines suivants: gestion de contenu, travail collaboratif, dématérialisation des

procédures, migration vers le libre, architecture et dimensionnement d'applications basées sur

OpenERP…etc.

Développement : le cœur métier de Nextma et comprend le développement sur la

base de logiciels libres, de portails collaboratifs internet ou intranet, avec des composantes de

publication web, de travail collaboratif, de gestion électronique de documents et de workflow.

1.3 Secteurs d’activité

De par les multiples projets que Nextma a mené, elle a acquis un savoir-faire

susceptible de lui permettre l’implantation de logiciels libres dans les différents secteurs:

Enterprise Ressource Planning (ERP) : la solution adoptée par Nextma est

OpenERP, un PGI Open-Source.

Customer Relationship Management (CRM) : Nextma propose l’offre

SUGARCRM qui permet la gestion de la relation client.

Intranet des entreprises et gestion des contenus : Création d’identités visuelles et

sites internet institutionnels et e-Commerce. La solution proposée est Virtuemart, une solution

libre de e-commerce (Commerce électronique) qui s'appuie sur le système de gestion du

contenu « Joomla ».


Gestion électronique des documents : Il s’agit d’un système informatisé

d'acquisition, classement, stockage et archivage des documents. La solution proposée est

Alfresco.

1.4 Références

Nextma compte plusieurs déploiements réussît d’OpenERP dans des PME marocaines

dont je cite quelques références :

Figure 3: Clients Nextma


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

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

La pharmacie d'officine est la branche la plus connue de la pharmacie. C'est la branche

regroupant les pharmaciens qui travaillent dans les pharmacies de ville, appelées aussi

officines, où les médicaments sont délivrés au public.

Le rôle du pharmacien d'officine est la délivrance des ordonnances prescrites par les

médecins, les conseils associés à la prise des médicaments, à l'hygiène, à la nutrition ou, plus

globalement, à la santé publique.

Le travail du pharmacien d'officine est aussi l'analyse de l'ordonnance, la vérification

des posologies, des interactions médicamenteuses et des contre-indications existantes en

fonction de l'état du patient. Le pharmacien, étant au bout de la chaîne de la prescription

médicale, est responsable des médicaments délivrés, même en cas d'erreur ou négligence de la

part du médecin prescripteur.

À ce titre, il peut refuser de délivrer l'ordonnance, ou bien modifier les posologies ou

médicaments, le plus souvent après accord avec le médecin prescripteur. Il peut également

faire le suivi du traitement et aider à l'établissement d'un plan pharmacothérapique.

Le pharmacien d'officine a aussi un rôle social, il est en mesure d'indiquer aux

personnes en difficulté les organismes ou les structures compétentes en matière de Santé

Publique et d'aides sociales.

2.2 Problématique

Les officines marocaines souhaitent s’ouvrir sur les nouvelles technologies et les

utiliser pour avoir un meilleur rendement, et ainsi intégrer des solutions de gestion complètes,

paramétrables et flexibles pour la gestion de tout ce qui se rapporte au domaine de la

pharmacie.

Certes il existe des solutions sur le marché, mais elles sont payantes, en plus du fait

qu’il est difficile de communiquer entre ces applications avec d’autres solutions « externes »

(le cas d’automatiser les commandes de médicaments), et leur support est bien limité vu

qu’elles ont été codées à la demande, à noter aussi qu’elles ne sont pas flexibles.

Avec ces outils, le pharmacien se retrouve obligé d’effectuer lui-même un bon nombre

de tâches qui normalement, avec ces solutions, doivent être automatisées, je cite comme

exemple envoyer des bons de commande vers le grossiste (fournisseur) : le pharmacien (agent

ou administrateur) crée un bon de commande avec une liste des produits demandés ainsi que


leur quantités, ce bon devra être transmis automatiquement vers un fournisseur parmi ceux

enregistrés dans la liste, après sa validation, cette option était opérationnelle avant, mais

nécessitait une installation matérielle particulière (modems 56k..etc) qui n’était pas disponible

chez tous les partenaires, et a été abandonnée plus tard, donc le pharmacien est obligé de

passer par la méthode classique qui est passer sa commande par téléphone. Les bons de

commande sont donc temporaires, et se trouvent dans la plupart des cas supprimés après avoir

effectué la réception des produits.

Autre problème que le pharmacien rencontre, est quand l’application plante, et qu’il

n’a plus accès à certaines données, comme ce cas dont j’étais témoin lors de ma visite à

l’officine du client, la liste des fournisseurs a été endommagée et n’était plus accessible, ce

qui empêchait d’établir des bons de commande ou effectuer des réceptions dans le logiciel,

ainsi les bons de livraisons des grossistes s’entassaient les uns sur les autres, en attendant que

la service support du logiciel envoie un technicien pour rétablir la base de données. Ceci avait

d’autres conséquences, le pharmacien était habitué à faire une sauvegarde quotidienne de ses

transactions, cette sauvegarde n’était plus possible depuis que la liste des fournisseurs est

perdue, ce qui représente un grand risque pour ces données, surtout qu’il était en période de

garde et avait effectué plusieurs ventes et réceptions. En plus, les quantités des produits au

stock sont devenues toutes fausses.

L’éditeur du logiciel proposait une assistance instantanée, via un logiciel d’assistance

à distance, qui n’a pas été fourni à tous ses clients, et la seule solution pratique était d’envoyer

les techniciens réparer les machines ne fonctionnant plus.

Résultat : près de 5 jours d’attente, sans aucune sauvegarde, avec des données

erronées, et encore faut-il du temps pour saisir toutes ces réceptions effectuées pendant la

panne, après la réparation du logiciel.

2.3 Objectifs du projet

Le travail demandé est d’adapter un progiciel libre, OpenERP, aux besoins des

officines, en essayant de rajouter de nouvelles fonctionnalités que les autres solutions ne

peuvent offrir.

Afin de garantir une modernisation des services des officines, il est indispensable

d’adopter les nouvelles technologies et les exploiter pour en tirer le meilleur profit.

Les PGI sont connus pour leur intégration des principales fonctions nécessaires à la

gestion des flux et procédures de l’entreprise (comptabilité, achats, ventes…), tous ces outils

accèdent à des ressources communes, en particulier des bases de données.

Parmi les autres avantages des PGI, c’est qu’ils sont conçus de telle sorte qu'un

"simple" paramétrage suffit à les adapter à l'organisation de l'entreprise. Il n'est normalement

pas nécessaire d'effectuer des développements spécifiques, sauf en cas de nécessité, lorsque ce


paramétrage ne permet pas de prendre en compte des particularités liées au métier des

officines.

Donc, le système d’information à développer aura pour objectifs :

- Objectifs globaux :

o Disposer d’un outil de gestion complet, qui contribuera à l’évolution des

officines

o Disposer d’un outil dont le support ne nécessite pas trop de ressources, et qui

pourra communiquer avec d’autres applications sans complication

- Objectifs spécifiques :

o Permettre une gestion des éléments de bases, comme les clients, patients,

médecins et fournisseurs

o Permettre une « vente au comptoir » aisée, avec une interface ergonomique qui

facilite la recherche des produits, et supporte plus qu’une méthode de

paiement.

o Permettre d’effectuer des achats auprès des fournisseurs, où il est possible

d’éditer des devis, de créer des bons de commande et de recevoir les produits

o Permettre une gestion de stock efficace, avec la possibilité de faire des

inventaires physiques et de voir l’état des stocks n’importe quand.

o Permettre le suivi des clients, voir leur situation en tout moment, et régler leur

crédit s’ils en ont.

o Enfin, avoir des statistiques concernant ces points cités auparavant


2.4 Conduite du projet

2.4.1 Processus du développement

Introduction

La complexité croissante des systèmes informatiques a conduit les concepteurs à

s’intéresser aux méthodes. On a comptabilisé en 1994 jusqu’à 50 méthodes. Chaque méthode

se définit par une notation et un processus spécifique. UML a ouvert le terrain en fusionnant

la notation. Il reste cependant à définir le processus pour réellement capitaliser des règles dans

le domaine du développement logiciel. Les groupes de travail UML ont donc travaillé à

unifier non pas les processus, mais plus exactement les meilleures pratiques de

développement objet. Ces processus ce distingueront par le générique « UNIFIED

PROCESS ».

Un processus définit une séquence d’étapes, en partie ordonné, qui concoure à

l’obtention d’un système logiciel ou à l’évolution d’un système existant. Pour produire des

logiciels de qualité, qui répondent aux besoins des utilisateurs dans des temps et des coûts

prévisibles. On découpe le processus en deux axes :

- L’axe de développement technique, qui de concentre principalement sur la qualité de

production.

- L’axe de gestion du développement, qui permet la mesure et la prévision des coûts et

des délais.

Choix de la méthodologie de conception

Avant d’adopter une méthode, il faut d’abord faire une comparaison entre les différentes

méthodes existantes, voir les points forts et les points faibles de chacune, puis déterminer

celle qui va mieux dans le contexte du projet.

Ci-dessous un tableau qui résume cette comparaison (la liste est non exhaustive, voir la

page suivante)


Description Points forts Points faibles

Rational

Unified Process

(RUP)

-Méthodologie centrée

sur l’architecture et

couplée aux

diagrammes UML

-Concerne des projets

de +10 personnes

-Processus complet

assisté par des outils

exhaustifs

-Itératif

-Spécifie le dialogue

entre les différents

intervenants du projet :

les livrables, plannings

et prototypes…

-Propose des modèles

de documents, et des

canevas pour des

projets types

-Rôles bien définis,

modélisation

-Coûteux à personnaliser

-Très axé processus, au

détriment du

développement

-Lourd, largement étendu, il

peut être difficile à mettre

en œuvre de façon

spécifique

-Convient pour les grands

projets qui générent

beaucoup de documentation

eXtreme

Programming

(XP)

-Développement guidé

par les besoins du client

-Equipes réduites,

centrées sur les

développeurs

-Itératif

-Simple à mettre en

œuvre

-Laisse une large place

aux aspects techniques

-Builds journaliers

-Amélioration

constante adaptation

aux modifications

-Ne couvre pas les phases

en amont et en aval du

développement

-Assez flou dans sa mise en

œuvre : quels intervenants ?

Quels livrables ?

-Focalisé sur l’aspect

individuel du

développement, au

détriment d’une vue globale

et des pratiques de

management ou de

formalisation.

Two Track

Unified Process

(2TUP)

-Articulé autour de

l’architecture

-Cycle de

développement en Y

-Convient aux projets de

toutes tailles

-Itératif, laisse une

large partie à la

technologie et à la

gestion du risque

-Définit les profils des

intervenants, les

livrables, les prototypes

-Superficiel sur les phases

en amont et en aval du

développement

-Aucune proposition de

document type

Tableau 1 : Comparaison des méthodes de développement

Pour atteindre les objectifs, j’ai suivi la méthode 2TUP (2Track Unified Process), qui sera

plus détaillée dans ce qui suit.


Cycle de vie du modèle 2TUP

Le modèle 2TUP repose sur cinq principes fondamentaux :

o Séparer les aspects fonctionnels et les aspects techniques

o Travailler selon deux points de vue qui se complètent et s’enrichissent mutuellement ;

celui de l’entreprise, celui des applications.

o Modéliser l’activité de l’entreprise et des applications aux moyens d’objets en utilisant

UML.

o Faire des maquettes et des prototypes pour affiner les besoins fonctionnels et les

aspects techniques.

o Effectuer la réingénierie des applications dans le sens de la réutilisation.

Le schéma suivant montre bien le cycle en « Y » caractéristique de 2TUP.

Figure 4: Cycle de développement en Y


2.4.2 Planification du projet

Le diagramme de GANT ci-dessous présente les différentes tâches nécessaires pour réaliser le projet :

Figure 5: Planning du projet


Pour bien mener ce projet, je me suis déplacé, dans un premier temps, à l’officine du

client, afin de découvrir les différentes activités et processus métier de ce domaine, des notes

concernant ceci ont été prises, et des explications ont été fournies pour chaque question

concernant un processus plus ou moins compliqué.

Après cette visite des lieux, je suis passé à l’étape suivante qui est de reformuler les

différents points pour bien limiter les besoins requis et ensuite élaborer un cahier des charges

que le client devra consulter, et validera si tous les points cités correspondent à ceux qu’il

cherche.

Les PGI sont un nouveau monde pour moi, il est donc évident de prendre un peu de

temps pour se familiariser avec, comprendre leur coté technique d’abord, puis comprendre

leur coté fonctionnel. Et comme OpenERP est écrit en Python, combiné à XML pour générer

les différentes vues, j’ai eu à lire quelques livres sur le développement avec python, et aussi

avec le framework « Open Object », dédié au développement sous OpenERP.

Une fois familiarisé un peu avec l’outil, je suis passé à écrire quelques modules

simples pour s’assurer que j’ai bien assimilé sa technique de développement, comme ça je

pourrais me lancer dans la découverte fonctionnelle du PGI, car c’est à travers elle que je

déterminerai les modules déjà existants et qui répondent en partie aux exigences du client.

Cette découverte m’a permis de fixer les fonctionnalités non existantes et qui devront être

ajoutées, en plus du paramétrage à mettre en place.

Après avoir créé les objets manquants, et après avoir paramétré l’application, j’ai

commencé à faire des simulations, afin de s’assurer que le paramétrage suivi est le bon, et

aussi chercher si il y a des bugs dans le module que je viens de créer, ou dans les autres

modules auxquels il est lié, puis je suis parti à la recherche de solutions pour les différentes

anomalies détectées.


Partie II : Etude fonctionnelle et technique

Chapitres :

- Analyse et conception du projet

- Technologies mises en œuvre

- Développement du module « officine »


3 Chapitre III : Analyse et Conception du projet

3.1 Analyse du projet

Le but du projet est d’adapter OpenERP pour qu’il puisse permettre une gestion

d’officine. Il est donc nécessaire de faire une visite des lieux, une pharmacie, afin de bien

cadrer son contexte, et de faire une liste des différentes fonctionnalités requises pour une telle

gestion, avant de développer cette liste en un cahier des charges pour le valider avec le client.

Les fonctionnalités requises sont présentées dans le tableau ci-dessous :

Objectif Fonctionnalités

Gestion de base - Gestion des médicaments

- Gestion des clients

- Gestion des fournisseurs

- Gestion des patients

- Gestion des médecins

- Gérer les DCIs

Vente au comptoir - Recherche de produits multicritère (nom, code ou code à barre)

- Paiement supportant différentes méthodes de paiement (espèces,

chèques, crédit, ou carte de crédit)

- Impression du ticket de vente

- Gestion de l’ordonnancier (vente sur ordonnance)

- Consulter le journal du comptoir

Gestion des achats - Consulter la liste des fournisseurs

- Créer des devis de fournisseurs

- Créer des bons de commandes

- Effectuer des réceptions de médicaments

- Suivi des règlements fournisseurs

Gestion des ventes - Consulter la liste des clients

- Gestion des avoirs clients

- Suivi des règlements clients

- Consulter le journal des ventes

- Edition des devis

Gestion de stock - Consulter la liste de produit

- Effectuer des inventaires physiques

- Voir les mouvements de stock

- Calcul des écarts entre stock initial et stock actuel

- Afficher le stock réel

Statistiques - Consulter les produits en stock d’alerte (quantité insuffisante)

- Distribution mensuelle des ventes par client

- Distribution mensuelle des achats par fournisseur

- Distribution détaillée des achats par produit / fournisseur

- Distribution détaillée des ventes par produit / client Tableau 2: Liste des fonctionnalités requises


3.2 Conception

L’étape de conception est très importante pour la réussite d’un projet informatique car

elle vise à définir une feuille de route du projet, le concevoir et le valider avant de passer au

développement du système. Elle permet aussi d’avoir une bonne réflexion avant de passer à

l’action, une bonne organisation du travail et une bonne communication entre les différents

intervenants dans le projet.

J’ai utilisé des diagrammes UML pour cette étape, vu qu’il est le plus approprié pour les

projets informatiques orientés objet, et aussi car ses diagrammes facilitent la lisibilité et la

compréhension des modèles même pour les ceux qui sont loin du domaine informatique.

Le principal avantage d'UML est qu'il est devenu le standard en termes de modélisation

objet, son caractère polyvalent et performant et sa souplesse en fait un langage universel.

3.2.1 Diagramme des cas d’utilisations :

Dans ce projet, j’ai six grands cas d’utilisations, ces cas sont détaillés dans les

diagrammes suivants :

1. Gestion basique :

Diagramme 1: Gestion basique

La gestion basique veut dire l’ajout, modification et suppression des objets

élémentaires dans une officine, à savoir les médicaments, les fournisseurs, les clients, les

médecins, les patients, les DCI (Dénomination Commune Internationale, nom du composant

chimique principal d’un médicament), les utilisateurs et leurs groupes.

Cette gestion est limitée aux administrateurs, qui n’auront la main pour effectuer leurs

modifications qu’après s’être connecté.


2. Vente au comptoir :

Diagramme 2: Vente au comptoir

La vente au comptoir est l’activité principale dans une officine, dans ce cas, un simple

agent, reçoit la demande du client, ensuite recherche les médicaments demandées, puis

renseigne les quantités de chaque produit, les ajoute à la liste, comme il peut retirer des

produits de la liste, selon la demande du client, après il calcule le total du ticket, applique une

remise s’il y en a et informe le client du montant.

Vient ensuite l’étape du paiement, là le client déclare la méthode de paiement qu’il

souhaite, et l’agent la choisit parmi sa liste de méthodes disponibles, si le client opte pour un

crédit, alors l’ordre de vente se transforme en facture ouverte au client jusqu’à son paiement.

Une fois payé, l’agent livre les médicaments au client, et peut lui imprimer le ticket de vente

et le lui remettre.

Si le client amène une ordonnance, l’agent suit une procédure similaire à celle décrite ci-

dessus, avec la particularité qu’il doit renseigner dans cette vente le nom du médecin l’ayant

établi, en plus du patient à qui elle est destinée. Il est possible que dans cette vente se trouvent

des produits n’ayant pas de relations avec l’ordonnance, ce cas est connu comme « vente

libre ».


3. Gestion des achats :

Diagramme 3: Gestion des achats

La gestion des achats permet au pharmacien de se procurer des médicaments auprès de

ses fournisseurs. Il lui est possible de créer des devis des grossistes, convertir ces devis en

bons de commande, choisir la méthode de facturation de ces derniers, et les valider. Une fois

ces bons validés, des réceptions de produits, correspondants chacune à un bon de commande,

sont générées automatiquement et passent au statut « en attente de traitement ». Le traitement

des réceptions peut être partiel ou total, c’est-à-dire que lors d’une réception le pharmacien

peut recevoir la totalité des produits commandés, traiter la réception et passer à la facturation,

ou recevoir une partie des produits seulement, dans ce cas il ne renseigne que la quantité reçue

et valide la réception, cette dernière est dupliquée, et le duplicata est une nouvelle réception

contenant le reste des produits à recevoir, en statut « en attente de traitement ».

Après la réception des produits, le pharmacien passe à la facturation des produits

reçus, pour payer le fournisseur. Il pourra par la suite consulter les factures établies et voir

leurs situations. Les factures payées sont écrites dans le journal des achats.


4. Gestion des ventes :

Diagramme 4: Gestion des ventes

Les ventes se font toutes au niveau du point de vente, la gestion des ventes ici

concerne le suivi des clients qui se procurent des produits par crédit, car dans cette partie

l’agent peut consulter les factures des clients et voir celle qui sont toujours ouvertes, aussi il

pourra consulter la liste de ses clients et voir le montant des crédits de chacun.

Cette gestion permet aussi de gérer les avoirs, produits retournés par les clients pour

différentes raisons, une mauvaise commande par exemple.

A travers ce volet, le pharmacien peut aussi éditer des devis pour des clients qui

viennent se renseigner sur les prix de certains médicaments.

Enfin, le pharmacien a la possibilité de consulter le journal des ventes, où se trouvent

les écritures comptables des ventes par crédit.


5. Gestion du stock :

Diagramme 5 : Gestion du stock

La gestion du stock concerne la gestion des produits, où il est possible de voir la liste

de produits, voir les mouvements du stock, effectuer des inventaires physiques, voir l’état réel

du stock, et même voir les écarts entre stock actuel et stock initial.

6. Statistiques et alertes :


Diagramme 6: Cas d'utilisations - Statistiques et alertes

Ce volet est autour de tout ce qui est statistiques utiles pour le pharmacien, afin d’avoir

une idée claire de ses ventes et ses achats, comme la distribution des ventes par produit ou par

client, la distribution des achats par produit ou par fournisseur, la distribution détaillée des

ventes ou achats.

Le pharmacien pourra consulter les produits en stock d’alerte afin de pouvoir les

commander à nouveau.

3.2.2 Diagramme des classes :

Le diagramme suivant est le diagramme de classes « fonctionnel » que j’ai réalisé

avant de me lancer dans le développement.


Diagramme 7: Diagramme des classes - fonctionnel

Ce diagramme représente les classes nécessaires pour assurer un bon fonctionnement du

système à mettre en œuvre, les utilisateurs de l’application sont regroupés dans des groupes,

chaque groupe possédant des privilèges qui permettent à ses utilisateurs inscrits d’accéder à

certaines fonctionnalités.

Les utilisateurs peuvent effectuer des achats de produits auprès des fournisseurs, chaque

achat se compose des lignes d’achat, chacune de ces lignes contient un médicament désigné,

avec la quantité à acheter.

Un médicament est lié à la classe DCI de deux façons : la première concerne sa

composition, car un médicament est composé d’une ou plusieurs DCI, avec en général une

seule DCI connue, qui est sa composante principale. La deuxième liaison concerne les contre-

indications d’un médicament, qui ne sont autres que des DCI qui risquent de causer des

complications si elles sont combinées ensemble.

Les médicaments sont ensuite vendus au public, chaque vente, liée à un utilisateur,

comporte des lignes de ventes, qui regroupent le médicament vendu, sa quantité, sa remise, et

indique si elle fait partie d’une ordonnance ou non. Si la ligne fait partie d’une ordonnance

alors l’utilisateur devra renseigner le nom du médecin qui a écrit cette dernière, en plus du

nom du patient concerné.

Si le client souhaite payer par crédit, le vendeur devra renseigner dans ce cas le nom de

ce client, afin que le montant de cette vente s’ajoute à son crédit.


Evidemment, des changements ont eu lieu sur ce diagramme, surtout après la recherche

des modules OpenERP existants qui répondent en partie aux besoins du cahier des charges, ce

qui a imposé ces modifications.


4 Chapitre IV : Technologies mises en œuvre

Ce chapitre décrit les différentes technologies adoptées par Nextma, et utilisées pour la

réalisation de ce projet, à commencer par le système d’exploitation Ubuntu, tout en passant

par le PGI OpenERP, le système de gestion de bases de données PostgreSQL, et en fin les

langages nécessaires pour le développement, à savoir le langage Python et XML.

4.1 Ubuntu

Ubuntu est un système d’exploitation libre commandité par la société Canonical et une

marque déposée par cette même société.

Fondé sur la distribution Linux Debian et utilisant le bureau Unity, Ubuntu se veut

« convivial, intuitif et sûr ». Il est constitué de logiciels libres, est disponible gratuitement y

compris pour les entreprises, et bénéficie d'une nouvelle version (appelée « mise à niveau »)

tous les six mois.

Avec une utilisation globale estimée à plus de 25 millions d'utilisateurs, il est

principalement conçu pour une utilisation sur des ordinateurs personnels (portables et fixes),

bien que d'autres versions consacrées aux netbooks et aux serveurs existent aussi. Depuis

Ubuntu 11.04, la version Netbook a fusionné avec la version Desktop. Cette dernière étant

passée à l'interface Unity, il n'y avait plus de raison de maintenir deux branches distinctes.

Figure 6: Interface d'Ubuntu 11.10

La version d’Ubuntu utilisée pour ce projet est la 11.10, ayant pour nom de code « The

Oneiric Ocelot », cette version est la quinzième version d'Ubuntu. Son développement s'est

échelonné sur six mois, jusqu'à sa publication en tant que version stable le 13 octobre 2011.


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

2013.

4.2 PostgreSQL

PostgreSQL est un système de gestion de base de données relationnelle et objet

(SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD.

Ce système est concurrent d'autres systèmes de gestion de base de données, qu'ils

soient libres (comme MySQL et Firebird), ou propriétaires (comme Oracle, Sybase, DB2,

Informix et Microsoft SQL Server). Comme les projets libres Apache et Linux, PostgreSQL

n'est pas contrôlé par une seule entreprise, mais est fondé sur une communauté mondiale de

développeurs et d'entreprises.

PostgreSQL peut stocker plus de types de données que les types traditionnels entier,

caractères, etc. L'utilisateur peut créer des types, des fonctions, utiliser l'héritage de type etc.

PostgreSQL est pratiquement conforme (de plus en plus conforme) aux normes ANSI

SQL 89, SQL 92 (SQL 2), SQL 99 (SQL 3), SQL:2003 et SQL:2008. Il fonctionne sur

diverses plates-formes matérielles et sous différents systèmes d'exploitation.

Figure 7 : Logo PostgreSQL

PostgreSQL fonctionne sur Solaris, SunOS, Mac OS X, HP-UX, AIX, Linux, IRIX,

Digital Unix, BSD, NetBSD, FreeBSD, OpenBSD, SCO unix, NeXTSTEP, UnixWare et

toutes sortes d'Unix. Depuis la version 8.0, PostgreSQL fonctionne également nativement sur

Windows. Avant la version 8, il fallait un émulateur de type cygwin pour faire fonctionner

PostgreSQL sur ce système d'exploitation.

PostgreSQL est largement reconnu pour son comportement stable, proche de Oracle.

Mais aussi pour ses possibilités de programmation étendues, directement dans le moteur de la

base de données, via PL/pgSQL. Le traitement interne des données peut aussi être couplé à

d'autres modules externes compilés dans d'autres langages.


4.3 OpenERP

Anciennement connu sous le nom Tiny ERP, signifiant la fourmi de l’Enterprise

resource planning) est un progiciel intégré de gestion ouvert, libre de droits comprenant les

ventes, la gestion de relation client (CRM), la gestion de projet, la gestion d'entrepôt, la

production, la comptabilité et les ressources humaines. OpenERP a trois composants séparés :

le serveur openerp-server qui stocke ses données dans une base postgresql, le client openerp-

client qui s'installe sur le poste de l'utilisateur et le serveur web openerp-web qui permet une

utilisation depuis un navigateur. Ces trois composants communiquent par les protocoles xml-

rpc et net-rpc.

Figure 8 : Interface Web d'OpenERP

Le logiciel est basé sur une forte architecture MVC, des flux de travail flexibles, une

interface-utilisateur graphique dynamique, une interface XML-RPC, et un système

personnalisable de comptes-rendus avec une intégration pratique d'OpenOffice.org.

Dans la classification des logiciels, OpenERP, comme tout autre PGI sur le marché est

un package destiné, a priori, à tous les secteurs, à toutes les fonctions, les adaptations

nécessaires se faisant par paramétrage.

Il dispose de forts arguments commerciaux pour séduire les dirigeants (il propose de

mettre un terme au désordre du système d’information, et aussi de régler des problèmes

d’organisation sans effort politique). Cette offre séduisante par sa qualité et sa cohérence se

révèle à l’usage plus risquée que l’on avait pu l’imaginer : elle ne peut être efficace que si l’on

accepte les contraintes qu’elle impose. Sa mise en œuvre comporte des difficultés et des

pièges.

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

o Optimisation des processus de gestion

o Cohérence et homogénéité des informations

o Intégrité et unicité du Système d’information


o Mise à disposition d’un outil multilingue et multidevises (très adapté aux

multi-nationales)

o Communication interne et externe facilitée par le partage du même système

d’information

o Meilleure coordination des services et donc meilleur suivi des processus

(meilleur suivi de commande ou meilleure maîtrise des stocks par exemple)

o Normalisation de la gestion des ressources humaines (pour les entreprises

gérant de nombreuses entités parfois géographiquement dispersées)

o Minimisation des coûts (formation et maintenance)

o Maîtrise des coûts et des délais de mise en œuvre et de déploiement

o Mise à disposition, des cadres supérieurs, d’indicateurs nettement plus fiables

que lorsqu’ils étaient extraits de plusieurs systèmes différents

Toutefois, cela peut avoir quelques inconvénients, comme la lourdeur et la rigidité de

la mise en œuvre, ou encore les difficultés d’appropriation par le personnel de l’entreprise.

OpenERP comporte plusieurs modules fonctionnels, je cite les exemples suivants :

o CRM ; gestion de la relation client

o Comptabilité analytique et financière (Conforme aux exigences françaises)

o Gestion des stocks

o Gestion de production (GPAO)

o Gestion de projets et des activités de services

o Norme qualité : ISO 9001 version 2000

o Gestion des ventes

o Gestion des achats

o Marketing

o Logistique

o Ressources humaines

o Gestion documentaire

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

1. Un serveur de base de données PostgreSQL (qui peut contenir plusieurs bases

de données)

2. Un serveur d'applications (contenant les objets de gestion, le moteur de

workflow, le générateur d'édition, etc.)

3. Un serveur de présentation (appelé OpenERP Web) qui permet à l'utilisateur de

se connecter à OpenERP avec n'importe quel navigateur internet (avec le

lecteur Flash installé pour l'affichage des graphiques). Ce serveur n'est pas

nécessaire si l'utilisateur utilise le client lourd mais qui nécessitera une

installation physique sur le poste de l'utilisateur (cette application se nomme

Client GTK).


Figure 9: Architecture d'OpenERP

Ses fonctions de veille économique intégrées permettent à des utilisateurs multiples de

traiter tous les aspects du logiciel. Ainsi, les rapports et les flux de travail peuvent être

personnalisés.

La partie serveur est écrite en langage Python. Les différentes briques sont organisées

en «modules». Un module est un dossier avec une structure pré-définie contenant du code

Python et des fichiers XML. Un module définit la structure de données, formulaires, rapports,

menus, procédures, flux de travail, etc.

Le client est léger car il ne contient pas de logique d'entreprise (l'ensemble est

embarqué dans le serveur d'application). Ainsi, l'ajout de nouveaux objets, comme les menus

ou formulaires, le rend accessible à tout type de client graphique (GTK+, Web, Qt, ou Texte).

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

Le client-web est écrit en langage Python. Il utilisait la plate-forme turboGears jusqu'à

la version 5.0.1. Bien que concernant le contenu, les clients GTK + et -web soient équivalents,

il existe certaines différences dans la fonctionnalité de l'interface. Par exemple le client-web

peut avoir un lien de personnalisation sur chaque formulaire, mais le client GTK+ n'a pas de

fonction comparable.

Pour ce projet, la version d’OpenERP qui m’a été conseillée pour l’utiliser est la 6.1,

parue en février 2012, cette version comporte plusieurs nouveautés :

- Un meilleur partage des informations : Des fonctionnalités de partage des

informations à des tiers ont été ajoutées. Il est par exemple possible de permettre

l'accès aux données d'un projet en cours à un sous-traitant ou de permettre à un client

de consulter les factures qui lui correspondent et de les imprimer. La refonte de

l'interface Web riche en javascript permet en outre d'intégrer n'importe quelle partie de

l'interface d'OpenERP à site Web tiers.


- Fonctions d'échanges EDI : Des fonctions d'Échange de données informatisé font leur

apparition, permettant à un partenaire d'importer des données (par exemple une

facture) le concernant dans son propre système OpenERP ou progiciel tiers (au format

JSON), et même d'effectuer le paiement en ligne.

- Une interface mobile : Une nouvelle interface conçue pour l'utilisation sur les

terminaux mobiles de type smartphone fait son apparition. Basée sur le framework

JQuery Mobile, elle ne permet pour l'instant que la consultation en lecture seule des

informations.

- Une interface destinée aux points de ventes : Une nouvelle interface dédiée aux points

de ventes à écran tactiles, tablettes et autre dispositifs de caisse interactifs est

inaugurée dans cette version d'OpenERP. Cette fonctionnalité très demandée permet

d'utliser un lecteur de codes à barres, de sélectionner des produits par catégorie/sous

catégorie, la recherche par nom de produits et peut fonctionner hors-ligne et se

synchroniser automatiquement lorsque la connexion avec le serveur est rétablie.

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

améliorations :

o Une configuration plus simple : De nouveaux boutons de raccourcis font leur

apparition, permettant de créer plus intuitivement de nouveaux documents et

de nouveaux enregistrements directement à partir de leur saisie dans les

champs de données. De même, une installation fraîche d'OpenERP inclut

dorénavant une configuration minimale des modules, basée sur les bonnes

pratiques et les utilisations les plus courantes observées chez les utilisateurs.

o Un effort sur l'utilisabilité : L'installateur et l'assistant de configuration ont été

repensés afin de faciliter la compréhension par les nouveaux utilisateurs, en

demandant moins de détails sur la société à gérer et en se focalisant sur les

informations absolument nécessaires. La page d'installation des modules

propose par défaut une installation sous forme de « thèmes ». Par exemple, un

clic sur le thème « Ventes » installera tous les modules nécessaires à la gestion

des ventes, et vous dirigera ensuite automatiquement vers ce module configuré

et prêt à l'emploi.

o Importation des données facilitée : L'importation des données dans OpenERP à

partir de sources tierces a été améliorée. En effet, un assistant fait son

apparition permettant de facilement faire correspondre un fichier de données

au format csv au schéma de données OpenERP. À noter aussi l’existence de

fonctions d'importation automatisée des données depuis SugarCRM et Google

Calendar.

o Sous-système de courriels unifié : La configuration des paramètres de

connexions pour l'envoi et la réception de courriels est maintenant unifiée, ce

qui met fin à la duplication des configurations pour les modules tirant partie de

ces fonctions de courriels.


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

d'être plus flexible et s'adapter ainsi plus aisément aux spécificités de chaque

pays et de chaque entreprise.

o Ré-écriture de l'interface Web : L'interface Web d'OpenERP a été entièrement

ré-écrite et fait dorénavant la part belle à la technologie Javascript, sans non

plus bouleverser son apparence et l'expérience utilisateur. Parmi les

conséquences, on peut noter qu'elle offre plus de fonctionnalités avec moins de

code, et est plus rapide que l'ancienne implémentation de la 6.0. Au niveau des

améliorations se trouve aussi la possibilité de personnaliser les tableaux de

bord directement depuis l'interface avec de simples glisser-déposer, ainsi que

l'arrivée d'une nouvelle forme de présentation des données, la vue « kanban ».

o Compatibilité WSGI : De gros efforts ont été fait afin de rendre OpenERP

compatible avec Web Server Gateway Interface qui permet de recourir à des

serveurs d'application python tels que Gunicorn et uWSGI facilitant une

implémentation extrêmement robuste d'OpenERP sur les serveurs, un bien

meilleur contrôle de l'assignation des ressources matérielles et une

simplification de la mise en place de mécanismes de réplication et de

répartition de charge (les serveurs d'applications proposant souvent de telles

fonctionnalités).

4.4 Python

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

programmation impérative structurée, et orientée objet. Il est doté d'un typage dynamique fort,

d'une gestion automatique de la mémoire par ramasse-miettes et d'un système de gestion

d'exceptions ; il est ainsi similaire à Perl, Ruby, Scheme, Smalltalk et Tcl.

Le langage Python est placé sous une licence libre proche de la licence BSD et

fonctionne sur la plupart des plates-formes informatiques, des supercalculateurs aux

ordinateurs centraux, de Windows à Unix en passant par Linux et Mac OS, avec Java ou

encore .NET. Il est conçu pour optimiser la productivité des programmeurs en offrant des

outils de haut niveau et une syntaxe simple à utiliser. Il est également apprécié par les

pédagogues qui y trouvent un langage où la syntaxe, clairement séparée des mécanismes de

bas niveau, permet une initiation plus aisée aux concepts de base de la programmation.

Python est un langage :


o conçu pour produire du code de qualité, portable et facile à intégrer : grâce à

sa syntaxe claire, cohérente et concise, Python permet aux développeurs de

produire du code de qualité, lisible et maintenable. Écrire du code Python est

un exercice agréable, même en respectant les conventions de codage.

Fourni dès le départ avec des modules de tests, Python est un langage agile. Le

terme agile est originellement issu de la méthodologie de programmation agile

(Beck et Al.), très proche de la programmation itérative. Cette méthodologie,

qui réduit les risques liés à la conception de logiciels, introduit entre autres des

principes de tests continus du code.

o De haut niveau, orienté objet et totalement libre : même si elle n’est pas

imposée, Python permet la programmation orientée objet. Tous les mécanismes

objet essentiels sont implémentés et toutes les données manipulées sont des

instances de classes, comme pour les langages SmallTalk ou Ruby.

Enfin, le code peut être structuré en modules (fichiers) qui sont ensuite

importables dans l’interpréteur. Ce découpage, permet d’organiser le code et

son utilisation par des espaces de noms, et aussi de faciliter l’extension du

langage par des bibliothèques tierces compilées dans d’autres langages.

o Hautement productif : La conception d’applications en Python est très rapide

car certains aspects de programmation sont gérés automatiquement, comme la

gestion des ressources mémoire et le typage des données.

Grâce à des types de base très puissants et des primitives de haut niveau, un

programme Python est simple à concevoir et concis. Un programme Python est

en général 3 à 5 fois plus court qu’un programme C++ équivalent. Ces qualités

font de Python un langage idéal dans beaucoup de domaines.

Enfin, la bibliothèque standard de Python est très complète, et permet de

répondre aux besoins communs de programmation.

Grâce au modèle Open Source, la communauté des développeurs Python est en

outre très productive et de nombreuses extensions gravitent autour du langage.

o Dynamique : dans la plupart des implémentations, le code source n’est pas

compilé contrairement à des langages comme C ou Pascal, mais exécuté à la

volée. On parle alors de langage interprété.

Ce mode de fonctionnement rend la programmation beaucoup plus souple

puisqu’il est possible de changer un programme en cours d’exécution, ou de

tester du code en mode interactif sans disposition particulière.

L’interprétation rend aussi l’exécution plus lente, mais ce défaut est

surmontable grâce à de bonnes pratiques de programmation et des techniques

d’optimisation.


4.5 XML

XML (eXtensible Markup Language) est en quelque sorte un langage HTML amélioré

permettant de définir de nouvelles balises. Il s'agit effectivement d'un langage permettant de

mettre en forme des documents grâce à des balises (markup).

Contrairement à HTML, qui est à considérer comme un langage défini et figé (avec un

nombre de balises limité), XML peut être considéré comme un métalangage permettant de

définir d'autres langages, c'est-à-dire définir de nouvelles balises permettant de décrire la

présentation d'un texte (Qui n'a jamais désiré une balise qui n'existait pas ?).

La force de XML réside dans sa capacité à pouvoir décrire n'importe quel domaine de

données grâce à son extensibilité. Il va permettre de structurer, poser le vocabulaire et la

syntaxe des données qu'il va contenir.

En réalité les balises XML décrivent le contenu plutôt que la présentation

(contrairement À HTML). Ainsi,XML permet de séparer le contenu de la présentation, ce qui

permet par exemple d'afficher un même document sur des applications ou des périphériques

différents sans pour autant nécessiter de créer autant de versions du document que l'on

nécessite de représentations !

XML a été mis au point par le XML Working Group sous l'égide du World Wide Web

Consortium (W3C) dès 1996. Depuis le 10 février 1998, les spécifications XML 1.0 ont été

reconnues comme recommandations par le W3C, ce qui en fait un langage reconnu. (Tous les

documents liés à la norme XML sont consultables et téléchargeables sur le site web du

W3C, http://www.w3.org/XML/)

XML est un sous ensemble de SGML (Standard Generalized Markup Language),

défini par le standard ISO8879 en 1986, utilisé dans le milieu de la Gestion Electronique

Documentaire (GED). XML reprend la majeure partie des fonctionnalités de SGML, il s'agit

donc d'une simplification de SGML afin de le rendre utilisable sur le web !

XML fait partie du code des modules composants OpenERP, les vues par lesquelles

sont représentés les différents objets sont écrites en XML, ainsi nous y trouvons la description

détaillée de l’affichage des arbres, formulaires, menus et autres actions.


5 Chapitre IV : Développement du module

« officine » Dans ce chapitre, je présente les modules existants dans OpenERP et qui répondent

partiellement aux besoins requis dans le cahier des charges, pour ensuite limiter les

fonctionnalités restantes à mettre en œuvre.

Une fois le développement terminé, il ne reste que le paramétrage à faire, pour assurer

un bon fonctionnement du système.

5.1 Analyse fonctionnelle des modules OpenERP

Avant de commencer l’étape du développement, il m’a fallut d’abord chercher parmi

les modules existants sous OpenERP, ceux qui offrent des fonctionnalités exigées

précédemment dans le cahier des charges fonctionnel. Après une analyse des différents

modules, je peux décrire les modules utiles à mon système comme suit :

Module Nom

technique

Description Fonctionnalités

Gestion de

base

base Ce module est en fait le noyau

d’OpenERP, il est nécessaire pour

toute installation de nouveau

module.

En effet, dans ce module sont

définis les objets de base, qui sont

essentiels pour le bon

fonctionnement du PGI

Gestion des :

- Clients

- Workflow

- Devises de monnaie

- Langues

- Pays

- Sécurité de base

Gestion de

Stock

stock Ce module sert de base pour la

gestion de/des entrepôt(s) d’une

entreprise dans OpenERP

- Gestion d'entrepôt

- Les bons de livraison

- Traçabilité

- Produits

- Règles du Stock

- Reporting

Gestion des

ventes

sale Permet la gestion des ventes et

leur facturation.

- Gestion et suivi des

achats/ventes pour produits

stockable/services.

- Relances.

- Gestion des listes de prix.

- Création automatique des

bons de livraison.

- Facturation à partir des

livraisons.

- Calcul automatique des prix

en fonction des quantités et

des délais de livraison.

- Proposition automatique de

réapprovisionnement.

- Gestion des ristournes et

promotions.

- Gestion des livraisons

partielles et retours

fournisseurs.


- Gestion des incoterms.

Gestion des

achats

purchase Ce module concerne tout ce qui est

en relation avec l’achat de

produits

- Demande de devis

- Les commandes d'achat

- Carnet d'adresses

- Contrôle des stocks

- Contrôle de facture

Comptabilité account Ce module concerne la

comptabilité dans l’entreprise.

- Ecritures dans journaux

avec automatisation des

contreparties.

- Génération automatique

des pièces comptables.

- Automatisation complète :

calculs de TVA, date d'échéance,

équilibrage.

- Gestion des conditions de

paiement.

- Rapprochement manuel ou

automatique des écritures

bancaires, avec gestion des

ajustements.

- Edition des documents :

balance, grand livre, bilan, compte

de résultat, déclaration TVA…

- Gestion budgétaire.

Comptabilité

& finance

Account_acco

untant

Ce module permet à

l’administrateur d’accéder à toutes

les options de la comptabilité

comme les journaux et le plan

comptable

- Gestion des journaux

- Gestion des registres de

caisse

Paiement Account_vouc

her

Ce module est utilisé pour

effectuer le paiement des

différentes factures établies

Rajoute le bouton « paiement »

aux factures des clients et des

fournisseurs pour pouvoir effectuer

les paiements

Point de vente Point_of_sale Ce module, qui a été

complètement rénové, permet

d’avoir un point de vente et de

vendre des produits dans une

approche plus sociale que la vente

des produits classiques dans

OpenERP.

Le point de vente tactile OpenERP

permet de gérer les ventes dans

une boutique très facilement. Il est

entièrement basé sur le Web et ne

nécessite aucune installation ou

déploiement de logiciel tiers et

tous les commerces de vente

peuvent être facilement

consolidés. Il fonctionne en mode

connecté et déconnecté de sorte

qu’on puisse continuer à vendre si

on n’est plus connecté à Internet.

- Gestion des ventes

- Analyse des caisses

- Analyse du point de vente

- Configuration des

méthodes de paiement

- Configuration des caisses

- Inscription des ventes dans

les journaux…

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


Malgré la variété de fonctionnalités satisfaites par ces modules, il reste à créer certains

objets qui n’existent pas encore sur OpenERP, en créant un nouveau module qui les

regroupera, le schéma suivant montre comment seront intégrés ces modules listés ci-dessus et

comment ils seront liés avec le nouveau module que je vais créer :

Figure 10 : Dépendences du module officine

Officine

Point_of_sale

Account_accountant

Account_voucher

Account

Stock

Sale

Base

Purchase


5.2 Module « Officine »

Après avoir analysé les différents modules, j’ai constaté qu’il faut créer les objets

suivants :

- Médecin : cet objet est nécessaire dans le cas d’une vente par ordonnance, car

il faut renseigner le nom du médecin qui l’a établit

- Patient

- DCI : « Dénomination Commune Internationale », représente le nom du

composant chimique d’un médicament, ici au Maroc la DCI joue un rôle

secondaire pour déterminer les produits car on se base sur leur nom

commercial.

Ces nouveaux objets sont regroupés dans un nouveau module à ajouter, qui n’est autre

que « officine ». Le module est un dossier composé de fichiers python (.py) contenants les

définitions des classes et d’autres XML contenants les détails des vues de ces dernières, en

plus de certains dossiers comme les wizards (assistants se lançant dans certaines conditions)

ou report (contient les modèles de rapport du module).

En plus j’ai eu à étendre certains objets déjà créés pour qu’ils répondent aux besoins, ces

objets sont :

- Produit : ajout des attributs propres au médicament à la classe produit, comme

la posologie, la/les DCIs composant le produit (un médicament peut se

composer de plusieurs DCI, mais seul une est considérée principale), ainsi que

les DCIs listées comme contre indication.

- Ligne de vente : ajout d’un attribut « ordonnance » afin de préciser si la ligne

fait partie d’une ordonnance ou non, car après discussion avec le client, il s’est

avéré qu’il est possible de faire une vente sur ordonnance en plus d’autres

produits non prescrits dans cette dernière, tout ceci en une seule vente.

- Ordre de vente : cette classe déjà créée par le module point de vente, nécessite

d’avoir des liens avec un médecin et un patient, lorsqu’on souhaite réaliser une

vente sur ordonnance, car il faudra dans ce cas renseigner le nom du médecin

ayant établi l’ordonnance, et le patient à laquelle elle est destinée. Je lui ai

ajouté aussi un champ qui calcul le montant total des produits achetés sur

ordonnance.

Après avoir créé et étendu les classes citées ci-dessus (voir l’annexe A qui contient des

détails quant au développement de classes avec le framework « Open Object »), il fallait

passer à créer les vues pour les représenter graphiquement et les utiliser, les vues sont des

fichiers XML dans lesquelles on définit la structure d’affichage des nouveaux objets créés, et

on peut aussi hériter des vues déjà existantes, et soit les modifier, ou y ajouter de nouveaux

champs à afficher.

L’avantage de coder ces nouveaux objets sous « Open Object » réside dans le fait qu’il

suffit de renseigner une nouvelle classe, mentionner ses attributs, pour qu’ensuite Open

Object lui crée une table dans la base de données et lui associe ses méthodes élémentaires


(ajout, modification, suppression), les méthodes spécifiques à une classe doivent être écrites

dans cette dernière.

Après la création des différentes classes nouvelles et classes filles, nous devons créer

deux fichiers spéciaux pour OpenERP afin de pouvoir installer le module. Le premier fichier

est « __init__.py » où on importe tous les fichiers python qu’il nous faut pour faire

fonctionner le module. Le deuxième est « __openerp__.py » (anciennement appelé

__terp__.py), dans ce fichier se trouve la fiche technique du module, à savoir son nom, sa

description, le nom de l’auteur, les noms des modules auxquels il dépend, et les fichiers des

vues XML à inclure pour pouvoir afficher nos objets créés ou étendus.

5.3 Installation

Maintenant que le codage est terminé, on peut passer à l’installation du module

« officine », qui installera d’abord les modules auxquels il est lié, ensuite ajoutera ses propres

fonctionnalités.

Avant de lancer le serveur d’OpenERP, on doit copier le dossier du module « officine »

dans le dossier « Addons » d’OpenERP, ensuite on lance le serveur (fichier openerp-

server.py), et nous pourrons à ce stade, installer notre nouveau module.

Bien évidemment, on doit d’abord se connecter puis accéder aux paramètres.

Figure 11: Connexion


Figure 12: Accueil OpenERP - client web

Une fois connecté, on se rend aux paramètres, puis dans le menu modules, on lance

une mise à jour de la liste des modules, afin qu’on puisse trouver celui qu’on vient d’ajouter

parmi la liste, là on lance l’installation du module officine.

Figure 13: Liste des modules OpenERP

5.4 Paramétrage

Maintenant que j’ai installé mon module, je peux commencer à paramétrer le PGI et

démarrer une simulation pour s’assurer de son bon fonctionnement.

5.4.1 Général

Avant de se lancer dans le paramétrage de l’application, je commence par un

paramétrage général, où il faut saisir le nom de l’officine, son adresse, et autres coordonnées


(compte bancaire…), aussi il faut changer la devise vers le Dirham, pour que les prix et les

factures soient bien affichés ultérieurement, selon le contexte marocain.

5.4.2 Plan comptable

Toute application fonctionnant sous OpenERP, il faut spécifier un plan comptable à

utiliser pour la génération des différentes écritures comptables et journaux de comptabilité.

Pour le plan comptable de ce projet, j’ai choisi le plan comptable général d’OpenERP

par défaut pour enregistrer les différentes écritures comptables dans leurs journaux respectifs,

en raison de sa simplicité d’utilisation. Il existe bien sûr un plan comptable marocain pour

OpenERP, mais il y a eu beaucoup d’erreur lors des tests avec ce dernier, ce qui m’a poussé à

revenir vers le plan par défaut.

5.4.3 Produit

Les produits contiennent un bon nombre d’attributs qui facilitent le paramétrage, ainsi

j’ai utilisé les attributs suivants :

Attribut Fonction

Name Nom du produit

reference Code du produit

Ean13 Code à barre du produit

Categ_id Catégorie du produit, utile pour le calcul de son prix public sur la base de

liste de prix

Standard_price Prix d’achat

List_price Prix public

State Etat du produit

Pos_categ_id Forme du produit, utile pour le classement des produits dans le point de

vente, ce qui facilite leur recherche

posologie Posologie du produit

Dcis Liste des DCIs du produit

Cis Liste des contre indications du produit Tableau 4 : attributs du produit

5.4.4 Méthodes de paiements :

Avant de pouvoir passer au point de vente, il faut d’abord configurer les méthodes de

paiements qu’on souhaite mettre à disposition, puis ensuite ouvrir les caisses, on peut ouvrir

toutes les caisses à la fois, ou choisir d’ouvrir que quelques unes, dans le cas où il n’est pas

possible d’effectuer un certain type de paiement, du à une panne matérielle par exemple.

Pour créer les méthodes de paiements il faut se connecter en tant qu’administrateur puis

se rendre au backend du point de vente, là on pourra configurer les méthodes de paiement

qu’il nous faut.

Une méthode de paiement est caractérisée par : (voir la page suivante)


Attribut Fonction

Name Nom de la méthode

Code Code de la méthode

Type Type sur lequelle se base la méthode : liquidité, ventes, banques et

chèques…

Default_credit_account_id Indique le journal de crédit utilisé pour cette méthode

Default_debit_account_id Indique le journal de débit utilisé par défaut

View_id Indique la vue à utiliser pour afficher les entrées dans le journal Tableau 5: Attributs de la méthode de paiement


5.5 Simulation

Dans cette partie je présente quelques captures d’écran de l’application pour montrer les

fonctionnalités qu’elle offre. Les captures ci-dessous ont été faites sur une nouvelle base de

données, avec un produit exemple. Je travaille maintenant sur l’importation d’une liste de

produits fournie par le client à cette base pour ensuite livrer une base de données complète, ne

nécessitant ni nouveau paramétrage ni nouvelle importation de données.

5.5.1 Gestion de base

La gestion de base concerne les objets élémentaires, comme les utilisateurs, les

produits, les médecins…

Figure 14: Gestion des utilisateurs

Figure 15: Gestion des groupes


Figure 16: Liste des médecins

Pour faciliter l’utilisation de l’application, des info-bulles s’affichent lorsqu’on survole

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

renseigner.

Figure 17: Formulaire médecin

Figure 18:Formulaire patient


5.5.2 Gestion des achats

Les figures suivantes montrent la gestion des achats, qui comprend l’édition et validation

de bons de commande, effectuer des réceptions de produit.

Figure 19: Bons de commande fournisseur

En créant un bon de commande, on sélectionne un fournisseur auquel il est adressé,

ensuite on ajoute les produits qu’on souhaite commander auprès de lui, on peut aussi choisir

la méthode de facturation si elle doit être basée sur le bon de commande ou sur les réceptions

des produits.

Les réceptions peuvent se faire sur bons de commande, ou tout simplement sans origine.

Si une réception est basée sur un bon de commande validé, et qu’elle contient une quantité

inférieure à celle demandée, la réception est dupliquée, avec comme origine le même bon de

commande, mais cette fois elle contient la différence entre la quantité demandée et celle

reçue.


Figure 20: Liste des réceptions

5.5.3 Gestion des ventes

Dans ce volet nous pouvons consulter la liste des clients, voir les détails de chaque client

et autres actions en relation.

Figure 21: Formulaire client

Comme le montre la figure ci-dessus, nous pouvons voir, en plus des informations de

base du client, la situation du crédit de ce client, comme il nous est possible d’afficher ses

factures, bons de commandes ou chiffre d’affaire mensuel.


5.5.4 Gestion du stock

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

physiques par exemple :

Figure 22: Gestion des inventaires physiques

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

stocks » :

Figure 23: Liste des mouvements de stock

On peut aussi définir les règles de stock minimum des produits, à condition qu’on ait

spécifié le fournisseur dans la fiche du produit, pour qu’ensuite dès qu’un produit franchit la

limite définie, un bon de commande est automatiquement créé et est envoyé au fournisseur

quand le planificateur est lancé.


Figure 24: Liste des règles de stock minimum

Le formulaire du produit, après extension, devient comme le montre la figure suivante

Figure 25: Formulaire produit – I


Figure 26: Formulaire produit - II

Quand la quantité d’un produit descend en dessous de celle définie dans les règles de

stock minimum (par défaut 0), le produit s’affiche en rouge dans la liste des produits, voir la

figure ci-dessous.

Figure 27: Produit en stock d'alerte

Il nous est possible de faire une analyse des mouvements de stocks, on peut aussi

personnaliser cette analyse, en y ajoutant quelques filtres et groupements.

Figure 28: Analyse des mouvements de stocks


5.5.5 Comptabilité

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

Figure 29: Liste des factures clients

A travers ce module nous pouvons suivre de près les règlements de factures des

clients, voir les factures qui n’ont pas encore été validés, comptabiliser les factures payées…

Figure 30: Détails facture client

Ces factures client sont utiles lorsqu’on effectue une vente par crédit, car la facture reste

ouverte tant qu’elle n’est pas payée, son montant s’ajoute au crédit du client concerné, et ne

sera comptabilisée qu’après son paiement.


Figure 31: Paiements clients

OpenERP considère les clients et fournisseurs comme étant une seule entité : partenaire,

avec un attribut qui désigne si ce dernier est client ou fournisseur, donc les factures et

paiements pour les fournisseurs ont la même présentation que celle des clients.

Autres fonctionnalités possibles dans ce module, c’est la gestion des méthodes de

paiements, différents journaux de comptabilités, on peut même changer de plan comptable et

utiliser un autre.

Ce volet de comptabilités offre aussi la possibilité de générer des rapports et des analyses

des écritures comptables, journaux et factures, comme le grand livre ou le bilan, il offre aussi

une analyse générale de la société, donnant ainsi des idées plus claires sur la situation

financière de l’officine.


5.5.6 Point de vente

La version 6.1 d’OpenERP a apporté de grands changements pour le module du point de

vente, résultant en une meilleure ergonomie et une grande interactivité et support des

différents outils communs dans les petits commerces.

Figure 32: Point de vente

Cette nouvelle interface, complètement écrite en javascript, offre plusieurs façons de

rechercher un produit : à partir du nom, code, ou code à barre, la recherche avec code à barre

est plus pratique en utilisant la douchette qui lit ce dernier directement sur le médicament.

Elle permet d’effectuer plusieurs types de paiements à la fois, comme payer la moitié

d’un ticket en espèces, l’autre moitié avec une carte de crédit…

Figure 33: Paiement en espèces


Le lancement du point de vente vérifie s’il existe des méthodes de paiement enregistrées,

ensuite il vérifie s’il y a des caisses basées sur ces méthodes qui sont ouvertes, le cas échéant

un assistant demande si on souhaite ouvrir les caisses, si on confirme, de nouvelles caisses

sont créées, et nous pouvons nous lancer dans la vente.

Figure 34: Assistant d'ouverture des caisses

Si aucune méthode de paiement n’est enregistrée, on ne pourra pas effectuer de ventes,

nous aurons donc à retourner au backend pour créer les méthodes qui nous conviennent.

Figure 35: Liste des méthodes de paiement

Figure 36: Formulaire de création/modification d'une méthode de paiement


Une fois nos méthodes définies, nous pouvons ouvrir les caisses automatiquement à

l’aide de l’assistant, nous aurons dans ce cas de nouvelles caisses vides, chacune

correspondante à une méthode de paiement déjà enregistrée, sinon nous pouvons les créer

manuellement et les ouvrir ensuite.

Figure 37: Liste des caisses

Une des fonctionnalités ajoutées à ce module est l’ordonnancier, où on effectue des

ventes sur ordonnance, pour y accéder, il faut aller dans le backend du point de vente, puis

créer une nouvelle vente.

Figure 38: Journal des ventes

Figure 39: Ordre de vente


L’onglet « ordonnance » ajouté, permet de renseigner le nom du médecin ayant rédigé

l’ordonnance, ainsi que le patient à qui elle est destinée. Les lignes de vente peuvent

correspondre à l’ordonnance elle-même, ou seulement des lignes de vente « libre ». Ce qui

explique l’ajout d’une case à cocher si la ligne correspond à une ordonnance ou non, et l’ajout

du champ « total ordonnance » qui calcule le total des lignes d’ordonnance.

Figure 40: Renseignement des informations d'ordonnance

Les produits dans le point de vente sont classés par catégorie, ce qui facilite leur

recherche. Une catégorie du point de vente peut avoir une catégorie mère, on obtient donc une

hiérarchie de catégorie.

Figure 41: Catégories des produits - point de vente

Le module « point de vente » offre aussi des statistiques et des analyses concernant ses

ventes.


Figure 42: Analyse du point de vente par produit

Il est aussi possible de voir ces analyses par utilisateur :

Figure 43: Analyse des enregistreuses par utilisateur

5.6 Problèmes rencontrés

Lors de la simulation, quelques bugs ont été rencontrés, comme par exemple la recherche

multi critère des médicaments dans le point de vente où seule la recherche par nom était

possible.

Après plusieurs lectures et relectures du code, et après plusieurs recherches sur internet,

notamment sur le launchpad, site où la communauté des chercheurs et développeurs

d’OpenERP signalent les différents problèmes des versions publiées, j’ai pu trouver des

correctifs à appliquer au module pour profiter de ces fonctionnalités.

Le problème a été du au fait que le module a été complètement rénové, et que sa date de

publication était très récente (février 2012).


Conclusion

Ce stage de fin d’études a été, encore une fois, une occasion pour moi pour côtoyer le

monde de l’entreprise, mais avec plus de responsabilités cette fois-ci.

Coté technique, le travail réalisé jusqu’ici permet une gestion interne d’une officine, et

peut être étendu en développant le concept d’ « échanges » entre confrères pharmaciens, ou

encore en intégrant OpenERP chez les grossistes, fournisseurs de produits aux pharmaciens,

et lier ces deux solutions pour automatiser les commandes de médicaments par exemple.

Le module développé pourra maintenant subir des tests plus importants que ceux

réalisés par moi-même pendant son développement, c'est-à-dire passer à une phase béta, où

une liste de produits contenant toutes les informations nécessaires des médicaments sera

importée, ensuite il sera installé dans une officine, et sera utilisé en parallèle avec le logiciel

de gestion existant déjà, pour juger de son efficacité et de sa facilité d’utilisation.

Coté personnel, travailler dans le monde de l’open source, et plus précisément sur un

PGI tel que OpenERP m’a permis d’apprendre plus sur ces domaines, notamment le langage

python et l’utilisation du framework « OpenObject », et de rejoindre une communauté

mondiale de plus de 1500 individus impliqués eux aussi dans la recherche et le

développement de nouveaux modules, afin de faciliter l’intégration d’une telle solution dans

tous les domaines professionnels et sociaux.

A travers ce projet, j’ai pu voir l’importance des logiciels libres pour les PME

marocaines, surtout leur capabilité à satisfaire un bon nombre de besoins fonctionnels, tout

ceci à faibles coûts, ce qui permet leur croissance dans leur marché et garantir leur durabilité

face à la concurrence.


Bibliographie & webographie

Bibliographie

- Rapport du projet de fin d’études de MOUNIR Majid, ENSA de Tanger

- OpenERP, pour une gestion d’entreprise efficace et intégrée (Eyrolles)

- Open Object Developer Book (Tiny SPRL)

- OpenERP : a modern approach to integrated business management based on a

free Open Source software system (Geoffrey S. Gardiner and Fabien Pinckaers)

- Programmation python (édition 2), (Eyrolles)

Webographie

- http://www.theopensourcerer.com/2012/02/22/how-to-install-openerp-6-1-on-

ubuntu-10-04-lts

- http://www.easyopenerp.com/principales-nouveautes-de-la-version-6-1/

- http://www.ibcscorp.com/application-integration-customization/erp/openerp-

2/openerp-custom-module-development-quick-start-guide/

- http://planet.domsense.com/docs/openerp-web/en/addons.html

- https://code.launchpad.net/~guerrerocarlos/openobject-

addons/point_of_sale_6.1_barcode__merge/+merge/99129 (fix pr recherche ac

code à barre)

- http://mohsinpage.wordpress.com

- http://www.docstoc.com/docs/21264701/OpenERP-User-Manual

- http://blip.tv/openerp-support


Annexe A

Introduction au développement de modules OpenERP avec le framework « Open Object »


INTRODUCTION AUX OBJETS

Toutes les données d'OpenERP sont accessibles par les objets: c’est à dire pour la

création d'un module, on ne manipule pas les données directement car les objets sont eux qui

créent les tables de base de données contenant les données d'OpenERP via « ORM » (Object

Relational Mapping).

Par exemple: il existe dans le module de base d'OpenERP, l'objet res.partner qui

permet d'accéder aux informations concernant les partenaires. Aussi il y'a dans le module de

base account, l'objet d'OpenERP account.invoice pour accéder aux données relatives à la

facture. Tous ces objets se trouvent dans des fichiers d'extension .py.

On signale qu'il y'a un objet pour chaque type de ressource et non un objet pour une

ressource, ainsi un il y'a un unique objet res.partner pour manipuler tous les partenaires

(dans ce cas les ressources) et on ne peut pas avoir l'objet res.partner pour chaque partenaire:

parlons aux termes d'orienté objet pour bien assimiler cette notion, on peut dire que l'objet

d'OpenERP est considéré comme la classe et les ressources sont les instances de cette classe

c’est à dire les objets. Et si on parle du coté de la base de données les objets d'OpenERP sont

les tables de la BD et les lignes des tables sont les ressources. Donc une table (un objet

d'OpenERP) comprend plusieurs lignes (Ressources d'openErp).

Une conséquence directe de cette notion objet-ressources est que toutes les méthodes

des objets ont un paramètre commun : le paramètre ids. Il spécifie sur quelles ressources la

méthode s'appliquera: précisément ce paramètre contient une liste des identificateurs des

ressources (ids) sur laquelle la méthode s'appliquera.

Par exemple, si on a deux ressources partenaires avec les identificateurs 1et 2 (les

identificateurs de ressources sont les id des lignes de la table qui correspond à l'objet qui

manipule ces ressources) et aussi nous voulons appeler la méthode d'objet res.partner qui est

send_email, nous procédons comme suit: res_partner.send_email(..., [1, 2], ...)

Ultérieurement dans ce support, nous verrons comment appeler les méthodes d'objets

et les quelques méthodes propres d'OpenERP.

Un rappel important pour les programmeurs :

- Les objets d'OpenERP sont appelés classes si on parle au terme de la

programmation orientée objet

- Et une ressource est appelée objet, l'instance de la classe.

Definition des objets en OpenERP

Pour définir un nouvel objet, on définit une nouvelle classe et après on l'instancie,

cette classe doit hériter de la clase OSV du module OSV d'OpenERP.


Ainsi, la première ligne de la définition de l'objet sera toujours comme suivant:

class nom_objet(osv.osv):

_name = 'nom de l'objet'

_columns = {...}

...

nom_objet()

Donc, l'objet se définit en déclarant quelques attributs avec des noms prédéfinis dans

la classe, deux de ces attributs sont obligatoires à savoir _columns et _name, les autres sont

optionnels. Les attributs prédéfinis sont:

- _auto: Prend True /False et détermine si la table correspondante dans postgres

doit se générer automatiquement à partir de cet objet. Mettre _auto=False

pourra être utile dans les cas ou on veut créer objets basés sur des vues de

postgresql sans créer des tables.

- _columns(obligatoire): on y définit les champs(les attributs de la classe si on

parle au terme d'orienté objet) de l'objet

- _constraints: on y détermine des restrictions sur l'objet (on en parlera

ultérieurement)

- _defaults: on définit les valeurs par défaut pour quelques champs de l'objet.

- _inherit: on met l'objet père que l'actuel objet hérite. On va le détailler dans

deux types:

o ORM - Object Declaration - _inherit (1) : Réalise un héritage d'un objet

existant, mais crée un nouvel objet, exemple :

class formateur(osv.osv):

_name = 'formateur'

_inherit = 'res.partner'

_columns = {

'lang_ids' : fields.many2many('res.lang',

'res_lang_partner_rel',

'partner_id', 'lang_id', 'Languages')}

formateur()

o ORM - Object Declaration - _inherit (2) : Réalise un héritage d'un objet

existant, ajoute des caractéristiques à l'objet dont nous héritons,

exemple :

class res_partner_add_langs(osv.osv):

_name = 'res.partner'

_inherit = 'res.partner'


_columns = {

'lang_ids' :

fields.many2many('res.lang','res_lang_partner_rel',

'partner_id', 'lang_id', 'Languages')}

res_partner_add_langs()

- _name(obligatoire): le nom de l'objet, la valeur par défaut est None

- _order: on met le nom du champ de l'objet actuel qui sera comme critère de tri

des résultats des méthodes search et read. Sa valeur par défaut est 'id'

- _sql: on met le code sql pour l'exécuter dans la création de l'objet (seulement si

_auto=True)

- _table: nom de la table sql correspondante a cet objet, sa valeur par défaut est

celle de _name en remplaçant les points (.) par des tirets (_)

Les champs des objets

Les objets peuvent contenir différents types de champs. Ces types s'articulent dans

trois catégories: types simples, types relationnelles et champs fonctionnels.

Les types simples englobent les entiers, les réels, les booléens et les chaines de

caractère…, les champs de type relationnel permettent de représenter les relations entre les

objets (one2one, many2one, many2many). Les champs fonctionnels sont des champs

spéciaux parce qu'ils ne sont pas enregistrés dans la base de données mais plutôt sont

calculables à partir d'autres champs dans le temps réel.

La signature de la méthode d'initialisation de la classe dont hérite tout champ déclaré

dans OpenERP( ..... /osv/fields.py).

def init (self, string='unknown', required=False, readonly=False, domain=[],

context="", states={}, priority=0, change_default=False, size=None, ondelete="set null",

translate=False, select=False, **args) :

Ainsi les paramètres optionnels communs pour tous les types de champs sont comme

suit:

- change_default: (True/False) quand ce champ prend la valeur booléenne

True, le programme permet à l'utilisateur d'établir des valeurs par défaut dans

autres champs qui dépendent de la valeur de ce champ. Sa valeur par défaut

est: False. Exemple:(dans res.partner.adress)

- 'zip': fields.char('Zip', change_default=True, size=24), dans ce cas, les

utilisateurs peuvent mettre des valeurs par défaut dans les champs de la vue qu

dépendent du champs 'Zip'(code postale). Par exemple, l'utilisateur peut

programmer que le programme remplit automatiquement le champ 'city' à

Barcelone si le code postale prend la valeur '08000'.

- help: montre un message d'aide lorsque la souris est au-dessus de ce champ.

Exemple: 'name': fields.char('name', help='le nom s'affiche.'),


- Readonly:(True/False) détermine si le champ sera éditable ou non. Valeur par

défaut=False

- required: (True/False) détermine si le champ est obligatoire ou non,

signalons que OpenERP refuse d'enregistrer une ressource si un champ

obligatoire est vide. Donc il est obligatoire de remplir tous les champs

obligatoires avant d'enregistrer une ressource. Valeur par défaut=False

- states: ce paramètre permet de définir des autres attributs pour ce champs qui

seront disponibles selon des états déterminés de la ressource. Format: states=

{'état de la ressource': [liste des attributs]} Avec liste des attributs est une

liste de tuples de la forme: [('nom de l'attribut', valeur), ...]. Valeur par

défaut ={}

Exemple: (dans account.transfer)

'partner_id': fields.many2one('res.partner', 'Partner', states={'posted

[('readonly',True)]}),

Dans cet exemple, lorsque l'état de la ressource est 'posted', l’attribut

‘partner_id’ sera en lecture seule.

- String: c'est l’étiquette du champ. Valeur par defaut=unknown

- translate: (True/False) détermine si ce champ doit être traduit.(géré par le

système de traduction). Valeur par défaut=False

Finalement, voici les paramètres optionnels spécifiques pour quelques types de

champs :

- domain: sert a restreindre le domaine des ressources, ce paramètre est valide

seulement pour les champs de type relationnel. Valeur par défaut=[]

Exemple: domain=[('nom','=',valeur)])

- invisible: (True/False) pour cacher la valeur du champ dans les formulaires

(mots de passes…). Valeur par défaut=False

- selection: sert à sélectionner le niveau de recherche par défaut dans les vues.si

ce paramètre prend la valeur '1', ceci signifie que le champs toujours apparaît

dans le filtre de recherche dans la vue qui manifeste ce champs. Et s'il prend

'2', le champ apparaît seulement dans la recherche avancée qui se manifeste

lorsqu'on clique sur le symbole +

- on_change: lance une fonction (définit sur l'objet ORM qui contient ce champ)

quand la valeur de ce champ change dans une vue. Exemple: on_change =

"onchange_shop_id(shop_id)”

Types de champs :

Champs simples:

- boolean: le champ boolean prend deux valeurs (True/False)

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

- integer : si la valeur voulue est un entier.

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

- Float : si la valeur voulue est un nombre flottant (réel).


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

Note: il y'a un paramètre spécifique digit pour le champ de type float, ce paramètre précise le

nombre de chiffres après la virgule et précise le nombre des chiffres significatif c’est à dire le

nombre de chiffres après et avant la virgule.

Exemple:

'rate' : fields.float('le taux', digits=(12,6) [, Parametres optionnels])

- char: Une chaine de caractères de longueur limitée. Le paramètre obligatoire

size détermine sa longueur

Syntaxe : fields.char('Nom du champs', size=n [, Parametres optionnels]), ou n

est un entier.

- text: un texte de longueur illimitée

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

- Date : ce champs détermine la date .

Syntaxe : fields.date('Nom du champs' [paramétres optionnels, ]),

- datetime : Permet l'édition de la date et l'heure dans le même champ.

Syntaxe : fields.datetime('Nom du champs' [paramétres optionnels, ]),

- Binary: pour l'image, Exemple : 'image': fields.binary('Image')

- selection: ce champ permet à l'utilisateur de sélectionner plusieurs valeurs

prédéfinis.

Syntaxe:fields.selection([('n','non confirmé'), ('c','Confirmé')], 'Nom du

champs' [, paramètres optionnels]),

Remarque: le format du paramètre de sélection est une liste de tuples:[('clé', 'chaine de

caractère à montrer'), ...] ou la clé s'enregistre dans la ligne de la table (correspondante à

l'objet qui contient le champ) comme une valeur prédéfinie.

Champs fonctionnels:

Le champ fonctionnel est un champ dont la valeur est calculée par une fonction (au

lien de s'enregistrer dans la base de données). Dans les cas spéciales (pour faciliter la

recherche ou la consultation) les champs de type fonctionnel peuvent être sauvegardés dans la

base de données avec le paramètre STORE (il va prendre la valeur booléenne True). Ils sont

actualisés par les fonctions et non par les utilisateurs.

Paramétres: fnct, arg=None, fnct_inv=None, fnct_inv_arg=None, type="float,

fnct_search=None, obj=None, method=False,

- fcnt_inv: Fonction inverse pour écrire

- fcnt_search: Fonction permettant de réaliser une recherche sur le champ

method: Si True, il s'agit d'une méhode d'instance d'openErp, sinon, fonction

- type: Indique le type d'élément (char, integer, float, boolean, date, datetime)

- store: Si True, stocke dans la base de données la valeur du champ(par défaut

False)


fnct: c'est la fonction qui calcule la valeur du champs avec une méthode d'openErp ou

une fonction globale,Si method=True,la signature de méthode sera comme suit:

def fnct(self, cr, uid, ids, field_name, arg, context)

Exemple:

_columns = {

'avg': fields.function(_get_average_value, fcnt_inv=_something_write,

fcnt_search = _something_search, method=True,

string="Fields", type="float", store=True)

}

CHAMPS relationnels

ORM - Champs - Relationnel - one2many, exemple : Un instructeur donne plusieurs

formations

class openacademy_instructor(osv.osv):

_name = 'openacademy.instructor'

_columns = {

'training_ids' : fields.one2many('openacademy.training',

'instructor_id', 'Trainings')

}

ORM - Champs - Relationnel - many2one, exemple : plusieurs formations sont données

par un instructeur

_columns = {

'instructor_id' : fields.many2one('openacademy.instructor',

'Instructor')

}

ORM - Champs - Relationnel - many2one & one2many

Comment retenir la différence ?

- Champ many2one: plusieurs (many) de ces objets sont possèdés par un (one)

objet parent

- Champ one2many: l'objet (one) possède plusieurs (many) enfants


ORM - Champs - Relationnel - many2many, exemple :

_columns = {

'participant_ids' : fields.many2many('openacademy.participant',

'openacademy_training_participant_rel', 'training_id',

'participant_id', 'Participants')

}

- Un participant peut suivre plusieurs formations

- Une formation est donnée à plusieurs participants

ORM – Méthodes spéciales – Méthodes prédéfinies

Méthodes prédéfinies :

- create: Création d'un enregistrement

- write: Mise à jour d'un enregistrement

- unlink: Suppression d'un enregistrement

- read: Lecture de champs d'un enregistrement

- copy : Duplication d'un enregistrement

- search: Recherche d'enregistrement

- browse: Récupération d'enregistrement via critères de recherche

- name_get: Retourne uniquement que le nom et l'identifiant du record

- name_search: Réalise une recherche du nom sur base d'un domaine

- init : Permet de créer une vue si _auto = False

- _auto_init : Permet de créer un index ou un objet SQL si nécessaire

adaptation et integration d’openerp pour la gestion d’officine

Technology