Ce document présente un projet de gestion intégré au sein d'Openios Consulting, incluant des remerciements et une dédicace. Il détaille l'organisation, les objectifs, les méthodologies, ainsi que l'analyse et la conception des besoins fonctionnels et non fonctionnels. L'étude technique et la réalisation de ce projet incluent l'utilisation de plusieurs technologies et outils de développement.

1. 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

2. 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 Soen KARRAY, qui m'a encadré, avisé et motivé de façon
continue et qui m'a oert 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.
Enn, je tiens à exprimer mon amitié et mon respect profonds envers tous mes
collègues de la FST.

3. 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

4. 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écication 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 Identication 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 Modier 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

5. 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

6. 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

7. 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 Modier 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

8. 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

9. 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 eectué 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éciques 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.
An 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 an de clarier 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écication des besoins fonctionnels et non-fonctionnels. Dans le quatrième
chapitre qui concerne la conception, nous présenterons les diérents diagrammes statiques
1

10. 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.

11. 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éciquement 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

12. 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'ecacité des systèmes d'information des entreprises.
Gestion électronique des documents et workow : 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/Workow, 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 an 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/Workow -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écique autour de Filenet
et Alfreco.[6]

13. CHAPITRE 1. PRÉSENTATION DU PROJET 5
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 signie 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
workow 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.

14. CHAPITRE 1. PRÉSENTATION DU PROJET 6
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
workow.
1.2.2 OpenERP
Figure 1.3 OpenERP
Créée en 2002 par Fabien PINCKAERS, anciennement connu sous le nom Tiny
ERP, signiant 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 modier, 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 ache en eet une progression de
1542% de son chire d'aaires 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]

15. CHAPITRE 1. PRÉSENTATION DU PROJET 7
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 prol 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

16. CHAPITRE 1. PRÉSENTATION DU PROJET 8
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 workow,
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écication 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'aectent pas le traitement des données, et que les données peuvent
être réorganisées sans changer l'interface utilisateur.

17. CHAPITRE 1. PRÉSENTATION DU PROJET 9
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 à prot 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 an 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 insusance dans plusieurs cas de gestion en tenant
compte de la diversité des articles et des contraintes exigées. En eet, la valorisation de
stock est réalisée selon deux méthodes, chacune possède des inconvénients :

18. CHAPITRE 1. PRÉSENTATION DU PROJET 10
Méthode de coût Prix standard : Le système n'intervient pas pour changer
le prix de l'article conguré par cette méthode. L'intervention du gestionnaire de stock
est directe, où il eectue 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 eet, la
récupération de cette dernière valeur, avec les outils existants dans OpenERP pour cette
méthode, est très dicile 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 eectué 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 insusances 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 workow pour gérer la validation périodique des changements de prix.
Il est demandé aussi de faire le reporting nécessaires an 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é.

19. CHAPITRE 1. PRÉSENTATION DU PROJET 11
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'Unied 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écier, 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 ore é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.

20. CHAPITRE 1. PRÉSENTATION DU PROJET 12
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

21. CHAPITRE 1. PRÉSENTATION DU PROJET 13
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éciant 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.

22. 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 orent 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

23. 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 simplie 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.

24. CHAPITRE 2. ÉTAT DE L'ART 16
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 eet, 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

25. CHAPITRE 2. ÉTAT DE L'ART 17
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

26. CHAPITRE 2. ÉTAT DE L'ART 18
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érier 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 conrmé. 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 conrmé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

27. CHAPITRE 2. ÉTAT DE L'ART 19
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 planication, 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 planication des biens
stockables, consommables ou des services.

28. CHAPITRE 2. ÉTAT DE L'ART 20
Le tableau 2.4 décrit les principales fonctionnalités du module production.
Table 2.4 Fonctionnalités du Module Gestion de production

29. CHAPITRE 2. ÉTAT DE L'ART 21
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

30. CHAPITRE 2. ÉTAT DE L'ART 22
Par l'interface de la gure 2.9 le gestionnaire de stock conrme 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 ache 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 conrmée par le gestionnaire d'achat.
Reçu : quand le gestionnaire termine la réception.

31. CHAPITRE 2. ÉTAT DE L'ART 23
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 an 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
conrmation du bon de commande, le gestionnaire de stock conrme 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 eectué,
en indiquant lors de la création que la méthode de fourniture est Produire .
Nous allons intéresser aux ordres de fabrications an de valoriser les articles fabriqués
qui seront stockés.

32. CHAPITRE 2. ÉTAT DE L'ART 24
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 eet 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

33. CHAPITRE 2. ÉTAT DE L'ART 25
Après la création d'un article et la dénition de la nomenclature, le gestionnaire
de production conrme l'ordre de fabrication ce qui provoque un mouvement des ma-ti
ères premières, en attendant l'ordre de consommation an de produire l'article ar-ticle_
Production .
L'ordre de consommation eectué 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 conrme la fabrication par l'interface assistant de fabrication qui ache la
quantité et le mode :
Figure 2.13 Assistant Fabriquer
Après la conrmation 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

34. CHAPITRE 2. ÉTAT DE L'ART 26
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.

35. Chapitre 3
Analyse et spécication des besoins
Introduction
Après avoir présenté le projet précédemment et an 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 an 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'ore pas cette
possibilité qu'à travers le module reporting.
Figure 3.1 Méthode de coût
27

36. 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 eet, 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, an 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 .

37. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 29
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 eectué 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é.

38. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 30
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
An 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 achant les informations nécessaires
permettant d'orir une vue sur le changement de la valeur globale du stock, si cette
demande est validé.
Conrmation par le gestionnaire de stock Validation ou annulation par le respon-sable
générale.
Modication : la modication est permise tant que la demande n'est pas encore
conrmée.
Suppression demande.
Consultation demande.
Faciliter la recherche des demandes à travers des ltres.
Réaliser le reporting nécessaire an 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 ecace 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, an de res-pecter
les formats des champs de base de données.
L'utilisation du moteur workow 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 condentialité des données.
Assurer la sécurité de l'application.
Utiliser les notions de sessions et authentication.

39. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 31
3.3 Diagramme de cas d'utilisation
La conception sera modélisée à l'aide du langage UML (Unied 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 Identication des acteurs
L'analyse dans la démarche d'UML débute par la recherche des acteurs du système.
En eet, 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

40. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 32
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'eectuer des tâches de
gestion sur les articles. Il peut ajouter, modier, 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 eectuer sur l'article.
Le système vérie les contraintes relatives à cette opération.
Le système enregistre les modications relatives à l'article.
Le système ache l'écran de l'article en mode achage seul pour renseigner l'uti-lisateur
de succès de l'enregistrement

41. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 33
Post-condition : l'article est modié suivant l'opération eectuée par le gestion-naire
de stock.
Cas d'utilisation Recevoir article
Titre : Recevoir article.
Description : Le gestionnaire de stock réceptionne les articles.
Acteur : Gestionnaire de stock.
Pré-condition : le gestionnaire de stock est authentié.
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 conrme 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 modications 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'eectuer des tâches
de gestion sur les demandes. Il peut ajouter, modier, consulter ou supprimer des
demandes.
Acteur : Gestionnaire de stock.
Pré-condition : le gestionnaire de stock est authentié.
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 eectuer sur la demande.
Le système vérie les contraintes relatives à cette opération
Le système enregistre les modications relatives à la demande.
Post-condition : La demande est modiée suivant l'opération eectuée par le ges-tionnaire
de stock.

42. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 34
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 Modier méthode de coût
Titre : Modier méthode de coût.
Description : modier 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 accède au menu de gestion des articles.
Le gestionnaire de stock choisit l'opération modier article .
Le gestionnaire de stock sélectionne une nouvelle méthode de coût.
Le système modie le type d'accès au champ Prix de revient selon la nouvelle
méthode choisit.
Le gestionnaire de stock conrme les modications.
Le système enregistre les modications relatives à l'article.
Le système ache l'écran de l'article en mode achage 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 ache l'historique des prix de revient déjà
utilisés auparavant.

43. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 35
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'article à consulter.
Le gestionnaire de stock accède à la page Historique
Le gestionnaire de stock actualise l'historique.
Le système ache l'historique des prix de revient de cet article.
Post-condition : l'écran historique est aché.
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.
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'article à consulter.
Le système charge les données à acher pour cet article.
Le gestionnaire de stock accède à la page Informations
Post-condition : Le prix moyen de l'article en stock est aché.
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

44. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 36
Description : Le responsable de production conrme la fabrication d'un article.
Acteur : Responsable de production.
Pré-condition : le gestionnaire de stock est authentié.
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 conrme la fabrication.
Le système déclenche les calculs nécessaires pour valoriser le coût de fabrication.
Le système enregistre les modications 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 Conrmer demande
Titre : Conrmer demande.
Description : le gestionnaire de stock conrme 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 à conrmer.
Le système vérie les contraintes relatives à cette opération.
Le système modie l'état de demande à demande conrmé.

45. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 37
Le système modie le type d'accès à la demande en lecture seul.
Post-condition : la demande de changement des prix est conrmé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
Acteur : Gestionnaire de stock
Pré-condition : le gestionnaire de stock est authentié.
Scénario :
Le gestionnaire de stock accède au menu Changement des prix.
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.

46. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 38
Cas d'utilisation Charger par ajout article
Titre : Charger par ajout article.
Description : le gestionnaire de stock charge la liste des articles à changer.
Acteur : Gestionnaire de stock.
Pré-condition : le gestionnaire de stock est authentié.
Scénario :
Le gestionnaire de stock accède au menu Changement des prix.
Le gestionnaire de stock choisit l'option Créer ou Modier une demande
en état brouillon.
Le gestionnaire de stock accède au menu Changement des prix.
Le système vérie les contraintes relatives à cette opération.
Le système enregistre les modications relatives à l'article.
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.
Acteur : Gestionnaire de stock
Pré-condition : le gestionnaire de stock est authentié.
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 eectuer sur l'article.
Le système vérie les contraintes relatives à cette opération.
Le système enregistre les modications relatives à l'article.
Post-condition : La liste des articles est chargée.

47. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 39
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 le
Manager
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 conrmé.
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 modie les prix de revient des articles de la liste.
Le système enregistre les modications relatives à la demande.
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 conrmé.

48. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 40
Le Manger consulte la liste des articles à changer.
Le Manager consulte la liste des comptes comptables des articles.
Le Manager annule la demande.
Le système enregistre les modications relatives à 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.

49. 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 identie 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écications d'UML.
Ce diagramme représente les classes relatives à la conception de notre module, Ainsi
que les modications apportées sur les tables d'OpenERP. Remarque : les classes en blanc
présentent la conception d'OpenERP déjà existante.
41

50. CHAPITRE 4. CONCEPTION 42
Figure 4.1 Diagramme de classes

51. CHAPITRE 4. CONCEPTION 43
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 an 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 identie 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

52. CHAPITRE 4. CONCEPTION 44
qui est responsable du calcul du coût de fabrication d'un article, an d'enregistrer les
valeurs associé à chaque fabrication et de contrôler l'aectation 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 an 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 enn l'attribut état qui désigne
l'état de le demande (brouillon, conrmé, annulé, validé)
stock_change_price_line
C'est la classe qui représente les articles à changer associés à une demande en identiant
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éciant 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 aecté, la date d'aectation et la méthode de
coût utilisée pour obtenir ce prix de revient.

53. CHAPITRE 4. CONCEPTION 45
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 eet 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 : ore 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 modier un enregistrement.
4.2.1 Diagramme de séquence Modier méthode de coût
Figure 4.2 Diagramme de séquence Modier méthode de coût
La gure 4.2 décrit le déroulement du cas d'utilisation Modier 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 Modier et il modier la méthode de coût
à travers la liste des choix qui ache toutes les méthodes de coût dans OpenERP (les

54. CHAPITRE 4. CONCEPTION 46
méthodes de la version standard et les méthode ajoutées). Après le gestionnaire de stock
conrme la modication en appuyant sur le bouton Enregistrer qui déclenche le
traitement de modication 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) an 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'achage de l'historique d'un article.

55. CHAPITRE 4. CONCEPTION 47
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 ache les articles non reçu d'un bon de
commande. Le gestionnaire de stock conrme 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 modier 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 .

56. CHAPITRE 4. CONCEPTION 48
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 achant l'article à fabriquer ainsi sa
quantité. Le responsable de production conrme 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 an de calculer le coût de fabrication et le
nouveau prix moyen de cet article. A la n, faire les modications 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 .

57. CHAPITRE 4. CONCEPTION 49
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 acher 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écie 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 .Enn fermer l'assistant
et acher les articles à changer.

58. CHAPITRE 4. CONCEPTION 50
Figure 4.7 Diagramme de séquence Charger par assistant

59. CHAPITRE 4. CONCEPTION 51
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.

60. CHAPITRE 4. CONCEPTION 52
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 conrmé, 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 modier 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 identier l'état initial et l'en-semble
des états naux, ensuite il faut identier les diérents états intermédiaires et enn

61. CHAPITRE 4. CONCEPTION 53
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 conrmé lorsque
le gestionnaire de stock conrme 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.

62. 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
An 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

63. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 55
PowerAMC est un environnement graphique très simple à utiliser qui permet d'eec-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.

64. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 56
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++ ore
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]

65. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 57
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 achage 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.

66. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 58
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é ociellement 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 susant. OpenERP aussi
permet la création de Wizards (sous-programmes), l'automatisation des tâches et leur
planication, 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
workow 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 eet, 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.

67. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 59
Figure 5.6 ORM d'OpenERP
Cette couche (notamment dans OpenERP) permet de centraliser les vérications de
la validité des données lors de la sauvegarde, les vérications 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 workow
Le workow (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.

68. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 60
Il existe plusieurs types de workow :
Le workow administratif, concernant les documents internes à l'entreprise (enga-gement
de dépense, gestion des absences...).
Le workow de production, concernant les procédures classiques de l'entreprise (prise
de commande, émission de facture, gestion des réclamations des clients...).
Le workow 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 workow 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 workow. Ceci permet de formaliser les règles métier de
l'entreprise an d'automatiser la prise de décision, c'est-à-dire la branche du workow à
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 OpenOce ou LibreOce et transférer le chier SXW (le
format de chier d'OpenOce 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 enn il va utiliser son moteur de conversion RML2PDF ou
RML2HTML pour convertir le chier RML au format PDF ou HTML.[13]

69. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 61
L'accès généralisé via les web services en XML-RPC
Toutes les communications entre le Framework et les interfaces sont eectué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 signie 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écique 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éciquement 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 ecacement 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

70. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 62
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 workow.
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 unie 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.

71. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 63
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, an d'aider le gestionnaire de stock
pour mieux gérer les articles stockables. Les méthodes ajoutées sont :

72. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 64
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'eectue 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'eectue 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 , an d'orir
au gestionnaire la possibilité de consulter ces deux valeurs pour chaque article où :
Prix moyen ache le prix moyen du stock d'un article.
Dernier prix ache 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.

73. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 65
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 .
An d'orir la possibilité de consulter les diérents valeurs du prix de revient pour
chaque article, nous avons intégré un page Historique qui ache pour chaque chan-gement
de valeur date du changement et la méthode de coût.

74. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 66
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 eectuée
selon deux manières. La première consiste à ajouter les articles un par un.

75. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 67
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 achées dans la liste déroulante. Après l'ajout, les données
liées à cet article seront aché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.

76. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 68
Figure 5.18 Barre d'état d'une demande
La barre en haut permet d'acher l'état actuel de la demande :
Brouillon : en cours de création.
Conrmé : le gestionnaire de stock conrme 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éciant
la méthode de coût.
Après le chargement de la liste des articles, le gestionnaire consulte la liste des comptes
comptables ; an 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.

77. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 69
Figure 5.20 Consulter Compte Comptable
Le gestionnaire conrme 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.

78. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 70
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.

79. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 71
Nous avons ajouté la possibilité d'imprimer la demande, an 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.

80. 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, an de faciliter l'intégration d'une telle solution dans tous
les domaines professionnels et sociaux.
Certes, nous avons rencontré plusieurs diculté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

81. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 73
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'eectue
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.

82. 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 ecace 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 .

83. 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_contentview=articleid=5Itemid=231lang=fr
[13] : http ://people.via.ecp.fr/~alexis/openerp/
[14] http ://fr.wikipedia.org/wiki/Python_(langage)
[15] https ://doc.openerp.com/