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

‫رة ا‬
105 ‫ا‬

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

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

2

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

3

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.

4

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.

5

Liste des abréviations
Sigle Définition
ERP Enterprise Resource Planning
PGI Progiciels de Gestion Intégrés
GNU General Public License
SAP Systeme Anwendungen Produkte in der Datenverarbeitung(en anglais
Systems, Applications and Products in Data Processing)
SSLL Société de Services en Logiciels Libres
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 Lightweight Directory Access Protocol
OLAP Online Analytical Processing
SGBD Système de Gestion de Base de Données
IDE Itegrated Development Environment
SWT Standard Widget Toolkit
SQL Structured Query Language
SGML Standard Generalized Markup Language
HTML Hypertext Transfer Protocol
DTD Document Type Definition

6

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

7

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

8

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

9

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

10

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

11

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

12

Contexte général du
Partie projet

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

13

Chapitre
Présentation de NEXTMA

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.

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.

14

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

15

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.

16

Chapitre

Présentation du projet

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.

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)

17

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.

Description Points Forts Points Faibles
- Itératif ;
- Méthodologie centrée - Spécifie le dialogue entre les
RUP sur l’architecture et différents intervenants du
- Coûteux à personnaliser ;
Rational couplée aux diagrammes projet : les livrables, les
- Très axé processus, au
Unified UML ; plannings, les prototypes…
détriment du développement.
Process - Cible des projets de - Propose des modèles de
plus de 10 personnes. documents, et des canevas pour
des projets types.
- Ne couvre pas les phases en
- Itératif ;
XP amont et en aval au
- Cible des projets de - Simple à mettre en œuvre ;
eXtreme développement ;
moins de 10 personnes. - Fait une large place aux
Programming - Assez flou dans sa mise en
aspects techniques.
œuvre.
- Itératif ;
-S'articule autour de
- Fait une large place à la - Plutôt superficiel sur les
2TUP l'architecture ;
technologie et à la gestion du phases situées en amont et en
Two Track -Propose un cycle de
risque ; aval du développement ;
Unified développement en Y ;
- Définit les profils des - Ne propose pas de
Process - Cible des projets de
intervenants, les livrables, les documents types.
toutes tailles.
plannings, les prototypes.
Tableau 1 : Synthèse des méthodologies utilisées dans le cadre de développement Objet et Nouvelles
technologies

18

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.

19

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.

20

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 : 16/03/2009 04/04/2009 20j

Langage de programmation Python ;

Framework d’OpenERP OpenObject ;

Fonctionnement d’OpenERP.

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

21

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.

22

fonctionnelle
Etude fonctionnelle
Partie et technique

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

23

Chapitre

Etude préliminaire

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.

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 ;

24

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 :

25

2.1 Circuit simplifié d’un dossier import/export

Secrétaire I
Réception des documents

Secrétaire II
Ouverture et suivi des dossiers
import/export

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
Figure 3 : Circuit d’un dossier

26

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 ;

27

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)

28

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.

29

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;

30

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.

31

Chapitre

Etude fonctionnelle

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.

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

32

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.

33

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 :

34

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

35

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
Scénario Action de l’acteur Action du système
authentification 1 Se connecter au système.
2 Vérifier login et mot de passe, valider
et autoriser l’accès selon les droits.
Exceptions
1 Se connecter au système
2 Le système ne répond pas

1 Se connecter au système
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.


36

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.
Scénario Gérer_Dossier Action de l’acteur Action du système
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
6 Etat dossier ouvert
Exceptions
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.


Tableau 4 : Scénario de gérer dossier

37

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.
Scénario Gerer_Ventilation Action de l’acteur Action du système
1 Lister dossiers ouverts
2 Afficher liste dossiers
ouverts.
3 Choisir numéro dossier
4 Afficher dossier choisi
5 Ajouter ventilation
6 Enregistrer les informations
dans la base de données du
système
Exceptions
1 Lister dossiers ouverts
3 Ajouter ventilation
5 Données insuffisantes pour
la ventilation
Fréquence A la demande

Tableau 5 : Scénario de gérer ventilation

38

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
Scénario Gerer_Declaration Action de l’acteur Action du système
1 Lister dossiers à déclarer
2 Afficher liste dossier à
déclarer
5 Déclarer dossier
6 Calculer paramètres
7 Etat dossier déclaré
Exceptions
2 Déclarer dossier
4 Données insuffisantes
pour le calcul
Calcul impossible dossier
(déjà déclaré)

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

39

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
Scénario Gerer_Facturation Action de l’acteur Action du système
1 Lister dossiers déclarés
2 Afficher liste dossiers
déclarés
5 Facturer dossier
6 Calculer montant total
7 Etat dossier facturé
Exceptions
2 Facturer dossier
4 Données insuffisantes
pour la facturation

Tableau 7 : Scénario de gérer facturation

40

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
Scénario Action de l’acteur Action du système
Paramétrage du 1 Choisir l’option Paramétrage du
système Système.
2 Afficher la liste des paramètres.
3 Définir les paramètres.
4 Valider
5 Sauvegarder
Exceptions
1 Définir les paramètres
1 Définir les paramètres
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.

41

Chapitre
Etude technique

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

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.

42

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

43

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

44

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

45

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

46

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.

47

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.

48

Mise en Œuvre du
Partie projet

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

49

Chapitre

Conception de la solution

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.

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

50

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

51

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)

52

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.

53

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

54

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

55

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:

56

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

57

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.

58

Chapitre

Réalisation de la solution

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.

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 ;

59

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 ;

60

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.

61

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

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

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

Similaire à Gestion d"une société de transit avec openerp (20)

Plus de HORIYASOFT

Plus de HORIYASOFT (20)

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