Rapport Master v5

UNIVERSITE HASSAN II – MOHAMMEDIA

Faculté des Sciences Ben M’Sik

Département de Mathématiques et Informatique

Master Spécialisé Qualité de Logiciels

Rapport de stage de fin d’études

Etude, synchronisation et mise en place d’un progiciel de gestion intégrée

« Openbravo ERP »

Réalisé par : MOUKRIM Chouaib

Au sein de : ELECTRO PROTECT

Soutenu en septembre 2012 devant le jury :

Hamza MECHTALY : encadrant professionnel

Abderrahim TRAGHA : encadrant académique

Habib BENLAHMAR : examinateur

Année Universitaire 2011/2012

MOUKRIM Chouaib Septembre 2012


Dédicaces

À mon père et ma très chère mère qui m'a toujours donnée un magnifique modèle de

sacrifice, de persévérance et de bonne conduite. J'espère qu'elle trouvera dans ce travail

toute ma reconnaissance et tout mon amour.

À mon frère et mes sœurs en témoignage de ma profonde reconnaissance pour tout

d'amour et l’émotion qui m’ont donnés, que je puisse jamais les récompensés.

À toute ma famille.

À toutes mes amies, merci pour les moments inoubliables et votre soutien.

À ma ville natale Casablanca, à tout le peuple syrien et palestinien résistants, à tous les

musulmans à travers le monde.

Je dédie cette mémoire…


Remerciements

En premier lieu, je remercie Dieu, le Tout-Puissant pour ses faveurs et ses grâces, de m’avoir

donné le courage et la patience de mener ce travail.

Au terme de ce travail, je tiens à remercier Mr. ABDERRAHIM TRAGHA mon encadrant à la

faculté des sciences Ben M'sik, pour les conseils qu’il m’a prodigué, son judicieux encadrement ainsi que

son assistance.

Ainsi, j’exprime ma profonde gratitude et je tiens à remercier tout le personnel du Département

informatique, pour leur soutien et pour leur générosité considérable quant à l’offre de l’information.

Je tiens à exprimer mes gratitudes à mes encadrant à ElectroProtect et plut précisément l’équipe

du Perf Informatique pour leur soutien, et surtout Mr. MECHTALY HAMZA responsable du projet

RAWAJ qui m’a assisté tout au long de ce travail.

Mes remerciements s’adressent également à Mr. NABIL LAHLOU Directeur Général de la

société ElectroProtect de m'avoir accepté parmi son équipe, et de me donner l’opportunité de travailler

sur un sujet très intéressant.

Que messieurs les membres du jury trouvent ici l’expression de mes reconnaissances pour avoir

accepté de juger mon travail.

Que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement de ce travail

trouvent l’expression de mes remerciements les plus chaleureux.

MOUKRIM Chouaib


Résumé

Le sujet présenté consiste à l’Implémentation d’une Solution ERP Open Source. L’étude de cas

consiste à répondre au besoin du projet RAWAJ ayant une activité nationale.

Notre travaille consiste a l’adaptation et l’intégration de la solution ERP Open Source choisie,

pour ce projet. Cette société désire se doter d’une solution ERP afin d’augmenter son efficacité

de réduire ainsi ses frais de gestion, et la plus essentielle est l’édition des données comptables de

manière à pouvoir effectuer un suivi et une transmission à une entité comptable externe en

incluant les divers éléments nécessaire à l’établissement des divers documents comptables

réglementaires tels que Compte de Résultats, Bilan, Déclaration de TVA et autre.

Une investigation préliminaire sur les solutions ERP Open Source disponibles à été conduite et

«Openbravo » a retenu l’attention grâce au haut niveau de ces fonctionnalités.

Le noyau du sujet est l’implémentation d’une plateforme test de manière à valider la pertinence

de la solution et son ergonomie. Cette plateforme test devra être implémentée sous forme d’une

machine virtuelle Linux déployable sous VMWare. Donc notre rôle est de synchroniser les

données de l’ERP et de POS (Point Of Sales), adapte de la plateforme de test à d’autres normes

comptables et d’autres langues en particulier le français, l’anglais et l’arabe, le développer de tel

sort, il adopte les différents modèles tel que : les modèles de documents, les modèles de

rapports. Ce nouveau ERP sera menu d’une documentation complète pour le déploiement et

une documentation d’update et d’upgrade.


Sommaire

DEDICACES .................................................................................................... 3

REMERCIEMENTS ............................................................................................. 4

RESUME ........................................................................................................ 5

GLOSSAIRE .................................................................................................. 11

LISTE DES FIGURES ET DES TABLEAUX ................................................................ 12

INTRODUCTION ............................................................................................. 15

STRUCTURE DU MEMOIRE ................................................................................ 16

PARTIE 1 : ................................................................................................... 18

SYNTHESE BIBLIOGRAPHIQUE ...................................................................................................... 18

I. CONTEXTE GENERAL DU PROJET ........................................................ 20

1. ORGANISME D’ACCUEIL ......................................................................................................... 20

2. PRESENTATION DU PROJET RAWAJ IT ? ........................................................................................ 21

3. PRESENTATION DU SUJET ...................................................................................................... 21

4. APPROCHE PROPOSEE ......................................................................................................... 22

II. PLAN DE SELECTION DE L’ERP ........................................................... 24

1. ENTREPRISE RESOURCE PLANNING (ERP) ...................................................................................... 24

2. CARACTERISTIQUE GENERALE DES ERP ......................................................................................... 25

3. ARCHITECTURE MODULAIRE .................................................................................................... 26

4. LES PRINCIPAUX EDITEURS DES ERP ............................................................................................ 26

i. les principaux ERP propriétaires ........................................................................................ 26

ii. Les principaux ERP Open Source ........................................................................................ 27

5. ETUDE COMPARATIVE ENTRE OPEN SOURCE .................................................................................... 28

6. SYNTHESE ...................................................................................................................... 31


III. OPENBRAVO ERP ............................................................................ 33

1. PRESENTATION DE L’EDITEUR OPENBRAVO ..................................................................................... 33

A. Introduction ................................................................................................................ 33

B. Historique .................................................................................................................. 33

2. PRESENTATION DE LÈRP OPENBRAVO ........................................................................................ 33

Les caractéristiques de lÈRP Openbravo .................................................................................. 33

3. MODE DE FONCTIONNEMENT DE LÈRP OPENBRAVO ........................................................................... 34

L’Architecture ............................................................................................................. 34

A. L’Architecture Générale ................................................................................................. 34

B. L’Architecture détaillée : ................................................................................................ 35

4. LES MODULES DE LÈRP OPENBRAVO ......................................................................................... 37

5. LES TECHNOLOGIES UTILISEES POUR LE DEVELOPPEMENT ...................................................................... 41

6. SYNTHESE : .................................................................................................................... 42

PARTIE 2 : ................................................................................................... 43

DEVELOPPEMENT DU SYSTEME ..................................................................................................... 43

IV. ETUDE DES BESOINS ........................................................................ 45

1. ETUDE DE L’EXISTANT : ........................................................................................................ 45

A. Openbravo POS v2.30.2 (IPOS) .......................................................................................... 45

B. Lacunes du système actuel .............................................................................................. 46

C. Synthèse : .................................................................................................................. 46

2. ETUDE DES PROCESSUS ET CIRCULATION DE L’INFORMATION ................................................................... 47

A. Le processus de synchronisation POS ................................................................................... 48

B. Gestion des données principales: ....................................................................................... 48

C. Le processus de vente .................................................................................................... 49

D. Le processus stock :....................................................................................................... 50

E. Le processus achat : ...................................................................................................... 51

3. DIAGNOSTIC DE LÈTUDE DU SYSTEME ......................................................................................... 52


A. Diagnostic .................................................................................................................. 52

B. Solutions et suggestions pour améliorer le système existant ....................................................... 53

4. RETRO-CONCEPTION ........................................................................................................... 54

5. CONDUITE DU PROJET .......................................................................................................... 55

A. Processus de développement ............................................................................................ 55

B. Planning du projet ........................................................................................................ 57

V. ANALYSE & CONCEPTION DU NOUVEAU SYSTEME .................................... 59

INTRODUCTION ..................................................................................................................... 59

1. L’ANALYSE FONCTIONNELLE ................................................................................................... 59

A. Identification des acteurs du nouveau système ....................................................................... 59

B. Identification des cas d`utilisation ..................................................................................... 60

C. L’architecture fonctionnelle du système en pacquages : ............................................................ 61

D. Les diagrammes de cas d’utilisation .................................................................................... 62

Package : Gestion des données principales ......................................................................... 62

Package : Gestion des ventes ......................................................................................... 63

Package : Gestion des achats ......................................................................................... 63

Package : Comptabilité ................................................................................................ 64

Package : Synchronisation POS ........................................................................................ 65

E. Description des cas d`utilisation ........................................................................................ 65

i. Module : Gestion des données principale. ........................................................................... 65

ii. Module : Point de vente ............................................................................................. 68

iii. Module : Comptabilité ............................................................................................... 69

iv. Module : Gestion des ventes ........................................................................................ 70

v. Module : Gestion des achats .......................................................................................... 72

2. L’ANALYSE STATIQUE .......................................................................................................... 74

L’authentification ............................................................................................................. 74

Diagrammes de classe : Gestion des ventes ................................................................................ 76

Diagrammes de classe : Gestion d’achat ................................................................................... 77


Diagrammes de classe : Gestion des données principales ................................................................ 78

Diagrammes de classe : module synchronisation POS ..................................................................... 79

Diagrammes de classe : module comptabilité ............................................................................. 80

3. L’ANALYSE DYNAMIQUE : ...................................................................................................... 81

I. CONCEPTION DES DIAGRAMMES DE D’ACTIVITE ................................................................................. 81

Diagramme d’activité : Gestion des ventes ................................................................................ 81

Diagramme d’activité : Gestion des achats ................................................................................ 82

II. CONCEPTION DES DIAGRAMMES DE SEQUENCE .................................................................................. 83

PARTIE 3 : ................................................................................................... 87

LA REALISATION DU NOUVEAU SYSTEME ........................................................................................... 87

VI. LE PROCESSUS DE SYNCHRONISATION POS ............................................ 89

1. INTRODUCTION ................................................................................................................. 89

2. VUE D'ENSEMBLE DE L'INTEGRATION ........................................................................................... 89

3. LE PROCESSUS DE SYNCHRONISATION POS ..................................................................................... 90

A. La configuration d’Openbravo ERP...................................................................................... 90

La notion du système de modularité d’Openbravo ERP ............................................................ 90

Installation du module « Webservice pour la synchronisation d’Openbravo POS » ............................ 90

Vérification de l'installation du module ............................................................................. 91

Ajout du point de vente externe dans Openbravo erp : ........................................................... 92

Paramètres de la requête ............................................................................................. 93

Les Business Objects disponibles ..................................................................................... 93

B. La configuration d’Openbravo POS ..................................................................................... 94

Présentation et concept de PDI ....................................................................................... 94

Installation de Pentaho Data Integration ............................................................................ 95

Configurer Pentaho Data Integration ................................................................................. 96

C. Exécution de la synchronisation ......................................................................................... 97

La synchronisation principale ......................................................................................... 97


La Synchronisation des commandes .................................................................................. 98

VII. REALISATION ET MISE EN PLACE ........................................................101

1. ENVIRONNEMENT DE PROGRAMMATION ........................................................................................ 101

Choix de l’OpenBravo ....................................................................................................... 101

Description des serveurs .................................................................................................... 101

Choix du SGBD ................................................................................................................ 101

Choix du domaine dàpplication & l’IDE .................................................................................. 102

Choix du serveur dàpplication (Apache Tomcat) ....................................................................... 102

Choix du modèle de développement de làpplication .................................................................. 103

2. CONCEPTS DE BASE DE LA PLATEFORME « OPENBRAVO » ................................................................. 103

Model Driven Développement (MDD) ...................................................................................... 103

MVC Fondation Framework ................................................................................................. 104

3. IMPORTATION DES DONNEES ................................................................................................... 105

Format d’importation ....................................................................................................... 105

Importation des articles .................................................................................................... 106

Importation des commandes ............................................................................................... 107

4. PARAMETRAGE ................................................................................................................ 108

Paramétrage des taxes ...................................................................................................... 108

Paramétrage des catégories d’articles .................................................................................... 109

Paramétrage des tarifs ...................................................................................................... 109

Paramétrage des tiers ....................................................................................................... 110

5. MISE EN PLACE DE L’ERP ..................................................................................................... 111

Module achat ................................................................................................................. 112

Module vente ................................................................................................................. 115

Module comptabilité ......................................................................................................... 118

6. SECURITE INFORMATIQUE ..................................................................................................... 119

CONCLUSION ...............................................................................................120


BIBLIOGRAPHIE ............................................................................................121

WEBOGRAPHIE.............................................................................................121

ANNEXES ...................................................................................................122

ANNEXE 1 OPENBRAVO POS ................................................................................................... 122

ANNEXE 2 OPENBRAVO ERP ................................................................................................... 125

Glossaire

Dans ce glossaire nous citons quelques termes nécessaires pour la compréhension du rapport.

ERP: Entreprise Ressource Planning.

PFE: Projet de Fin d’Etude.

MVC : Modèle Vue Contrôleur

MDD: Model Driven Development

WAD: Wizard for Application Development

POS : Point de vente

CNC : Conseil National de la Comptabilité

IDE: Integrated Development Environment

JDBC: Java Data Base Connectivite

PGI : Progiciel de Gestion Intégré

PME : Petites et Moyennes Entreprises

SI : Système d’Information

SQL: Structured Query Language

UML: Unified Modeling Language

HTTP: Hyper Text Transfer Protocol

EJB : Entreprise JavaBean


Liste des figures et des tableaux

Liste des figures

Figure 1 Solution Proposée .................................................................................................................................... 22

Figure 2 : L’évolution des ERP .............................................................................................................................. 25

Figure 3 : l'Architecture générale d'Openbravo ................................................................................................... 34

Figure 4 : L’Environnement de développement de l'ERP Openbravo ........................................................... 36

Figure 5 : Les interactions entre les interfaces "Utilisateur-Openbravo" ........................................................ 37

Figure 6 : La structure modulaire de l'ERP Openbravo .................................................................................... 37

Figure 7 : Interface de vente OpenbravoPOS(*) .................................................................................................. 46

Figure 8 : l’architecture modulaire et l’interconnexion entre les modules....................................................... 47

Figure 9 : Schéma illustre le processus de vente en Action, et interactions avec les autres processus. ...... 49

Figure 10 : Schéma illustre le processus de commande de stock. .................................................................... 50

Figure 11 : Schéma illustre le processus d’achat .................................................................................................. 51

Figure 12 : Schéma illustre le processus de demande d’achat ........................................................................... 52

Figure 13 : Processus de Rétro-Conception ......................................................................................................... 54

Figure 14 : Processus 2TUP ................................................................................................................................... 56

Figure 15 : Planning des tâches .............................................................................................................................. 57

Figure 16 : les packages d'Openbravo erp ............................................................................................................ 61

Figure 17 : Gestion des données principales........................................................................................................ 62

Figure 18 : Gestion des ventes ............................................................................................................................... 63

Figure 19 : Gestion des achats................................................................................................................................ 64

Figure 20 : comptabilité ........................................................................................................................................... 64


Figure 21 Synchronisation de POS ........................................................................................................................ 65

Figure 22 : gestion des droits d'accès .................................................................................................................... 75

Figure 23 : les interfaces .......................................................................................................................................... 75

Figure 24 : Gestion des ventes ............................................................................................................................... 76

Figure 25 : Gestion d'achat ..................................................................................................................................... 77

Figure 26 : Gestion des données principales........................................................................................................ 78

Figure 27 : module synchronisation POS ............................................................................................................. 79

Figure 28 : comptabilité ........................................................................................................................................... 80

Figure 29 : Diagramme d’activité : « Gestion des ventes » ................................................................................ 82

Figure 30 : Diagramme d'activité : « gestion des achats » .................................................................................. 83

Figure 31 : Authentification .................................................................................................................................... 84

Figure 32 : Télécharger le catalogue des produits ............................................................................................... 85

Figure 33 : Synchroniser les ventes........................................................................................................................ 86

Figure 34 : page d'accueil du Web service. ........................................................................................................... 92

Figure 35 : point de vente externe dans Openbravo erp ................................................................................... 93

Figure 36 : Exécution du processus de synchronisation .................................................................................... 98

Figure 37 : importation de la commande.............................................................................................................. 99

Figure 38 : Description des serveurs ...................................................................................................................101

Figure 39 : le modèle MVC ...................................................................................................................................103

Figure 40 : Génération automatique de code WAD ........................................................................................104

Figure 41 : Format d’importation des données .................................................................................................106

Figure 42 : Importation d’un article ....................................................................................................................107

Figure 43 : Importation de commande ...............................................................................................................108

Figure 44 : Paramétrage de taxes .........................................................................................................................108


Figure 45 : Paramétrage de catégories produites ...............................................................................................109

Figure 46 : Paramétrage des tarifs ........................................................................................................................110

Figure 47 : Configuration des tiers ......................................................................................................................111

Figure 48 : création initial de la société ...............................................................................................................112

Figure 49 : Commande d'achat.............................................................................................................................113

Figure 50 : réception marchandise ......................................................................................................................114

Figure 51 : facture d'achat .....................................................................................................................................115

Figure 52 : commande vente ................................................................................................................................116

Figure 53 : Gestion d’expédition commande de vente .....................................................................................117

Figure 54 : Facture de vente .................................................................................................................................118

Figure 55 : comptabilité .........................................................................................................................................119

Figure 56 : Schéma Entité Relation d'Openbravo POS 2.30.2 .......................................................................124

Figure 57 : les interactions entres les couches d’Openbravo ..........................................................................126

Figure 58 : Data Access Layer d’Openbravo ERP 3MP11..............................................................................127

Figure 59 : web service REST du module synchronisation POS ...................................................................130

Liste des tableaux

Tableau 1 : les principaux modules de l'ERP ....................................................................................................... 26

Tableau 2 : Etude Comparative 1 (Caractéristiques générales) ......................................................................... 30

Tableau 3 : Etude Comparative 2 (Module fonctionnels) ................................................................................ 30

Tableau 4 : Etude Comparative 3 (Technologies) ............................................................................................... 30

Tableau 5 : Etude comparative entre les différents processus de développement ........................................ 55

Tableau 6 : les acteurs du système ......................................................................................................................... 60

Tableau 7 : Liste des cas d’utilisation .................................................................................................................... 61

Tableau 8 : Business Objects .................................................................................................................................. 94


Introduction

Aujourd’hui, toute entreprise est prête à investir des sommes considérables

dans l’implantation des technologies logicielles afin d’améliorer ses services

d’accroitre son agilité et sa flexibilité, de réduire les couts d’augmenter la

production et de faire face aux défis du marché en effet, vu la croissance des

activités au sein des entreprises, la tâche de gérer efficacement toutes ces

fonctions s’avère de plus en plus complexe et difficile.

Pour dépasser ces difficultés, une entreprise doit utiliser des outils optimisés et

adaptes facilitant les taches et offrant des fonctionnalités riches et utiles, parmi ces

outils nous trouvons les systèmes intègres de gestion tel que les ERP (Entreprise

Ressources Planning).

Ces ERP sont des outils de gestion et d’analyse permettant d’optimiser la

diffusion des information en interne, d’améliorer les processus de gestion et

d’automatiser les tâches ce qui augmente énormément la réactivité des entreprises

et leurs agilités fonctions s’avère de plus en plus complexe et difficile.


STRUCTURE DU MEMOIRE

Pour tenté de répondre aux notre objectifs de notre étude, nous avons organisé notre mémoire en trois parties :

Une partie théorique ou nous ferons une synthèse bibliographique des déférents concepts théoriques. Cette partie présente une étude détaillée sur le contexte de notre travail qui est l’ERP et plus précisément l’intégration des modules comptabilité, achat, ventes dans l’ERP Openbravo, cette partie est structuré en trois chapitres, qui présentent toutes l’information récoltée dans la littérature et nécessaire pour introduire la partie Pratique :

Le premier chapitre : Contexte général du projet Dans ce chapitre, nous allons présenter la société ELECTRO PROTECT, son partenariat avec le projet RAWAJ, en termes d’activités et d’organisation.

Le second chapitre : Plan de sélection de l’ERP Dans ce chapitre et après avoir présenté l’organisme d’accueil ainsi que les objectifs à atteindre on effectue un état de l’art lié au concept de l’ERP et ses déférents processus. Nous montrons grâce aux définitions que ce concept signifie. Ce chapitre rassemble les fondements importants des ERP.

Le troisième chapitre : OpenBravo ERP Décrit spécialement l`ERP open bravo, on a tente de faire une description sur toutes les façades de cet ERP (organisationnelle, technique….), dans ce chapitre, nous présentons dans un premier temps des notions élémentaires de base sur l’open source.

La deuxième partie présente le résonnement qu’on a mis en place pour la construction de notre système et en détaillera clairement notre étude. Pour accompagner tous ce qui a été fait, nous commencerons par les concepts les plus touchants à ces domaines de l’OpenBravo, pour arriver finalement à ce qui nous intéressent vraiment dans le cadre de l’élaboration de ce mémoire, cette partie regroupant les deux chapitres : présente notre proposition qui décrit l’aspect spécification et conception.

Le chapitre quatre : étude de l’existant Présente notre proposition qui décrit l’aspect spécification des modules gestion financière, vente, et achat. Ce chapitre traite la gestion de comptabilité en pratique telle qu’elle est appliquée au sein de l’ERP OpenBravo, elle est analysée en détail et diagnostique pour définir de façon détaillée les besoins de l’entreprise et aboutir à une ébauche solution. Ce chapitre traite aussi l’Openbravo POS : est un logiciel de point de ventes pour écrans tactiles qui est en cours de développement par ElectroProtect.

Le chapitre cinq: Analyse du nouveau système. Ce chapitre décrit une phase très importante qui comporte la conception détaillée du nouveau système en utilisant différents diagrammes et qui décrit le déroulement des processus.


La troisième partie présente la réalisation du nouveau système.

Le sixième chapitre: Le processus de synchronisation POS. Le but de cette intégration est de créer un système où Openbravo est le dépôt central des données. Openbravo POS à la capacité de gérer le catalogue des produits téléchargé depuis Openbravo et de télécharger les ventes créent par les activités de ventes d’Openbravo POS vers Openbravo, cette intégration a été développée avec des services web.

Le dernier chapitre : réalisation et mise en place. Décrit l’implantation et le déploiement. Ce dernier chapitre d’écrit aussi les taches accomplies en titre de réalisation. Lors de ce chapitre on présentera les différentes interfaces de notre application.

Enfin On terminera par une conclusion générale récapitulant le travail réalisé ainsi que des perspectives futures pour d’éventuelles améliorations.

Ces chapitres seront suivis d’annexes qui donneront des éclaircissements qui enlèveront l’ambiguïté qui pourrait entourer certaines notions et termes.

___________________________ Traduction : « un POS (Point Of Sales) est un logiciel de point de ventes pour écrans tactiles »


Partie 1 :

Synthèse Bibliographique

Chapitre :

Chapitre 1 : Contexte général du projet

Chapitre 2 : Plan de sélection de l’ERP

Chapitre 3 : OpenBravo ERP


Dans ce cadre, cette partie a pour objectif de situer notre projet dans son contexte général à savoir l’organisme d’accueil et le sujet traité. Dans la première section nous donnons une brève présentation de l organisme d accueil ELECTRO PROTECT et son partenariat celle de RAWAJ. Dans la deuxième section nous décrivons le sujet à traiter et les objectifs à atteindre.


I. CONTEXTE GENERAL DU PROJET

1. Organisme d’accueil

Créé en 1996 par Mr. Nabil LAHLOU, ElectroProtect est une société de service spécialisée dans les secteurs :

- Pesage électronique (Balance et ponts bascules)

- Solution d’informatisation du processus de vente

- Equipement informatique mobile

- Traçabilité

- Procès et équipements de valorisation (Machines à glaces, chambres froides…)

- Equipements de manutention (chariot et convoyeur) Située au cœur du Maroc à Casablanca, ElectroProtect dispose d'un axe géographiquement bien desservi (Agadir, Oujda, Laâyoune, Dakhla, Tanger) et propose des prestations de services informatiques de qualité avec une couverture nationale et des compétences décentralisées.

a. Fiche Signalétique

- Raison sociale : ElectroProtect SARL

- Capital : 2.000.000 DH

- Siège social : 22, rue Imam Al Boukhari 20370 Maarif Casablanca Maroc

- Effectif : plus de 70 personnes

- Date de création : 1996

- Site web : www.electroprotect.org

b. Départements

Les principaux départements du siège social sont les suivants :

- Département des ressources humaines

- Département finance et comptabilité

- Département production

- Département marketing

- Département informatique

Durant mon stage, j’ai intégré le département informatique qui se compose de deux entités :

- Réseaux et télécommunication : S’occupe de l’implémentation et paramétrage des systèmes et

réseaux en suivant les bonnes pratiques (Best Practices) du groupe.

- Développement informatique : C’est l’entité qui prend en charge le développement,

l’implémentation, et le suivi des projets informatiques.

http://www.electroprotect.org/


2. Présentation du projet Rawaj IT ?

Rawaj IT est un projet qui a été initié par le ministère du commerce et de l’industrie (département du commerce intérieur). Il vise à promouvoir la modernisation des outils d’encaissement et de gestion des commerces de proximité. Par une subvention de 12.000 DH TTC par installation, l’état envisage d’accompagner 20.000 commerces d’ici à fin 2015. Le MCI (Ministère de l’Industrie du Commerce) par l’intermédiaire de l’ANPME (Agence Nationale pour la Promotion de la Petite et Moyenne Entreprise) a lancé en Novembre 2011, un appel à manifestation d’intérêt. La société ELECTRO PROTECT a participé à cet appel d’offre, et a proposé un package articulé autours d’équipements et de solution soft (open source). Après de multiples présentations, et l’adaptation des équipements et de l’application aux exigences du CPS (Cahier des Prescriptions Spéciales), le MCI a qualifié 4 offres dont celle d’ELECTRO PROTECT. Le démarrage de ce projet, attend l’approbation du ministère des finances.

3. Présentation du sujet

Le but d’ELECTRO PROTECT est de continuer à fournir le meilleur service qui soit auprès de sa clientèle. Pour accomplir ses taches, ELECTRO PROTECT est toujours à la recherche de nouveaux produits et de nouvelles méthodes issues dédiées à des traitements spécifiques et les technologies de pointe. ELECTRO PROTECT s'est forgé à devenir un intégrateur de solutions et offre à ses clients des solutions clés en main.

ELECTRO PROTECT s’intéresse à une solution plus robuste et paramétrable qui garde trace de toutes ses actions commerciales. Dans ce contexte, notre objectif de travail se traduit par l’étude du système existant (Openbravo POS) au sein de l’organisme d’accueil afin d’aboutir à l’identification des fonctionnalités du système dans le but de la synchronisation avec ERP. La phase de spécification des besoins prend en compte les défaillances du système existant dans le but de détecter les nouveaux besoins au niveau de la mise en place de l’ERP open source.

Nous sommes donc appelées à mettre en place l’ERP au sein de cette entreprise, à développer quelques fonctionnalités pour satisfaire leurs besoins. L’importation de données reste la phase la plus importante dans le processus d’intégration de l’ERP. Ainsi, on utilise une méthode d’extraction ETL (Extraction, Transformation and Loading) destiné à extraire les données du système existant et à les transformer ensuite les charger dans l’entrepôt de données relatif à l’ERP.

Cette mise en place se focalise essentiellement sur l’étude comparative des ERP Open Source, la retro-conception, la personnalisation, le paramétrage ainsi que le développement des fonctionnalités spécifiques au sein des modules existants.

Nous allons donc s’intéresser principalement aux lacunes suivantes : • Améliorer le système actuel en évitant les circuits papier et en gardant trace des

différentes activités de l’entreprise ; • Faciliter l’activité commerciale de l’entreprise ;


• Etablir des analyses statistiques afin de suivre la tendance du produit pour chaque semestre.

Pour cela, la meilleure solution était d’implémenter un ERP multifonctions qui

vise à centraliser le système d’information et à automatiser ses activités tout en garantissant une sécurité de haut niveau.

4. Approche Proposée

Durant ce travail, nous allons suivre la démarche suivante :

La retro-conception de l’ERP qui touche les aspects courants les données manipulés d’un côté et les processus exécutés de l’autre côté ;

La collecte des besoins spécifiques du client ;

La classification des parties manquantes en deux types : le premier concerne le paramétrage des modules existant et le deuxième concerne le développement spécifique.

La présentation solution sera suivie tout au long de ce mémoire. La figure suivante illustre la succession des taches de la solution proposée.

Figure 1 Solution Proposée

Dans ce chapitre nous avons présenté ELECTRO PROTECT l’organisme d’accueil.

Dans la deuxième partie, nous avons décrit l’objectif du travail puis nous avons proposée

l’approche réponds au besoin de la société.


Le chapitre précédent de ce rapport a présenté le cadre du projet ainsi que l’objectif de notre travail. Dans ce chapitre nous introduisons les concepts clés que nous avons utilisées pour la réalisation de notre projet. Tout d’abord, nous commençons par introduire le concept de l’ERP. Ensuite, l’étude comparative entre les ERP Open source.


II. PLAN DE SELECTION DE L’ERP

1. Entreprise Resource Planning (ERP)

Dans cette section nous essayons de donner les différentes définitions de terme « ERP » mentionnées par plusieurs auteurs, chacun selon son domaine de recherche :

Dans [Caillaud J. 2004], l’auteur donne une définition qui concerne le concept ERP: «Un

système ERP, ou PGI (progiciel de gestion intégré), est un progiciel qui vise à couvrir et optimiser la totalité des fonctions et des processus de gestion d´une organisation. Il s´appuie sur une couche « standard » pour traiter les besoins génériques et répond aux besoins spécifiques par des paramétrages. Enfin, il peut fonctionner indifféremment sur plusieurs serveurs de données, systèmes d'exploitation et SGBD ».

[ERP : GOC] précise que « les ERP sont des progiciels conçus pour la gestion des entreprises, composés de plusieurs modules entourant les déférents secteurs fonctionnels comme : planification, fabrication, ventes, distribution, comptabilité financières, gestion des ressources humaines, gestion des projets, gestion des stocks, service et entretien, transport et e-business… ».

Dans [SUPINFO, 2008] cité par [Matthieu CIRELLI, 2008]: « Il est nécessaire de paramétrer de manière très poussée (rôle de l’intégrateur) chacun des modules fonctionnels pour répondre aux besoins spécifiques de l’entreprise ».

Synthèse

De ces définitions, nous retenons que ‘’l’ERP’’ est un progiciel à implanter qui permet de gérer l’ensemble des processus de l’entreprise en intégrant l’ensemble de ces processus et l’ensemble des fonctions de cette dernière comme : la gestion des ressources humaines, la gestion financière et comptable, la vente et la production, l’achat et l’approvisionnement tout en partageant une base de données commune. Appellations : Le terme « ERP » est une appellation qui n’est pas très bien contrôlée et n’existe pas une seule mais pas moins de sept dénominations : progiciel, progiciel intégré, progiciel applicatif, progiciel applicatif intégré, progiciel de gestion, progiciel de gestion intégré et le plus courant c’est l’ERP (entreprise ressource planning), connaissent un développement accéléré de puis le début des années 1990, ils ont été développés, à l’origine, par extension des systèmes de gestion de production de type MRP en fin des années 60 (voir : Figure 2).


Figure 2 : L’évolution des ERP

2. Caractéristique générale des ERP

Après avoir vu làpport des ERP aux organisations, il est important de citer leurs caractéristiques, on s’intéresse seulement à leurs caractéristiques générales:

Premièrement, lÈRP est un progiciel : c’est un ensemble de programmes conçus par un éditeur pour correspondre aux besoins de plusieurs types dèntreprise.

Un ERP est modulaire, ce nèst pas une construction monolithique, mais un ensemble de programmes (modules) séparables correspondant chacun a un processus de gestion.

Un ERP est intégré : ou les divers modules ne sont pas conçus de manière indépendante, ils peuvent échanger des informations selon des schémas prévus.

Un ERP vise à optimiser les processus de gestion : a la construction de lÈRP, le concepteur sàppuie sur des modèles de processus issus des meilleurs pratiques du secteur, de fait, l`éditeur de lÈRP obtient un ensemble de règles de gestion qui constitue un standards de fait pour un secteur donne.

LÈRP est un paramétrable : c’est un produit standardisé, est conçus a lòrigine pour satisfaire les besoins dèntreprises diverses. Cependant, il existe généralement des versions différentes par secteur dàctivité, encore par langue dùtilisation (options locales ou régionales).


3. Architecture modulaire

Nous avons donc vu que l’ERP est le plus performant et le plus avancé des logiciels de gestion du marché, et qu’il est composé de modules fonctionnels répondant à différents besoins dans divers secteurs de l’entreprise. Voici les principaux secteurs: Comptabilité et Finance Etablissement de tous types d’informations

comptables ou financières : Bilans, comptes de résultats, prévisions

Achat et Stock Gestion des achats et des stocks, établissement des factures …

Investissement Suivi des décisions d’investissements, gestion de la rentabilité, Nous avons donc vu que l’ERP est le progiciel de gestion intégré le plus performant et le plus avancé du marché, et qu’il est composé de modules fonctionnels répondant à différents besoins dans divers secteurs de l’entreprise.

Production Prévision et gestion de la production : Coûts de fabrication, gestion de la chaîne de gestion logistique, …

Pilotage d’entreprise Gestion de la productivité et de la compétitivité de l’entreprise.

Qualité Gestion des processus qualité

Ressources Humains GRH : Embauche, licenciements,

Vente Gestion des ventes : Prix, gestion des commandes, vente en ligne,…

Service après vente (SAV) Gestion du service après vente : Hotline, maintenance, gestion des techniciens…

Gestion Projets Regroupe les phases d’une gestion de projets : Suivi budgétaire, planning, …

Tableau 1 : les principaux modules de l'ERP

4. Les principaux éditeurs des ERP

On distingue deux sortes d'ERP : les ERP propriétaires édités par des sociétés qui impliquent l'achat d'une licence et les ERP Open-source qui sont « gratuits ».

i. les principaux ERP propriétaires

Parmi les principaux ERP propriétaires existent sur le marché, nous évoquerons ici quelques grands éditeurs :

SAP

Oracle-PeopleSoft


SAGE ADONIX

Microsoft

SSA Global

ii. Les principaux ERP Open Source

Avant de découvrir les principaux ERP Open Source, nous allons voir qu’est ce que l’Open Source et pourquoi choisir l’Open Source ERP Open Source

Un ERP Open Source est différent d’un logiciel ERP propriétaire, non pas en ce qui concerne les fonctionnalités disponible, mais sur tout ce qui touche à la licence du produit, ainsi qu’à la personnalisation de ce dernier.

Qu’est ce que Open Source ?

A la différence d’un logiciel propriétaire dont le cadre source est protégé, un logiciel Open Source doit proposer le libre téléchargement du code source. En effet, le principe de l’Open Source est de permettre à chacun de participer au développement du produit. Aussi, la ou les éditeurs de logiciels propriétaires ont un monopole total sur la personnalisation de ce dernier, un logiciel Open Source sera personnalisable par toute personne maitrisant le langage de programmation utilisé lors du développement. De nombreux logiciels open source ont su séduire les consommateurs du monde entier : Firefox, Open Office, Apache, Linux, Asterisk, etc.…

Pourquoi choisir l’open source ?

Ils permettent à des petites PME de disposer d'outils de gestion complets au meilleur

coût, leur apportant rapidement un vrai bénéfice en termes de compétitivité. Les seuls

coûts étant alors la formation des utilisateurs et le service éventuellement assuré par le

fournisseur du logiciel.

Ils s'adressent aussi à des PME de plus de 1000 salariés, que ce soit dans les secteurs

industriels, distribution ou services.

D'une manière générale, comme avec toute famille de produits Open Source on peut

s'attendre à des économies de licence en installant un ERP Open Source. En première

approche, l'ERP étant un progiciel complexe, les coûts d'intégration et de maintenance rendent

cette économie directe de licence modérée au regard du coût total de possession de l'ERP.

Ainsi, l'économie d'une licence propriétaire présenterait entre 25% et 50% du coût total de

possession (incluant intégration, support et maintenance) à périmètre équivalent.


Cependant, face aux dépenses marketing engagées par les ERP propriétaires, nous

savons qu'il n'est pas toujours facile de défendre un produit open source dont le coût certain est

annoncé de façon transparente d'entrée de jeu par les intégrateurs face à des produits

propriétaires qui font tout pour masquer leur coût réel à moyen terme en jouant sur les

promotions confidentielles, les packages, les licences, le nombre d'utilisateurs..

5. Etude comparative entre Open Source

La majorité des ERP Open Source existants et tout particulièrement Openbravo, Opiner,

Compiere, Adempiere, Apache OFBiz, Neogia, et ERP5. Dans une communauté très active,

Plusieurs ERP Open source apparaissent alors que d’autre sont délaissées. Nous avons étudiées

l’étude comparative d’Open source par rapport leurs caractéristiques générales. En fait, nous

intéressons sur la dynamique, technologie, notoriété, périmètre enfin la souplesse comme suite

Dynamique :

Il s’agit de la dynamique communautaire autour de la solution open source. Avec la qualité

technique, elle va déterminer directement la place de la solution dans le futur.

Technologie :

Investissements et communauté sont encore peu de chose devant la cohérence, la puissance

et l’adéquation

Avec les standards des modélisations au cœur d’un ERP. Ils sont considérés :

Respect de standards existants si possible ;

Degré de factorisation du code (La fiabilité et de prise en main) ;

Maturité et couverture des web services ;

Modularité de l’application (pattern Inversion Of Control si possible afin que

l’application soit composée d’un noyau minimal et de plugins qui sachent bien tenir

compte les uns des autres) ;

Absence de problème évident de performance.

Notoriété actuelle : Sont considérés :

Nombre et importances des références clients ;


Nombre et notoriété des intégrateurs existants (s’agit-il uniquement d’amateurs

isolés ou de vraies entreprises ? N’y a-t-il qu’un seul intégrateur derrière un projet ?) ;

Citations dans la presse professionnelle.

Périmètre :

Il s’agit du volume global des fonctionnalités. A noté qu’il faut aussi garder cette vision

globale des fonctionnalités. Beaucoup de ces dernières ne sont jamais utilisées ou devront être

modifiées. Le critère de ‘Souplesse’ est autrement plus impactant en termes de coût ou de

capacité à coût donné. D’autant que sur un ERP souple, l’ajout d’une fonctionnalité peut se

révéler relativement simple. On retiendra qu’Openbravo est meilleurs dans la gestion de

production en face de Compiere.

Souplesse :

La souplesse rejoint la technologie mais elle met spécifiquement l’accent sur la modularité

de la plateforme de l’ERP et sur l’efficacité du développement par des tierces parties. Il s’agit

aussi, d’un critère absolument déterminent dans le coût total de possession compte-tenu du fort

coût relatif des développements spécifiques. Ils sont considérés :

Facilité à modifier les structures de données pour ajouter ou altérer le stockage des

objets métier ;

Facilité à modifier les interfaces utilisateurs pour leur donner une bonne ergonomie

métier ;

Facilité à adapter les rapports (factures et autres).

Nous concluons au final, en synthétisant tout ceci avec les tableaux suivants :

Evaluation entre 0 (faible) et 5(excellent)


Caractéristiques générales

Dynamique Technologie Notoriété Périmètre Souplesse

Openbravo 5 3 4

4 3

Neogia 3 4 3 4 3

ERP5 2 4 4 4 4

Compiere 3 3 5 4 3

Tableau 2 : Etude Comparative 1 (Caractéristiques générales)

Modules fonctionnels :

Achats Ventes Compta CRM RH Paies Projet Web BI

Openbravo

4 4 3 2 0 0 0 5 4

Neoga

4 4 4 3 1 0 3 3 3

ERP5

4 4 5 4 4 4 ? 4 ?

Compiere 5 4 5 3 0 0 3 1 3

Tableau 3 : Etude Comparative 2 (Module fonctionnels)

Technologies

Langage de programmation Base de données Interface Client

Adempiere Java PostgreSQL, oracle Windows

Apache OFBiz Java, JavaScript, Prolog

Indépendant WEB

Openbravo Java, JavaScript, PL/SQL, XML, XHTML PostgreSQL, oracle WEB

Open ERP Pyhon PostgreSQL Windows

Compiere Java, JavaScript, PL/SQL

JDBC, Oracle Sybase

Web, Gnome, KDE, Win 32

Tableau 4 : Etude Comparative 3 (Technologies)


Nous concluons, au final, pour la réalisation de ce travail, nous avons choisi Openbravo. Il

se distingue avec son activité communautaire très importante et sa diversité de modules, Nous

notons qu’ici que les ERP tels que Openbravo a une très bonne capacité à être configurés

(notamment Workflow dans la gestion d’achat, rapports) et requièrent donc moins de

développement spécifique. Il est mieux paramétrable que ses concurrents dans le domaine

technologique et fonctionnel. Ainsi, il répond aux besoins d’entreprise telle que la gestion

commerciale ainsi que la gestion de la relation client (GRC/CRM).

6. Synthèse

Dans ce chapitre nous avons vu c’est quoi réellement les ERP. Ce chapitre sert donc à

présenter des principes et concept de base sur les ERP.

A travers de cette présentation, il importe de constater la place prépondérante que prennent

actuellement les ERP au cœur des différentes systèmes des organisations. Ou l’intérêt des ERP

semble être double. D’un part, nous pouvons retenir un indiscutable intérêt technique, du

principalement à l’intégration des données de l’entreprise qui permet un gain de temps et

d’argent considérable, d’autre part, ce sont des progiciels de gestion prêt à implanter couvrant

l’ensemble des processus de l’organisation de l’entreprise.

Dans la suite de ce document nous allons présenter l’étude auxquels on doit répondre Notre

application, nous allons procéder à une étude détaillée sur l’ERP OpenBravo.


Ce chapitre traite les caractéristiques, le mode de fonctionnement, les modules, les technologies utilisées pour le développement d’Openbravo ERP.


III. OPENBRAVO ERP

1. Présentation de l’éditeur Openbravo

A. Introduction

Openbravo est le nom d’une société espagnol qui édite une suit de logiciels et des progiciels de gestion intégrés appelé PGI, qui offre une proposition de « valeur unique – une valeur supérieure à un coût inférieur ». Le progiciel est pour les petites et moyennes entreprises qui sont à la recherche d'un système intégré pour gérer et adapté aux besoins de n'importe quelle entreprise.

B. Historique

L’éditeur espagnol Openbravo a présenté, le 1er mars 2001 un projet qui a été initie à catalogne en Espagne. La première partie de leur objectifs est développer et lancer sur le marché un logiciel dèntreprise standard qui intègre touts les processus métiers, la seconde partie de leur objectifs était que les outils et làrchitecture ont été développé afin dùne part de faciliter le développement et dàutre part de réduire le temps de maintenance du code existant. Entre 2001 et 2006 elle a développé un fork (logiciel basé sur la même base de données) de Compiere partiel web avec des fonctionnalités, notamment en gestion de production. En octobre 2007, elle a acquis le leader des logiciels Open Source de gestion des points de vente Open. Elle a apportée une solution full Web appelé Openbravo, avec l’ensemble des besoins fonctionnels d’une Entreprise totalement intégré.

2. Présentation de lÈRP openbravo

Nous avons noté dans les parties ci avant que les PME/PMI sont touchées par l’ère des ERP au début de ce siècle, du fait de la disponibilité dòffre intégrées adaptées a leurs tailles et a leurs budgets. Open bravo est la plateforme bout a bout d’une solution particulièrement conçue pour de petites et moyenne entreprise, en offrant une solution complète couvrant tous les aspects des affaires de lèntreprise (les achats, les ventes, la production, comptabilité, administration, …). Dans cette partie nous allons citer en premier lieux les caractéristiques de cet ERP, une vues fonctionnelles, et on terminera cette partie par une présentation technique d’Openbravo.

Les caractéristiques de lÈRP Openbravo

Openbravo apporte une solution full Web, avec l’ensemble des besoins fonctionnels d’une entreprise totalement intégré. IL nous permis:

de gérer facilement vos tâches quotidiennes.

d’automatiser des activités manuelles.

de rationaliser les processus métier.

d’accéder à vos informations de n’importe où et n’importe quand.

d’obtenir une pleine visibilité de votre business.


de réduire vos coûts opérationnels.

L’expérience des utilisateurs de l’ERP OpenBravo montre un retour sur investissement supérieur à 40% sur 3 ans. Il a été spécialement conçu pour aider les entreprises à optimiser leur performance.

Sa couverture fonctionnelle s’étend à l’ensemble des départements de l’entreprise.

Openbravo est un ERP Open Source libère semble être une de ces solutions Open Source appelées à devenir un hit. Couplé à un e-commerce, il pourrait devenir le compagnon idéal des petites et moyennes entreprises désirant se lancer dans le e-commerce.

Son progiciel intégré est une solution mature, fiable et à l’état de l’art technologique.

OpenBravo apporte une solution full Web, avec l’ensemble des besoins fonctionnels d’une entreprise totalement intégré.

3. Mode de fonctionnement de l`ERP Openbravo

L’ERP OpenBravo est une pure application web conçu sur des standards ouverts, autour d’une combinaison unique d’une architecture et d’une méthode de conception MVC, et de Framework Ingénierie dirigée par les modèles MDD, la plupart du code est généré automatiquement sur la base du modèle de dictionnaire de données par le moteur WAD,

L’Architecture

Pour mieux comprendre bien Openbravo on doit savoir son mode de fonctionnement, le bien étudier, comprendre et maîtriser. Après une étude approfondie on a aperçus deux sortes d’architectures fonctionnelles : une architecture générale et une architecture détaillé.

A. L’Architecture Générale

Figure 3 : l'Architecture générale d'Openbravo

Modèle Vue Contrôle MVC :


Est un modèle à trois couches pour isoler busines logique de l'interface utilisateur. L'utilisateur interagit via une interface utilisateur. Le contrôleur se charge ensuite de ces intrants et les dirige vers le modèle. Ce moteur exécute et recompile les fichiers de l’application (la figure3) à chaque fois que l'administrateur système modifie la configuration sur une demande utilisateur.

Il gère ses données et les affiche à l'utilisateur par l'intermédiaire de points de vue. (Un IDE, contient le code source et l'affiche via un éditeur de texte). C’est une gamme d’outils solides de programmation, sélectionnés soit à partir des meilleurs outils disponibles en Open Source sinon celles crée par Openbravo lui même. Ces outils favorisent le développement de l’application web MVC.

Model Driven Development MDD :

Un concept de logiciel qui dépend des métas donnés conservées dans un dictionnaire pour refléter le comportement du programme. Il en résulte en une grande diminution d’encodage manuel et moins de problèmes, permettant aux experts ayant peu d’expérience de codage de paramétrer le logiciel pour s’adapter aux besoins de chaque entreprise. Son rôle est de conserve le méta données qui décrivent chaque élément du logiciel et son comportement.

Wizard for Application Development (WAD):

Un moteur construit par Openbravo, produit automatiquement les applications binaires à partir du dictionnaire de données MDD et les fichiers produits par WAD sont conformes aux normes MVC.

B. L’Architecture détaillée :

L’architecture détaillée représente les différents environnements dans laquelle l’ERP Openbravo fonctionne, et on distingue :

i. Environnement de développement

Openbravo est une pure application web construite suivant le modèle MVC. La plupart du code est généré automatiquement sur la base du MDD par un moteur que nous appelons WAD. Le moteur exécute et recompile l'application à chaque fois que l'administrateur système modifie la configuration sur une demande utilisateur. Cela exécute une création et une recompilation des fichiers pour les différentes composantes du modèle MVC que montre la figure ci-dessous:


Figure 4 : L’Environnement de développement de l'ERP Openbravo

Modèle: xsql fichiers exécutables SQL

Vue: des fichiers HTML et XML de définition de la disposition des formulaires et de définition de la relation avec les données

Control: java servlets pour définir les actions à exécuter, gérer et générer le modèle de la vue.

ii. L’environnement d'exploitation

Openbravo s’exécute sur le dessus d'un groupe d'applications bien connus tiers:

Apache-Tomcat. On utilise Apache Tomcat comme le conteneur de servlet.

Apache-Ant. est utilisé pour automatiser un certains nombre de tâches telles que la construction du système de code source.

PostgreSQL (8.4) ou Oracle SE (10g-11g) comme système de gestion de la base de données SGBD.

iii. Environnement d'exécution

Pour exécuter le code, l'application doit être installée dans un serveur exécutant MVC et un groupe d'applications de tierce-partie que nous appelons l'environnement d'exécution. Les utilisateurs n'ont besoin de rien de plus qu'un navigateur Web standard de préférence, le navigateur Open Source FireFox ou Google chrome.


Figure 5 : Les interactions entre les interfaces "Utilisateur-Openbravo"

Le WAD et le MVC-FF Openbravo sont en grande partie du développement interne. Le MDD est une extension de celui de l’ERP Compiere, avec les modules d'origine (comme la production), et les ajustements nécessaires pour l'adapter à la construction aux normes comptables et aux processus de paiement.

Toutes ces applications peuvent être installées dans les deux OS (Windows et Linux).

4. Les modules de l`ERP Openbravo

Figure 6 : La structure modulaire de l'ERP Openbravo


Gestion des données

Openbravo ERP centralise les données dans une base de données unique pour l’ensemble des

applications permettant ainsi:

D’organiser et de regrouper toutes les données

clés (produits, composants, factures, clients,

fournisseurs, employés,…) efficacement,

De garantir la cohérence de celles-ci et éviter les

duplications,

De permettre le partage et la circulation fluide des

informations à travers tous les services de votre

entreprise

D'optimiser la maintenance du système

d’information avec un point central et unique de

gestion des données.

Gestion des achats

Openbravo gère le flux d’achat dans son intégralité

avec l'intégration en comptabilité. Les demandes

d’achats, les commandes d’achats, les réceptions des

marchandises et l’enregistrement des factures

s'effectuent de manière simple, fiable et efficace

avec, à tout moment, une visibilité comptable à jour.

Openbravo permet :

De garantir l’intégrité et l’homogénéité du

processus achat,

De minimiser l’introduction de données et

éviter ainsi les erreurs humaines,

D'apporter une navigation aisée à travers

différents documents d’un même processus

d’achat,

De connaître en temps réel l’état d’une

commande donnée

D'optimiser les demandes d’achat avec des

propositions d'achats automatisées


Gestion de la logistique

Le module logistique d'Openbravo prend en compte toute

la gestion des entrepôts avec les réceptions, les livraisons,

les inventaires, les stocks et les mouvements entre les

différents entrepôts:

L’inventaire à jour et correctement valorisé à tout

moment,

La localisation exacte du produit est accessible en

permanence,

Les échanges entre les différents entrepôts n'ont

jamais été aussi faciles.

De plus, Openbravo offre la possibilité de gérer des lots, des numéros de série et des dates de

péremption.

Gestion de la production

Openbravo dispose d’un module de gestion de production très abouti avec des fonctions de planification, BOMs, MRP, ordres de fabrication, coût de production, maintenance préventive, reporting des tâches,…

Ce module offre une vision globale de la structure de production de l'entreprise avec la construction de plans de production détaillés tenant compte des interdépendances.

Il utilise un module de planification pour gérer la disponibilité des différentes ressources (matériel, humain,..) avec une gestion de la maintenance performante.


Gestion des ventes

Les fonctionnalités de gestion des ventes ont été conçues

avec l’objectif de permettre un maximum de flexibilité et

d’adaptabilité dans leurs exécutions:

Liaison de tous les documents (commandes,

livraisons, factures,..) dans une commande,

Ne pas tenir compte des documents non utilisés

par l'entreprise,

Gérer des produits et des tarifs différents en

fonction du point de ventes, du client,

Garantir le tracking des processus de ventes,

Optimiser la gestion des commerciaux,

Optimiser le suivi et l’analyse des ventes

Pouvoir facilement s'intégrer avec un système de

prise de commandes (Palm, Pocket PC,...).

Gestion de projets

Le module de gestion de projet est orienté pour les entreprises

qui réalisent des projets et des prestations de service.

Il offre la possibilité de gérer les différentes phases et tâches,

les ressources, les budgets, les achats et les dépenses

spécifiques à chaque projet:

Une gestion efficace de tous types de projets

individuels

Une définition précise des services et des ressources

avec un contrôle de toutes les activités.

La gestion de projet peut-être liée à la gestion de production, la gestion des

achats voir la gestion de ventes si une facturation par phase ou par tâche est réalisable.


Gestion financière et comptable

Le module de comptabilité d'Openbravo agit comme un

collecteur de toutes les opérations effectuées par les autres

modules.

De nombreuses opérations comptables sont de ce fait

totalement automatisés, permettant de minimiser la saisie

manuelle de données, de limiter les erreurs et de favoriser

les tâches à forte valeur ajoutée ( reporting, simulation,

analyse,…).

Openbravo apporte toutes les fonctionnalités de

comptabilité générale, analytique et budgétaire avec un

minimum de réécriture comptable.

Openbravo POS

Plus qu'un module, Openbravo POS est une solution

complète de ventes et d'encaissement adaptée aux écrans

tactiles. Parfaitement intégré à Openbravo ERP, il peut être

utilisé en mode autonome ou en liaison permanente avec

celui-ci tout en garantissant une continuité du flux

d'encaissement.

5. Les technologies utilisées pour le développement

Openbravo utilise des technologies modernes mais testées pour respecter la performance rigoureuse et les besoins de classement des divers services des organisations, on a : Java et JavaScript, SQL(PostgreSQL) et PL/SQL(Oracle), XML * XHTML. Openbravo compte aussi sur un certain nombre de structures déjà connues d’Open Source pour un processus de développement plus efficace. Différents outils Open Source sont utilisés pour le développement de l’ERP Openbravo :


Java : Langage de développement orienté objet sur lequel se base le développement.

Eclipse : Plateforme de développement développé par IBM qu’Openbravo utilise pour développer les différents composants Java constituant Cortex.

PostgreSQL : Base de données relationnelle utilisée pour stocker les données. Toutes les données sont centralisées ce qui simplifie l'administration, la maintenance et la sauvegarde ce celles-ci.

Apache Tomcat : Serveur d'application dans lequel Cortex est exécuté. Il s'agit d'un conteneur de servlet développé par ‘’Apache Software Foundation’’ implémente les spécifications JavaServer Pages (JSP) et Java Servlet de Sun Microsystems.

Apache Web Server : Server Web développé par ‘’Apache Software Fondations’’ et souvent appelé Apache (ou Apache2), et à ne pas confondre avec Tomcat. Il s'occupe de rendre le contenu statique et / ou dynamique, il peut gérer le cache entre le serveur d'application et l'utilisateur ou compresser les données transférées entre le serveur et le client pour réduire les volumes transférés.

Apache Ant : Logiciel Open Source, écrit en Java et développé par « Apache Software Foundation » qui a pour but d'automatiser les processus de compilation d'applications en particulier le langage Java, son rôle consiste a : la compilation, la génération de pages HTML de document (Javadoc), la génération de rapports, l'exécution d'outils annexes (checkstyle, findbugs etc.), l'archivage sous forme distribuable (JAR etc.).

Mercurial : Système de gestion de versions décentralisé. Cet outil nous permet de gérer les versions et de garder l'historique des modifications des différents composants développés.

Hibernate : Hibernate est un Framework Open Source, fort et performant gérant la persistance des objets en base de données relationnelle. Hibernate nous permet de, développer des classes persistante suivant les principes de l’orienté objet, exprimer les requêtes dans son propre langage HQL portable du langage originale SQL.

6. Synthèse :

Nous avons analysé trois environnements de L’architecture détaillée dans la quelle l’ERP openbravo fonctionne, et représentant chacun un type d’outil. Pour la conception de contenu nous pouvons dire que :

Openbravo est un site Web entièrement fonctionnel et intégré. Le système est pour les petites et moyennes entreprises qui sont à la recherche d'un système intégré pour gérer leur entreprise.

Openbravo comprend toutes les fonctionnalités que vous attendez d'une solution ERP étendu.

Openbravo est distribué sous une licence Open Source. La licence garantit pas de frais d'utilisation, l'accès public au code source et la permission de le modifier librement.

Openbravo est basé sur une architecture révolutionnaire qui offre une meilleure façon de créer des applications logicielles.


Partie 2 :

Développement du Système

Chapitre :

Chapitre 4 : Etude des besoins

Chapitre 5 : Analyse & conception du nouveau système


ELECTRO PROTECT utilise actuellement comme un logiciel POS (Point Of Sales), nous présenterons l’étude de l’existant de l’entreprise. Nous focaliserons notre étude sur la fonction de la comptabilité ainsi que sur ces interconnexions avec les autres modules. A travers ce chapitre, notre analyse de la situation nous permettra de délimiter les frontières du sujet d’étude.


IV. ETUDE DES BESOINS

Afin de pouvoir proposer une restriction d’un système, répondant aux attentes de ses utilisateurs, il est important d’établir une étude préalable, qui servira à prendre connaissance du système actuel, ses spécificités, les postes existants, procédures de travail, et faire ressortir ses principaux fonctionnements et contraintes.

1. Etude de l’existant :

A. Openbravo POS v2.30.2 (IPOS)

Openbravo-POS, anciennement TinaPOS, solution libre de vente en caisse réputée mondialement, désormais passée sous le girond d'Openbravo. Openbravo-POS va notamment beaucoup plus loin qu'un simple client lourd puisqu'il embarque beaucoup de logique propre de gestion des stocks ce qui permet de gérer une boutique avec plus d’autonomie vis à vis de l'ERP central.

Openbravo POS est le leader des solutions de gestion et d'encaissement Open Source sur le marché de la distribution. Il a été conçu avec des logiciels Open Source à l’état de l’art technologique :

Développé en java

Utilisation de Swing pour une interface utilisateur sophistiquée

Base de données performante et Open Source utilisant l’interface standard JDBC

Utilisation d’outils puissants de rapports et graphiques : Jasper Reports et FreeChart

Support d’une large variété de matériels de points de vente

Processus de localisation facile à implémenter

Très simple à configurer fournissant une adaptation parfaite à tous types d’utilisateurs

de points de vente.


Figure 7 : Interface de vente OpenbravoPOS(*)

B. Lacunes du système actuel

Manque de la centralisation et l’historisation des données client.

Outils de gestion commerciale limitée qui ne garantit pas une cohérence de donnée parfaite ;

Perte de temps pour la recherche de l’information chez le client et besoin d’un système plus robuste ;

Perte d’information concernant le client ;

limitation des capacités poule traitement d’un grand nombre de données.

Manque des fonctions transversales nécessaire pour l’entreprise : finance et comptabilité

C. Synthèse :

Après analyse du système actuel de l’entreprise et la détection des différents anomalies qui peuvent s’y présenter ainsi que quelques défauts liées aux solutions commercialisées pour

___________________________ (*) OpenbravoPOS : les fonctionnalités d’IPOS sera détaillées dans l’annexe.


la gestion commerciale nous traitons plutôt les différentes notions liées à la gestion commerciale y compris la gestion des commandes d’achats et de ventes, la génération des rapports semestrielles de vente/achats ainsi que la comptabilité afin de détecter les besoins liées.

Dans cette logique, ce progiciel doit permettre une consolidation de l’information de gestion entre tous les départements de l’organisation tout en assurant l’intégration et l’adaptation des fonctionnalités suivantes :

Au niveau du siège central Au niveau des régions et Point de vent

Gestion des achats Gestion des stocks et approvisionnements Gestion des ventes Gestion financière (comptabilité)

Gestion des stocks et approvisionnements Gestion des ventes Gestion logistique (tournés)

Cette étude a pour objectif de recenser les différents postes de travail entrant affectant, Chaque filière de l’entreprise a ces spécificités de gestion, cela tout en précisant les tâches assurées par chaque poste et les différents documents manipulés ( information, entrées, sortie,…etc.). Le module comptabilité représente le maillon principal dans la chaine, ce qui nous mène à nous concentrer sur ce module lors de l’étude de l’existant (et l’étude des processus). Ainsi sur ces impacts et ces interactions, et les flux échangés avec les autres modules.

Figure 8 : l’architecture modulaire et l’interconnexion entre les modules.

2. Etude des processus et circulation de l’information

L’objectif de cette étude est la description de la circulation d’information entre les déférents modules et le module de la comptabilité ainsi que les tâches réalisées par ces derniers dans le système.


Le module comptabilité, est le module le plus convoité par les entreprises car il permet de gérer tout ce qui rapporte aux vente/achat, en particulier la gestion des stocks qui coutent chers aux entreprises. Ce module gérer les commandes clients et les livraisons, il assure aussi une liaison directe avec le compte de résultat et le système de production, il permet l’optimisation des processus de la gestion des stocks, des contrôles qualités et facture.

A. Le processus de synchronisation POS

Openbravo gère une seule base de données, intègre les processus parmi les différents départements, une interface cohérente pour chaque utilisateur, et des rapports homogènes affichant les données opérationnelles de toute l'organisation.

Toutefois il y a des domaines spécifiques d'une organisation qu'un système ERP ne peut résoudre. Par exemple, les systèmes POS (système de point de vente) comme Openbravo POS où des types d'utilisateurs spéciaux ou des supports de périphériques sont requis. L'utilisateur du système POS est un vendeur qui utilise un ERP d'une manière différente. L'interface doit être très facile à utiliser et doit fournir uniquement les informations spécifiques dont le vendeur a besoin. Ce vendeur a besoin d'utiliser le POS aussi vite que possible puisque son travail est de vendre et non pas de faire fonctionner le POS. Par exemple il n'a pas besoin d'une souris et d'un clavier, il préférera un écran tactile. De plus, le système POS a besoin de supporter beaucoup de périphériques tels que: les imprimantes tickets, les lecteurs de code-barres, les écrans d'affichage clients, les tiroirs caisses, les balances, etc.

Le but de l’intégration d’OpenBravo POS avec OpenBravo ERP est de créer un système où Openbravo est le dépôt central des données.

B. Gestion des données principales:

L’ensemble des informations collectées sur la clientèle et les fournisseurs, les produits est ensuite exploitée de manière à proposer des offres en correspondance avec les attentes. Il existe en général de nombreuses opérations que l’on voit apparaitre tous les mois. On peut distinguer ainsi les opérations relatifs au paramétrage initiale des informations sur les tiers (clients /fournisseurs) ainsi que les informations sur les produits et les familles de produit .On opte par conséquent à augmenter la marge réalisée avec chaque client ainsi que chaque fournisseur, à organiser les différentes gammes de produit associées avec les tiers et les groupes de tiers en question.

La gestion des données principales permet donc à l’entreprise de répondre à trois objectifs :

Augmenter la marge réalisée avec chaque client et chaque fournisseur ;

Distinguer les clients en les regroupant en groupes de tiers ;

Fournir une organisation hiérarchique des différentes gammes de produit;

Garantir la cohérence et robustesse des données parfaite avec une distinction entre les différents groupes de tiers ;

Possibilité de l’importation d’une grande quantité de donnée ;

Possibilité de configurer les listes de prix pour les différents produits.


C. Le processus de vente

Pour effectuer une opération de vente, il faut avoir les données de base : les articles, les clients et les fournisseurs, La gestion de vente permet à gérer toute les activités liées aux ventes à la clientèle, tels que les factures, prix, livraison, facturation et Reporting. Ci-dessous est décrit le processus de vente à connaitre afin d’effectuer, dans l’ordre, une commande de vente.

i. Schéma du processus de vente

Une vente peut être de plusieurs types : Commande d’un devis validé totalement ou partiellement Commande de vente normale avec certain accès, par exemple, fiche client, conditions

tarifaires, accès aux stocks, etc. Commande de vente de type marché (avec contrat).

Figure 9 : Schéma illustre le processus de vente en Action, et interactions avec les autres processus.

ii. Description du scénario de processus « vente »

Lorsque un document « commande de vente » est réservé, différents types de document peuvent être sélectionnés pour indiquer la destination du document.

La quantité de la commande reste en stock jusqu’à la livraison et l’envoie aura lieu.

Utilisé un document Les produits de retour (ristourne) lorsqu’un produit expédié est retourné, les quantités du commande sont négatives afin d’augmenter la taille des stocks.

Les devis sont aussi utilisés pour enregistrer les clients potentiels.

Commande prépayé et un type de commande de vente, la facture est envoyée et elle doit être payée avant que les marchandises seront expédiées.

À la fin de la « commande de vente », le système crée automatiquement une expédition et une facture. Le client reçoit la marchandise et la facture ensemble.


Donc suite à une vente, il faut suivre le processus de vente soit : livraison (déjà programmer par défaut dans l’ERP), facturation ou retour sur vente.

iii. La comptabilisation du processus de ventes :

Facture de vente : c'est la facture client, contient les articles vendus. L'entrée comptable à générer sera de créditer les comptes de ventes et taxes dues du montant total de la facture et le total des taxes de la facture respectivement, et de débiter le compte des réceptions d'argent.

Expédition marchandise: consiste à livrer les composants de la facture de vente (les lignes de la facture). La livraison correspondre a débité le COGS (produits consommés) et créditer le compte de l’actif du produit pour chaque ligne de facture de vente.

D. Le processus stock :

Lors d’une vente, un achat ou autre, il ya différents mouvements internes qui ont une influence sur le stock : Les entrées diverses, Les sorties diverses, Les inventaires et Les contrôles qualité.

i. Schéma du processus de stock

Voici une description schématique qui modélise le processus stock au sein de l’ERP :

Figure 10 : Schéma illustre le processus de commande de stock.

Dans l’ERP, les stocks sont gérer de manière automatique. Son paramétrage doit, par ailleurs, être défini en fonction de l’entreprise le type de gestion ainsi que les quantités minimales et maximales.

ii. Description du scénario de processus « stock»

Le demandeur exprime une demande pour des biens ou des services part une réquisition.

Le responsable des achats choisit le fournisseur le plus approprié en fonction des


objectifs d'achat et génère le bon de commande, soit manuellement, soit automatiquement en fonction de règles.

Réception Un document indique les produits ou marchandises reçues d'un fournisseur.

Lorsque le document de ‘’réception des marchandises’’ est généré et complété, la

quantité en stock du produit est mise à jour.

Les Factures d'achat reçus du Fournisseur seront vérifiées par rapport aux factures prévues.

E. Le processus achat :

Ce processus permet d’effectuer le paiement des biens nécessaires et les fournir. Elle est liée au stockage, la gestion financière, et de la gestion des projets et de services.

i. Schéma du processus d’achat

Figure 11 : Schéma illustre le processus d’achat

Le flux à suivre pour paramétrer un ERP concernant la commande d’achat est modélisé ci – Dessous. Celle-ci est créer âpres un appel d’offre et une demande d’achat, elle-même étant gérée par des règles de signature.


Figure 12 : Schéma illustre le processus de demande d’achat

Pour effectuer une commande d’achat, il faut connaitre les articles, les fournisseurs, la quantité à commander pour chaque article ainsi qu’un tarif de vente, par conséquent, les données de base à manipuler sont donc les fournisseurs, les articles, et les tarifs d’achat car ces derniers peuvent varier fonction de certains critères (période, quantité, etc.). Enfin, concernant le formulaire de la commande d’achat, il suit le même principe de paramétrage que pour la commande de vente ; paramétrage/achat/transaction achat, le paramétrer doit afficher ou non, donner la possibilité de modification ou non, etc.

ii. La comptabilisation des achats

Facture d’achat : après avoir créé une facture d’achat et la compléter. Le logiciel nous permettre de générer l’entrée comptable correspondante a cette facture. Grâce à la fonction POST (bouton), on génère une entrée comptable dans le registre. L’opération d’achat est une sortie d’argent pour l’entreprise, donc le compte qui représente la sortie d’argent sera prendra le montant total facture, et les deux comptes correspondants à la taxe aura la valeur du taxe et le reste pour le produit acheté (actif).

Réception marchandises : ce document prouve qu’une marchandise commandé et facturé a été livrée. Cette opération mise à jour notre stock du point de vue valeur et volume, et puis la représentation comptable sera, débiter le compte du produit reçus et créditer le compte des réceptions non facturé, et cela pour chaque ligne de la réception.

3. Diagnostic de l`étude du système

A. Diagnostic

Afin dàssurer un développement harmonieux du nouveau système, il importe de détecter lènsemble des causes éventuelles de disfonctionnements, en vue d`y remédier et dàpporter les améliorations nécessaires. Cette recherche sèffectue au moyen du diagnostic.


Le diagnostic conduira à mettre en évidence les anomalies et les points faible pour un déduire les corrections à apporter et la manière de le faire, les points forts pour mieux les utiliser et s`y appuyer. 1- Gestion des droits dàccès

Le système actuel, se base juste sur un super utilisateur avec la possibilité de change le rôle actuel vers plusieurs autres profiles.

2- défaut de structuration, importation des donnes du système La gestion des données de la comptabilité de lòpenbravo est fortement dépendante des fichiers Excel.

3- Importer la liste des organisations, produites, entrepôts de stockage : Openbravo nous donne la possibilité d’importer que les clients et les commandes.

B. Solutions et suggestions pour améliorer le système existant

Apres avoir effectue un diagnostic complet du système, nous sommes en mesure de proposer des solutions pour làméliorer et l’adapter pour satisfaire nos besoins.

1. Apporter certain changement au niveau informationnel et traitement de données: Openbravo propose une fonctionnalité d’importation et d’exportation des données, et en particulier les données de la comptabilité. Mais, cette méthode est limitée puisqu’elle propose un nombre limité de modèle. Donc, notre solution consiste à proposer d’autres modèles et fournir des outils de teste de cohérence des données à l’intérieur des modèles.

2. Rôle et privilèges : La Solution consiste à manager les rôles et privilèges ou on distingue les utilisateurs suivants : Super utilisateur , Administrateur système, Le simple utilisateur, Le planificateur, Utilisateur comptable, Comptable chef, Comptable assistant, Comptable contrôleur

3. Importer la liste des organisations, produites, entrepôts de stockage : Openbravo nous donne la possibilité d’importer les clients et les commandes, notre solution permettre aussi d’importer les organisations, les produits, les entrepôts de stockages, etc.…

4. Les fonctionnalités non implémentées : a. La traduction d’Openbravo et l’ajout d’une barre de langue. b. L’ajout d’un web services pour l’intégration d’Openbravo POS avec ERP

central. Ces fonctionnalité ne sont pas implémentées en Openbravo, et notre travail est les ajouter, et on fait notre possible de y arriver.


4. Rétro-Conception

La rétro-conception (Reverse Engineering) est l’activité qui consiste à étudier un système pour en déterminer les composants et leurs relations, dans le but de le représenter sous une autre forme ou dans un niveau supérieur d’abstraction.

Cette technique a pour objectifs :

Ré-documenter le système ;

Comprendre le fonctionnement d’un système pour bien l’utiliser ou le modifier ;

Identifier les fonctionnalités d’un système dans le but de la réutilisation ;

Créer un nouveau système ayant des fonctionnalités identique au système de départ sans violation de brevet.

Figure 13 : Processus de Rétro-Conception

Les composants du système sur lesquels on peut effectuer de la rétro- Conception sont :

L’architecture. Les données. Les traitements. Les Interfaces Utilisateurs.


5. Conduite du projet

A. Processus de développement

L’adéquation du projet au processus de développement peut largement affecter le sort d’un

projet informatique. Donc un mauvais choix du processus de développement peut conduire un

projet à l’échec. Afin de minimiser ce risque j’ai dressé un tableau comparatif des différents

processus utilisés dans le cadre de développement de projet informatique présenté dans le

Tableau 5.

Description Points Forts Points Faibles

RUP

Rational

Unified

Process

-Méthodologie entrée sur l’architecture et couplée aux diagrammes UML. - Cible des projets de + que 10 personnes.

-Itératif. -Spécifie le dialogue entre les différents intervenants du projet : les livrables, les plannings, les prototypes… - Propose des modèles de documents, et des canevas pour des projets types.

- Coûteux à personnaliser - Très axé processus, au détriment du développement

XP

eXtreme

Programmin

g

- Cible des projets de moins de 10 personnes.

- Itératif. - Simple à mettre en œuvre. - Fait une large place aux aspects techniques.

- Ne couvre pas les phases en amont et en aval au développement : - Assez flou dans sa mise en œuvre: quels intervenants, quels livrables ?

2TUP

Two Track

Unified

Process

-S'articule autour de l'architecture -Propose un cycle de développement en Y - Cible des projets de toutes tailles

- Itératif. - Fait une large place à la technologie et à la gestion du risque. - Définit les profils des intervenants, les livrables, les plannings, les prototypes

- Plutôt superficiel sur les phases situées en amont et en aval du développement. - Ne propose pas de documents types

Tableau 5 : Etude comparative entre les différents processus de développement

Nous constatons que toutes ces méthodologies proposent de travailler de façon itérative, que ce

soit au niveau des plannings, des spécifications, ou du développement.

Si l'itératif s'est imposé, c'est parce qu'il réduit la complexité de réalisation des phases en

travaillant par approches successives et incrémentales.

Il est alors possible de présenter rapidement aux utilisateurs des éléments de validation. De plus,

l'itératif permet une gestion efficace des risques, en abordant dès les premières itérations, les

points difficiles.


Ainsi, le choix de la technologie et l’architecture logicielle et applicative de mon futur système

est l’une des phases les plus importantes de mon projet vu le degré élevé de sa complexité

technique. Et puisque 2TUP fait une place à part entière à la technologie dans le processus de

développement, il semble le plus adapté pour mener à bien mon projet.

2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des aspects

fonctionnels. Illustré en figure 14, le processus en Y s'articule autour de 3 phases :

une branche technique

une branche fonctionnelle

une phase de réalisation

Figure 14 : Processus 2TUP

2TUP est un processus qui répond également à d’autres caractéristiques telles que:

Un processus incrémental piloté par les risques

Un processus piloté par les exigences des utilisateurs

Un processus de modélisation avec UML


B. Planning du projet

Durant mon stage, j’ai suivi le planning suivant :

Figure 15 : Planning des tâches


Ce chapitre présente une phase importante pour analyser et modéliser les besoins requis avant d’aborder la phase basé sur l’adaptation de l’ERP à nos besoins spécifiques. Cette phase comprend à son tour l’étude de l’existant par rapport au système qu’on utilise et qu’introduit par la suite les modifications à adopter en termes de fonctionnalités à ajouter ainsi que les scénarios relatifs.


V. ANALYSE & CONCEPTION DU NOUVEAU SYSTEME

Introduction

Lànalyse, pour sa part, met en place les fondements du système à réaliser en donnant une idée précisé et claire sur ce dernier qui délimité son étendue et notamment son fonctionnement. Cela se fait en présentant les déférents diagrammes (cas dùtilisation, classe, séquences,…), suivant la méthode de modélisation UML2.4, dont chacun résume et explique un aspect du nouveau système et sa marche. Lànalyse présente une abstraction total étant indépendante de toute technologie ou implémentation. Cette analyse se base sur les résultats de l`étude de lèxistant qui nous a permis d`évaluer le système actuel et dèn percevoir les besoins, et ainsi en d`écrire le bon comportement que doit avoir le nouveau système a réaliser pour ensuite proposer des alternatives et des solutions quìl comportera. L’analyse de notre système sera faite sur les trois axes suivants

o L’axe fonctionnel : qui décrit le savoir-faire (opération, règle de gestion). o L’axe statique : décrit la structure statique du système (objet, association). o L’axe dynamique : d’écrit la dynamique des objets du système.

1. L’analyse fonctionnelle

Les besoins sont le point de départ pour le développement du nouveau système, et qui doivent traduire ce quìl est possible dàpporter aux utilisateurs, en montrant les différentes fonctionnalités. Pour cette phase on a utilise le diagramme de cas dùtilisation pour bien collecter les besoins des utilisateurs du nouveau système, et pour cela nous avons procédé comme suit :

A. Lìdentification de tous les acteurs du nouveau système. B. Lìdentification des cas dùtilisation. C. Le regroupement des cas dùtilisation en package. D. La description de chaque cas dùtilisation

Cette phase nous permet de bien connaitre les utilisateurs du nouveau système, chacun avec son rôle, ainsi que ce que le nouveau système pourra leur apporter.

A. Identification des acteurs du nouveau système

Le tableau ci-après contient la description des acteurs du système :


Acteur Description

L’administrateur de l’ERP

Il a tout les droits au niveau de la gestion de la base de travail, durant la mise en œuvre de l’ERP Openbravo, l’administrateur du système est le consultant, et celui qui sera chargé de configurer l’application pour les nouveaux besoins, et de gérer les profils utilisateurs (la sécurité du système).

L’administrateur du POS

C’est un utilisateur final du POS, son principal rôle est la synchronisation des données

Commercial Son rôle consiste à fournir les paramètres nécessaires au bon fonctionnement du module et à l’intégrité des données résultants.

Le comptable il a le droit de manipuler les données comptable, initialisé la comptabilité, générer et créer des rapports comptables.

Tableau 6 : les acteurs du système

Remarque :

làdministrateur remplissent essentiellement le rôle de super utilisateur pour les décisions dùn certain degré. En bref. L’administrateur du système, est un utilisateur spécifique. Sur Openbravo, il doit être un super utilisateur.

B. Identification des cas dùtilisation

Les cas dùtilisation déterminent pour les fonctionnalités, les différentes acteurs concernes et leurs enchainement. Les éléments de base des cas dùtilisation sont : Acteur : est une entité externe qui interagit avec le système, les acteurs peuvent être de trois types :

Humaine : sont les utilisateurs du logiciel a travers lìnterface graphique du système.

Logiciel : ce sont les logiciels qui communiquent avec les logiciels à une interface.

Matériel : ce sont les robots ou les automates qui interagissent avec le système. Cas dùtilisation : ensemble dàction réalisées par le système, en réponse a une action dùn acteur

Le tableau ci-dessous contient une classification des cas d’utilisation par acteur :

Déclencheur Cas d’utilisation

Administrateur ERP Installation du système

Gestion des profils (Création et mise à jour)

Gestion de la société

Gestion des rôles


Administrateur POS effectuer une vente

synchronisation des ventes

gérer les produits

importer le catalogue des produits

Comptable création d’un calendrier budgétaire

Créer la comptabilité générale

Créer une catégorie fiscale

Mise à jour des partenaires commerciaux

Comptabilité de la facture d’achat

Payer la facture d’achat

Comptabilité de la facture vente

Créer un versement

Créer un règlement

Chef Commercial Gérer format d’importation

Gérer catégorie produit

Gérer inventaire physique

Importer les données (Produits, commandes, …)

Créer liste des prix

Gérer la planification facture

Créer un bon de commande

Créer la réception des marchandises

Créer la facture d’achat

Gérer les ventes

Créer une expédition de marchandises

Créer la facture vente

Tableau 7 : Liste des cas d’utilisation

C. L’architecture fonctionnelle du système en pacquages :

Le schéma ci-dessous représente les différents pacquages qui regroupent les fonctionnalités de notre système

Figure 16 : les packages d'Openbravo erp

dataimportfinancialmgmt

pos

procurement

salesshipping


D. Les diagrammes de cas d’utilisation

Package : Gestion des données principales

Figure 17 : Gestion des données principales

<<extends>>

<<include>>

<<include>>

<<extends>>

<<extends>>

<<extends>>

<<extends>>

<<extends>>

<<extends>>

<<extends>>

Administrateur Openbravo ERP

Gesti on soci été

Créer soci été

Gesti on uti l i sateur

Gesti on rôl e

Créer l e Form at d 'i m portati on

Créer une catégori e de produi t

Im porter l es produi ts

i m porter partenai re com m erci al

i m porter l es taxes

Créer L i ste des pri x

Créer une p l ani fi cati on facture

Modi fi er l es produi ts

Créer i nv entai re phy si que

i m porter l es com ptesChef commercial.

Im porter l es données

Ajouter produi ts

Suppri m er produi ts

Modi fi er soci été

suppri m er soci été


Package : Gestion des ventes

Figure 18 : Gestion des ventes

Package : Gestion des achats

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Créer une v ente

Créer expédi ti on de m archandi ses

Créer facture de v ente

Com ptab i l i té Facture de v ente

Créer règl em ent

Créer v ersem ent

Générer processus de factures

Chef Commercial

Comptable

S 'authenti fi er


Figure 19 : Gestion des achats

Package : Comptabilité

Figure 20 : comptabilité

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Chef Commercial

Créer un b on de com m ande

Créer l a récepti on des m archandi ses

Créer facture d 'achat

Com ptab i l i té de Facture d 'achat

Pay er l a facture d 'achatComptable

Authenti fi cati on

<<include>>

<<include>>

<<include>>

<<extends>>

Créer un cal endri er b udgétai re

Créer l a com ptab i l i té général e

Créer une catégori e fi scal e

S'authenti fi er

comptable

Mi se à jour des partenai res com m erci al es


Package : Synchronisation POS

Figure 21 Synchronisation de POS

E. Description des cas dùtilisation

Dans ce qui suit nous proposons une description textuelle des cas dùtilisation, cette dernière elle permet dàvoir une idée sur le fonctionnement de chaque cas dùtilisation. Et on va les structures comme suit :

Sommaire d’identification qui contient : o Le titre du cas d’utilisation. o Le but du cas d’utilisation. o Le résumé du cas d’utilisation.

Les différents enchainements du cas dùtilisation.

i. Module : Gestion des données principale.

Créer une société

Le but de cas d’utilisation : Testez le processus client Configuration initiale

<<extends>>

<<include>>

<<include>>

<<include>>

<<extends>>

<<include>>

Administrateur OpenBRAVO POSs 'authenti fi er au POS

gerer l es produi ts

Tél écharger l e catal ogue de produi t

Se connecter à OpenBR AVO ER P

Effectuer une v enteSy nchroni ser l es v entes


Les acteurs : administrateur Pré-conditions :

o L’utilisateur se connecte en tant que Openbravo/ openbravo

Enchainements o L’administrateur sélectionne la configuration de la société initiale puis remplit les

informations de la nouvelle société avec les droits d’accès. o Il Remplit les données dans : Configuration générale -> Société-> configuration

de la société initial

o Il valide en cliquant sur le bouton « créer »

Gestion des profils (Création et mise à jour)

Le but de cas d’utilisation : permettre à l’administrateur de créer, de modifier ou de supprimer un profil utilisateur.

Les acteurs : L’administrateur Pré-conditions :

o L’administrateur se connecte au système par authentification.

Enchainements(a) : ajout d’un nouveau profil o l’administrateur saisit le libellé du nouveau profil.

o Il coche le/les privilèges à lui accorder et valide cet Il valide en cliquant sur le

bouton « créer »

Enchainement(b) : modification d’un profil sélectionné

o L’administrateur sélectionne le profil à modifier. o Le système affiche les privilèges associés. o L’administrateur modifier le libellé et/ou les privilèges et valide.

Enchainement(c) : suppression d’un profil sélectionné

o L’administrateur sélectionne le profil à supprimer. o Le système affiche les privilèges associés. o L’administrateur valide sa suppression.

Gestion des rôles

Le but de cas d’utilisation : Création d'un rôle pour un utilisateur

Les acteurs : administrateur Pré-conditions :

o L’utilisateur se connecte en tant que Openbravo/ openbravo


Enchainements o L’administrateur sélectionne dans la configuration générale l’option sécurité o Il Remplit les données et plan de comptes


Gérer format d’importation

Le but de cas d’utilisation : Créer le chargeur de format d'importation pour entreprises partenaires, les produits et les taxes …

Les acteurs : Chef commercial Pré-conditions :

o L’utilisateur se connecte en tant que Chef commercial

Enchainements o Le Chef commercial sélectionne dans la configuration des données ce chemin

Importer des données-> Format Loader importation o Il Remplit les données. o Il valide en cliquant sur le bouton « créer »

Importation des données (Produits, Taxes, Partenaires commerciaux, commandes, …)

Le but de cas d’utilisation : Importer à partir du POS les derniers changements des (Produits, Taxes, …).



Enchainements o Le Chef commercial sélectionne dans la configuration des données ce chemin

Importer des données-> Importer (Produits, taxes, commandes,…) o Il clique sur traiter l’importation pour valider. o Il valide en cliquant sur le bouton « importer »

Gérer la planification facture

Le but de cas d’utilisation : Créer un calendrier de facturation à utiliser dans la génération des factures



Enchainements


o Le Chef commercial ouvre la page dans ce chemin Gestion des données principales-> Configuration du partenaire commercial -> Facture calendrier

o Il clique sur nouveau et remplit les champs nécessaires. o Il valide en cliquant sur le bouton « OK »

ii. Module : Point de vente

Synchronisation des ventes

Le but de cas d’utilisation : Envoyer les commandes qui ont été faites par l’utilisateur du POS

Les acteurs : administrateur POS Pré-conditions :

o L’utilisateur se connecte à Openbravo pos o L’utilisateur doit se connecter aussi à Openbravo erp

Enchainements o L’administrateur POS ouvre la page de Pentaho Data Integration et doit

configurer le fichier kattle.properties et remplir les paramètres de connexion de l’ERP

o L’administrateur lance la synchronisation avec l’outil PDI pour envoyer les données à l’ERP centrale.

Post-conditions : o La synchronisation des ventes devra se terminer

Importer le catalogue des produits

Le but de cas d’utilisation : importer les données à partir des tables d’Openbravo ERP

Les acteurs : administrateur POS Pré-conditions :

o L’utilisateur se connecte à Openbravo pos o L’utilisateur doit se connecter aussi à Openbravo erp

Enchainements o L’administrateur POS ouvre la page de Pentaho Data Integration et doit

configurer le fichier kattle.properties et remplir les paramètres de connexion de l’ERP

o L’administrateur lance la synchronisation avec l’outil PDI pour envoyer les données à l’ERP centrale.


o Il valide en cliquant sur le bouton « créer » Post-conditions :

o La synchronisation d’importation devra se terminer

iii. Module : Comptabilité

Création d’un calendrier budgétaire

Le but de cas d’utilisation : Le comptable crée des périodes et les documente.

Les acteurs : Comptable Pré-conditions :

o Le comptable se connecte à Openbravo erp

Enchainements o Le comptable ouvre la page dans ce chemin Gestion financière-> Comptabilité-

> Configuration-> Fiscal calendrier> Année o Il Clique sur le bouton créer périodes o Il Déplace à chaque période et cliquez sur le bouton Ouvrir / Fermer tout


Création de la comptabilité générale

Le but de cas d’utilisation : Le comptable crée la comptabilité générale pour tester d'autres fonctions.


o Le comptable doit se connecter à Openbravo erp

Enchainements o Le comptable ouvre la page dans ce chemin Gestion financière-> Comptabilité-

> Configuration-> comptabilité générale o Il clique sur Nouveau dans la comptabilité générale. o Il accède à l'onglet Comptabilité. o Il crée un nouveau record. o Il sélectionne un compte de dépenses à la fois pour débit et de crédit o Il valide en cliquant sur le bouton « créer »

Mise à jour des partenaires commerciaux


Le but de cas d’utilisation : Le comptable crée une catégorie fiscale du partenaire commerciale pour faire des impôts dans les documents transactionnels. En outre il ajouter une nouvelle catégorie de clientèle.



Enchainements o Le comptable ouvre la page dans ce chemin Gestion des données principales->

Partenaire commercial o Il sélectionne un client o A l'intérieur de l’onglet Client, il sélectionne une Catégorie fiscale. o Il valide en cliquant sur le bouton «valider»

iv. Module : Gestion des ventes

Créer une vente

Le but de cas d’utilisation : son objectif est la création d’une vente à utiliser lors de l'expédition des marchandises.



Enchainements o Le Chef commercial ouvre la page dans ce chemin Gestion de vente ->

Transaction-> vente o Il remplit tout les champs : TVA, produit,… o Il valide en cliquant sur le bouton « OK »

Créer une expédition de marchandises

Le but de cas d’utilisation : son objectif est la création d’un envoi des marchandises d'une vente du client



Enchainements


o Le Chef commercial ouvre la page dans ce chemin Gestion de vente -> Transaction-> Créer expéditions de vente

o Il sélectionne la commande client et cliquez sur « processus » o Il valide en cliquant sur le bouton « OK »

Post-conditions : o L'ordre de vente doit être disparaître

Créer une facture de vente

Le but de cas d’utilisation : son objectif est la création d’une facture de vente du client



Enchainements o Le Chef commercial ouvre la page dans ce chemin Gestion de vente ->

Transaction-> facture de vente o Il remplit tout les champs : TVA, produit,… o Il valide en cliquant sur le bouton « OK »

Comptabilité de la facture vente

Le but de cas d’utilisation : Comptabiliser toutes les achats qui ont été faites.


o Le comptable doit se connecter à Openbravo erp o Le bouton "Non publié" doit être apparu

Enchainements o Le comptable ouvre la page dans ce chemin Gestion des ventes-> Transactions-

> Facture de vente o Il clique sur les ventes "Non publié" o Il Vérifie si l'entrée du journal créé est correcte o Il valide

Créer un règlement

Le but de cas d’utilisation : Traiter toutes les règlements de ventes




Enchainements o Le comptable ouvre la page dans ce chemin Gestion financière-> Transactions-

> règlement o Il remplit les champs obligatoires du nouveau règlement. o Il crée un nouveau paiement et valide (et sélectionne un client comme partenaire

commercial) o Il valide en cliquant sur valider

Créer un versement

Le but de cas d’utilisation : Le comptable peut créer des remises avec des versements.



Enchainements o Le comptable ouvre la page dans ce chemin Gestion financière-> Créances et

dettes-> Transactions-> Remise o Il remplit les champs obligatoires du nouveau versement. o Il clique sur continue o Il valide en cliquant sur valider

v. Module : Gestion des achats

Créer un bon de commande

Le but de cas d’utilisation : Création d’une commande à utiliser lors de la réception des produits



Enchainements o Le Chef commercial ouvre la page dans ce chemin Gestion de

l'approvisionnement -> Transaction-> Bon de commande o Il clique sur nouveau et remplit les champs nécessaires. o Il valide en cliquant sur le bouton « OK »


Créer une réception des marchandises

Le but de cas d’utilisation : son objectif est la création de biens pour la réception




l'approvisionnement -> Transaction-> Entrée de marchandises o Il crée un nouveau vendeur : il remplit les champs, sélectionne un partenaire

commercial et valide. o Il sélectionne le bon de commande o Il sélectionne une position d’entrepôt o Il sélectionne la ligne de commande o Il valide en cliquant sur le bouton « OK »

Créer une facture d'achat

Le but de cas d’utilisation : son objectif est la création d’une facture d’achat




l'approvisionnement -> Transaction-> facture d’achat o Il remplit tout les champs : TVA, vendeur ,… o Il valide en cliquant sur le bouton « OK »

Comptabilité de la facture d’achat

Le but de cas d’utilisation : Comptabiliser toutes les achats qui ont été faites



Enchainements


o Le comptable ouvre la page dans ce chemin Gestion de l'approvisionnement de -> Opérations-> facture d’achat

o Il clique sur "Non Publié" pour être en mode d'édition, puis il clique sur OK o Il vérifie si le journal créé est correct et valide.

Payer la facture d’achat

Le but de cas d’utilisation : Le comptable crée le journal de caisse en utilisant ce paiement



Enchainements o Le comptable ouvre la page dans ce chemin Gestion financière-> Créances et

Paiements> Transactions-> Cash revue o Il clique sur Nouveau, remplisse les champs obligatoires et sauvegarde o Il accède à l'onglet Lignes o Il clique sur Nouveau type de trésorerie et sélectionne: dette-paiement o Il clique sur l'icône de paiement, remplit les champs obligatoires et valide o Il clique sur "Non publié" o Il vérifie si l'entrée du journal est correcte et valide

2. L’analyse statique

Cette phase doit déterminer le modèle statique du nouveau système qui à déterminer les objets, leurs attributs et leurs méthodes ainsi que les relations qui relient ces objets.

L’objectif de cette étape est de produire le diagramme de classes qui servira pour l’implémentation. Nous décrirons les relations entre les classes de modèle de domaine, en précisant les attributs et les opérations privées de différentes classes.

L’authentification


Figure 22 : gestion des droits d'accès

Remarque : Tous les diagrammes de classes qui seront présentés par la suite, implémentent les interfaces suivantes :

Figure 23 : les interfaces

error

conn

AuthenticationData

*-+

log4jInitRecordNumberadUserId

: Logger: String: String

= Logger.getLogger(AuthenticationData.class) = "0"

+

+

+

<<Getter>>

<<Implement>>

getInitRecordNumber ()

getField (String fieldName)

getUserId (ConnectionProvider connectionProvider, String user)

FieldProvider

(<ModeleOrienteObjet_1>)

+ getField (String fieldName) : String

AuthenticationException

--

serialVersionUIDerror

: long: OBError

= 1L

+

+

+

+

<<Constructor>>

<<Constructor>>

<<Constructor>>

AuthenticationException (String msg)

AuthenticationException (String msg, Throwable cause)

AuthenticationException (String msg, OBError error)

getOBError () : OBError

OBException


- serialVersionUID : long = 1L

+

+

+

+

#

<<Constructor>>

<<Constructor>>

<<Constructor>>

<<Constructor>>

OBException ()

OBException (String message, Throwable cause)

OBException (String message)

OBException (Throwable cause)

getLogger ()

AuthenticationManager{abstract}

-------####

log4jDEFAULT_AUTH_CLASSSUCCESS_SESSION_STANDARDSUCCESS_SESSION_WEB_SERVICEREJECTED_SESSION_WEB_SERVICESUCCESS_SESSION_CONNECTORFAILED_SESSIONconndefaultServletUrllocalAdressusername

: Logger: String: String: String: String: String: String: ConnectionProvider: String: String: String

+

+

+

#

<<Constructor>>

<<Constructor>>

getAuthenticationManager (HttpServlet s)

AuthenticationManager ()

AuthenticationManager (HttpServlet s)

bdErrorAjax (HttpServletResponse response, String strType, String strTitle, String strText)...

OBError


----

typetitlemessageconnectionAvailable

: String: String: String: boolean

+

+

+

<<Constructor>> OBError ()

setType (String _data)

getType ()

...

ConnectionProvider


+

+

+

+

+

+

+

+

+

+

getConnection ()

getRDBMS ()

getTransactionConnection ()

releaseCommitConnection (Connection conn)

releaseRollbackConnection (Connection conn)

getPreparedStatement (String poolName, String strSql)

getPreparedStatement (String strSql)

getPreparedStatement (Connection conn, String strSql)

releasePreparedStatement (PreparedStatement preparedStatement)

getStatement (String poolName)...

: Connection

: String

: Connection

: void

: void

: PreparedStatement

: PreparedStatement

: PreparedStatement

: void

: Statement

Traceable

(<Openbravo erp>)

+

+

+

+

+

+

+

+

getCreatedBy ()

setCreatedBy (User user)

getCreationDate ()

setCreationDate (Date date)

getUpdatedBy ()

setUpdatedBy (User user)

getUpdated ()

setUpdated (Date date)

: User

: void

: Date

: void

: User

: void

: Date

: void

ClientEnabled

(<Openbravo erp>)

+

+

getClient ()

setClient (Client client)

: Client

: void

OrganizationEnabled

(<Openbravo erp>)

+ getOrganization ()

...

: Organization

ActiveEnabled

(<Openbravo erp>)

+

+

isActive ()

setActive (Boolean active)

: Boolean

: void


Diagrammes de classe : Gestion des ventes

Figure 24 : Gestion des ventes

Commission

-+++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_ACTIVEPROPERTY_CREATIONDATE...

: long: String: String: String: String: String: String: String

BaseOBObject

(<Openbravo>){abstract}

---------

logserialVersionUIDmodelnewOBObjectdataisDerivedReadableallowReaddataTrlhasLookedForTrl...

: org.apache.log4j.Logger: long: Entity: boolean: Object[]: Boolean: boolean: BaseOBObject: boolean

CommissionAmount

-+++++++



CommissionDetail

-++++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_ACTIVEPROPERTY_CREATIONDATEPROPERTY_CREATEDBY...

: long: String: String: String: String: String: String: String: String

CommissionLine

-++++++++



CommissionRun

-++++++++



ConditionGoods

-+++++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_ACTIVEPROPERTY_CREATIONDATEPROPERTY_CREATEDBYPROPERTY_UPDATED...

: long: String: String: String: String: String: String: String: String: String

SalesRegion

-+++++++++




Diagrammes de classe : Gestion d’achat

Figure 25 : Gestion d'achat

POInvoiceMatch

-++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_ACTIVE...

: long: String: String: String: String: String: StringBaseOBObject


-----

logserialVersionUIDmodelnewOBObjectdata...

: org.apache.log4j.Logger: long: Entity: boolean: Object[]

ReceiptInvoiceMatch

-+++++++



Requisition

-+++++++



RequisitionLine

-+++++++



RequisitionPOMatch

-++++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_CREATIONDATEPROPERTY_CREATEDBYPROPERTY_UPDATED...



Diagrammes de classe : Gestion des données principales

Figure 26 : Gestion des données principales

BankStatement

-+++++++



BaseOBObject


-----

logserialVersionUIDmodelnewOBObjectdata...

: org.apache.log4j.Logger: long: Entity: boolean: Object[]

BudgetLine2

-+++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATION...

: long: String: String: String: String: String

BusinessPartner

-++++++++



ElementValue

-++++++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_ACTIVEPROPERTY_CREATEDBYPROPERTY_CREATIONDATEPROPERTY_UPDATEDPROPERTY_UPDATEDBY...

: long: String: String: String: String: String: String: String: String: String: String

GLJournal

-+++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_NEWCLIENTIDENTIFIER...


ImportFormat

-+++++++



ImportFormatRow

-++++++


: long: String: String: String: String: String: String

Inventory

-+++++++



Invoice

-+++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATION...


Order

-++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_TRXORGANIZATION...

: long: String: String: String: String: String: String

Product

-++++++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_ACTIVEPROPERTY_CREATIONDATEPROPERTY_CREATEDBYPROPERTY_UPDATEDPROPERTY_UPDATEDBY...


Tax

-+++++++



= 1L = "I_Tax" = "DataImportTax" = "id" = "client" = "organization" = "active" = "creationDate"


Diagrammes de classe : module synchronisation POS

Figure 27 : module synchronisation POS

<<bind>>

PosObject++++--

PROPERTY_ENTITYNAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONpropertiesorderByProperties

: String: String: String: String: Properties: List<String>

= "entityName" = "id" = "client" = "organization"

+

-

<<Constructor>> PosObject ()

defaultOrder ()...

: void

PosAttribute+ PROPERTY_NAME : String = "name"

+

-

<<Constructor>> PosAttribute ()

order ()

...

: void

PosAttributeSet+ PROPERTY_NAME : String

+ <<Constructor>> PosAttributeSet ()...

PosAttributeSetInstance++

PROPERTY_ATTRIBUTESETPROPERTY_DESCRIPTION...

: String: String

PosAttributeUse+++

PROPERTY_ATTRIBUTEPROPERTY_ATTRIBUTESETPROPERTY_SEQUENCENUMBER...

: String: String: String

PosAttributeValue+++

PROPERTY_SEARCHKEYPROPERTY_NAMEPROPERTY_ATTRIBUTE...


PosBP+++++

PROPERTY_NAMEPROPERTY_SEARCHKEYPROPERTY_TAXIDPROPERTY_FIRSTNAMEPROPERTY_LASTNAME...

: String: String: String: String: String

= "name" = "searchKey" = "taxID" = "firstName" = "lastName"

PosInventory++++

PROPERTY_WAREHOUSEPROPERTY_PRODUCTPROPERTY_ATTSETINSTANCEPROPERTY_UNITS...

: String: String: String: String

PosOrder+++++

PROPERTY_TICKET_NUMBERPROPERTY_TICKET_TYPEPROPERTY_TICKET_DATEPROPERTY_CUSTOMERPROPERTY_LINE...


PosProcessedOrdersResults+++++

PROPERTY_TITLEPROPERTY_OLNOTIMPORTEDPROPERTY_OINSERTEDPROPERTY_OLINSERTEDPROPERTY_ONOTPROCESSED...


PosProduct+++++

PROPERTY_NAMEPROPERTY_SEARCHKEYPROPERTY_UPCEANPROPERTY_PRODUCTCATEGORYPROPERTY_TAXCATEGORY...


PosProductCategory+++

PROPERTY_NAMEPROPERTY_PARENTPROPERTY_IMAGE...


PosTax++++

PROPERTY_NAMEPROPERTY_RATEPROPERTY_PARENTTAXRATEPROPERTY_TAXCATEGORY...

: String: String: String: String

Comparable_PosTax

PosTaxCategory+ PROPERTY_NAME : String = "name"

+

-

<<Constructor>> PosTaxCategory ()

order ()...

PosTaxCustomerCategory+ PROPERTY_NAME : String = "name"

+

-

<<Constructor>> PosTaxCustomerCategory ()

order ()...

PosWarehouse++

PROPERTY_NAMEPROPERTY_ADDRESS

: String: String

Comparable

<T>


Diagrammes de classe : module comptabilité


ADCreatefactTemplate

-+++++++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_ISACTIVEPROPERTY_CREATIONDATEPROPERTY_CREATEDBYPROPERTY_UPDATEDPROPERTY_UPDATEDBYPROPERTY_NAME...

: long: String: String: String: String: String: String: String: String: String: String: String

BaseOBObject


--------

logserialVersionUIDmodelnewOBObjectdataisDerivedReadableallowReaddataTrl...

: org.apache.log4j.Logger: long: Entity: boolean: Object[]: Boolean: boolean: BaseOBObject

AccountingFact

-+++++++++



Budget

-++++++++++



BudgetLine

-++++++++++



Dimension

-++++++


: long: String: String: String: String: String: String FIN_FinancialAccountAccounting

-++++++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_ACCOUNTPROPERTY_ACCOUNTINGSCHEMAPROPERTY_CLIENTPROPERTY_ORGANIZATIONPROPERTY_ACTIVEPROPERTY_CREATIONDATEPROPERTY_CREATEDBY...


= 1L = "FIN_Financial_Account_Acct" = "FIN_Financial_Account_Acct" = "id" = "account" = "accountingSchema" = "client" = "organization" = "active" = "creationDate" = "createdBy"

OrganizationClosing

-+++++++++



TablePostV

-+++++++

serialVersionUIDTABLE_NAMEENTITY_NAMEPROPERTY_IDPROPERTY_NAMEPROPERTY_LANGUAGEPROPERTY_CLIENTPROPERTY_ORGANIZATION...



3. L’analyse dynamique :

Cette phase a pour but de préciser la modélisation dynamique du nouveau système se basant sur divers modèles, nous y utiliserons deux diagrammes à savoir :

Diagramme d’activité Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de flots de données. Ils permettent ainsi de représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas d’utilisation.

Diagramme de séquence permet de représenter des collaborations entre objets impliqué dans les scénarios (présentés dans les cas d’utilisation) selon un point de vue temporel, on y met l’accent sur la chronologie des envois de messages.

i. Conception des diagrammes de d’activité

Diagramme d’activité : Gestion des ventes

La figure suivante présente le diagramme d’activité des différentes transactions de vente. En effet, une transaction de vente est résumée par le scénario suivant :

La préparation de devis est une étape nécessaire à l’élaboration d’une commande de vente. En effet, le devis présente un document transactionnel qui a l’allure de facture et qui permet au client en question ainsi qu’à l’agent commercial de distinguer les caractéristiques d’un produit et du prix et de lancer après acceptation un ordre de vente.

La deuxième étape indispensable c’est l’exécution de la commande de vente en elle-même qui nécessite le paramétrage et la sélection des produits et des différents partenaires qui entrent en jeu au moment de la commande. Une commande en général se termine par une

Livraison et nécessite la vérification du stock lors de l’exécution.

En cas de terminaison des paramétrages nécessaires à la commande et en parallèle avec la livraison au client le processus traite la phase de facturation. En effet, une facture doit être associée à chaque livraison-commande.


Figure 29 : Diagramme d’activité : « Gestion des ventes »

Diagramme d’activité : Gestion des achats

Le processus d’achat est semblable à celui de la vente. En outre, il traduit la gestion des transactions d’achat entre responsable commercial et fournisseur en question. La figure suivante présente le diagramme d’activité des différentes transactions d’achat autrement dit « processus d’affaires» de la gestion des achats. En effet, une transaction d’achat est résumée par le scénario suivant :


Figure 30 : Diagramme d'activité : « gestion des achats »

ii. Conception des diagrammes de séquence


Figure 31 : Authentification

1.Demande d'authentification

3.Saisir login et mot de passe

7.Message d'erreur

9.Interface d'accueil affiche

2.Interface affichée

4.Envoi mot de passe)d'authentificationmot de passe)(login

6.Login / mot de passe incorrect

8.login et mot de passe correct

5.Vérification

Uti l i s a teur

In Ter fa ce ba s e d e d o n n ées

identification incorrect

identification correct

alt

1.Demande d'authentification

3.Saisir login et mot de passe

7.Message d'erreur

9.Interface d'accueil affiche


4.Envoi mot de passe)d'authentificationmot de passe)(login

6.Login / mot de passe incorrect

8.login et mot de passe correct

5.Vérification


Figure 32 : Télécharger le catalogue des produits

1.Demande d'afficher la liste de produits

2.Envoi la demande

3.Liste de produits affichée

4.Liste de produit affichée

5.Se connecter à Openbravo ERP

6.Demande de connection

7.Connection confirmée

8.Rechercher la liste de produit

9.Demande de télecharger les catalogues de produits

10.Confirmation

11.Liste des catalogues affichées


13.Mise à jour avec succés

14.Informations ajoutées

Ad mi n i s tr a teur Open B r a vo B r a vo POS

INTERFACE OPen B RAVO POS OPen B RAVO ERP

1.Demande d'afficher la liste de produits

2.Envoi la demande

3.Liste de produits affichée

4.Liste de produit affichée

5.Se connecter à Openbravo ERP

6.Demande de connection

7.Connection confirmée

8.Rechercher la liste de produit

9.Demande de télecharger les catalogues de produits

10.Confirmation



13.Mise à jour avec succés

14.Informations ajoutées


Figure 33 : Synchroniser les ventes

Dans ce chapitre nous avons entamé la phase d’analyse et conception qui se présente selon trois vues : une vue fonctionnelle (diagramme de cas d’utilisations), une vue statique (diagramme de classes), une vue dynamique (diagrammes d’activité et de séquence). Après avoir achevé cette étape, nous passons maintenant à l'implémentation de l’application. Ceci doit être précédé par une étude qui déterminera le choix technologique « chapitre 7 » que nous avons suivi dans ce projet.

1.Demande d'ajouter un client

3.Saisir les informations de nouveau client

6.Client a ajouter avec succés

7.Demande d'une commande de produit

10.Commande validée


4.Information saisie


8.Envoi de commande

9.Commande validée

11.Synchronisation vente

12.Synchronisation confirmée

a d mi n i s tr a teur o pen B r a vo POS

i n ter fa ce Open B r a vo POS Open B r a vo ERP

1.Demande d'ajouter un client

3.Saisir les informations de nouveau client


7.Demande d'une commande de produit

10.Commande validée


4.Information saisie


8.Envoi de commande

9.Commande validée

11.Synchronisation vente

12.Synchronisation confirmée


Partie 3 :

La réalisation du nouveau système

Chapitre :

Chapitre 6 : Processus de synchronisation POS

Chapitre 7 : Réalisation et mise en place.


Ce chapitre décrit l'effort d'intégration fait entre Openbravo ERP et Openbravo POS pour combiner et travailler avec le même jeu de données. Cette intégration est basée sur les web services.


VI. LE PROCESSUS DE SYNCHRONISATION POS

1. Introduction

Dans une organisation, il existe souvent plus d'une application pour supporter un aspect particulier des besoins opérationnels. Le résultat est un ensemble d’applications hétérogènes exigeant le partage des données et l'intégration. Un système ERP (progiciel de gestion intégré) tel qu’Openbravo essaye de résoudre ce problème en offrant une solution pour chaque besoin opérationnel. Openbravo gère une seule base de données, intègre les processus parmi les différents départements, une interface cohérente pour chaque utilisateur, et des rapports homogènes affichant les données opérationnelles de toute l'organisation.

Toutefois il y a des domaines spécifiques d'une organisation qu'un système ERP ne peut résoudre. Par exemple, les systèmes POS (système de point de vente) comme Openbravo POS où des types d'utilisateurs spéciaux ou des supports de périphériques sont requis. L'utilisateur du système POS est un vendeur qui utilise un ERP d'une manière différente. L'interface doit être très facile à utiliser et doit fournir uniquement les informations spécifiques dont le vendeur a besoin. Ce vendeur a besoin d'utiliser le POS aussi vite que possible puisque son travail est de vendre et non pas de faire fonctionner le POS. Par exemple il n'a pas besoin d'une souris et d'un clavier, il préférera un écran tactile. De plus, le système POS a besoin de supporter beaucoup de périphériques tels que: les imprimantes tickets, les lecteurs de code-barres, les écrans d'affichage clients, les tiroirs caisses, les balances, etc.

2. Vue d'ensemble de l'intégration

L'objectif de cette intégration est de créer un système où Openbravo ERP est le référentiel central des données: produits, les clients, les taxes, les commandes ... Et Openbravo POS a la capacité de fonctionner avec les données de base téléchargée depuis Openbravo ERP et de télécharger des commandes créées par l'activité de vente d’Openbravo POS.

Cette intégration a été développée avec le Web services REST.

Le web services REST d’Openbravo ERP fonctionne sur Business Objects (à Openbravo ERP). Un Business Object (dans Openbravo ERP) peut être une entité simple (un tableau), comme une monnaie qui vient de champs primitifs de base. Ou peut-être aussi complexe que la structure des entités, par exemple un bon de commande avec ses lignes de commande.

Le web services REST d’Openbravo ERP offre les fonctionnalités suivantes:

Récupérer un objet métier ou une liste d'objets métier à l'aide d'une norme HTTP GET demande.

Interrogation, le filtrage, la pagination et le tri des listes d'objets métier, de nouveau dans les requêtes HTTP standard.

Mettre à jour un objet métier existant ou plusieurs objets métier avec XML et HTTP POST ou PUT opérations.

Créer de nouveaux objets métier avec un POST / PUT opération.


Exporter et importer des données: les fichiers XML qui contiennent un mélange de différents types d'objets métier et d'un mélange d'objet métier existants et nouveaux.

Opération de suppression en utilisant soit une URL pointant vers un objet métier spécifique qui doit être enlevé ou un document XML qui contient les objets métier (comme XML complète ou partielle en XML) qui doivent être supprimés.

Les services Web REST d’Openbravo ERP utilisent le même accès/autorisations que l'application standard Openbravo ERP. Avant d'appeler un service Web, l'appelant doit se connecter. La fonctionnalité de connexion est fournie par le cadre Openbravo ERP REST. Toutes les actions REST sont alors exécutées dans le contexte d'un rôle de client/organisation et le courant de l'utilisateur.

3. Le processus de synchronisation POS

Dans un environnement intégré toutes les informations produits, informations entrepôt, catégories de produits, les impôts et les informations clients sont maintenus dans Openbravo ERP. Ce processus est exécuté quand est nécessaire pour synchroniser Openbravo POS avec l'information qui a changé dans Openbravo ERP.

A. La configuration d’Openbravo ERP

La notion du système de modularité d’Openbravo ERP

Un module d'extension est un morceau de fonctionnalités supplémentaires qui peuvent être éventuellement et indépendamment déployé au-dessus d’Openbravo ERP.

L'expérience de l'utilisateur de déployer des modules est similaire à celui des plugins Firefox: parcourir un catalogue de modules, l'installation (et de désinstallation), de déployer et de les mettre à jour directement à partir de l'interface utilisateur Openbravo ERP administration.

Un développeur d'un module d'extension peut emballer et livrer un module indépendamment d’Openbravo ERP, ce qui signifie qu'il est possible d'emballer les modules avec un mécanisme de prestation qui inclut uniquement les fichiers et les métadonnées responsables.

La fonctionnalité des Web services REST est très utile pour les scénarios d'intégration standard et dans notre cas nous permettre de Business Objects désirés à partir d’Openbravo ERP et mettre à jour un objet métier existant.

L'idée est d'installer un module (indépendant d’Openbravo ERP) qui est le responsable de déployer un Webservice REST en charge de la synchronisation.

Installation du module « Webservice pour la synchronisation d’Openbravo POS »

Pour installer le module de la synchronisation il faut suivre les étapes suivantes :

Connectez-vous en tant qu'administrateur système dans Openbravo ERP. Aller à la Configuration générale> Application Management Module>. Aller à l’onglet Ajouter modules.


Sélectionnez dans la liste ci-dessous POS WebService synchronisation et appuyez sur la touche Installer maintenant le bouton.

Après il faut suivre les étapes d’installation et de la recompilation du système.

Vérification de l'installation du module

Pour vérifier si le module est correctement installé, pointez votre navigateur sur:

http://localhost:8000/openbravo/ws/org.openbravo.pos.sync.ws

Cet exemple supposé qu’Openbravo ERP s’exécute localement surle port 8000, il peut être nécessaire de remplacer le localhost:8000 par le nom de serveur : port.

Avant d'appeler le service Web, l'appelant doit se connecter.

Le résultat devrait une page d'accueil avec une brève description de l'utilisation du service Web.



Figure 34 : page d'accueil du Web service.

Ajout du point de vente externe dans Openbravo erp :

Dans Openbravo ERP on ajoute le point externe pour définir les produits qui seront disponibles pour chaque point de vente. Avec cela, On peut obtenir le catalogue de produits d’Openbravo POS, et vis versa.

Pour ajouter le point de vente externe, il faut changer le rôle de l'administrateur Openbravo ERP de l'entité avec lequel on travaille, puis on ouvre le menu Application>Gestion des ventes> Configuration > point de vente.


Figure 35 : point de vente externe dans Openbravo erp

Paramètres de la requête

Dans la base de données et le web services installé il faut savoir les valeurs suivantes :

erp.id: L'identifiant client d’Openbravo ERP interne de vente. erp.org: L'identificateur d’Openbravo ERP de l’organisation interne de la pointe

externe de vente. erp.pos: La clé de recherche ou le code « pour la traduction française » du point de

vente externe défini dans Openbravo ERP utilisé pour identifier le système Openbravo POS à l'intérieur d’Openbravo ERP.

erp.user: L'utilisateur d’Openbravo ERP, utilisé pour appeler la fonctionnalité d'intégration.

erp.password: Le mot de passe de l'utilisateur Openbravo ERP.

Les Business Objects disponibles


POS Business Object POS Table ERP Table

Attribute ATTRIBUTE m_attribute

AttributeSet ATTRIBUTESET m_attributeset

AttributeValue ATTRIBUTEVALUE m_attributevalue

AttributeUse ATTRIBUTEUSE m_attributeuse

AttributeInstance ATTRIBUTEINSTANCE m_attributeisntance

AttributeSetInstance ATTRIBUTESETINSTANCE m_attributesetinstance

Warehouse LOCATIONS m_warehouse

BusinessPartnerTaxCategory TAXCUSTCATEGORIES c_bp_taxcategory

TaxCategory TAXCATEGORY c_taxcategory

Tax TAXES c_tax

ProductCategory CATEGORIES m_product_category

Product PRODUCTS m_product

Inventory STOCKCURRENT, STOCKDIARY, STOCKLEVEL m_storage_detail

BusinessPartner CUSTOMERS c_bpartner

Tableau 8 : Business Objects

Restrictions :

Product (Article pour la traduction française) o Type de produit doit être objet o Emballage du produit doit être unitaire o Le produit doit appartenir à la Version Liste récente des Prix à l'intérieur

du Tarif choisie dans le point de vente externe.

Inventory

Le modèle de stockage à Openbravo ERP est différent:

Openbravo ERP # Openbravo POS

| # |

|--- Warehouse # |--- Warehouse

|-----| # |

|--- Storage Bin # |---Products

| #

|--- Products #

Lorsque le stock d'un produit est synchronisé, la somme du stock disponible dans le stock de l'entrepôt sélectionné est terminée.

B. La configuration d’Openbravo POS

Présentation et concept de PDI

PDI (Pentaho Data Integration), qui était auparavant connu sous le nom de Kettle, est un logiciel d’ETL (Extract, Transform, Load) Open Source qui permet la conception ainsi que

http://wiki.openbravo.com/wiki/Projects:POS/ERP_Integration




l’exécution des opérations de manipulation et de transformation de données très complexes. Qu’est ce qu’un ETL ? Il s'agit d'une technologie informatique intergicielle (comprendre middleware) permettant d'effectuer des synchronisations massives d'information d'une base de données vers une autre. Selon le contexte, on est amené à exploiter différentes fonctions, souvent combinées entre elles : « extraction », « transformation », « constitution » ou « conversion », « alimentation ». PDI permet d'effectuer deux types de traitements :

1. Des transformations : traitement de base comprenant l'extraction de sources, la transformation et le chargement de cibles.

2. Des jobs : traitement permettant de séquencer plusieurs transformations. PDI est aussi composé de trois applications :

1. Spoon : interface graphique, faite avec SWT (Standard Widget Toolkit). 2. Pan : application en ligne de commande afin de lancer une transformation donnée. 3. Kitchen : application en ligne de commande afin de lancer une tâche donnée.

Pentaho Data Integration est un outil très flexible et convivial qui fournit un outil très graphique intuitif (Spoon) pour modifier et créer nos transformations. Pour l'utilisateur final est très facile à utiliser et ne nécessitent pas de compétences en programmation spéciaux. En outre, il ya une communauté active derrière le projet, ce qui signifie Forum, une documentation complète et ainsi de suite.

L'architecture actuelle réduit l'effort nécessaire pour modifier une fonctionnalité existante et minimise l'impact de la mise en œuvre d'une nouvelle fonctionnalité. La fonctionnalité des Webservices REST est très utile car ils permettent de récupérer des informations à partir de tous les Business Objects de Openbravo ERP, juste il faut faire une requête HTTP. Donc, si des données supplémentaires sont nécessaires, les modifications seront seulement affecter l'environnement Pentaho Data Integration.

D'autres applications peuvent s'intégrer avec Openbravo POS par Pentaho Data Integration d'une manière simple: la création d'une nouvelle transformation ou d'emploi. Ils n'ont pas besoin de modifier le code Openbravo POS, Pentaho Data Integration fournit un mécanisme suffisant pour atteindre une synchronisation réussie entre une application externe et Openbravo POS.

Pentaho Data Integration offre la possibilité de programmer des transformations ou des travaux à exécuter dans un serveur distant ou de forcer la synchronisation après événement exceptionnel qui se passe dans Openbravo POS, par exemple, lorsque l'argent est fermé. Ce point est important, car n'est pas besoin d'une interaction avec l'utilisateur à chaque fois qu’on a besoin pour faire fonctionner l'intégration, il suffit de préparer le calendrier dans un temps convenable et exécuter une fois.

Installation de Pentaho Data Integration

Pour l'installer, il faut le télécharger dans ce site www.pentaho.com et le décompresser simplement dans un dossier.


Pentaho Data Integration nécessite de Sun Java Runtime Environment (JRE) version 1.5 ou plus récent.

Tous les pilotes JDBC fournis dans Pentaho Data Integration sont situés dans data integration/libext/JDBC .

Est obligatoire d'utiliser dans Pentaho Data Integration une version du pilote JDBC compatible avec la version du pilote JDBC utilisé dans Openbravo POS.

Configurer Pentaho Data Integration

Il faut modifier le fichier « kettle » pour configurer notre base de données et les paramètres de connexions pour Openbravo ERP.

Ce fichier se trouve pour mon ordinateur dans ce chemin : C:\Users\Chouaib\.kettle\kettle.properties

# Database Connection

db.URL = jdbc:derby:C:\\ipos_base ; create=true

db.driver = org.apache.derby.jdbc.EmbeddedDriver

db.user =

db.password =

# Openbravo ERP

erp.URL = http://localhost:8000/openbravo/ws/org.openbravo.pos.sync.ws

erp.id = 6BCACEB47FA24B9687729D4478A8BF40



erp.org = A955BB2978F54372BCDD6DCAAF99BFC6

erp.pos = monpos

erp.user = Openbravo

erp.password = openbravo

Les valeurs de configuration sont les suivantes:

db.URL: Pour localiser le pilote JDBC et la base de données. db.driver: Le nom de la classe Java qui implémente le pilote JDBC. Ce nom est

également défini par le fournisseur de moteur de base de données. db.user: Le nom de l'utilisateur de base de données autorisée. db.password: Le mot de passe de l'utilisateur de base de données. Le mot de passe doit

être rédigé en texte brut et non codé tel qu'il apparaît dans le fichier de configuration Openbravopos.properties

erp.URL: L’URL du Web service. erp.user: L'utilisateur Openbravo ERP utilisé pour appeler la fonctionnalité

d'intégration. erp.password: Le mot de passe de l'utilisateur Openbravo ERP. Le mot de passe doit

être rédigé en texte brut. erp.id: L'identifiant client Openbravo ERP interne de la pointe externe de vente. erp.org: L'identificateur d’Openbravo ERP organisation interne de la pointe externe de

vente. erp.pos: (le code) du point de vente externe défini dans Openbravo ERP utilisé pour

identifier le système Openbravo POS à l'intérieur d’Openbravo ERP.

Il faut vérifier les variables après l’ouverture de l’outil Spoon. Dans le menu principal aller à Edition> Edition du fichier kettle.properties ou simplement (Ctrl + Alt + P) et les variables et leurs valeurs doivent apparaître dans la boîte de dialogue.

C. Exécution de la synchronisation

La synchronisation principale

Il faut ouvrir le fichier Job ALL SYNCHRONIZATION.kjb puis on clique sur le bouton Exécuter pour effectuer la synchronisation, dans le menu, ou en appuyant sur F9.

Le processus de synchronisation démarre automatiquement.


Figure 36 : Exécution du processus de synchronisation

La Synchronisation des commandes

Il faut ouvrir ORDERS.ktr dans la transformation Spoon et puis on exécute en cliquant sur le bouton Exécuter dans le menu, ou en appuyant sur F9.

Après la synchronisation des commandes, on traite ensuite les commandes importées dans Openbravo ERP.

Il faut changer le rôle de l'administrateur Openbravo ERP à l'entité qu’on travaille avec.

Enfin pour finaliser le processus d’importation, il faut naviguer dans Géstion des données principales> Importer des données>importer commande et exécuter.


Figure 37 : importation de la commande

Remarque : pour plus de détails sur les autres types d’importation voir le chapitre suivant.


La réalisation et la mise en place vient couronner les phases précédentes, donnant un aspect tangible aux suggestions présentées lors de l`étude de l`existant et une forme concrété a la conception. Afin de présenter le prototype réalisé, on utilise des prises d’écran (Screen Shoots) pour figurer le travail fait et d’illustrer les grandes et principales fonctionnalités du système.


VII. REALISATION ET MISE EN PLACE

1. Environnement de programmation

Choix de l’OpenBravo

Divers sont les progiciels ERP sur le marche, tels indique dans l’état de l’art, payants ou libre (Open Source). Le choix dépendra essentiellement des fonctionnalités de bases offertes par l`ERP. Dans notre cas, nous avons opte pour le produit : Openbravo 3 MP11.

Description des serveurs

La structure de développement de notre système étant en architecture web.

Figure 38 : Description des serveurs

Choix du SGBD

Nous avons choisi de travailler avec PostgreSQL 8.4 comme système de gestion de base de données. Grace a certaines fonctionnalités orientées objet qui`il incorpore.

PostgreSQL est un système de gestion de Base de Données Relationnelles Objet (SGBDRO), fonctionnant sur diverses plates formes matérielles sous différents systèmes d’exploitation.


PostgreSQL est largement considérer comme le système de base de données non commercial le plus avancé. IL dispose de nombreuses fonctionnalités que l’on ne rencontre que dans des grands produits commerciaux.

Ce SGBD est un projet Open Source, ce qui signifie qu’on peut obtenir son code source, l’utiliser et le modifier à fin qu’il satisfasse nos besoins personnels, librement sans subir les restrictions des logiciels propriétaires.

Choix du domaine dàpplication & l’IDE

Le choix de ces outils est principalement motive par le fait que ces outils soient développés en JAVA. Ils sont également gratuits et possèdent des environnements de débogage.

L’IDE Eclipse

Un langage de programmation nécessite forcement un environnement dans lequel on

désire développer une application. Eclipse est un environnement de développement libre (le

terme Eclipse désigne également le projet correspondant, lancé par IBM) extensible, universel et

polyvalent, permettant potentiellement de créer des projets de développent mettant en œuvre

n’importe quel langage de programmation. Eclipse IDE est principalement écrit en Java (à l’aide

de la bibliothèque graphique SWT, d’IBM), et ce langage, grâce à des bibliothèques spécifiques,

est également utilisé pour écrire des extensions.

Choix du serveur dàpplication (Apache Tomcat)

Le serveur dàpplication Apache Tomcat joue le role de conteneur JSP /Servlet qui permet a

sa connexion avec un serveur web de délivrer du contenu dynamique aux clients.

La version du serveur utilisée dans notre projet est Apache Tomcat 6.0.32.

Tomcat est un serveur Web qui gère les servlets J2EE. Il est souvent employé en combinaison

avec un serveur Web Apache : Apache s'occupe de toutes les pages web traditionnelles, et

Tomcat uniquement des pages d'une application web Java. Issu du projet Jakarta, Tomcat

implémente les spécifications des servlets et des JSP de Sun Microsystems. Il inclut des

outils pour la configuration et la gestion, mais peut également être configuré en éditant des

fichiers de configuration XML. Comme Tomcat inclut un serveur HTTP interne, il est aussi

considéré comme un serveur HTTP, il est aussi une plateforme pour le développement et le

déploiement d’applications web et des web services.

Le serveur d’application Java « Tomcat 6 » est utilisé dans l’exécution officielle de référence

http://fr.wikipedia.org/wiki/Apache_Jakarta

http://fr.wikipedia.org/wiki/Servlet

http://fr.wikipedia.org/wiki/JavaServer_Pages

http://fr.wikipedia.org/wiki/Sun_Microsystems


pour les technologies de Java Servlet et des pages JSP. Il est développé dans un environnement

Open Source et est sous le permis de logiciel d’apache. Tomcat offre aussi beaucoup d’avantage

soient:

o Une parfaite conformité avec les spécifications de SUN pour les SERVLET et les JSP.

o Une fiabilité certaine résultat de plusieurs années d’évolutions et d’améliorations par les

meilleurs développeurs.

o La gratuité : son cout reste loin du prix d’achat des produits commerciaux concurrents.

Tomcat a été écrit en langage Java, il peut donc s'exécuter via la JVM (machine virtuelle java)

sur n'importe quel système d'exploitation.

Choix du modèle de développement de l`application

Pour assurer le bon fonctionnement de notre système et mettre en œuvre les

caractéristiques citées précédemment, nous avons développé une architecture basée sur le

modèle J2EE (une plate-forme dédiée aux applications multi-tiers), pour le modèle J2EE, nous

avons applique le modèle MVC.

Figure 39 : le modèle MVC

2. Concepts de base de la plateforme « OpenBravo »

Model Driven Développement (MDD)

OpenBravo ERP suit l’approche dirigée par les modèles (Driven Développements Model (MDD)). En effet, il utilise un modèle de technologie agnostique afin de définir les composants d'application, tels que les fenêtres et les processus. Basé sur ce modèle d'application, la plateforme « open bravo » utilise un assistant de génération de code java appelé (Assistant au développement d’applications « WAD ») à partir des métadonnées


stockées dans le dictionnaire applicatif. Plus, concrètement le dictionnaire applicatif de la plateforme Open Bravo permet de définir et de personnaliser les différents composants d’application il est représenté au niveau de la base de données par les tables ayant le préfixe « AD » . Ces tables présentent les différents types de métadonnées utilisés tout au long de l’application , nous présentons ainsi le méta model de l’ERP « open bravo » ainsi que l’architecture de génération de code automatique WAD.

Figure 40 : Génération automatique de code WAD

MVC Fondation Framework

Openbravo suit une approche modèle-vue-contrôleur pour le design des interfaces utilisateur et ce via se une génération d'exécution et de la technologie avancée de Template (MVC-FF) afin de générer l'interface utilisateur (la page html) demandée. MVC-FF est composé d'un ensemble d’outils développés par Openbravo tels que : XmlEngine, SQLC et HttpBaseSecureServlet. Il est nécessaire pour permettre le développement de fichiers découplés pour les composants du modèle (classes Vue, modèle et de contrôle de l'architecture MVC).Cet ensemble de services publics s'est avéré très efficace pour l'équipe de développement Openbravo.

XmlEngine : est un utilitaire utilisé pour créer des documents XML / HTML à partir la description du modèle sous forme de fichiers XML / HTML ainsi que les fichiers de configuration XML tout en assurant la dynamité des données insérée. Ces interfaces sont également conformes aux données existantes dans le modèle ce qui facilite la saisie des données et l’exécution des différentes transactions.

SQLC : (SQL compilateur) est un utilitaire utilisé pour éviter la tâche répétitive de l'écriture du code Java d’interaction avec la base de données. il génère automatiquement le code de connexion à la base à partir des fichiers XML des instructions SQL


standards ce qui facilite énormément la manipulation des données à partir des interfaces utilisateur.

http BaseServlet : http BaseServlet et HttpBaseSecureServlet sont les servlets à partir de lesquelles sont dérivées toutes les servlets du système qui désignent à leurs tours la partie contrôleur de la composante MVC. Ces servlets assurent les fonctionnalités courantes telles que l'authentification le contrôle et, l'autorisation de base de connectivité et de gestion des erreurs. Les servlets dérivant de HttpBaseSecureServlet rendent le contrôle standard de lecture de données encore plus sécurisé et coopèrent avec des classes générées par SQLC afin de fournir la sortie à XmlEngine et générer les interfaces utilisateur.

3. Importation des données

L’importation des données est une phase indispensable pour la mise en place d’un ERP. En effet, nous appliquons une méthode avec l’ETL qui consiste à extraire les données du système existant et à les transformer ensuite les charger dans l’entrepôt de données relatif à l’ERP. Les interfaces suivantes décrivent le processus d’importation de données.

Format d’importation

Il permet de créer, d’une première part, le format d’importation comme suit : Ordres Produit, Budget, tiers, comptes et Taxe. Les différents formats permettent de définir les structures des fichiers Excel à importer. Le système permet de stocker les données dans des tables intermédiaires afin de les traiter par la suite. La figure suivante présente les divers formats que nous avons créés afin de réaliser l’importation des données.


Figure 41 : Format d’importation des données

Afin de réaliser l’importation de données à partir des fichiers Excel contenant les données à importer dans les tables temporaires. Il est nécessaire de traiter chaque fichier Excel associé à chaque format d’importation.

Importation des articles

Le paramétrage des articles consiste à configurer les articles déjà importés à partir des fichiers Excel ou les POS. La figure suivante présente un exemple d’importation de produit.


Figure 42 : Importation d’un article

Importation des commandes

L’importation des commandes désigne la configuration des commandes déjà importés par le POS afin de les traiter par la suite lors de l’exécution du processus commercial. L’exemple de la figure traite une commande déjà importée et qui est prête à être traitée.


Figure 43 : Importation de commande

4. Paramétrage

Paramétrage des taxes

Le paramétrage des taxes est une étape indispensable pour le paramétrage des produits .En effet, les taxes peuvent être applicables selon la catégorie de produit. Nous avons défini dans notre cas la catégorie de taxe TVA comme taxe standard avec trois types de pourcentage : 6%, 12%, 18 %.

Figure 44 : Paramétrage de taxes


Paramétrage des catégories d’articles

Le paramétrage des biens ou des articles joue un rôle très important lors de la manipulation du processus commercial de l’ERP Open bravo. Il est possible ainsi de classer les articles par catégorie de produit. L’interface suivante présente le paramétrage du produit « Couscous ». On peut constater le paramétrage de la catégorie de taxe et la catégorie de produit.

Figure 45 : Paramétrage de catégories produites

Le paramétrage des produits sous Open bravo requiert le paramétrage des catégories d’article ainsi que le paramétrage des catégories de taxe appliquées pour chaque produit.

Paramétrage des tarifs

Le paramétrage des tarifs consiste au paramétrage ainsi que la création de la liste de prix associés pour chaque produit.


Figure 46 : Paramétrage des tarifs

Paramétrage des tiers

La gestion des tiers désigne le paramétrage des clients et des fournisseurs, des catalogues de produits, la définition des différents types de taxes requises et enfin la génération des listes de prix ou encore la gestion des tarifs. La phase de configuration des produits reste indispensable à l’exécution de plusieurs types de transactions d’achat et de vente.

Configuration des groupes tiers

Les groupes tiers désignent les catégories de partenaires qui entrent en jeu lors d’une transaction de type commerciale, on peut distinguer les clients et les fournisseurs.


Figure 47 : Configuration des tiers

5. Mise en place de l’ERP

La phase de mise en place désigne la phase d’intégration du système de l’ERP au sein de l’entreprise. En effet, cette étape requiert la manipulation d’un grand nombre de données qui présentent les données du système d’information d’entreprise ainsi que la configuration et le paramétrage de différents types de fonctionnalités mises en jeu.

Le processus commercial traite la gestion des données principales requises à la manipulation de différentes pièces commerciales telles que les commandes les livraisons, les devis, les factures…

L’étape préambule de la mise en place de l’ERP est la création initiale de la société ELECTRO PROTECT. En effet, elle est définit par : le nom de la société, le devise et mot de passe ainsi que d’autre information plus des tailles tel que l’adresse, l’autre mail…


Figure 48 : création initial de la société

Nous allons dans ce qui suit présenter le processus de paramétrage ainsi que l’exécution des commandes tout en respectant les différentes fonctionnalités présentées lors de la phase de conception.

Module achat

Ce module traite les étapes principales de gestion commerciale bien spécifiées. En effet, la gestion des achats englobe la gestion des différentes transactions d’achat y compris la gestion des devis fournisseur, des bons de réception de la part du fournisseur ainsi que les factures liées. La définition des commandes requiert le pré paramétrage des listes de tiers et de produit et requiert aussi la création et la configuration de la liste des prix encore appelée tarif. Voici un exemple de commande d’achat.


Figure 49 : Commande d'achat

Après avoir traité la commande d’achat, il est nécessaire lors d’un processus d’achat d’éditer les bon de réception de marchandises. Ces derniers présentent les documents à traiter lors d’une réception d’articles de la part du fournisseur et après terminaison d’une commande d’achat .cette phase présente la phase intermédiaire entre le traitement des commandes d’achat et aussi le traitement des factures d’achats.


Figure 50 : réception marchandise

Le système d’Openbravo traite plusieurs types de factures. On peut en citer par exemple : les factures de retour client, les factures de retour fournisseur, les factures de vente et ceux d’achats. Les factures sont généralement liées d’une part au processus financier puisqu’ils traitent le payement lors d’une livraison ou d’une réception d’articles.la figure suivante présente le type de facture à traiter lors d’une réception d’articles .en effet elle peut être générée automatiquement à partir des bons de réceptions dans le cas d’une transaction d’achat.


Figure 51 : facture d'achat

Module vente

La gestion des ventes englobe la gestion des différentes transactions de vente y compris la gestion des devis clients, les bons de livraison, les livraisons ainsi que les factures liées. La définition des commandes requiert le pré paramétrage des listes de tiers et de produit et requiert aussi la création et la configuration de la liste des prix encore appelée tarif. La configuration des commandes requiert plusieurs types de données liées tels que la configuration des taxes, la configuration des modes de payement. Voici un exemple de commande de vente :


Figure 52 : commande vente

La gestion d’expédition désigne la phase de livraison au moment de vente. Elle poursuive la création et le traitement d’une commande de vente et elle est liée directement à la facturation.la figure suivante présente l’expédition liée à la commande précédente.


Figure 53 : Gestion d’expédition commande de vente

La gestion de facturation dans le cas d’une transaction de vente désigne la génération des factures liées à la livraison. La gestion de facturation fait partie de la gestion financière après exécution de commandes de vente. La génération des factures se fait automatiquement après livraison et peut être générée à partir des commandes de vente.

Dans ce cas on respecte plusieurs normes lors du payement de la facture .en effet le traitement d’une facture prend en compte plusieurs paramètres tels que : la liste de tarif sélectionnée, le mode de payement, le pourcentage .remise lors du payement .etc. La figure suivante traite un exemple de facture avec la sélection des tiers, des produits, des différents paramètres liés au payement.


Figure 54 : Facture de vente

Module comptabilité



6. Sécurité informatique

La fiabilité de tout système dépend d`une grande part du mécanisme de sécurité d`accès aux données mise en place.

La Sécurité du nouveau système :

Openbravo est un ERP qui utilise des moyens technologiques avancés assurant une circulation sécurisée de l’information.

La sécurité en Openbravo est basé sur des notions et des principes très importants, la séparation, le cryptage, la codification, le paramétrage. Touts ces moyens utilisés engendrent un système sécurisé, fiable, et opérationnel.

La sécurité existe dans Openbravo, et elle est très performante et utile, donc il suffit de l’utiliser a notre avantage, notamment dans la gestion des profiles et des droits d’accès.


Conclusion

L’objectif de ce projet est de mettre en place l’ERP Open Source « Openbravo» en

effectuant les paramétrages et les configurations nécessaires des modules achat, vente, finance et

stock au bon fonctionnement du nouveau système d’information d’ELECTROPROTECT.

Au cours de ce travail, on a réalisé dans un premier temps l’étude comparative des ERP

Open sources qui existent sur le marché. La vraie phase de sélection s’est basé principalement

sur cinq critères de sélection tels que : la dynamité pour déterminer la valeur ajoutée de la

solution dans le futur, la technologie pour détecter la maturité de la solution en termes de

technologie, le périmètre pour évaluer la solution en termes de fonctionnalités, la notoriété

actuelle afin de mesurer la popularité de l’ERP et enfin le critère de souplesse.

Au cours de ces itérations, nous avons entamé par la suite l’étude du système existant

afin de détecter les anomalies qui y existent. En fait, la société ELECTROPROTECT utilise un

système actuel qui manque de fiabilité et de performance de ce faite on a défini nos besoins par

rapport au système actuel. La détection des apports du nouveau système de l’ERP open bravo

reste indispensable à la définition de nos principaux cas d’utilisation. Ensuite, nous avons

abordé la phase de conception afin de détailler la définition de nos besoins en utilisant le

standard de conception universel UML avec les différents diagrammes nécessaires. D’autre

part, nous avons détaillé lors de cette phase l’exécution des processus métier du système

d’Openbravo nécessaires à la gestion du système d’information d’entreprise. Nous avons défini

aussi les structures de données nécessaires à la mise en place de l’ERP au sein de l’entreprise.

De point de vue réalisation, j’ai bien réussi à mettre en place les quatre modules de

l’ERP de manière générique que possible permettant ainsi de capitaliser sur ces modules afin de

pouvoir les commercialiser à d’autre client. Cette étape requiert une bonne compréhension de la

cartographie des processus d’Openbravo et une migration de données adéquate en utilisant les

techniques d’importation de données ETL. Notre travail s’intéresse plutôt à la gestion du

processus commercial tout en assurant la génération automatique des pièces commerciales

mises en jeu.


Bibliographie

[1] P. ROQUES. – UML 2. Modéliser une application web, 4ème édition,2006, Eyrolles..

[2] Mickaël Mannechez. – La mise en place d'un ERP

[3] FLEUR-A. blain. – Présentation générale des ERP et leur architecture modulaire

[4] Raphaël Valyi. – Smile ERP open source

Webographie

[Site d’Openbravo] http://www.openbravo.com/

[Site Source] http://sourceforge.net/projects/openbravo/

[Wiki d’Openbravo] http://wiki.openbravo.com/wiki/ERP_2.50

[Site Pentaho] http://infocenter.pentaho.com/help

[Site MDA] http://www.omg.org/mda/

[Site Source forge] www. sourceforge.net/projets/ Openbravo/

[Wiki POS] http://wiki.openbravo.com/wiki/OpenbravoPOS_FAQ/fr

[JavaDoc d’Openbravo] http://code.openbravo.com/docs/erp/devel/3.0MP11/

http://www.openbravo.com/

http://sourceforge.net/projects/openbravo/

http://wiki.openbravo.com/wiki/ERP_2.50

http://infocenter.pentaho.com/help/index.jsp

http://www.omg.org/mda/

http://sourceforge.net/projects/openbravo/

http://wiki.openbravo.com/wiki/OpenbravoPOS_FAQ/fr

http://code.openbravo.com/docs/erp/devel/3.0MP11/


Annexes

ANNEXE 1 OPENBRAVO POS

I. Présentation

Openbravo POS s'intègre sur la plupart des équipements existants, offre un large panel

de modules et de paramétrages, et couvre ainsi l'ensemble des besoins des entreprises et de leurs

points de ventes.

Conçu spécifiquement pour les écrans tactiles,

Identification des utilisateurs par code, carte ou badge,

Gestion des droits d’accès par rôles d'utilisateurs,

Édition, réédition et remboursement de tickets,

Mise en attente du ticket et édition depuis un autre

TPV,

Gestion des bons d'achat, clients en compte et de la

fidélité,

Ouverture et clôture de caisse conviviale et en

"aveugle",

Openbravo POS s'adapte aussi bien aux boutiques mono-caisse qu'aux chaînes de

magasin multi-caisses avec son Backoffice Openbravo ERP, la solution offre des capacités de

gestion multi-sites puissantes et évolutives:

Gestion des achats, des commandes et des bons de livraisons,

Gestion des stocks et des approvisionnements,

Gestion hiérarchique par organisations, sociétés et point de

ventes,

Gestion financière et comptable,

Outils statistiques avancées,

Accessible de n'importe où grâce à sa technologie Full Web.

Electro Protect ajoute la possibilité de développer et d'intégrer des fonctions et modules, et

ainsi couvrir l'intégralité du processus de vente et d'encaissement spécifique à chaque entreprise.


II. Détail des principales fonctionnalités

a) Gestion des données

Un module central permet de gérer l’ensemble des données

de l’application: Utilisateurs, magasins, produits, catégories,

sous-catégories, entrepôts, taxes, aire de vente,

agencement,…

b) Ventes, remboursement et gestion de la caisse

Édition tickets de caisse, factures A4 et facturettes

Mise en attente du ticket et récupération à partir d'un autre

terminal

Multi- paiement

Gestion des clients en compte

Compatible avec de grands nombres de périphériques

Gestion efficace des remboursements

Interface très simple et conviviale

c) Gestion de la logistique

Gestion multi-entrepôts

Gestion des catégories, familles et sous-familles

Conserver l'inventaire constamment à jour

Connaître l'état de stock en temps réel

Tracer les mouvements de produits en relation avec les tickets de

caisses

III. Schéma Entité Relation d'Openbravo POS


Figure 56 : Schéma Entité Relation d'Openbravo POS 2.30.2


ANNEXE 2 OPENBRAVO ERP

On se focalise dans cette annexe sur les technologies et Framework utilisés dans le développement du nouveau système, et ses principales caractéristiques.

I. Framework de l’ERP Openbravo

Openbravo ERP est une application développée grâce à un cadre de développement intégré inclus dans la distribution Openbravo ERP. Ce Framework intégré prend en charge un large éventail de préoccupations dans toutes les zones concernées au cours du processus de développement. Les plus pertinents de niveau faible à haut niveau:

Intégration avec Eclipse IDE

Intégration avec SCM (Mercurial)

Processus de conception automatisé

Processus de mise à jour automatisé

Processus de déploiement automatisé

Intégré dans l'infrastructure pour les besoins de développement de plusieurs éléments communs :

o MVC framework (xmlEngine, httpBaseServlet, sqlc) o Interface d’utilisateurs Ajax-JavaScript (intégration avec Dojo) o Une couche d’accès aux données (basé sur la technologie Hibernate) o Serveur web conteneur servlet (intégration avec Apache-Tomcat et

support autre J2EE implémentations) o Reporting (intégration avec le moteur Jasper-reports) o Services web (intégration avec Apache-Axis) o Emailing (intégration avec Sun mail) o L’ordonnancement des processus (intégration avec Quartz)

Le Framework de développement MDD.

Le support d’une interface utilisateur multilingues.

Incorporé avec une modèle de sécurité.

Incorporé avec une model d’entreprise.

Support La multidevises.

Support un schéma de plusieurs plans comptables.


Figure 57 : les interactions entres les couches d’Openbravo

Justement, il faut reconnaître que même si elle est sans doute la meilleure plateforme Open

Source actuellement disponible, la plateforme actuelle d'OpenBravo a quelques limites. Là

encore, OpenBravo offre une vision claire et rassurante avec même un prototype sur SVN de sa

nouvelle plateforme applicative nommée "Green".

II. Java - Lightweight J2EE :

Openbravo utilise Java come son back-end langage de programmation. Pourquoi Java ?

Il existe plusieurs raisons pour choisi Java come un langage server –side :

Sa nature d’Open Source.

Un large soutien à l'entreprise au niveau du développement.

Une architecture mûre pour les applications web

Openbravo suit Java 2 Edition Entreprise architecture (J2EE) sans faire usage du conteneur

EJB. Au lieu de cela (EJB) Openbravo utilise l’infrastructure lightweight (léger) pour

implémenter l’accès aux données et à la logique des affaires (Business Logic). En Openbravo

(version 3), Il a livré une nouvelle Couche d'Accès de Données (DAL : Data Access Layer)

basées sur Hibernate qui fournit un puissant mais toujours léger, persistant mécanisme.

La figure suivant montre l'architecture envisagée pour la couche d'accès aux données DAL

dans Openbravo ERP.


Figure 58 : Data Access Layer d’Openbravo ERP 3MP11

III. Support de multiple base de données :

Openbravo est préposé pour éviter le verrouillage de vendeur dans n’importe quelle

technologie incluant la base de données. Openbravo marche sur PostgreSQL (8.4) ou Oracle

SE (10g-11g).

Dans les prochaines versions Openbravo aspire à être indépendant de la base de données. La

nouvelle couche d’accès de données (DAL) basée sur Hibernate est la première étape dans

cette transition.

IV. La modularité d’Openbravo ERP

La notion de la modularité est une nouvelle capacité introduite dans Openbravo

(spécialement les versions récents), qui permet de définir les packages des fonctionnalités

additionnelles, les extensions de configurations indépendamment du cœur du produit.

La modularité change la façon dont il peut être adapté aux besoins des utilisateurs. Au lieu la

personnalisation du code afin de correspondre a ces besoins, il est possible d'étendre ces

fonctionnalités à l'extérieur. Cette approche a plusieurs avantages, les plus importantes sont :

Permettre a un pur développement distribué : une nouvelle fonctionnalité, qui peut

être développé grâce a des modules d’une manière bien distribué. Les développeurs

d’un module peuvent travailler séparément des autres, et le cycle de vie de ce module


est indépendant des autre modules.

Forte amélioration de la maintenance du code : Le développent par modules veux

dire packaging d’une façon indépendante. Avec une définition correcte des

dépendances entre les modules et les processus de maintien de l'API stable le

processus de la mise à jour d’une instance peut être effectué en un simple click de la

part de l’utilisateur.

Encourage le partage et la réutilisation des nouvelles fonctionnalités : le

développement modulaire facilite et simplifier le partage cette nouvelle fonctionnalité

avec d’autres personnes. Pour partager leurs modules, ils ont juste besoins de publier

leur package (le forge Openbravo (Central Repository)).

V. Caractéristiques :

Openbravo ERP possède de nombreuses fonctions habiles qui le démarquent des autres outils de

gestion et qui en font le logiciel parfait des entreprises. Voici une présentation de quelques uns de

ces aspects…

Alertes : Des avertissements peuvent être programmées ils s’affichent clairement lors de la

connexion de l’utilisateur au logiciel, pour le prévenir qu’un certain statut est atteint

(diminution de stock, les impayés d’un client, etc.).

Articles associés : Les utilisateurs peuvent accéder à toutes les données du logiciel

associées à n’importes quelles autres de ce dernier, à condition qu’elles soient autorisées.

Trouver des factures correspondantes, des contacts ou tous autres bons d’expédition est

très simple. Ils ont toujours la possibilité d’un aperçu à 360° de toutes les données du

programme.

Rapport dimensionnel : Afin d’obtenir des données cruciales incorporées de l’entreprise,

les utilisateurs peuvent créer des rapports sous formats personnalisés grâce à plusieurs

champs et catégories. De nouveaux rapports peuvent être ajoutés à l’ERP en à peine

quelques heures. Un accès facile aux données est un élément crucial à l’accomplissement

de l’application d’un ERP, et Openbravo est parfaitement adapté.

Concordance et Partage : Exporter un fichier unique ou une série de fichiers directement

du logiciel vers Excel, CSV, ou PDF. Les fichiers exportés peuvent aussi être joints à

n’importe quel fichier du logiciel pour un retrait et une gestion facile.

Mail : En un clic, directement depuis l’ERP, ouvrez une page mail pour envoyer des

données ou des fichiers joints à vos clients ou fournisseurs. Les adresses mails peuvent être


paramétrées pour chaque utilisateur du logiciel.

Navigation par Clavier : En plus d’être une application sur internet, Openbravo a été

conçu de manière à être opérationnel depuis le clavier sans utiliser la souris. Les utilisateurs

avancés peuvent gagner du temps et effectuer leurs tâches quotidiennes rapidement.

Modulaire : Créer facilement des modules tiers ou d’extensions ; ou parcourir le répertoire

et opter pour l’installation de la fonctionnalité partagée créée par d’autres utilisateurs. La

fonctionnalité de tiers partagée comporte des rapports, des mots de liaison, des insertions

de produits et des contenus types supplémentaires tels les taux d’imposition et les

caractéristiques des produits. Cette capacité donne accès à un plus grand nombre de

fonctionnalités tout en diminuant de beaucoup les frais d’application de l’ERP.

Paramétrage simple : Chaque organisation est unique et la conception de produit est

facile à développer et à paramétrer afin de correspondre parfaitement à vos besoins. Grâce

au développement d’une maquette avant lancement, vous pouvez personnaliser les

fonctionnalités existantes et les règlementations professionnelles, et ajouter de nouvelles

fonctionnalités sans aucune programmation. Openbravo ERP peut contribuer à vous

distinguer de la concurrence.

Rôles : Openbravo est accessible à des utilisateurs de profils variés dont les fonctions sont

personnalisées à leurs tâches de travail, et qui protègent toutes les données qu’ils voient et

modifient. Au travers des "rôles", vous pouvez assigner les pages accessibles depuis le

menu aux utilisateurs de l’entreprise, et distinguer celles en mode Modification ou Lecture

seule. Langue et autres configurations du système peuvent aussi être paramétrées pour

chaque utilisateur. Le français et l’anglais sont en standard, mais aussi bien d’autres langues.

Extensibilité : Openbravo peut être distribué sur un seul serveur ou sur un groupe,

desservant des milliers d’utilisateurs. Les serveurs peuvent être situés sur place, dans le

centre des données, ou dans le cloud – par exemple sur Amazon EC2.

Multi-X: Multi-langues, multi-devises, schémas de multi-comptabilités (dont comptabilité

française, US et Suisse), multi-entreprises, etc. Openbravo ERP est prêt à desservir des

environnements multinationaux, multi-sites, multi-clients.

Audit : Comme organisation de solutions logicielles, toutes les données du programme

peuvent être vérifiées et retracées jusqu’à l’auteur de sa création, ou jusqu’au dernier

utilisateur les ayant modifié.

VI. Web service REST pour la synchronisation :


Figure 59 : web service REST du module synchronisation POS

Rapport Master v5

Documents

Transcript of Rapport Master v5