Gestion d"une société de transit avec openerp

Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 1

�رة ا�� 105ا��


Dédicaces

Pour les grands sacrifices que tu as faits pour nous, Pour les nuits où tu es resté sans dormir pour veiller sur nous,

Pour la formidable mère que tu es

Toi qui es toujours fier de moi, Pour le symbole respectueux que tu es pour moi,

Pour le père que tu es

Nul mot ne reflète ma reconnaissance vers vous Pour votre temps et encouragement Pour le frère et sœur que vous êtes

Pour votre soutien

Vous membres de ma famille Je dédie ce travail


Remerciement

Avant d’entamer ce rapport, je tiens à témoigner ma profonde gratitude à toutes les

personnes qui ont participé de loin ou de près à l’élaboration de ce projet de fin d’études.

Mes sincères remerciements sont à adresser à Mr. Abderrahman ELKAFIL, directeur de

la société NEXTMA et mon encadrant professionnel, pour l’intérêt et le professionnalisme

avec lesquels il a suivi la progression de mon travail, et pour ces aides et ces conseils

fructueux qu’il n’a cessé de me prodiguer durant toute la durée de mon Projet de Fin

d’Études.

Je tiens à exprimer ma profonde gratitude à Mr. Kamal Eddine EL KADIRI, mon

encadrant universitaire et responsable du Master Spécialisé : Qualité du Logiciel à la Faculté

des Sciences de Tétouan, pour son excellent suivi, ses remarques pertinentes et ses

recommandations fortes enrichissantes dont j’ai bénéficié tout au long de ce stage,

qu’il trouve, ainsi, mes vifs remerciements et mes sentiments les plus respectueux.

Je remercie tout particulièrement Mr. Mohamed KHALDI, professeur à la Faculté des

Sciences de Tétouan pour sa disponibilité, ses nombreux conseils et ses indications

précieuses qui m’ont permis de mener mon travail à bien.

Mes vis remerciements vont également à tout le cadre professoral de la faculté des

sciences de Tétouan, pour la formation prodigieuse qu’il nous a prodiguée.

Que messieurs les membres de jury trouvent ici l’expression de ma reconnaissance

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.

Hatim EL BOUANANI


Résumé

On ne présente plus les logiciels libres, aujourd’hui reconnus pour leur qualité et leur

ouverture. Ils ont démontré leur efficacité dans plusieurs domaines, notamment Internet, avec

par exemple, le serveur web Apache et le système d’exploitation Linux. Aussi, de nombreuses

entreprises et gouvernements ont commencé la migration de leurs systèmes d’information

vers des solutions libres.

En conséquence, on commence à trouver ces logiciels dans des secteurs

traditionnellement réservés aux logiciels propriétaires, en particulier Les ERP (en anglais

Enterprise Resource Planning), aussi appelés Progiciels de Gestion Intégrés (PGI). Ainsi,

OpenERP, les GNU Entreprise, Compiere et autres viennent empiéter sur les terres de BAAN,

SAP, ORACLE, etc. Cependant, ce type d’application joue un rôle stratégique au sein des

entreprises qui les utilisent. Il requiert un très haut niveau de technicité et de compétences que

ces dernières ne sont pas prêtes à laisser aux mains de développeurs éparpillés aux quatre

coins du monde.

C’est pourquoi, comme pour les logiciels propriétaires, est apparue la nécessité d’avoir

des entreprises prestataires de services spécialisées en logiciels libres. Ce besoin s’est renforcé

avec la rationalisation des coûts liés aux systèmes d’information depuis l’éclatement de la

«Bulle Internet».

NEXTMA, société dans laquelle j’ai effectué mon stage de fin d’études du 16 mars au

01 juillet 2009, est une de ces nouvelles SSLL (Société de Services en Logiciels Libres). Elle

propose à ses clients un PGI basé sur le logiciel libre « OpenERP » pour lequel elle peut

développer des besoins spécifique pour chacun d’entre eux.

Au cours de ce stage, mon travail a consisté à comprendre le fonctionnement de

l’OpenERP, et à concevoir et développer un module de gestion de transit à l’aide de l'ERP

open source OpenERP. Ce stage m’a aussi permis de mieux comprendre comment fonctionne

une société de services et comment une SSLL peut vivre du logiciel libre.

Mots clés :

� ERP open source OpenERP ;

� Framework OpenObject ;

� Python ;

� XML.


Abstract

It is no longer open source software, today recognized for their quality and openness.

They have demonstrated their effectiveness in several areas, including the Internet, for

example, the Apache Web server and the Linux operating system. Also, many companies and

governments have begun migrating their information systems to open source solutions.

Accordingly, we begin to find these programs in areas traditionally reserved for

proprietary software, especially ERP (Enterprise Resource Planning), also called Integrated

Management Software (IMS). Thus, OpenERP, GNU Enterprise, Compiere and others from

encroaching on the lands of BAAN, SAP, Oracle, etc... However, this application plays a

strategic role within companies that use them. It requires a very high level of technology and

skills that they are not ready to leave in the hands of developers scattered around the world.

Therefore, as with proprietary software, has emerged the need for service providers

specializing in open source software. This need has increased with the rationalization of costs

associated with information systems since the bursting of the "Internet bubble".

NEXTMA, in which I conducted my internship graduation from 16 March to 30 June 2009, is

one of these new SSLL (in french Société de Services en Logiciels Libres). It offers its

customers an ERP system based on free software "OpenERP" for which it can develop

specific needs for each of them.

During this stage, my job was to understand the functioning of the OpenERP and realize

the design and dévloppement the Module transit Management using the open source ERP

OpenERP.

This internship also allowed me to better understand how a service company and how a

SSLL can live free software.

Keywords :

� ERP open source OpenERP ;

� Framework OpenObject ;

� Python ;

� XML.


Liste des abréviations

Sigle Définition

ERP Enterprise Resource Planning PGI Progiciels de Gestion Intégrés GNU General Public L icense SAP Systeme Anwendungen Produkte in der Datenverarbeitung(en anglais

Systems, Applications and Products in Data Processing) SSLL Société de Services en Logiciels L ibres PME Petites et Moyennes Entreprises CRM Customer Relationship Management BI Business Intelligence UML Unified Modeling Language 2TUP Two Track Unified Process RUP Rational Unified Process XP eXtreme Programming FOB Free On Board DHS Dirhams DUM Déclaration Unique de la Marchandise SADOC Système de l'Administration des Douanes et de l'Office des Changes ODEP Office d'Exploitation des Ports SI Système d’Information MVC Model View Controller XML eXtensible Markup Language RPC Remote Procedure Call LDAP L ightweight Directory Access Protocol OLAP Online Analytical Processing SGBD Système de Gestion de Base de Données IDE I tegrated Development Environment SWT Standard Widget Toolkit SQL Structured Query Language SGML Standard Generalized Markup Language HTML Hypertext Transfer Protocol DTD Document Type Definition


Liste des figures

Figure 1 : Cycle de développement en Y……………………………………… 20 Figure 2 : Diagramme de Gantt……………………………………………....... 21 Figure 3 : Circuit d’un dossier…………………………………………………. 26 Figure 4 : Les acteurs principaux du système 34 Figure 5 : Diagramme des cas d’utilisation Cycle de vie d’un dossier client….. 35 Figure 6 : Architecture technique d’un ERP……………………………........... 43 Figure 7 : Architecture modulaire d’un ERP………………………………....... 44 Figure 8 : Fonctionnalités de base d’un ERP………………………………….. 44 Figure 9 : les relations structurelles entre les trois objets……………………… 45 Figure 10 : Environnement d’exploitation de l’ERP open source OpenERP…… 46 Figure 11 : Diagramme de séquences du scénario Authentification……………. 51 Figure 12 : Diagramme de séquences du scénario Paramétrage………………… 51 Figure 13 : Diagramme de séquences du scénario Gestion des dossiers………... 52 Figure 14 : Diagramme de séquences du scénario Ventilation………………….. 53 Figure 15 : Diagramme de séquences du scénario Déclaration…………………. 54 Figure 16 : Diagramme de séquences du scénario Gestion de la facturation…… 55 Figure 17 : Diagramme de classes……………………………………………… 56 Figure 18 : Diagramme d’activité Cycle de vie d’un dossier…………………… 57 Figure 19 : Diagramme d’état Cycle de vie d’un dossier 58 Figure 20 : Page d’authentification…………………………………………....... 63 Figure 21 : Page de module…………………………………………………....... 64 Figure 22 : Page de dossier……………………………………………………… 64 Figure 23 : Détails de dossier…………………………………………………… 65 Figure 24 : Détails de ventilation de dossier……………………………………. 65 Figure 25 : Détails de déclaration de dossier……………………………………. 66 Figure 26 : Facture des ventes………………………………………………....... 67 Figure 27 : Interface de configuration de la base de données…………………… 75 Figure 28 : Interface de la connexion avec la base de données…………………. 75 Figure 29 : Interface de configuration du profil de l’entreprise………………… 76 Figure 30 : Interface d’authentification des utilisateurs………………………… 76 Figure 31 : Représentation d’une classe………………………………………… 78 Figure 32 : Représentation d’un objet………………………………………....... 78 Figure 33 : Association entre deux classes……………………………………… 78 Figure 34 : Agrégation entre deux classes………………………..…………....... 78 Figure 35 : Héritage entre deux classes…………………………………………. 79 Figure 36 : Diagramme de séquence……………………………………………. 79 Figure 37 : Diagramme de collaboration……………………………………....... 80 Figure 38 : Diagramme d’états transition……………………………………….. 80 Figure 39 : Diagramme d’activité organisé par acteur………………………….. 80 Figure 40 : Diagramme de cas d’utilisation…………………………………....... 81 Figure 41 : Diagramme d’objets……………………………………………........ 81 Figure 42 : Diagramme de classe……………………………………………….. 82 Figure 43 : Diagramme de composant………………………………………....... 82 Figure 44 : Diagramme de déploiement……………………………………........ 82


Liste des tableaux

Tableau 1 : Synthèse des méthodologies utilisées dans le cadre de développement Objet et Nouvelles technologies…………………….

18

Tableau 2 : Planning du projet…………………………………………………… 21 Tableau 3 : Scénario d’authentification………………………………………….. 36 Tableau 4 : Scénario de gérer dossier…………………………………………….. 37 Tableau 5 : Scénario de gérer ventilation………………………………………… 38 Tableau 6 : Scénario de gérer déclaration………………………………………... 39 Tableau 7 : Scénario de gérer facturation………………………………………… 40 Tableau 8 : Scénario de paramétrage…………………………………………….. 41


Tables des matières

Introduction générale…………………………………………….....................................

11

Partie I : Contexte général du projet………………………………………………………….. 13 Chapitre 1 : Présentation de NEXTMA……………………………………………….. 14 1. Présentation générale de NEXTMA……………………………………………… 14 1.1. NEXTMA en Bref………………………………………................................. 14 1.2. Prestations et services………………………………………………………… 14 2. Secteurs d’activités ……………………………………………………………... 16 Chapitre 2 : Présentation du projet……………………………………………………. 17 1. Présentation du projet……….………………………………................................. 17 1.1. Thème du projet………………………………………………………………. 17 1.2. La démarche à suivre…………………………………………………………. 17 2. Planning du projet…………………………………………………………………

20

Partie II : Etude fonctionnelle et technique…………………………………………………… 23 Chapitre 1 : Etude préliminaire………………………………………………………... 24 1. Projet de la gestion de transit……………………………………………………... 24 2. Procédures et circuit d’un dossier de transit……………………………………... 25 2.1 Circuit simplifié d’un dossier import/export………………………………….. 26 2.2 Le circuit d’un dossier………………………………………………………… 27 3. Problématique…………………………………………………………………….. 30 4. Synthèse…………………………………………………………………………... 31 Chapitre 2 : Etude fonctionnelle………………………………………………………. 32 1. Objectifs du projet………………………………………………………………... 32 2. Capture des besoins fonctionnels…………………………………………………. 33 2.1 Définition des acteurs du système…………………………………………….. 33 2.2 Cas d’utilisation du système………………………………………………….. 34 2.3 Description des cas d’utilisation………………………………………………. 36 Chapitre 3 : Etude technique…………………………………………………………... 42 1. Les ERP : Entreprise Resource Planning…………………………………………. 42 1.1 Architecture technique………………………………………………………… 43 1.2 Architecture modulaire………………………………………………………... 43 1.3 Les fonctionnalités de base……………………………………………………. 44 2. Solution de gestion intégrée OpenERP…………………………………………… 45 2.1 Environnement de développement……………………………………………. 45 2.2 Environnement d'exécution…………………………………………………… 46 2.3 Environnement d'exploitation…………………………………………………. 46 2.4 Framework OpenObject………………………………………………………..

47

Partie III : Mise en Œuvre du projet…………………………………………………………... 49 Chapitre 1 : Conception de la solution………………………………………………... 50 1. Conception des classes métiers…………………………………………………… 50 1.1 Diagrammes de séquences……………………………………………………. 50 1.2 Digramme de classes…………………………………………………….......... 56 Chapitre 2 : Réalisation de la solution………………………………………………… 59 1. Outils utilisés……………………………………………………………………... 59 1.1 IDE Eclipse……………………………………………………………………. 59 1.2 SGBD PostgreSQL.…………………………………………………………… 60 1.3 Langage Python.....……………………………………………………………. 60


1.4 Langage XML…………………………………………………………………. 61 2. Réalisation du système…………………………………………………………… 63 2.1 Exemples d’illustration………………………………………………………...

63

Conclusion et Perspectives……………………………………………………………… 68 Glossaire……………………………………………………………………………........ 70 Bibliographie……………………………………………………………………………. 71 Webographie…………………………………………………………………………….. 71 Annexes…………………………………………………………………………………. 72


Introduction générale

Les ERP open source 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é. Mais déjà, ils remontent l'échelle, et s'adressent à des PME de plus de 1000

salariés, que ce soit dans les secteurs industriel, distribution ou services.

Mon projet de fin d’études vise à concevoir et développer un module de gestion de

transit, qui sera incorporé et déployé sur un progiciel de gestion intégré open source, qui porte

le nom « OpenERP ».

SECORA-TRANS, Société générale de transit, opère au sein d’un secteur concurrentiel,

à forte agressivité commerciale et en pleine évolution. La mise en place donc des procédures

et d’une organisation de système d’information sort à l’évidence pour mieux répondre aux

exigences d’un tel environnement.

Pour cela, SECORATRANS s’est donné dés fin 2006, comme objectif prioritaire

l’acquisition d’un Progiciel de Gestion Intégrée open source, afin d'améliorer la qualité de la

gestion des dossiers, le partage de l'information dans le cadre des réseaux de gestion, la

communication interne, et d'assurer la traçabilité des documents et une rapidité dans leur

traitement, pour un meilleur suivi du circuit global des dossiers.

Alors mon projet de fin d’études s’articule à concevoir et développer un module de

gestion de transit pour SECORATRANS, afin de suivre et contrôler les dossiers.

Mon rapport s’axe principalement sur trois parties:

La première partie présente une vue générale sur mon projet de fin d’études, elle est

composée de deux chapitres: le premier est consacré à la présentation de l’organisme

d’accueil, quant au deuxième il présente les objectifs de mon projet de fin d’études et la

démarche suivie pour assurer son bon déroulement.

La deuxième partie est consacrée à l’étude fonctionnelle et technique, elle est constituée

de trois chapitres: le premier expose une étude préliminaire visant à donner une vue sur

l’existant, le deuxième présente l’étude fonctionnelle, à travers la capture des besoins

fonctionnels, les cas d’utilisations UML et leurs descriptions textuelles, et le troisième définit

l’architecture logicielle et le Framework utilisé.


La troisième partie est consacrée à la mise en œuvre du projet, elle s’articule autour de

deux chapitres: le premier est consacré à la conception des classes métiers en présentant les

différents diagrammes de séquences, le diagramme de classes, le diagramme d’activité et le

diagramme d’état, quant au deuxième il est consacré à la réalisation de la solution en

présentant les différents outils utilisés et quelques prises d’écran du système que j’ai réalisé.


Cette première partie présente une vue générale sur mon

projet de fin d’études intitulé « Conception et

Développement d’un module de gestion de transit à

l’aide de l'ERP open source OpenERP ». Elle se

compose de deux chapitres :

� Le premier chapitre est consacré à la présentation de

l’organisme d’accueil.

� Le deuxième chapitre présente les objectifs de mon

projet de fin d’études ainsi que la démarche suivie

pour assurer son bon déroulement dans les délais

fixés.

Partie

1 Contexte général du Contexte général du Contexte général du Contexte général du

projetprojetprojetprojet


Chapitre

Présentation de NEXTMA

1. Présentation générale de NEXTMA

1.1 NEXTMA en Bref

NEXTMA est une Société de Services en Logiciels Libres (SSLL) qui accompagne les

entreprises et institutions dans le choix de solutions open source ainsi que dans l'intégration,

le développement, l'adaptation aux besoins spécifiques, la maintenance et le support. Afin de

bénéficier des meilleures solutions libres dans la gestion des systèmes d'information,

NEXTMA offre aux PME marocaines des services qui sont orientés sur le modèle «

ONE STOP SHOPPING ». C'est-à-dire en offrant une gamme étendue des services

complémentaires sur mesure, car chaque entreprise à sa spécificité, afin qu'elles puissent faire

face aux échéances du libre échange et soient à niveau par rapport aux normes de qualité et de

performance internationalement reconnues.

1.2 Prestations et services

NEXTMA offre une large palette de prestations et de services basés sur des

composants libres adaptés aux systèmes et aux réseaux des clients. La principale tâche

de cette société est d’offrir des solutions sur mesure, en matière de formation et

d’assistance, concernant les problématiques relevant des systèmes d’informations,

moyennant des outils libres.

Dans ce chapitre, je présente de manière générale la société

NEXTMA en tant qu’organisme d’accueil où s’est déroulé

mon projet, en exposant ses domaines d’activités d’une façon

générale.


La gamme de services de NEXTMA est articulée autour de quatre axes majeurs qui

permettent d'accompagner les clients durant toutes les phases d'un projet afin d'en assurer sa

réussite.

� Support

En plus des offres de formations. La société propose aux équipes dédiées au

développement, des prestations de support d’aide à la maintenance, afin de réduire le

temps de résolution des interrogations ou des difficultés que les entreprises pourraient

rencontrer lors de la mise en œuvre de certains logiciels.

� Conseil

NEXTMA possède une équipe formée de consultants techniques et fonctionnels

qui assure soit dans le cadre de projets, soit en amont, des missions de conseil dans

les domaines suivants: gestion de contenu, travail collaboratif, dématérialisation des

procédures, migration vers le libre, architecture et dimensionnement d'applications basées

sur open ERP…etc.

� Développement

Il constitue le cœur métier de NEXTMA et comprend le développement sur la base de

logiciels libres, de portails collaboratifs Internet ou Intranet, avec des composantes de

publication web, de travail collaboratif, de gestion électronique de documents et de

workflow.

� Formation

L’offre des formations, techniques et fonctionnelles, permet d'accompagner les

organisations qui disposent d’équipes opérationnelles capables de mener à bien des projets.

Ces formations peuvent être établies sous forme de transferts de compétences, en phases

avals des projets


2. Secteurs d’activités

De part les multiples projets que NEXTMA a mené, elle a acquis un savoir

faire susceptible de lui permettre l’implantation de logiciels libres dans les différents secteurs.

� Enterprise Ressource Planning (ERP)

En français Progiciels de Gestion Intégré (PGI). NEXTMA est le partenaire officiel de

l’ERP open source Open ERP au Maghreb depuis 2006. Elle adapte celui-ci à la législation

marocaine et aux besoins spécifiques des entreprises.

� Customer Relationship Management (CRM)

NEXTMA propose l’offre SUGARCRM qui permet la gestion de la relation client.

� Business Intelligence (BI) ou informatique décisionnelle. � Intranet des entreprises et gestion des contenus

� Création d’identités visuelles et sites Internet institutionnels et e-Commerce

La solution proposée est SMARTSHOP qui une solution libre de e-commerce

(commerce électronique) qui s'appuie sur le gestionnaire contenu Joomla!

� Gestion électronique des documents

Il s’agit d’un système informatisé d’acquisition, classement, stockage, archivage

des documents.


Dans ce deuxième chapitre je présente mon projet de fin

d’études, ses objectifs ainsi que la démarche suivie pour son

déroulement dans les meilleures conditions.

Chapitre

Présentation du projet

1. Présentation du projet

1.1. Thème du projet

Mon projet de fin d’études vise à concevoir et développer un module de gestion de

transit pour les transitaires, afin de mettre en place des indicateurs pour suivre et contrôler les

dossiers des clients. Le module permettra alors de gérer le cycle de vie d’un dossier,

depuis l’ouverture jusqu’à la facturation de vente.

1.2. La démarche à suivre

Afin d’élaborer mon projet, j’ai choisi d’utiliser UML (Unified Modeling Language)

comme formalisme, et 2TUP (Two Track Unified Process) comme démarche. Dans cette

section, je commence par une brève présentation du langage de modélisation UML en

justifiant ce choix, et ensuite, je passe en revue les différentes étapes de la démarche 2TUP en

expliquant les raisons qui j’ai poussé à l’adopter. (Pour plus de détails sur le formalisme UML

voir l’annexe 2)


1.2.1 Le formalisme UML

UML est considéré comme le langage standard de conception orienté objet, il est un

formalisme et pas une méthode. Il s'en suit qu'il définit un ensemble d’éléments de

modélisation et une notation graphique pour modéliser les systèmes et ne décrit pas les étapes

à suivre pour le faire.

Les raisons qui m’ont poussé à adopter UML dans mon projet se résument en :

� UML offre un outil prêt à l'emploi basé sur une modélisation visuelle qui permet

d'échanger des modèles compréhensibles ;

� Si on développe avec des langages Orientés Objet, il est plus approprié de concevoir

avec des formalismes Orientés Objet.

1.2.2 Processus de développement

Le succès d’un projet dépend de l’adéquation du projet au processus de développement.

Le tableau suivant (Tableau 1) présente une synthèse des processus les plus en vogue dans la

communauté Objet et Nouvelles Technologies.

Tableau 1 : Synthèse des méthodologies utilisées dans le cadre de développement Objet et Nouvelles technologies

Description Points Forts Points Faibles

RUP Rational Unified Process

- Méthodologie centrée sur l’architecture et couplée aux diagrammes UML ; - Cible des projets de plus de 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 Programming

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

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.


On constate 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 la 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.

Le RUP couvre l'ensemble du processus en spécifiant les interactions entre chacune des

phases, XP se concentre sur la phase de développement, tandis que 2TUP fait une large place

à l'analyse et à l'architecture.

Ainsi, et en prenant compte des modalités de mon projet, le 2TUP semble le plus adapté

pour mener mon projet.

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

des aspects fonctionnels. Le processus en Y s'articule autour de 3 phases :

� une phase d’étude technique;

� une phase d’étude fonctionnelle;

� une phase de réalisation.


La figure ci-dessous (Figure 1) illustre les différentes branches du cycle de

développement en Y :

Figure 1 : Cycle de développement en Y

L'objectif de la branche technique est de rassembler les besoins techniques (sécurité,

intégration à l'existant,…) dans un dossier, élaborer une architecture logicielle et applicative

qui répond aux contraintes présentées dans le dossier technique et identifier les besoins en

frameworks techniques afin de palier aux manques de la technologie (formulaires de saisie

interactifs, outils de mapping Objet / Relationnel, …). Quant à la branche fonctionnelle, elle a

pour objectif de juger de la capacité des développeurs à intégrer l'architecture applicative à

monter en compétences sur les frameworks techniques, à comprendre la conception et à suivre

les règles de développement.


2. Planning du projet

Dés mon première réunion avec mon encadrant, il m’a proposé un planning prévisionnel

(Table 2) que j’ai ajusté par la suite et au fur et à mesure de l’avancement du projet. Les

tâches inscrites dans ce planning correspondent parfaitement aux phases du cycle du

développement Y.

Id Tâche Date de début Date de fin Durée

1 Autoformation / Formation :

� Langage de programmation Python ;

� Framework d’OpenERP OpenObject ;

� Fonctionnement d’OpenERP.

16/03/2009 04/04/2009 20j

2 Etude de l’existant 06/04/2009 20/04/2009 11j

3 Etude fonctionnelle 21/04/2009 28/04/2009 6j

4 Etude technique 29/04/2009 05/05/2009 5j

5 Conception de la solution 06/05/2009 18/05/2009 9j

6 Réalisation 19/05/2009 26/06/2009 28j

7 Validation et tests 29/06/2009 30/06/2009 2j

8 Finalisation du rapport 01/07/2009 02/07/2009 2j

Total 83j

Tableau 2 : Planning du projet

Figure 2 : Diagramme de Gantt


Dans sa globalité, le sujet consiste à concevoir et développer un module de gestion de

transit à l’aide de l’ERP open source OpenERP pour les transitaires. Pour la bonne conduite

du projet, le processus adopté est le processus 2TUP vu qu’il offre l’avantage d’effectuer en

parallèle deux études technique et fonctionnelle avant d’attaquer la conception de la solution.

La partie suivante sera consacrée à l’étude fonctionnelle et technique en plus d’une étude

préliminaire.

Dans cette partie, il était question de présenter le contexte général du projet permettant

d’avoir une idée plus claire sur le cadre entourant mon projet, afin de découvrir les

différentes parties qui suivent avec une vision plus claire.


La deuxième partie de ce rapport est consacrée à l’étude

fonctionnelle et technique. Elle s’articule autour de trois

chapitres :

� Le premier chapitre présente une étude préliminaire

visant à donner une vue sur l’existant à

SECORATRANS où j’ai fait l’étude de

l’existant.

� Le deuxième chapitre présente l’étude fonctionnelle, à

travers la capture des besoins fonctionnels, les cas

d’utilisation UML et leurs descriptions textuelles.

� Le troisième chapitre définit l’architecture logicielle

du système et le Framework utilisé.

Partie

2 Etude foncEtude foncEtude foncEtude fonctionnelle tionnelle tionnelle tionnelle

et techniqueet techniqueet techniqueet technique


Chapitre

Etude préliminaire

1. Projet de la gestion de transit

SECORA-TRANS, est une société générale de transit où j’ai fait l’étude de l’existant,

opère au sein d’un secteur concurrentiel, à forte agressivité commerciale et en pleine

évolution, la mise en place donc des procédures et d’une organisation de système

d’information sort à l’évidence pour mieux répondre aux exigences d’un tel environnement.

Les moyens mis en place pour exercer les formes de coordination au niveau de la

direction tout en laissant au personnel leur autonomie, sont de trois sortes :

� Le contrôle de performance, d’où une gestion par objectif ;

� La supervision directe, d’où la standardisation et la formalisation de toutes les

procédures de travail ;

� Le travail de groupe pour une polyvalence des collaborateurs et un système de

résultat.

Ces moyens réduisent la surface de contrôle du sommet stratégique. Les qualifications

professionnelles requises et la formation continue y contribuent pour beaucoup.

En outre toute cette organisation ne peut donner ces meilleurs fruits que si elle est

accompagnée d’un système d’information bien rodé. Cela ne peut se faire qu’à l’aide d’un

Progiciel de Gestion Intégré open source qui permettra :

� D’assurer une coordination entre tous les intervenants de l’équipe ;

Dans ce chapitre je présente une étude préliminaire sur le projet

en commençant par l’étude de l’existant, la problématique et

enfin une synthèse.


� De suivre toutes les opérations effectuées par les intervenants en temps réel ;

� D’avoir des tableaux de pilotage retraçant toute l’activité ;

� D’avoir un archivage et accès aux documents et aux informations sécurisé et

rapide.

Pour faire face à l’évolution des structures et des technologies du commerce

international, SECORA-TRANS a lancé d’une manière successive depuis 5 ans une série de

logiciels afin de mieux répondre à ces problèmes de gestion interne, je peux citer à titre

d’exemple :

� le logiciel « Gestion des dossiers » : qui sert seulement à l’archivage des dossiers

validés non encore facturés.

� le logiciel « Gestion de Ventilation » : c’est un logiciel utilisé par le déclarant

afin de répartir la valeur totale déclarée entre plusieurs articles d’une même

facture soumis à un même régime douanier ;

� le logiciel « Gestion de la facturation » : c’est un logiciel utilisé par l’employé

afin de l’aider à Facturer et suivre le paiement des clients.

2. Procédures et circuit d’un dossier de transit

Le système actuel est basé sur les registres manuels, ainsi que des applications métiers

ne communiquant pas entre elles en plus des états et des tableaux réalisés sur Excel ou word.

Le processus du métier est décrit dans les lignes qui suivent :


2.1 Circuit simplifié d’un dossier import/export

Figure 3 : Circuit d’un dossier

Déclarant Déclaration de la marchandise

Opératrice de saisie Saisie de la déclaration en détail

Commis Dédouanement des produits

Agent de facturation Etablissement de la facture clients :

Comptable Contrôle et suivi des dépenses et factures clients

Secrétaire II Ouverture et suivi des dossiers

import/export

Secrétaire I Réception des documents


2.2 Le circuit d’un dossier 2.1.1 Réception des documents «la secrétaire I »

Réception par fax, par courrier de l’ordre de transit et des documents qui

l’accompagnent (avis d’arrivée + factures fournisseur,…) afin de permettre au transitaire de

prendre les dispositions nécessaires à la déclaration (la date de réception ainsi que les

documents reçus).

Parfois le client se présente directement au bureau de la société muni des documents

nécessaires (factures fournisseur, liste de colisage, titre d’importation, certificat d’origine,

titre de transport, …).

Dans ce cas, «la secrétaire I» lui délivre un accusé de réception sur lequel est mentionné

le jour de réception, ainsi que les documents reçus, et garde une copie.

2.1.2 Ouverture d’un dossier «la secrétaire II»

Tout d’abord, elle vérifie les documents reçus et s’assure de leur caractère original,

relève les documents manquants au dossier, qui peuvent être source de blocage.

Elle procède par la suite à leur enregistrement sur un registre contenant les indications

suivantes :

� le numéro de dossier (numéro de classement+l’année) ;

� le nom de l’importateur ;

� le bureau de dédouanement (ex casa port, casa extérieur...) ;

� la désignation de la marchandise ;

� la valeur de la marchandise en dirham et en devise ;

� le fournisseur.

Sur ce registre sont mentionnés par la suite, le poids de la marchandise ainsi que la

nature des colis. Le régime douanier attribué à la marchandise ainsi que le numéro de la DUM

doivent également être enregistrés sur ce registre (après la validation du dossier).

Elle ouvre enfin un dossier sous un numéro et le remplit en fonction des documents

reçus, Elle doit mentionner (sur le dossier) les indications suivantes :

� la date de réception des documents ;

� le nom et l’adresse du destinataire des marchandises ;


� le nom et l’adresse de l’expéditeur des marchandises ;

� la désignation de la marchandise ;

� les documents manquants.

Après la réception du bon à délivrer, elle complète les énonciations manquantes à

savoir :

� Date d’arrivée ;

� Les marques, numéros, espèces et nombre des colis ;

� La nature et le poids brut des marchandises ;

� Le numéro du titre de transport ;

� Le dernier port ou aéroport (la provenance).

Le numéro du titre d’importation doit également figurer sur le dossier après sa

domiciliation.

2.1.3 Déclaration de la marchandise « le déclarant »

Il s’agit pour le déclarant de procéder à :

� Exploitation de dossier par «les secrétaires» ;

� Identification de tous les éléments lui permettant d’établir la déclaration en détail

et de choisir le régime douanier, en fonction de l’usage que l'opérateur

économique souhaite réserver à sa marchandise ;

� Désignation des nomenclatures : recherche de la nomenclature (numéro et

libellé) correspondante à chaque produit figurant sur la facture ;

� Calcul de la contre valeur en monnaie nationale : par l’application du cours de

change du jour de la déclaration ;

� Calcul du poids net total et poids brut total ;

� Calcul du montant à imputer sur le titre d’importation.

La valeur totale à déclarer Prix FOB en devise * cours de change en DHS + montant du fret en devise * cours de change + Frais d’assurance (0.3% du montant coût et frêt en dirhams + Frais d’aconage (23.4 dhs la tonne du poids brut sauf si le montant de l’aconage est indiqué sur la facture de la compagnie de transport)


2.1.4 La déclaration en détail (DUM) «L’OPÉRATRICE DE SAISIE»

Le logiciel SADOC permet la saisie, la modification et la consultation des éléments de

la déclaration, il permet également la consultation des déclarations sommaires. Avant de

commencer la saisie du dossier, elle lui donne un numéro de répertoire.

Une fois les énonciations de la DUM saisies, l’opératrice a deux possibilités. Soit mettre

la déclaration en «ATTENTE» dans ce cas le système procède à son enregistrement provisoire

et les données saisies sont gardées en mémoire pour une durée limité avant qu’elles soient

automatiquement effacées. Soit de valider définitivement la déclaration ce qui vaut signature

et enregistrement définitif par le système. Une déclaration signée et enregistrée définitivement

ne peut être ni supprimée ni modifiée par l’opératrice. Mais elle peut être consultée.

2.1.5 La facturation : « Agent de facturation »

Une fois le processus de dédouanement achevé, le dossier est transmis à l’agent chargé

de la facturation. La facture reprend tous les frais engagés qui sont à la charge de client. Une

fois établie une copie est adressée au client avec toutes les pièces justificatives (facture

d’échange, facture magasinage, récépissé d’envoi des lettres de réserve,…) en plus d’une

copie de l’exemplaire redevable de la DUM et l’engagement d’importation imputé. Et l’autre

copie est transmise au service comptabilité.

La facture client comprend plusieurs frais dont on peut citer à titre d’exemple :

� frais d’ouverture de dossier ;

� manipulation ;

� frais de transport local ou national ;

� frais d’échange ;

� aconage ODEP ;

� les lettres de réserves ;

� droit de douane ;

� frais de surestarie ;

� frais de magasinage (en cas de dépotage) ;

� honoraires.


3. Problématique

Le système actuel de la société SECORATRANS est basé sur les registres manuels ainsi

que des applications métiers ne communiquant pas entre elles en plus des états et des tableaux

réalisés sur Excel ou word.

Les outils existant aujourd’hui sur le marché proposent des fonctionnalités nettement

plus avancées et mieux adaptées aux besoins de SECORATRANS, en terme de pilotage,

d’intégration de données, de partage d’information en temps réel... Ils permettent également

de répondre aux exigences des clients et partenaires de l’entreprise.

Dans un tel contexte, l’entreprise avait plus que jamais besoin d’un nouveau système qui

correspond le plus à ses exigences.

Car, les premiers diagnostics qui ont été effectués ont fait ressortir que les applications

informatiques actuelles, qui malgré leur contribution effective à la gestion de l’entreprise,

restent marqués par des insuffisances techniques, stratégiques et organisationnelles.

Les principales faiblesses diagnostiquées sont :

� L’existence de diverses applications informatiques isolées ;

� un recours à l’informatique insuffisamment développé (exemple : opération du

contrôle et du suivi des dossiers non informatisée…) ;

� Coexistence de procédures manuelles avec les applications informatiques;

� Les systèmes informatiques n’intègrent pas toutes les demandes fonctionnelles

exprimées par l’entreprise ;

� Une large utilisation de documents non informatisés (les chemises import/export

(vert et jaune), fiches de dépense, chèque, bulletin de réception…) ;

� Manque de traçabilité ;

� Insuffisance du contrôle et du suivi des dossiers ;

� l’absence de procédure automatisée de recoupement d'information utilisant un

identifiant unique;


4. Synthèse

Pour remédier aux problèmes cités ci-dessus, et pour améliorer le système de suivi des

dossiers pour les transitaires, SECORATRANS cherche à mettre en place un ERP open

source OpenERP qui assure la gestion de l'ensemble des services de l’entreprise depuis la

réception des documents jusqu’au recouvrement : réception des documents, suivi et contrôle

des dossiers.

Cette étude préliminaire m’a permis de bien cerner le sujet et de dégager les principales

fonctionnalités utiles pour la mise en place de mon projet. J’entamerai dans le chapitre suivant

l’étude fonctionnelle.


Etude fonctionnelle

1. Objectifs du projet

La solution recherchée va couvrir l’ensemble des activités de l’entreprise : suivi des

dossiers, la ventilation de la valeur déclarée, la déclaration de la marchandise et l’archivage

des dossiers facturés, suivi et contrôle des dossiers, et devra permettre la dématérialisation de

l’ensemble des opérations de l’entreprise.

En effet, ce projet doit aussi avoir pour objectif :

� la réalisation d'une application informatique unique pour la gestion de l'ensemble

des services de l’entreprise depuis la réception des documents jusqu’au

recouvrement : réception des documents, suivi et contrôle des dossiers.

� mettre en place un système commun et partagé répondant aux attentes de

l’ensemble des utilisateurs de l’entreprise

� l’introduction d’un mot de passe pour chaque utilisateur, choisi par lui-même. Et

qui une fois attribué, il n’engage que la personne titulaire de dit mot de passe.

� mettre en place une solution complète de serveur d'entreprise comprenant des

fonctions de messagerie et de collaboration

� un stockage de données protégé et centralisé.

Ce chapitre présente l’étude fonctionnelle du projet qui

comprend la capture des besoins fonctionnels et la

formalisation de ces besoins en cas d’utilisation UML.

Chapitre


2. Capture des besoins fonctionnels

Après avoir cerner les besoins de la société dans le chapitre précédent (étude

préliminaire), je vais formaliser ces besoins en cas d’utilisation en définissant les acteurs

interagissant avec le système.

2.1 Définition des acteurs du système

À ce stade je vais déterminer les six acteurs principaux interagissant avec le système

� Utilisateur

Cet acteur accède de manière sécurisée au système, et consulte les contenus.

� Secrétaire de réception des dossiers

Cet acteur accède de manière sécurisée au système, recevoir les contenus, et c’est celui

qui valide ou pas les dossiers des clients.

� Déclarant

Cet acteur accède de manière sécurisée au système, ventile les dossiers, et c’est celui qui

fait la déclaration des marchandises.

� Opérateur de saisie

Cet acteur accède d’une manière sécurisée, obtient le numéro de la D.U.M de la

marchandise.

� Agent de facturation

Cet acteur accède d’une manière sécurisée, établit la facture des ventes des dossiers

clients.

� Administrateur

Cet acteur attribue les droits d'accès aux utilisateurs, gère les utilisateurs (ajout,

modification, suppression d'un utilisateur), ainsi que le contenu et l’arborescence de

l’OpenERP.


Remarque :

L’opérateur de saisie n’est pas un acteur système car il n’interagie qu’avec le système

SADOC de la douane.

Figure 4 : Les acteurs principaux du système

2.2 Cas d’utilisation du système

Le diagramme des cas d’utilisation permet de structurer les besoins des utilisateurs et les

objectifs d’un système. En effet, il identifie les acteurs et leurs interactions avec le système.

Afin de mieux comprendre tous les volets du système, je l’ai décomposé en huit cas

d’utilisations. Par la suite, je vais détailler les principaux cas d’utilisation.

La figure ci-dessous (Figure 5) représente le diagramme des cas d’utilisation :


Figure 5 : Diagramme de cas d’utilisation Cycle de vie d’un dossier client


2.3 Description des cas d’utilisation

2.3.1 Cas d’utilisation Authentification

Le tableau ci-dessous (Tableau 3), représente la description de ce cas d’utilisation:

Code CU_Authentification

Nom Authentification

Acteurs système Tous les acteurs

Objectif/Résultat Accès aux fonctionnalités attribuées.

Description Ce scénario permet à tout acteur de s’identifier auprès du système et d’accéder aux

fonctionnalités qui lui sont attribuées.

Pré condition Existence à dans la base de données du système

Action de l’acteur Action du système

1 Se connecter au système.

Scénario

authentification

2 Vérifier login et mot de passe, valider

et autoriser l’accès selon les droits.

1 Se connecter au système

2 Le système ne répond pas

1 Se connecter au système

Exceptions

2 Vérifier les informations de

l’utilisateur. Retour à 1 (login ou

password incorrect)

Fréquence A la demande.

Tableau 3 : Scénario d’authentification

2.3.2 Cas d’utilisation Gérer Dossier

Ce cas d’utilisation concerne la gestion des dossiers, opération effectuée par

l’Administrateur qui peut ajouter, modifier et supprimer un dossier, ainsi que la validation

d’un dossier.



Code CU_Gerer_Dossier

Nom Gérer Dossier

Acteurs système Administrateur

Objectif/Résultat Suivre et contrôler les dossiers clients.

Description Ce scénario permet de faire les opérations d’ajout, de modification et de

suppression d’un dossier client dans la base de données du système, ansi que la

validation et la clôture d’un dossier client.

Pré condition Authentification au système avec le compte Administrateur.


1 Saisir les informations de dossier à

ajouter.

2 Rechercher le numéro de dossier à

modifier.


supprimer.

4 Enregistrer les informations dans

la base de données du système.

5 Valider dossier

Scénario Gérer_Dossier

6 Etat dossier ouvert


ajouter.

2 Le système ne répond pas.


ajouter.

2 Données insuffisantes.


modifier, à supprimer et valider.

2 Le système ne répond pas.


modifier, à supprimer et à valider.

2 Erreur.

Exceptions


Tableau 4 : Scénario de gérer dossier


2.3.3 Cas d’utilisation Gérer Ventilation

Ce cas d’utilisation consiste à saisir les détails des différents articles de la marchandise

(nomenclature, quantité, poids, valeur).


Code CU_Gerer_Ventilation

Nom Ventilation de la marchandise.

Acteurs système Déclarant.

Objectif/Résultat Saisie des détails des différents articles de la marchandise.

Description Ce scénario permet de faire la saisie des articles qui seront utiles pour la

déclaration de la marchandise.

Pré condition Authentification au système avec le compte Déclarant.


1 Lister dossiers ouverts

2 Afficher liste dossiers

ouverts.

3 Choisir numéro dossier

4 Afficher dossier choisi

5 Ajouter ventilation

Scénario Gerer_Ventilation

6 Enregistrer les informations

dans la base de données du

système

1 Lister dossiers ouverts


3 Ajouter ventilation


Exceptions

5 Données insuffisantes pour

la ventilation

Fréquence A la demande

Tableau 5 : Scénario de gérer ventilation


2.3.4 Cas d’utilisation Gérer Déclaration

Ce cas d’utilisation consiste à calculer la contre valeur, le poids net total, poids brut total

et le montant à imputer sur le titre d’importation brut.


Code CU_Gerer_Declaration

Nom Déclaration de la marchandise

Acteurs système Déclarant

Objectif/Résultat Calcul des différents indicateurs de la marchandise

Description Ce scénario permet de faire le calcul de la contre valeur, le poids net total,

poids brut total et le montant à imputer sur le titre d’importation brut. qui

seront utiles pour la déclaration chez le système de la douane (SADOC).

Pré condition Authentification au système avec le compte Déclarant


1 Lister dossiers à déclarer

2 Afficher liste dossier à

déclarer



5 Déclarer dossier

6 Calculer paramètres

Scénario Gerer_Declaration

7 Etat dossier déclaré


2 Déclarer dossier


4 Données insuffisantes

pour le calcul

Exceptions

Calcul impossible dossier

(déjà déclaré)


Tableau 6 : Scénario de gérer déclaration


2.3.5 Cas d’utilisation Gérer Facturation

Ce cas d’utilisation reprend tous les frais engagés qui sont à la charge de client. Une fois

établie une copie est adressée au client avec toutes les pièces justificatives.


Code CU_Gerer_Facturation

Nom Facture des ventes

Acteurs système Agent Facturation

Objectif/Résultat Calcul des frais de dossier

Description Ce scénario permet de faire le calcul tous les frais engagés qui sont à la

charge de client

Pré condition Authentification au système avec le compte Agent Facturation


1 Lister dossiers déclarés

2 Afficher liste dossiers

déclarés



5 Facturer dossier

6 Calculer montant total

Scénario Gerer_Facturation

7 Etat dossier facturé


2 Facturer dossier


Exceptions

4 Données insuffisantes

pour la facturation


Tableau 7 : Scénario de gérer facturation


2.3.6 Cas d’utilisation Paramétrage

Ce cas d’utilisation concerne le paramétrage de l’application (la gestion des accès et la

gestion de contenu).


Code CU_PARAM_APPLICATION

Nom Définition des paramètres de l’application

Acteurs système Administrateur.

Objectif/Résultat Paramétrer l’application

Description Ce scénario permet de paramétrer l’application, la gestion des accès, la gestion de

contenus...

Pré condition Connexion avec le compte Administrateur


1 Choisir l’option Paramétrage du

Système.

2 Afficher la liste des paramètres.

3 Définir les paramètres.

4 Valider

Scénario

Paramétrage du

système

5 Sauvegarder

1 Définir les paramètres


1 Définir les paramètres

Exceptions

2 Paramètres désactivés


Tableau 8 : Scénario de paramétrage

Au terme de ce chapitre, j’ai achevé les différentes phases de la branche fonctionnelle

du processus Y. L’objet du chapitre suivant est l’étude technique du projet qui a pour but de

faire apparaître le choix de l’architecture du système et les frameworks techniques qui seront

utilisés.


Chapitre

Ce chaplitre détaille la branche technique du processus Y. Je

présente d’abord, la technologie utilisée, puis l’architecure logicielle

du système pour enfin le Framework et techniques utilisés

Etude technique

1. Les ERP : Entreprise Resource Planning

Les ERPs (Enterprise Resource Planning), aussi appelés Progiciels de Gestion Intégrés

(PGI), sont des applications dont le but est de coordonner l'ensemble des activités d'une

entreprise autour d'un même système d'information.

Les Progiciels de Gestion Intégrés proposent généralement des outils de Groupware et

de Workflow afin d'assurer la transversalité et la circulation de l'information entre les

différents services de l'entreprise.

Plus qu'un simple logiciel, un ERP est un véritable projet demandant une intégration

totale d'un outil logiciel au sein d'une organisation et d'une structure spécifique, et donc des

coûts importants d'ingénierie. D'autre part sa mise en place dans l'entreprise entraîne des

modifications importantes des habitudes de travail d'une grande partie des employés. Ainsi on

considère que le coût de l'outil logiciel représente moins de 20% du coût total de mise en

place d'un tel système.


1.1 Architecture technique

Figure 6 : Architecture technique d’un ERP

L'ERP est donc sur serveur. La majorité des ERP sont couplés à une base de données

ORACLE. De plus, les ERP sont compatibles packs Office, en particulier pour PowerPoint et

Excel. En effet, le premier étant utile pour personnaliser les bureaux ERP en fonction de

l'entreprise et le second pour effectuer les imports/exports de données. Enfin, les ERP sont

aussi compatibles avec des outils de reporting (CrystalReport en général). Le reporting étant

utilisé en particulier pour le module de gestion relation client, que nous verrons par la suite.

1.2 Architecture modulaire

Un ERP est un ensemble dont toutes les parties fonctionnent les unes avec les autres

d'où l'ergonomie et l'unicité des informations et donc la cohérence du SI.

Un ERP est modulaire dans le sens où il est possible de n'avoir qu'une ou plusieurs

applications en même temps, ou peu à peu. Les applications modulaires telles que les ERP

permettent d'être sûr de la compatibilité des modules entre eux, ils s'imbriquent comme des


blocs de Lego et fonctionnent ensemble (pas de vérification de compatibilité à

effectuer).Voici un exemple d'architecture modulaire qui tend à représenter tous les ERP:

Figure 7 : Architecture modulaire d’un ERP

L'architecture modulaire schématisée ci-dessus intègre plusieurs modules retouchant aux

grandes fonctions d'une entreprise : le module finance, logistique et e-commerce…

1.3 Les fonctionnalités de base

La figure ci-dessous (Figure x) représente les fonctionnalités de base d’un ERP :

Figure 8 : Fonctionnalités de base d’un ERP


2. Solution de gestion intégrée OpenERP

Open ERP est un progiciel de gestion intégré en licence libre, dont la grande souplesse

est idéale aussi bien pour les indépendants que pour les PME. Il couvre pratiquement

tous les secteurs d’activité : industrie, commerce, prestations de services, e-Commerce,

négoce, etc. Comme la plupart des logiciels libres, l'accessibilité, la flexibilité et la simplicité

sont les maîtres mots du développement.

2.1 Environnement de développement

Un MVC est une architecture de modèle utilisée en génie logiciel. Dans des

applications complexes qui présentent des lots de données aux utilisateurs, on

souhaite souvent séparer les données (modèle) et l'interface utilisateur (vue), de sorte

que les changements à l'interface utilisateur n'affectent pas le traitement des données,

et que les données peuvent être réorganisées sans changer l'interface utilisateur.

Le MVC résout ce genre de problème en découplant l'accès des données et la

logique des applications de la présentation des données et de l'interaction utilisateur,

en introduisant un composant intermédiaire : « le contrôleur ».

Dans open ERP, on peut appliquer cette sémantique de Model-View-Controller avec :

� Model : les modèles sont les objets déclarés dans OpenERP. Ils sont également

des tables PostgreSQL ;

� View : les vues sont définies en fichiers XML dans OPENERP ;

� Controller : le contrôleur est Python qui contrôle OPENERP.

Figure 9 : les relations structurelles entre les trois objets


2.2 Environnement d'exécution

Pour exécuter le code, l'OpenERP serveur doit être installée dans un serveur exécutant

MVC Framework Foundation et un groupe d'applications de tierce-partie que nous appelons

l'environnement d'exploitation. Les utilisateurs n'ont besoin de rien de plus qu'un OpenERP

web client ou OpenERP GTK client pour accéder aux différents modules de l’ERP.

2.3 Environnement d'exploitation

OpenERP a besoin d'un groupe bien connu d'applications tierces telles web services,

OpenERP web client ou OpenERP GTK client, et quelques autres utilitaires. Base de données

PostgreSQL est également nécessaire.

Le modèle est basé sur le standard SQL, et toutes ces applications peuvent être installées

aussi bien sur Linux ou Windows.

Figure 10 : Environnement d’exploitation de l’ERP open source OpenERP


2.4 Framework OpenObject

OpenObject est le Framework d'OpenERP, ou programme permettant la génération

d'OpenERP. Il est très souple et complet, et permet la création des applications de gestion,

quelles qu'elles soient.

Figure 11 : Framework OpenObject d’OpenERP

2.4.1 Rapidité de développement

Développer des applications de gestion avec OpenObject, bien plus qu'avec n'importe

quel autre outil de ce type. On crée un fichier Python contenant la description des champs et

les règles de gestion, un fichier XML décrivant les écrans, et le tour est joué. Bien sûr, il n'y a

aucune limitation aux codes, ceci étant écrit en Python, langage très riche.

Si on a besoin d'aller plus loin, OpenObject permet la création de Wizards (sous-

programmes), l'automatisation des tâches et leur planification, l'intégration de données.


2.4.2 Génération de rapports

Les rapports sont très simplement définis et intégrés, ce sous 2 formes :

� Rapports imprimables

Ils sont générés par le biais de reportlab. Les fichiers de génération de ces rapports

peuvent être transformés dans OpenOffice, puis importés rapidement.

� Ecrans

On peut définir tout type de tableau de bord, contenu des données, des listes, des

graphiques.

2.4.3 Gestion des workflows

Toutes les règles de gestion peuvent être définies. Le moteur de Workflows

d'OpenObject est très puissant, et permet des imbrications de règles complexes (ou simples),

qui peuvent être ensuite modifiées par le biais de l'application elle-même.

2.4.4 Communication avec des applications tierces

Toutes les communications entre OpenObject et les interfaces (même vers le client GTK

officiel) sont effectuées en XMLRPC. Les types d'objets, les écrans, les données sont

transmises par ce protocole. On a besoin d'intégrer les applications OpenObject à un portail

ou à une autre application.

Des connecteurs existent entre OpenObject et LDAP, ainsi qu'avec de nombreuses

autres applications Open Source (ezPublish, Asterisk, ...).

2.4.5 Business Intelligence

OpenObject est, dans sa version 5, entièrement doté des fonctionnalités pour effectuer

simplement le stockage des données dans des bases de données tierces (OLAP). Les rapports

sont donc le vrai reflet des activités, non de simples statistiques internes.

Ce chapitre a permis de détailler les différents choix techniques, à savoir la technologie

adoptée, l’architecture logicielle et le Framework utilisé. La partie suivante détaillera la

branche réalisation du processus Y.


Le contenu de cette partie s’articule sur

deux chapitres :

� Le premier est consacré à l’analyse et

la conception du module métier du

système, en présentant le diagramme

de classes, d’activité et d’état, quelques

diagrammes de séquences et la

structure du système.

� Le deuxième est consacré à la

réalisation du système, en présentant

quelques prises d’écran.

Partie

3 Mise en Œuvre du Mise en Œuvre du Mise en Œuvre du Mise en Œuvre du

projetprojetprojetprojet


Chapitre

Conception de la solution

1. Conception des classes métiers

1.1 Diagrammes de séquences

Le diagramme de séquences permet de mettre en relief les différents messages échangés

entre les objets et acteurs du système, et ce selon un point de vue temporelle. En effet, l'ordre

d'envoi d'un message est déterminé par sa position sur l'axe vertical (axe temporel) du

diagramme ; le temps s'écoule indépendamment des événements, "de haut en bas" de l’axe

vertical. Je vais dans la suite présenter quelques diagrammes de séquences.

1.1.1 Scénario Authentification

Ce scénario permet à l’utilisateur de se connecter au système en saisissant son login et

mot de passe. Le système vérifie ces informations qui sont stockées dans la base de données

et affiche la page d’accueil suivant les privilèges et le rôle de l’utilisateur.

La figure ci-dessous (Figure 12) représente le diagramme de séquences du scénario

d’authentification

Ce chaplitre détaille la phase conception de la branche réalisation

du processus Y. Je présente d’abord la conception des classes

métiers puis la structure du système.


Figure 12 : Diagramme de séquences du scénario Authentification

1.1.2 Scénario Paramétrage

Ce scénario est déclenché par l’administrateur du système, il consiste à faire la gestion

du contenu, et la gestion des comptes utilisateurs et les droits d’accès attribués à ces derniers.

La figure suivante (Figure 13), présente le diagramme de séquences du cas Paramétrage.

Figure 13 : Diagramme de séquences du scénario Paramétrage


1.1.3 Scénario Gestion des Dossiers :

Ce scénario est déclenché par l’administrateur du système, il consiste à faire la gestion

des dossiers, et le suivi et le contrôle de ces dossiers (Figure 14).

Figure 14 : Diagramme de séquences du scénario Gestion des dossiers

1.1.4 Scénario Ventilation :

La ventilation consiste à saisir les détails des différents articles (nomenclature, quantité,

poids, valeur)


Figure 15 : Diagramme de séquences du scénario Ventilation

1.1.5 Scénario Déclaration

La déclaration de la marchandise consiste à effectuer les opérations suivantes :

� Calcul de la contre valeur en monnaie nationale : par l’application du cours de

change du jour de la déclaration ;

� Calcul du poids net total et poids brut total ;

� Calcul du montant à imputer sur le titre d’importation.


Figure 16 : Diagramme de séquences du scénario Déclaration


1.1.6 Scénario Gestion de la facturation

La facture reprend tous les frais engagés qui sont à la charge de client. Une fois établie

une copie est adressée au client avec toutes les pièces justificatives (facture d’échange, facture

magasinage, récépissé d’envoi des lettres de réserve,…).

Pour créer un avoir, agent de facturation utilise le numéro de la facture correspondant à

la commande client.

Figure 17 : Diagramme de séquences du scénario Gestion de la facturation


1.2 Digramme de classes

Le diagramme de classes exprime, de manière générale, la structure statique d’un

système, en termes de classes et de relations entre elles.

Une classe permet de décrire un ensemble d’objets (attributs et comportements), tandis

qu’une relation ou association permet de faire apparaître des liens entre ces objets.

Le schéma ci-dessous (Figure 18) représente le diagramme de classe que j’ai établi pour

la conception du système:

Figure 18 : Diagramme de classes

Le schéma ci-dessous (Figure 19) représente le diagramme d’activité que j’ai établi pour

la conception du système:


Figure 19 : Diagramme d’activité Cycle de vie d’un dossier


Le schéma ci-dessous (Figure 20) représente le diagramme d’état que j’ai établi pour la

conception du système:

Figure 20 : Diagramme de classes

Ce chapitre avait pour objectif la présentation de la conception détaillée de la solution à

travers le diagramme de classes, d’activité, d’état, et quelques diagrammes de séquences.

Dans le chapitre suivant je exposerai les outils utilisés, et quelques exemples d’illustration.


Réalisation de la solution

1. Outils utilisés

Pour le développement du système je me suis basés sur l’ERP OpenERP et les

différentes technologies et Framework qu’il utilise, pour ajouter le système comme module au

sein de cet ERP j’ai eu recours à plusieurs outils comme l’IDE Eclipse et le SGBD

PostgreSQL, ainsi que la langage de programmation Python et la langage à balises extensible

XML, dont la présentation est détaillée dans les paragraphes suivants.

1.1 IDE Eclipse

Eclipse est un environnement de développement intégré dont le but est de fournir une

plate-forme modulaire pour permettre la réalisation des développements informatiques.

Eclipse utilise énormément le concept de modules nommés "plug-ins" dans son

architecture. D'ailleurs, hormis le noyau de la plate-forme nommé "Runtime", tout le reste de

la plate-forme est développé sous la forme de plug-in. Ce concept permet de fournir un

mécanisme pour l'extension de la plate-forme et fournir ainsi la possibilité à des tiers de

développer des fonctionnalités qui ne sont pas fournies en standard par Eclipse.

Eclipse possède de nombreux points forts qui sont à l'origine de son énorme succès dont

les principaux sont :

� L’extensibilité de plate-forme grâce au mécanisme de plug-ins ;

Ce chaplitre détaille la phase réalisation de mon projet. Je

présente d’abord, les outils utilisés et quelques prises d’écran du

système.

Chapitre


� La cohabitation entre plusieurs versions d'un même plug-in sur une même plate-

forme ;

� Le support de plusieurs langages grâce à des plug-ins dédiés : Python, Java,

Cobol, C, PHP, C#, ... ;

� Le support de plusieurs plates-formes d'exécution : Linux, Windows,…

� La rapidité d'exécution grâce à l'utilisation de la bibliothèque SWT ;

� La construction incrémentale des projets grâce à un compilateur interne qui

permet de compiler un code même avec des erreurs, de générer des messages

d'erreurs personnalisés…

1.2 SGBD PostgreSQL

PostgreSQL est un serveur de bases de données SQL (Structured Query Language) qui a

acquis une popularité croissante au fil des années, notamment par sa gratuité et son

exploitation sur Internet [www.Postgres.com].

Il consiste en un serveur de base de données SQL Multi-Utilisateur et multi-thread.

Nous avons utilisé PostgreSQL sous Linux, et nous avons utilisé l’utilitaire pgAdmin pour

l’utiliser à distance à partir d’un client Windows.

1.3 Langage Python

Python est un langage portable, dynamique, extensible, gratuit, qui permet (sans

l'imposer) une approche modulaire et orientée objet de la programmation. Python est

développé depuis 1989 par Guido van Rossum et de nombreux contributeurs bénévoles.

Détaillons un peu les principales caractéristiques du langage Python:

� Portable : Il est supporté par les différents systèmes d’exploitation ;

� Gratuit ;

� Simple : Il possède une syntaxe très simple tout en combinant des types de

données évolués (listes, dictionnaires…) ;

� Absence des pointeurs ;

� Il est orienté objet et supporte l’héritage multiple et la surcharge des opérateurs ;


� Dynamique : cette fonctionnalité est probablement la plus intéressante de

Python ;

� Extensible : on peut facilement l’interfacer avec des bibliothèques C existantes ;

� Python : gère ses ressources (mémoire, descripteurs de fichiers...) sans

intervention du programmeur, par un mécanisme de comptage de références ;

� Python : possède actuellement deux implémentations. L'une, interprétée, dans

laquelle les programmes Python sont compilés en instructions portables, puis

exécutés par une machine virtuelle (comme pour Java, avec une différence

importante: Java étant statiquement typé, il est beaucoup plus facile

d'accélérer l'exécution d'un programme Java que d'un programme

Python).L'autre génère directement du bytecode Java ;

� Dynamiquement typé ;

� Soutenu par la communauté d’utilisateurs qui tentent à l’évoluer.

1.4 Langage XML

XML (eXtensible Markup Language et en Français Langage à balises étendu, ou

Langage à balises extensible) était lancé en 1997 par la communauté SGML

(Standard Generalized Markup Language). XML est un langage simple et puissant de

description et d’échange de documents structurés de n’importe quel domaine de

données grâce à son extensibilité, il décrit cette structure à l’aide d’un système de balises.

Quelques points remarquables d’XML :

� Il apparaît comme un format d’échange de données universel ;

� Il a la possibilité de créer des nouvelles balises contrairement à HTML qui

définit un nombre limité ;

� Il garantit à ses utilisateurs l’indépendance de leurs documents de toute

technologie propriétaire ;

� Il unifie le monde du traitement de document et celui du Web.


Tout document XML se compose :

� D’un prologue qui peut contenir une déclaration XML, des instructions de

traitement et une déclaration de type de document, dont la présence est

facultative mais conseillée. Il contiendra un certain nombre de déclarations ;

� D’un arbre d’éléments, on parle d’élément père et d’élément fils. En fait

la partie essentielle d’un document XML sera toujours formée d’une hiérarchie

d’éléments qui dénote la sémantique de son contenu ;

� De commentaires et d’instructions de traitement, dont la présence est

facultative. Ils pourront, moyennant certaines restrictions, apparaître aussi bien

dans le prologue que dans l’arbre d’éléments.

Un document XML valide est forcément un document bien formé mais il obéit en plus à

une structure type définie dans une DTD (Document Type Definition).Une DTD peut contenir

� des déclarations d'entités générales ;

� des déclarations d'entités paramètres ;

� des déclarations de notations ;

� des déclarations d'éléments ;

� des déclarations de listes d'attributs ;

� des commentaires.


2. Réalisation du système

Dans les chapitres précédents j’ai pu dégager les différentes fonctionnalités auxquelles

doit répondre le système, ensuite j’ai formalisé ces fonctionnalités par des diagrammes UML

et j’ai spécifié les différents choix techniques. Dans la suite je présente le travail réalisé à

travers quelques exemples d’illustration.

2.1 Exemples d’illustration

Pour illustrer quelques cas de figures du système, je présente dans la suite quelques unes

de ses fonctionnalités.

2.1.1 La page d’authentification

Afin de donner la notion de sécurité au système la première page qui s’affiche (Figure

21) est la page d’authentification.

Figure 21 : Page d’authentification

Le module de gestion de transit est représenté comme la figure ci dessous (Figure 22):

� Configuration : contient les tables de base (Régime, Bureaux de douane,

Fournisseur, …) ;

� Gestion des dossiers : comporte les dossiers, la ventilation et la déclaration…


Figure 22 : Page de module

2.1.2 Le dossier

Le système offre la possibilité de créer un dossier en état ouvert afin de le suivre et de le

contrôler jusqu'à l’état de clôture (Figure 23).

Figure 23 : Page de dossier


Figure 24 : Détails de dossier

2.1.3 La ventilation

Le système nous permet de saisir les détails des différents articles de la marchandise

(nomenclature, quantité, poids, valeur) et le calcul du montant de chaque article ainsi que le

montant total de la marchandise.

Figure 25 : Détails de ventilation de dossier


2.1.4 La déclaration

Le calcul des différents indicateurs de dossier se base sur la ventilation cité

précédemment, le calcul de ses indicateurs se fait d’une manière automatique en offrant au

Déclarant un Process qui fait un calcul fiable et sûr des indicateurs (Figure 26).

Figure26 : Détails de déclaration de dossier


2.1.5 La facturation

La facture reprend tous les frais engagés qui sont à la charge de client (ouverture de

dossier, transport local,…). Une fois établie une copie est adressée au client avec toutes les

pièces justificatives (facture d’échange, facture magasinage,…).

Figure27 : Facture des ventes

Dans ce chapitre j’ai présenté la phase de réalisation du processus Y. Durant lequel j’ai

présenté l’IDE Eclipse, le SGBD PostgreSQL, le langage Python, le langage XML ainsi que

le Framework OpenObject utilisé, j’ai également illustré le travail élaboré par quelques prises

d’écran.


Conclusion et Perspectives

Persuadés et convaincus de l’importance de l’open source dans le monde de

l’informatique, j’ai opté dans mon stage de fin d’études pour la réalisation d’un

module de la gestion de transit à l’aide de l’ERP open source OpenERP.

Or, je juges très utile cette expérience de 4 mois que j’ai passé dans ce stage de

fin d’études. En effet, le fait de plonger dans les méandres d’OpenERP et lui-même une

motivante aventure où on est amené à intercepter tous les côtés d’un projet, parmi

lesquels on cite :

� Le côté fonctionnel: les rencontres continues avec le client pour spécifier les

besoins de métier permettent l’apprentissage de nouveaux concepts

économiques ;

� Le côté technique : il consiste à adapter les besoins fonctionnels du client en une

application hautement conviviale et facilement paramétrable ;

� Le côté commercial : il faut introduire convenablement le produit qui doit être

modulable et adaptable au besoin du client et lui accompagner d’un

commode marketing pour le commercialiser.

Ce stage a été pour moi un grand pas vers le milieu professionnel, où j’ai bénéficié

d’une excellente expérience qui m’a permis de concrétiser mes connaissances informatiques

acquises au cours des années d’études lors de la période de ma formation à la Faculté

des Sciences de Tétouan.

Aussi, ce projet m’a permis d’acquérir des valeurs indispensables pour le métier

d’un analyste développeur telles que la responsabilité, le travail d’équipe, l’adaptabilité à

l’environnement de l’entreprise et le sens d’analyse. Ces valeurs sont sans aucun doute les

bases de réussite dans le milieu professionnel.

A propos du projet, j’ai établi la base d’un module de gestion de transit, pour la

tenue du contrôle et du suivi des dossiers de l’entreprise en alliant souplesse d’utilisation,

convivialité et conformité aux transitaires marocaine.

Parmi les perspectives futures, signalons l’intérêt d’étendre le module de transit par

l’intégration des fonctionnalités suivantes :


� La gestion de transport;

� Le paramétrage des comptes comptables pour le transfert direct vers la

comptabilité.

Finalement, je souhaite que le projet de fin d’études soit la base d’une

implémentation du module d’OpenERP qui traite la gestion de transit sachant

qu’aucune expérience n’a été établie jusqu’à présent.


Glossaire

Bulle Internet : La Bulle Internet (dot-com bubble en anglais) ou bulle technologique est

une bulle spéculative, qui a affecté les « valeurs technologiques », c'est-à-

dire celles des secteurs liés à l'informatique et aux télécommunications,

sur les marchés d'actions à la fin des années 1990. Son apogée a eu lieu

en mars 2000.La Bulle Internet est liée à ce que l'on appelle l'immatériel

dans l'économie moderne.

Web Services : Un service web est un programme informatique permettant la

communication et l'échange de données entre applications et systèmes

hétérogènes dans des environnements distribués. Il s'agit donc d'un

ensemble de fonctionnalités exposées sur Internet ou sur un intranet, par

et pour des applications ou machines, sans intervention humaine, et en

temps réel.

Le standard SQL : SQL (Structured Query Language, traduisez Langage de requêtes

structuré) est un langage de définition de données (LDD, ou en anglais

DDL Data Definition Language), un langage de manipulation de

données (LMD, ou en anglais DML, Data Manipulation Language), et

un langage de contrôle de données (LCD, ou en anglais DCL, Data

Control Language), pour les bases de données relationnelles.

XMLRPC : XML-RPC est un protocole RPC (Remote procedure call), une

spécification simple et un ensemble de codes qui permettent à des

processus s'exécutant dans des environnements différents de faire des

appels de méthodes à travers un réseau.

LDAP : Lightweight Directory Access Protocol (LDAP) est à l'origine un

protocole permettant l'interrogation et la modification des services

d'annuaire. Ce protocole repose sur TCP/IP. Il a cependant évolué pour

représenter une norme pour les systèmes d'annuaires, incluant un

modèle de données, un modèle de nommage, un modèle fonctionnel

basé sur le protocole LDAP, un modèle de sécurité et un modèle de

réplication.

OLAP : Online Analytical Processing (OLAP) désignait à l'origine les bases de

données multidimensionnelles (aussi appelées cubes ou hypercubes)

destinées à des analyses complexes sur des données.

GNU : GNU est un projet de système d'exploitation composé exclusivement de

logiciels libres.


Bibliographie

OpenERP5 : OpenERP pour une gestion d’entreprise : efficace et intégré

Par Fabien PINCKAERS et Geoff GARDINER

Édition : 2

Publié en 2008

Python : Tutoriel Python Release 2.4.3

Par Guido van Rossum

Édition : 19 juillet 2006

Traduction française dirigée par Olivier Berger

PostgreSQL : Documentation PostgreSQL 8.2.5

The PostgreSQL Global Development Group

Cet ouvrage contient l'adaptation française de la documentation officielle de

PostgreSQL

XML : Introduction à XML

Par Victor Stinner

Édition : 16/09/2003

UML :

UML 2

Par Laurent AUDIBERT

Édition : 2007-2008

Webographie

Le site officiel de l’ERP open source Open ERP : http://openerp.com

http://openerp.tv

(Mars-juin 2009) Solution de gestion intégrée OpenERP : www.open-net.ch

(Mars-juin 2009) www.developpez.com : http://www.developpez.com

(Mars-juin 2009)

www.supinfo-projects.com : http://www.supinfo-projects.com/

(Mars-juin 2009)


Ce présent rapport comprend deux annexes

portant sur :

� Installation d’OpenERP sous Ubuntu

� Le formalisme UML

AnnexesAnnexesAnnexesAnnexes


Annexe 1Annexe 1Annexe 1Annexe 1 : : : : Installation d’OpenERP sous ubuntu

1. Installation de l’environnement

1.1 Installation des paquets nécessaires

Pour installer les bibliothèques nécessaires, vous pouvez effectuer les opérations

suivantes dans votre Shell:

sudo apt-get install python python-psycopg2 python-reportlab \ python-egenix-mxdatetime python-xml python-tz python-pychart \ python-pydot python-lxml python-libxslt1 python-vobject

1.2 Installation de PostgreSQL

Sur Ubuntu, installer le package PostgreSQL:

sudo apt-get install postgresql

Vous devez créer un utilisateur PostgreSQL. OpenERP utilisera cet utilisateur pour se

connecter à PostgreSQL.

createuser - createdb - no-createrole - pwprompt openuser

1.3 Flash plugin

Votre navigateur doit avoir le plugin Flash installé, car OpenERP Web utilise des

composants Flash.

Sudo apt-get install flashplugin-nonfree

2. Installation d’OpenERP

1.1 Installation d’OpenERP Server

OpenERP Server peut être téléchargé sur le site Web officiel de l’OpenERP :

ww.openerp.com.

L’OpenERP Server peut être installé très facilement à l'aide du fichier setup.py: tar -xzf openerp-server-5.0.0.tar.gz tar-xzf openerp-server-5.0.0.tar.gz cd openerp-server-5.0.0 cd openerp-server-5.0.0 sudo python setup.py install sudo python setup.py install


1.2 Installation d’OpenERP Client GTK

Pour installer les bibliothèques nécessaires, vous pouvez effectuer les opérations suivantes

dans votre Shell:

sudo apt-get install python python-gtk2 python-glade2 \ python-matplotlib python-egenix-mxdatetime python-xml python-hippocanvas python-matplotlib python-egenix-mxdatetime python-xml python-hippocanvas

L’OpenERP Client peut être téléchargé sur le site Web officiel de l’OpenERP

ww.openerp.com.

L’OpenERP Client peut être installé très facilement à l'aide du fichier setup.py:

tar -xzf openerp-client-5.0.0.tar.gz tar-xzf openerp-client-5.0.0.tar.gz cd openerp-client-5.0.0 cd openerp-client-5.0.0 sudo python setup.py install sudo python setup.py install

1.3 Installation d’OpenERP Web

Tout d’abord vous devez installer TurboGears ne effectuant les opérations suivantes dans

votre Shell:

Sudo apt-get install python-setuptools sudo easy_install TurboGears == 1.0.8 $ Sudo easy_install TurboGears == 1.0.8

Puis, Pour installer l’OpenERP Web, vous pouvez effectuer l’opération suivante dans

votre Shell:

Sudo easy_install-U openerp-web

Si tout marche bien vous pouvez maintenant accéder à OpenERP, pour cela on se

connecte en effectuant les opérations suivantes dans votre Shell:

openerp-server openerp-cilent

1.4 Création de la base de données

Si vous utilisez le client GTK, choisissez Fichier, Bases de données, Nouvelle base de

données. Entrez le mot de passe de super-administrateur et le nom de la nouvelle base de

données que vous créez.


Figure 27 : Interface de configuration de la base de données

La base de données est créée, mais sans aucun module installé. Il est important de s'y

connecter avec le compte administrateur afin de configurer les fonctionnalités dont on a

besoin.

Figure 28 : Interface de la connexion avec la base de données

Suite à la création de la base, open ERP se connecte avec le compte administrateur en

proposant une aide à la configuration par un système d'étapes.

Pour notre exemple, nous avons choisi le profil « service » car la plupart des entreprises en

ont besoin pour paramétrer les modules de comptabilité et de finance. (Voir figure x)


Figure 29 : Interface de configuration du profil de l’entreprise

Une fois toutes les étapes effectuées pour paramétrer le profile des entreprises, il ne reste qu'à

se connecter via l’interface d’authentification suivante :

Figure 30: Interface d’authentification des utilisateurs

3. Support

� http://www.openerp.com � http://www.axelor.com


Annexe Annexe Annexe Annexe 2222 :::: Le formalisme UML

Unified Modeling Language (UML) est considéré comme le langage standard de

conception orienté objet. Il permet de visualiser, concevoir et documenter les composants

statiques et dynamiques d’un système. Cette annexe présente une vue globale sur la notation

UML ainsi que ces différents diagrammes.

1. Le langage UML

UML est le fruit d’une fusion de plusieurs méthodes orientées objet. C’est un langage

de modélisation unifié favorisant :

� Une meilleure communication entre les intervenants dans un projet : il offre des moyens de

capture des connaissances sur un sujet à travers divers points de vues (ces points de vues

sont fournis par ses différents diagrammes) ;

� Une bonne compréhension du problème : le système à étudier sera traité suivant différents

angles et suivant les différents cas d’utilisation de ce système ;

� Une incorporation des meilleures pratiques d’ingénierie dans les différents domaines, ce

qui lui permet d’être adapté aux différents types de systèmes.

� UML permet aussi de suivre un projet dans ces différentes étapes :

� Spécification : il s’adresse à la spécification du système, il peut être utilisé pour modéliser

les besoins (le quoi) et l’architecture (le comment) ;

� Visualisation : les différents diagrammes donnent aux concepteurs une vue précise sur le

système avant sa réalisation ;

� Construction : les différents diagrammes et modèles établis durant la phase de spécification

et de conception servent de base pour la réalisation ;

� Documentation : les diagrammes utilisés durant les différentes phases pour communiquer

les connaissances entre les membres du projet, de la spécification des besoins jusqu’à la

réalisation, présentent un document détaillé sur les diverses phases et modules du projet.


2. Les diagrammes UML

Avant de présenter les neufs diagrammes de UML, nous allons commencer par présenter les

notations utilisées par ce langage.

• Notation

� Classe : description abstraite d’une entité ou une réalisation d’un type.

Nom de la classe

Attributs de la classe

Opérations de la classe()

Figure 31 : Représentation d’une classe

� Objet : une instance d’une classe.

Nom de l'objet

Figure 32 : Représentation d’un objet

� Association entre deux classes : exprime une relation équilibrée entre deux classes.

Nom de la classe



Nom de la classe



Figure 33 : Association entre deux classes

� Agrégation entre deux classes : forme d’association non symétrique qui exprime un

couplage fort et une relation de subordination.

Nom de la classe2 Nom de la classe1

Figure 34 : Agrégation entre deux classes

Héritage : relation entre deux classes qui permet le partage de propriétés définies dans une classe


Nom de la classe1

Nom de la classe2

Figure 35 : Héritage entre deux classes

• Les diagrammes de comportement (dynamique)

Ces diagrammes offrent un moyen de modéliser les interactions entre les acteurs et le système et

entre les différents modules du système.

� Les diagrammes de séquences : ils représentent les interactions entre les objets dans

un contexte temporel. C’est donc le temps qui détermine l’ordre des envois des

messages entre ces objets. Il est constitué de deux axes, un axe vertical représentant

l’évolution temporelle et l’autre horizontal représentant les objets considérés.

Objet1 Objet2 Objet3

1: M1 2: M2

4: M3

5: M4

6: M5

3: Traitement

OK

OK-----

Figure 36 : Diagramme de séquence

m1, m2, m3, m4 et m5 représentent les différents messages échangés entre les trois

objets au cours du temps (le processus commence par l’envoi du message m1 par

l’objet1 et se termine par la réception de m4 ou m5 toujours par l’objet1).

� Les diagrammes de collaborations : comme les diagrammes de séquences, les

diagrammes de collaborations visualisent les échanges de messages, mais ils font

apparaître plus d’objets qui collaborent entre eux afin de répondre à une activité du


� système. L’axe du temps n’est pas représenté explicitement sur ces diagrammes,

l’ordonnancement des messages entre les objets est matérialisé par leur numérotation.

Objet1 Objet2

Objet3 Objet4

1: M1

2: M23: M3

4: M4

Figure 37 : Diagramme de collaboration

� Les diagrammes d’états transition : ils permettent de visualiser l’ensemble des états

d’un objet durant sa période de vie. Ils sont des graphes dirigés constitués d’un

ensemble d’états reliés par des connexions appelées transitions. Ces transitions sont

déclenchées par les événements qui surviennent dans le domaine du problème.

Figure 38 : Diagramme d’états transition

� Les diagrammes d’activités : ils sont des cas particuliers des diagrammes d’états

transitions, mais ici les événements sont internes qui correspondent aux différents

opérations et processus. Un diagramme d’activité ressemble au modèle organisationnel

des traitements (MOT) défini dans Merise, il permet de modéliser les flux de données

entre les différents acteurs du système.

Figure 39 : Diagramme d’activité organisé par acteur


• Les diagrammes statiques

Ces diagrammes mettent l’accent sur la partie statique et spatiale du système ainsi que sur les

relations entre les différents objets.

� Les diagrammes de cas d’utilisations : ils représentent les différentes utilisations

potentielles du système. Celles-ci correspondent à des vues des acteurs externes sur le

système. Un diagramme de cas d’utilisation rassemble les différents acteurs et les

activités attendues du système.

UseCase2

Acteur1

UseCase3

Acteur2

UseCase1

Figure 40 : Diagramme de cas d’utilisation

� Les diagrammes d’objets : ou d’instances expriment l’état statique du système. Ils

sont utilisés principalement pour faciliter la compréhension d’un contexte. Ils mettent

en relation un ensemble d’objets du système pour répondre à un cas d’utilisation ou une

activité du système.

Objet1 Objet2

Objet3 Objet4

Figure 41 : Diagramme d’objets

� Les diagrammes de classes : comme les diagrammes d’objets, ils montrent l’aspect

statique du système


Classe1 Classe2

Classe3

Figure 42 : Diagramme de classe

• Les diagrammes d’implémentation

Les diagrammes d’implémentation mettent en évidence les différentes dépendances, qu’elles soient

logiques ou physiques, entre les différents modules d’un logiciel à savoir :

� Les diagrammes de composants : ils décrivent les éléments physiques (les fichiers,

les paquetages, …etc.) ainsi que les relations entre ces différents éléments. Les

dépendances sont représentées par des traits discontinus pour indiquer qu’un

composant fait références aux services offerts par l’autre composant.

Composant2Composant1

Figure 43 : Diagramme de composant

� Les diagrammes de déploiement : ils évoquent la partie matérielle et physique du

système ainsi que la répartition des programmes suivant les différents composants

matériels. Chaque composant est représenté par un nœud sous forme d’un cube. Les

différents nœuds sont reliés par des lignes modélisant les connexions entre les

composants physiques du système.

Serveur

ClientServeur2

HTTPTCP/IP

FTP

Figure 44 : Diagramme de déploiement

Gestion d"une société de transit avec openerp

Technology

Transcript of Gestion d"une société de transit avec openerp