Rapport de Stage : Développement sur l'erp libre OFBiz-Néogia

Polytech Tours Département Informatique 64, avenue Jean Portalis 37200 - Tours : Développement sur l'erp libre OFBiz-Néogia Responsable de Stage : Étudiant : Olivier HEINTZ Néréide 3 bis, les Isles - 37270 Véretz

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 dispensés, ainsi que Madame Sophie Benaroch pour sa parfaite connaissance de l'anglais. Je n'oublie pas mes collègues stagiaires, Monsieur Majid El Idrissi et Monsieur Peter Goron ; le premier pour son esprit «droit» mais néanmoins enjoué, le second pour son aide claire et précise ainsi que son inexpugnable sérieux. Je souhaite enfin remercier tous les collaborateurs de Néréide pour l'ambiance agréable et conviviale qu'ils ont su faire régner dans leur société, ainsi que tous les membres de la famille Heintz de nous accueillir chez eux à l'heure du déjeuner et spécialement Madame Catherine Heintz pour ses desserts inégalés. 2

Sommaire Table des matières Remerciements... 2 Sommaire...3 Introduction... 4 Présentation de l'entreprise... 5 1.Néréide...6 2.Le réseau Libre-entreprise...7 3.Les sociétés partenaires de Néréide... 8 Présentation de l'erp OFBiz-Néogia... 9 1 Généralités sur les ERP...10 2 Présentation d'ofbiz... 12 3 OFBiz-Néogia... 22 Mes réalisations... 26 1 Procédure de réalisation d'un ordre d'achat...27 4 Diagramme UML simplifié d'order...38 5 Diagramme UML des relations entre Facility et Order...40 6 Réalisations sur le module Order...41 7 Réalisations sur le module Facility... 51 Conclusion... 53 3

Introduction Mon stage de 3ème année de l Ecole Polytechnique Universitaire de Tours, s'est déroulé au sein de la société Néréide, SSLL (Solutions et Services en Logiciels Libres), spécialisée dans le domaine de l'intégration 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. Près d'une grande entreprise sur deux, déclare avoir déjà déployé des solutions logicielles non propriétaires. L'un des principaux ressorts du "Libre" c'est la réduction des coûts tout en circonscrivant les risques. Mais ce n'est pas tout, utiliser des logiciels libres représente aussi la garantie de travailler sur des standards ouverts et donc interopérablese et de bébféficier. En outre, le logiciel libre mobilise souvent des communautés, qui le font évoluer au gré des nouveaux besoins, et qui peuvent répondre rapidement à des demandes précises. Mon travail au cours de ce stage s'est tout d'abord axé autour de la compréhension du PGI OFBizNéogia : son implémentation, son fonctionnement et l'interconnexion entre les différents modules. Je me suis ensuite attaché à implémenter diverses fonctionnalités sur les modules Order et Facility. Ce rapport se divise en trois parties : la première partie s'attache à présenter la société Néréide ; la seconde tente de présenter les ERP OFBiz et OFBiz-Néogia ; les développements que j'ai effectués sont traités dans la dernière partie de ce document. 4

Présentation de l'entreprise 5

1. Néréide «La collaboration et les bonnes pratiques en action.» Néréide est une jeune SSLL, fondée en 2004 et spécialisée dans l'intégration de l'erp Open Source Ofbiz-Néogia auprès des PME. Il s'agit d'une SARL à capital variable. Son siège social se situe à une dizaine de kilomètres de Tours : Société Néréide 3 bis, Les Isles 37270 VERETZ En complémentarité avec l'intégration d'ofbiz-néogia, cette société propose une gamme complète de services : développement d'applications spécifiques : réaliser ou accompagner le développement de fonctions complémentaires à OFBiz-Néogia et spécifiques au client ; administration de systèmes : mettre en place un élément système, un réseau, intégrer et migrer des composants systèmes, administration de système existant... ; maintenance et support applicatif (TMA : Tierce Maintenance Applicative) : prestations de support et de maintenance corrective et / ou évolutive pour toutes les applications développées à partir de l'architecture OFBiz-Néogia ; gestion du système d'information (infogérance) : gestion globale du système d'information du client, prestation effectuée en trois phases : inventaire détaillé, transition et transformation. De part sa participation au réseau Libre-Entreprise son offre de service peut être étendue à toutes les compétences des membres de ce réseau. L'équipe de Néréide est actuellement composée de 7 personnes. L'équipe technique est constituée de personnes expertes dans la mise en œuvre de PGI Progiciel de Gestion Intégré, (essentiellement Baan, SAP, Oracle) issues de grands cabinets de conseils internationaux. 6

2. Le réseau Libre-entreprise Le réseau Libre-entreprise est un rassemblement d'entreprise toutes fortement impliquées dans le domaine du logiciel libre. Les membres du réseau ont en commun des valeurs et un mode de fonctionnement basé sur : le partage des connaissances ; la capitalisation des expériences clients et des réalisations ; le respect de tous les acteurs d'un projet ; la qualité des prestations. L'appartenance d'une entreprise au réseau fait l'objet d'une évaluation par les autres membres sur le respect de ces valeurs qui forment la base du réseau. Un compte rendu mensuel permet d'avoir une idée de la situation précise de chaque entreprise, il porte sur leurs activités, leurs finances... De nombreux documents sont partagés afin d'aider les membres du réseau dans leur démarches : documents sur la création de l'entreprise ; documents techniques ; modèles de documents ; Un ensemble d outils de travail collaboratif est mis à la disposition des membres du réseau pour simplifier la communication et le partage des connaissances : calendrier ; listes de diffusion partagées ; serveur de messagerie instantanée (Jabber) ; le laboratoire Libre-entreprise : une plate-forme d hébergement de projets informatiques tel que le célèbre SourceForge. Elle offre les mêmes services, à savoir, site web, espace ftp, accès cvs, mailing-lists, etc. ; Planet Libre-Entreprise : c est un aggrégateur de contenu qui permet de suivre l activité des membres du réseau. 7

3. Les sociétés partenaires de Néréide Néréide a développé des rapports étroits de collaboration auprès de différentes sociétés afin de faire bénéficier de leurs compétences le développement d'ofbiz-néogia. Les 7 Arts La SSLL, les 7 Arts s'est spécialisée dans l'environnement libre depuis de nombreuses années, aussi bien à l'attention des PME que des particuliers dans la région de Montpellier. Son créateur, Jacques Le Roux, apporte sa contribution active au développement de l'erp OFBiz-Néogia, notamment sur le module Point de vente. TAU Le développement du module Gestion de Production d'ofbiz a été l'occasion de travailler en partenariat avec la SSII TAU, société située en Italie. Depuis septembre 2003, elle participe concrètement à l'élaboration du module Gestion de Production en partenariat avec l'équipe de Néréide. Son expérience dans la reprise des bases de données AS400 vers OFBiz est un atout majeur. Code Lutin Créée en 2002 par Cédric Pineau et Benjamin Poussin, Code Lutin est une jeune Société de Services nantaise spécialisée dans l'environnement libre. Leurs expertises métiers dans la modélisation objet en UML et la génération de code, les ont naturellement amenés à travailler avec Néréide pour arriver à une parfaite maîtrise des outils de génération de code, à travers l'utilisation de LutinGenerator (outil de génération de code créé par la société Code Lutin) utilisé dans le processus de développement de Néogia. 8

Présentation de l'erp OFBiz-Néogia 9

1 Généralités sur les ERP 1.1 Définition Un PGI progiciel de gestion intégré (en anglais Enterprise Resource Planning ou ERP) est un «logiciel qui permet de gérer l'ensemble des processus d'une entreprise en intégrant l'ensemble des fonctions de cette dernière comme la gestion des ressources humaines, la gestion comptable et financière, l'aide à la décision, mais aussi la vente, la distribution, l'approvisionnement, le commerce électronique»(définition du grand dictionnaire terminologique de l'office québécois de la langue française (OLF)) Le principe fondateur d'un ERP est de construire une application (paie, comptabilité, gestion de stocks ) de manière modulaire tout en partageant une base de données unifiée. Cela crée une différence importante avec la situation pré-existante car les différentes fonctions de l'entreprise étaient gérées par une multitude d'applications dédiées souvent hétérogènes. Ainsi, les Achats, la Comptabilité, la Gestion des Stocks, les Ressources Humaines, la Gestion Commerciale,... sont maintenant totalement interconnectés. Avec l'arrivée de l'erp, les données sont désormais standardisées et partagées entre les différents modules, ce qui élimine les saisies multiples et évite l'ambiguïté des données multiples de même nature (ex : «Clermont-Fd», «Clermont Ferrand», «Clermont-Ferrand»,...). Ceci permet un accroissement considérable de la fiabilité des informations puisque la source des données est unique, d'où une réduction des délais et des coûts de traitements. L'autre principe qui caractérise un ERP est l'usage systématique de ce qu'on appelle un moteur de workflow, et qui permet, lorsqu'une donnée est entrée dans le système d'information, de la propager dans tous les modules du système qui en ont besoin, selon une programmation prédéfinie. Ainsi, on peut parler d'erp lorsqu'on est en présence d'un système d'information composé de plusieurs applications partageant une seule et même base de données, par le biais d'un système automatisé prédéfini éventuellement paramétrable (un moteur de workflow). 1.2 Avantages Comparés à des applications sur mesure, les ERP / PGI présentent plusieurs avantages : optimisation des processus de gestion (flux économiques et financiers) ; cohérence et homogénéité des informations ; intégrité et unicité du système d'information ; partage du même système d information facilitant la communication interne et externe ; globalisation de la formation (même logique, même ergonomie) ; maîtrise des coûts et des délais de mise en œuvre et de déploiement. Il est important de remarquer que la mise en place d'un ERP dans une entreprise est souvent le déclencheur d'une réorganisation et rationalisation de l'ensemble des tâches et processus de l'entreprise. 10

1.3 Inconvénients Les ERP / PGI ne sont cependant pas exempts d'inconvénients : 1.4 coût élevé ; périmètre 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 ; difficultés d'appropriation par le personnel de l'entreprise ; nécessité d'une bonne connaissance des processus de l'entreprise (par exemple, une commande d'achat et une commande de vente nécessitent deux processus différents : il est important de savoir pourquoi, de savoir décrire les points communs et les différences entre ces deux processus de façon à bien les paramétrer) ; nécessité d'adapter parfois certains processus de l'organisation ou de l'entreprise au progiciel ; nécessité d'une maintenance continue. Les ERP libres Le secteur des ERP a depuis quelques années déjà subi un petit bouleversement : l'arrivée de logiciels libres (OFBiz Tiny ERP, ERP5, Compiere,...) sur des terres où règnent en maîtres les logiciels propriétaires : SAP, BAAN, Oracle,... Le premier avantage des ERP Libre sur leurs alter-ego propriétaires est bien sûr l'absence de coût de licence ; coût qui peut souvent apparaître comme prohibitif pour les PME. Un autre atout important est la possibilité d'adapter et de faire évoluer soi-même le progiciel sans dépendre du bon vouloir de la société éditrice. En outre, le logiciel libre mobilise souvent des communautés, qui le font évoluer au gré des nouveaux besoins, et qui peuvent répondre rapidement à des demandes précises. De plus comme tout logiciel libre, les ERP libre donne la garantie de travailler sur des standards ouverts et donc inter-opérables, avantages stratégiques pour beaucoup d'entreprises. En parallèle avec l'augmentation de l'utilisation des ERP en France :48 % des PME françaises sont équipées, et en janvier 2005, 9 % des PME françaises envisageaient d'acquérir et de mettre en place un nouvel ERP dans l'année (Atelier groupe BNP Paribas), l'intérêt porté par les entreprises sur le logiciel libre progresse. Ainsi, 58 % des entreprises envisageraient de passer de leur ERP propriétaire actuel à un ERP libre en 2004 (ERP2004 INFOWORLD). La présence du logiciel libre sur le marché des ERP n'est donc plus marginal et les ERP Open Source prennent leurs places dans ce secteur. 11

2 Présentation d'ofbiz OFBiz (pour «Open For Business») est un projet d'erp Open source initié en mai 2001 par deux américains : Andy Zeneski et David E. Jones. Il est actuellement publié sous licence MIT, licence libre et permissive, c'est-à-dire qu elle ne fixe aucune obligation et / ou interdiction quant à l utilisation, la modification, l extension 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 société 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 intégration d'ofbiz, développements spécifiques, formation des utilisateurs... OFBiz offre déjà un grand choix de fonctionnalités 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, sélection par lots ; comptabilité ; gestion de fabrication ; gestion de projets (événements, tâches, demandes, etc.) ; gestion de contenu. Ce projet compte rassembler à terme tous les modules permettant de gérer les principaux processus d'une entreprise : SCM (Supply Chain Management), ou en français GCL, (Gestion de la Chaîne 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 (Système de Gestion de Contenu) CMMS (Computerized Maintenance Management System), ou GMAO (Gestion de la Maintenance Assistée par Prdinateur ) Le progiciel est entièrement écrit en JAVA sous une architecture J2EE, il respecte de nombreux standards notamment J2EE et XML afin de garantir son évolutivité. Son énorme avantage réside dans sa parfaite compatibilité avec tous les serveurs d'applications J2EE et toutes les bases de données du marché. 12

2.1 Architecture d'ofbiz OFBiz obéit au standard J2EE qui offre un première couche d'abstraction : Image 1 : J2EE et OFBiz 13

Comme tout ERP qui se respecte, OFBiz est décomposé en niveaux, chacun offrant des services particuliers. Image 2 Architecture d'ofbiz 14

De plus, les niveaux applicatifs sont décomposés en module permettant un développement modulaire tout en facilitant la réutilisabilité du code. Les interactions entre modules ainsi fixées, on peut aisément changer l'implémentation d'un module sans bouleverser complètement le système. Image 3 Architecture détaillée d'ofbiz 2.2 Le FrameWork Le framework d'ofbiz est un de ses points forts. S'il a été développé en premier lieu pour OFBiz, il est parfaitement utilisable pour d'autre application. Son fonctionnement repose sur trois composants majeurs que nous allons décrire : l'entityengine, le ServiceEngine, le ControlServlet. Entity Engine L'Entity Engine d'ofbiz offre un ensemble d'outils et de mécanismes permettant la modélisation et la gestion des données. Une entité est un élément de donnée défini par des champs et un ensemble de relations avec les autres entités. La modélisation est basée sur le modèle entité-relation. Son but premier est de gérer automatiquement la persistance des données dans une application transactionnelle. L'Entity Engine permet de s'abstraire de la base de données sous-jacente utilisée. Ainsi les entités sont définies dans des fichiers au format XML (composant/entitydef/entitymodel.xml) qui permettront de faire le lien avec la source de données. Voici un exemple de définition d'une entité : <entity entity-name="ordertype" package-name="org.ofbiz.order.order" title="order Type Entity"> <field name="ordertypeid" type="id-ne" /> 15

<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 définis : les propriétés de l'entité : nom, paquet, titre ; les propriétés des champs : nom, type (qui est automatiquement traduit en type SQL avec un correspondant Java) le nom des clés primaires (qui peuvent être composées) ; 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 spécifique a une entité, les objets générés sont génériques et on accède aux champs par une Map, la clef étant le nom du champ. Les classes du package org.ofbiz.entity définissent l'api pour interagir avec l'entity Engine. Les classes utiles pour l'utilisateur sont : GenericValue : l'objet générique représentant l'entité ; GenericDelegator qui permet de manipuler les GenericValue, c'est-à-dire les créer, les trouver, les stocker. Service Engine Alors que l'entity Engine s'attache à gérer les données, 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> 16

Sont ainsi définis : le nom du service ; le langage utilisé ; la localisation ; le nom de la fonction à appeler les entrées et les sorties, leurs caractères obligatoires, si un préfixe est stipulé, toutes les données ayant ce préfixe sont automatiquement stockées dans une Map. La définition d'une méthode Java appelée en tant que service est la suivante : public static Map updateapprovedorderitems(dispatchcontext dctx, Map context) { Les données en entrées et sorties sont contenues dans le contexte, des tests sont automatiquement effectués afin de savoir si les données sont conformes à leur types. Dans un code java, la méthode courante pour appeler un service de manière synchrone est d'utiliser la méthodes «runsync()» de la classe LocalDispatcher : map_out = dispatcher.runsync("service_name", map_in); Un service peut aussi être lancé de manière asynchrone. ControlServlet Le ControlServlet est un ensemble de classe permettant la présentation d'une application web autour du framework d'ofbiz. Son but premier est d'apporter un mécanisme de séparation propre entre la présentation logique des données et l'affichage selon le principe modèle-vue-contrôleur. OFBiz propose une multitude de moteurs de rendu, les plus utilisés actuellement étant les Widgets. Je détaillerai ici les mécanismes utilisés lors du cheminement de la requête «deleteshipmentitemfromitems» dans le module Facility, jusqu'à l'affichage de la page Web correspondante : Etape 1 : Traitement à effectuer à la réception de la requête : 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 requête = "deleteshipmentitemfromitems" Si l'utilisateur est authentifié et la connexion sécurisée Alors invoquer le service removeordershipmentfromshipment (les paramètres en entrée de cette vue sont présents sur la page actuel et sont transformés en objet Java) 17

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 Création de l'écran de réponse: <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 stipulés les traitements à effectuer : positionnement de champs ; appel de fichiers beanshell (.bsh langage très proche proche du Java, la différence étant qu'il n'est pas pré-compilé mais directement interprété à l'exécution) qui permettront d'effectuer divers traitements côté serveur (interrogations de la base de données...) et de positionner dans le contexte différentes variables. Les widgets assurent la présentation des données. Des fichiers freemarker (moteur de template pour générer du texte) peuvent être appelés. 18

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 généré : <html>... Bonjour monsieur le correcteur... </html> 2.3 Les différents modules Content Le module Content permet d'assurer la gestion de contenu (CMS). Ses entités sont utilisées pour enregistrer et manipuler les contenus généraux et les bases de connaissance. Ces entités incluent de nombreux concepts tels que : la séparation de l information et de l organisation des données qui peut être utilisé dans beaucoup de structures de données comme des arbres, listes ou des Maps d objets. Une fois ces structures créées, des outils évolués de recherche d information sont utilisés pour automatiser la création de nouvelles structures et permettre à l entreprise de gérer les documents. Accounting Les entités de Comptabilité sont organisées sur des principes généralement admis comme la comptabilité à double entrée, un registre général avec des comptes hiérarchisés... Elles sont structurées pour que l'on puisse gérer la comptabilité de plusieurs organisations. 19

Party Le module Party permet d'assurer la gestion de la relation client (CRM). Un Party peut représenter 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 modéliser des hiérarchies, des groupes de sécurité. Cette application est généralement utilisée pour gérer les informations sur le personnel de l entreprise, sur les relations avec ses clients et ses fournisseurs, etc. À chaque contact, on peut associer de nombreuses informations telles que des adresses, des numéros de téléphones, des rôles, et par un mécanisme d'extensions, des données supplémentaires. Product Les entités de Product contiennent les informations générales sur les produits vendables, achetables d'une entreprise. Les produits peuvent être des articles (matières premières, produits finis...), des services,... Les produits peuvent être organisés en catégories et en catalogue (notion de promotions, canaux de ventes...). Ils peuvent être associés à une multitude de prix selon la devise, le fournisseur, les dates, la quantité achetée, etc. Facility Un «Facility» est un bâtiment ou un emplacement physique tel que les stocks, les magasins, les docks, les bureaux,... En général un «Facility» aura un contact associé : une adresse, un numéro de téléphone,... Les bâtiments peuvent être regroupés en groupe de bâtiments, eux-mêmes pouvant faire partie de groupes de bâtiments. Ces groupes sont, par exemple, des chaînes de magasins, régions, départements. Des personnes ou groupes de personnes peuvent aussi être associés à des bâtiments pour définir où une personne travaille, qui gère le bâtiment, etc. Ce module permet de gérer les stocks d'une entreprise, il connaît ainsi pour un produit ses lieux de stockages, les quantités stockées et les indices de gestion de stock : seuils d'alerte, quantité économique... Order Le module «Order» permet de gérer tous les processus autour d'une commande d'achat ou de vente. Un ordre se compose d une en-tête de commande et de lignes de commandes qui décrivent les détails de l ordre et des ajustements tarifaires. Ces ajustements correspondent aux promotions, aux taxes et aux frais de ports appliqués à l ordre. Toutes les étapes d'une commande sont gérées du devis, à la facturation en passant par la réception de la commande, la gestion du retour de marchandise,... Shipment «Shipment» gère l ensemble des échanges de produits avec l extérieur, autrement dit les réceptions et les expéditions ainsi que les entrées et sorties de stock. On peut ainsi connaître pour un produit et un «Shipment» la quantité du produit expédiée ou reçue. Shipment fait aussi le lien avec les services des transporteurs pour le suivi des colis et des livraisons. 20

2.4 Processus de programmation Il est évident que tous les programmeurs d'ofbiz ne travaillent pas en même temps sur des sources partagées par tous. Nous utilisons donc un système de contrôle des versions appelé Subversion. Chaque programmeur travaille sur une copie locale des sources, cette copie pouvant être mise à jour avec la version la plus récente d'ofbiz grâce à la commande : svn update dans le répertoire d'ofbiz. La procédure de validation de nos développements est en revanche extrêmement fastidieuse. En effet, seules de rares personnes ont le droit de modifier les sources d'ofbiz. Les modifications apportées sont donc envoyées aux développeurs d'ofbiz sous forme de patch décrivant précisément les buts et raisons de ces modifications. L'incorporation de ces patchs (si ils sont un jour acceptés) peut prendre un certain temps(plusieurs semaines) et est source de nombreuses discussions, les patchs n'ayant pas une utilité flagrante et immédiate sont ainsi souvent rejetés. Les petites modifications sont beaucoup plus aisément admises et donc préférées. Or, un problème survient ici si vous voulez développer rapidement une nouvelle fonctionnalité. Vous envoyez vos premiers patchs qui n'ont aucune utilité directe et ne sont validés qu'après de longues discussions. S'ils sont un jour validés, ils sont souvent modifiés et donc à vous de modifier tous les traitements qui en découlent de votre côté. 21

3 3.1 OFBiz-Néogia Les origines d'ofbiz-néogia Bien qu'ofbiz soit totalement écrit en Java, la modélisation utilisée est un modèle entité-relation. Ainsi, les entités de base de données ne sont pas traduites en objet, on accède donc directement aux tûples de la base de donnée. La puissance d'un langage objet est alors totalement sous-utilisé, la plupart des méthodes est statique, on perd de plus le haut niveau d'abstraction offert par le langage objet. Le modèle entité-relation qui s'attache à la modélisation des données s'avère peu adapté à la réalisation des composants métiers où la modélisation des traitement est à privilégier. Néréide a donc initié en mai 2004, le projet Néogia 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 créer des composants OFBiz grâce à une modélisation UML. Néréide est en outre à l'origine de internationalisation d'ofbiz. 3.2 La génération de code Neogia utilise la technologie «Lutin-generator», développé par l'entreprise Code-Lutin, afin d'obtenir du code à partir de diagrammes UML. Les diagrammes sont créés grâce au logiciel Poseidon_for_UML Exemple de diagramme UML utilisé : 22

Image 4 exemple de modélisation UML Un système de tags permet de spécifier certaines caractéristiques aux entités : et aux attributs : 23

Cette génération de code, qui peut paraître de prime abord comme un «gadget», est dans les faits extrêmement utile. En effet, un nombre impressionnant de fichiers (environ 70 %) est généré faisant gagner un temps précieux en développement : fichiers de définition des services ; fichiers de définition des entités ; fichiers Java permettant l'abstraction Objet<->Entité ; fichiers d interfaces graphiques par défaut pour les objets modélisés ; fichiers de formulaires de recherche ; fichiers d'internationalisation. On peut aussi remarquer que la génération, de par son caractère systématique, permet d'amener une certaine homogénéisation des procédures de codage, homogénéisation malheureusement absente sur OFBiz. De plus, l'utilisation préalable d'une modélisation UML au codage «direct» offre la possibilité de fixer clairement le fonctionnement du module et permet aux nouveaux développeurs d'avoir un point de départ clair et précis pour mieux comprendre l'implémentation adoptée. 3.3 Modification de composants OFBiz De nombreux composants OFBiz ont été modifiés afin de pouvoir utiliser la modélisation objet de Néogia. Le principal but de ces modifications est de «traduire»les entités d'ofbiz en objet rendant la programmation beaucoup plus aisée : appel des méthodes de l'objet plutôt que l'appel direct aux tûples de la base de donnée. Les principales modifications (autres que la possibilité d'accéder directement à l'objet «traduit» de l'entité) apportées à ces composants sont : Common : permet de stocker les énumérations et les statuts utilisés dans Néogia dans les entités correspondantes d Ofbiz. Product : redirection d'une partie de la gestion des stocks sur le composant Néogia Facility 3.4 Ajout de composants De nombreux composants ont été rajoutés afin d'offrir un plus grand choix de fonctionnalités aux clients. Ces composants remplacent les composants OFBiz lorsqu'ils sont jugés trop insatisfaisants ou abordent des concepts absents dans OFBiz. Composants ajoutés : Manufacturing : remplace complètement le composant de même nom sous Ofbiz. Il remplit les mêmes fonctions mais a été entièrement repensé à partir d une modélisation UML. Facility : remplace le module de gestion des stocks dans Product d Ofbiz. Le modèle de données a été entièrement revu et il apporte en plus la gestion des inventaires physiques. Accounting : remplace le composant Accounting d Ofbiz et supporte la comptabilité analytique. 24

3.5 ServiceMgnt : gère toutes les activités de services ou de suivi de projet. Il n y a pas d équivalent dans Ofbiz. Processus de programmation Le système de contrôle de versions utilisé sous Néogia est CVS. Le processus de développement avec OFBiz-Néogia est simple et convivial. Plusieurs branches sont utilisées, dont principalement la branche HEAD et la branche STABLE. Les programmeurs travaillent avec la branche HEAD et valident directement leurs travaux sur cette dernière. Lorsque les fonctionnalités sont suffisamment mûres et solides, elles sont incorporées dans la branche STABLE. C'est cette branche STABLE qui est proposée aux clients. Lorsque les programmeurs d'ofbiz-néogia travaillent sur des composants propres à OFBiz, ce qui est relativement peu courant, nous envoyons nos modifications suivant la procédure d'ofbiz. Afin d'optimiser la communication entre les différent collaborateurs et ainsi la productivité, nous utilisons un repositoire Web. Les différentes tâches à accomplir y sont déposées et classées par type (bug, patch OFBiz, nouvelle foncionnalité) et module. Une priorité peut être associée à chaque tâche. Les status d'iune tâche sont les suivants ToBeTested : la tâche a été réalisé on fait appel à un collaborateur différent du réalisateur afin de valider le fonctionnement ToStable : la tâche a été validé et est prête à passer dans la branche STABLE ToJIRA : le développement réalisé doit être envoyé sous forme de patch à OFBiz 25

Mes réalisations 26

1 Procédure de réalisation d'un ordre d'achat Afin de rendre plus compréhensible et mieux situer les explications sur mes développements, je commencerai par vous présenter l'enchaînement d'écran actuel (à la fin de mon stage) du processus réalisation d'un ordre d'achat, de sa création à sa réception. Les parties créations et modifications d'un ordre d'achat font partie du module «Order» et sont donc développées par l'équipe d'ofbiz. En revanche, la réception est spécifique à Néogia et se trouve dans le module Facility ; ce dernier a été développé par Messieurs Gaudin et Malet (équipe Néréide). 1.1 Création d'un ordre d'achat étape 1 : Dans le cadre d'un ordre d'achat, l'utilisateur peut sélectionner : le centre de profit : il définit toutes les règles commerciales (taxes, livraisons, paiements, promotions... l'acteur facturé : l'entreprise de l'utilisateur, un service particulier, une filiale,... le fournisseur : personne à qui on achète les produits, les prix du produits sont associés au fournisseur Image 5 étape 1 de la création d'un ordre d'achat 27

étape 2 : Sélection des conditions de paiement particulières, promotions etc. ; Choix de la devise ; Image 6 étape 2 de la création d'un ordre d'achat étape 3 : Dans cet écran sont ajoutés les produits ; pour l'ajout d'un article on peut spécifier : la référence de l'article ; la quantité délivrée ; l'unité de mesure de cette quantité comme par exemple : le conditionnement par boîte de 10 unités ; la date de livraison souhaitée pour cet article ; un éventuel commentaire. Sont ensuite affichés les produits déjà ajoutés et les éventuelles promotions, une fois un produit ajouté son coût et sa quantité ne sont plus modifiables. 28

Image 7 ajout des lignes d'une commande (étape 3) La référence de l'article peut être renseignée soit directement, soit grâce à un lookup (la petite icône à droite du champ de saisie). Le lookup est un procédé couramment utilisé ; il permet d'afficher les champs d'une table ou d'une vue, des opérations de recherche peuvent être effectuées selon différents critères. L'exemple montré dans la copie d'écran suivante illustre le lookup apparaissant pour le choix d'un article : 29

Image 8 lookup sur les produits étape 4 : Permet de spécifier des règles de paiement particulières (article non interchangeable, exclusivité)... Image 9 conditions de règlements (étape 4) étape 5 : Permet de spécifier l'adresse où les articles doivent être expédiés soit : l'adresse du magasin de stockage (par défaut sont présentées les adresses du magasin par défaut du centre de profit) ; l'adresse d'un acteur. 30

Image 10 adresse d'expédition (étape 5) étape 6 : Dispositions particulières sur l'expédition : moyens d'envoi (poste, colis express,...) ; attendre ou non que tous les produits commandés soient prêts pour envoyer la commande ; message spécial, par exemple dans le cadre d'un cadeau ; dates de livraisons. Image 11 dispositions particulière de l'expédition (étape 6) 31

étape 7 : Permet d'ajouter des informations supplémentaires sur d'éventuels acteurs à associer à la commande, on choisi un acteur puis son rôle parmi la liste des rôles que l'acteur peut effectuer. Image 12 ajout de rôles (étape 7) étape 8 : Vérification de de la commande, récapitulation des achats et calcul du prix avec les taxes, promotions, frais de port,... Image 13 vérification commande (étape 8) 32

étape 9 : Création de la commande : La commande est maintenant créée, divers liens permettent de naviguer sur les informations associées à la commande (fournisseur, acteurs, centre de profit, réception,...), 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 manière plus fonctionnelle, la création d'un ordre de vente consiste en la création d'un objet Java : le ShoppingCart. Chaque ligne de commande est stockée dans un ShoppingCartItem. L'objet ShoppingCart, assimilable à un caddie, conserve toutes les informations relatives à l'ordre d'achat et ce jusqu'à la création effective de ce dernier (étape 8). Cette étape de création consiste à stocker dans les entités du module Order toutes les informations contenues dans le ShoppingCart. Le principal problème de la méthode, consistant à utiliser un ShoppingCart plutôt que directement les entités d'order, est la duplication de code. Par exemple tous les getters et setters sont dupliqués, 33

ainsi que des méthodes plus compliquées comme le calcul du prix ce qui ne facilite pas la maintenance du code. 34

3.6 Modification d'un ordre d'achat Après avoir cliqué sur le bouton d'édition des lignes plusieurs opérations 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 création d'un ordre d'achat, la seule différence étant la possibilité de modifier le prix. Image 15 modification commande Fonctionnellement, le principe est le même que lors de la création. Lorsque l'utilisateur clique sur le bouton de mise à jour des lignes ou d'ajout d'une ligne, les données contenues dans les entités du module Order sont «chargées» dans le ShoppingCart, subissent les modifications apportées par l'utilisateur et, enfin, à nouveau stockées dans les entités d'order. 35

3.7 Réception d'un ordre d'achat étape 1 : Création d'une réception : type de réceptions (réception de retour de vente, de fabrication de commande d'achat...) ; la commande principale associée à la réception (une réception est souvent associée à une seule commande mais il sera possible si on le souhaite dans les écrans suivants d'associer d'autres commandes à la réception créée ; à l'inverse, une commande peut faire l'objet de plusieurs réceptions) ; le bon de livraison reçu à la réception des produits ; d'éventuels commentaires. Image 16 création réception (étape 1) étape 2 : Réception de stock, l'utilisateur choisit ici les commandes correspondant aux produits réceptionnés, il peut ensuite choisir d'afficher un seul produit ou tous les produits de la commande. Image 17 sélection produit(s) à réceptionner (étape 2) 36

Étape 3 : L'utilisateur indique : l'emplacement de stockage, qui peut être un entrepôt et plus précisément une pièce d'un entrepôt ; les quantités acceptées ; les quantités refusées avec la raison du refus ; si l'article est stocké en série ou non. Image 18 édition ligne(s) de réception (étape 3) Étape 4 : Sont récapitulés ici, les différents produits reçus. Pour chaque produit, les quantités reçues sont indiquées (lors de cette réception mais aussi lors d'autres réceptions de ce produit avec la même commande) ainsi que les quantités restantes. 37

Image 19 visualisation ligne(s) de réception (étape 4) La réception utilise l'objet Shipment et les objets en relation directe avec ce dernier : ShipmentItem. Le fait de réceptionner des produits s'apparente à des mouvements de stocks. On distingue les mouvements de stocks réalisés : StockEvent des mouvements de stocks planifiés : StockEventPlanned. 4 Diagramme UML simplifié d'order Afin de préciser mes explications ultérieures, je vais détailler ici les principales entités du module Order que sont OrderItem et OrderHeader. 38

Image 20 diagramme simplifié de Order OrderHeader correspond aux informations de l'en-tête de la commande : date de la commande, type de commande (achat, vente,...), date de la commande, fournisseur, centre de profit, devise, canaux de vente (téléphone, mail,...), acteur, méthode de paiement, statut de la commande (créée, approuvée, annulée,...)... OrderItem correspond aux informations de chaque ligne de la commande : quantité, prix unitaire, prix moyen, commentaire, produit, expédition, mouvement de stock... 39

5 Diagramme UML des relations entre Facility et Order Image 21 diagramme UML des relations entre facility et order La relation entre une réception (Shipment) et une commande (Order) ne se fait pas au niveau des entêtes mais bien des lignes (respectivement ShipmentItem et OrderItem). On peut trouver dans une réception des lignes de plusieurs commandes différentes et de même une commande peut être réceptionnée par plusieurs réceptions. 40

6 Réalisations sur le module Order 6.1 Gestion des unités de quantité sur le module Order Problématique : Lors de la saisie d'un ordre, il n'y a actuellement aucun moyen de stipuler une unité de quantité (boîte de 10, litre, mètre). Or, le besoin de cette unité de quantité est rapidement devenu évident. Par exemple, si vous voulez avoir une boîte de 100 clous (notion différente pour le stock de 100 clous à l'unité) ou une boîte de 10 clous, le seul moyen actuellement est de créer 2 produits différents. 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 développements apportés à l'équipe d'ofbiz et s'efforcer de les faire adopter. Après réflexion, 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 unités de quantité du même type que l'unité de quantité par défaut du produit. La quantité saisie est directement convertie dans l'unité par défaut du produit afin de ne pas modifier le comportement de tous les traitements utilisant la quantité. Démarche adoptée : analyse et modification des entités de gestion des unité de mesure (ou uom Unity Of Measure) et des services de conversions d'unités proposé par OFBiz ; analyse des entités d'order pour savoir comment stocker l'information sur l'unité de quantité ; modification des mécanismes du ShoppingCart pour y incorporer cette information ; modification de l'interface graphique. Analyse et modification des entités de gestion des uom et des services de conversions d'unités proposés par OFBiz Modèle UML simplifié décrivant les entités chargées de la gestion des unités de mesure : 41

Image 22 diagramme UML des Uom Le modèle proposé par OFBiz est parfaitement suffisant car il permet de prendre en compte une notion de type entre les unités de quantité. De plus, la conversion entre les uom est rendue possible grâce aux entités UomConversion et UomConversionDated (incluant la notion de dates très utile pour la monnaie, par exemple). Le service de conversion proposé par OFBiz est par contre beaucoup moins séduisant. Entrée : 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. 42

Deux inconvénients majeurs sont à relever : Il ne propose pas, en entrée, la notion de date. Ainsi, le facteur de conversion choisi pour une conversion datée est toujours la conversion la plus récente de l'entité UomConversionDated. Ce service est donc inutilisable pour des conversions de monnaies qui nécessitent le facteur de conversion à la date de la transaction. Il ne trouve de conversions entre les 2 unités en entrée, qu'à la condition qu'elles soient directement présentes dans les tables. Exemple : si dans la table UomConversion nous avons l'enregistrement suivant : uomto=minute, uomfrom=heure, conversionfactor=60 et à l'entrée du service uomto=heure et uomfrom=minute, le service est alors incapable de trouver une conversion. S'il y a n Uom d'un même 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 débutant. J'ai donc créé un nouveau service de conversion en Java dont voici la définition : <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 unités en entrées est prise en compte jusqu'à une indirection et quelque soit le sens. Par exemple : si sont présents 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 créer des conversions vers une unité étalon (exemple : le Kg pour le poids) ce qui réduit considérablement le nombre d'enregistrements de conversions nécessaires. Analyse des entités 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 stockées dans l'entité OrderItem. Une relation a donc était rajoutée 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> 43

<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 mécanismes du ShoppingCart pour y incorporer la gestion de l'unité de quantité Modifications apportées à ShoppingCartItem, entité contenant les informations d'une ligne d'une commande : ajout de l'attribut itemquantityuomid, la référence 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 défaut 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 entités d'order (méthode statique loadcartfromorder de ShoppingCartServices) pour prendre en compte le nouvel attribut. Modification de l'évènement permettant de créer un nouveau ShoppingCartItem (méthode statique addtocart de ShoppingCartEvents) pour prendre en compte le nouvel attribut. Ajout de la méthode statique getuomquantity(...)(code identique à la méthode 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 apparaît dans quatre écrans provenant tous d'un fichier freemarker différent ou l'unité de mesure a été rajoutée : image 6 (ajout des lignes d'une commande) modification de showcart.ftl 44

image 16 (visualisation commande) modification de orderitems.ftl image 17 (modification commande)modification de editorderitems.ftl et appenditems.ftl Modification du fichier générant le PDF imprimable de la commande : orderview.fo.ftl Sur l'image 6 un lookup a été ajouté afin d'afficher toutes les unités de quantité du même type que l'unité de quantité par défaut du produit. Pour ce faire quatre fichiers ont été modifiés : 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 paramètre le champ de retour et en deuxième l'uri. du lookup. Comme, il est nécessaire de connaître l'identifiant du produit afin d'afficher le bon Uom ce dernier est concaténé à l'uri du lookup dans la fonction findproductuom(), il pourra ainsi être récupéré 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"> 45

<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 même type que le produit : Récupération de l'identifant du produit passé en paramètre au lookup : <set field="productid" from-field="parameters.productid" /> Récupération de l'identifiant de l'unité de mesure de quantité par défaut du produit grâce à une interrogation de la base de donnée : <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 même 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 définis 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" /> 46

<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="&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 généré : Image 23 Lookup sur les Uom disponibles pour produits 47

Bilan L'objectif fonctionnel est réalisé et la gestion des unités de quantité fonctionne. En revanche, les modifications n'ont pas été validées par l'équipe d'ofbiz. Cette tâche a été ma première réalisation au sein de l'équipe de Néréide et m'a pris relativement beaucoup de temps. En effet, un nombre extrêmement important de petites modifications est nécessaire et ce, sur des fichiers totalement inconnus avec de multiples langages. De plus, le composant d'ofbiz ne bénéficie pas de la traduction des entités en objet, chose ce qui ne simplifie pas la programmation. 6.2 Gestion des prix lors de modifications d'une commande Problématique : la gestion des prix sur l'écran d'order est essentielle pour l'erp, or de multiples problèmes ont été relevés. Objectifs fonctionnels : Il convient de résoudre les problèmes suivants : après modification d'une commande d'achat tous les prix sont remis à zéro ; les prix unitaires préalablement modifiés sont perdus après une mise à jour de la commande ; les rôles des acteurs d'une commande d'achat (débiteur, créditeur) sont mal définis ; la saisie des prix n'est pas localisée lors de la modification d'une commande. Objectifs non fonctionnels : être le moins invasif possible dans le code actuel ; envoyer les développements apportés à l'équipe d'ofbiz et s'efforcer de les faire adopter. 6.2.1 Mémorisation d'un changement de prix Lors de la modification d'une commande, les prix ne sont pas chargés dans le ShoppingCartItem avec le reste des informations concernant une ligne de commande (quantité, produit,...). En effet, les prix dépendent de la quantité de produit et sont donc recalculés à chaque mise à jour. Un nouveau champ a donc été rajouté dans ShoppingCartItem et OrderItem afin de préciser si le prix a déjà été modifié et, dans ce cas particulier, le prix est chargé directement du stockitem et n'est pas recalculé. 48

6.2.2 Recalcul du prix des commandes d'achats La méthode 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 dépend directement du produit, alors que celui d'une commande d'achat dépend du fournisseur. Cette méthode a donc été modifiée pour qu'elle puisse calculer à la fois les prix des commandes d'achat et de vente. 6.3 Définition des rôles d'une commande d'achat A chaque commande (OrderHeader) sont associés des acteurs correspondant a des rôles : l'acteur créditeur et l'acteur débiteur. 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 débiteur et dans le cas d'une commande d'achat du créditeur. Or, lors du chargement d'un OrderItem dans le ShoppingCart, l'acteur du ShoppingCart prenait automatiquement la valeur du débiteur quel que soit le type de la commande. Un contrôle 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 OFBizNéogia est un ERP internationalisé, cela se traduit par exemple avec la gestion des nombres décimaux. 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 chaîne de caractères saisie est convertie en prix selon une locale (le pays). L'objet Java utilisé permettant de convertir une chaîne de caractères 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()); } 49

Bilan Ses modifications sur les prix fonctionnenet actuellement malgré quelques déboire aux début (divers effets de bords). Toutes les modifications apportées ont été prises en compte par l'équipe d'ofbiz. 6.5 Diverses améliorations du composant Order Diverses améliorations 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 défaut é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 défaut du centre de profit. Un hook a été rajouté sur l'identifiant d'une commande. Le principe d'un hook est de «dévier» un traitement dans un fichier particulier, fichier qui est facilement modifiable par le client. Il peut donc customiser comme il le souhaite le traitement spécifique, sans risque d'effet de bord. Si le client ne customise par le traitement alors le traitement par défaut d'ofbiz-néogia est appliqué. 50

7 Réalisations sur le module Facility 7.1 Améliorere la gestion de la rejection Problématique : Comme vu sur l'écran de réception d'une commande d'achat (image 18), on peut refuser une partie de la commande et ceci pour divers raisons : produit non-commandé, endommagés... Ce refus d'une certaine quantité de produit entraîne la création d'un mouvement de stock (StockEvent). Or, comme vous pouvez le voir sur le schéma UML de Facility to Event (image 21), aucun champ n'est prévu 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 idéal. Objectif fonctionnel : Intégrer la raison du refus dans les entités de Facility et modifier les traitements afin de prendre en compte cette modification Démarche adoptée : modification des entités de Facility Après analyse des différentes tables proposées par OFBiz, il apparaît qu'une entité rejectionreason existait déjà. Il m'a donc suffit de créer une relation entre le mouvement de stock réalisé et l'entité rejectionreason dans le diagramme UML. Après génération de code, le fichier de définition des entités 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> 51

Grâce à la génération de code, la classe StockEvent a été modifiée afin de pouvoir gérer ce nouvel attribut. Comme tous les mécanismes internes de gestion de ce nouvel attribut sont générés automatiquement, on peut remercier la génération automatique et passer à la phase suivante. Il s'agit maintenant de modifier les interfaces graphiques de saisie des réceptions afin de saisir et d'afficher le motif du refus à partir de ce nouveau champ et non du commentaire. L'interface graphique d'affichage de réceptions utilise deux fichiers : ListReceiptByOrder.bsh qui a pour rôle de placer dans le contexte toutes les informations concernant les mouvements de stocks. L'information sur le motif de refus a donc été rajoutée : 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 récupère alors la donnée pour générer la page html : <div class="tabletext"><font color="red">$ {shipmentitem.rejectionreason?if_exists}</font></div> 7.2 Lier un acteur à un événement de stock Bien que la relation entre un acteur et un mouvement de stock réalisé soit présente dans la base de données aucune interface graphique ne permet d'effectuer cette association et les mécanismes internes ne sont pas non plus implémentés. Objectif fonctionnel : Pouvoir lier un acteur à un mouvement de stock La démarche utilisée est très similaire au chapitre précédent et je ne la détaillerai donc pas ici. 52

Conclusion Ce stage m'a été extrêmement enrichissant à la fois sur le plan personnel et technique. Les différentes tâches auxquelles je me suis attelées ont été pour la plupart menées à leurs termes. Si le FrameWork d'ofbiz est extrêmement puissant il ne rend pas pour autant la programmation facile. Ainsi, un nombre extrêment important de fichiers et de mécanismes sont à appréhender. 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 générique possible) et est fortement connecté avec les autres processus et la moindre modification entraîne de nombreux effets de bords. Une compréhension globale des processus est alors nécessaire, compréhension longue à acquérir pour le néophyte. Ce projet m'a permis de découvrir de nombreuses technologies (BeanShell, FreeMarker, J2EE, MVC, ant, générateur, 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é séduit par leurs surprenantes maturité et l'énergie des communautés qui les développent. 53