OpenERP - Gestion de prix de revient

Dédicace

Je dédie ce modeste travail à

Mes parents, qui n'ont jamais cessé de m'encourager et me soutenir,

Mon frère Mouhamed, et ma s÷ur Soumaya

Tous les membres de ma famille,

Mes Collègues : Naceur, Cherif, Foued, Amine, Mourad

Tous mes amis,

Et ceux qui me sont chers.

Taieb

Remerciements

Je tiens à remercier chaleureusement l'ensemble des personnes qui ont contribué de

prêt ou de loin à l'élaboration de ce projet qui a été pour moi très enrichissant tant au

niveau formation que sur le plan personnel.

Je remercie Mr Faouzi BEN CHARRADA, pour son suivi de près de l'avance-

ment de ce projet, pour les conseils judicieux qu'il n'a cessé de me prodiguer.

Je remercie Mr So�en KARRAY, qui m'a encadré, avisé et motivé de façon

continue et qui m'a o�ert cette chance de poursuivre ce stage très béné�que.

Je remercie, également, tout le cadre administratif et les professeurs de la FST pour

la formation de qualité et l'ambiance qu'ils ont su instaurer pendant toutes mes années

d'études.

En�n, je tiens à exprimer mon amitié et mon respect profonds envers tous mes

collègues de la FST.

Table des matières

Dédicace i

Remerciements ii

Table de Matières iii

Table des �gures vi

Liste des tableaux viii

Introduction générale 1

1 Présentation du projet 3

Conclusion 3

1.1 Organisme d'Accueil : OpenIOS Consulting . . . . . . . . . . . . . . . . . . 3

1.1.1 Domaine d'activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.2 Organisation d'OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Progiciel de Gestion Intégré . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.2 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5.1 Langage de modélisation : UML . . . . . . . . . . . . . . . . . . . . 11

1.5.2 Processus de développement . . . . . . . . . . . . . . . . . . . . . . 12

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 État de l'art 14

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Module � Gestion des Articles � . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Module � Comptabilité et Finance � . . . . . . . . . . . . . . . . . . . . . 16

2.3 Module � Gestion des achats � . . . . . . . . . . . . . . . . . . . . . . . . 18

iii

TABLE DES MATIÈRES iv

2.4 Module � Gestion de Production � . . . . . . . . . . . . . . . . . . . . . . 19

2.5 Module � Gestion de stock � . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6 Processus de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6.1 Réception par achat . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6.2 Réception par production . . . . . . . . . . . . . . . . . . . . . . . 23

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Analyse et spéci�cation des besoins 27

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Analyse de l'existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 Méthode de coût basé sur le � Dernier prix � . . . . . . . . . . . . . 27

3.1.2 Consultation des articles . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.3 Prix moyen pondéré et le dernier prix . . . . . . . . . . . . . . . . . 28

3.1.4 Valorisation du coût de fabrication d'un article . . . . . . . . . . . . 28

3.1.5 Changement automatique du prix de revient . . . . . . . . . . . . . 28

3.2 Étude de besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Diagramme de cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3.1 Identi�cation des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3.2 Diagramme de cas d'utilisation global . . . . . . . . . . . . . . . . . 32

3.3.3 Diagramme de cas d'utilisation � Gérer article � . . . . . . . . . . . 34

3.3.4 Diagramme cas d'utilisation � Recevoir article � . . . . . . . . . . . 35

3.3.5 Diagramme cas d'utilisation � Gérer Demande de changement des

prix � par le gestionnaire de stock . . . . . . . . . . . . . . . . . . . 36

3.3.6 Diagramme de cas d'utilisation � Créer Demande de changement

des prix � . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.7 Diagramme cas d'utilisation � Gérer Demande de changement des

prix � par le Manager . . . . . . . . . . . . . . . . . . . . . . . . . 39

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Conception 41

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.1 Diagramme de séquence � Modi�er méthode de coût � . . . . . . . 45

4.2.2 Diagramme de séquence � Actualiser historique � . . . . . . . . . . 46

4.2.3 Diagramme de séquence � Recevoir articles achetés � . . . . . . . . 47

4.2.4 Diagramme de séquence � Fabriquer article � . . . . . . . . . . . . 48

4.2.5 Diagramme de séquence � Charger par ajout article � . . . . . . . . 49

TABLE DES MATIÈRES v

4.2.6 Diagramme de séquence � Charger par assistant � . . . . . . . . . . 49

4.2.7 Diagramme de séquence � Calculer les valeurs des comptes comp-

tables � . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.8 Diagramme de séquence � Valider demande � . . . . . . . . . . . . 52

4.3 Diagramme d'états-transitions . . . . . . . . . . . . . . . . . . . . . . . . . 52

Conclusion 53

5 Étude technique et Réalisation 54

Conclusion 54

5.1 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1.1 Outil de conception : PowerAMC . . . . . . . . . . . . . . . . . . . 54

5.1.2 Système de gestion de base de données : PostgreSQL . . . . . . . . 55

5.1.3 Éditeur de texte : Notepad++ . . . . . . . . . . . . . . . . . . . . . 56

5.1.4 Éditeur de catalogues textuels : PoEdit . . . . . . . . . . . . . . . . 57

5.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.1 Framework OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.2 Langage de programmation : Python . . . . . . . . . . . . . . . . . 61

5.2.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.4 RML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.5 Fichier PO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.1 Gestion des articles . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.2 Gestion des Demandes . . . . . . . . . . . . . . . . . . . . . . . . . 66

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Conclusion générale 72

Bibliographie ix

Webographie x

Table des �gures

1.1 OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Organigramme OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Modules OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5 Architecture multi-tiers d'OpenERP . . . . . . . . . . . . . . . . . . . . . 7

1.6 Protocole XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.7 Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Formulaire� Créer article � . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Formule de Prix moyen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Formulaire � Créer Catégorie � . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Module � Comptabilité et �nance � . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Module � Gestion des achats � . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6 Formulaire � Créer Bon de commande � . . . . . . . . . . . . . . . . . . . 19

2.7 Module � Gestion de production � . . . . . . . . . . . . . . . . . . . . . . 19

2.8 Module � Gestion de stock � . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.9 Interface � Réception du bon de commande � . . . . . . . . . . . . . . . . 22

2.10 Assistant � Réception par article � . . . . . . . . . . . . . . . . . . . . . . 23

2.11 Formulaire � Créer Ordre de fabrication � . . . . . . . . . . . . . . . . . . 24

2.12 Assistant � Créer Nomenclature � . . . . . . . . . . . . . . . . . . . . . . . 24

2.13 Assistant � Fabriquer � . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.14 Interface Article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Méthode de coût . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Changement automatique de prix de revint . . . . . . . . . . . . . . . . . . 29

3.3 Diagramme de cas d'utilisation global . . . . . . . . . . . . . . . . . . . . . 32

3.4 Diagramme de cas d'utilisation � Gérer article � . . . . . . . . . . . . . . . 34

3.5 Diagramme cas d'utilisation � Recevoir article � . . . . . . . . . . . . . . . 35

3.6 Diagramme cas d'utilisation � Gérer demande de changement des prix � . 36

3.7 Diagramme cas d'utilisation � Créer Demande � . . . . . . . . . . . . . . . 37

vi

TABLE DES FIGURES vii

3.8 Diagramme cas d'utilisation � Gérer Demande de changement � par le

Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Diagramme de séquence � Modi�er méthode de coût � . . . . . . . . . . . 45

4.3 Diagramme de séquence � Actualiser historique � . . . . . . . . . . . . . . 46

4.4 Diagramme de séquence � Recevoir article acheté � . . . . . . . . . . . . . 47

4.5 Diagramme de séquence � Fabriquer article � . . . . . . . . . . . . . . . . 48

4.6 Diagramme de séquence � Charger par ajouter article � . . . . . . . . . . . 49

4.7 Diagramme de séquence � Charger par assistant � . . . . . . . . . . . . . . 50

4.8 Diagramme de séquence � Calculer les valeurs des comptes comptables � . 51

4.9 Diagramme de séquence � Valider demande � . . . . . . . . . . . . . . . . 52

4.10 Diagramme d'état-transition � Demande de changement � . . . . . . . . . 53

5.1 Logo PowerAMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 Logo PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3 Logo Notepad++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.4 Logo PoEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5 Module OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.6 ORM d'OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.7 Objet OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.8 Logo Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.9 Les sections d'un �chier RML . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.10 Intégration des méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.11 Premier réception � article_Prix moyen � . . . . . . . . . . . . . . . . . . 64

5.12 Deuxième réception � article_Prix moyen � . . . . . . . . . . . . . . . . . 65

5.13 Réception � article_Dernier prix � . . . . . . . . . . . . . . . . . . . . . . 65

5.14 Historique Prix de revient . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.15 Module Changement des prix . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.16 Ajouter article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.17 Données articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.18 Barre d'état d'une demande . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.19 Assistant � Charger Liste � . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.20 Consulter Compte Comptable . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.21 Valider les changements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.22 Changement de prix de revient . . . . . . . . . . . . . . . . . . . . . . . . 70

5.23 Rapport � Changement des prix � . . . . . . . . . . . . . . . . . . . . . . . 71

Liste des tableaux

1.1 Tableau comparatif des méthodes de développement . . . . . . . . . . . . . 12

2.1 Calcul Prix moyen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Fonctionnalités du Module � Comptabilité et Finance � . . . . . . . . . . . 17

2.3 Fonctionnalités du Module � Gestion des Achats � . . . . . . . . . . . . . . 18

2.4 Fonctionnalités du Module � Gestion de production � . . . . . . . . . . . . 20

2.5 Fonctionnalités du Module � gestion de stock � . . . . . . . . . . . . . . . 21

3.1 Acteurs principaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

viii

Introduction générale

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 infor-

matiques pour remédier aux di�érentes problématiques réelles.

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

répondues à 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 intégré, les utilisateurs de di�é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'infor-

mation, ainsi que la réduction des temps de traitement.

OpenIOS Consulting, société au sein de laquelle nous avons e�ectué notre stage de �n

d'études, propose à ses clients un ERP basé sur le logiciel libre � OpenERP � pour lequel

elle peut développer des besoins spéci�ques pour chacun d'entre eux.

Au cours de ce stage, notre travail a consisté à comprendre le fonctionnement de

l'OpenERP, à concevoir et développer un module de gestion des prix des articles de stock

totalement intégré dans ERP et développé avec les outils et les concepts fournit par la

communauté OpenERP.Ce module vient d'ajouter une nouvelle fonctionnalité à la pro-

blématique de gestion de stock exigé dans le contexte des sociétés locales tunisiennes.

A�n d'illustrer la démarche de notre travail, nous présentons dans ce qui suit l'organi-

sation générale du présent rapport qui s'articule autour de cinq chapitres. Dans le premier

chapitre, nous présenterons le cadre du projet à travers une présentation de la société,

des généralités autour des ERP et OpenERP permettant de mieux cadrer notre travail,

la problématique et le choix méthodologique. Ensuite, nous présenterons dans le chapitre

suivant l'état de l'art a�n de clari�er les di�érents modules liés à la gestion de stock. Le

troisième chapitre sera consacré à la partie analyse où nous élaborerons une étude de l'exis-

tant et une spéci�cation des besoins fonctionnels et non-fonctionnels. Dans le quatrième

chapitre qui concerne la conception, nous présenterons les di�érents diagrammes statiques

1

LISTE DES TABLEAUX 2

et dynamiques ainsi que l'architecture globale de la solution. Le cinquième chapitre est

réservé à l'étude technique où nous présenterons les outils et les technologies utilisées, et

nous présenterons les interfaces à l'aide des captures écrans avec les explications. Pour

conclure, nous présenterons les connaissances acquises durant ce stage et nous proposons

un ensemble de perspectives à ce travail.

Chapitre 1

Présentation du projet

Introduction

Dans ce premier chapitre, nous allons présenter le cadre général du projet. Pour

ce faire, nous allons présenter, dans un premier lieu, l'entreprise d'accueil. Ensuite, nous

introduisons les ERP et le progiciel OpenERP utilisé dans cette entreprise, ainsi que la

présentation du projet : la problématique, les objectifs et la méthodologie du travail.

1.1 Organisme d'Accueil : OpenIOS Consulting

Figure 1.1 � OpenIOS

Le projet a été réalisé au sein de la société OpenIOS située aux Berges du Lac.

Fondée en 2011, OpenIOS est une société tunisienne active dans le domaine des systèmes

d'information spécialisée dans l'édition et l'intégration des logiciels Open Source. Résul-

tant d'une expérience de consulting de plus de 12 ans en gestion d'entreprise, OpenIOS

a adopté OpenERP comme solution ERP spéci�quement conçue pour les PME de services.

OpenIOS est un spécialiste des technologies de développement open source, Python

et Java, pour les plateformes OpenERP, J2EE, Servlets, JSP, Tomcat, JBOSS et IBM

Websphere Application Server. Le Framework de développement est basé sur des outils et

des composantes Open source adoptés par de nombreux éditeurs et entreprises d'envergure

internationale. [6]

3

CHAPITRE 1. PRÉSENTATION DU PROJET 4

1.1.1 Domaine d'activité

Les consultants d'OpenIOS accompagnent le client dans la gestion de son système

d'information et dans le pilotage de ses processus : du consulting au transfert de compé-

tences en incluant le paramétrage et l'intégration d'OpenERP avec d'autres applications

tierces.

Dans le but de fournir à chacun de ses clients un service sur-mesure et de qualité avec

une solution parfaitement adaptée à leurs besoins. Ainsi le domaine d'activité d'OpenIOS

tourne essentiellement autour du développement de logiciel sur-mesure et consulting, par-

ticulièrement touche les domaines suivants :

� Stratégie de Nouvelle Technologie dans le Système d'Information de client : service

de conseil visant à renforcer l'e�cacité des systèmes d'information des entreprises.

� Gestion électronique des documents et work�ow : en couvrant la dé�nition du �

roadmap � du projet de mise en place, l'assistance et l'accompagnement de mise en

place des systèmes GED/Work�ow, l'étude et la conception des processus métiers,

en utilisant les standards comme BPMN, et l'interaction de solutions � Lowcost �

en l'occurrence basés sur l'Open Source.

� Business Intelligence : proposition aux clients d'une ré�exion approfondie par le

biais d'une analyse de l'existant, d'une évaluation du gap et de la mise en place de

solutions simples de business intelligence.

� Management projet : Les chefs de projets OpenIOS apportent leurs savoir-faire dans

la conduite des projets a�n de respecter l'adéquation coût, délai et qualité.

� Développement autour d'OpenERP : basé sur OpenObject, un Framework modu-

laire, scalable et intuitif, c'est un � Rapid Application Development � (RAD) Fra-

mework écrit en Python.

� Développement Java : basé sur les serveurs d'application J2EE JBOSS et IBM

Websphere application server.

� Développement autour des plate-forme GED/Work�ow -IBM FileNet/ Alfresco : En

accumulant les projets de Gestion Electronique de Document, l'équipe d'OpenIOS

a conçu des composants qui facilitent le développement spéci�que autour de Filenet

et Alfreco.[6]


1.1.2 Organisation d'OpenIOS

Le diagramme suivant représente les di�érents services rattachés à une direction

générale :

Figure 1.2 � Organigramme OpenIOS

1.2 Progiciel de Gestion Intégré

1.2.1 ERP

L'acronyme ERP signi�e Enterprise Ressource Planning traduit en français par Pro-

giciel de Gestion Intégré ou PGI. ERP est le terme le plus couramment utilisé.

Un ERP est un progiciel qui permet de gérer d'une manière centralisée l'ensemble

des processus d'une entreprise intégrant l'ensemble de ses fonctions comme la gestion des

ressources humaines, la gestion �nancière et comptable, l'aide à la décision, la vente, la

distribution, l'approvisionnement, la production ou encore du e-commerce.

Le principe fondateur d'un ERP est de construire des applications informatiques cor-

respondant aux diverses fonctions citées précédemment de manière modulaire sachant que

ces modules sont indépendants entre eux, tout en partageant une base de données unique

et commune au sens logique. [7]

L'autre principe qui caractérise un ERP est l'usage de ce qu'on appelle un moteur de

work�ow et qui permet, lorsqu'une donnée est enregistrée dans le système d'information,

de la propager dans les modules qui en ont l'utilité, selon une programmation prédé�nie.


Ainsi, on peut parler d'ERP lorsqu'on est en présence d'un système d'information

composé de plusieurs applications partageant une seule et même base de donnés, par le

biais d'un système automatisé prédé�ni et éventuellement paramétrable, un moteur de

work�ow.

1.2.2 OpenERP

Figure 1.3 � OpenERP

Créée en 2002 par Fabien PINCKAERS, anciennement connu sous le nom Tiny

ERP, signi�ant la fourmi de l'Enterprise ,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.

Le principe du logiciel libre est la gratuité, mais aussi la possibilité d'accéder aux codes

des programmes, ce qui permet de les modi�er, de les adapter à volonté, à condition de

rendre publique la nouvelle version.

Grâce à la communauté open source, le catalogue de logiciels d'OpenERP s'était déve-

loppé bien plus rapidement que pour un éditeur de logiciels dits � propriétaires � (comme

ceux de SAP, Microsoft, Sage, Oracle. . .) : pas moins de 500 modules étaient déjà à dis-

position des entreprises. On notait déjà plus de 1000 installations par jour, devenant le

logiciel de gestion le plus installé au monde. OpenERP a�che en e�et une progression de

1542% de son chi�re d'a�aires en cinq ans , en passant de 500 modules, �n 2009, à 2200

proposé par la nouvelle version OpenERP 7, avec croissance qui passe 100% par an.[8]


Figure 1.4 � Modules OpenERP

OpenERP possède une structure modulaire qui permet d'ajouter de nouveaux modules

facilement pour étendre les fonctionnalités. Un module est un dossier avec une structure

prédé�nie contenant du code Python et des �chiers XML, qui permet de dé�nir la struc-

ture de données, formulaires, rapports, menus, procédures, �ux de travail, etc. Lors de la

première installation, on installe le noyau d'OpenERP avec un certain nombre de modules

dont module � base � selon de pro�l d'installation choisit.

OpenERP est basé sur une architecture multi-tiers. La logique d'OpenERP est entiè-

rement du côté serveur. Le client est un � client léger � ; son travail consiste à demander

des données (formulaires, listes, arbres) à partir du serveur et de les renvoyer. Avec cette

approche tous les développements sont réalisés sur le côté serveur. Ce qui rend Ope-

nERP plus simple au développement et à la maintenance.

Figure 1.5 � Architecture multi-tiers d'OpenERP

L'architecture du système OpenERP est 3 tiers :

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


données) pour l'enregistrement de ces données, où OpenERP utilise un � Object

Relational Mapping �(ORM) pour la persistence de ses objets métier.

� Un serveur d'applications (contenant les objets de gestion, le moteur de work�ow,

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

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

connecter à OpenERP avec n'importe quel navigateur internet.

Le transport des données est réalisé via XML-RPC, c'est un protocole RPC (Remote

procedure call), une spéci�cation simple et un ensemble de codes qui permettent à des

processus s'exécutant dans des environnements di�érents de faire des appels de méthodes

à travers un réseau.

Figure 1.6 � Protocole XML-RPC

OpenERP adopte le modèle MVC avec une séparation stricte entre le modèle de don-

nées, la vue et les traitements.

Figure 1.7 � Modèle MVC

Un (MVC) est une architecture de modèles utilisée en génie logiciel. Dans des applica-

tions complexes qui présentent des lots de données aux utilisateurs, on souhaite souvent

séparer les données (modèle) et l'interface utilisateur (vue), de sorte que les changements à

l'interface utilisateur n'a�ectent pas le traitement des données, et que les données peuvent

être réorganisées sans changer l'interface utilisateur.


Le MVC résout ce genre de problème en découplant l'accès des données et la logique des

applications de la présentation des données et de l'interaction utilisateur, en introduisant

un composant intermédiaire : � le contrôleur �. Dans OpenERP, on peut appliquer cette

sémantique de Model-View-Controller avec :

� Modèle : les modèles sont les objets déclarés dans OpenERP. Ils sont également des

tables PostgreSQL.

� Vue : les vues sont dé�nies en �chiers XML dans OpenERP.

� Contrôleur : le contrôleur est Python qui contrôle OpenERP.

1.3 Problématique

Les stocks représentent les biens achetés, transformés ou à vendre à un moment donné.

Ainsi, les principaux types de stocks sont :

� Le stock de marchandises. Les stocks des commerçants (revente à pro�t d'articles

sans valeur ajoutée de transformation par l'entreprise).

� Le stock de matières premières qui représente les articles achetés auprès de four-

nisseurs en vue d'une transformation ultérieure.

� Le stock des produits en cours de fabrication (semi-�nis) qui représente les

articles qui ne sont pas vendables en l'état car devant encore subir des transforma-

tions.

� le stock des produits �nis qui représente les articles que l'entreprise peut vendre

après les avoir fabriquées.

Le coût d'entrée d'un stock est constitué de :

� Coûts d'acquisition : ce sont les prix d'achat des matières premières, fournitures

ou marchandises auquel s'ajoutent les éventuels frais de transport et de manutention,

les droits de douane, les di�érents taxes.

� Coûts de transformation que sont les coûts ajoutés au coût d'acquisition a�n de

parvenir au coût de production déterminé par la comptabilité analytique.

� Coûts encourus pour amener les stocks à l'endroit et dans l'état où ils se trouvent.

La valorisation des prix de revient des articles est très importante, car c'est l'un des

facteurs primordiaux dans le calcul du prix de vente, ainsi c'est vital pour la rentabilité

d'une entreprise.

OpenERP utilise principalement deux méthodes, dans sa version standard, pour va-

loriser le stock, ce qui provoque une insu�sance dans plusieurs cas de gestion en tenant

compte de la diversité des articles et des contraintes exigées. En e�et, la valorisation de

stock est réalisée selon deux méthodes, chacune possède des inconvénients :


Méthode de coût � Prix standard � : Le système n'intervient pas pour changer

le prix de l'article con�guré par cette méthode. L'intervention du gestionnaire de stock

est directe, où il e�ectue la mise à jour du prix de revient d'article sans tenir compte de la

valeur réelle du coût de réception de cet article dans l'entrepôt de l'entreprise. En e�et, la

récupération de cette dernière valeur, avec les outils existants dans OpenERP pour cette

méthode, est très di�cile car nécessite une consultation des tous les bons de réception

pour chercher dans chacune le prix unitaire de réception et la quantité pour qu'on calcule

le prix de revient.

Méthode de coût basée sur le � Prix moyen � : Le système calcule le nouveau

prix de revient après chaque réception. Le cas contraire de la méthode précédente, car

cette méthode calcule le coût unitaire pour un article stocké dans l'entrepôt, mais la mise

à jour de prix de revient est e�ectué automatiquement pour chaque réception d'article

sans aucun contrôle ou manipulation par le gestionnaire de stock, ce qui peut provoquer

une mauvaise gestion.

Nous remarquons aussi l'absence d'une méthode pour dé�nir le prix de revient selon

le dernier coût, malgré l'importance de cette méthode pour un grand nombre d'article,

où ce type de valorisation devient nécessaire aux plusieurs entreprises pour une gestion

adéquate. En plus, les articles fabriqués, dans certain cas seront valoriser et revu périodi-

quement et non systématiquement par le système.

1.4 Objectifs

L'objectif de ce projet est de développer un module de gestion de prix de revient

dans OpenERP. Ce module permet d'ajouter les insu�sances dans le calcul du prix de

revient basé sur le dernier prix d'achat, et d'ajouter un processus de contrôle permettant

au gestionnaire de stock de mieux gérer le changement des prix des articles. Ce module

devrait proposer un work�ow pour gérer la validation périodique des changements de prix.

Il est demandé aussi de faire le reporting nécessaires a�n de consulter l'état valorisé du

stock.

1.5 Choix méthodologique

Notre démarche est de comprendre le système d'information, de cerner les besoins et de

proposer des solutions qui répondent à ces besoins. La méthodologie suivie est composée

de deux parties : le formalise adopté et le processus adopté.


1.5.1 Langage de modélisation : UML

Une des phases clés dans le développement d'une application est sans doute la phase

de conception. Durant cette phase, nous allons essayer de présenter les principales fonc-

tionnalités à implanter, de ré�échir sur l'aspect structurel de l'application et de concevoir

les scénarios d'utilisation de l'application. Le but est de réduire la complexité du déve-

loppement et d'avoir une vision des di�érents angles de vues du système d'information.

Pour ce projet, on opte pour la notation UML.

UML est la forme contractée d'Uni�ed Modeling Language, qui peut se traduire en

français par langage uni�é pour la modélisation. UML représente l'état de l'art des lan-

gages de modélisation objet. Il fournit les fondements pour spéci�er, construire, visualiser

et décrire un système. Pour cela, UML se base sur une sémantique précise et sur une

notation graphique expressive. Il dé�nit des concepts de base et o�re également des mé-

canismes d'extension de ces concepts.

UML n'est pas un langage propriétaire : il est accessible à tout les fabriquant d'ou-

tils, aussi les entreprises peuvent en faire usage. La volonté d'ouverture, la richesse et la

notation de la dé�nition sémantique précise des éléments de modélisation font d'UML un

langage général et simple, sans être simpliste pour autant. [3]

Dans UML chaque diagramme permet d'exprimer certains points de vue d'un même

problème. La combinaison de plusieurs diagrammes permettra donc d'avoir une vue com-

plète du système. Ainsi en fonction du problème à résoudre, il convient de choisir les

diagrammes adéquats à utiliser. UML dé�nit neuf types de diagrammes dont nous dé-

taillerons ceux que nous utiliserons dans la suite :

Diagramme de cas d'utilisation : Les cas d'utilisation décrivent le comportement

du système du point de vue utilisateur sous la forme d'actions et de réaction. Un cas

d'utilisation indique une fonctionnalité du système déclenchée par un acteur externe au

système. Ce genre de diagramme permet de mettre en place et de comprendre les besoins

du client. Dans le diagramme, interviennent trois éléments : les acteurs, le système et les

cas d'utilisations. L'acteur représente un rôle joué par une personne ou un autre système

qui interagit avec système en cours de modélisation. Un cas d'utilisation regroupe plusieurs

scénarios d'utilisation du système.

Diagramme de séquence : Les diagrammes de séquence permettent de représenter

des collaborations entre objet selon un point de vue temporel, on y met l'accent sur la

chronologie des envois de messages. Les diagrammes de séquences peuvent servir à illustrer

un cas d'utilisation.


Diagramme de classe : Le diagramme de classe est le point central du développement

orienté objet. En analyse, il a pour objectif de décrire la structure des entités manipulées

par les utilisateurs. En conception, le diagramme de classe représente la structure d'un

code orienté objet ou, à un niveau de travail plus important, les modules du langage de

développement.

Diagramme états-transitions : Les diagrammes d'états-transitions d'UML décrivent

le comportement interne d'un objet à l'aide d'un automate à états �nis. Ils présentent les

séquences possibles d'états et d'actions qu'une instance de classe peut traiter au cours de

son cycle de vie en réaction à des évènements discrets (de type signaux, invocations de

méthode).

1.5.2 Processus de développement

Un processus de développement logiciel est un ensemble d'activités permettant de

transformer les besoins des utilisateurs en un système logiciel. Avant d'adopter une mé-

thode, il faut d'abord faire une comparaison entre les di�é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.

Table 1.1 � Tableau comparatif des méthodes de développement


Nous avons utilisé le Processus Simpli�é comme un Processus de développement logi-

ciel vu qu'il était le plus adéquat à notre projet et ce pour les raisons suivantes :

� C'est un processus basé sur les cas d'utilisation comme le Processus Uni�é classique.

� Plus simple et facile à mettre en pratique que le PU.

� Ayant l'agilité de la programmation extrême.

� N'utilise que 20% des diagrammes UML pour modéliser 80% de l'application.

� La phase d'analyse de ce processus, comportant une étude du domaine (traduise par

un diagramme des classes du domaine), est appropriée à l'esprit de la conception

conduite par le domaine.

� La programmation extrême, étant une méthode agile de développement, ne s'adapte

pas à notre projet vu que l'application à réaliser est dé�nie au début du stage.

En général, le Processus Simpli�é est perçu comme une solution intermédiaire entre le

Processus Uni�é et la Programmation extrême couvrant à la fois les avantages des deux

processus et évitant leurs inconvénients. Le Processus Simpli�é est composé des phases

suivantes :

� Étude des besoins : cette phase va être élaborée dans le chapitre3 de notre rapport.

Elle consiste à délimiter le système en spéci�ant les besoins fonctionnels et non

fonctionnels.

� Analyse : cette phase consiste à modéliser les besoins des utilisateurs à l'aide de

diagrammes de cas d'utilisation. Elle sera élaborée dans le chapitre3.

� Conception : cette phase regroupe les cas d'utilisation détaillés accompagné des

diagrammes de séquence détaillés ainsi que les diagrammes de classe d'activité et

de déploiement. Cette phase sera détaillée dans le chapitre4.

� Implémentation : cette phase expose la structure générale de l'application et pré-

sente les principaux modules.

Conclusion

Ce chapitre nous a permis de présenter le cadre général de notre projet en introduisant

l'entreprise d'accueil et en expliquant le travail demandé et la méthodologie adoptée. Nous

pouvons maintenant passer à l'étude de l'art.

Chapitre 2

État de l'art

Introduction

Avant de commencer l'étape du développement, nous avons cherché tout d'abord parmi

les modules existants sous OpenERP, ceux qui o�rent des fonctionnalités exigées précé-

demment dans le cahier des charges fonctionnel. Après une analyse des di�érents modules,

nous décrivons les modules utilisés dans notre système.

2.1 Module � Gestion des Articles �

Dans le module responsable de gestion des produits et des listes des prix dans Ope-

nERP, les articles peuvent avoir des variantes, di�érentes méthodes de calcul du prix,

les informations des fournisseurs, di�érentes méthode de lancement de la fabrication (sur

stock ou sur commande), di�érentes unités de mesures, dé�nir le conditionnement et les

propriétés.

Figure 2.1 � Formulaire� Créer article �

Dans notre projet, nous mettons l'accent sur le traitement de � Méthode de coût �.

14

CHAPITRE 2. ÉTAT DE L'ART 15

Le champ marqué dans la �gure de type liste déroulante qui contient les deux méthodes

permettant la valorisation de prix de revient :

� � Prix standard � : Le prix de revient est mise à jour manuellement à la �n de

chaque période (généralement chaque année).

� � Prix moyen � : Le prix de revient est recalculé à chaque réception.

Le fait de choisir la méthode de coût basé sur le � Prix moyen �, le champ � Prix

de revient � devient de type � readonly � (en lecture seul) car la mise à jour se fait

automatiquement en fonction de changement du � Prix moyen �. Le � Prix moyen � est

recalculé à chaque réception selon la formule suivante :

Figure 2.2 � Formule de Prix moyen

Le tableau 2.1 explique le processus de calcul de prix moyen lors des mouvements

entrants et sortant d'un article.

Table 2.1 � Calcul Prix moyen

Pour chaque article, il faut dé�nir sa catégorie, soit en choisissant une des catégories

déjà créer ou on crée une nouveau. OpenERP simpli�e cette action, par la liste de recherche

dans le formulaire de création d'article où on peut trouver la possibilité de création rapide.

La �gure 2.3 représente le formulaire de création d'une catégorie.


Figure 2.3 � Formulaire � Créer Catégorie �

A l'aide de cette interface nous précisions le compte comptable d'article représenté

dans le formulaire par la liste de sélection � Compte d'entrée en stock �. En e�et, si

la valorisation du stock est faite en temps réel, les écritures de contrepartie de tous les

mouvements de stock entrants seront passées sur ce compte, sauf si un compte particulier

est précisé pour l'emplacement source. C'est la valeur par défaut pour tous les articles de

cette catégorie. Il est également possible de la préciser directement sur chaque article. Les

comptes comptables appartiennent à un plan comptable dé�nit en installant le module �

Comptabilité et �nance �.

2.2 Module � Comptabilité et Finance �

Figure 2.4 � Module � Comptabilité et �nance �

Ce module ajoute les fonctionnalités comptables telles que les mouvements comptables

et le plan comptable. Le plan comptable est l'ensemble des règles d'évaluation et de tenue


des comptes qui constitue la norme de la comptabilité. Le plan de comptes, c'est-à-dire

la liste des comptes ordonnée, est un des éléments du plan comptable. C'est à tort que le

langage usuel réduit souvent le plan comptable au seul plan de comptes.

Au minimum, quatre types de compte sont nécessaires pour enregistrer les évènements

économiques et �nanciers de l'entreprise :

� compte de produits, ce qui est produit ou vendu.

� compte de charges, ce qui est consommé ou acheté, dont le solde augmente ou

diminue les capitaux propres.

� compte d'actifs, ce qui est possédé ou peut l'être.

� compte de passifs, ce qui est dû aux tiers, dont le solde représente les capitaux

propres.

Le tableau 2.2 décrit les principales fonctionnalités de ce module.

Table 2.2 � Fonctionnalités du Module � Comptabilité et Finance �


2.3 Module � Gestion des achats �

Figure 2.5 � Module � Gestion des achats �

Le module achat permet de créer et de suivre les commandes fournisseurs, gérer les

informations fournisseurs, demandes de prix, de contrôler le processus de réception des

articles et de véri�er les factures des fournisseurs.

Il permet aussi de créer une demande de prix lors d'un achat des articles à un four-

nisseur mais que l'achat n'est pas encore con�rmé. Le passage en revue est possible des

demandes de prix crées automatiquement et basées sur des règles logistiques (stock mi-

nimum, production à la demande, etc.). Le gestionnaire peut convertir une demande de

prix en bon de commande une fois que la commande est con�rmée. Ainsi sélectionner

comment contrôler les factures fournisseur : sur les commandes, sur les réceptions ou par

saisie manuelle. Le module achat permet de gérer facilement l'approvisionnement par les

bons d'achats, et fournit des tableaux de bord et des rapports. Le tableau 2.3 décrit les

principales fonctionnalités.

Table 2.3 � Fonctionnalités du Module � Gestion des Achats �


Par le formulaire de la �gure 2.6 le gestionnaire d'achat modélise le processus d'achat

des articles, en précisant dans la page � Bon de commande � les di�érents articles à

acheter. Nous allons mettre l'accent sur cette partie qui contient les noms des articles, les

quantités et les prix d'achat pour valoriser chaque prix de revient d'un article en stock.

Figure 2.6 � Formulaire � Créer Bon de commande �

2.4 Module � Gestion de Production �

Figure 2.7 � Module � Gestion de production �

Ce module permet de couvrir la plani�cation, les ordres, les stocks, la fabrication

et l'assemblage des produits à partir de matières premières et de composants. Il gère la

consommation et la production de produit selon leur nomenclature et les opérations néces-

saires en machines, outils et ressources humaines en accord avec les gammes opératoires.

Le module � production � supporte l'intégration complète et la plani�cation des biens

stockables, consommables ou des services.


Le tableau 2.4 décrit les principales fonctionnalités du module production.

Table 2.4 � Fonctionnalités du Module � Gestion de production �


2.5 Module � Gestion de stock �

Figure 2.8 � Module � Gestion de stock �

OpenERP permet facilement de gérer le stock, le prélèvement, l'emballage et la li-

vraison des produits. OpenERP met à la disposition des PME la valorisation des stocks

en continu, méthode de gestion moderne utilisée par tous les grandes entreprises depuis

plusieurs décennies.

En plus OpenERP a inventé le système de double entrée de la gestion du stock per-

mettant de gérer les besoins complexes très facilement : le suivi des stocks des fournisseurs

/ clients, une traçabilité complète, liens comptables, etc.

OpenERP supporte la multi-gestion d'entrepôt basé sur la structure de localisation

hiérarchique. Gérez vos propres emplacements internes, externes, lieux des clients, des

fournisseurs ou des inventaires de fabrication. Le tableau 2.5 décrit les principales fonc-

tionnalités de ce module.

Table 2.5 � Fonctionnalités du Module � gestion de stock �


Par l'interface de la �gure 2.9 le gestionnaire de stock con�rme la réception d'un bon

de commande traité par le gestionnaire d'achat. A cette phase le calcule pour valoriser le

stock se déclenche, d'où c'est l'une des importantes actions qu'il faut étudier dans notre

projet.

Figure 2.9 � Interface � Réception du bon de commande �

La barre en haut a�che les états d'un bon de commande en distinguant l'état actuel.

Les états d'un bon de commande sont :

� Brouillon : En cours.

� Prêt à recevoir : une fois la commande est con�rmée par le gestionnaire d'achat.

� Reçu : quand le gestionnaire termine la réception.


2.6 Processus de gestion

Comme la valorisation du stock d'un article est une phase réalisée lors de la réception

d'une quantité d'article à stocker, précédée par des phases représentant la cause de cette

quantité. Ainsi, nous allons expliquer les processus de ces phases pour bien comprendre

la démarche globale et a�n de dégager les points intéressant dans notre projet.

2.6.1 Réception par achat

Au premier lieu, il faut créer des articles. C'est à l'aide du formulaire de création

d'article (Figure 2.2). Le gestionnaire d'achat crée le bon de commande contenant les

articles à acheter et en précisant la quantité et le prix unitaire (Figure 2.6). Après la

con�rmation du bon de commande, le gestionnaire de stock con�rme la réception des

articles en consultant l'interface de bon de réception (Figure 2.11) et en précisant les

articles reçus à l'aide de l'assistant � Recevoir article �.

Figure 2.10 � Assistant � Réception par article �

Lors de cette étape, les quantités achetées entre dans le stock avec changement du

prix de revient. Donc il faut bien étudier cette partie dans notre projet. Nous allons nous

intéresser dans cette étape du calcul du prix de revient.

2.6.2 Réception par production

Comme le scénario précédent, il faut créer d'abord un article. Ce qui est di�érent dans

ce cas, c'est qu'il faut indiquer que l'article est obtenu par production. Ceci est e�ectué,

en indiquant lors de la création que la méthode de fourniture est � Produire �.

Nous allons intéresser aux ordres de fabrications a�n de valoriser les articles fabriqués

qui seront stockés.


Figure 2.11 � Formulaire � Créer Ordre de fabrication �

La liste de sélection � Nomenclature � permet de choisir une qu'était déjà crée ou

pour créer une nouvelle nomenclature, en e�et la nomenclature permet de dé�nir la liste

des matières premières pour la fabrication d'un produit �ni.

Figure 2.12 � Assistant � Créer Nomenclature �


Après la création d'un article et la dé�nition de la nomenclature, le gestionnaire

de production con�rme l'ordre de fabrication ce qui provoque un mouvement des ma-

tières premières, en attendant l'ordre de consommation a�n de produire l'article � ar-

ticle_Production �.

L'ordre de consommation e�ectué par le gestionnaire de production. Pour chaque

consommation d'un article de la nomenclature, cet article passe d'un � article à consommé

� à un � article consommé � et nous allons mettre l'accent sur cette partie dans notre

projet car cette action permet de dé�nir le coût de production d'article.

Après la consommation des tous les articles de la nomenclature, le responsable de

production con�rme la fabrication par l'interface assistant de fabrication qui a�che la

quantité et le mode :

Figure 2.13 � Assistant � Fabriquer �

Après la con�rmation de fabrication, l'article fabriqué s'ajoute au stock avec la quan-

tité déjà précisé mais le prix de revient ne change pas.

Figure 2.14 � Interface Article


Conclusion

Dans ce chapitre nous avons étudié les di�érents modules liés à notre projet et plus

précisément les modules agissant sur la valorisation du stock. Ainsi nous pouvons passer

aux phases d'analyse et de conception de notre module en commençant par la phase

d'analyse qui correspond à la présentation de cahier de charges et les diagrammes de cas

d'utilisation générales.

Chapitre 3

Analyse et spéci�cation des besoins

Introduction

Après avoir présenté le projet précédemment et a�n de déterminer clairement les prin-

cipales étapes à suivre. Une étude de l'existant s'avère alors nécessaire dans le but de

proposer un meilleur aspect pour la réalisation. Cette étude est d'une grande utilité pour

dé�nir les exigences demandés et surtout préciser les interactions et les intégrations à

développer a�n de mieux présenter nos fonctionnalités aux utilisateurs.

3.1 Analyse de l'existant

Une étude de l'existant est fortement indispensable. Elle permet d'extraire les insuf-

�sances, que les intervenants sont en train de rencontrer en utilisant les méthodes et les

modules existantes.

3.1.1 Méthode de coût basé sur le � Dernier prix �

Malgré l'importance d'une méthode de valorisation basée sur le dernier prix de ré-

ception, pour plusieurs types d'articles, la version standard OpenERP n'o�re pas cette

possibilité qu'à travers le module reporting.

Figure 3.1 � Méthode de coût

27

CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 28

3.1.2 Consultation des articles

Manque au niveau des services liés à la consultation des indicateurs primordiaux pour

une meilleure gestion de stock. En e�et, pour chaque article le prix moyen pondéré, qui

représente la valeur réel de la quantité en stock, et le dernier prix de réception, qui donne

une vue approximatif à la valeur du produit dans le marché ou le coût réel de la fabrica-

tion, sont nécessaire pour le gestionnaire de stock pour gérer les articles et les comparées

avec le prix de revient.

Ainsi l'inexistence d'un moyen pour consulter, dans la �che article, l'historique de son

prix de revient, a�n de former une idée sur son évolution en fonction de temps et les

méthodes de coût utilisé.

3.1.3 Prix moyen pondéré et le dernier prix

Dans ce qui précède, nous avons indiqué l'importance de ces deux valeurs pour un

article. Or le module gestion des achats dans la version standard d'OpenERP ne les traite

pas.

3.1.4 Valorisation du coût de fabrication d'un article

Après un ordre de fabrication d'un article, le prix de revient ne change pas ; à cause

de l'absence de calcul des coûts de fabrication, en tenant compte la valeur des articles

consommés. La �gure 2.20 montre que la valeur du prix de revient ne change pas même

après la fabrication, et aucune indication sur le coût de production.

3.1.5 Changement automatique du prix de revient

Absence des outils organisationnels pour contrôler et manipuler le changement de prix

de revient par le gestionnaire de stock et le responsable générale, pour les articles géré

par la méthode de coût basé sur le � Prix moyen �.


Figure 3.2 � Changement automatique de prix de revint

Cette �gure est un extrait de scénario du chapitre précédent montre le changement

automatique du prix de revient. Alors que pour les articles basés sur la méthode de coût

� Prix standard �, le processus de changement de prix est e�ectué par papier ce qui peut

provoquer plusieurs problèmes : perte de temps, perte de document, des données fausses,

des erreurs de saisis, etc.

3.2 Étude de besoin

Après une analyse de l'existant nous avons pu extraire les besoins pour gérer les prix au

niveau du module stock et production. Dans cette section, nous allons essayer de donner

une description des exigences fonctionnelles attendues

3.2.1 Besoins fonctionnels

Améliorer la gestion des articles

� Intégrer une nouvelle méthode de coût basé sur le � Dernier prix � : à chaque ré-

ception d'article, le prix de revient change automatiquement pour prendre comme

valeur le prix unitaire de dernière réception.

� Consulter le prix moyen.

� Consulter le dernier prix.

� Consulter l'historique des prix de revient pour chaque article.

� Intégrer des méthodes de coût permettant de créer des articles avec changement de

prix de revient contrôlé par le gestionnaire de stock et validé par le responsable.

Améliorer la gestion de production

Intégrer les traitements nécessaires pour calculer le dernier coût de fabrication et le prix

moyen pour chaque stock d'article fabriqué.


Améliorer la gestion d'achat

Intégrer les traitements nécessaires pour enregistrer le dernier prix d'achat d'un article

et calculer le prix moyen pour chaque stock d'article.

Gérer les demandes de changement des prix de revient

A�n de créer un processus de changement de prix de revient dans OpenERP, il faut

passer par l'intégration d'un nouveau module qui répond à certaines exigences :

� Création d'une demande de changement des prix, qui permet au gestionnaire de

stock de préciser les articles à changer ; et en a�chant les informations nécessaires

permettant d'o�rir une vue sur le changement de la valeur globale du stock, si cette

demande est validé.

� Con�rmation par le gestionnaire de stock Validation ou annulation par le respon-

sable générale.

� Modi�cation : la modi�cation est permise tant que la demande n'est pas encore

con�rmée.

� Suppression demande.

� Consultation demande.

� Faciliter la recherche des demandes à travers des �ltres.

� Réaliser le reporting nécessaire a�n d'obtenir des �ches des demandes pour les en-

treprises qui exigent la signature pour la validation.

3.2.2 Besoins non fonctionnels

Les besoins non fonctionnels décrivent souvent les besoins d'utilisation qui font ré-

férence à des aspects généraux de l'application. Donc pour béné�cier d'une application

�able et e�cace il faut qu'elle réponde à un certain nombre de besoins non fonctionnels :

� Réaliser des interfaces ergonomique et facile à utiliser, donc elles satisfont le critère

de convivialité.

� Assurer l'homogénéité des interfaces du module à intégrer avec celles d'OpenERP.

� L'utilisateur doit être guidé lors de la saisie de certaines informations, a�n de res-

pecter les formats des champs de base de données.

� L'utilisation du moteur work�ow d'OpenERP.

� la précision dans les messages d'erreurs.

� L'optimalité dans le temps de réponse et la rapidité du traitement.

� L'internationalisation.

� L'utilisation des aspects implémentés dans OpenERP :

� La con�dentialité des données.

� Assurer la sécurité de l'application.

� Utiliser les notions de sessions et authenti�cation.


3.3 Diagramme de cas d'utilisation

La conception sera modélisée à l'aide du langage UML (Uni�ed Modeling Language) en

raison de son formalisme relativement simple. C'est un langage qui permet une meilleure

compréhension du système et qui désigne l'interface entre les di�érents acteurs d'un projet

commun.

3.3.1 Identi�cation des acteurs

L'analyse dans la démarche d'UML débute par la recherche des acteurs du système.

En e�et, un acteur est toute entité qui joue un rôle, actif ou passif, vis-à-vis le système.

Un acteur peut être un utilisateur direct du système, un administrateur (assure la main-

tenance) du système ou tout autre système externe avec lequel le système interagit. À ce

stade nous allons déterminer les six acteurs principaux interagissant avec le système.

Table 3.1 � Acteurs principaux


3.3.2 Diagramme de cas d'utilisation global

Le diagramme des cas d'utilisation est la solution UML pour représenter le modèle

conceptuel et pour structurer les besoins et les objectifs. Il représente les utilisations pos-

sibles du système par les di�érents acteurs. Un cas d'utilisation représente un ensemble de

séquence d'actions réalisées par le système et produit un résultat observable intéressant

pour un acteur particulier.

Nous présentons le diagramme de cas d'utilisation global et nous détaillerons par

la suite les cas d'utilisation nécessitant une description plus approfondie. Cette �gure

représente le diagramme général de notre système :

Figure 3.3 � Diagramme de cas d'utilisation global

Cas d'utilisation � Gérer article �

� Titre : Gérer article.

� Description : le gestionnaire de stock possède le privilège d'e�ectuer des tâches de

gestion sur les articles. Il peut ajouter, modi�er, consulter ou supprimer des articles.

� Acteur : Gestionnaire de stock.

� Pré-condition : le gestionnaire de stock est authenti�é.

� Scénario :

� Le gestionnaire de stock accède au menu de gestion des articles.

� Le gestionnaire de stock choisit l'opération qu'il désire e�ectuer sur l'article.

� Le système véri�e les contraintes relatives à cette opération.

� Le système enregistre les modi�cations relatives à l'article.

� Le système a�che l'écran de l'article en mode a�chage seul pour renseigner l'uti-

lisateur de succès de l'enregistrement


� Post-condition : l'article est modi�é suivant l'opération e�ectuée par le gestion-

naire de stock.

Cas d'utilisation � Recevoir article �

� Titre : Recevoir article.

� Description : Le gestionnaire de stock réceptionne les articles.



� Scénario :

� Le gestionnaire de stock accède au menu du bon de réception.

� Le gestionnaire de stock accède à l'assistant de réception.

� Le gestionnaire de stock con�rme la réception de chaque article.

� Le système calcule pour chaque article le prix moyen et l'enregistre ainsi le dernier

prix, et enregistre le prix de revient si la méthode d'article est � Prix moyen � ou

� Dernier prix �.

� Le système enregistre les modi�cations relatives au bon de réception.

� Post-condition : les articles du bon de commande sont stockés.

Cas d'utilisation � Gérer Demande de changement des prix �

� Titre : Gérer demande de changement des prix.

� Description : le gestionnaire de stock possède le privilège d'e�ectuer des tâches

de gestion sur les demandes. Il peut ajouter, modi�er, consulter ou supprimer des

demandes.



� Scénario :

� Le gestionnaire de stock accède au menu Changement des demandes.

� Le gestionnaire de stock choisit l'opération qu'il désire e�ectuer sur la demande.

� Le système véri�e les contraintes relatives à cette opération

� Le système enregistre les modi�cations relatives à la demande.

� Post-condition : La demande est modi�ée suivant l'opération e�ectuée par le ges-

tionnaire de stock.


3.3.3 Diagramme de cas d'utilisation � Gérer article �

Figure 3.4 � Diagramme de cas d'utilisation � Gérer article �

Cas d'utilisation � Modi�er méthode de coût �

� Titre : Modi�er méthode de coût.

� Description : modi�er la méthode de calcul de coût.

� Acteur : Gestionnaire de stock

� Pré-condition : le gestionnaire de stock est authenti�é et l'article est créé.

� Scénario :


� Le gestionnaire de stock choisit l'opération � modi�er article �.

� Le gestionnaire de stock sélectionne une nouvelle méthode de coût.

� Le système modi�e le type d'accès au champ � Prix de revient � selon la nouvelle

méthode choisit.

� Le gestionnaire de stock con�rme les modi�cations.


� Le système a�che l'écran de l'article en mode a�chage seul pour renseigner l'uti-

lisateur de succès de l'enregistrement.

� Post-condition : l'article est modi�é.

Cas d'utilisation � Actualiser historique �

� Titre : Actualiser historique

� Description : le gestionnaire de stock a�che l'historique des prix de revient déjà

utilisés auparavant.




� Scénario :


� Le gestionnaire de stock choisit l'article à consulter.

� Le gestionnaire de stock accède à la page � Historique �

� Le gestionnaire de stock actualise l'historique.

� Le système a�che l'historique des prix de revient de cet article.

� Post-condition : l'écran historique est a�ché.

Cas d'utilisation � Consulter Prix moyen �

� Titre : Consulter Prix moyen

� Description : le gestionnaire de stock aura la possibilité de consulter à tout moment

le prix moyen de chaque article.



� Scénario :


� Le gestionnaire de stock choisit l'article à consulter.

� Le système charge les données à a�cher pour cet article.

� Le gestionnaire de stock accède à la page � Informations �

� Post-condition : Le prix moyen de l'article en stock est a�ché.

3.3.4 Diagramme cas d'utilisation � Recevoir article �

Figure 3.5 � Diagramme cas d'utilisation � Recevoir article �

Cas d'utilisation � Fabriquer article �

� Titre : Fabriquer article


� Description : Le responsable de production con�rme la fabrication d'un article.

� Acteur : Responsable de production.


� Scénario :

� Le Responsable de production accède au menu des ordres de fabrications.

� Le Responsable de production choisit l'ordre de fabrication à traiter.

� Le Responsable de production con�rme la fabrication.

� Le système déclenche les calculs nécessaires pour valoriser le coût de fabrication.

� Le système enregistre les modi�cations relatives à l'article fabriqué.

� Post-condition : l'ordre de fabrication est terminé et la quantité de l'article est

stockée.

3.3.5 Diagramme cas d'utilisation � Gérer Demande de change-

ment des prix � par le gestionnaire de stock

Figure 3.6 � Diagramme cas d'utilisation � Gérer demande de changement des prix �

Cas d'utilisation � Con�rmer demande �

� Titre : Con�rmer demande.

� Description : le gestionnaire de stock con�rme la demande de changement des prix.

� Acteur : Gestionnaire de stock � Pré-condition : le gestionnaire de stock est au-

thenti�é.

� Scénario :

� Le gestionnaire de stock accède au menu Changement des prix.

� Le gestionnaire de stock choisit la demande à con�rmer.


� Le système modi�e l'état de demande à demande con�rmé.


� Le système modi�e le type d'accès à la demande en lecture seul.

� Post-condition : la demande de changement des prix est con�rmée.

3.3.6 Diagramme de cas d'utilisation � Créer Demande de chan-

gement des prix �

Figure 3.7 � Diagramme cas d'utilisation � Créer Demande �

Cas d'utilisation � Créer demande �

� Titre : Créer demande

� Description : le gestionnaire de stock



� Scénario :


� Le gestionnaire de stock choisit l'option � Créer �.

� Le gestionnaire de stock charge la liste des articles à changer.

� Le gestionnaire de stock donne l'ordre pour calculer les valeurs des comptes comp-

tables associé aux articles.

� Le système enregistre la demande avec état � brouillon �.

� Post-condition : une demande de changement des prix est créée.


Cas d'utilisation � Charger par ajout article �

� Titre : Charger par ajout article.

� Description : le gestionnaire de stock charge la liste des articles à changer.



� Scénario :


� Le gestionnaire de stock choisit l'option � Créer � ou � Modi�er � une demande

en état brouillon.




� Post-condition : La liste des articles à changer d'une demande est chargée.

Cas d'utilisation � Charger par assistant �

� Titre : Charger par assistant

� Description : le gestionnaire de stock charge la liste des articles à changer en

utilisant un assistant.



� Scénario :

� Le gestionnaire de stock accède au menu de Changement des prix.

� Le gestionnaire de stock choisit l'opération qu'il désire e�ectuer sur l'article.



� Post-condition : La liste des articles est chargée.


3.3.7 Diagramme cas d'utilisation � Gérer Demande de change-

ment des prix � par le Manager

Figure 3.8 � Diagramme cas d'utilisation � Gérer Demande de changement � par leManager

Cas d'utilisation � Valider demande �

� Titre : Valider demande

� Description : le Manager valide une demande de changement des prix

� Acteur : Manager

� Pré-condition : le Manager est authenti�é.

� Scénario :

� Le Manager accède au menu Changement des prix

� Le Manager choisit la demande con�rmé.

� Le Manger consulte la liste des articles à changer

� Le Manager consulte la liste des comptes comptables des articles

� Le Manager valide la demande

� Le système modi�e les prix de revient des articles de la liste.


� Post-condition : la demande de changement des prix est validée et les prix de

revient des articles sont changés.

Cas d'utilisation � Annuler demande �

� Titre : Annuler demande

� Description : Le Manager annule une demande de changement des prix.

� Acteur : Manager.

� Pré-condition : Le Manager est authenti�é.

� Scénario :

� Le Manager accède au menu Changement des prix.

� Le Manager choisit la demande con�rmé.


� Le Manger consulte la liste des articles à changer.

� Le Manager consulte la liste des comptes comptables des articles.

� Le Manager annule la demande.


� Post-condition : La demande de changement des prix est annulée.

Conclusion

Dans ce chapitre, nous avons présenté une étude de l'existence ainsi que les besoins

fonctionnels et non fonctionnels qui ont été illustrés par des diagrammes de cas d'uti-

lisations. Dans le chapitre qui suit, on se propose de faire une conception détaillée du

projet.

Chapitre 4

Conception

Introduction

Après avoir spéci�é les besoins et �xer les choix conceptuels qui seront adoptés

lors de la réalisation de notre projet, nous abordons la phase de la conception. Dans

ce chapitre, nous allons détailler la conception de chaque fonctionnalité à part. Cette

phase de conception est primordiale dans le cycle de vie d'un logiciel : elle permet de

mettre en place un modèle sur lequel nous allons s'appuyer tout au long de la phase de

développement.

4.1 Diagramme de classes

Le diagramme des classes identi�e la structure des classes d'un système, y com-

pris les propriétés et les méthodes de chaque classe. Les diverses relations, telles que la

relation d'héritage par exemple, qui peuvent exister entre les classes y sont également

représentées. Le diagramme des classes est le diagramme le plus largement répandu dans

les spéci�cations d'UML.

Ce diagramme représente les classes relatives à la conception de notre module, Ainsi

que les modi�cations apportées sur les tables d'OpenERP. Remarque : les classes en blanc

présentent la conception d'OpenERP déjà existante.

41

CHAPITRE 4. CONCEPTION 42

Figure 4.1 � Diagramme de classes


Description

Pour mieux comprendre l'aspect d'intégration de notre module, nous allons aussi ex-

pliquer les classes existantes :

stock_picking

Elle représente la réception et la livraison des articles : entrant dans le stock par achat ou

production, ainsi les mouvements sortant du stock soit livraison (vente) ou consommation

lors de la production. L'objet stock_picking représente un mouvement global composé des

lignes élémentaires des mouvements de la transaction réception ou livraison).

stock_move

Elle représente le mouvement unitaire d'un article. C'est un élément du mouvement

global � stock_picking �, qui précise principalement la quantité, le prix et l'emplacement

pour chaque article.

stock_picking_ext

Hérité de la classe � stock_picking �. Il redé�nit la méthode � do_partial � qui est

responsable de calcul du prix de revient a�n de contrôler le changement automatique des

prix de revient, et pour enregistrer le dernier prix et aussi calculer le prix moyen pour

chaque mouvement.

purchase_order

Représente le bon de commande fournisseur, composé par des achats des articles re-

présentés dans la classe � purchase_order_line �. La création d'un bon de commande se

termine par la création d'un mouvement d'article vers le stock.

purchase_order_line

Elle dé�nit les lignes liées aux bons de commandes, qui identi�e l'article acheté, sa

quantité et son prix unitaire.

mrp_production

Elle dé�nit l'ordre de fabrication d'un article, un article fabriqué consomme les matières

premiers à partir de la nomenclature dé�nit dans la classe � mrp_bom � qui représente la

nomenclature d'un article à fabriquer, où elle dé�nit la quantité unitaire de chaque article

des matières premiers et son prix de stock.

mrp_production_ext

Hérité de la classe � mrp_production �. Elle redé�nit la méthode �_cost_generate�


qui est responsable du calcul du coût de fabrication d'un article, a�n d'enregistrer les

valeurs associé à chaque fabrication et de contrôler l'a�ectation de prix de revient

product_product

C'est la classe qui représente les articles, elle dé�nit toutes les informations sur un

article : nom, code, catégorie, méthode de coût, prix de revient, etc.

product_product_ext

Hérité de la classe � product_product � a�n d'ajouter, les valeurs nécessaires à la

gestion du prix moyen et le dernier prix pour chaque article. Elle redé�nit l'attribut

� méthode de coût � pour ajouter les nouvelles méthodes à intégrer.

stock_change_price

C'est la classe qui représente la demande de changement de prix de revient crée par le

gestionnaire de stock, une demande est dé�nie par les attributs référence, date de création,

total actuel(valeur actuel des tous les articles stockés associés à des comptes comptables

des articles existants dans la demande), nouveau total (c'est la valeur de stock atteint si

les articles de la demande change de prix de revient),et en�n l'attribut état qui désigne

l'état de le demande (brouillon, con�rmé, annulé, validé)

stock_change_price_line

C'est la classe qui représente les articles à changer associés à une demande en identi�ant

l'article, quantité en stock, le prix de revient actuel, le nouveau prix le total actuel,

nouveau total et � ratio � pour connaitre la progression de la valeur des articles en stock

une fois les prix de revient changent.

stock_compte_comptable

Cette classe dé�nit, pour une demande de changement, les comptes comptables associés

aux articles ajoutés dans la demande.

stock_�ll_change_price

Elle dé�nit la liste des articles à changer pour une demande en spéci�ant le choix des

méthodes de coût à traiter (seulement les articles avec méthodes de coût � Prix moyen

Controlé �, ou seulement les � Dernier prix Controlé �, ou les deux).

product_history

Cette classe représente l'historique des prix de revient pour tous les articles, en iden-

ti�ant l'article, le nouveau prix de revient a�ecté, la date d'a�ectation et la méthode de

coût utilisée pour obtenir ce prix de revient.


4.2 Diagramme de séquence

Dans le formalisme UML, un diagramme de séquence est une présentation graphique

des interactions entre les objets du système selon un ordre chronologique. Un diagramme

de cas d'utilisation peut seulement donner une vue générale simpli�é d'un cas ou d'un en-

semble de cas d'utilisation et pour mieux décrire chaque cas d'utilisation nous avons utilisé

le diagramme de séquence. En e�et Les diagrammes de séquences sont la représentation

graphique des interactions entre les acteurs et le système selon un ordre chronologique

dans la formulation UML. Ils servent à illustrer un cas d'utilisation.

Dans les diagrammes de séquence, nous allons utiliser pour les requêtes traitant les

objets persistais les noms des méthodes ORM :

� Search : o�re les fonctionnalités d'une requête de sélection, elle retourne les identi-

�cateurs.

� Browse : permet de charger un tous les données d'un enregistrement.

� Unlink : permet de supprimer un enregistrement.

� Create : permet d'insérer un nouvel enregistrement.

� Write : permet de modi�er un enregistrement.

4.2.1 Diagramme de séquence � Modi�er méthode de coût �

Figure 4.2 � Diagramme de séquence � Modi�er méthode de coût �

La �gure 4.2 décrit le déroulement du cas d'utilisation � Modi�er méthode de coût �,

qui apparaît dans la �gure : 3.5. Le gestionnaire de stock, accède à l'écran de consultation

d'article, ensuite il appuie sur le bouton � Modi�er � et il modi�er la méthode de coût

à travers la liste des choix qui a�che toutes les méthodes de coût dans OpenERP (les


méthodes de la version standard et les méthode ajoutées). Après le gestionnaire de stock

con�rme la modi�cation en appuyant sur le bouton � Enregistrer � qui déclenche le

traitement de modi�cation de la méthode de coût en interagissant avec l'objet persisté.

4.2.2 Diagramme de séquence � Actualiser historique �

Figure 4.3 � Diagramme de séquence � Actualiser historique �

La �gure 4.3 décrit le déroulement du cas d'utilisation � Actualiser historique �, qui

apparaît dans la �gure : 3.4. Chaque utilisateur de l'OpenERP, peut accéder à l'écran de

consultation d'article, ensuite il clique sur l'onglet de la page historique, et après il appuie

sur le bouton d'actualisation qui envoie, à partir de la couche de traitement, une requête

de sélection traitant l'objet persisté � historique � (qui contient l'historique de tous les

articles) a�n de récupérer seulement les données liée à l'article courant. Les données seront

stockées dans une table réservée pour l'a�chage de l'historique d'un article.


4.2.3 Diagramme de séquence � Recevoir articles achetés �

Figure 4.4 � Diagramme de séquence � Recevoir article acheté �

La �gure 4.3 décrit le déroulement du cas d'utilisation � Recevoir article acheté �,

qui apparaît dans la �gure : 3.5. Le gestionnaire de stock, accède à l'écran de consulta-

tion d'un bon de réception non encore reçu, il appuie sur le bouton � Reçu � qui fait

apparaître l'assistant � Recevoir article � qui a�che les articles non reçu d'un bon de

commande. Le gestionnaire de stock con�rme la réception en cliquant sur le bouton rece-

voir. Ce qui produit un appel à la méthode � do_partail � de la couche du traitement �

stock_picking �. Récupérer, au début, les mouvements entrants en interrogeant son objet

persisté � stock.move �, pour extraire les données des articles entrants. Ensuite calculer

le nouveau prix moyen de chaque article. Finalement, mettre à jour le prix moyen et le

dernier prix pour chaque article , à travers l'objet persisté � Article �, et modi�er le prix

de revient si la méthode de coût de l'article n'est pas contrôlé. Pour les méthodes de

coût automatique, enregistrer le changement de prix de revient à travers l'objet persisté

� Historique �.


4.2.4 Diagramme de séquence � Fabriquer article �

Figure 4.5 � Diagramme de séquence � Fabriquer article �

La �gure 4.5 décrit le déroulement du cas d'utilisation � Fabriquer article �, qui

apparaît dans la �gure : 3.5. Le responsable de production, accède à l'écran de consul-

tation d'un ordre de fabrication non terminé. Il appuie sur le bouton � Fabriquer � qui

fait apparaître l'assistant � Fabriquer article �, en a�chant l'article à fabriquer ainsi sa

quantité. Le responsable de production con�rme la fabrication en cliquant sur le bouton

� Fabriquer �, qui fait appel à la méthode � do_produce � de la couche du traitement de

production. Au début, le traitement de la méthode commence par récupérer les mouve-

ments des articles consommés en interrogeant son objet persisté � stock.move �. Ensuite

extraire les données des articles consommés a�n de calculer le coût de fabrication et le

nouveau prix moyen de cet article. A la �n, faire les modi�cations dans l'objet persisté de

l'article concernant le prix moyen, dernier prix et le prix de revient selon la méthode de

coût utilisé. Pour les méthodes de coût automatique, enregistrer le changement de prix

de revient à travers l'objet persisté � Historique �.


4.2.5 Diagramme de séquence � Charger par ajout article �

Figure 4.6 � Diagramme de séquence � Charger par ajouter article �

La �gure 4.6 décrit le déroulement du cas d'utilisation � Charger par ajout article

�, qui apparaît dans la �gure : 3.7. Le gestionnaire de stock, accède à l'écran de création

d'une demande de changement des prix, dans la liste des articles à changer il saisit le nom

d'article. L'ajout d'article déclenche le traitement de la méthode � on_change_product

� pour calculer le nouveau total et a�cher le prix de revient actuel et le nouveau prix de

revient en interrogeant l'objet persisté � Article �.

4.2.6 Diagramme de séquence � Charger par assistant �

La �gure 4.6 décrit le déroulement du cas d'utilisation � Charger par assistant �,

qui apparaît dans la �gure : 3.7. Le gestionnaire de stock, accède à l'écran de création

d'une demande de changement des prix. Il appuie sur le bouton � Charger Liste � qui

fait apparaître l'assistant de chargement. Il spéci�e les méthodes de coût à traiter et il

précise les comptes comptables des articles à changer. Ensuite il appuie sur le bouton �

Charger liste � qui déclenche le traitement de la méthode � action_consult � qui permet de

récupérer les articles associés aux comptes comptables précisés selon la méthode spéci�é.

Ensuite la méthode calcule les totaux actuels et les nouveaux totaux , et les enregistre, à

travers l'objet persisté de la liste des articles � Articles-Demande � .En�n fermer l'assistant

et a�cher les articles à changer.


Figure 4.7 � Diagramme de séquence � Charger par assistant �


4.2.7 Diagramme de séquence � Calculer les valeurs des comptes

comptables �

Figure 4.8 � Diagramme de séquence � Calculer les valeurs des comptes comptables �

La �gure 4.8 décrit le déroulement du cas d'utilisation � Calculer les valeurs des

comptes comptables �, qui apparaît dans la �gure : 3.7. Le gestionnaire de stock, accède

à l'écran de création d'une demande de changement des prix. Il accède à l'onglet compte

comptable et il appuie sur le bouton � calculer �. Le traitement commence par parcourir

la liste des articles à changer, et chercher pour chaque article son compte comptable et

calculer pour ce dernier les valeurs des totaux de ses articles stockés.


4.2.8 Diagramme de séquence � Valider demande �

Figure 4.9 � Diagramme de séquence � Valider demande �

La �gure 4.9 décrit le déroulement du cas d'utilisation � Valider demande �, qui

apparaît dans la �gure : 3.8. Le Manager, accède à l'écran de consultation d'une demande

de changement des prix con�rmé, il consulte la liste des articles et la liste des comptes

comptables. Après il valide la demande en cliquant sur le bouton � Valider � qui déclenche

le traitement de la méthode � action_done � pour modi�er les nouveaux prix de revient, à

travers l'objet persisté � Article �, et enregistrer les changements à travers l'objet persisté

� Historique �.

4.3 Diagramme d'états-transitions

Un diagramme d'états-transitions est associé à une classe et décrit les séquences

d'états qu'un objet peut prendre en réponse à un évènement. L'état est une situation

dans laquelle peuvent se trouver les objets d'une classe durant leur vie. Puisque un objet

est toujours dans un état dé�ni ou connu pour un certain temps, les états se caractérisent

par une durée dé�nie dans le temps et par une stabilité par rapport au temps. Dans un

état, l'objet peut satisfaire des conditions, accomplir des actions ou réagir à des évène-

ments. Une classe, lorsque'elle a une dynamique non négligeable, dispose de son automate,

représenté sous forme de diagramme d'états transitions.

Pour élaborer ce diagramme, en premier lieu, il faut identi�er l'état initial et l'en-

semble des états �naux, ensuite il faut identi�er les di�érents états intermédiaires et en�n


il faut relier ces états entre eux en utilisant des transitions contrôlées par des conditions

de passage.

Figure 4.10 � Diagramme d'état-transition � Demande de changement �

Une demande de changement des prix, après sa création, sera chargée par les articles

à changer en restant dans l'état Brouillon. Son état passera alors à l'état con�rmé lorsque

le gestionnaire de stock con�rme l'émission au Manager et selon les décisions prises pour sa

gestion, elle pourra être annulé ou validé. A tout moment la demande peut être supprimé,

les états �naux représentés par : Demande supprimer et Demande validé.

Conclusion

Ce chapitre a permis de comprendre en détails les di�érentes fonctionnalités atten-

dues de notre module et l'enchaînement de leur déroulement dans le temps. Ceci donne la

possibilité de passer au développement de la solution. Le cinquième chapitre portera sur

une description détaillée de l'environnement dans lequel notre projet a été réalisé ainsi

qu'une présentation des interfaces.

Chapitre 5

Étude technique et Réalisation

Introduction

Pour le développement du système nous nous sommes basés sur le Framework Ope-

nERP et les di�érentes technologies qu'il utilise, et pour ajouter le système comme module

au sein de cet ERP nous avons eu recours à plusieurs outils, dont la présentation est dé-

taillée dans les paragraphes suivants. Nous passerons ensuite aux détails de la réalisation.

5.1 Environnement logiciel

Le bon choix de l'environnement de travail est très important. Dans ce chapitre, nous

nous intéressons aux choix des technologies et des environnements aidant à l'implémen-

tation de notre application.

5.1.1 Outil de conception : PowerAMC

A�n de modéliser notre travail en langage UML, nous avons utilisé un logiciel complet

de modélisation intitulé Power AMC dans sa version 15.1. C'est un outil tout-en-un de mo-

délisation d'entreprise et de gestion de métadonnées destiné à documenter l'architecture

d'entreprise.

Figure 5.1 � Logo PowerAMC

54

CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 55

PowerAMC est un environnement graphique très simple à utiliser qui permet d'e�ec-

tuer les tâches suivantes :

� Modélisation intégrée via l'utilisation de méthodologies et de notations standards :

� Données (E/R, Merise),

� Métiers (BPMN, BPEL, ebXML),

� Application (UML),

� Génération automatique de code via des Template personnalisables,

� SQL (avec plus de 50 SGBD),

� Java,

� NET.

� Fonctionnalités de reverse engineering pour documenter et mettre à jour des sys-

tèmes existants,

� Une solution de référentiel d'entreprise avec des fonctionnalités de sécurité et de

gestion des versions très complètes pour permettre un développement multiutilisa-

teurs,

� Fonctionnalités de génération et de gestion de rapports automatisés et personnali-

sables,

� Un environnement extensible, qui vous permet d'ajouter des règles, des commandes,

des concepts et des attributs à vos méthodologies de modélisation et de codage. [9]

5.1.2 Système de gestion de base de données : PostgreSQL

Nous avons utilisé PostgeSQL dans sa version 9.2 comme système de gestion de base

de données relationnel objet (SGBDRO)

Figure 5.2 � Logo PostgreSQL

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

projets libres, 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 : entiers,

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

etc.

PostgreSQL est pratiquement conforme aux normes ANSI SQL 89, SQL 92 (SQL 2),

SQL 99 (SQL 3), SQL :2003 et SQL :2008.

PostgreSQL est largement reconnu par son comportement stable, proche d'Oracle.

Mais aussi par 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.

5.1.3 Éditeur de texte : Notepad++

Pour le développement en langage Python, nous n'avons pas utilisé d'environnement

de développement particulier. L'utilisation d'un éditeur de texte avancé permet de rendre

le code plus lisible et de fournir des fonctions supplémentaires. Le logiciel Open Source

Notepad++ a donc été mon éditeur pour le développement en Python et aussi pour XML.

Figure 5.3 � Logo Notepad++

Notepad++ est un éditeur de code source qui prend en charge plusieurs langages. Ce

programme, codé en C++ avec STL et win32 api, a pour vocation de fournir un éditeur de

code source de taille réduite mais très performant. En optimisant de nombreuses fonctions

tout en conservant une facilité d'utilisation et une certaine convivialité. Notepad++ o�re

plusieurs fonctionnalités :

� Coloration syntaxique et Relief syntaxique (Folding de syntaxe)

� Langage dé�nit par utilisateur

� PCRE (Perl Compatible Regular Expression) pour la recherche et le replacement

� Plan du document

� Auto-complétion

� Multi-documents (Les onglets)

� Multi-Vues

� WYSIWYG (What You See Is What You Get - verser l'impression). [10]


5.1.4 Éditeur de catalogues textuels : PoEdit

L'internationalisation d'un logiciel consiste à préparer son adaptation à des langues

di�érentes. Pour traduire OpenERP ou un de ses modules c'est mettre en Français (ou

autre langue) des phrases qui sont en Anglais. Pour cela nous avons utilisé l'éditeur PoEdit.

Figure 5.4 � Logo PoEdit

PoEdit est un éditeur de catalogues textuels (�chiers ayant l'extension .po). C'est une

assistance précieuse à la traduction. Ce logiciel permet :

� de traduire automatiquement selon une base de données,

� de visualiser ergonomiquement dans un système de double a�chage la version ori-

ginale et sa traduction, tout en travaillant et validant cette traduction, [11]

Lors de la première utilisation, le logiciel demande à l'utilisateur de l'aider à créer une

base de données qui l'aidera plus tard pour la traduction automatique. Cette opération

est assez longue mais nécessaire pour une traduction automatisée.

5.2 Technologies

Pour le développement du système je me suis basés sur l'ERP OpenERP et les di�é-

rentes technologies et Framework qu'il utilise,dont la présentation est détaillée dans les

paragraphes suivants.

5.2.1 Framework OpenERP

Un Framework est un ensemble de fonctions bas niveau qui permettent de gérer les

besoins et concepts les plus couramment utilisés dans le développement d'un logiciel, et

lui sert ainsi de base technologique.


Anciennement connu par � Framework OpenObject �, mais comme cela était source

de beaucoup de confusion car beaucoup de gens se demandaient quelle était la di�érence

entre OpenObject et OpenERP, cette appellation a été o�ciellement abandonnée. Ce

Framework est un environnement qui dispose d'une boite à outils complète et modulaire

permettant un développement simple et rapide des applications. Pour créer un module

OpenERP, la création d'un �chier Python contenant la description des champs et des

règles de gestion et un �chier XML décrivant les écrans, c'est su�sant. OpenERP aussi

permet la création de Wizards (sous-programmes), l'automatisation des tâches et leur

plani�cation, l'intégration de données par défaut et/ou de démonstration.

Figure 5.5 � Module OpenERP

Le Framework d'OpenERP se distingue par l'intégration d'un ORM, un moteur de

work�ow et un moteur de rapports et plusieurs fonctionnalités.

ORM : Object Relational Mapping

OpenERP utilise un ORM pour la persistance de ses objets métier. Dès ses débuts,

OpenERP s'est doté d'un ORM, alors que cette technologie était encore très peu répan-

due. L'ORM permet d'avoir une couche d'abstraction par rapport à la base de données ;

il gère les droits d'accès et évite d'avoir à écrire le code SQL dans lequel il faut refaire

toutes les relations entre les tables avec des JOIN. En e�et, c'est une technique de pro-

grammation qui crée l'illusion d'une base de données orientée objet à partir d'une base

de données relationnelle en dé�nissant des correspondances entre cette base de données

et les objets du langage utilisé. C'est une correspondance entre monde objet et monde

relationnel. L'ORM d'OpenERP ne fonctionne qu'avec PostgreSQL.


Figure 5.6 � ORM d'OpenERP

Cette couche (notamment dans OpenERP) permet de centraliser les véri�cations de

la validité des données lors de la sauvegarde, les véri�cations des droits d'accès, etc.

Les objets métier sont déclarés comme des classes Python héritant de la classe osv se

trouvant dans le module osv( l'Object Service � OSV � implémente une couche complet

de mapping objet-relationnel), ce qui les rend partie de la modèle OpenERP, et persisté

par la couche ORM.

Figure 5.7 � Objet OpenERP

OpenERP a fait évoluer son ORM au fur et à mesure des versions, mais continue

d'utiliser son propre ORM et n'a pas basculé vers un ORM libre � standard �. Cependant,

il reste possible d'utiliser des requêtes SQL dans le code d'OpenERP, par exemple pour

certaines parties du code où les performances sont très importantes.

Moteur de work�ow

Le work�ow (�ux de travaux) concerne l'analyse, la modélisation et l'automatisation

des �ux d'information dans l'entreprise. Il s'appuie sur des outils informatiques automa-

tisant la circulation des documents. Il permet ainsi d'organiser dynamiquement les tâches

au sein d'un cheminement documenté, plani�é, contrôlable en permanence et aisément

adaptable au gré des évolutions de l'environnement.


Il existe plusieurs types de work�ow :

� Le work�ow administratif, concernant les documents internes à l'entreprise (enga-

gement de dépense, gestion des absences...).

� Le work�ow de production, concernant les procédures classiques de l'entreprise (prise

de commande, émission de facture, gestion des réclamations des clients...).

� Le work�ow collaboratif, qui fait intervenir des acteurs internes ou externes sur un

sujet commun (documentation technique, fourniture de produits complexes...).

Bien que nécessitant un investissement important et la réorganisation des processus de

l'entreprise, la mise en place d'un work�ow apporte des avantages substantiels :

� Diminution des délais de réaction.

� Augmentation de la productivité (essentiellement dans les services administratifs).

� Diminution des erreurs.

OpenERP intègre un moteur de work�ow. Ceci permet de formaliser les règles métier de

l'entreprise a�n d'automatiser la prise de décision, c'est-à-dire la branche du work�ow à

choisir, en fonction du contexte donné. [12]

Moteur de rapport

Le moteur de rapport par défaut d'OpenERP est basé sur le langage RML, qui est

un standard mis au point par la société anglaise ReportLab. La société ReportLab a

développé une implémentation OpenSource limitée et une implémentation propriétaire

payante plus complète du langage RML.

OpenERP a réalisé sa propre implémentation du langage RML en développant un outil

de conversion RML vers PDF et RML vers HTML. Cette implémentation est disponible

dans le serveur OpenERP.

Il y a 2 façons de se servir de ce moteur de rapport :

� coder le rapport directement en RML. Cela implique d'apprendre ce langage ;

� concevoir le rapport dans OpenO�ce ou LibreO�ce et transférer le �chier SXW (le

format de �chier d'OpenO�ce 1.x) résultant dans un module OpenERP. Le �chier

est alors stocké au format SXW et converti au format RML.

Si le format de sortie du rapport est le format PDF ou HTML, alors le serveur OpenERP

va lire le �chier RML (codé ou généré à partir du �chier SXW), puis il va remplacer les

champs par leur valeur, et en�n il va utiliser son moteur de conversion RML2PDF ou

RML2HTML pour convertir le �chier RML au format PDF ou HTML.[13]


L'accès généralisé via les web services en XML-RPC

Toutes les communications entre le Framework et les interfaces sont e�ectuées en

XMLRPC. Les types d'objets, les écrans, les données sont transmises par ce protocole.

Tous les objets d'OpenERP sont accessibles via les web services, que ce soit en lecture,

écriture, création et suppression. Aussi toutes les fonctions d'OpenERP sont accessibles

en web services. Cela signi�e par exemple que n'importe quel clic sur un bouton de l'in-

terface d'OpenERP peut être fait depuis un web service.

Comme l'accès via les web services est une fonction native du Framework, lors de

développement d'un module spéci�que qui crée un nouvel objet, et un nouveau bouton,

alors cet objet et ce bouton seront automatiquement accessibles en web services, sans

écrire du code spéci�quement pour cela.

5.2.2 Langage de programmation : Python

Le Framework d'OpenERP utilise le langage Python (version 2.7) ; plus précisément,

il impose que les modules soient écrits en Python et il est lui-même codé en Python.

Figure 5.8 � Logo Python

Python est un langage de programmation libre et orienté objet, qui est connu pour

être lisible et facile à utiliser pour le développeur. Il est livré avec un débugger intégré, qui

permet de travailler e�cacement sur les bugs. C'est un langage interprété et non compilé,

ce qui implique qu'il est beaucoup moins rapide que des langages compilés comme le C

ou le C++ et un peu moins rapide que des langages semi-compilés comme Java. Python

dispose d'une large communauté, ce qui permet d'avoir accès à un vaste choix de librairies,

matures pour la plupart.[14]

Les principales caractéristiques du langage Python :

� Portable : Il est supporté par les di�érents systèmes d'exploitation. Python pos-

sède actuellement deux implémentations. L'une, interprétée, dans laquelle les pro-

grammes Python sont compilés en instructions portables, puis exécutés par une


machine virtuelle (comme pour Java, avec une di�érence importante : Java étant

statiquement typé, il est beaucoup plus facile d'accélérer l'exécution d'un programme

Java que d'un programme Python). L'autre génère directement du bytecode Java ;

� Orienté objet et supporte l'héritage multiple et la surcharge des opérateurs ;

� Simple : Il possède une syntaxe très simple tout en combinant des types de données

évolués (listes, dictionnaires. . .) ;

� Dynamiquement typé ;

� Gère ses ressources (mémoire, descripteurs de �chiers...) sans intervention du pro-

grammeur, par un mécanisme de comptage de références ;

� Gratuit et soutenu par la communauté d'utilisateurs qui tentent à l'évoluer.

5.2.3 XML

OpenERP utilise XML pour la description des données, la description des interfaces,

la description des rapports et la description des work�ow.

XML (eXtensible Markup Language et en Français Langage à balises étendu, ou Lan-

gage à balises extensible) est un langage simple et puissant de description et d'échange

de documents structurés de n'importe quel domaine de données grâce à son extensibilité,

il décrit cette structure à l'aide d'un système de balises.

Quelques points remarquables d'XML :

� Il apparaît comme un format d'échange de données universel ;

� Il a la possibilité de créer des nouvelles balises contrairement à HTML qui dé�nit

un nombre limité ;

� Il garantit à ses utilisateurs l'indépendance de leurs documents de toute technologie

propriétaire ;

� Il uni�e le monde du traitement de document et celui du Web.

5.2.4 RML

OpenERP utilise une extension du XML pour dé�nir les rapports : le � RML �. Les

�chiers RML décrivent la structure du document ainsi que les expressions et les champs

à inclure. C'est un langage XML de style pour décrire la mise en page de documents. Il

permet aussi de dé�nir et manipuler n'importe quel aspect d'un document, y compris le

contenu et le style, en utilisant des balises dont la plupart des balises sont similaires à

HTML. Le contenu d'un �chier RML composé principalement par trois sections.


Figure 5.9 � Les sections d'un �chier RML

5.2.5 Fichier PO

Toutes les chaines de caractères qui doivent être traduites sont stockées dans des

�chiers .po qui contiennent des informations sur la langue, sur l'identité des traducteurs

et les phrases originales et traduites.

5.3 Réalisation

5.3.1 Gestion des articles

Figure 5.10 � Intégration des méthodes

Nous avons intégrer trois nouveaux méthodes, a�n d'aider le gestionnaire de stock

pour mieux gérer les articles stockables. Les méthodes ajoutées sont :


� � Dernier prix d'achat � : c'est une méthode de coût basé sur le dernier prix

d'achat, elle permet de changer le prix de revient automatiquement à chaque nouvelle

réception d'article.

� � Prix moyen Contrôlé � : c'est une méthode de coût basé sur le prix moyen,

comme la méthode � Prix moyen � sauf que le changement du prix de revient ne

s'e�ectue pas automatiquement mais après une demande du gestionnaire de stock

et validation du manager.

� � Dernier prix Contrôlé � : c'est une méthode de coût basé sur le dernier prix

d'achat, comme la méthode � Dernier prix � sauf que le changement du prix de

revient ne s'e�ectue pas automatiquement mais après une demande du gestionnaire

de stock et validation du manager.

Nous avons aussi intégré deux propriétés � Prix moyen � et � Dernier prix �, a�n d'o�rir

au gestionnaire la possibilité de consulter ces deux valeurs pour chaque article où :

� � Prix moyen � a�che le prix moyen du stock d'un article.

� � Dernier prix � a�che le prix unitaire de dernière réception en stock d'un article.

Ces deux valeurs aident le gestionnaire de stock pour prendre une décision ; soit pour

changer la méthode de coût, ou de demander le changement du prix de revient. Pour

mieux expliquer, les �gures ci-dessous représentent les �ches de deux articles :

� article_Prix moyen Contrôlé : le calcul du prix de revient sera fait selon la méthode

de coût � Prix moyen Contrôlé �

� article_Dernier prix : le calcul du prix de revient sera fait selon la méthode de coût

� Prix moyen Contrôlé �

Figure 5.11 � Premier réception � article_Prix moyen �

Après la première réception de cet article, le � Prix de revient � ne change pas mais

nous remarquons que les valeurs des indicateurs � Prix moyen � et � Dernier prix � sont

égaux, car c'est la première entrée en stock de cet article.


Figure 5.12 � Deuxième réception � article_Prix moyen �

Après une deuxième réception, avec un prix unitaire est égale à (nous pouvons le

consulter à travers le champ � Dernier prix) ; nous remarquons le changement de valeur

pour le � Prix moyen � et le � Dernier prix �.

Figure 5.13 � Réception � article_Dernier prix �

Après une nouvelle réception d'une quantité d' � article_Dernier prix � en stock, le

prix de revient change automatiquement et prendre la valeur de � Dernier prix �.

A�n d'o�rir la possibilité de consulter les di�érents valeurs du prix de revient pour

chaque article, nous avons intégré un page � Historique � qui a�che pour chaque chan-

gement de valeur date du changement et la méthode de coût.


Figure 5.14 � Historique Prix de revient

5.3.2 Gestion des Demandes

Nous avons ajouté sous le Menu � Gestion de stock � un nouvel élément � Changement

des prix �, pour aider le gestionnaire de stock à créer ses demandes contenant la liste des

articles à changer ses prix de revient.

Figure 5.15 � Module Changement des prix

Pour créer une demande, il faut d'abord saisir une référence de la demande ; ensuite

charger la liste des articles à changer ses prix de revient. Cette dernière étape est e�ectuée

selon deux manières. La première consiste à ajouter les articles un par un.


Figure 5.16 � Ajouter article

Dans le champ � Article � le gestionnaire de stock saisit le nom d'article, où il choisit

un article parmi les articles a�chées dans la liste déroulante. Après l'ajout, les données

liées à cet article seront a�chés.

Figure 5.17 � Données articles

La deuxième méthode consiste à utiliser un assistant de chargement où le gestionnaire

de stock précise les comptes comptables. Chaque compte comptable est associé à plu-

sieurs articles, alors un traitement qui se déclenche pour charger la liste par les articles

(seulement les articles contrôlés) de chaque compte comptable.


Figure 5.18 � Barre d'état d'une demande

La barre en haut permet d'a�cher l'état actuel de la demande :

� Brouillon : en cours de création.

� Con�rmé : le gestionnaire de stock con�rme la demande.

� Validé : le Manager valide la demande.

� Annulé : le Manager refuse la demande.

Figure 5.19 � Assistant � Charger Liste �

Le gestionnaire peut �ltrer les articles des comptes à charger dans la liste en spéci�ant

la méthode de coût.

Après le chargement de la liste des articles, le gestionnaire consulte la liste des comptes

comptables ; a�n de former une idée sur les nouvelles valeurs du stock. Les totaux de

chaque compte comporte les valeurs de tous les articles même les non contrôlés.


Figure 5.20 � Consulter Compte Comptable

Le gestionnaire con�rme l'émission de la demande. Ensuite le Manager consulte cette

demande pour valider ou annuler les changements.

Figure 5.21 � Valider les changements

Après la validation, le prix de revient de chaque article prendre la nouvelle valeur selon

sa méthode de coût.


Figure 5.22 � Changement de prix de revient

C'est la �che de l'article � article_Prix moyen Controlé � (l'exemple du paragraphe

5.3.1), nous remarquons le changement du prix de revient.


Nous avons ajouté la possibilité d'imprimer la demande, a�n d'obtenir un rapport

signé par le Manager.

Figure 5.23 � Rapport � Changement des prix �

Conclusion

Au cours de ce chapitre, nous avons présenté en détails la réalisation de projet, com-

mençant par la présentation des outils de développement. Nous avons présenté également

des captures d'écran qui montrent le bon fonctionnement des di�érents services précités.

Conclusion générale

Le but de ce travail a consisté principalement à l'extension du module de gestion de

stock du PGI OpenERP. Plus précisément on doit implémenter un nouveau module de

contrôle de gestion de prix des articles stockés et fabriqués. Nous avons débuté par une

phase de recherche sur ce progiciel non seulement sur les aspects techniques mais aussi

fonctionnels. Après avoir bien assimilé les concepts et le fonctionnement d'OpenERP, nous

avons entamé l'étape suivante qui consiste à exploiter le Framework pour bien développer

ce nouveau module OpenERP de gestion de prix de stock.

Le module ainsi réalisé permet de gérer le prix moyen et le prix d'achat des articles

avec plus de souplesse et de contrôler les changements automatiques du prix de revient

des articles stockés.

Travailler dans le monde de l'open source, et plus précisément sur un progiciel tel que

OpenERP nous avons permis d'apprendre plus sur ces domaines de processus, la gestion

de stock, la production, l'achat, etc. De point de vue technique nous avons pu découvrir

et maitriser les langages python et XML dans le contexte du Framework OpenERP. Aussi

nous avons fait mes premiers contacts avec sa grande communauté mondiale dans la re-

cherche et le développement, a�n de faciliter l'intégration d'une telle solution dans tous

les domaines professionnels et sociaux.

Certes, nous avons rencontré plusieurs di�cultés ; étant donné le manque des docu-

mentations sur les techniques de développement des modules OpenERP. Mais à l'aide des

forums et divers tutoriels faits par les centaines de partenaires je les ai surmenés. Aussi

La richesse d'OpenERP provoque certaines complexités. Nous avons pu cacher certaines

de ces complexités avec une rigueur dans la méthodologie en concentrant uniquement sur

mes problématiques projets. Pour citer un exemple de ces complexités, la recherche des

dépendances dans un nombre important de classes python et tables de bases de données

postgres (plus de 350 objets sans compter les modules partenaires).

72


Certaines améliorations peuvent être apportées à ce travail et toucheront essentiel-

lement à l'extension fonctionnelle du module pour d'autres méthodes de coût telle que

LIFO et FIFO, où les entrées en stock sont comptabilisées par lot. Chaque lot dans le

magasin possède son prix unitaire. Lors de la sortie du stock, le prélèvement s'e�ectue

dans un lot selon des règles particulières. Une extension technique est aussi possible pour

le reporting et le tableau de bord en utilisant Jasper Report pour les rapports complexes

et l'utilisation du mode de vue � graph � qui permet de présenter le ratio de changement

sous forme de graphique.

Bibliographie

[1] Livre : Apprenez à programmer en Python pour � Vincent Le Go� �

[2] Livre : � Drive your Sales & Marketing Activities with OpenERP � pour � Fabien

Pinckaers � et � Els Van Vossel �

[3] Livre : � Modélisation objet avec UML � pour � Pierre-Alain Muler � et � Nathalie

Gaertner �

[4] Livre : � OpenERP pour une gestion d'entreprise e�cace et intégrée � (Eyrolles)

pour � Fabien Pinckers � et � Geo� Gardiner �

[5] Support de cours � Génie logiciel et méthodes de conception orientées objet � pour

Mr � Abdellatif Abdelaziz �.

Netographie

[6] :http ://www.openios.tn/services.html

[7] :http ://fablain.developpez.com/tutoriel/presenterp/

[8] :http ://www.innovatech.be/upload/documents/dossier_de_presse_OpenERP.pdf

[9] :http ://infocenter.sybase.com/archive/index.jsp

[10] :http ://notepad-plus-plus.org/fr/features/

[11] :http ://www.commentcamarche.net/faq/6326-traduire-un-logiciel-open-source-poedit

[12] :http ://iclosion.com/index.php ?

option=com_content&view=article&id=5&Itemid=231&lang=fr

[13] : http ://people.via.ecp.fr/~alexis/openerp/

[14] http ://fr.wikipedia.org/wiki/Python_(langage)

[15] https ://doc.openerp.com/

OpenERP - Gestion de prix de revient

Engineering

Transcript of OpenERP - Gestion de prix de revient