1. DdicaceJe ddie ce modeste travail Mes parents, qui n'ont jamais cess de m'encourager et me soutenir,Mon frre Mouhamed, et ma sur SoumayaTous les membres de ma famille,Mes Collgues : Naceur, Cherif, Foued, Amine, MouradTous mes amis,Et ceux qui me sont chers.Taieb

2. RemerciementsJe tiens remercier chaleureusement l'ensemble des personnes qui ont contribu deprt ou de loin l'laboration de ce projet qui a t pour moi trs enrichissant tant auniveau formation que sur le plan personnel.Je remercie Mr Faouzi BEN CHARRADA, pour son suivi de prs de l'avance-mentde 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 faoncontinue et qui m'a oert cette chance de poursuivre ce stage trs bnque.Je remercie, galement, tout le cadre administratif et les professeurs de la FST pourla formation de qualit et l'ambiance qu'ils ont su instaurer pendant toutes mes annesd'tudes.Enn, je tiens exprimer mon amiti et mon respect profonds envers tous mescollgues de la FST. 3. Table des matiresDdicace iRemerciements iiTable de Matires iiiTable des gures viListe des tableaux viiiIntroduction gnrale 11 Prsentation du projet 3Conclusion 31.1 Organisme d'Accueil : OpenIOS Consulting . . . . . . . . . . . . . . . . . . 31.1.1 Domaine d'activit . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.2 Organisation d'OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Progiciel de Gestion Intgr . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1 ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5 Choix mthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5.1 Langage de modlisation : UML . . . . . . . . . . . . . . . . . . . . 111.5.2 Processus de dveloppement . . . . . . . . . . . . . . . . . . . . . . 12Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 tat de l'art 14Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1 ModuleGestion des Articles. . . . . . . . . . . . . . . . . . . . . . . . 142.2 ModuleComptabilit et Finance. . . . . . . . . . . . . . . . . . . . . 162.3 ModuleGestion des achats. . . . . . . . . . . . . . . . . . . . . . . . 18iii 4. TABLE DES MATIRES iv2.4 ModuleGestion de Production. . . . . . . . . . . . . . . . . . . . . . 192.5 ModuleGestion de stock. . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 Processus de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.1 Rception par achat . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.2 Rception par production . . . . . . . . . . . . . . . . . . . . . . . 23Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Analyse et spcication des besoins 27Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1 Analyse de l'existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.1 Mthode de cot bas sur leDernier prix. . . . . . . . . . . . . 273.1.2 Consultation des articles . . . . . . . . . . . . . . . . . . . . . . . . 283.1.3 Prix moyen pondr et le dernier prix . . . . . . . . . . . . . . . . . 283.1.4 Valorisation du cot de fabrication d'un article . . . . . . . . . . . . 283.1.5 Changement automatique du prix de revient . . . . . . . . . . . . . 283.2 tude de besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Diagramme de cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . 313.3.1 Identication des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 313.3.2 Diagramme de cas d'utilisation global . . . . . . . . . . . . . . . . . 323.3.3 Diagramme de cas d'utilisationGrer article. . . . . . . . . . . 343.3.4 Diagramme cas d'utilisationRecevoir article. . . . . . . . . . . 353.3.5 Diagramme cas d'utilisationGrer Demande de changement desprixpar le gestionnaire de stock . . . . . . . . . . . . . . . . . . . 363.3.6 Diagramme de cas d'utilisationCrer Demande de changementdes prix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.7 Diagramme cas d'utilisationGrer Demande de changement desprixpar le Manager . . . . . . . . . . . . . . . . . . . . . . . . . 39Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 Conception 41Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Diagramme de squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.1 Diagramme de squenceModier mthode de cot. . . . . . . 454.2.2 Diagramme de squenceActualiser historique. . . . . . . . . . 464.2.3 Diagramme de squenceRecevoir articles achets. . . . . . . . 474.2.4 Diagramme de squenceFabriquer article. . . . . . . . . . . . 484.2.5 Diagramme de squenceCharger par ajout article. . . . . . . . 49 5. TABLE DES MATIRES v4.2.6 Diagramme de squenceCharger par assistant. . . . . . . . . . 494.2.7 Diagramme de squenceCalculer les valeurs des comptes comp-tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.8 Diagramme de squenceValider demande. . . . . . . . . . . . 524.3 Diagramme d'tats-transitions . . . . . . . . . . . . . . . . . . . . . . . . . 52Conclusion 535 tude technique et Ralisation 54Conclusion 545.1 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.1 Outil de conception : PowerAMC . . . . . . . . . . . . . . . . . . . 545.1.2 Systme de gestion de base de donnes : PostgreSQL . . . . . . . . 555.1.3 diteur de texte : Notepad++ . . . . . . . . . . . . . . . . . . . . . 565.1.4 diteur de catalogues textuels : PoEdit . . . . . . . . . . . . . . . . 575.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2.1 Framework OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . 575.2.2 Langage de programmation : Python . . . . . . . . . . . . . . . . . 615.2.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2.4 RML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2.5 Fichier PO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3 Ralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3.1 Gestion des articles . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3.2 Gestion des Demandes . . . . . . . . . . . . . . . . . . . . . . . . . 66Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Conclusion gnrale 72Bibliographie ixWebographie x 6. Table des gures1.1 OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Organigramme OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Modules OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Architecture multi-tiers d'OpenERP . . . . . . . . . . . . . . . . . . . . . 71.6 Protocole XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.7 Modle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1 Formulaire Crer article. . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Formule de Prix moyen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 FormulaireCrer Catgorie. . . . . . . . . . . . . . . . . . . . . . . . 162.4 ModuleComptabilit et nance. . . . . . . . . . . . . . . . . . . . . . 162.5 ModuleGestion des achats. . . . . . . . . . . . . . . . . . . . . . . . 182.6 FormulaireCrer Bon de commande. . . . . . . . . . . . . . . . . . . 192.7 ModuleGestion de production. . . . . . . . . . . . . . . . . . . . . . 192.8 ModuleGestion de stock. . . . . . . . . . . . . . . . . . . . . . . . . . 212.9 InterfaceRception du bon de commande. . . . . . . . . . . . . . . . 222.10 AssistantRception par article. . . . . . . . . . . . . . . . . . . . . . 232.11 FormulaireCrer Ordre de fabrication. . . . . . . . . . . . . . . . . . 242.12 AssistantCrer Nomenclature. . . . . . . . . . . . . . . . . . . . . . . 242.13 AssistantFabriquer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.14 Interface Article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 Mthode de cot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Changement automatique de prix de revint . . . . . . . . . . . . . . . . . . 293.3 Diagramme de cas d'utilisation global . . . . . . . . . . . . . . . . . . . . . 323.4 Diagramme de cas d'utilisationGrer article. . . . . . . . . . . . . . . 343.5 Diagramme cas d'utilisationRecevoir article. . . . . . . . . . . . . . . 353.6 Diagramme cas d'utilisationGrer demande de changement des prix. 363.7 Diagramme cas d'utilisationCrer Demande. . . . . . . . . . . . . . . 37vi 7. TABLE DES FIGURES vii3.8 Diagramme cas d'utilisationGrer Demande de changementpar leManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Diagramme de squenceModier mthode de cot. . . . . . . . . . . 454.3 Diagramme de squenceActualiser historique. . . . . . . . . . . . . . 464.4 Diagramme de squenceRecevoir article achet. . . . . . . . . . . . . 474.5 Diagramme de squenceFabriquer article. . . . . . . . . . . . . . . . 484.6 Diagramme de squenceCharger par ajouter article. . . . . . . . . . . 494.7 Diagramme de squenceCharger par assistant. . . . . . . . . . . . . . 504.8 Diagramme de squenceCalculer les valeurs des comptes comptables. 514.9 Diagramme de squenceValider demande. . . . . . . . . . . . . . . . 524.10 Diagramme d'tat-transitionDemande de changement. . . . . . . . . 535.1 Logo PowerAMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2 Logo PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.3 Logo Notepad++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.4 Logo PoEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.5 Module OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.6 ORM d'OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.7 Objet OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.8 Logo Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.9 Les sections d'un chier RML . . . . . . . . . . . . . . . . . . . . . . . . . 635.10 Intgration des mthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.11 Premier rceptionarticle_Prix moyen. . . . . . . . . . . . . . . . . . 645.12 Deuxime rceptionarticle_Prix moyen. . . . . . . . . . . . . . . . . 655.13 Rceptionarticle_Dernier prix. . . . . . . . . . . . . . . . . . . . . . 655.14 Historique Prix de revient . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.15 Module Changement des prix . . . . . . . . . . . . . . . . . . . . . . . . . 665.16 Ajouter article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.17 Donnes articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.18 Barre d'tat d'une demande . . . . . . . . . . . . . . . . . . . . . . . . . . 685.19 AssistantCharger Liste. . . . . . . . . . . . . . . . . . . . . . . . . . 685.20 Consulter Compte Comptable . . . . . . . . . . . . . . . . . . . . . . . . . 695.21 Valider les changements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.22 Changement de prix de revient . . . . . . . . . . . . . . . . . . . . . . . . 705.23 RapportChangement des prix. . . . . . . . . . . . . . . . . . . . . . . 71 8. Liste des tableaux1.1 Tableau comparatif des mthodes de dveloppement . . . . . . . . . . . . . 122.1 Calcul Prix moyen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Fonctionnalits du ModuleComptabilit et Finance. . . . . . . . . . . 172.3 Fonctionnalits du ModuleGestion des Achats. . . . . . . . . . . . . . 182.4 Fonctionnalits du ModuleGestion de production. . . . . . . . . . . . 202.5 Fonctionnalits du Modulegestion de stock. . . . . . . . . . . . . . . 213.1 Acteurs principaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31viii 9. Introduction gnraleLes technologies de l'information ont connu une importante volution durant cesdernires annes, ce qui a donn comme rsultat l'mergence de plusieurs solutions infor-matiquespour remdier aux direntes problmatiques relles.Les Progiciels de Gestion Intgr, appels PGI ou ERP, sont l'une des solutions les plusrpondues ce jour. Ils intgrent les principales composantes fonctionnelles de l'entreprise :gestion de production, gestion commerciale, logistique, ressources humaines, comptabilit,contrle de gestion. A l'aide de ce systme intgr, les utilisateurs de dirents mtierstravaillent dans un environnement applicatif identique qui repose sur une base de donnesunique. Ce modle permet d'assurer l'intgrit des donnes, la non-redondance de l'infor-mation,ainsi que la rduction des temps de traitement.OpenIOS Consulting, socit au sein de laquelle nous avons eectu notre stage de nd'tudes, propose ses clients un ERP bas sur le logiciel libreOpenERPpour lequelelle peut dvelopper des besoins spciques pour chacun d'entre eux.Au cours de ce stage, notre travail a consist comprendre le fonctionnement del'OpenERP, concevoir et dvelopper un module de gestion des prix des articles de stocktotalement intgr dans ERP et dvelopp avec les outils et les concepts fournit par lacommunaut OpenERP.Ce module vient d'ajouter une nouvelle fonctionnalit la pro-blmatique de gestion de stock exig dans le contexte des socits locales tunisiennes.An d'illustrer la dmarche de notre travail, nous prsentons dans ce qui suit l'organi-sationgnrale du prsent rapport qui s'articule autour de cinq chapitres. Dans le premierchapitre, nous prsenterons le cadre du projet travers une prsentation de la socit,des gnralits autour des ERP et OpenERP permettant de mieux cadrer notre travail,la problmatique et le choix mthodologique. Ensuite, nous prsenterons dans le chapitresuivant l'tat de l'art an de clarier les dirents modules lis la gestion de stock. Letroisime chapitre sera consacr la partie analyse o nous laborerons une tude de l'exis-tantet une spcication des besoins fonctionnels et non-fonctionnels. Dans le quatrimechapitre qui concerne la conception, nous prsenterons les dirents diagrammes statiques1 10. LISTE DES TABLEAUX 2et dynamiques ainsi que l'architecture globale de la solution. Le cinquime chapitre estrserv l'tude technique o nous prsenterons les outils et les technologies utilises, etnous prsenterons les interfaces l'aide des captures crans avec les explications. Pourconclure, nous prsenterons les connaissances acquises durant ce stage et nous proposonsun ensemble de perspectives ce travail. 11. Chapitre 1Prsentation du projetIntroductionDans ce premier chapitre, nous allons prsenter le cadre gnral du projet. Pource faire, nous allons prsenter, dans un premier lieu, l'entreprise d'accueil. Ensuite, nousintroduisons les ERP et le progiciel OpenERP utilis dans cette entreprise, ainsi que laprsentation du projet : la problmatique, les objectifs et la mthodologie du travail.1.1 Organisme d'Accueil : OpenIOS ConsultingFigure 1.1OpenIOSLe projet a t ralis au sein de la socit OpenIOS situe aux Berges du Lac.Fonde en 2011, OpenIOS est une socit tunisienne active dans le domaine des systmesd'information spcialise dans l'dition et l'intgration des logiciels Open Source. Rsul-tantd'une exprience de consulting de plus de 12 ans en gestion d'entreprise, OpenIOSa adopt OpenERP comme solution ERP spciquement conue pour les PME de services.OpenIOS est un spcialiste des technologies de dveloppement open source, Pythonet Java, pour les plateformes OpenERP, J2EE, Servlets, JSP, Tomcat, JBOSS et IBMWebsphere Application Server. Le Framework de dveloppement est bas sur des outils etdes composantes Open source adopts par de nombreux diteurs et entreprises d'envergureinternationale. [6]3 12. CHAPITRE 1. PRSENTATION DU PROJET 41.1.1 Domaine d'activitLes consultants d'OpenIOS accompagnent le client dans la gestion de son systmed'information et dans le pilotage de ses processus : du consulting au transfert de comp-tences en incluant le paramtrage et l'intgration d'OpenERP avec d'autres applicationstierces.Dans le but de fournir chacun de ses clients un service sur-mesure et de qualit avecune solution parfaitement adapte leurs besoins. Ainsi le domaine d'activit d'OpenIOStourne essentiellement autour du dveloppement de logiciel sur-mesure et consulting, par-ticulirement touche les domaines suivants : Stratgie de Nouvelle Technologie dans le Systme d'Information de client : servicede conseil visant renforcer l'ecacit des systmes d'information des entreprises. Gestion lectronique des documents et workow : en couvrant la dnition du roadmapdu projet de mise en place, l'assistance et l'accompagnement de mise enplace des systmes GED/Workow, l'tude et la conception des processus mtiers,en utilisant les standards comme BPMN, et l'interaction de solutionsLowcost en l'occurrence bass sur l'Open Source. Business Intelligence : proposition aux clients d'une rexion approfondie par lebiais d'une analyse de l'existant, d'une valuation du gap et de la mise en place desolutions simples de business intelligence. Management projet : Les chefs de projets OpenIOS apportent leurs savoir-faire dansla conduite des projets an de respecter l'adquation cot, dlai et qualit. Dveloppement autour d'OpenERP : bas sur OpenObject, un Framework modu-laire,scalable et intuitif, c'est unRapid Application Development(RAD) Fra-meworkcrit en Python. Dveloppement Java : bas sur les serveurs d'application J2EE JBOSS et IBMWebsphere application server. Dveloppement autour des plate-forme GED/Workow -IBM FileNet/ Alfresco : Enaccumulant les projets de Gestion Electronique de Document, l'quipe d'OpenIOSa conu des composants qui facilitent le dveloppement spcique autour de Filenetet Alfreco.[6] 13. CHAPITRE 1. PRSENTATION DU PROJET 51.1.2 Organisation d'OpenIOSLe diagramme suivant reprsente les dirents services rattachs une directiongnrale :Figure 1.2Organigramme OpenIOS1.2 Progiciel de Gestion Intgr1.2.1 ERPL'acronyme ERP signie Enterprise Ressource Planning traduit en franais par Pro-gicielde Gestion Intgr ou PGI. ERP est le terme le plus couramment utilis.Un ERP est un progiciel qui permet de grer d'une manire centralise l'ensembledes processus d'une entreprise intgrant l'ensemble de ses fonctions comme la gestion desressources humaines, la gestion nancire et comptable, l'aide la dcision, la vente, ladistribution, l'approvisionnement, la production ou encore du e-commerce.Le principe fondateur d'un ERP est de construire des applications informatiques cor-respondantaux diverses fonctions cites prcdemment de manire modulaire sachant queces modules sont indpendants entre eux, tout en partageant une base de donnes uniqueet commune au sens logique. [7]L'autre principe qui caractrise un ERP est l'usage de ce qu'on appelle un moteur deworkow et qui permet, lorsqu'une donne est enregistre dans le systme d'information,de la propager dans les modules qui en ont l'utilit, selon une programmation prdnie. 14. CHAPITRE 1. PRSENTATION DU PROJET 6Ainsi, on peut parler d'ERP lorsqu'on est en prsence d'un systme d'informationcompos de plusieurs applications partageant une seule et mme base de donns, par lebiais d'un systme automatis prdni et ventuellement paramtrable, un moteur deworkow.1.2.2 OpenERPFigure 1.3OpenERPCre en 2002 par Fabien PINCKAERS, anciennement connu sous le nom TinyERP, signiant la fourmi de l'Enterprise ,est un progiciel intgr de gestion ouvert, librede droits comprenant les ventes, la gestion de relation client (CRM), la gestion de projet,la gestion d'entrept, la production, la comptabilit et les ressources humaines.Le principe du logiciel libre est la gratuit, mais aussi la possibilit d'accder aux codesdes programmes, ce qui permet de les modier, de les adapter volont, condition derendre publique la nouvelle version.Grce la communaut open source, le catalogue de logiciels d'OpenERP s'tait dve-lopp bien plus rapidement que pour un diteur de logiciels ditspropritaires(commeceux de SAP, Microsoft, Sage, Oracle. . .) : pas moins de 500 modules taient dj dis-positiondes entreprises. On notait dj plus de 1000 installations par jour, devenant lelogiciel de gestion le plus install au monde. OpenERP ache en eet une progression de1542% de son chire d'aaires en cinq ans , en passant de 500 modules, n 2009, 2200propos par la nouvelle version OpenERP 7, avec croissance qui passe 100% par an.[8] 15. CHAPITRE 1. PRSENTATION DU PROJET 7Figure 1.4Modules OpenERPOpenERP possde une structure modulaire qui permet d'ajouter de nouveaux modulesfacilement pour tendre les fonctionnalits. Un module est un dossier avec une structureprdnie contenant du code Python et des chiers XML, qui permet de dnir la struc-turede donnes, formulaires, rapports, menus, procdures, ux de travail, etc. Lors de lapremire installation, on installe le noyau d'OpenERP avec un certain nombre de modulesdont modulebaseselon de prol d'installation choisit.OpenERP est bas sur une architecture multi-tiers. La logique d'OpenERP est enti-rement du ct serveur. Le client est unclient lger; son travail consiste demanderdes donnes (formulaires, listes, arbres) partir du serveur et de les renvoyer. Avec cetteapproche tous les dveloppements sont raliss sur le ct serveur. Ce qui rend Ope-nERPplus simple au dveloppement et la maintenance.Figure 1.5Architecture multi-tiers d'OpenERPL'architecture du systme OpenERP est 3 tiers : Un serveur de base de donnes PostgreSQL (qui peut contenir plusieurs bases de 16. CHAPITRE 1. PRSENTATION DU PROJET 8donnes) pour l'enregistrement de ces donnes, o OpenERP utilise unObjectRelational Mapping (ORM) pour la persistence de ses objets mtier. Un serveur d'applications (contenant les objets de gestion, le moteur de workow,le gnrateur d'dition, etc.). Un serveur de prsentation (appel OpenERP Web) qui permet l'utilisateur de seconnecter OpenERP avec n'importe quel navigateur internet.Le transport des donnes est ralis via XML-RPC, c'est un protocole RPC (Remoteprocedure call), une spcication simple et un ensemble de codes qui permettent desprocessus s'excutant dans des environnements dirents de faire des appels de mthodes travers un rseau.Figure 1.6Protocole XML-RPCOpenERP adopte le modle MVC avec une sparation stricte entre le modle de don-nes, la vue et les traitements.Figure 1.7Modle MVCUn (MVC) est une architecture de modles utilise en gnie logiciel. Dans des applica-tionscomplexes qui prsentent des lots de donnes aux utilisateurs, on souhaite souventsparer les donnes (modle) et l'interface utilisateur (vue), de sorte que les changements l'interface utilisateur n'aectent pas le traitement des donnes, et que les donnes peuventtre rorganises sans changer l'interface utilisateur. 17. CHAPITRE 1. PRSENTATION DU PROJET 9Le MVC rsout ce genre de problme en dcouplant l'accs des donnes et la logique desapplications de la prsentation des donnes et de l'interaction utilisateur, en introduisantun composant intermdiaire :le contrleur . Dans OpenERP, on peut appliquer cettesmantique de Model-View-Controller avec : Modle : les modles sont les objets dclars dans OpenERP. Ils sont galement destables PostgreSQL. Vue : les vues sont dnies en chiers XML dans OpenERP. Contrleur : le contrleur est Python qui contrle OpenERP.1.3 ProblmatiqueLes stocks reprsentent les biens achets, transforms ou vendre un moment donn.Ainsi, les principaux types de stocks sont : Le stock de marchandises. Les stocks des commerants (revente prot d'articlessans valeur ajoute de transformation par l'entreprise). Le stock de matires premires qui reprsente les articles achets auprs de four-nisseursen vue d'une transformation ultrieure. Le stock des produits en cours de fabrication (semi-nis) qui reprsente lesarticles qui ne sont pas vendables en l'tat car devant encore subir des transforma-tions. le stock des produits nis qui reprsente les articles que l'entreprise peut vendreaprs les avoir fabriques.Le cot d'entre d'un stock est constitu de : Cots d'acquisition : ce sont les prix d'achat des matires premires, fournituresou marchandises auquel s'ajoutent les ventuels frais de transport et de manutention,les droits de douane, les dirents taxes. Cots de transformation que sont les cots ajouts au cot d'acquisition an deparvenir au cot de production dtermin par la comptabilit analytique. Cots encourus pour amener les stocks l'endroit et dans l'tat o ils se trouvent.La valorisation des prix de revient des articles est trs importante, car c'est l'un desfacteurs primordiaux dans le calcul du prix de vente, ainsi c'est vital pour la rentabilitd'une entreprise.OpenERP utilise principalement deux mthodes, dans sa version standard, pour va-loriserle stock, ce qui provoque une insusance dans plusieurs cas de gestion en tenantcompte de la diversit des articles et des contraintes exiges. En eet, la valorisation destock est ralise selon deux mthodes, chacune possde des inconvnients : 18. CHAPITRE 1. PRSENTATION DU PROJET 10Mthode de cotPrix standard: Le systme n'intervient pas pour changerle prix de l'article congur par cette mthode. L'intervention du gestionnaire de stockest directe, o il eectue la mise jour du prix de revient d'article sans tenir compte de lavaleur relle du cot de rception de cet article dans l'entrept de l'entreprise. En eet, larcupration de cette dernire valeur, avec les outils existants dans OpenERP pour cettemthode, est trs dicile car ncessite une consultation des tous les bons de rceptionpour chercher dans chacune le prix unitaire de rception et la quantit pour qu'on calculele prix de revient.Mthode de cot base sur lePrix moyen: Le systme calcule le nouveauprix de revient aprs chaque rception. Le cas contraire de la mthode prcdente, carcette mthode calcule le cot unitaire pour un article stock dans l'entrept, mais la mise jour de prix de revient est eectu automatiquement pour chaque rception d'articlesans aucun contrle ou manipulation par le gestionnaire de stock, ce qui peut provoquerune mauvaise gestion.Nous remarquons aussi l'absence d'une mthode pour dnir le prix de revient selonle dernier cot, malgr l'importance de cette mthode pour un grand nombre d'article,o ce type de valorisation devient ncessaire aux plusieurs entreprises pour une gestionadquate. En plus, les articles fabriqus, dans certain cas seront valoriser et revu priodi-quementet non systmatiquement par le systme.1.4 ObjectifsL'objectif de ce projet est de dvelopper un module de gestion de prix de revientdans OpenERP. Ce module permet d'ajouter les insusances dans le calcul du prix derevient bas sur le dernier prix d'achat, et d'ajouter un processus de contrle permettantau gestionnaire de stock de mieux grer le changement des prix des articles. Ce moduledevrait proposer un workow pour grer la validation priodique des changements de prix.Il est demand aussi de faire le reporting ncessaires an de consulter l'tat valoris dustock.1.5 Choix mthodologiqueNotre dmarche est de comprendre le systme d'information, de cerner les besoins et deproposer des solutions qui rpondent ces besoins. La mthodologie suivie est composede deux parties : le formalise adopt et le processus adopt. 19. CHAPITRE 1. PRSENTATION DU PROJET 111.5.1 Langage de modlisation : UMLUne des phases cls dans le dveloppement d'une application est sans doute la phasede conception. Durant cette phase, nous allons essayer de prsenter les principales fonc-tionnalits implanter, de rchir sur l'aspect structurel de l'application et de concevoirles scnarios d'utilisation de l'application. Le but est de rduire la complexit du dve-loppementet d'avoir une vision des dirents angles de vues du systme d'information.Pour ce projet, on opte pour la notation UML.UML est la forme contracte d'Unied Modeling Language, qui peut se traduire enfranais par langage uni pour la modlisation. UML reprsente l'tat de l'art des lan-gagesde modlisation objet. Il fournit les fondements pour spcier, construire, visualiseret dcrire un systme. Pour cela, UML se base sur une smantique prcise et sur unenotation graphique expressive. Il dnit des concepts de base et ore galement des m-canismes d'extension de ces concepts.UML n'est pas un langage propritaire : il est accessible tout les fabriquant d'ou-tils,aussi les entreprises peuvent en faire usage. La volont d'ouverture, la richesse et lanotation de la dnition smantique prcise des lments de modlisation font d'UML unlangage gnral et simple, sans tre simpliste pour autant. [3]Dans UML chaque diagramme permet d'exprimer certains points de vue d'un mmeproblme. La combinaison de plusieurs diagrammes permettra donc d'avoir une vue com-plte du systme. Ainsi en fonction du problme rsoudre, il convient de choisir lesdiagrammes adquats utiliser. UML dnit neuf types de diagrammes dont nous d-taillerons ceux que nous utiliserons dans la suite :Diagramme de cas d'utilisation : Les cas d'utilisation dcrivent le comportementdu systme du point de vue utilisateur sous la forme d'actions et de raction. Un casd'utilisation indique une fonctionnalit du systme dclenche par un acteur externe ausystme. Ce genre de diagramme permet de mettre en place et de comprendre les besoinsdu client. Dans le diagramme, interviennent trois lments : les acteurs, le systme et lescas d'utilisations. L'acteur reprsente un rle jou par une personne ou un autre systmequi interagit avec systme en cours de modlisation. Un cas d'utilisation regroupe plusieursscnarios d'utilisation du systme.Diagramme de squence : Les diagrammes de squence permettent de reprsenterdes collaborations entre objet selon un point de vue temporel, on y met l'accent sur lachronologie des envois de messages. Les diagrammes de squences peuvent servir illustrerun cas d'utilisation. 20. CHAPITRE 1. PRSENTATION DU PROJET 12Diagramme de classe : Le diagramme de classe est le point central du dveloppementorient objet. En analyse, il a pour objectif de dcrire la structure des entits manipulespar les utilisateurs. En conception, le diagramme de classe reprsente la structure d'uncode orient objet ou, un niveau de travail plus important, les modules du langage dedveloppement.Diagramme tats-transitions : Les diagrammes d'tats-transitions d'UML dcriventle comportement interne d'un objet l'aide d'un automate tats nis. Ils prsentent lessquences possibles d'tats et d'actions qu'une instance de classe peut traiter au cours deson cycle de vie en raction des vnements discrets (de type signaux, invocations demthode).1.5.2 Processus de dveloppementUn processus de dveloppement logiciel est un ensemble d'activits permettant detransformer les besoins des utilisateurs en un systme logiciel. Avant d'adopter une m-thode, il faut d'abord faire une comparaison entre les direntes mthodes existantes, voirles points forts et les points faibles de chacune, puis dterminer celle qui va mieux dansle contexte du projet. Ci-dessous un tableau qui rsume cette comparaison.Table 1.1Tableau comparatif des mthodes de dveloppement 21. CHAPITRE 1. PRSENTATION DU PROJET 13Nous avons utilis le Processus Simpli comme un Processus de dveloppement logi-cielvu qu'il tait le plus adquat 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 extrme. N'utilise que 20% des diagrammes UML pour modliser 80% de l'application. La phase d'analyse de ce processus, comportant une tude du domaine (traduise parun diagramme des classes du domaine), est approprie l'esprit de la conceptionconduite par le domaine. La programmation extrme, tant une mthode agile de dveloppement, ne s'adaptepas notre projet vu que l'application raliser est dnie au dbut du stage.En gnral, le Processus Simpli est peru comme une solution intermdiaire entre leProcessus Uni et la Programmation extrme couvrant la fois les avantages des deuxprocessus et vitant leurs inconvnients. Le Processus Simpli est compos des phasessuivantes : tude des besoins : cette phase va tre labore dans le chapitre3 de notre rapport.Elle consiste dlimiter le systme en spciant les besoins fonctionnels et nonfonctionnels. Analyse : cette phase consiste modliser les besoins des utilisateurs l'aide dediagrammes de cas d'utilisation. Elle sera labore dans le chapitre3. Conception : cette phase regroupe les cas d'utilisation dtaills accompagn desdiagrammes de squence dtaills ainsi que les diagrammes de classe d'activit etde dploiement. Cette phase sera dtaille dans le chapitre4. Implmentation : cette phase expose la structure gnrale de l'application et pr-sente les principaux modules.ConclusionCe chapitre nous a permis de prsenter le cadre gnral de notre projet en introduisantl'entreprise d'accueil et en expliquant le travail demand et la mthodologie adopte. Nouspouvons maintenant passer l'tude de l'art. 22. Chapitre 2tat de l'artIntroductionAvant de commencer l'tape du dveloppement, nous avons cherch tout d'abord parmiles modules existants sous OpenERP, ceux qui orent des fonctionnalits exiges prc-demment dans le cahier des charges fonctionnel. Aprs une analyse des dirents modules,nous dcrivons les modules utiliss dans notre systme.2.1 ModuleGestion des Articles Dans le module responsable de gestion des produits et des listes des prix dans Ope-nERP,les articles peuvent avoir des variantes, direntes mthodes de calcul du prix,les informations des fournisseurs, direntes mthode de lancement de la fabrication (surstock ou sur commande), direntes units de mesures, dnir le conditionnement et lesproprits.Figure 2.1Formulaire Crer article Dans notre projet, nous mettons l'accent sur le traitement deMthode de cot .14 23. CHAPITRE 2. TAT DE L'ART 15Le champ marqu dans la gure de type liste droulante qui contient les deux mthodespermettant la valorisation de prix de revient :Prix standard: Le prix de revient est mise jour manuellement la n dechaque priode (gnralement chaque anne).Prix moyen: Le prix de revient est recalcul chaque rception.Le fait de choisir la mthode de cot bas sur lePrix moyen , le champPrixde revientdevient de typereadonly(en lecture seul) car la mise jour se faitautomatiquement en fonction de changement duPrix moyen . LePrix moyenestrecalcul chaque rception selon la formule suivante :Figure 2.2Formule de Prix moyenLe tableau 2.1 explique le processus de calcul de prix moyen lors des mouvementsentrants et sortant d'un article.Table 2.1Calcul Prix moyenPour chaque article, il faut dnir sa catgorie, soit en choisissant une des catgoriesdj crer ou on cre une nouveau. OpenERP simplie cette action, par la liste de recherchedans le formulaire de cration d'article o on peut trouver la possibilit de cration rapide.La gure 2.3 reprsente le formulaire de cration d'une catgorie. 24. CHAPITRE 2. TAT DE L'ART 16Figure 2.3FormulaireCrer Catgorie A l'aide de cette interface nous prcisions le compte comptable d'article reprsentdans le formulaire par la liste de slectionCompte d'entre en stock . En eet, sila valorisation du stock est faite en temps rel, les critures de contrepartie de tous lesmouvements de stock entrants seront passes sur ce compte, sauf si un compte particulierest prcis pour l'emplacement source. C'est la valeur par dfaut pour tous les articles decette catgorie. Il est galement possible de la prciser directement sur chaque article. Lescomptes comptables appartiennent un plan comptable dnit en installant le module Comptabilit et nance .2.2 ModuleComptabilit et Finance Figure 2.4ModuleComptabilit et nance Ce module ajoute les fonctionnalits comptables telles que les mouvements comptableset le plan comptable. Le plan comptable est l'ensemble des rgles d'valuation et de tenue 25. CHAPITRE 2. TAT DE L'ART 17des comptes qui constitue la norme de la comptabilit. Le plan de comptes, c'est--direla liste des comptes ordonne, est un des lments du plan comptable. C'est tort que lelangage usuel rduit souvent le plan comptable au seul plan de comptes.Au minimum, quatre types de compte sont ncessaires pour enregistrer les vnementsconomiques 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 oudiminue les capitaux propres. compte d'actifs, ce qui est possd ou peut l'tre. compte de passifs, ce qui est d aux tiers, dont le solde reprsente les capitauxpropres.Le tableau 2.2 dcrit les principales fonctionnalits de ce module.Table 2.2Fonctionnalits du ModuleComptabilit et Finance 26. CHAPITRE 2. TAT DE L'ART 182.3 ModuleGestion des achats Figure 2.5ModuleGestion des achats Le module achat permet de crer et de suivre les commandes fournisseurs, grer lesinformations fournisseurs, demandes de prix, de contrler le processus de rception desarticles et de vrier les factures des fournisseurs.Il permet aussi de crer une demande de prix lors d'un achat des articles un four-nisseurmais que l'achat n'est pas encore conrm. Le passage en revue est possible desdemandes de prix cres automatiquement et bases sur des rgles logistiques (stock mi-nimum,production la demande, etc.). Le gestionnaire peut convertir une demande deprix en bon de commande une fois que la commande est conrme. Ainsi slectionnercomment contrler les factures fournisseur : sur les commandes, sur les rceptions ou parsaisie manuelle. Le module achat permet de grer facilement l'approvisionnement par lesbons d'achats, et fournit des tableaux de bord et des rapports. Le tableau 2.3 dcrit lesprincipales fonctionnalits.Table 2.3Fonctionnalits du ModuleGestion des Achats 27. CHAPITRE 2. TAT DE L'ART 19Par le formulaire de la gure 2.6 le gestionnaire d'achat modlise le processus d'achatdes articles, en prcisant dans la pageBon de commandeles dirents articles acheter. Nous allons mettre l'accent sur cette partie qui contient les noms des articles, lesquantits et les prix d'achat pour valoriser chaque prix de revient d'un article en stock.Figure 2.6FormulaireCrer Bon de commande 2.4 ModuleGestion de Production Figure 2.7ModuleGestion de production Ce module permet de couvrir la planication, les ordres, les stocks, la fabricationet l'assemblage des produits partir de matires premires et de composants. Il gre laconsommation et la production de produit selon leur nomenclature et les oprations nces-sairesen machines, outils et ressources humaines en accord avec les gammes opratoires.Le moduleproductionsupporte l'intgration complte et la planication des biensstockables, consommables ou des services. 28. CHAPITRE 2. TAT DE L'ART 20Le tableau 2.4 dcrit les principales fonctionnalits du module production.Table 2.4Fonctionnalits du ModuleGestion de production 29. CHAPITRE 2. TAT DE L'ART 212.5 ModuleGestion de stock Figure 2.8ModuleGestion de stock OpenERP permet facilement de grer le stock, le prlvement, l'emballage et la li-vraisondes produits. OpenERP met la disposition des PME la valorisation des stocksen continu, mthode de gestion moderne utilise par tous les grandes entreprises depuisplusieurs dcennies.En plus OpenERP a invent le systme de double entre de la gestion du stock per-mettantde grer les besoins complexes trs facilement : le suivi des stocks des fournisseurs/ clients, une traabilit complte, liens comptables, etc.OpenERP supporte la multi-gestion d'entrept bas sur la structure de localisationhirarchique. Grez vos propres emplacements internes, externes, lieux des clients, desfournisseurs ou des inventaires de fabrication. Le tableau 2.5 dcrit les principales fonc-tionnalits de ce module.Table 2.5Fonctionnalits du Modulegestion de stock 30. CHAPITRE 2. TAT DE L'ART 22Par l'interface de la gure 2.9 le gestionnaire de stock conrme la rception d'un bonde commande trait par le gestionnaire d'achat. A cette phase le calcule pour valoriser lestock se dclenche, d'o c'est l'une des importantes actions qu'il faut tudier dans notreprojet.Figure 2.9InterfaceRception 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. Prt recevoir : une fois la commande est conrme par le gestionnaire d'achat. Reu : quand le gestionnaire termine la rception. 31. CHAPITRE 2. TAT DE L'ART 232.6 Processus de gestionComme la valorisation du stock d'un article est une phase ralise lors de la rceptiond'une quantit d'article stocker, prcde par des phases reprsentant la cause de cettequantit. Ainsi, nous allons expliquer les processus de ces phases pour bien comprendrela dmarche globale et an de dgager les points intressant dans notre projet.2.6.1 Rception par achatAu premier lieu, il faut crer des articles. C'est l'aide du formulaire de crationd'article (Figure 2.2). Le gestionnaire d'achat cre le bon de commande contenant lesarticles acheter et en prcisant la quantit et le prix unitaire (Figure 2.6). Aprs laconrmation du bon de commande, le gestionnaire de stock conrme la rception desarticles en consultant l'interface de bon de rception (Figure 2.11) et en prcisant lesarticles reus l'aide de l'assistantRecevoir article .Figure 2.10AssistantRception par article Lors de cette tape, les quantits achetes entre dans le stock avec changement duprix de revient. Donc il faut bien tudier cette partie dans notre projet. Nous allons nousintresser dans cette tape du calcul du prix de revient.2.6.2 Rception par productionComme le scnario prcdent, il faut crer d'abord un article. Ce qui est dirent dansce cas, c'est qu'il faut indiquer que l'article est obtenu par production. Ceci est eectu,en indiquant lors de la cration que la mthode de fourniture estProduire .Nous allons intresser aux ordres de fabrications an de valoriser les articles fabriqusqui seront stocks. 32. CHAPITRE 2. TAT DE L'ART 24Figure 2.11FormulaireCrer Ordre de fabrication La liste de slectionNomenclaturepermet de choisir une qu'tait dj cre oupour crer une nouvelle nomenclature, en eet la nomenclature permet de dnir la listedes matires premires pour la fabrication d'un produit ni.Figure 2.12AssistantCrer Nomenclature 33. CHAPITRE 2. TAT DE L'ART 25Aprs la cration d'un article et la dnition de la nomenclature, le gestionnairede production conrme l'ordre de fabrication ce qui provoque un mouvement des ma-tires premires, en attendant l'ordre de consommation an de produire l'articlear-ticle_Production .L'ordre de consommation eectu par le gestionnaire de production. Pour chaqueconsommation d'un article de la nomenclature, cet article passe d'unarticle consomm unarticle consommet nous allons mettre l'accent sur cette partie dans notreprojet car cette action permet de dnir le cot de production d'article.Aprs la consommation des tous les articles de la nomenclature, le responsable deproduction conrme la fabrication par l'interface assistant de fabrication qui ache laquantit et le mode :Figure 2.13AssistantFabriquer Aprs la conrmation de fabrication, l'article fabriqu s'ajoute au stock avec la quan-tit dj prcis mais le prix de revient ne change pas.Figure 2.14Interface Article 34. CHAPITRE 2. TAT DE L'ART 26ConclusionDans ce chapitre nous avons tudi les dirents modules lis notre projet et plusprcisment les modules agissant sur la valorisation du stock. Ainsi nous pouvons passeraux phases d'analyse et de conception de notre module en commenant par la phased'analyse qui correspond la prsentation de cahier de charges et les diagrammes de casd'utilisation gnrales. 35. Chapitre 3Analyse et spcication des besoinsIntroductionAprs avoir prsent le projet prcdemment et an de dterminer clairement les prin-cipalestapes suivre. Une tude de l'existant s'avre alors ncessaire dans le but deproposer un meilleur aspect pour la ralisation. Cette tude est d'une grande utilit pourdnir les exigences demands et surtout prciser les interactions et les intgrations dvelopper an de mieux prsenter nos fonctionnalits aux utilisateurs.3.1 Analyse de l'existantUne 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 mthodes et lesmodules existantes.3.1.1 Mthode de cot bas sur leDernier prix Malgr l'importance d'une mthode de valorisation base sur le dernier prix de r-ception, pour plusieurs types d'articles, la version standard OpenERP n'ore pas cettepossibilit qu' travers le module reporting.Figure 3.1Mthode de cot27 36. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 283.1.2 Consultation des articlesManque au niveau des services lis la consultation des indicateurs primordiaux pourune meilleure gestion de stock. En eet, pour chaque article le prix moyen pondr, quireprsente la valeur rel de la quantit en stock, et le dernier prix de rception, qui donneune vue approximatif la valeur du produit dans le march ou le cot rel de la fabrica-tion,sont ncessaire pour le gestionnaire de stock pour grer les articles et les comparesavec le prix de revient.Ainsi l'inexistence d'un moyen pour consulter, dans la che article, l'historique de sonprix de revient, an de former une ide sur son volution en fonction de temps et lesmthodes de cot utilis.3.1.3 Prix moyen pondr et le dernier prixDans ce qui prcde, nous avons indiqu l'importance de ces deux valeurs pour unarticle. Or le module gestion des achats dans la version standard d'OpenERP ne les traitepas.3.1.4 Valorisation du cot de fabrication d'un articleAprs un ordre de fabrication d'un article, le prix de revient ne change pas ; causede l'absence de calcul des cots de fabrication, en tenant compte la valeur des articlesconsomms. La gure 2.20 montre que la valeur du prix de revient ne change pas mmeaprs la fabrication, et aucune indication sur le cot de production.3.1.5 Changement automatique du prix de revientAbsence des outils organisationnels pour contrler et manipuler le changement de prixde revient par le gestionnaire de stock et le responsable gnrale, pour les articles grpar la mthode de cot bas sur lePrix moyen . 37. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 29Figure 3.2Changement automatique de prix de revintCette gure est un extrait de scnario du chapitre prcdent montre le changementautomatique du prix de revient. Alors que pour les articles bass sur la mthode de cot Prix standard , le processus de changement de prix est eectu par papier ce qui peutprovoquer plusieurs problmes : perte de temps, perte de document, des donnes fausses,des erreurs de saisis, etc.3.2 tude de besoinAprs une analyse de l'existant nous avons pu extraire les besoins pour grer les prix auniveau du module stock et production. Dans cette section, nous allons essayer de donnerune description des exigences fonctionnelles attendues3.2.1 Besoins fonctionnelsAmliorer la gestion des articles Intgrer une nouvelle mthode de cot bas sur leDernier prix: chaque r-ception d'article, le prix de revient change automatiquement pour prendre commevaleur le prix unitaire de dernire rception. Consulter le prix moyen. Consulter le dernier prix. Consulter l'historique des prix de revient pour chaque article. Intgrer des mthodes de cot permettant de crer des articles avec changement deprix de revient contrl par le gestionnaire de stock et valid par le responsable.Amliorer la gestion de productionIntgrer les traitements ncessaires pour calculer le dernier cot de fabrication et le prixmoyen pour chaque stock d'article fabriqu. 38. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 30Amliorer la gestion d'achatIntgrer les traitements ncessaires pour enregistrer le dernier prix d'achat d'un articleet calculer le prix moyen pour chaque stock d'article.Grer les demandes de changement des prix de revientAn de crer un processus de changement de prix de revient dans OpenERP, il fautpasser par l'intgration d'un nouveau module qui rpond certaines exigences : Cration d'une demande de changement des prix, qui permet au gestionnaire destock de prciser les articles changer ; et en achant les informations ncessairespermettant d'orir une vue sur le changement de la valeur globale du stock, si cettedemande est valid. Conrmation par le gestionnaire de stock Validation ou annulation par le respon-sablegnrale. Modication : la modication est permise tant que la demande n'est pas encoreconrme. Suppression demande. Consultation demande. Faciliter la recherche des demandes travers des ltres. Raliser le reporting ncessaire an d'obtenir des ches des demandes pour les en-treprisesqui exigent la signature pour la validation.3.2.2 Besoins non fonctionnelsLes besoins non fonctionnels dcrivent souvent les besoins d'utilisation qui font r-frence des aspects gnraux de l'application. Donc pour bncier d'une applicationable et ecace il faut qu'elle rponde un certain nombre de besoins non fonctionnels : Raliser des interfaces ergonomique et facile utiliser, donc elles satisfont le critrede convivialit. Assurer l'homognit des interfaces du module intgrer avec celles d'OpenERP. L'utilisateur doit tre guid lors de la saisie de certaines informations, an de res-pecterles formats des champs de base de donnes. L'utilisation du moteur workow d'OpenERP. la prcision dans les messages d'erreurs. L'optimalit dans le temps de rponse et la rapidit du traitement. L'internationalisation. L'utilisation des aspects implments dans OpenERP : La condentialit des donnes. Assurer la scurit de l'application. Utiliser les notions de sessions et authentication. 39. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 313.3 Diagramme de cas d'utilisationLa conception sera modlise l'aide du langage UML (Unied Modeling Language) enraison de son formalisme relativement simple. C'est un langage qui permet une meilleurecomprhension du systme et qui dsigne l'interface entre les dirents acteurs d'un projetcommun.3.3.1 Identication des acteursL'analyse dans la dmarche d'UML dbute par la recherche des acteurs du systme.En eet, un acteur est toute entit qui joue un rle, actif ou passif, vis--vis le systme.Un acteur peut tre un utilisateur direct du systme, un administrateur (assure la main-tenance)du systme ou tout autre systme externe avec lequel le systme interagit. cestade nous allons dterminer les six acteurs principaux interagissant avec le systme.Table 3.1Acteurs principaux 40. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 323.3.2 Diagramme de cas d'utilisation globalLe diagramme des cas d'utilisation est la solution UML pour reprsenter le modleconceptuel et pour structurer les besoins et les objectifs. Il reprsente les utilisations pos-siblesdu systme par les dirents acteurs. Un cas d'utilisation reprsente un ensemble desquence d'actions ralises par le systme et produit un rsultat observable intressantpour un acteur particulier.Nous prsentons le diagramme de cas d'utilisation global et nous dtaillerons parla suite les cas d'utilisation ncessitant une description plus approfondie. Cette gurereprsente le diagramme gnral de notre systme :Figure 3.3Diagramme de cas d'utilisation globalCas d'utilisationGrer articleTitre : Grer article. Description : le gestionnaire de stock possde le privilge d'eectuer des tches degestion sur les articles. Il peut ajouter, modier, consulter ou supprimer des articles. Acteur : Gestionnaire de stock. Pr-condition : le gestionnaire de stock est authenti. Scnario : Le gestionnaire de stock accde au menu de gestion des articles. Le gestionnaire de stock choisit l'opration qu'il dsire eectuer sur l'article. Le systme vrie les contraintes relatives cette opration. Le systme enregistre les modications relatives l'article. Le systme ache l'cran de l'article en mode achage seul pour renseigner l'uti-lisateurde succs de l'enregistrement 41. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 33 Post-condition : l'article est modi suivant l'opration eectue par le gestion-nairede stock.Cas d'utilisationRecevoir articleTitre : Recevoir article. Description : Le gestionnaire de stock rceptionne les articles. Acteur : Gestionnaire de stock. Pr-condition : le gestionnaire de stock est authenti. Scnario : Le gestionnaire de stock accde au menu du bon de rception. Le gestionnaire de stock accde l'assistant de rception. Le gestionnaire de stock conrme la rception de chaque article. Le systme calcule pour chaque article le prix moyen et l'enregistre ainsi le dernierprix, et enregistre le prix de revient si la mthode d'article estPrix moyenou Dernier prix . Le systme enregistre les modications relatives au bon de rception. Post-condition : les articles du bon de commande sont stocks.Cas d'utilisationGrer Demande de changement des prixTitre : Grer demande de changement des prix. Description : le gestionnaire de stock possde le privilge d'eectuer des tchesde gestion sur les demandes. Il peut ajouter, modier, consulter ou supprimer desdemandes. Acteur : Gestionnaire de stock. Pr-condition : le gestionnaire de stock est authenti. Scnario : Le gestionnaire de stock accde au menu Changement des demandes. Le gestionnaire de stock choisit l'opration qu'il dsire eectuer sur la demande. Le systme vrie les contraintes relatives cette opration Le systme enregistre les modications relatives la demande. Post-condition : La demande est modie suivant l'opration eectue par le ges-tionnairede stock. 42. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 343.3.3 Diagramme de cas d'utilisationGrer article Figure 3.4Diagramme de cas d'utilisationGrer article Cas d'utilisationModier mthode de cotTitre : Modier mthode de cot. Description : modier la mthode de calcul de cot. Acteur : Gestionnaire de stock Pr-condition : le gestionnaire de stock est authenti et l'article est cr. Scnario : Le gestionnaire de stock accde au menu de gestion des articles. Le gestionnaire de stock choisit l'oprationmodier article . Le gestionnaire de stock slectionne une nouvelle mthode de cot. Le systme modie le type d'accs au champPrix de revientselon la nouvellemthode choisit. Le gestionnaire de stock conrme les modications. Le systme enregistre les modications relatives l'article. Le systme ache l'cran de l'article en mode achage seul pour renseigner l'uti-lisateurde succs de l'enregistrement. Post-condition : l'article est modi.Cas d'utilisationActualiser historiqueTitre : Actualiser historique Description : le gestionnaire de stock ache l'historique des prix de revient djutiliss auparavant. 43. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 35 Acteur : Gestionnaire de stock Pr-condition : le gestionnaire de stock est authenti. Scnario : Le gestionnaire de stock accde au menu de gestion des articles. Le gestionnaire de stock choisit l'article consulter. Le gestionnaire de stock accde la pageHistoriqueLe gestionnaire de stock actualise l'historique. Le systme ache l'historique des prix de revient de cet article. Post-condition : l'cran historique est ach.Cas d'utilisationConsulter Prix moyenTitre : Consulter Prix moyen Description : le gestionnaire de stock aura la possibilit de consulter tout momentle prix moyen de chaque article. Acteur : Gestionnaire de stock Pr-condition : le gestionnaire de stock est authenti. Scnario : Le gestionnaire de stock accde au menu de gestion des articles. Le gestionnaire de stock choisit l'article consulter. Le systme charge les donnes acher pour cet article. Le gestionnaire de stock accde la pageInformationsPost-condition : Le prix moyen de l'article en stock est ach.3.3.4 Diagramme cas d'utilisationRecevoir article Figure 3.5Diagramme cas d'utilisationRecevoir article Cas d'utilisationFabriquer articleTitre : Fabriquer article 44. CHAPITRE 3. ANALYSE ET SPCIFICATION 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. Scnario : Le Responsable de production accde au menu des ordres de fabrications. Le Responsable de production choisit l'ordre de fabrication traiter. Le Responsable de production conrme la fabrication. Le systme dclenche les calculs ncessaires pour valoriser le cot de fabrication. Le systme enregistre les modications relatives l'article fabriqu. Post-condition : l'ordre de fabrication est termin et la quantit de l'article eststocke.3.3.5 Diagramme cas d'utilisationGrer Demande de change-mentdes prixpar le gestionnaire de stockFigure 3.6Diagramme cas d'utilisationGrer demande de changement des prix Cas d'utilisationConrmer demandeTitre : Conrmer demande. Description : le gestionnaire de stock conrme la demande de changement des prix. Acteur : Gestionnaire de stockPr-condition : le gestionnaire de stock est au-thenti. Scnario : Le gestionnaire de stock accde au menu Changement des prix. Le gestionnaire de stock choisit la demande conrmer. Le systme vrie les contraintes relatives cette opration. Le systme modie l'tat de demande demande conrm. 45. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 37 Le systme modie le type d'accs la demande en lecture seul. Post-condition : la demande de changement des prix est conrme.3.3.6 Diagramme de cas d'utilisationCrer Demande de chan-gementdes prix Figure 3.7Diagramme cas d'utilisationCrer Demande Cas d'utilisationCrer demandeTitre : Crer demande Description : le gestionnaire de stock Acteur : Gestionnaire de stock Pr-condition : le gestionnaire de stock est authenti. Scnario : Le gestionnaire de stock accde au menu Changement des prix. Le gestionnaire de stock choisit l'optionCrer . Le gestionnaire de stock charge la liste des articles changer. Le gestionnaire de stock donne l'ordre pour calculer les valeurs des comptes comp-tablesassoci aux articles. Le systme enregistre la demande avec tatbrouillon . Post-condition : une demande de changement des prix est cre. 46. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 38Cas d'utilisationCharger par ajout articleTitre : 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. Scnario : Le gestionnaire de stock accde au menu Changement des prix. Le gestionnaire de stock choisit l'optionCrerouModierune demandeen tat brouillon. Le gestionnaire de stock accde au menu Changement des prix. Le systme vrie les contraintes relatives cette opration. Le systme enregistre les modications relatives l'article. Post-condition : La liste des articles changer d'une demande est charge.Cas d'utilisationCharger par assistantTitre : Charger par assistant Description : le gestionnaire de stock charge la liste des articles changer enutilisant un assistant. Acteur : Gestionnaire de stock Pr-condition : le gestionnaire de stock est authenti. Scnario : Le gestionnaire de stock accde au menu de Changement des prix. Le gestionnaire de stock choisit l'opration qu'il dsire eectuer sur l'article. Le systme vrie les contraintes relatives cette opration. Le systme enregistre les modications relatives l'article. Post-condition : La liste des articles est charge. 47. CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS 393.3.7 Diagramme cas d'utilisationGrer Demande de change-mentdes prixpar le ManagerFigure 3.8Diagramme cas d'utilisationGrer Demande de changementpar leManagerCas d'utilisationValider demandeTitre : Valider demande Description : le Manager valide une demande de changement des prix Acteur : Manager Pr-condition : le Manager est authenti. Scnario : Le Manager accde 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 systme modie les prix de revient des articles de la liste. Le systme enregistre les modications relatives la demande. Post-condition : la demande de changement des prix est valide et les prix derevient des articles sont changs.Cas d'utilisationAnnuler demandeTitre : Annuler demande Description : Le Manager annule une demande de changement des prix. Acteur : Manager. Pr-condition : Le Manager est authenti. Scnario : Le Manager accde au menu Changement des prix. Le Manager choisit la demande conrm. 48. CHAPITRE 3. ANALYSE ET SPCIFICATION 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 systme enregistre les modications relatives la demande. Post-condition : La demande de changement des prix est annule.ConclusionDans ce chapitre, nous avons prsent une tude de l'existence ainsi que les besoinsfonctionnels et non fonctionnels qui ont t illustrs par des diagrammes de cas d'uti-lisations.Dans le chapitre qui suit, on se propose de faire une conception dtaille duprojet. 49. Chapitre 4ConceptionIntroductionAprs avoir spci les besoins et xer les choix conceptuels qui seront adoptslors de la ralisation de notre projet, nous abordons la phase de la conception. Dansce chapitre, nous allons dtailler la conception de chaque fonctionnalit part. Cettephase de conception est primordiale dans le cycle de vie d'un logiciel : elle permet demettre en place un modle sur lequel nous allons s'appuyer tout au long de la phase dedveloppement.4.1 Diagramme de classesLe diagramme des classes identie la structure des classes d'un systme, y com-prisles proprits et les mthodes de chaque classe. Les diverses relations, telles que larelation d'hritage par exemple, qui peuvent exister entre les classes y sont galementreprsentes. Le diagramme des classes est le diagramme le plus largement rpandu dansles spcications d'UML.Ce diagramme reprsente les classes relatives la conception de notre module, Ainsique les modications apportes sur les tables d'OpenERP. Remarque : les classes en blancprsentent la conception d'OpenERP dj existante.41 50. CHAPITRE 4. CONCEPTION 42Figure 4.1Diagramme de classes 51. CHAPITRE 4. CONCEPTION 43DescriptionPour mieux comprendre l'aspect d'intgration de notre module, nous allons aussi ex-pliquerles classes existantes :stock_pickingElle reprsente la rception et la livraison des articles : entrant dans le stock par achat ouproduction, ainsi les mouvements sortant du stock soit livraison (vente) ou consommationlors de la production. L'objet stock_picking reprsente un mouvement global compos deslignes lmentaires des mouvements de la transaction rception ou livraison).stock_moveElle reprsente le mouvement unitaire d'un article. C'est un lment du mouvementglobalstock_picking , qui prcise principalement la quantit, le prix et l'emplacementpour chaque article.stock_picking_extHrit de la classestock_picking . Il rednit la mthodedo_partialqui estresponsable de calcul du prix de revient an de contrler le changement automatique desprix de revient, et pour enregistrer le dernier prix et aussi calculer le prix moyen pourchaque mouvement.purchase_orderReprsente le bon de commande fournisseur, compos par des achats des articles re-prsents dans la classepurchase_order_line . La cration d'un bon de commande setermine par la cration d'un mouvement d'article vers le stock.purchase_order_lineElle dnit les lignes lies aux bons de commandes, qui identie l'article achet, saquantit et son prix unitaire.mrp_productionElle dnit l'ordre de fabrication d'un article, un article fabriqu consomme les matirespremiers partir de la nomenclature dnit dans la classemrp_bomqui reprsente lanomenclature d'un article fabriquer, o elle dnit la quantit unitaire de chaque articledes matires premiers et son prix de stock.mrp_production_extHrit de la classemrp_production . Elle rednit la mthode _cost_generate 52. CHAPITRE 4. CONCEPTION 44qui est responsable du calcul du cot de fabrication d'un article, an d'enregistrer lesvaleurs associ chaque fabrication et de contrler l'aectation de prix de revientproduct_productC'est la classe qui reprsente les articles, elle dnit toutes les informations sur unarticle : nom, code, catgorie, mthode de cot, prix de revient, etc.product_product_extHrit de la classeproduct_productan d'ajouter, les valeurs ncessaires lagestion du prix moyen et le dernier prix pour chaque article. Elle rednit l'attribut mthode de cotpour ajouter les nouvelles mthodes intgrer.stock_change_priceC'est la classe qui reprsente la demande de changement de prix de revient cre par legestionnaire de stock, une demande est dnie par les attributs rfrence, date de cration,total actuel(valeur actuel des tous les articles stocks associs des comptes comptablesdes articles existants dans la demande), nouveau total (c'est la valeur de stock atteint siles articles de la demande change de prix de revient),et enn l'attribut tat qui dsignel'tat de le demande (brouillon, conrm, annul, valid)stock_change_price_lineC'est la classe qui reprsente les articles changer associs une demande en identiantl'article, quantit en stock, le prix de revient actuel, le nouveau prix le total actuel,nouveau total etratiopour connaitre la progression de la valeur des articles en stockune fois les prix de revient changent.stock_compte_comptableCette classe dnit, pour une demande de changement, les comptes comptables associsaux articles ajouts dans la demande.stock_ll_change_priceElle dnit la liste des articles changer pour une demande en spciant le choix desmthodes de cot traiter (seulement les articles avec mthodes de cotPrix moyenControl , ou seulement lesDernier prix Control , ou les deux).product_historyCette classe reprsente l'historique des prix de revient pour tous les articles, en iden-tiant l'article, le nouveau prix de revient aect, la date d'aectation et la mthode decot utilise pour obtenir ce prix de revient. 53. CHAPITRE 4. CONCEPTION 454.2 Diagramme de squenceDans le formalisme UML, un diagramme de squence est une prsentation graphiquedes interactions entre les objets du systme selon un ordre chronologique. Un diagrammede cas d'utilisation peut seulement donner une vue gnrale simpli d'un cas ou d'un en-semblede cas d'utilisation et pour mieux dcrire chaque cas d'utilisation nous avons utilisle diagramme de squence. En eet Les diagrammes de squences sont la reprsentationgraphique des interactions entre les acteurs et le systme selon un ordre chronologiquedans la formulation UML. Ils servent illustrer un cas d'utilisation.Dans les diagrammes de squence, nous allons utiliser pour les requtes traitant lesobjets persistais les noms des mthodes ORM : Search : ore les fonctionnalits d'une requte de slection, elle retourne les identi-cateurs. Browse : permet de charger un tous les donnes d'un enregistrement. Unlink : permet de supprimer un enregistrement. Create : permet d'insrer un nouvel enregistrement. Write : permet de modier un enregistrement.4.2.1 Diagramme de squenceModier mthode de cot Figure 4.2Diagramme de squenceModier mthode de cot La gure 4.2 dcrit le droulement du cas d'utilisationModier mthode de cot ,qui apparat dans la gure : 3.5. Le gestionnaire de stock, accde l'cran de consultationd'article, ensuite il appuie sur le boutonModieret il modier la mthode de cot travers la liste des choix qui ache toutes les mthodes de cot dans OpenERP (les 54. CHAPITRE 4. CONCEPTION 46mthodes de la version standard et les mthode ajoutes). Aprs le gestionnaire de stockconrme la modication en appuyant sur le boutonEnregistrerqui dclenche letraitement de modication de la mthode de cot en interagissant avec l'objet persist.4.2.2 Diagramme de squenceActualiser historique Figure 4.3Diagramme de squenceActualiser historique La gure 4.3 dcrit le droulement du cas d'utilisationActualiser historique , quiapparat dans la gure : 3.4. Chaque utilisateur de l'OpenERP, peut accder l'cran deconsultation d'article, ensuite il clique sur l'onglet de la page historique, et aprs il appuiesur le bouton d'actualisation qui envoie, partir de la couche de traitement, une requtede slection traitant l'objet persisthistorique(qui contient l'historique de tous lesarticles) an de rcuprer seulement les donnes lie l'article courant. Les donnes serontstockes dans une table rserve pour l'achage de l'historique d'un article. 55. CHAPITRE 4. CONCEPTION 474.2.3 Diagramme de squenceRecevoir articles achets Figure 4.4Diagramme de squenceRecevoir article achet La gure 4.3 dcrit le droulement du cas d'utilisationRecevoir article achet ,qui apparat dans la gure : 3.5. Le gestionnaire de stock, accde l'cran de consulta-tiond'un bon de rception non encore reu, il appuie sur le boutonReuqui faitapparatre l'assistantRecevoir articlequi ache les articles non reu d'un bon decommande. Le gestionnaire de stock conrme la rception en cliquant sur le bouton rece-voir.Ce qui produit un appel la mthodedo_partailde la couche du traitement stock_picking . Rcuprer, au dbut, les mouvements entrants en interrogeant son objetpersiststock.move , pour extraire les donnes des articles entrants. Ensuite calculerle nouveau prix moyen de chaque article. Finalement, mettre jour le prix moyen et ledernier prix pour chaque article , travers l'objet persistArticle , et modier le prixde revient si la mthode de cot de l'article n'est pas contrl. Pour les mthodes decot automatique, enregistrer le changement de prix de revient travers l'objet persist Historique . 56. CHAPITRE 4. CONCEPTION 484.2.4 Diagramme de squenceFabriquer article Figure 4.5Diagramme de squenceFabriquer article La gure 4.5 dcrit le droulement du cas d'utilisationFabriquer article , quiapparat dans la gure : 3.5. Le responsable de production, accde l'cran de consul-tationd'un ordre de fabrication non termin. Il appuie sur le boutonFabriquerquifait apparatre l'assistantFabriquer article , en achant l'article fabriquer ainsi saquantit. Le responsable de production conrme la fabrication en cliquant sur le bouton Fabriquer , qui fait appel la mthodedo_producede la couche du traitement deproduction. Au dbut, le traitement de la mthode commence par rcuprer les mouve-mentsdes articles consomms en interrogeant son objet persiststock.move . Ensuiteextraire les donnes des articles consomms an de calculer le cot de fabrication et lenouveau prix moyen de cet article. A la n, faire les modications dans l'objet persist del'article concernant le prix moyen, dernier prix et le prix de revient selon la mthode decot utilis. Pour les mthodes de cot automatique, enregistrer le changement de prixde revient travers l'objet persistHistorique . 57. CHAPITRE 4. CONCEPTION 494.2.5 Diagramme de squenceCharger par ajout article Figure 4.6Diagramme de squenceCharger par ajouter article La gure 4.6 dcrit le droulement du cas d'utilisationCharger par ajout article, qui apparat dans la gure : 3.7. Le gestionnaire de stock, accde l'cran de crationd'une demande de changement des prix, dans la liste des articles changer il saisit le nomd'article. L'ajout d'article dclenche le traitement de la mthodeon_change_product pour calculer le nouveau total et acher le prix de revient actuel et le nouveau prix derevient en interrogeant l'objet persistArticle .4.2.6 Diagramme de squenceCharger par assistant La gure 4.6 dcrit le droulement du cas d'utilisationCharger par assistant ,qui apparat dans la gure : 3.7. Le gestionnaire de stock, accde l'cran de crationd'une demande de changement des prix. Il appuie sur le boutonCharger Listequifait apparatre l'assistant de chargement. Il spcie les mthodes de cot traiter et ilprcise les comptes comptables des articles changer. Ensuite il appuie sur le bouton Charger listequi dclenche le traitement de la mthodeaction_consultqui permet dercuprer les articles associs aux comptes comptables prciss selon la mthode spci.Ensuite la mthode calcule les totaux actuels et les nouveaux totaux , et les enregistre, travers l'objet persist de la liste des articlesArticles-Demande.Enn fermer l'assistantet acher les articles changer. 58. CHAPITRE 4. CONCEPTION 50Figure 4.7Diagramme de squenceCharger par assistant 59. CHAPITRE 4. CONCEPTION 514.2.7 Diagramme de squenceCalculer les valeurs des comptescomptables Figure 4.8Diagramme de squenceCalculer les valeurs des comptes comptables La gure 4.8 dcrit le droulement du cas d'utilisationCalculer les valeurs descomptes comptables , qui apparat dans la gure : 3.7. Le gestionnaire de stock, accde l'cran de cration d'une demande de changement des prix. Il accde l'onglet comptecomptable et il appuie sur le boutoncalculer . Le traitement commence par parcourirla liste des articles changer, et chercher pour chaque article son compte comptable etcalculer pour ce dernier les valeurs des totaux de ses articles stocks. 60. CHAPITRE 4. CONCEPTION 524.2.8 Diagramme de squenceValider demande Figure 4.9Diagramme de squenceValider demande La gure 4.9 dcrit le droulement du cas d'utilisationValider demande , quiapparat dans la gure : 3.8. Le Manager, accde l'cran de consultation d'une demandede changement des prix conrm, il consulte la liste des articles et la liste des comptescomptables. Aprs il valide la demande en cliquant sur le boutonValiderqui dclenchele traitement de la mthodeaction_donepour modier les nouveaux prix de revient, travers l'objet persistArticle , et enregistrer les changements travers l'objet persist Historique .4.3 Diagramme d'tats-transitionsUn diagramme d'tats-transitions est associ une classe et dcrit les squencesd'tats qu'un objet peut prendre en rponse un vnement. L'tat est une situationdans laquelle peuvent se trouver les objets d'une classe durant leur vie. Puisque un objetest toujours dans un tat dni ou connu pour un certain temps, les tats se caractrisentpar une dure dnie dans le temps et par une stabilit par rapport au temps. Dans untat, l'objet peut satisfaire des conditions, accomplir des actions ou ragir des vne-ments.Une classe, lorsque'elle a une dynamique non ngligeable, dispose de son automate,reprsent sous forme de diagramme d'tats transitions.Pour laborer ce diagramme, en premier lieu, il faut identier l'tat initial et l'en-sembledes tats naux, ensuite il faut identier les dirents tats intermdiaires et enn 61. CHAPITRE 4. CONCEPTION 53il faut relier ces tats entre eux en utilisant des transitions contrles par des conditionsde passage.Figure 4.10Diagramme d'tat-transitionDemande de changement Une demande de changement des prix, aprs sa cration, sera charge par les articles changer en restant dans l'tat Brouillon. Son tat passera alors l'tat conrm lorsquele gestionnaire de stock conrme l'mission au Manager et selon les dcisions prises pour sagestion, elle pourra tre annul ou valid. A tout moment la demande peut tre supprim,les tats naux reprsents par : Demande supprimer et Demande valid.ConclusionCe chapitre a permis de comprendre en dtails les direntes fonctionnalits atten-duesde notre module et l'enchanement de leur droulement dans le temps. Ceci donne lapossibilit de passer au dveloppement de la solution. Le cinquime chapitre portera surune description dtaille de l'environnement dans lequel notre projet a t ralis ainsiqu'une prsentation des interfaces. 62. Chapitre 5tude technique et RalisationIntroductionPour le dveloppement du systme nous nous sommes bass sur le Framework Ope-nERPet les direntes technologies qu'il utilise, et pour ajouter le systme comme moduleau sein de cet ERP nous avons eu recours plusieurs outils, dont la prsentation est d-taille dans les paragraphes suivants. Nous passerons ensuite aux dtails de la ralisation.5.1 Environnement logicielLe bon choix de l'environnement de travail est trs important. Dans ce chapitre, nousnous intressons aux choix des technologies et des environnements aidant l'implmen-tationde notre application.5.1.1 Outil de conception : PowerAMCAn de modliser notre travail en langage UML, nous avons utilis un logiciel completde modlisation intitul Power AMC dans sa version 15.1. C'est un outil tout-en-un de mo-dlisation d'entreprise et de gestion de mtadonnes destin documenter l'architectured'entreprise.Figure 5.1Logo PowerAMC54 63. CHAPITRE 5. TUDE TECHNIQUE ET RALISATION 55PowerAMC est un environnement graphique trs simple utiliser qui permet d'eec-tuerles tches suivantes : Modlisation intgre via l'utilisation de mthodologies et de notations standards : Donnes (E/R, Merise), Mtiers (BPMN, BPEL, ebXML), Application (UML), Gnration automatique de code via des Template personnalisables, SQL (avec plus de 50 SGBD), Java, NET. Fonctionnalits de reverse engineering pour documenter et mettre jour des sys-tmes existants, Une solution de rfrentiel d'entreprise avec des fonctionnalits de scurit et degestion des versions trs compltes pour permettre un dveloppement multiutilisa-teurs, Fonctionnalits de gnration et de gestion de rapports automatiss et personnali-sables, Un environnement extensible, qui vous permet d'ajouter des rgles, des commandes,des concepts et des attributs vos mthodologies de modlisation et de codage. [9]5.1.2 Systme de gestion de base de donnes : PostgreSQLNous avons utilis PostgeSQL dans sa version 9.2 comme systme de gestion de basede donnes relationnel objet (SGBDRO)Figure 5.2Logo PostgreSQLC'est un outil libre disponible selon les termes d'une licence de type BSD. Comme lesprojets libres, PostgreSQL n'est pas contrl par une seule entreprise, mais est fond surune communaut mondiale de dveloppeurs et d'entreprises. 64. CHAPITRE 5. TUDE TECHNIQUE ET RALISATION 56PostgreSQL peut stocker plus de types de donnes que les types traditionnels : entiers,caractres, etc. L'utilisateur peut crer des types, des fonctions, utiliser l'hritage de typeetc.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 possibilits de programmation tendues, directement dans le moteurde la base de donnes, via PL/pgSQL. Le traitement interne des donnes peut aussi trecoupl d'autres modules externes compils dans d'autres langages.5.1.3 diteur de texte : Notepad++Pour le dveloppement en langage Python, nous n'avons pas utilis d'environnementde dveloppement particulier. L'utilisation d'un diteur de texte avanc permet de rendrele code plus lisible et de fournir des fonctions supplmentaires. Le logiciel Open SourceNotepad++ a donc t mon diteur pour le dveloppement en Python et aussi pour XML.Figure 5.3Logo Notepad++Notepad++ est un diteur de code source qui prend en charge plusieurs langages. Ceprogramme, cod en C++ avec STL et win32 api, a pour vocation de fournir un diteur decode source de taille rduite mais trs performant. En optimisant de nombreuses fonctionstout en conservant une facilit d'utilisation et une certaine convivialit. Notepad++ oreplusieurs fonctionnalits : Coloration syntaxique et Relief syntaxique (Folding de syntaxe) Langage dnit par utilisateur PCRE (Perl Compatible Regular Expression) pour la recherche et le replacement Plan du document Auto-compltion Multi-documents (Les onglets) Multi-Vues WYSIWYG (What You See Is What You Get - verser l'impression). [10] 65. CHAPITRE 5. TUDE TECHNIQUE ET RALISATION 575.1.4 diteur de catalogues textuels : PoEditL'internationalisation d'un logiciel consiste prparer son adaptation des languesdirentes. Pour traduire OpenERP ou un de ses modules c'est mettre en Franais (ouautre langue) des phrases qui sont en Anglais. Pour cela nous avons utilis l'diteur PoEdit.Figure 5.4Logo PoEditPoEdit est un diteur de catalogues textuels (chiers ayant l'extension .po). C'est uneassistance prcieuse la traduction. Ce logiciel permet : de traduire automatiquement selon une base de donnes, de visualiser ergonomiquement dans un systme de double achage la version ori-ginaleet sa traduction, tout en travaillant et validant cette traduction, [11]Lors de la premire utilisation, le logiciel demande l'utilisateur de l'aider crer unebase de donnes qui l'aidera plus tard pour la traduction automatique. Cette oprationest assez longue mais ncessaire pour une traduction automatise.5.2 TechnologiesPour le dveloppement du systme je me suis bass sur l'ERP OpenERP et les di-rentes technologies et Framework qu'il utilise,dont la prsentation est dtaille dans lesparagraphes suivants.5.2.1 Framework OpenERPUn Framework est un ensemble de fonctions bas niveau qui permettent de grer lesbesoins et concepts les plus couramment utiliss dans le dveloppement d'un logiciel, etlui sert ainsi de base technologique. 66. CHAPITRE 5. TUDE TECHNIQUE ET RALISATION 58Anciennement connu parFramework OpenObject , mais comme cela tait sourcede beaucoup de confusion car beaucoup de gens se demandaient quelle tait la direnceentre OpenObject et OpenERP, cette appellation a t ociellement abandonne. CeFramework est un environnement qui dispose d'une boite outils complte et modulairepermettant un dveloppement simple et rapide des applications. Pour crer un moduleOpenERP, la cration d'un chier Python contenant la description des champs et desrgles de gestion et un chier XML dcrivant les crans, c'est susant. OpenERP aussipermet la cration de Wizards (sous-programmes), l'automatisation des tches et leurplanication, l'intgration de donnes par dfaut et/ou de dmonstration.Figure 5.5Module OpenERPLe Framework d'OpenERP se distingue par l'intgration d'un ORM, un moteur deworkow et un moteur de rapports et plusieurs fonctionnalits.ORM : Object Relational MappingOpenERP utilise un ORM pour la persistance de ses objets mtier. Ds ses dbuts,OpenERP s'est dot d'un ORM, alors que cette technologie tait encore trs peu rpan-due.L'ORM permet d'avoir une couche d'abstraction par rapport la base de donnes ;il gre les droits d'accs et vite d'avoir crire le code SQL dans lequel il faut refairetoutes les relations entre les tables avec des JOIN. En eet, c'est une technique de pro-grammationqui cre l'illusion d'une base de donnes oriente objet partir d'une basede donnes relationnelle en dnissant des correspondances entre cette base de donneset les objets du langage utilis. C'est une correspondance entre monde objet et monderelationnel. L'ORM d'OpenERP ne fonctionne qu'avec PostgreSQL. 67. CHAPITRE 5. TUDE TECHNIQUE ET RALISATION 59Figure 5.6ORM d'OpenERPCette couche (notamment dans OpenERP) permet de centraliser les vrications dela validit des donnes lors de la sauvegarde, les vrications des droits d'accs, etc.Les objets mtier sont dclars comme des classes Python hritant de la classe osv setrouvant dans le module osv( l'Object ServiceOSVimplmente une couche completde mapping objet-relationnel), ce qui les rend partie de la modle OpenERP, et persistpar la couche ORM.Figure 5.7Objet OpenERPOpenERP a fait voluer son ORM au fur et mesure des versions, mais continued'utiliser son propre ORM et n'a pas bascul vers un ORM librestandard . Cependant,il reste possible d'utiliser des requtes SQL dans le code d'OpenERP, par exemple pourcertaines parties du code o les performances sont trs importantes.Moteur de workowLe workow (ux de travaux) concerne l'analyse, la modlisation et l'automatisationdes ux d'information dans l'entreprise. Il s'appuie sur des outils informatiques automa-tisantla circulation des documents. Il permet ainsi d'organiser dynamiquement les tchesau sein d'un cheminement document, plani, contrlable en permanence et aismentadaptable au gr des volutions de l'environnement. 68. CHAPITRE 5. TUDE TECHNIQUE ET RALISATION 60Il existe plusieurs types de workow : Le workow administratif, concernant les documents internes l'entreprise (enga-gementde dpense, gestion des absences...). Le workow de production, concernant les procdures classiques de l'entreprise (prisede commande, mission de facture, gestion des rclamations des clients...). Le workow collaboratif, qui fait intervenir des acteurs internes ou externes sur unsujet commun (documentation technique, fourniture de produits complexes...).Bien que ncessitant un investissement important et la rorganisation des processus del'entreprise, la mise en place d'un workow apporte des avantages substantiels : Diminution des dlais de raction. Augmentation de la productivit (essentiellement dans les services administratifs). Diminution des erreurs.OpenERP intgre un moteur de workow. Ceci permet de formaliser les rgles mtier del'entreprise an d'automatiser la prise de dcision, c'est--dire la branche du workow choisir, en fonction du contexte donn. [12]Moteur de rapportLe moteur de rapport par dfaut d'OpenERP est bas sur le langage RML, qui estun standard mis au point par la socit anglaise ReportLab. La socit ReportLab advelopp une implmentation OpenSource limite et une implmentation propritairepayante plus complte du langage RML.OpenERP a ralis sa propre implmentation du langage RML en dveloppant un outilde conversion RML vers PDF et RML vers HTML. Cette implmentation est disponibledans le serveur OpenERP.Il y a 2 faons 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 transfrer le chier SXW (leformat de chier d'OpenOce 1.x) rsultant dans un module OpenERP. Le chierest 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 OpenERPva lire le chier RML (cod ou gnr partir du chier SXW), puis il va remplacer leschamps par leur valeur, et enn il va utiliser son moteur de conversion RML2PDF ouRML2HTML pour convertir le chier RML au format PDF ou HTML.[13] 69. CHAPITRE 5. TUDE TECHNIQUE ET RALISATION 61L'accs gnralis via les web services en XML-RPCToutes les communications entre le Framework et les interfaces sont eectues enXMLRPC. Les types d'objets, les crans, les donnes sont transmises par ce protocole.Tous les objets d'OpenERP sont accessibles via les web services, que ce soit en lecture,criture, cration et suppression. Aussi toutes les fonctions d'OpenERP sont accessiblesen web services. Cela signie par exemple que n'importe quel clic sur un bouton de l'in-terfaced'OpenERP peut tre fait depuis un web service.Comme l'accs via les web services est une fonction native du Framework, lors dedveloppement d'un module spcique qui cre un nouvel objet, et un nouveau bouton,alors cet objet et ce bouton seront automatiquement accessibles en web services, sanscrire du code spciquement pour cela.5.2.2 Langage de programmation : PythonLe Framework d'OpenERP utilise le langage Python (version 2.7) ; plus prcisment,il impose que les modules soient crits en Python et il est lui-mme cod en Python.Figure 5.8Logo PythonPython est un langage de programmation libre et orient objet, qui est connu pourtre lisible et facile utiliser pour le dveloppeur. Il est livr avec un dbugger intgr, quipermet de travailler ecacement sur les bugs. C'est un langage interprt et non compil,ce qui implique qu'il est beaucoup moins rapide que des langages compils comme le Cou le C++ et un peu moins rapide que des langages semi-compils comme Java. Pythondispose d'une large communaut, ce qui permet d'avoir accs un vaste choix de librairies,matures pour la plupart.[14]Les principales caractristiques du langage Python : Portable : Il est support par les dirents systmes d'exploitation. Python pos-sde actuellement deux implmentations. L'une, interprte, dans laquelle les pro-grammesPython sont compils en instructions portables, puis excuts par une 70. CHAPITRE 5. TUDE TECHNIQUE ET RALISATION 62machine virtuelle (comme pour Java, avec une dirence importante : Java tantstatiquement typ, il est beaucoup plus facile d'acclrer l'excution d'un programmeJava que d'un programme Python). L'autre gnre directement du bytecode Java ; Orient objet et supporte l'hritage multiple et la surcharge des oprateurs ; Simple : Il possde une syntaxe trs simple tout en combinant des types de donnesvolus (listes, dictionnaires. . .) ; Dynamiquement typ ; Gre ses ressources (mmoire, descripteurs de chiers...) sans intervention du pro-grammeur,par un mcanisme de comptage de rfrences ; Gratuit et soutenu par la communaut d'utilisateurs qui tentent l'voluer.5.2.3 XMLOpenERP utilise XML pour la description des donnes, la description des interfaces,la description des rapports et la description des workow.XML (eXtensible Markup Language et en Franais Langage balises tendu, ou Lan-gage balises extensible) est un langage simple et puissant de description et d'changede documents structurs de n'importe quel domaine de donnes grce son extensibilit,il dcrit cette structure l'aide d'un systme de balises.Quelques points remarquables d'XML : Il apparat comme un format d'change de donnes universel ; Il a la possibilit de crer des nouvelles balises contrairement HTML qui dnitun nombre limit ; Il garantit ses utilisateurs l'indpendance de leurs documents de toute technologiepropritaire ; Il unie le monde du traitement de document et celui du Web.5.2.4 RMLOpenERP utilise une extension du XML pour dnir les rapports : leRML . Leschiers RML dcrivent la structure du document ainsi que les expressions et les champs inclure. C'est un langage XML de style pour dcrire la mise en page de documents. Ilpermet aussi de dnir et manipuler n'importe quel aspect d'un document, y compris lecontenu et le style, en utilisant des balises dont la p