Vous êtes sur la page 1sur 53

PolytechTours Dpartement Informatique 64, avenue Jean Portalis 37200 - Tours

Rapport de Stage : Dveloppement sur l'ERP libre OFBiz-Nogia

Responsable de Stage : Olivier HEINTZ Nride 3 bis, les Isles - 37270 Vretz

tudiant : Graud BUXEROLLES EPU-DI 3me anne Anne 2005

Remerciements
Mes remerciements vont tout d'abord mon responsable de stage Monsieur Olivier Heintz, pour sa disponibilit, ses explications, sa patience et sa bonne humeur. Je souhaite galement remercier Messieurs Jean-Luc Malet et Pierre Gaudin, avec qui j'ai collabor sur le modules Order et Facility, pour les multiples claircissements rapidement dispenss, ainsi que Madame Sophie Benaroch pour sa parfaite connaissance de l'anglais. Je n'oublie pas mes collgues stagiaires, Monsieur Majid El Idrissi et Monsieur Peter Goron ; le premier pour son esprit droit mais nanmoins enjou, le second pour son aide claire et prcise ainsi que son inexpugnable srieux. Je souhaite enfin remercier tous les collaborateurs de Nride pour l'ambiance agrable et conviviale qu'ils ont su faire rgner dans leur socit, ainsi que tous les membres de la famille Heintz de nous accueillir chez eux l'heure du djeuner et spcialement Madame Catherine Heintz pour ses desserts ingals.

Rapport de Stage EPU-DI 3me anne 2

Graud BUXEROLLES Anne 2005

Sommaire
Table des matires
Remerciements..................................................................................................................................... 2 Sommaire..............................................................................................................................................3 Introduction.......................................................................................................................................... 4 Prsentation de l'entreprise................................................................................................................... 5 1.Nride..........................................................................................................................................6 2.Le rseau Libre-entreprise.............................................................................................................7 3.Les socits partenaires de Nride ............................................................................................. 8 Prsentation de l'ERP OFBiz-Nogia................................................................................................... 9 1 Gnralits sur les ERP..............................................................................................................10 2 Prsentation d'OFBiz................................................................................................................. 12 3 OFBiz-Nogia............................................................................................................................ 22 Mes ralisations.................................................................................................................................. 26 1 Procdure de ralisation d'un ordre d'achat................................................................................27 4 Diagramme UML simplifi d'Order...........................................................................................38 5 Diagramme UML des relations entre Facility et Order..............................................................40 6 Ralisations sur le module Order...............................................................................................41 7 Ralisations sur le module Facility............................................................................................ 51 Conclusion.......................................................................................................................................... 53

Rapport de Stage EPU-DI 3me anne 3

Graud BUXEROLLES Anne 2005

Introduction
Mon stage de 3me anne de lEcole Polytechnique Universitaire de Tours, s'est droul au sein de la socit Nride, SSLL (Solutions et Services en Logiciels Libres), spcialise dans le domaine de l'intgration de PGI Open Source destination des PME. En effet, le logiciel libre, Open-Source et Linux compris, n'est plus aujourd'hui un no-mans'land. Prs d'une grande entreprise sur deux, dclare avoir dj dploy des solutions logicielles non propritaires. L'un des principaux ressorts du "Libre" c'est la rduction des cots tout en circonscrivant les risques. Mais ce n'est pas tout, utiliser des logiciels libres reprsente aussi la garantie de travailler sur des standards ouverts et donc interoprablese et de bbfficier. En outre, le logiciel libre mobilise souvent des communauts, qui le font voluer au gr des nouveaux besoins, et qui peuvent rpondre rapidement des demandes prcises.

Mon travail au cours de ce stage s'est tout d'abord ax autour de la comprhension du PGI OFBizNogia : son implmentation, son fonctionnement et l'interconnexion entre les diffrents modules. Je me suis ensuite attach implmenter diverses fonctionnalits sur les modules Order et Facility. Ce rapport se divise en trois parties :

la premire partie s'attache prsenter la socit Nride ; la seconde tente de prsenter les ERP OFBiz et OFBiz-Nogia ; les dveloppements que j'ai effectus sont traits dans la dernire partie de ce document.

Rapport de Stage EPU-DI 3me anne 4

Graud BUXEROLLES Anne 2005

Prsentation de l'entreprise

Rapport de Stage EPU-DI 3me anne 5

Graud BUXEROLLES Anne 2005

1. Nride

La collaboration et les bonnes pratiques en action. Nride est une jeune SSLL, fonde en 2004 et spcialise dans l'intgration de l'ERP Open Source Ofbiz-Nogia auprs des PME. Il s'agit d'une SARL capital variable. Son sige social se situe une dizaine de kilomtres de Tours : Socit Nride 3 bis, Les Isles 37270 VERETZ En complmentarit avec l'intgration d'OFBiz-Nogia, cette socit propose une gamme complte de services :

dveloppement d'applications spcifiques : raliser ou accompagner le dveloppement de fonctions complmentaires OFBiz-Nogia et spcifiques au client ; administration de systmes : mettre en place un lment systme, un rseau, intgrer et migrer des composants systmes, administration de systme existant ... ; maintenance et support applicatif (TMA : Tierce Maintenance Applicative) : prestations de support et de maintenance corrective et / ou volutive pour toutes les applications dveloppes partir de l'architecture OFBiz-Nogia ; gestion du systme d'information (infogrance) : gestion globale du systme d'information du client, prestation effectue en trois phases : inventaire dtaill, transition et transformation.

De part sa participation au rseau Libre-Entreprise son offre de service peut tre tendue toutes les comptences des membres de ce rseau. L'quipe de Nride est actuellement compose de 7 personnes. L'quipe technique est constitue de personnes expertes dans la mise en uvre de PGI Progiciel de Gestion Intgr, (essentiellement Baan, SAP, Oracle) issues de grands cabinets de conseils internationaux.

Rapport de Stage EPU-DI 3me anne 6

Graud BUXEROLLES Anne 2005

2. Le rseau Libre-entreprise

Le rseau Libre-entreprise est un rassemblement d'entreprise toutes fortement impliques dans le domaine du logiciel libre. Les membres du rseau ont en commun des valeurs et un mode de fonctionnement bas sur :

le partage des connaissances ; la capitalisation des expriences clients et des ralisations ; le respect de tous les acteurs d'un projet ; la qualit des prestations.

L'appartenance d'une entreprise au rseau fait l'objet d'une valuation par les autres membres sur le respect de ces valeurs qui forment la base du rseau. Un compte rendu mensuel permet d'avoir une ide de la situation prcise de chaque entreprise, il porte sur leurs activits, leurs finances ... De nombreux documents sont partags afin d'aider les membres du rseau dans leur dmarches :

documents sur la cration de l'entreprise ; documents techniques ; modles de documents ;

Un ensemble doutils de travail collaboratif est mis la disposition des membres du rseau pour simplifier la communication et le partage des connaissances :

calendrier ; listes de diffusion partages ; serveur de messagerie instantane (Jabber) ; le laboratoire Libre-entreprise : une plate-forme dhbergement de projets informatiques tel que le clbre SourceForge. Elle offre les mmes services, savoir, site web, espace ftp, accs cvs, mailing-lists, etc. ; Planet Libre-Entreprise : cest un aggrgateur de contenu qui permet de suivre lactivit des membres du rseau.

Rapport de Stage EPU-DI 3me anne 7

Graud BUXEROLLES Anne 2005

3. Les socits partenaires de Nride


Nride a dvelopp des rapports troits de collaboration auprs de diffrentes socits afin de faire bnficier de leurs comptences le dveloppement d'OFBiz-Nogia. Les 7 Arts La SSLL, les 7 Arts s'est spcialise dans l'environnement libre depuis de nombreuses annes, aussi bien l'attention des PME que des particuliers dans la rgion de Montpellier. Son crateur, Jacques Le Roux, apporte sa contribution active au dveloppement de l'ERP OFBiz-Nogia, notamment sur le module Point de vente. TAU Le dveloppement du module Gestion de Production d'OFBiz a t l'occasion de travailler en partenariat avec la SSII TAU, socit situe en Italie. Depuis septembre 2003, elle participe concrtement l'laboration du module Gestion de Production en partenariat avec l'quipe de Nride. Son exprience dans la reprise des bases de donnes AS400 vers OFBiz est un atout majeur. Code Lutin Cre en 2002 par Cdric Pineau et Benjamin Poussin, Code Lutin est une jeune Socit de Services nantaise spcialise dans l'environnement libre. Leurs expertises mtiers dans la modlisation objet en UML et la gnration de code, les ont naturellement amens travailler avec Nride pour arriver une parfaite matrise des outils de gnration de code, travers l'utilisation de LutinGenerator (outil de gnration de code cr par la socit Code Lutin) utilis dans le processus de dveloppement de Nogia.

Rapport de Stage EPU-DI 3me anne 8

Graud BUXEROLLES Anne 2005

Prsentation de l'ERP OFBiz-Nogia

Rapport de Stage EPU-DI 3me anne 9

Graud BUXEROLLES Anne 2005

1
1.1

Gnralits sur les ERP


Dfinition

Un PGI progiciel de gestion intgr (en anglais Enterprise Resource Planning ou ERP) est un logiciel qui permet de grer l'ensemble des processus d'une entreprise en intgrant l'ensemble des fonctions de cette dernire comme la gestion des ressources humaines, la gestion comptable et financire, l'aide la dcision, mais aussi la vente, la distribution, l'approvisionnement, le commerce lectronique (Dfinition du grand dictionnaire terminologique de l'Office qubcois de la langue franaise (OLF)) Le principe fondateur d'un ERP est de construire une application (paie, comptabilit, gestion de stocks) de manire modulaire tout en partageant une base de donnes unifie. Cela cre une diffrence importante avec la situation pr-existante car les diffrentes fonctions de l'entreprise taient gres par une multitude d'applications ddies souvent htrognes. Ainsi, les Achats, la Comptabilit, la Gestion des Stocks, les Ressources Humaines, la Gestion Commerciale,... sont maintenant totalement interconnects. Avec l'arrive de l'ERP, les donnes sont dsormais standardises et partages entre les diffrents modules, ce qui limine les saisies multiples et vite l'ambigut des donnes multiples de mme nature (ex : Clermont-Fd , Clermont Ferrand , Clermont-Ferrand , ...). Ceci permet un accroissement considrable de la fiabilit des informations puisque la source des donnes est unique, d'o une rduction des dlais et des cots de traitements. L'autre principe qui caractrise un ERP est l'usage systmatique de ce qu'on appelle un moteur de workflow, et qui permet, lorsqu'une donne est entre dans le systme d'information, de la propager dans tous les modules du systme qui en ont besoin, selon une programmation prdfinie. Ainsi, on peut parler d'ERP lorsqu'on est en prsence d'un systme d'information compos de plusieurs applications partageant une seule et mme base de donnes, par le biais d'un systme automatis prdfini ventuellement paramtrable (un moteur de workflow).

1.2

Avantages
optimisation des processus de gestion (flux conomiques et financiers) ; cohrence et homognit des informations ; intgrit et unicit du systme d'information ; partage du mme systme dinformation facilitant la communication interne et externe ; globalisation de la formation (mme logique, mme ergonomie) ; matrise des cots et des dlais de mise en uvre et de dploiement.

Compars des applications sur mesure, les ERP / PGI prsentent plusieurs avantages :

Il est important de remarquer que la mise en place d'un ERP dans une entreprise est souvent le dclencheur d'une rorganisation et rationalisation de l'ensemble des tches et processus de l'entreprise.

Rapport de Stage EPU-DI 3me anne 10

Graud BUXEROLLES Anne 2005

1.3

Inconvnients
cot lev ; primtre fonctionnel souvent plus large que les besoins de l'organisation ou de l'entreprise (le progiciel est parfois sous-utilis) ; lourdeur et rigidit de mise en uvre ; difficults d'appropriation par le personnel de l'entreprise ; ncessit d'une bonne connaissance des processus de l'entreprise (par exemple, une commande d'achat et une commande de vente ncessitent deux processus diffrents : il est important de savoir pourquoi, de savoir dcrire les points communs et les diffrences entre ces deux processus de faon bien les paramtrer) ; ncessit d'adapter parfois certains processus de l'organisation ou de l'entreprise au progiciel ; ncessit d'une maintenance continue.

Les ERP / PGI ne sont cependant pas exempts d'inconvnients :

1.4

Les ERP libres

Le secteur des ERP a depuis quelques annes dj subi un petit bouleversement : l'arrive de logiciels libres (OFBiz Tiny ERP, ERP5, Compiere, ...) sur des terres o rgnent en matres les logiciels propritaires : SAP, BAAN, Oracle, ... Le premier avantage des ERP Libre sur leurs alter-ego propritaires est bien sr l'absence de cot de licence ; cot qui peut souvent apparatre comme prohibitif pour les PME. Un autre atout important est la possibilit d'adapter et de faire voluer soi-mme le progiciel sans dpendre du bon vouloir de la socit ditrice. En outre, le logiciel libre mobilise souvent des communauts, qui le font voluer au gr des nouveaux besoins, et qui peuvent rpondre rapidement des demandes prcises. De plus comme tout logiciel libre, les ERP libre donne la garantie de travailler sur des standards ouverts et donc inter-oprables, avantages stratgiques pour beaucoup d'entreprises. En parallle avec l'augmentation de l'utilisation des ERP en France :48 % des PME franaises sont quipes, et en janvier 2005, 9 % des PME franaises envisageaient d'acqurir et de mettre en place un nouvel ERP dans l'anne (Atelier groupe BNP Paribas), l'intrt port par les entreprises sur le logiciel libre progresse. Ainsi, 58 % des entreprises envisageraient de passer de leur ERP propritaire actuel un ERP libre en 2004 (ERP2004 INFOWORLD). La prsence du logiciel libre sur le march des ERP n'est donc plus marginal et les ERP Open Source prennent leurs places dans ce secteur.

Rapport de Stage EPU-DI 3me anne 11

Graud BUXEROLLES Anne 2005

Prsentation d'OFBiz

OFBiz (pour Open For Business ) est un projet d'ERP Open source initi en mai 2001 par deux amricains : Andy Zeneski et David E. Jones. Il est actuellement publi sous licence MIT, licence libre et permissive, c'est--dire quelle ne fixe aucune obligation et / ou interdiction quant lutilisation, la modification, lextension et la commercialisation du logiciel. Afin de vivre de leur progiciel, les deux initiateurs du projet - Andy Zeneski et David E. Jones - ont cr la socit Undersun Consulting (par analogie Andersen Consulting, un des Big Five du monde du Conseil en 1996-97) avec qui ils proposent tout l'ventail de service possible autour d'OFBiz : installation et intgration d'OFBiz, dveloppements spcifiques, formation des utilisateurs... OFBiz offre dj un grand choix de fonctionnalits incluant :

e-commerce avanc ; gestion de catalogue ; gestion des promotions et des prix ; gestion des ventes et achats ; gestion des clients ; gestion de stock ; mouvement de stocks, slection par lots ; comptabilit ; gestion de fabrication ; gestion de projets (vnements, tches, demandes, etc.) ; gestion de contenu.

Ce projet compte rassembler terme tous les modules permettant de grer les principaux processus d'une entreprise :

SCM (Supply Chain Management), ou en franais GCL, (Gestion de la Chane Logistique) CRM (Customer Relationship Management), ou GRC (Gestion de la Relation Client) MRP (Manufacturing Resource Planning), ou GPP (Gestion et Planification de la Production) CMS (Content Management System), ou SGC (Systme de Gestion de Contenu) CMMS (Computerized Maintenance Management System), ou GMAO (Gestion de la Maintenance Assiste par Prdinateur )

Le progiciel est entirement crit en JAVA sous une architecture J2EE, il respecte de nombreux standards notamment J2EE et XML afin de garantir son volutivit. Son norme avantage rside dans sa parfaite compatibilit avec tous les serveurs d'applications J2EE et toutes les bases de donnes du march.

Rapport de Stage EPU-DI 3me anne 12

Graud BUXEROLLES Anne 2005

2.1

Architecture d'OFBiz

OFBiz obit au standard J2EE qui offre un premire couche d'abstraction :

Image 1 : J2EE et OFBiz

Rapport de Stage EPU-DI 3me anne 13

Graud BUXEROLLES Anne 2005

Comme tout ERP qui se respecte, OFBiz est dcompos en niveaux, chacun offrant des services particuliers.

Image 2 Architecture d'OFBiz

Rapport de Stage EPU-DI 3me anne 14

Graud BUXEROLLES Anne 2005

De plus, les niveaux applicatifs sont dcomposs en module permettant un dveloppement modulaire tout en facilitant la rutilisabilit du code. Les interactions entre modules ainsi fixes, on peut aisment changer l'implmentation d'un module sans bouleverser compltement le systme.

Image 3 Architecture dtaille d'OFBiz

2.2

Le FrameWork

Le framework d'OFBiz est un de ses points forts. S'il a t dvelopp en premier lieu pour OFBiz, il est parfaitement utilisable pour d'autre application. Son fonctionnement repose sur trois composants majeurs que nous allons dcrire : l'EntityEngine, le ServiceEngine, le ControlServlet.

Entity Engine

L'Entity Engine d'OFBiz offre un ensemble d'outils et de mcanismes permettant la modlisation et la gestion des donnes. Une entit est un lment de donne dfini par des champs et un ensemble de relations avec les autres entits. La modlisation est base sur le modle entit-relation. Son but premier est de grer automatiquement la persistance des donnes dans une application transactionnelle. L'Entity Engine permet de s'abstraire de la base de donnes sous-jacente utilise. Ainsi les entits sont dfinies dans des fichiers au format XML (composant/entitydef/entitymodel.xml) qui permettront de faire le lien avec la source de donnes. Voici un exemple de dfinition d'une entit :
<entity entity-name="OrderType" package-name="org.ofbiz.order.order" title="Order Type Entity"> <field name="orderTypeId" type="id-ne" /> Rapport de Stage EPU-DI 3me anne 15 Graud BUXEROLLES Anne 2005

<field name="parentTypeId" type="id-ne" /> <field name="hasTable" type="indicator" /> <field name="description" type="description" /> <prim-key field="orderTypeId" /> <relation type="one" fk-name="ORDER_TYPE_PARENT" title="Parent" rel-entity-name="OrderType"> <key-map field-name="parentTypeId" rel-field-name="orderTypeId" /> /relation> </entity>

Sont donc dfinis : les proprits de l'entit : nom, paquet, titre ; les proprits des champs : nom, type (qui est automatiquement traduit en type SQL avec un correspondant Java) le nom des cls primaires (qui peuvent tre composes) ; les relations : le nom de l'entit avec qui se fait la relation, la cardinalit de la relation (1 ou 0..1 ou 0..*) Pour permettre de minimiser au maximum le code spcifique a une entit, les objets gnrs sont gnriques et on accde aux champs par une Map, la clef tant le nom du champ. Les classes du package org.ofbiz.entity dfinissent l'API pour interagir avec l'Entity Engine. Les classes utiles pour l'utilisateur sont : GenericValue : l'objet gnrique reprsentant l'entit ; GenericDelegator qui permet de manipuler les GenericValue, c'est--dire les crer, les trouver, les stocker.
Service Engine

Alors que l'Entity Engine s'attache grer les donnes, le Service Engine permet la manipulation des traitements. Il est capable de lancer un traitement quel que soit son langage ou sa localisation. La description des traitements (composant/servicedef/services.xml) : est contenu dans un fichier XML

<service name="updateOrderItems" engine="java" auth="true" location="org.ofbiz.order.order.OrderServices" invoke="updateApprovedOrderItems"> <description>Update the quantities/prices for an existing order</description> <attribute name="orderId" type="String" mode="INOUT" optional="false"/> <attribute name="itemQtyMap" type="Map" mode="IN" string-mapprefix="iqm_" optional="false"/> <attribute name="itemPriceMap" type="Map" mode="IN" string-mapprefix="ipm_" optional="false"/> <attribute name="overridePriceMap" type="Map" mode="IN" string-mapprefix="opm_" optional="false"/> <attribute name="shoppingCart" type="org.ofbiz.order.shoppingcart.ShoppingCart" mode="OUT" optional="false"/> </service>

Rapport de Stage EPU-DI 3me anne 16

Graud BUXEROLLES Anne 2005

Sont ainsi dfinis : le nom du service ; le langage utilis ; la localisation ; le nom de la fonction appeler les entres et les sorties, leurs caractres obligatoires, si un prfixe est stipul, toutes les donnes ayant ce prfixe sont automatiquement stockes dans une Map. La dfinition d'une mthode Java appele en tant que service est la suivante :
public static Map updateApprovedOrderItems(DispatchContext dctx, Map context) {

Les donnes en entres et sorties sont contenues dans le contexte, des tests sont automatiquement effectus afin de savoir si les donnes sont conformes leur types. Dans un code java, la mthode courante pour appeler un service de manire synchrone est d'utiliser la mthodes runSync() de la classe LocalDispatcher :
map_out = dispatcher.runSync("service_name", map_in);

Un service peut aussi tre lanc de manire asynchrone.


ControlServlet

Le ControlServlet est un ensemble de classe permettant la prsentation d'une application web autour du framework d'OFBiz. Son but premier est d'apporter un mcanisme de sparation propre entre la prsentation logique des donnes et l'affichage selon le principe modle-vue-contrleur. OFBiz propose une multitude de moteurs de rendu, les plus utiliss actuellement tant les Widgets. Je dtaillerai ici les mcanismes utiliss lors du cheminement de la requte deleteShipmentItemFromItems dans le module Facility, jusqu' l'affichage de la page Web correspondante : Etape 1 : Traitement effectuer la rception de la requte : La description des divers traitements effectuer composant/webapp/composant/WEB-INF/controller.xml : se trouve dans le fichier

<request-map uri="deleteShipmentItemFromItems"> <security https="true" auth="true"/> <event type="service" path="" invoke="removeOrderShipmentFromShipment"/> <response name="success" type="view" value="EditShipmentItems"/> <response name="error" type="view" value="EditShipmentItems"/> </request-map> <view-map name="EditShipmentItems" type="screen" page="component://product/widget/facility/ShipmentScreens.xml#EditShipmentItems" />

Ce qui peut se traduire en algorithmique par : Si l'URI de la requte = "deleteShipmentItemFromItems" Si l'utilisateur est authentifi et la connexion scurise Alors invoquer le service removeOrderShipmentFromShipment (les paramtres en entre de cette vue sont prsents sur la page actuel et sont transforms en objet Java)
Rapport de Stage EPU-DI 3me anne 17 Graud BUXEROLLES Anne 2005

Si le service appel rend faux Alors appeler la vue "EditShipmentItems" Sinon appeler la vue "EditShipmentItems" FinSi Finsi Finsi Si le nom de la vue = EditShipmentItems Alors appeler l'cran EditShipmentItems dans le fichier Finsi

//product/widget/facility/ShipmentScreens.xml

Etape 2 Cration de l'cran de rponse:

<screen name="EditShipmentItems"> <section> <actions> <set field="titleProperty" value="PageTitleEditShipmentItems"/> <set field="headerItem" value="shipment"/> <set field="tabButtonItem" value="EditShipmentItems"/> <script location="component://product/webapp/facility/WEBINF/actions/shipment/EditShipmentItems.bsh"/> </actions> <widgets> <decorator-screen name="CommonShipmentDecorator"> <decorator-section name="body"> <platform-specific> <html><html-template location="component://product/webapp/ facility/shipment/EditShipmentItems.ftl"/> </html> </platform-specific> </decorator-section> </decorator-screen> </widgets> </section> </screen>

Dans les actions sont stipuls les traitements effectuer :


positionnement de champs ; appel de fichiers beanshell (.bsh langage trs proche proche du Java, la diffrence tant qu'il n'est pas pr-compil mais directement interprt l'excution) qui permettront d'effectuer divers traitements ct serveur (interrogations de la base de donnes...) et de positionner dans le contexte diffrentes variables.

Les widgets assurent la prsentation des donnes. Des fichiers freemarker (moteur de template pour gnrer du texte) peuvent tre appels.

Rapport de Stage EPU-DI 3me anne 18

Graud BUXEROLLES Anne 2005

Exemple d'utilisation de beanshell et freemarker :

fichier Benshell :
context.put("name", new String( monsieur le correcteur));

Fichier freemarker :
<html> ... Bonjour ${name} !!!! ... </html>

Fichier html gnr :


<html> ... Bonjour monsieur le correcteur ... </html>

2.3
Content

Les diffrents modules

Le module Content permet d'assurer la gestion de contenu (CMS). Ses entits sont utilises pour enregistrer et manipuler les contenus gnraux et les bases de connaissance. Ces entits incluent de nombreux concepts tels que : la sparation de linformation et de lorganisation des donnes qui peut tre utilis dans beaucoup de structures de donnes comme des arbres, listes ou des Maps dobjets. Une fois ces structures cres, des outils volus de recherche dinformation sont utiliss pour automatiser la cration de nouvelles structures et permettre lentreprise de grer les documents.

Accounting

Les entits de Comptabilit sont organises sur des principes gnralement admis comme la comptabilit double entre, un registre gnral avec des comptes hirarchiss... Elles sont structures pour que l'on puisse grer la comptabilit de plusieurs organisations.

Rapport de Stage EPU-DI 3me anne 19

Graud BUXEROLLES Anne 2005

Party

Le module Party permet d'assurer la gestion de la relation client (CRM). Un Party peut reprsenter soit une personne physique soit un groupe (un groupe pouvant tre une entreprise, un fournisseur ou un ensemble de personnes). La notion de groupe permet de modliser des hirarchies, des groupes de scurit. Cette application est gnralement utilise pour grer les informations sur le personnel de lentreprise, sur les relations avec ses clients et ses fournisseurs, etc. chaque contact, on peut associer de nombreuses informations telles que des adresses, des numros de tlphones, des rles, et par un mcanisme d'extensions, des donnes supplmentaires.
Product

Les entits de Product contiennent les informations gnrales sur les produits vendables, achetables d'une entreprise. Les produits peuvent tre des articles (matires premires, produits finis ...), des services, ... Les produits peuvent tre organiss en catgories et en catalogue (notion de promotions, canaux de ventes...). Ils peuvent tre associs une multitude de prix selon la devise, le fournisseur, les dates, la quantit achete, etc.
Facility

Un Facility est un btiment ou un emplacement physique tel que les stocks, les magasins, les docks, les bureaux,... En gnral un Facility aura un contact associ : une adresse, un numro de tlphone, ... Les btiments peuvent tre regroups en groupe de btiments, eux-mmes pouvant faire partie de groupes de btiments. Ces groupes sont, par exemple, des chanes de magasins, rgions, dpartements. Des personnes ou groupes de personnes peuvent aussi tre associs des btiments pour dfinir o une personne travaille, qui gre le btiment, etc. Ce module permet de grer les stocks d'une entreprise, il connat ainsi pour un produit ses lieux de stockages, les quantits stockes et les indices de gestion de stock : seuils d'alerte, quantit conomique...
Order

Le module Order permet de grer tous les processus autour d'une commande d'achat ou de vente. Un ordre se compose dune en-tte de commande et de lignes de commandes qui dcrivent les dtails de lordre et des ajustements tarifaires. Ces ajustements correspondent aux promotions, aux taxes et aux frais de ports appliqus lordre. Toutes les tapes d'une commande sont gres du devis, la facturation en passant par la rception de la commande, la gestion du retour de marchandise, ...
Shipment

Shipment gre lensemble des changes de produits avec lextrieur, autrement dit les rceptions et les expditions ainsi que les entres et sorties de stock. On peut ainsi connatre pour un produit et un Shipment la quantit du produit expdie ou reue. Shipment fait aussi le lien avec les services des transporteurs pour le suivi des colis et des livraisons.

Rapport de Stage EPU-DI 3me anne 20

Graud BUXEROLLES Anne 2005

2.4

Processus de programmation

Il est vident que tous les programmeurs d'OFBiz ne travaillent pas en mme temps sur des sources partages par tous. Nous utilisons donc un systme de contrle des versions appel Subversion. Chaque programmeur travaille sur une copie locale des sources, cette copie pouvant tre mise jour avec la version la plus rcente d'OFBiz grce la commande : svn update dans le rpertoire d'OFBiz. La procdure de validation de nos dveloppements est en revanche extrmement fastidieuse. En effet, seules de rares personnes ont le droit de modifier les sources d'OFBiz. Les modifications apportes sont donc envoyes aux dveloppeurs d'Ofbiz sous forme de patch dcrivant prcisment les buts et raisons de ces modifications. L'incorporation de ces patchs (si ils sont un jour accepts) peut prendre un certain temps(plusieurs semaines) et est source de nombreuses discussions, les patchs n'ayant pas une utilit flagrante et immdiate sont ainsi souvent rejets. Les petites modifications sont beaucoup plus aisment admises et donc prfres. Or, un problme survient ici si vous voulez dvelopper rapidement une nouvelle fonctionnalit. Vous envoyez vos premiers patchs qui n'ont aucune utilit directe et ne sont valids qu'aprs de longues discussions. S'ils sont un jour valids, ils sont souvent modifis et donc vous de modifier tous les traitements qui en dcoulent de votre ct.

Rapport de Stage EPU-DI 3me anne 21

Graud BUXEROLLES Anne 2005

3
3.1

OFBiz-Nogia
Les origines d'OFBiz-Nogia

Bien qu'OFBiz soit totalement crit en Java, la modlisation utilise est un modle entit-relation. Ainsi, les entits de base de donnes ne sont pas traduites en objet, on accde donc directement aux tples de la base de donne. La puissance d'un langage objet est alors totalement sous-utilis, la plupart des mthodes est statique, on perd de plus le haut niveau d'abstraction offert par le langage objet. Le modle entit-relation qui s'attache la modlisation des donnes s'avre peu adapt la ralisation des composants mtiers o la modlisation des traitement est privilgier. Nride a donc initi en mai 2004, le projet Nogia publi sous licence GPL. Cette licence GPL moins permissive que la la licence MIT assure que le code ne sera jamais commercialis. Ce projet a pour but de fournir des outils permettant de crer des composants OFBiz grce une modlisation UML. Nride est en outre l'origine de internationalisation d'OFBiz.

3.2

La gnration de code

Neogia utilise la technologie Lutin-generator , dvelopp par l'entreprise Code-Lutin, afin d'obtenir du code partir de diagrammes UML. Les diagrammes sont crs grce au logiciel Poseidon_for_UML Exemple de diagramme UML utilis :

Rapport de Stage EPU-DI 3me anne 22

Graud BUXEROLLES Anne 2005

Image 4 exemple de modlisation UML

Un systme de tags permet de spcifier certaines caractristiques aux entits :

et aux attributs :

Rapport de Stage EPU-DI 3me anne 23

Graud BUXEROLLES Anne 2005

Cette gnration de code, qui peut paratre de prime abord comme un gadget , est dans les faits extrmement utile. En effet, un nombre impressionnant de fichiers (environ 70 %) est gnr faisant gagner un temps prcieux en dveloppement :

fichiers de dfinition des services ; fichiers de dfinition des entits ; fichiers Java permettant l'abstraction Objet<->Entit ; fichiers dinterfaces graphiques par dfaut pour les objets modliss ; fichiers de formulaires de recherche ; fichiers d'internationalisation.

On peut aussi remarquer que la gnration, de par son caractre systmatique, permet d'amener une certaine homognisation des procdures de codage, homognisation malheureusement absente sur OFBiz. De plus, l'utilisation pralable d'une modlisation UML au codage direct offre la possibilit de fixer clairement le fonctionnement du module et permet aux nouveaux dveloppeurs d'avoir un point de dpart clair et prcis pour mieux comprendre l'implmentation adopte.

3.3

Modification de composants OFBiz

De nombreux composants OFBiz ont t modifis afin de pouvoir utiliser la modlisation objet de Nogia. Le principal but de ces modifications est de traduire les entits d'OFBiz en objet rendant la programmation beaucoup plus aise : appel des mthodes de l'objet plutt que l'appel direct aux tples de la base de donne. Les principales modifications (autres que la possibilit d'accder directement l'objet traduit de l'entit) apportes ces composants sont :

Common : permet de stocker les numrations et les statuts utiliss dans Nogia dans les entits correspondantes dOfbiz. Product : redirection d'une partie de la gestion des stocks sur le composant Nogia Facility

3.4

Ajout de composants

De nombreux composants ont t rajouts afin d'offrir un plus grand choix de fonctionnalits aux clients. Ces composants remplacent les composants OFBiz lorsqu'ils sont jugs trop insatisfaisants ou abordent des concepts absents dans OFBiz. Composants ajouts :

Manufacturing : remplace compltement le composant de mme nom sous Ofbiz. Il remplit les mmes fonctions mais a t entirement repens partir dune modlisation UML. Facility : remplace le module de gestion des stocks dans Product dOfbiz. Le modle de donnes a t entirement revu et il apporte en plus la gestion des inventaires physiques. Accounting : remplace le composant Accounting dOfbiz et supporte la comptabilit analytique.
Graud BUXEROLLES Anne 2005

Rapport de Stage EPU-DI 3me anne 24

ServiceMgnt : gre toutes les activits de services ou de suivi de projet. Il ny a pas dquivalent dans Ofbiz.

3.5

Processus de programmation

Le systme de contrle de versions utilis sous Nogia est CVS. Le processus de dveloppement avec OFBiz-Nogia est simple et convivial. Plusieurs branches sont utilises, dont principalement la branche HEAD et la branche STABLE. Les programmeurs travaillent avec la branche HEAD et valident directement leurs travaux sur cette dernire. Lorsque les fonctionnalits sont suffisamment mres et solides, elles sont incorpores dans la branche STABLE. C'est cette branche STABLE qui est propose aux clients. Lorsque les programmeurs d'OFBiz-Nogia travaillent sur des composants propres OFBiz, ce qui est relativement peu courant, nous envoyons nos modifications suivant la procdure d'OFBiz. Afin d'optimiser la communication entre les diffrent collaborateurs et ainsi la productivit, nous utilisons un repositoire Web. Les diffrentes tches accomplir y sont dposes et classes par type (bug, patch OFBiz, nouvelle foncionnalit) et module. Une priorit peut tre associe chaque tche. Les status d'iune tche sont les suivants

ToBeTested : la tche a t ralis on fait appel un collaborateur diffrent du ralisateur afin de valider le fonctionnement ToStable : la tche a t valid et est prte passer dans la branche STABLE ToJIRA : le dveloppement ralis doit tre envoy sous forme de patch OFBiz

Rapport de Stage EPU-DI 3me anne 25

Graud BUXEROLLES Anne 2005

Mes ralisations

Rapport de Stage EPU-DI 3me anne 26

Graud BUXEROLLES Anne 2005

Procdure de ralisation d'un ordre d'achat

Afin de rendre plus comprhensible et mieux situer les explications sur mes dveloppements, je commencerai par vous prsenter l'enchanement d'cran actuel ( la fin de mon stage) du processus ralisation d'un ordre d'achat, de sa cration sa rception. Les parties crations et modifications d'un ordre d'achat font partie du module Order et sont donc dveloppes par l'quipe d'OFBiz. En revanche, la rception est spcifique Nogia et se trouve dans le module Facility ; ce dernier a t dvelopp par Messieurs Gaudin et Malet (quipe Nride).

1.1
tape 1 :

Cration d'un ordre d'achat

Dans le cadre d'un ordre d'achat, l'utilisateur peut slectionner :


le centre de profit : il dfinit toutes les rgles commerciales (taxes, livraisons, paiements, promotions... l'acteur factur : l'entreprise de l'utilisateur, un service particulier, une filiale, ... le fournisseur : personne qui on achte les produits, les prix du produits sont associs au fournisseur

Image 5 tape 1 de la cration d'un ordre d'achat

Rapport de Stage EPU-DI 3me anne 27

Graud BUXEROLLES Anne 2005

tape 2 :

Slection des conditions de paiement particulires, promotions etc. ; Choix de la devise ;

Image 6 tape 2 de la cration d'un ordre d'achat

tape 3 :

Dans cet cran sont ajouts les produits ; pour l'ajout d'un article on peut spcifier :

la rfrence de l'article ; la quantit dlivre ; l'unit de mesure de cette quantit comme par exemple : le conditionnement par bote de 10 units ; la date de livraison souhaite pour cet article ; un ventuel commentaire.

Sont ensuite affichs les produits dj ajouts et les ventuelles promotions, une fois un produit ajout son cot et sa quantit ne sont plus modifiables.

Rapport de Stage EPU-DI 3me anne 28

Graud BUXEROLLES Anne 2005

Image 7 ajout des lignes d'une commande (tape 3)

La rfrence de l'article peut tre renseigne soit directement, soit grce un lookup (la petite icne droite du champ de saisie). Le lookup est un procd couramment utilis ; il permet d'afficher les champs d'une table ou d'une vue, des oprations de recherche peuvent tre effectues selon diffrents critres. L'exemple montr dans la copie d'cran suivante illustre le lookup apparaissant pour le choix d'un article :

Rapport de Stage EPU-DI 3me anne 29

Graud BUXEROLLES Anne 2005

Image 8 lookup sur les produits

tape 4 :

Permet de spcifier des rgles de paiement particulires (article non interchangeable, exclusivit)...

Image 9 conditions de rglements (tape 4)

tape 5 :

Permet de spcifier l'adresse o les articles doivent tre expdis soit :


l'adresse du magasin de stockage (par dfaut sont prsentes les adresses du magasin par dfaut du centre de profit) ; l'adresse d'un acteur.

Rapport de Stage EPU-DI 3me anne 30

Graud BUXEROLLES Anne 2005

Image 10 adresse d'expdition (tape 5)

tape 6 :

Dispositions particulires sur l'expdition :


moyens d'envoi (poste, colis express, ...) ; attendre ou non que tous les produits commands soient prts pour envoyer la commande ; message spcial, par exemple dans le cadre d'un cadeau ; dates de livraisons.

Image 11 dispositions particulire de l'expdition (tape 6)

Rapport de Stage EPU-DI 3me anne 31

Graud BUXEROLLES Anne 2005

tape 7 :

Permet d'ajouter des informations supplmentaires sur d'ventuels acteurs associer la commande, on choisi un acteur puis son rle parmi la liste des rles que l'acteur peut effectuer.

Image 12 ajout de rles (tape 7)

tape 8 :

Vrification de de la commande, rcapitulation des achats et calcul du prix avec les taxes, promotions, frais de port, ...

Image 13

vrification commande (tape 8)

Rapport de Stage EPU-DI 3me anne 32

Graud BUXEROLLES Anne 2005

tape 9 :

Cration de la commande : La commande est maintenant cre, divers liens permettent de naviguer sur les informations associes la commande (fournisseur, acteurs, centre de profit, rception, ...), on peut aussi la traduire en format PDF pour pouvoir l'imprimer. A ce stade, il est possible de modifier les lignes de la commande.

Image 14 visualisation commande (tape 9)

De manire plus fonctionnelle, la cration d'un ordre de vente consiste en la cration d'un objet Java : le ShoppingCart. Chaque ligne de commande est stocke dans un ShoppingCartItem. L'objet ShoppingCart, assimilable un caddie, conserve toutes les informations relatives l'ordre d'achat et ce jusqu' la cration effective de ce dernier (tape 8). Cette tape de cration consiste stocker dans les entits du module Order toutes les informations contenues dans le ShoppingCart. Le principal problme de la mthode, consistant utiliser un ShoppingCart plutt que directement les entits d'Order, est la duplication de code. Par exemple tous les getters et setters sont dupliqus,
Rapport de Stage EPU-DI 3me anne 33 Graud BUXEROLLES Anne 2005

ainsi que des mthodes plus compliques comme le calcul du prix ce qui ne facilite pas la maintenance du code.

Rapport de Stage EPU-DI 3me anne 34

Graud BUXEROLLES Anne 2005

3.6

Modification d'un ordre d'achat

Aprs avoir cliqu sur le bouton d'dition des lignes plusieurs oprations sont possibles :

modification des lignes : modification de la quantit et du prix unitaire, ou annulation de la ligne ; ajout de lignes : processus identique celui de l'tape 3 de la cration d'un ordre d'achat, la seule diffrence tant la possibilit de modifier le prix.

Image 15 modification commande

Fonctionnellement, le principe est le mme que lors de la cration. Lorsque l'utilisateur clique sur le bouton de mise jour des lignes ou d'ajout d'une ligne, les donnes contenues dans les entits du module Order sont charges dans le ShoppingCart, subissent les modifications apportes par l'utilisateur et, enfin, nouveau stockes dans les entits d'Order.

Rapport de Stage EPU-DI 3me anne 35

Graud BUXEROLLES Anne 2005

3.7
tape 1 :

Rception d'un ordre d'achat

Cration d'une rception :


type de rceptions (rception de retour de vente, de fabrication de commande d'achat...) ; la commande principale associe la rception (une rception est souvent associe une seule commande mais il sera possible si on le souhaite dans les crans suivants d'associer d'autres commandes la rception cre ; l'inverse, une commande peut faire l'objet de plusieurs rceptions) ; le bon de livraison reu la rception des produits ; d'ventuels commentaires.

Image 16 cration rception (tape 1)

tape 2 :

Rception de stock, l'utilisateur choisit ici les commandes correspondant aux produits rceptionns, il peut ensuite choisir d'afficher un seul produit ou tous les produits de la commande.

Image 17 slection produit(s) rceptionner (tape 2)

Rapport de Stage EPU-DI 3me anne 36

Graud BUXEROLLES Anne 2005

tape 3 :

L'utilisateur indique :

l'emplacement de stockage, qui peut tre un entrept et plus prcisment une pice d'un entrept ; les quantits acceptes ; les quantits refuses avec la raison du refus ; si l'article est stock en srie ou non.

Image 18 dition ligne(s) de rception (tape 3)

tape 4 :

Sont rcapituls ici, les diffrents produits reus. Pour chaque produit, les quantits reues sont indiques (lors de cette rception mais aussi lors d'autres rceptions de ce produit avec la mme commande) ainsi que les quantits restantes.

Rapport de Stage EPU-DI 3me anne 37

Graud BUXEROLLES Anne 2005

Image 19 visualisation ligne(s) de rception (tape 4)

La rception utilise l'objet Shipment et les objets en relation directe avec ce dernier : ShipmentItem. Le fait de rceptionner des produits s'apparente des mouvements de stocks. On distingue les mouvements de stocks raliss : StockEvent des mouvements de stocks planifis : StockEventPlanned.

Diagramme UML simplifi d'Order

Afin de prciser mes explications ultrieures, je vais dtailler ici les principales entits du module Order que sont OrderItem et OrderHeader.

Rapport de Stage EPU-DI 3me anne 38

Graud BUXEROLLES Anne 2005

Image 20 diagramme simplifi de Order

OrderHeader correspond aux informations de l'en-tte de la commande : date de la commande, type de commande (achat, vente, ...), date de la commande, fournisseur, centre de profit, devise, canaux de vente (tlphone, mail, ...), acteur, mthode de paiement, statut de la commande (cre, approuve, annule, ...) ... OrderItem correspond aux informations de chaque ligne de la commande : quantit, prix unitaire, prix moyen, commentaire, produit, expdition, mouvement de stock...

Rapport de Stage EPU-DI 3me anne 39

Graud BUXEROLLES Anne 2005

Diagramme UML des relations entre Facility et Order

Image 21 diagramme UML des relations entre facility et order

La relation entre une rception (Shipment) et une commande (Order) ne se fait pas au niveau des enttes mais bien des lignes (respectivement ShipmentItem et OrderItem). On peut trouver dans une rception des lignes de plusieurs commandes diffrentes et de mme une commande peut tre rceptionne par plusieurs rceptions.

Rapport de Stage EPU-DI 3me anne 40

Graud BUXEROLLES Anne 2005

6
6.1

Ralisations sur le module Order


Gestion des units de quantit sur le module Order

Problmatique :

Lors de la saisie d'un ordre, il n'y a actuellement aucun moyen de stipuler une unit de quantit (bote de 10, litre, mtre). Or, le besoin de cette unit de quantit est rapidement devenu vident. Par exemple, si vous voulez avoir une bote de 100 clous (notion diffrente pour le stock de 100 clous l'unit) ou une bote de 10 clous, le seul moyen actuellement est de crer 2 produits diffrents.

Objectif fonctionnel :

permettre de pouvoir stipuler une unit de quantit lors de la saisie d'une ligne de commande.

Objectifs non fonctionnels :


tre le moins invasif possible dans le code actuel ; envoyer les dveloppements apports l'quipe d'OFBiz et s'efforcer de les faire adopter.

Aprs rflexion, le principe de fonctionnement adopt est le suivant :

Lors de la saisie d'une ligne de commande, l'utilisateur se voit proposer comme unit de quantit toutes les units de quantit du mme type que l'unit de quantit par dfaut du produit. La quantit saisie est directement convertie dans l'unit par dfaut du produit afin de ne pas modifier le comportement de tous les traitements utilisant la quantit.
Dmarche adopte :

analyse et modification des entits de gestion des unit de mesure (ou uom Unity Of Measure) et des services de conversions d'units propos par OFBiz ; analyse des entits d'Order pour savoir comment stocker l'information sur l'unit de quantit ; modification des mcanismes du ShoppingCart pour y incorporer cette information ; modification de l'interface graphique.

Analyse et modification des entits de gestion des uom et des services de conversions d'units proposs par OFBiz Modle UML simplifi dcrivant les entits charges de la gestion des units de mesure :

Rapport de Stage EPU-DI 3me anne 41

Graud BUXEROLLES Anne 2005

Image 22 diagramme UML des Uom

Le modle propos par OFBiz est parfaitement suffisant car il permet de prendre en compte une notion de type entre les units de quantit. De plus, la conversion entre les uom est rendue possible grce aux entits UomConversion et UomConversionDated (incluant la notion de dates trs utile pour la monnaie, par exemple).

Le service de conversion propos par OFBiz est par contre beaucoup moins sduisant. Entre : la valeur convertir, l'unit de mesure de la valeur convertir (uomFrom), l'unit de mesure dans laquelle doit tre convertie la valeur (uomTo). Sortie : la valeur en sortie.

Rapport de Stage EPU-DI 3me anne 42

Graud BUXEROLLES Anne 2005

Deux inconvnients majeurs sont relever :

Il ne propose pas, en entre, la notion de date. Ainsi, le facteur de conversion choisi pour une conversion date est toujours la conversion la plus rcente de l'entit UomConversionDated. Ce service est donc inutilisable pour des conversions de monnaies qui ncessitent le facteur de conversion la date de la transaction. Il ne trouve de conversions entre les 2 units en entre, qu' la condition qu'elles soient directement prsentes dans les tables. Exemple : si dans la table UomConversion nous avons l'enregistrement suivant : uomTo=minute, uomFrom=heure, conversionFactor=60 et l'entre du service uomTo=heure et uomFrom=minute, le service est alors incapable de trouver une conversion. S'il y a n Uom d'un mme type, il faut donc 2n2 enregistrements dans la table de conversion pour avoir une conversion entre chaque Uom.

Le service propos est de plus crit en minilanguage, langage XML de programmation qui, s'il reste simple lire, n'est pas ais utiliser pour un dbutant. J'ai donc cr un nouveau service de conversion en Java dont voici la dfinition :
<service name="conversion" default-entity-name="UomConversion" engine="java" location="org.ofbiz.common.uom.ConversionServices" invoke="conversion" auth="false"> <description>Make a unit of measure conversion,if a date is present in UomConversionDated else in UomConversion</description> <auto-attributes include="pk" mode="IN" optional="false"/> <attribute name="date" mode="IN" type="Timestamp" optional="true"/> <attribute name="originalValue" mode="IN" type="Double" optional="false"/> <attribute name="convertedValue" mode="OUT" type="Double" optional="true"/> </service>

La date est maintenant bien prise en compte. La conversion entre les units en entres est prise en compte jusqu' une indirection et quelque soit le sens. Par exemple : si sont prsents dans l'entit UomConversion les enregistrements uom A vers uom X et uom X vers uom B , alors le service est capable de convertir une valeur de l'uom A vers l'uom B . On peut ainsi imaginer de crer des conversions vers une unit talon (exemple : le Kg pour le poids) ce qui rduit considrablement le nombre d'enregistrements de conversions ncessaires.

Analyse des entits de order pour savoir comment stocker l'information sur l'unit de quantit Comme vu sur le diagramme UML d'Order, les informations sur les lignes de commandes sont stockes dans l'entit OrderItem. Une relation a donc tait rajoute entre l'entit Uom et OrderItem :
<entity entity-name="OrderItem" package-name="org.ofbiz.order.order" never-cache="true" title="Order Item Entity"> <field name="orderId" type="id-ne"></field> <field name="orderItemSeqId" type="id-ne"></field> ... <key-map field-name="productId"/> </relation> Rapport de Stage EPU-DI 3me anne 43 Graud BUXEROLLES Anne 2005

<relation type="one" fk-name="ORDER_ITEM_RFUOM" title="RecurringFreq" relentity-name="Uom"> <key-map field-name="recurringFreqUomId" rel-field-name="uomId"/> + </relation> + <relation type="one" fk-name="ORDER_QUANTITYUOM" rel-entity-name="Uom"> + <key-map field-name="quantityUomId" rel-field-name="uomId"/> + </relation> <relation type="one" fk-name="ORDER_ITEM_STTS" rel-entity-name="StatusItem"> <key-map field-name="statusId"/> </relation> ... </entity>

Modification des mcanismes du ShoppingCart pour y incorporer la gestion de l'unit de quantit Modifications apportes ShoppingCartItem, entit contenant les informations d'une ligne d'une commande :

ajout de l'attribut itemQuantityUomId, la rfrence de l'unit de quantit ; ajout de la fonction getUomQuantity() qui retourne la quantit correspondant l'unit de quantit de l'orderItem, quantit obtenue en convertissant la quantit du ShoppingCart (qui correspond l'unit de quantit par dfaut du produit de l'orderItem) ; ajout des getters et setters sur le nouvel attribut et sur la description de l'uom.

Modification du service permettant de charger un ShoppingCart partir des entits d'Order (mthode statique loadCartFromOrder de ShoppingCartServices) pour prendre en compte le nouvel attribut. Modification de l'vnement permettant de crer un nouveau ShoppingCartItem (mthode statique addToCart de ShoppingCartEvents) pour prendre en compte le nouvel attribut. Ajout de la mthode statique getUomQuantity(...)(code identique la mthode getUomQuantity() de ShoppingCartItem) dans OrderReadHelper afin de pouvoir afficher correctement la quantit lors d'une lecture direct des OrderItem sans passer par le ShoppingCart. Modification de trois services dans OrderServices : modification, ajout, et annulation d'une ligne de commande, afin de pouvoir prendre en compte la gestion de l'unit de quantit chaque fois. Modification de l'interface graphique L'unit de quantit du ShoppingCartItem apparat dans quatre crans provenant tous d'un fichier freemarker diffrent ou l'unit de mesure a t rajoute :

image 6 (ajout des lignes d'une commande) modification de showcart.ftl

Rapport de Stage EPU-DI 3me anne 44

Graud BUXEROLLES Anne 2005

image 16 (visualisation commande) modification de orderitems.ftl image 17 (modification commande)modification de editorderitems.ftl et appendItems.ftl

Modification du fichier gnrant le PDF imprimable de la commande : orderView.fo.ftl Sur l'image 6 un lookup a t ajout afin d'afficher toutes les units de quantit du mme type que l'unit de quantit par dfaut du produit. Pour ce faire quatre fichiers ont t modifis : modification de showcart.ftl, pour ajouter le lookup:
<script language="JavaScript" type="text/javascript"> function findProductUom( productId){ if( productId.length > 0) target="/ordermgr/control/LookupProductUom?productId="+productId+"&"; return target; } </script> ... <td colspan="1"><input type="text" class="inputBox" size="25" name="itemQuantityUomId" value="${requestParameters.itemQuantityUomId?if_exists} "/> <span class='tabletext' name="LookupProduct"> <a href="javascript:call_fieldlookup2(document.quickaddform.itemQuantityUomId, findProductUom(document.quickaddform.add_product_id.value));"> <img src="/images/fieldlookup.gif" width="15" height="14" border="0" alt="Click here For Field Lookup"/> </a> /span> ...

Le principe de fonctionnement est le suivant : on appelle la fonction javascript call_fieldlookup2 qui prend en premier paramtre le champ de retour et en deuxime l'URI. du lookup. Comme, il est ncessaire de connatre l'identifiant du produit afin d'afficher le bon Uom ce dernier est concatn l'URI du lookup dans la fonction findProductUom(), il pourra ainsi tre rcupr et utilis par la suite. ajout de l'URI du lookup dans le controller.xml du composant order :
<request-map uri="LookupProductUom"> <security https="true" auth="true"/> <response name="success" type="view" value="LookupProductUom"/> </request-map> ... <view-map name="LookupProductUom" type="screen" page="component://product/widget/catalog/LookupScreens.xml#LookupProductUom"/>

ajout du widget LookupProductUom

dans //product/widget/catalog/LookupScreens.xml :

<screen name="LookupProductUom"> Rapport de Stage EPU-DI 3me anne 45 Graud BUXEROLLES Anne 2005

<section> <condition> <or> <if-has-permission permission="CATALOG" action="_VIEW"/> </or> </condition> <actions> <set field="title" value="Lookup Product"/> <set field="entityName" value="Uom"/> <set field="queryString" from-field="result.queryString"/> <set field="viewIndex" from-field="parameters.VIEW_INDEX" type="Integer"/> <set field="viewSize" from-field="parameters.VIEW_SIZE" type="Integer" default-value="20"/> <set field="productId" from-field="parameters.productId" /> <entity-one entity-name="Product" value-name="product"/> <set field="uomId" from-field="product.quantityUomId" /> <entity-one entity-name="Uom" value-name="uom"/> <set field="requestParameters.uomTypeId" from-field="uom.uomTypeId" defaultvalue="99"/> </actions> <widgets> <decorator-screen name="LookupDecorator" location="component://common/widget/CommonScreens.xml"> <decorator-section name="body"> <include-form name="lookupProductUom" location="component://product/ webapp/catalog/lookup/FieldLookupForms.xml"/> <include-form name="listLookupProductUom" location="component://product/ webapp/catalog/lookup/FieldLookupForms.xml" /> </decorator-section> </decorator-screen> </widgets> </section> </screen>

Les champs suivants suffisent eux seuls pour n'afficher que les Uom du mme type que le produit : Rcupration de l'identifant du produit pass en paramtre au lookup :
<set field="productId" from-field="parameters.productId" />

Rcupration de l'identifiant de l'unit de mesure de quantit par dfaut du produit grce une interrogation de la base de donne :
<entity-one entity-name="Product" value-name="product"/> <set field="uomId" from-field="product.quantityUomId" />

Filtre les Uom en imposant que le type soit le mme que le type de l'Uom du produit :

<entity-one entity-name="Uom" value-name="uom"/> <set field="requestParameters.uomTypeId" from-field="uom.uomTypeId" defaultvalue="99"/>

ajout des forms lookupProductUom

et listLookupProductUom

dans //product/webapp/catalog/lookup/FieldLookupForms.xml" : Sont dfinis ici tous les champs afficher dans le lookup :
<form name="lookupProductUom" default-title-style="tableheadtext" default-tooltip-style="tabletext" default-widget-style="inputBox" target="LookupProductUom" title="" type="single"> <actions> <property-map resource="CommonUiLabels" map-name="uiLabelMap"/> </actions> <auto-fields-entity entity-name="Uom" default-field-type="hidden" /> Rapport de Stage EPU-DI 3me anne 46 Graud BUXEROLLES Anne 2005

<field name="productId"><hidden value="${productId}"/></field> <field name="hideSearch"><hidden value="Y"/></field> <field name="uomId" title="${uiLabelMap.CommonUomUomId}"><text-find defaultvalue="equals"/></field> <field name="abbreviation" title="${uiLabelMap.CommonUomAbbreviation}"><textfind default-value="equals"/></field> <field name="description" title="${uiLabelMap.CommonUomDescription}"><textfind default-value="equals"/></field> <field name="submitButton" title="${uiLabelMap.CommonLookup}" widgetstyle="standardSubmit"> <submit button-type="button"/> </field> </form> <form name="listLookupProductUom" default-title-style="tableheadtext" defaulttooltip-style="tabletext" default-widget-style="tabletext" list-iterator-name="listIt" paginate-target="LookupProductUom" title="" type="list"> <actions> <service service-name="performFind" result-map-name="result" result-map-list-iterator-name="listIt"> <field-map field-name="inputFields" env-name="requestParameters"/> <field-map field-name="entityName" env-name="entityName"/> </service> </actions> <field name="hideSearch"><hidden value="Y"/></field> <field name="uomId" title="&amp;nbsp;" widget-style="buttontext"> <hyperlink also-hidden="false" target-type="plain" description ="${uomId}" target="javascript:set_values('${uomId}', '${uomId}')"/> </field> <field name="abbreviation"><display/></field> <field name="description"><display/></field> <field name="uomTypeId"><display/></field> </form>

Lookup gnr :

Image 23 Lookup sur les Uom disponibles pour produits

Rapport de Stage EPU-DI 3me anne 47

Graud BUXEROLLES Anne 2005

Bilan L'objectif fonctionnel est ralis et la gestion des units de quantit fonctionne. En revanche, les modifications n'ont pas t valides par l'quipe d'OFBiz. Cette tche a t ma premire ralisation au sein de l'quipe de Nride et m'a pris relativement beaucoup de temps. En effet, un nombre extrmement important de petites modifications est ncessaire et ce, sur des fichiers totalement inconnus avec de multiples langages. De plus, le composant d'OFBiz ne bnficie pas de la traduction des entits en objet, chose ce qui ne simplifie pas la programmation.

6.2

Gestion des prix lors de modifications d'une commande

Problmatique : la gestion des prix sur l'cran d'Order est essentielle pour l'ERP, or de multiples problmes ont t relevs. Objectifs fonctionnels : Il convient de rsoudre les problmes suivants :

aprs modification d'une commande d'achat tous les prix sont remis zro ; les prix unitaires pralablement modifis sont perdus aprs une mise jour de la commande ; les rles des acteurs d'une commande d'achat (dbiteur, crditeur) sont mal dfinis ; la saisie des prix n'est pas localise lors de la modification d'une commande.

Objectifs non fonctionnels :


tre le moins invasif possible dans le code actuel ; envoyer les dveloppements apports l'quipe d'OFBiz et s'efforcer de les faire adopter.

6.2.1 Mmorisation d'un changement de prix


Lors de la modification d'une commande, les prix ne sont pas chargs dans le ShoppingCartItem avec le reste des informations concernant une ligne de commande (quantit, produit, ...). En effet, les prix dpendent de la quantit de produit et sont donc recalculs chaque mise jour. Un nouveau champ a donc t rajout dans ShoppingCartItem et OrderItem afin de prciser si le prix a dj t modifi et, dans ce cas particulier, le prix est charg directement du stockItem et n'est pas recalcul.

Rapport de Stage EPU-DI 3me anne 48

Graud BUXEROLLES Anne 2005

6.2.2 Recalcul du prix des commandes d'achats


La mthode permettant de calculer les prix dans le ShoppingCart ne permettait pas de calculer les prix des commandes d'achat, seulement les prix des commandes de ventes. En effet, le prix de la commande de vente dpend directement du produit, alors que celui d'une commande d'achat dpend du fournisseur. Cette mthode a donc t modifie pour qu'elle puisse calculer la fois les prix des commandes d'achat et de vente.

6.3

Dfinition des rles d'une commande d'achat

A chaque commande (OrderHeader) sont associs des acteurs correspondant a des rles : l'acteur crditeur et l'acteur dbiteur. Le ShoppingCart lui ne stocke qu'un seul acteur, ce dernier tant la personne concluant la commande avec l'utilisateur. Dans le cas d'une commande de vente, il s'agit du dbiteur et dans le cas d'une commande d'achat du crditeur. Or, lors du chargement d'un OrderItem dans le ShoppingCart, l'acteur du ShoppingCart prenait automatiquement la valeur du dbiteur quel que soit le type de la commande. Un contrle du type de la commande lors du chargement a donc t rajout afin de corriger ce bug.

6.4

localisation de la saisie des prix

OFBizNogia est un ERP internationalis, cela se traduit par exemple avec la gestion des nombres dcimaux. En France, on utilise la virgule alors que dans d'autre pays, comme aux Etats-Unis par exemple, le point est utilis. Afin de pouvoir assurer cette fonctionnalit la chane de caractres saisie est convertie en prix selon une locale (le pays). L'objet Java utilis permettant de convertir une chane de caractres en chiffre selon une locale est le NumberFormat :
NumberFormat nf; if (locale!=null) nf=NumberFormat.getNumberInstance(locale); else nf=NumberFormat.getNumberInstance(); try { price=nf.parse(priceStr).doubleValue(); } catch (ParseException e) { Debug.logError(e, module); eturn ServiceUtil.returnError(e.getMessage()); }

Rapport de Stage EPU-DI 3me anne 49

Graud BUXEROLLES Anne 2005

Bilan

Ses modifications sur les prix fonctionnenet actuellement malgr quelques dboire aux dbut (divers effets de bords). Toutes les modifications apportes ont t prises en compte par l'quipe d'OFBiz.

6.5

Diverses amliorations du composant Order

Diverses amliorations du processus de saisie d'un ordre d'achat ont t effectu :


l'utilisateur peut maintenant choisir un centre de profit (image 5). Par le pass, un centre de profit par dfaut tait automatiquement li un ordre d'achat ; l'utilisateur peut maintenant choisir un magasin de stockage (image 10). Autrefois le magasin de stockage correspondait au magasin par dfaut du centre de profit.

Un hook a t rajout sur l'identifiant d'une commande. Le principe d'un hook est de dvier un traitement dans un fichier particulier, fichier qui est facilement modifiable par le client. Il peut donc customiser comme il le souhaite le traitement spcifique, sans risque d'effet de bord. Si le client ne customise par le traitement alors le traitement par dfaut d'OFBiz-Nogia est appliqu.

Rapport de Stage EPU-DI 3me anne 50

Graud BUXEROLLES Anne 2005

7
7.1

Ralisations sur le module Facility


Amliorere la gestion de la rejection

Problmatique :

Comme vu sur l'cran de rception d'une commande d'achat (image 18), on peut refuser une partie de la commande et ceci pour divers raisons : produit non-command, endommags... Ce refus d'une certaine quantit de produit entrane la cration d'un mouvement de stock (StockEvent). Or, comme vous pouvez le voir sur le schma UML de Facility to Event (image 21), aucun champ n'est prvu pour stocker la raison du refus et il est actuellement stock dans le commentaire ce qui, d'un point de vue fonctionnel, n'est pas idal.

Objectif fonctionnel :

Intgrer la raison du refus dans les entits de Facility et modifier les traitements afin de prendre en compte cette modification

Dmarche adopte :

modification des entits de Facility

Aprs analyse des diffrentes tables proposes par OFBiz, il apparat qu'une entit rejectionReason existait dj. Il m'a donc suffit de crer une relation entre le mouvement de stock ralis et l'entit rejectionReason dans le diagramme UML. Aprs gnration de code, le fichier de dfinition des entits a t automatiquement modifi :
<entity entity-name="StockEvent" package-name="org.ofbiz.facility.stockevent"> <!--implement-classname="org.ofbiz.facility.stockevent.developed.StockEvent"> --> <field name="discriminator" type="id"></field> <field name="idName" type="name"></field> ... <field name="sevttypEnumId" type="id-ne"></field> <field name="intritIdName" type="name"></field> + <field name="rejectionId" type="id-ne"></field> <field name="partyId" type="id-ne"></field> <prim-key field="idName"/> <relation type="one" fk-name="STOCKEVENT0" rel-entity-name="Product"> <key-map field-name="prdtProductId" rel-field-name="productId"/> </relation> .. <relation type="one-nofk" rel-entity-name="IntegTransactionItem"> <key-map field-name="intritIdName" rel-field-name="idName"/> </relation> + <relation type="one-nofk" rel-entity-name="RejectionReason"> + <key-map field-name="rejectionId"/> + </relation> <relation type="one" fk-name="STOCKEVENT3" rel-entity-name="Party"> <key-map field-name="partyId"/> </relation> </entity>

Rapport de Stage EPU-DI 3me anne 51

Graud BUXEROLLES Anne 2005

Grce la gnration de code, la classe StockEvent a t modifie afin de pouvoir grer ce nouvel attribut. Comme tous les mcanismes internes de gestion de ce nouvel attribut sont gnrs automatiquement, on peut remercier la gnration automatique et passer la phase suivante. Il s'agit maintenant de modifier les interfaces graphiques de saisie des rceptions afin de saisir et d'afficher le motif du refus partir de ce nouveau champ et non du commentaire. ListReceiptByOrder.bsh qui a pour rle de placer dans le contexte toutes les informations concernant les mouvements de stocks. L'information sur le motif de refus a donc t rajoute :

L'interface graphique d'affichage de rceptions utilise deux fichiers :

mapShipmentItem.put("partyId",orderStockEvent.getParty().getPartyId()); + if(orderStockEvent.getRejectionReason()!=null) + mapShipmentItem.put("rejectionReason",orderStockEvent.getRejectionReason + ().getDescription()); mapShipmentItem.put("receiveDate",orderStockEvent.getDates());

le fichier POInventory.ftl rcupre alors la donne pour gnrer la page html :

<div class="tabletext"><font color="red">$ {shipmentItem.rejectionReason?if_exists}</font></div>

7.2

Lier un acteur un vnement de stock

Bien que la relation entre un acteur et un mouvement de stock ralis soit prsente dans la base de donnes aucune interface graphique ne permet d'effectuer cette association et les mcanismes internes ne sont pas non plus implments. Objectif fonctionnel : Pouvoir lier un acteur un mouvement de stock La dmarche utilise est trs similaire au chapitre prcdent et je ne la dtaillerai donc pas ici.

Rapport de Stage EPU-DI 3me anne 52

Graud BUXEROLLES Anne 2005

Conclusion
Ce stage m'a t extrmement enrichissant la fois sur le plan personnel et technique. Les diffrentes tches auxquelles je me suis atteles ont t pour la plupart menes leurs termes. Si le FrameWork d'OFBiz est extrmement puissant il ne rend pas pour autant la programmation facile. Ainsi, un nombre extrment important de fichiers et de mcanismes sont apprhender. Ceci implique donc un temps d'apprentissage important sur la technique de programmation. De plus, comme dans tout ERP chaque processus est complexe (car le plus gnrique possible) et est fortement connect avec les autres processus et la moindre modification entrane de nombreux effets de bords. Une comprhension globale des processus est alors ncessaire, comprhension longue acqurir pour le nophyte. Ce projet m'a permis de dcouvrir de nombreuses technologies (BeanShell, FreeMarker, J2EE, MVC, ant, gnrateur, moteur de rendu, framework...) ainsi que les principes de fonctionnement des ERP. Enfin, se stage m'a permis de me familiariser avec le monde des logiciels libres. N'tant pas l'origine un mordu inconditionnel des logiciels libres, je dois dire que j'ai t sduit par leurs surprenantes maturit et l'nergie des communauts qui les dveloppent.

Rapport de Stage EPU-DI 3me anne 53

Graud BUXEROLLES Anne 2005