Faculté des Sciences
    Département d'informatique
    1, Rue de Chartres 
    45067 Orléans cedex 2.

Rapport de Stage :
     Développement sur l'ERP libre
OFBiz­Néogia

    Responsable de Stage :                              Étudiant :
     Peter GORON Mickaël HARDOUIN
     Master 2 IRAD

    
     3 bis, les Isles ­ 37270 Véretz                     Année 2006
     
 Remerciements

Mes remerciements vont à toute l'équipe de Néreide, en commençant par Olivier Heintz pour 
sa disponibilité, ses explications, en particulier  sur  le plan fonctionnel, et sa patience à  me les 
transmettre. 

Nicolas Malin, pour la générosité de son accueil à son domicile lors de ma semaine de 
formation; Peter Goron pour m'avoir encadré tout au long de mon stage et pour tous ses conseils 
techniques avisés; Sophie Benaroch pour la relecture de mes documentations fonctionnelles dans le 
but de les rendre plus claires .

Je souhaite également remercier Jean Luc Malet et Pierre Gaudin, pour m'avoir également 
transmis   des   explications   sur   le   plan   fonctionnel   ainsi   que   la   bonne   humeur   qu'ils   apportent   à 
l'ambiance déjà très chaleureuse de l'équipe . 

Je   n'oublie   pas   ma   collègue   stagiaire;   Cécile   Bourreau   pour   l'aide   qu'elle   m'a   apportée 
notamment sur le module « Order » .

Pour mettre un trait d'honneur à ces remerciements, je voudrais remercier toute la famille 
Heintz, pour sa gentillesse et l'accueil qu'ils ont pu m'accorder au sein de leur domicile tout au long 
de ce stage; notamment durant les pauses déjeuners.
Table des matières
Remerciements.....................................................................................................................................3
Introduction..........................................................................................................................................6
Présentation de l'entreprise...................................................................................................................7
1. La société Néreide........................................................................................................................7
2. Le réseau Libre­Entreprise...........................................................................................................8
Présentation de l'ERP OfbizNéogia......................................................................................................9
1. Généralités sur les ERP................................................................................................................9
1.1 Définition...............................................................................................................................9
1.2 Avantages...............................................................................................................................9
1.3 Inconvénients.......................................................................................................................10
1.4 Les ERP libres.....................................................................................................................10
2. Le projet Ofbiz...........................................................................................................................11
2.1 Architecture d'Ofbiz............................................................................................................12
2.2 Le framework......................................................................................................................13
2.2.1 L'EntityEngine.............................................................................................................13
2.2.2 Le Service Engine........................................................................................................14
2.2.3 Le Control Servlet........................................................................................................14
2.3 Les différents modules........................................................................................................16
2.3.1 Content.........................................................................................................................16
2.3.2 Accounting...................................................................................................................16
2.3.3 Party.............................................................................................................................16
2.3.4 Product.........................................................................................................................16
2.3.5 Facility.........................................................................................................................17
3. Le projet Néogia.........................................................................................................................18
Contexte de travail..............................................................................................................................19
1. Outils utilisés..............................................................................................................................19
2. Méthode de travail.....................................................................................................................20
Développement Réalisés.....................................................................................................................21
1. Gestion des erreurs.....................................................................................................................21
1.1  Présentation et Objectifs.....................................................................................................21
1.2  Analyse...............................................................................................................................22
1.3  Résultat...............................................................................................................................24
2. Liste de transferts.......................................................................................................................26
1.1  Présentation et Objectifs..........................................................................................................26
1.2  Analyse...............................................................................................................................27
1.3  Résultat...............................................................................................................................29
Conclusion..........................................................................................................................................32
Résumé...............................................................................................................................................33
Abstract...............................................................................................................................................33
Bibliographie......................................................................................................................................34
Index des illustrations
Illustration 1: Logo entreprise Néreide.................................................................................................7
Illustration 2: Logo du réseau Libre­Entreprise...................................................................................8
Illustration 3: Logo ERP Ofbiz...........................................................................................................11
Illustration 4: Architecture ERP Ofbiz...............................................................................................12
Illustration 5: Boucle d'évènement.....................................................................................................15
Illustration 6: Logo Projet Néogia......................................................................................................18
Illustration 7: Exemple de déclenchement d'erreur.............................................................................21
Illustration 8: Résultat du diagramme UML après modification........................................................23
Illustration 9: Écran listant les erreurs enregistrer en base.................................................................24
Illustration 10: Écran d'édition des permission ( lecture / écriture ) sur les erreurs...........................25
Illustration 11: Écran d'ajout de transfert à une liste de transfert........................................................26
Illustration 12: Relation de l'entité TransfertList avant la création de l'entité TransfertListModel....27
Illustration 13: Relation après la création de TransfertListModel......................................................28
Illustration 14: Création du modèle de la liste de transfert.................................................................29
Illustration 15: Écran d'ajout de transfert à un modèle de liste de transfert .......................................29
Illustration 16: Création de la liste de transfert...................................................................................30
Illustration 17: Liste des transfert planifiés ne faisant pas partie d'une liste.......................................30
 Introduction
  On  ne  présente plus les logiciels libres, aujourd'hui reconnus  pour leurs qualités et  leur 
ouverture. Ils ont démontré leur efficacité dans plusieurs domaines, notamment Internet, avec par 
exemple,   le   serveur   web   Apache   et   le   système   d'exploitation   Linux.   Aussi,   de   nombreuses 
entreprises et gouvernements ont commencé la migration de leurs systèmes d'information vers des 
solutions   libres.   Par   conséquence,   on   commence   à   trouver   ces   logiciels   dans   des   secteurs 
traditionnellement   réservés   aux   logiciels   propriétaires,   en   particulier,   les   PGI   ou   Progiciels   de 
Gestion Intégrés. Cependant, ce type d'application joue un rôle stratégique au sein des entreprises 
qui les utilisent. Il requiert un très haut niveau de technicité et de compétences que ces dernières ne 
sont pas prêtes à laisser aux mains de développeurs éparpillés aux quatre coins du monde. C'est 
pourquoi, comme pour les logiciels propriétaires, est apparue la nécessité d'avoir des entreprises 
prestataires de services spécialisées en logiciels libres. 
Néréide est une de ces nouvelles SSLL (Société de Services en Logiciels Libres). Elle propose à ses 
clients un PGI basé sur le logiciel libre Open For Business (Ofbiz) pour lequel elle peut développer 
des besoins spécifiques pour chacun d'entre eux.

Voulant élargir mes connaissances dans le domaine fonctionnel et par la même occasion découvrir 
le monde du travail dans les SSLL , mon choix s'est naturellement orienté vers cette jeune entreprise 
qui m'a accueilli du début du mois d'avril jusqu'à fin septembre sous la responsabilité de Peter 
Goron.

La première partie de mon travail a consisté en l'étude du fonctionnement de l'ERP OfbizNéogia. 
Pour m'aider dans cette tâche, j'ai effectué une semaine de formation avec 3 autres stagiaires. Cette 
formation m'a permis de connaître les bases du fonctionnement de l'application, notamment   les 
interconnexions entre les différents modules que compose l'ERP.  Contrairement à certains de mes 
collègues qui se sont spécialisés sur un module, mes développements ont été divers et variés. J'ai 
commencé par travailler sur un module technique puis continuer sur des modules fonctionnels. 
 Présentation de l'entreprise

1. La société Néreide

Illustration 1: Logo entreprise 
Néreide

Néréide   est   une   jeune   société   de   services   en   logiciels   libres   (SSLL)   spécialisée   dans 
l'intégration de l'ERP Open Source OfbizNéogia. Créée en mars 2004 sous la forme d'une SARL à 
capital variable, elle est située à 10 km à l'Est de Tours. Outre l'intégration d' OfbizNéogia, elle 
propose   à   ses   clients   toute   une   gamme   de   services   centrés   autour   de   l'ERP   :   développements 
spécifiques, administration système, infogérance, maintenance et support applicatif. Étant membre 
du   réseau   Libre­Entreprise,   cette   offre   peut   être   étendue   selon   les   services   que   proposent   les 
membres de ce réseau (cf. section suivante). 

L'équipe de Néreide se compose de : 
• Olivier Heintz, Directeur de projet;
• Jean­Luc Malet, Directeur de projet;
• Yannick Thebault, Architecte.
• Pierre Gaudin, Développeur;
• Sophie Benaroch, Chargée d'affaires;
• Catherine Heintz, Responsable communication – administration
• Peter Goron, Développeur;   ( mon maître de stage ) 

Également présent en tant que stagiaire durant ma période de stage :
• Cécile Bourreau,  Master de l'université de Poitiers DESSTAUP
• Cédric Vallée, 2ème année à Polytech’ Tours, département informatique;
• Simon Baudry, 2ème année à Polytech’ Tours, département informatique;
 2. Le réseau Libre­Entreprise

Illustration 2: Logo du réseau 
Libre­Entreprise

Le   réseau   Libre­Entreprise   regroupe   des   entreprises   ayant   des   spécialités   proches   ou 
complémentaires, en particulier dans le domaine du logiciel libre. 
L'organisation en réseau permet à tous les membres de bénéficier d'une offre commerciale étendue 
homogène   et   de   disposer   d'un   ensemble   de   ressources   spécialisées   dans   chaque   domaine 
d'intervention   grâce   aux   partages   des   connaissances.   En   outre,   un   ensemble   d'outils   de   travail 
collaboratif est mis à la disposition des membres du réseau pour simplifier la  communication au 
sein du réseau et pour les aider dans leurs démarches :
• documentations partagées :
• documents sur la création d'entreprise,
• documents techniques,
     • modèles de documents;
• calendrier partagé;
• listes de diffusion partagées;
• serveur de messagerie instantanée (Jabber);
• le laboratoire Libre­Entreprise : une plateforme 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 agrégateur de contenu qui permet de suivre l'activité des
       membres du réseau.

Pour faire partie du réseau, les sociétés doivent envoyer un compte­rendu mensuel d'activité 
sur la liste de diffusion "réseau" afin que tous les membres puissent connaître l'évolution de chaque 
entreprise.   La   forme   exacte   de   ce   rapport   n'est   pas   définie   mais   certaines   informations   sont 
nécessaires, comme une rapide présentation de l'entreprise, l'effectif, les finances, les affaires en 
cours et les affaires probables.
 Présentation de l'ERP OfbizNéogia 
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.   Ainsi,   les 
Achats, la Comptabilité, la Gestion des Stocks, les Ressources Humaines, la Gestion Commerciale, 
etc 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. 
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
­ minimisation des coûts: pas d’interface entre les modules, synchronisation des traitements, 
    maintenance corrective simplifiée car assurée directement par l'éditeur et non plus par le 
    service informatique de l'entreprise      
­ 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.
 
1.3 Inconvénients

Les ERP / PGI ne sont cependant pas exempts d'inconvénients :

­ coût élevé      
­ périmètre fonctionnel souvent plus large que les besoins de l'organisation ou de l'entreprise
­ 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 
­ nécessité d'adapter parfois certains processus de l'organisation ou de l'entreprise au   
    progiciel ;
­ nécessité d'une maintenance continue.
     
1.4 Les ERP libres

Le secteur des ERP a subi depuis quelques années 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.
 2. Le projet Ofbiz

Illustration 3: Logo ERP Ofbiz
Open For Business, ou Ofbiz, est un projet de progiciel de gestion intégré (PGI) libre initié 
par deux développeurs américains, Andy Zeneski et David E. Jones, en mai 2001. L'objectif de ce 
projet est de fournir un ensemble de composants homogènes permettant de développer aisément et 
rapidement des logiciels libres de gestion. 
À terme, il est prévu d'obtenir tous les composants nécessaires à un PGI intégrant les modules de 
gestion suivants :

­ 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 )

Ofbiz se base sur de nombreux logiciels libres tels que Ant, Tomcat , JPublish, FreeMarker, 
etc. Ces logiciels sont reconnus pour leur qualité et ils assurent l'indépendance du projet. De même, 
pour garantir un maximum de compatibilité avec les systèmes existants et futurs, Ofbiz respecte de 
nombreux standards, notamment J2EE et XML. Ce dernier possède une part très importante dans le 
projet Ofbiz notamment pour décrire les données et les traitements. Un des avantages d'Ofbiz réside 
dans  sa   parfaite compatibilité   avec tous  les  serveurs  d'applications  J2EE  et  toutes  les  bases   de 
données du marché. Par ailleurs, le code source du projet est publié sous la licence MIT qui est 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.   Grâce   à   l'ouverture   du   code,   une 
véritable communauté d'utilisateurs et de développeurs s'est formée. Cette dernière assure ainsi la 
réactivité et la qualité du projet mais également la pérennité du projet. Cependant, de par sa taille et 
sa complexité, ce type de logiciel nécessite de gros investissements humains, matériels et financiers 
pour   son   développement   mais  aussi  pour  être  reconnu.  Les  auteurs   initiaux  ont  donc  créé   une 
société, Undersun Consulting, qui offre des services autour d'Ofbiz tout en les rémunérant pour leur 
travail de développement. Plusieurs sociétés du même type se sont créées un peu partout dans le 
monde, dont Néréide pour la France. Elles participent ainsi au projet en tant que sponsors.
 2.1 Architecture d'Ofbiz

   Ofbiz est une application java client­serveur compatible avec la spécification J2EE qui 
définit une architecture logicielle standard. On retrouve ainsi les trois éléments caractéristiques
d'une architecture 3­tiers :
• les clients légers : machines disposant d'un navigateur internet;
• un serveur exécutant les différentes applications Ofbiz;
• et une ou plusieurs bases de données stockant le système d'information de l'entreprise.

Cependant Ofbiz à la possibilité de faire appel à des applications externes via des services locaux ou 
distants ( WebServices ). On peut donc considérer Ofbiz comme une architecture n­tiers.

Illustration 4: Architecture ERP Ofbiz

L'architecture   d'Ofbiz   se   décompose   en   une   multitude   de   composants   qui,   regroupés 

ensemble, forment un PGI complet. Toutefois, tous n'ont pas le même rôle au sein du PGI, c'est 
pourquoi on les classe selon trois niveaux d'abstraction :
• le framework qui permet de développer des applications métier rapidement;
• les applications de base que l'on retrouve dans tout type d'organisation;
• les applications de haut­niveau et/ou applications métier.
 2.2 Le framework

Le fonctionnement du framework d'Ofbiz repose sur 3 composants majeurs : l'EntityEngine, 
le ServiceEngine, le ControlServlet. 

2.2.1 L'EntityEngine

  L'Entity Engine est un composant Ofbiz qui se charge de la gestion des données de tous les
autres composants Ofbiz. L'Entity Engine possède de nombreux points forts :
• gestion automatique de la persistance de données;
• accès aux données via une interface unique, le « GenericDelegator »;
• supporte l'accès transparent à plusieurs base de données;
• les entités sont définies dans de simples fichiers XML;
• tous les types java de base ont un équivalent en base de données;

Voici un exemple de définition d'une entité : 

<entity entity­name="RoleType"
            package­name="org.ofbiz.party.party"
            default­resource­name="PartyEntityLabels"
            title="Role Type Entity">
      <field name="roleTypeId" type="id­ne"></field>
      <field name="parentTypeId" type="id"></field>
      <field name="hasTable" type="indicator"></field>
      <field name="description" type="description"></field>
      <prim­key field="roleTypeId"/>
      <relation type="one" fk­name="ROLE_TYPE_PAR" title="Parent" rel­entity­name="RoleType">
        <key­map field­name="parentTypeId" rel­field­name="roleTypeId"/>
      </relation>
      <!­­ Begin neogia specific : value factory ­­>
      <value­factory class­name="org.ofbiz.party.party.developed.RoleTypeServices" />
      <!­­ End neogia specific : value factory ­­>
    </entity>

Chaque   entité   possède  un   nom   (   entity­name   )   ,   un  emplacement   (   package­name   ),   un   titre   , 

éventuellement un string définissant le fichier de labels à utiliser (default­ressource­name) , une liste 
de champs ( field ) et pour la plupart du temps des relations avec une ou plusieurs entités. 
 2.2.2 Le Service Engine

   Le Service Engine se charge des traitements des composants Ofbiz. Ces traitements sont 
appelés Services et peuvent être exécutés localement ou à distance. L'avantage du Service Engine se 
situe   dans   la   non   nécessité   de   connaître   l'emplacement   ou   l'implémentation   des   services   pour 
pouvoir les lancer. C'est le ServiceDispatcher qui se charge alors de trouver l'implémentation du 
service et de son exécution. Un autre intérêt est la possibilité de rendre disponible tout service Ofbiz 
vers l'extérieur.

Chaque service doit comporter les éléments suivants : 
– un nom
– une implémentation ( ici java )
– sa localisation
– la méthode à invoquer
– la nécessité ou non d'être authentifié pour pouvoir l'appeler
– les paramètres d'entrée ( attribut en mode IN )
– les paramètres de sortie si existant ( mode OUT )

Lors de l'appel à un service, une vérification automatique des paramètres d'entrée est effectuée pour 
contrôler que tous les paramètres obligatoires sont bien renseignés, et qu'ils sont du type attendu. 

2.2.3 Le Control Servlet

   Le   ControlServlet   est   l'élément   clé   de   la   communication   entre   les   utilisateurs   et   les 
applications web d'Ofbiz. Implémenté selon le modèle MVC (Modèle­Vue­Controleur), il gère la 
boucle d'événements de l'interface graphique et les différents moteurs de rendu de l'application. Les 
réponses aux interactions de l'utilisateur s'effectuent par l'intermédiaire d'événements qui peuvent 
être implémentés sous la forme de services, de méthodes java, de scripts Beanshell ou Minilang.

Illustration 5: Boucle d'évènement
Voici l'ensemble des opérations effectuées suite à une interaction avec l'utilisateur pour lui afficher 
une page à l'aide de JPusblish et FreeMarker  :
1. L'utilisateur clique sur un lien hypertexte ou valide un formulaire. Le navigateur envoie alors une 
requête HTTP au serveur Ofbiz qui est interceptée par Tomcat et transmise au ControlServlet de 
l'application web correspondante.
2.   Le  ControlServlet  vérifie   si   l'URI  demandée   est  définie  par  l'application.  Le  cas  échéant,   il 
appelle le ou les événements associés à cette URI. Dans le cas contraire, il renvoie une erreur au 
navigateur web de l'utilisateur (Erreur HTTP 404 : page non trouvée).
3.   Si   l'événement   généré   doit   appeler   un   service,   il   vérifie   que   les   paramètres   de   la   requête 
correspondent aux attributs du service.
4. Si l'événement généré doit appeler un service, il convertit les paramètres de la requête sous forme 
textuelle en objets Java correspondant.
5. L'événement appelle un service ou un gestionnaire d'événements (méthode java statique).
6.   Le   service   ou   le   gestionnaire   d'événements   peuvent   effectuer   des   actions   sur   le   modèle   de 
données.
7. L'EntityEngine convertit ces actions en requêtes SQL pour le serveur de base de données.
8. Le service ou le gestionnaire d'événement renvoie le résultat de leur action. 
9. L'événement transmet ce résultat au ControlServlet.
10. À partir du résultat de l'événement, le ControlServlet sélectionne la vue à afficher et appelle le 
moteur de rendu adéquat.
11. À partir de la définition d'une vue, le moteur de rendu construit les différents sous­éléments de 
cette dernière.
12. Pour chaque sous­élément, il peut appeler des scripts BeanShell qui récupèrent et mettent en 
forme les données à afficher.
13. Pour chaque sous­élément, il appelle le moteur de template qui se charge de générer le code 
HTML correspondant.
14. Le moteur de rendu assemble les différents sous­éléments pour former une page web complète.
15. Le ControlServlet transmet la page générée au navigateur web de l'utilisateur.

2.3 Les différents modules

2.3.1 Content

Le module Content assure 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 peuvent être 
utilisés 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.

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

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

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

2.3.5 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...
 3. Le projet Néogia

Illustration 6: Logo Projet Néogia
                                                            
L'objectif du projet Néogia est d'être une sur­couche objet de l'ERP Ofbiz pour appliquer un 
développement   objet   et   s'affranchir   de   la   structure   de   la   base   de   données   ,   de   disposer   de 
composants  fonctionnels basés sur  une  modélisation UML et à  partir de ces  modèles UML  de 
générer automatiquement le plus de code possible.  Les outils de génération de code utilisés par le 
projet Néogia se basent sur une technologie mise au point par Code­Lutin, une société de services 
en   logiciels   libres   nantaise,   membre   du   réseau   Libre­Entreprise   et   spécialisée   dans   le 
développement applicatif en Java. Cette technologie, appelée LutinGenerators, permet à partir d'une 
modélisation   UML  stockée  dans   un fichier   XMI   de générer  n'importe  quel  type  de  fichier   dès 
l'instant qu'un générateur correspondant existe. L'utilisation de cette technologie est le fruit d'une 
collaboration entre Néréide et Code­Lutin dans le cadre d'un transfert de compétences au sein du 
réseau Libre­Entreprise. Cette génération de code est extrêmement utile car il permet de gagner un 
temps précieux en développement; en effet on estime à environ 70 % de fichier généré. 

Les fichiers générés sont les :
           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.
       
 Contexte de travail
1. Outils utilisés

OfbizNéogia étant un vaste projet en logiciel libre utilisant plusieurs technologies, les outils 
utilisés sont nombreux et variés et ceux­ci se veulent libres également . 
On retrouve les programmes suivants : 
– Eclipse WTP 
– Ant
– Apache
– iReport ( générateur de fichier Pdf )
– OpenJms ( implémentation open source de Sun Microsystems's Java Message Service )
– BeanShell ( éditeur de fichier bsh )
– FreeMarker ( éditeur de fichier ftl )
– Firefox ( avec le plugins Selenium­ide , Xpath checker et Web developer )
– Poséidon 

Eclipse n'est plus à présenter, il s'agit d'un formidable outil de développement qui intègre 
notamment CVS. En revanche, on connaît moins Eclipse WTP ( Work Tool Project ) qui est une 
extension d'Eclipse contenant des éditeurs intégrés pour HTML, Javascript, CSS, JSP, SQL, XML, 
DTD, XSD et  WSDL. Eclipse a été utilisé conjointement avec Ant ( utilitaire de compilation pour 
Java ). Étant donné qu'un utilisateur de OfbizNéogia n'a besoin que d'un navigateur internet pour 
tester le logiciel, Firefox a été d'une grande utilité pour pouvoir effectuer des tests. Il permet de 
disposer   de   plusieurs   plugins   indispensable   pour   des   développeurs   web:   Web   developper   afin 
d'afficher toutes les caractéristiques d'un formulaire ( son nom , la(les) requêtes à effectuer lors des 
actions sur le(s) boutons, les champs avec leur valeurs et leur clef y compris les champs cachés). 
Tout ceci a permis d'accélérer les phases de debuggage; Xpath checker quant à lui, il nous donne les 
identifiants   des   places   des   composants   des   différents   formulaires;   utilisé   conjointement   avec 
Sélénium­ide   pour   enregistrer   des   scénarios   de   déroulement.   Par   exemple   des   scénarios   de 
commande d'achat , ou des ordres de fabrication. Seul Poséidon n'est pas un logiciel libre et fait pâle 
figure dans cette liste. Il n'a malheureusement pas pu, pour le moment, être remplacé. Il est utilisé 
pour la modélisation UML de toutes les entités de l'ERP. Combiné à  LutinGenerators il permet de 
générer 70% du code du projet. 
 2. Méthode de travail
Afin que la communauté participant au développement du projet OfbizNéogia puisse suivre 
l'évolution de chacun, que les mainteneurs puissent intégrer le travail des différentes contributeurs; 
plusieurs outils sont indispensables : CVS, SourceForge qui héberge OfbizNéogia pour sa gestion 
des trackers, ainsi que les mailing­list qui permettent de suivre toutes les modifications par mail 
(mail   présentant   les   différences   entre   deux   versions   d'un   même   fichier).   Afin   de   préserver   la 
stabilité   du   projet,  on  utilise   la  notion  de  « Branche ».  Le  projet  OfbizNéogia  se  trouve  sur   la 
branche principale appelée Head. C'est sur celle­ci que se grefferons les développements. Lors du 
début d'un nouveau développement, chaque développeur crée une nouvelle branche, créée à partir 
d'un identifiant de tracker obtenu sur le site SourceForge; cette identifiant va permettre de retrouver 
le   but   du   développement,   la   personne   affectée   à   ce   développement,   son   statut   et   d'autres 
informations. Cette nouvelle branche va alors être indépendante du projet principale et ne perturbera 
pas ce dernier . Une fois toutes les modifications apportées à cette branche, et les test Selenium 
validés,   le développeur change alors le statut du tracker en TBT, cela signifie que ces  nouvelles 
modifications devront être testées par un des mainteneurs du projet pour être validées et intégrées au 
projet global. Une fois validées, une documentation fonctionnelle et / ou technique est écrite sur le 
Wiki du projet améliorant la compréhension des utilisateurs finaux ou obtenir des informations 
techniques pour de futures modifications ou utilisations et ainsi assurer un meilleur suivi.  

Afin de participer au développement du projet OfbizNéogia on peut distinguer 3 types de 
développements : les évolutifs ( ajout de nouvelles fonctionnalités), les correctifs ( résolution de 
bugs ), les spécifiques ( réponse au besoins des clients ). J’ai eu à réaliser de nombreuses tâches sur 
l’ERP, il n’est pas possible de toutes les présenter dans la limite des pages qui m'est imparti. J’ai 
donc choisi d’expliquer les deux principales. Un développement évolutif : La gestion des erreurs, un 
spécifique : les modèles de liste de transferts ( qui passa dans le projet principal étant donné l'atout 
majeur qu'apporta ce développement ) .
 Développement Réalisés
1. Gestion des erreurs

1.1  Présentation et Objectifs

Dans tout logiciel qui se respecte, il existe une gestion des erreurs. Dans OfbizNéogia cette 
gestion d'erreur est existante. Chaque erreur possède un statut qui est plus ou moins à tenir en 
compte;  certaines ne sont qu'à titre d'information et d'autre sont incontournables. Ces dernières 
déclenchent alors des rollback ( annulation de modification ) dans les bases. On peut distinguer 
deux   types   d'erreurs   :   les   erreurs   fonctionnelles   (   le   plus   souvent   déclenchées   par   des   erreurs 
humaines, par exemple une valeur manquante dans un formulaire) et les erreurs techniques ( Null 
pointer   exception   ,   GenericEntitityException   ).   Ces   dernières   sont   dues   à   des   erreurs   de 
programmations ou à un manque de sécurité. Si une telle erreur se produit c'est qu'une correction 
d'un code est à revoir, ce ne seront donc pas normalement des erreurs récurrentes. En revanche les 
erreurs fonctionnelles sont bien plus nombreuses, « l'erreur est humaine » et c'est ce type d'erreur 
qui devra être visible directement par l'utilisateur. Celles­ci sont visibles par l'utilisateur grâce des 
messages d'alerte qui s'affichent en rouge. 

Illustration 7: Exemple de déclenchement d'erreur

Malgré la visibilité de ces erreurs, il peut arriver que l'utilisateur n'en tienne rigueur ou qu'il ne s'en 
rende compte. Pour cette raison, l'idée d'enregistrer ces alertes et erreurs en bases est apparue. De 
cette   manière,   l'administrateur   peut   accéder   à   l'ensemble   des   erreurs   qui   a   été   engendrées.   Ce 
mécanisme était présent lors du commencement de mon travail, néanmoins il n'était pas utilisé car il 
n'existait   aucun   écran   fonctionnel   permettant   d'y   accéder.   Mon   travail   fut   donc   d'en   créer   un 
générique dans un premier temps, de façon à ce qu'il puisse être utilisé à n'importe quel endroit de 
l'application. Dans un second temps,  il m'a été demandé d'améliorer la sécurité  de cet écran afin de 
limiter l'accès seulement à des utilisateurs ayant certaines permissions . 

1.2  Analyse 

Cette tache fut la première que j'ai eu à développer pour le compte de l'ERP OfbizNéogia, ce 
fut   donc   une   réelle   confrontation   avec   le   fonctionnement   complet.   En   effet,   dès   ma   première 
approche j'ai dû analyser deux composants bien distincts : Party et Common . Cependant, malgré de 
grosse   différences,   un   grand   nombre   d'éléments   du   composant   party   dépend   du   composant 
Common. Par exemple la notion des décorateurs de Party hérite des décorateurs de Common. J'ai 
mis un bon moment avant de pouvoir appréhender ces processus, car les aller­retours entre les deux 
composants sont très nombreux et difficile à suivre pour une première approche. Néanmoins grâce à 
cette difficulté j'ai réussi à mieux percevoir la boucle des évènements de l'utilisation de l'ERP par la 
suite, car pour cette tâche j'ai du réaliser la plupart de ces évènements. Lors du commencement de 
cette tâche j'ai dû analyser l'existant. 
Il s'avéra alors que certaines entités était déjà présentes : 
­ ApplicationLog 
­ ApplicationLogCode
­ ApplicationLogLevel
­ ApplicationLogStatus

Ainsi ApplicationLog correspond à l'erreur. Chaque erreur contient un identifiant, un code d'erreur ( 
relié à ApplicationLogCode), un niveau d'erreur   ( relié à ApplicationLogLevel ),   un statut de 
lecture ( relié à ApplicationLogStatus ) . Une fois avoir étudié les fichiers java correspondants à ces 
différentes  entités, j'ai donc commencé  par créer  l'écran générique permettant de visualiser   ces 
erreurs; ce qui constituait la première partie de cette tâche. Dans un second temps, j'ai eu à créer un 
procédé   permettant   de   limiter   l'affichage   de   ces   erreurs.   Auparavant,   tout   utilisateur   avait   la 
possibilité de visionner toutes les erreurs générées. Il est désormais obligatoire de posséder certains 
droits, il a donc fallu modifier le diagramme UML de façon à avoir une relation entre les acteurs 
( en l'occurence la personne connectée ) et les erreurs générées. 
De cette nouvelle contrainte est apparues de nouvelles entités nécessaires à l'application de cette 
modification:
­ApplicationLogPerm ( Type de droit : lecture et modification ) 
­PartyAppLogPerm ( Class d'association entre Party ( les acteurs ) , ApplicationLogCode , 
ApplicationLogPerm )

Grâce à cette modification, pour pouvoir voir les erreurs ayant pour code X , il faut avoir une entrée 
dans la table PartyAppLogPerm correspondant à l'identifiant de l'utilisateur , le code X et le droit le 
lecture ; sans une telle entrée, aucune erreur ayant pour code X ne sera visible . 

Ce procédé représenta une réelle avancé pour la gestion des erreurs. Pourtant, il ne fût pas suffisant. 
Il   est   vrai   qu'un   très   grand   nombre   d'erreurs   peut   être   généré   ce   qui   aurait   pour   conséquence 
d'agrandir au fur et à mesure la taille de l'écran à afficher. Pour cette raison, la modification suivante 
fût de n'afficher que les erreurs non lues.  A ce stade, la gestion des erreurs au niveau technique était 
complète,   mais   au niveau fonctionnel  il  manquait  encore un  détail. Les  erreurs  ne  sont  que  la 
conséquence de procédés ayant mal fonctionnés, or   c'est justement ce que l'on souhaite éviter à 
l'avenir. Malheureusement à ce moment rien ne permettait de savoir quel était le procédé qui était en 
cause. Il a donc fallu revoir la modélisation pour pouvoir corriger ce problème. C'est ainsi qu'un 
attribut   (runId,   un   identifiant   généré   lors   de   lancement   d'un   processus   )   et   plusieurs   relations 
supplémentaires   furent   introduits   pour   pouvoir   tracer   à   la   source   le   problème;   donnant   lieu   au 
nouveau diagramme UML ci dessous :  

Illustration 8: Résultat du diagramme UML après modification

1.3  Résultat

L'écran de visualisation des erreurs  étant générique, il n'existe pas de visualisation de celui­
ci. En revanche un écran implémentant une partie de ces possibilités est accessible et pleinement 
opérationnel depuis le menu des acteurs, comme on peut le voir sur l'illustration 9. Lors de l'appel à 
l'écran   générique   on   peut   lui   passer   deux   paramètres   optionnels   (   runId   et   partyId)   qui   vont 
permettre de faire du tri respectivement sur le processus à afficher, et sur les permissions du partyId 
( l'acteur ) ; on peut bien sûr combiner les deux.  
 Illustration 9: Écran listant les erreurs enregistrer en base

Malgré les documentations créées pour l'utilisation de cette fonctionnalité, elle n'est utilisée qu'à 
deux endroits différents d'après ce que j'ai pu constater .

Contrairement   à   l'écran   de   visualisation   de   la   liste   d'erreur,   l'écran   d'édition   des   permissions 

( illustration 10 ) n'est pas générique, et ne possède pas les mêmes contraintes de sécurité pour son 
accès.  C'est  à   dire que tous les utilisateurs pourront visionner leur droit. En revanche un  autre 
mécanisme  de  sécurité   déjà   présent  dans   l'ERP   permet  d'activer  ou  de  désactiver   la  possibilité 
d'édition de ces permissions. Étant donné que pour faire la capture de l'illustration 10 , je m'étais 
connecté en administrateur il va de soit que l'édition était possible , dans le cas contraire le lien 
jaune ne sera pas visible, et la requête effectuée par ce lien ne serait pas non plus atteignable.

 
Illustration 10: Écran d'édition des permissions ( lecture / écriture ) sur les erreurs
 2. Liste de transferts

1.1  Présentation et Objectifs

Dans une grande société ou dans un groupe possédant des stocks importants de produits et 
différents lieux de stockage, il est régulier de devoir faire des transferts de produits d'une zone à une 
autre; et afin de procéder aux transfert et d'améliorer la traçabilité des produits et ainsi éviter qu'il ne 
se perde dans la nature ; des feuilles de suivis comportant des listes de transferts sont imprimées . 
Le mécanisme de création de liste de transferts était déjà existant , cependant la création d'une telle 
liste de transfert pouvait être longue et fastidieuse. En effet pour chaque transfert d'objet, l'utilisateur 
était obligé de le rajouter manuellement à la liste via cet écran :

Illustration 11: Écran d'ajout de transfert à une liste de transfert

 
Sur cet écran on peut remarquer que pour chaque objet que l'on veut transférer on doit remplir au 
moins 4 informations: la zone de provenance, la zone de destination, le produit, ainsi que la quantité 
désirée. Pour de courtes listes de transferts, le temps à créer ces listes est relativement rapide, mais 
dès  que  cette  liste dépasse une centaine d'objets, ce processus devient très rébarbatif. Or  il  est 
régulier que des listes de transfert soient très similaires dans le temps. A partir de cette constatation 
et afin d'améliorer le temps de création de ces listes; on m'a chargé de créer des modèles de liste de 
transferts, grâce à ces modèles la création de longue liste de transfert ne se ferait plus qu'en quelques 
instants (sous condition d'avoir créer le modèle au préalable). 

1.2  Analyse 

Comme   pour   le   procédé   de   gestion   des   erreurs,   j'ai   dû   reprendre   les   modélisations   et 
développement  déjà préexistant afin de les analyser. Mais contrairement à la gestion des erreurs qui 
n'était pas utilisé, la création de liste de transfert était déjà utilisé par plusieurs clients de l'ERP.  Je 
ne pouvais donc pas me permettre de modifier les processus déjà livrés, qui auraient entraîné une 
perte de temps et donc d'argent pour ses sociétés.  

Illustration 12: Relation de l'entité TransfertList avant la création de l'entité TransfertListModel
Dans le modèle UML on distingue clairement l'emplacement de TransfertList, il s'agit d'une liste 
contenant des StockItem (les produits à transférer ). J'ai eu à reproduire un mécanisme similaire lors 
de la création de mes modèles de listes de transfert ( TransfertListModel ). Ces derniers contenants 
des   TransfertUnitModel   (identifiant   de   produit   correspondant   aux   StockItem   +   quantité   ).   J'ai 
également introduit des mécanismes afin de choisir des emplacements sources et destination   par 
défaut au cas ou l'utilisateur aurait oublier de les  renseigner.   

Illustration 13: Relation après la création de TransfertListModel

L'avantage   de   ce   processus   est   indéniable   pour   la   création   de   liste   de   transferts   répétitives, 

néanmoins les transferts entre deux entrepôts peuvent être divers et variés , à cause de cela les 
modèles de liste de transfert n'ont aucune utilité dans certains cas ( liste demandé trop disparâtre par 
rapport aux modèles existants ). Or de très nombreux StockEventPlanned ( Transferts planifiés ) 
sont créés seul ( sans appartenir à une liste ). Par conséquent on se retrouve avec des milliers de 
transferts planifiés directement accessibles via un seul écran, et parmi ces milliers de transferts une 
bonne partie ont de grande chance d'être répétés. J'ai donc créé un processus qui permettrait de 
produire des listes à partir de transferts planifiés. Une simple sélection des éléments à reprendre 
(   seul   ceux   n'appartenant   pas   déjà   à   une   liste   sont   sélectionnables   )   et   un   clic   de   souris   sont 
désormais suffisant pour créer une liste de transfert, de plus, plus la base de données des transferts 
planifiés est grande plus l'on trouve tous les transferts que l'on a besoin et moins d'éditions de la 
liste de transferts sont nécessaires.  
 1.3  Résultat

Le processus d'amélioration à la création de liste de transfert est pleinement opérationnel et à 
été déployé chez le client demandeur. Pour l'utilisateur le procédé est très simple il lui suffit de 
renseigner les trois champs ( illustration 14). Le champ description correspond à une phrase qui lui 
permettra de reconnaître plus facilement le modèle par la suite ( voir illustration 16 )

Illustration 14: Création du modèle de la liste de transfert

Une fois le modèle de transfert crée il ne reste plus qu'à l'éditer ( Illustration 15 ) de façon à rajouter 
tous les transferts que l'on aura besoin. Sur la partie gauche de l'écran on dispose des données que 
l'on à renseigner lors de l'illustration 14. 

Illustration 15: Écran d'ajout de transfert à un modèle de liste de transfert 

Sur la partie droite, un écran nous invite à renseigner les données nécessaires à la création d'un 
nouveau   transfert.  Enfin  la  partie  inférieure  liste  les   transferts   déjà   présents.  Une  fois   que   l'on 
dispose   d'un modèle on peut passer à la création de la liste de transfert (Illustration 16). 

Illustration 16: Création de la liste de transfert
Sur cet écran on dispose de deux possibilités : laisser l'identifiant du modèle de liste de transfert 
vide, dans ce cas on utilise le processus standard; ou sélectionner un modèle. Ce choix rend les 
autres champs obligatoires ou non. Nous allons nous concentrer sur la deuxième possibilité. A partir 
de cet instant seule la date de réalisation est nécessaire; les magasins de destinations et d'origine s'il 
ne sont pas remplis le seront par ceux par défaut du modèle de liste de transferts. A partir du 
moment où l'utilisateur cliquera sur « Ajouter » le processus créera la liste de transfert avec tout les 
transferts contenu dans le modèle. 

Illustration 17: Liste des transfert planifiés ne faisant pas partie d'une liste

Une fois validée cette liste créera automatiquement  des transferts planifiés ayant un identifiant de 
liste indiquée dans la case « Préparation » de l'illustration 17. 

Pour créer une liste de transferts avec la deuxième nouvelle façon ( à partir des transferts planifiés ) , 
il suffit de sélectionner ceux désirés comme sur l'illustration 17 et de cliquer sur le bouton « Créer ». 
Une nouvelle liste de transferts sera alors produite et nous redirigera alors sur son écran d'édition.   

Bien que les manipulations utilisateurs se soient considérablement amoindris, il reste encore des 
lacunes pour la création de liste de transferts. Il n'est pas possible de créer des listes de transferts à 
partir de transferts planifiés appartenant déjà à des listes; or la plupart du temps les transferts de 
marchandise ne se font pas à l'unité, le coût de transports étant beaucoup trop grand. Par conséquent 
on risque de se retrouver dans le cas où aucun transferts planifiés ne sera sélectionnable, on ne 
pourra donc utiliser que la première solution. 
Un des autres points à améliorer est la vitesse de création de liste à partir d'un modèle, en effet lors 
de mes tests, je ne me suis basé que sur des courtes listes par manque de temps, or il s'avère que de 
longue liste pose quelque soucis de lenteur. 
 Conclusion
Durant le long de mon cursus universitaire, nous avons étudié de nombreux domaines, mais 
pour la plupart, seulement sur la partie théorique. Ce stage m'a permis de les voir sous une autre 
approche, la pratique. En effet j'ai dû utiliser mes connaissances en UML , en J2EE , en base de 
données, en réseau et même en Théorie des langages, chose à laquelle je ne m'attendais pas du tout ! 
Il est indéniable que sur le plan technique j'ai énormément gagné, je suis désormais plus confiant; 
mais   outre   la   technique,   j'ai   surtout   appris   sur   le   plan   fonctionnel   et   le   relationnel.   Un   ERP 
permettant d'améliorer la gestion de toute une entreprise, il va de soit que j'ai eu à comprendre de 
nombreux   domaines   tel   que   la   gestion   des   ressources   humaines,   la   gestion   des   stocks   et   de 
nombreux autres. Malgré ces six mois; je sais qu'il me reste une masse phénoménale d'informations 
à encore apprendre mais c'est la diversité de ce stage qui l'a rendu aussi attrayant . OfbizNéogia 
étant un logiciel libre, j'ai également pris conscience de l'importance des documentations. En effet il 
est   primordial   d'avoir   une   documentation   aussi   exhaustive   que   possible   afin   de   permettre 
l'amélioration ou la correction future. J'ai également eu la possibilité d'avoir des contacts directs 
avec des clients du projet Néogia ce qui m'a  également  permis d'entrevoir le plan relationnel et me 
rendre compte de l'importance de la communication entre tous les différents acteurs d'un tel projet. 
 Résumé
Mon stage de 2ème année de Master s’est déroulé au sein de l’entreprise Néréide, depuis début 
février 2006 jusqu'à fin septembre 2006, sous la responsabilité de Monsieur Peter Goron. Cette 
entreprise est une Société de Services en Logiciels Libres spécialisée dans l’intégration de l’ERP 
libre   Ofbiz.   Au   cours   de   ces   6   mois   de   stage,   j’ai   effectué   de   nombreuses   tâches   autour   du 
développement de cet ERP. J’ai notamment apporté des nouvelles fonctionnalités au module de 
gestion   des   stock  ou   la   gestion  des   ressources   humaines.  Ce   projet   m’a   permis   d’enrichir   mes 
connaissances   en   programmation   Java,   mais   surtout   mes   connaissances   fonctionnels   quasiment 
inexistante auparavant.

Mots clés : PGI, Logiciels Libres, JAVA, UML, Développement

Abstract
My internship took place within the company Néréide, since the beginning of April to the end of 
September, under the responsibility of Mister Peter Goron. This company only used Open Source 
software and is specialized in Ofbiz ERP integration. During those 6 months, I carried out a lot of 
different   work   around   the   development   of   this   ERP.   In   particular   I   carried   out   some   new 
fonctionnality in the component in charge of inventory control and human ressources . This project 
enabled  me to enrich my knowledge in Java development, but especially my functional knowledge 
which was almost inexistant before.

Key Words : ERP, Open­Source, JAVA, UML, Development
 Bibliographie

  ­ The Neogia Project. http://wiki.neogia.org/
­ Démonstration du projet Néogia http://demo.neogia.org/
­ The Open For Business Project. David E. Jones et Andy Zeneski. http://www.ofbiz.org/
­ Le réseau Libre­Entreprise. http://www.libre­entreprise.com/