Dédicace 
Je dédie ce modeste travail à 
Mes parents, qui n'ont jamais cessé de m'encourager et me soutenir, 
Mon frère Mo...
Remerciements 
Je tiens à remercier chaleureusement l'ensemble des personnes qui ont contribué de 
prêt ou de loin à l'éla...
Table des matières 
Dédicace i 
Remerciements ii 
Table de Matières iii 
Table des gures vi 
Liste des tableaux viii 
Intr...
TABLE DES MATIÈRES iv 
2.4 Module  Gestion de Production  . . . . . . . . . . . . . . . . . . . . . . 19 
2.5 Module  Gest...
TABLE DES MATIÈRES v 
4.2.6 Diagramme de séquence  Charger par assistant  . . . . . . . . . . 49 
4.2.7 Diagramme de séque...
Table des gures 
1.1 OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 
1.2 Organigramme...
TABLE DES FIGURES vii 
3.8 Diagramme cas d'utilisation  Gérer Demande de changement  par le 
Manager . . . . . . . . . . ....
Liste des tableaux 
1.1 Tableau comparatif des méthodes de développement . . . . . . . . . . . . . 12 
2.1 Calcul Prix moy...
Introduction générale 
Les technologies de l'information ont connu une importante évolution durant ces 
dernières années, ...
LISTE DES TABLEAUX 2 
et dynamiques ainsi que l'architecture globale de la solution. Le cinquième chapitre est 
réservé à ...
Chapitre 1 
Présentation du projet 
Introduction 
Dans ce premier chapitre, nous allons présenter le cadre général du proj...
CHAPITRE 1. PRÉSENTATION DU PROJET 4 
1.1.1 Domaine d'activité 
Les consultants d'OpenIOS accompagnent le client dans la g...
CHAPITRE 1. PRÉSENTATION DU PROJET 5 
1.1.2 Organisation d'OpenIOS 
Le diagramme suivant représente les diérents services ...
CHAPITRE 1. PRÉSENTATION DU PROJET 6 
Ainsi, on peut parler d'ERP lorsqu'on est en présence d'un système d'information 
co...
CHAPITRE 1. PRÉSENTATION DU PROJET 7 
Figure 1.4  Modules OpenERP 
OpenERP possède une structure modulaire qui permet d'aj...
CHAPITRE 1. PRÉSENTATION DU PROJET 8 
données) pour l'enregistrement de ces données, où OpenERP utilise un  Object 
Relati...
CHAPITRE 1. PRÉSENTATION DU PROJET 9 
Le MVC résout ce genre de problème en découplant l'accès des données et la logique d...
CHAPITRE 1. PRÉSENTATION DU PROJET 10 
Méthode de coût  Prix standard  : Le système n'intervient pas pour changer 
le prix...
CHAPITRE 1. PRÉSENTATION DU PROJET 11 
1.5.1 Langage de modélisation : UML 
Une des phases clés dans le développement d'un...
CHAPITRE 1. PRÉSENTATION DU PROJET 12 
Diagramme de classe : Le diagramme de classe est le point central du développement ...
CHAPITRE 1. PRÉSENTATION DU PROJET 13 
Nous avons utilisé le Processus Simplié comme un Processus de développement logi-ci...
Chapitre 2 
État de l'art 
Introduction 
Avant de commencer l'étape du développement, nous avons cherché tout d'abord parm...
CHAPITRE 2. ÉTAT DE L'ART 15 
Le champ marqué dans la gure de type liste déroulante qui contient les deux méthodes 
permet...
CHAPITRE 2. ÉTAT DE L'ART 16 
Figure 2.3  Formulaire  Créer Catégorie  
A l'aide de cette interface nous précisions le com...
CHAPITRE 2. ÉTAT DE L'ART 17 
des comptes qui constitue la norme de la comptabilité. Le plan de comptes, c'est-à-dire 
la ...
CHAPITRE 2. ÉTAT DE L'ART 18 
2.3 Module  Gestion des achats  
Figure 2.5  Module  Gestion des achats  
Le module achat pe...
CHAPITRE 2. ÉTAT DE L'ART 19 
Par le formulaire de la gure 2.6 le gestionnaire d'achat modélise le processus d'achat 
des ...
CHAPITRE 2. ÉTAT DE L'ART 20 
Le tableau 2.4 décrit les principales fonctionnalités du module production. 
Table 2.4  Fonc...
CHAPITRE 2. ÉTAT DE L'ART 21 
2.5 Module  Gestion de stock  
Figure 2.8  Module  Gestion de stock  
OpenERP permet facilem...
CHAPITRE 2. ÉTAT DE L'ART 22 
Par l'interface de la gure 2.9 le gestionnaire de stock conrme la réception d'un bon 
de com...
CHAPITRE 2. ÉTAT DE L'ART 23 
2.6 Processus de gestion 
Comme la valorisation du stock d'un article est une phase réalisée...
CHAPITRE 2. ÉTAT DE L'ART 24 
Figure 2.11  Formulaire  Créer Ordre de fabrication  
La liste de sélection  Nomenclature  p...
CHAPITRE 2. ÉTAT DE L'ART 25 
Après la création d'un article et la dénition de la nomenclature, le gestionnaire 
de produc...
CHAPITRE 2. ÉTAT DE L'ART 26 
Conclusion 
Dans ce chapitre nous avons étudié les diérents modules liés à notre projet et p...
Chapitre 3 
Analyse et spécication des besoins 
Introduction 
Après avoir présenté le projet précédemment et an de détermi...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 28 
3.1.2 Consultation des articles 
Manque au niveau des services liés à...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 29 
Figure 3.2  Changement automatique de prix de revint 
Cette gure est ...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 30 
Améliorer la gestion d'achat 
Intégrer les traitements nécessaires po...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 31 
3.3 Diagramme de cas d'utilisation 
La conception sera modélisée à l'...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 32 
3.3.2 Diagramme de cas d'utilisation global 
Le diagramme des cas d'u...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 33 
 Post-condition : l'article est modié suivant l'opération eectuée par...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 34 
3.3.3 Diagramme de cas d'utilisation  Gérer article  
Figure 3.4  Dia...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 35 
 Acteur : Gestionnaire de stock 
 Pré-condition : le gestionnaire de ...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 36 
 Description : Le responsable de production conrme la fabrication d'u...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 37 
 Le système modie le type d'accès à la demande en lecture seul. 
 Pos...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 38 
Cas d'utilisation  Charger par ajout article  
 Titre : Charger par a...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 39 
3.3.7 Diagramme cas d'utilisation  Gérer Demande de change-ment 
des ...
CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 40 
 Le Manger consulte la liste des articles à changer. 
 Le Manager con...
Chapitre 4 
Conception 
Introduction 
Après avoir spécié les besoins et xer les choix conceptuels qui seront adoptés 
lors...
CHAPITRE 4. CONCEPTION 42 
Figure 4.1  Diagramme de classes
CHAPITRE 4. CONCEPTION 43 
Description 
Pour mieux comprendre l'aspect d'intégration de notre module, nous allons aussi ex...
CHAPITRE 4. CONCEPTION 44 
qui est responsable du calcul du coût de fabrication d'un article, an d'enregistrer les 
valeur...
CHAPITRE 4. CONCEPTION 45 
4.2 Diagramme de séquence 
Dans le formalisme UML, un diagramme de séquence est une présentatio...
CHAPITRE 4. CONCEPTION 46 
méthodes de la version standard et les méthode ajoutées). Après le gestionnaire de stock 
conrm...
CHAPITRE 4. CONCEPTION 47 
4.2.3 Diagramme de séquence  Recevoir articles achetés  
Figure 4.4  Diagramme de séquence  Rec...
CHAPITRE 4. CONCEPTION 48 
4.2.4 Diagramme de séquence  Fabriquer article  
Figure 4.5  Diagramme de séquence  Fabriquer a...
CHAPITRE 4. CONCEPTION 49 
4.2.5 Diagramme de séquence  Charger par ajout article  
Figure 4.6  Diagramme de séquence  Cha...
CHAPITRE 4. CONCEPTION 50 
Figure 4.7  Diagramme de séquence  Charger par assistant
CHAPITRE 4. CONCEPTION 51 
4.2.7 Diagramme de séquence  Calculer les valeurs des comptes 
comptables  
Figure 4.8  Diagram...
CHAPITRE 4. CONCEPTION 52 
4.2.8 Diagramme de séquence  Valider demande  
Figure 4.9  Diagramme de séquence  Valider deman...
CHAPITRE 4. CONCEPTION 53 
il faut relier ces états entre eux en utilisant des transitions contrôlées par des conditions 
...
Chapitre 5 
Étude technique et Réalisation 
Introduction 
Pour le développement du système nous nous sommes basés sur le F...
CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 55 
PowerAMC est un environnement graphique très simple à utiliser qui permet d...
CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 56 
PostgreSQL peut stocker plus de types de données que les types traditionnel...
CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 57 
5.1.4 Éditeur de catalogues textuels : PoEdit 
L'internationalisation d'un ...
CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 58 
Anciennement connu par  Framework OpenObject , mais comme cela était source...
CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 59 
Figure 5.6  ORM d'OpenERP 
Cette couche (notamment dans OpenERP) permet de ...
CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 60 
Il existe plusieurs types de workow : 
 Le workow administratif, concernant...
CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 61 
L'accès généralisé via les web services en XML-RPC 
Toutes les communicatio...
CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 62 
machine virtuelle (comme pour Java, avec une diérence importante : Java éta...
CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 63 
Figure 5.9  Les sections d'un chier RML 
5.2.5 Fichier PO 
Toutes les chain...
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
Prochain SlideShare
Chargement dans…5
×

OpenERP - Gestion de prix de revient

5 446 vues

Publié le

Gérer les changements de prix de revient des articles
Gérer le prix moyen et le dernier prix des articles

Publié dans : Ingénierie
3 commentaires
5 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
5 446
Sur SlideShare
0
Issues des intégrations
0
Intégrations
25
Actions
Partages
0
Téléchargements
526
Commentaires
3
J’aime
5
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

OpenERP - Gestion de prix de revient

  1. 1. Dédicace Je dédie ce modeste travail à Mes parents, qui n'ont jamais cessé de m'encourager et me soutenir, Mon frère Mouhamed, et ma s÷ur Soumaya Tous les membres de ma famille, Mes Collègues : Naceur, Cherif, Foued, Amine, Mourad Tous mes amis, Et ceux qui me sont chers. Taieb
  2. 2. Remerciements Je tiens à remercier chaleureusement l'ensemble des personnes qui ont contribué de prêt ou de loin à l'élaboration de ce projet qui a été pour moi très enrichissant tant au niveau formation que sur le plan personnel. Je remercie Mr Faouzi BEN CHARRADA, pour son suivi de près de l'avance-ment de ce projet, pour les conseils judicieux qu'il n'a cessé de me prodiguer. Je remercie Mr Soen KARRAY, qui m'a encadré, avisé et motivé de façon continue et qui m'a oert cette chance de poursuivre ce stage très bénéque. Je remercie, également, tout le cadre administratif et les professeurs de la FST pour la formation de qualité et l'ambiance qu'ils ont su instaurer pendant toutes mes années d'études. Enn, je tiens à exprimer mon amitié et mon respect profonds envers tous mes collègues de la FST.
  3. 3. Table des matières Dédicace i Remerciements ii Table de Matières iii Table des gures vi Liste des tableaux viii Introduction générale 1 1 Présentation du projet 3 Conclusion 3 1.1 Organisme d'Accueil : OpenIOS Consulting . . . . . . . . . . . . . . . . . . 3 1.1.1 Domaine d'activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2 Organisation d'OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Progiciel de Gestion Intégré . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1 ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.2 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.1 Langage de modélisation : UML . . . . . . . . . . . . . . . . . . . . 11 1.5.2 Processus de développement . . . . . . . . . . . . . . . . . . . . . . 12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 État de l'art 14 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1 Module Gestion des Articles . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Module Comptabilité et Finance . . . . . . . . . . . . . . . . . . . . . 16 2.3 Module Gestion des achats . . . . . . . . . . . . . . . . . . . . . . . . 18 iii
  4. 4. TABLE DES MATIÈRES iv 2.4 Module Gestion de Production . . . . . . . . . . . . . . . . . . . . . . 19 2.5 Module Gestion de stock . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.6 Processus de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6.1 Réception par achat . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6.2 Réception par production . . . . . . . . . . . . . . . . . . . . . . . 23 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3 Analyse et spécication des besoins 27 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1 Analyse de l'existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.1 Méthode de coût basé sur le Dernier prix . . . . . . . . . . . . . 27 3.1.2 Consultation des articles . . . . . . . . . . . . . . . . . . . . . . . . 28 3.1.3 Prix moyen pondéré et le dernier prix . . . . . . . . . . . . . . . . . 28 3.1.4 Valorisation du coût de fabrication d'un article . . . . . . . . . . . . 28 3.1.5 Changement automatique du prix de revient . . . . . . . . . . . . . 28 3.2 Étude de besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3 Diagramme de cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.1 Identication des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.2 Diagramme de cas d'utilisation global . . . . . . . . . . . . . . . . . 32 3.3.3 Diagramme de cas d'utilisation Gérer article . . . . . . . . . . . 34 3.3.4 Diagramme cas d'utilisation Recevoir article . . . . . . . . . . . 35 3.3.5 Diagramme cas d'utilisation Gérer Demande de changement des prix par le gestionnaire de stock . . . . . . . . . . . . . . . . . . . 36 3.3.6 Diagramme de cas d'utilisation Créer Demande de changement des prix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3.7 Diagramme cas d'utilisation Gérer Demande de changement des prix par le Manager . . . . . . . . . . . . . . . . . . . . . . . . . 39 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4 Conception 41 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2.1 Diagramme de séquence Modier méthode de coût . . . . . . . 45 4.2.2 Diagramme de séquence Actualiser historique . . . . . . . . . . 46 4.2.3 Diagramme de séquence Recevoir articles achetés . . . . . . . . 47 4.2.4 Diagramme de séquence Fabriquer article . . . . . . . . . . . . 48 4.2.5 Diagramme de séquence Charger par ajout article . . . . . . . . 49
  5. 5. TABLE DES MATIÈRES v 4.2.6 Diagramme de séquence Charger par assistant . . . . . . . . . . 49 4.2.7 Diagramme de séquence Calculer les valeurs des comptes comp-tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2.8 Diagramme de séquence Valider demande . . . . . . . . . . . . 52 4.3 Diagramme d'états-transitions . . . . . . . . . . . . . . . . . . . . . . . . . 52 Conclusion 53 5 Étude technique et Réalisation 54 Conclusion 54 5.1 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.1.1 Outil de conception : PowerAMC . . . . . . . . . . . . . . . . . . . 54 5.1.2 Système de gestion de base de données : PostgreSQL . . . . . . . . 55 5.1.3 Éditeur de texte : Notepad++ . . . . . . . . . . . . . . . . . . . . . 56 5.1.4 Éditeur de catalogues textuels : PoEdit . . . . . . . . . . . . . . . . 57 5.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2.1 Framework OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2.2 Langage de programmation : Python . . . . . . . . . . . . . . . . . 61 5.2.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.2.4 RML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.2.5 Fichier PO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.1 Gestion des articles . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.2 Gestion des Demandes . . . . . . . . . . . . . . . . . . . . . . . . . 66 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Conclusion générale 72 Bibliographie ix Webographie x
  6. 6. Table des gures 1.1 OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Organigramme OpenIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Modules OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Architecture multi-tiers d'OpenERP . . . . . . . . . . . . . . . . . . . . . 7 1.6 Protocole XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.7 Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Formulaire Créer article . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Formule de Prix moyen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 Formulaire Créer Catégorie . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Module Comptabilité et nance . . . . . . . . . . . . . . . . . . . . . . 16 2.5 Module Gestion des achats . . . . . . . . . . . . . . . . . . . . . . . . 18 2.6 Formulaire Créer Bon de commande . . . . . . . . . . . . . . . . . . . 19 2.7 Module Gestion de production . . . . . . . . . . . . . . . . . . . . . . 19 2.8 Module Gestion de stock . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.9 Interface Réception du bon de commande . . . . . . . . . . . . . . . . 22 2.10 Assistant Réception par article . . . . . . . . . . . . . . . . . . . . . . 23 2.11 Formulaire Créer Ordre de fabrication . . . . . . . . . . . . . . . . . . 24 2.12 Assistant Créer Nomenclature . . . . . . . . . . . . . . . . . . . . . . . 24 2.13 Assistant Fabriquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.14 Interface Article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1 Méthode de coût . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2 Changement automatique de prix de revint . . . . . . . . . . . . . . . . . . 29 3.3 Diagramme de cas d'utilisation global . . . . . . . . . . . . . . . . . . . . . 32 3.4 Diagramme de cas d'utilisation Gérer article . . . . . . . . . . . . . . . 34 3.5 Diagramme cas d'utilisation Recevoir article . . . . . . . . . . . . . . . 35 3.6 Diagramme cas d'utilisation Gérer demande de changement des prix . 36 3.7 Diagramme cas d'utilisation Créer Demande . . . . . . . . . . . . . . . 37 vi
  7. 7. TABLE DES FIGURES vii 3.8 Diagramme cas d'utilisation Gérer Demande de changement par le Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2 Diagramme de séquence Modier méthode de coût . . . . . . . . . . . 45 4.3 Diagramme de séquence Actualiser historique . . . . . . . . . . . . . . 46 4.4 Diagramme de séquence Recevoir article acheté . . . . . . . . . . . . . 47 4.5 Diagramme de séquence Fabriquer article . . . . . . . . . . . . . . . . 48 4.6 Diagramme de séquence Charger par ajouter article . . . . . . . . . . . 49 4.7 Diagramme de séquence Charger par assistant . . . . . . . . . . . . . . 50 4.8 Diagramme de séquence Calculer les valeurs des comptes comptables . 51 4.9 Diagramme de séquence Valider demande . . . . . . . . . . . . . . . . 52 4.10 Diagramme d'état-transition Demande de changement . . . . . . . . . 53 5.1 Logo PowerAMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2 Logo PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.3 Logo Notepad++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.4 Logo PoEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.5 Module OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.6 ORM d'OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.7 Objet OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.8 Logo Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.9 Les sections d'un chier RML . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.10 Intégration des méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.11 Premier réception article_Prix moyen . . . . . . . . . . . . . . . . . . 64 5.12 Deuxième réception article_Prix moyen . . . . . . . . . . . . . . . . . 65 5.13 Réception article_Dernier prix . . . . . . . . . . . . . . . . . . . . . . 65 5.14 Historique Prix de revient . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.15 Module Changement des prix . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.16 Ajouter article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.17 Données articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.18 Barre d'état d'une demande . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.19 Assistant Charger Liste . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.20 Consulter Compte Comptable . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.21 Valider les changements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.22 Changement de prix de revient . . . . . . . . . . . . . . . . . . . . . . . . 70 5.23 Rapport Changement des prix . . . . . . . . . . . . . . . . . . . . . . . 71
  8. 8. Liste des tableaux 1.1 Tableau comparatif des méthodes de développement . . . . . . . . . . . . . 12 2.1 Calcul Prix moyen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Fonctionnalités du Module Comptabilité et Finance . . . . . . . . . . . 17 2.3 Fonctionnalités du Module Gestion des Achats . . . . . . . . . . . . . . 18 2.4 Fonctionnalités du Module Gestion de production . . . . . . . . . . . . 20 2.5 Fonctionnalités du Module gestion de stock . . . . . . . . . . . . . . . 21 3.1 Acteurs principaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 viii
  9. 9. Introduction générale Les technologies de l'information ont connu une importante évolution durant ces dernières années, ce qui a donné comme résultat l'émergence de plusieurs solutions infor-matiques pour remédier aux diérentes problématiques réelles. Les Progiciels de Gestion Intégré, appelés PGI ou ERP, sont l'une des solutions les plus répondues à ce jour. Ils intègrent les principales composantes fonctionnelles de l'entreprise : gestion de production, gestion commerciale, logistique, ressources humaines, comptabilité, contrôle de gestion. A l'aide de ce système intégré, les utilisateurs de diérents métiers travaillent dans un environnement applicatif identique qui repose sur une base de données unique. Ce modèle permet d'assurer l'intégrité des données, la non-redondance de l'infor-mation, ainsi que la réduction des temps de traitement. OpenIOS Consulting, société au sein de laquelle nous avons eectué notre stage de n d'études, propose à ses clients un ERP basé sur le logiciel libre OpenERP pour lequel elle peut développer des besoins spéciques pour chacun d'entre eux. Au cours de ce stage, notre travail a consisté à comprendre le fonctionnement de l'OpenERP, à concevoir et développer un module de gestion des prix des articles de stock totalement intégré dans ERP et développé avec les outils et les concepts fournit par la communauté OpenERP.Ce module vient d'ajouter une nouvelle fonctionnalité à la pro-bl ématique de gestion de stock exigé dans le contexte des sociétés locales tunisiennes. An d'illustrer la démarche de notre travail, nous présentons dans ce qui suit l'organi-sation générale du présent rapport qui s'articule autour de cinq chapitres. Dans le premier chapitre, nous présenterons le cadre du projet à travers une présentation de la société, des généralités autour des ERP et OpenERP permettant de mieux cadrer notre travail, la problématique et le choix méthodologique. Ensuite, nous présenterons dans le chapitre suivant l'état de l'art an de clarier les diérents modules liés à la gestion de stock. Le troisième chapitre sera consacré à la partie analyse où nous élaborerons une étude de l'exis-tant et une spécication des besoins fonctionnels et non-fonctionnels. Dans le quatrième chapitre qui concerne la conception, nous présenterons les diérents diagrammes statiques 1
  10. 10. LISTE DES TABLEAUX 2 et dynamiques ainsi que l'architecture globale de la solution. Le cinquième chapitre est réservé à l'étude technique où nous présenterons les outils et les technologies utilisées, et nous présenterons les interfaces à l'aide des captures écrans avec les explications. Pour conclure, nous présenterons les connaissances acquises durant ce stage et nous proposons un ensemble de perspectives à ce travail.
  11. 11. Chapitre 1 Présentation du projet Introduction Dans ce premier chapitre, nous allons présenter le cadre général du projet. Pour ce faire, nous allons présenter, dans un premier lieu, l'entreprise d'accueil. Ensuite, nous introduisons les ERP et le progiciel OpenERP utilisé dans cette entreprise, ainsi que la présentation du projet : la problématique, les objectifs et la méthodologie du travail. 1.1 Organisme d'Accueil : OpenIOS Consulting Figure 1.1 OpenIOS Le projet a été réalisé au sein de la société OpenIOS située aux Berges du Lac. Fondée en 2011, OpenIOS est une société tunisienne active dans le domaine des systèmes d'information spécialisée dans l'édition et l'intégration des logiciels Open Source. Résul-tant d'une expérience de consulting de plus de 12 ans en gestion d'entreprise, OpenIOS a adopté OpenERP comme solution ERP spéciquement conçue pour les PME de services. OpenIOS est un spécialiste des technologies de développement open source, Python et Java, pour les plateformes OpenERP, J2EE, Servlets, JSP, Tomcat, JBOSS et IBM Websphere Application Server. Le Framework de développement est basé sur des outils et des composantes Open source adoptés par de nombreux éditeurs et entreprises d'envergure internationale. [6] 3
  12. 12. CHAPITRE 1. PRÉSENTATION DU PROJET 4 1.1.1 Domaine d'activité Les consultants d'OpenIOS accompagnent le client dans la gestion de son système d'information et dans le pilotage de ses processus : du consulting au transfert de compé- tences en incluant le paramétrage et l'intégration d'OpenERP avec d'autres applications tierces. Dans le but de fournir à chacun de ses clients un service sur-mesure et de qualité avec une solution parfaitement adaptée à leurs besoins. Ainsi le domaine d'activité d'OpenIOS tourne essentiellement autour du développement de logiciel sur-mesure et consulting, par-ticuli èrement touche les domaines suivants : Stratégie de Nouvelle Technologie dans le Système d'Information de client : service de conseil visant à renforcer l'ecacité des systèmes d'information des entreprises. Gestion électronique des documents et workow : en couvrant la dénition du roadmap du projet de mise en place, l'assistance et l'accompagnement de mise en place des systèmes GED/Workow, l'étude et la conception des processus métiers, en utilisant les standards comme BPMN, et l'interaction de solutions Lowcost en l'occurrence basés sur l'Open Source. Business Intelligence : proposition aux clients d'une réexion approfondie par le biais d'une analyse de l'existant, d'une évaluation du gap et de la mise en place de solutions simples de business intelligence. Management projet : Les chefs de projets OpenIOS apportent leurs savoir-faire dans la conduite des projets an de respecter l'adéquation coût, délai et qualité. Développement autour d'OpenERP : basé sur OpenObject, un Framework modu-laire, scalable et intuitif, c'est un Rapid Application Development (RAD) Fra-mework écrit en Python. Développement Java : basé sur les serveurs d'application J2EE JBOSS et IBM Websphere application server. Développement autour des plate-forme GED/Workow -IBM FileNet/ Alfresco : En accumulant les projets de Gestion Electronique de Document, l'équipe d'OpenIOS a conçu des composants qui facilitent le développement spécique autour de Filenet et Alfreco.[6]
  13. 13. CHAPITRE 1. PRÉSENTATION DU PROJET 5 1.1.2 Organisation d'OpenIOS Le diagramme suivant représente les diérents services rattachés à une direction générale : Figure 1.2 Organigramme OpenIOS 1.2 Progiciel de Gestion Intégré 1.2.1 ERP L'acronyme ERP signie Enterprise Ressource Planning traduit en français par Pro-giciel de Gestion Intégré ou PGI. ERP est le terme le plus couramment utilisé. Un ERP est un progiciel qui permet de gérer d'une manière centralisée l'ensemble des processus d'une entreprise intégrant l'ensemble de ses fonctions comme la gestion des ressources humaines, la gestion nancière et comptable, l'aide à la décision, la vente, la distribution, l'approvisionnement, la production ou encore du e-commerce. Le principe fondateur d'un ERP est de construire des applications informatiques cor-respondant aux diverses fonctions citées précédemment de manière modulaire sachant que ces modules sont indépendants entre eux, tout en partageant une base de données unique et commune au sens logique. [7] L'autre principe qui caractérise un ERP est l'usage de ce qu'on appelle un moteur de workow et qui permet, lorsqu'une donnée est enregistrée dans le système d'information, de la propager dans les modules qui en ont l'utilité, selon une programmation prédénie.
  14. 14. CHAPITRE 1. PRÉSENTATION DU PROJET 6 Ainsi, on peut parler d'ERP lorsqu'on est en présence d'un système d'information composé de plusieurs applications partageant une seule et même base de donnés, par le biais d'un système automatisé prédéni et éventuellement paramétrable, un moteur de workow. 1.2.2 OpenERP Figure 1.3 OpenERP Créée en 2002 par Fabien PINCKAERS, anciennement connu sous le nom Tiny ERP, signiant la fourmi de l'Enterprise ,est un progiciel intégré de gestion ouvert, libre de droits comprenant les ventes, la gestion de relation client (CRM), la gestion de projet, la gestion d'entrepôt, la production, la comptabilité et les ressources humaines. Le principe du logiciel libre est la gratuité, mais aussi la possibilité d'accéder aux codes des programmes, ce qui permet de les modier, de les adapter à volonté, à condition de rendre publique la nouvelle version. Grâce à la communauté open source, le catalogue de logiciels d'OpenERP s'était déve-lopp é bien plus rapidement que pour un éditeur de logiciels dits propriétaires (comme ceux de SAP, Microsoft, Sage, Oracle. . .) : pas moins de 500 modules étaient déjà à dis-position des entreprises. On notait déjà plus de 1000 installations par jour, devenant le logiciel de gestion le plus installé au monde. OpenERP ache en eet une progression de 1542% de son chire d'aaires en cinq ans , en passant de 500 modules, n 2009, à 2200 proposé par la nouvelle version OpenERP 7, avec croissance qui passe 100% par an.[8]
  15. 15. CHAPITRE 1. PRÉSENTATION DU PROJET 7 Figure 1.4 Modules OpenERP OpenERP possède une structure modulaire qui permet d'ajouter de nouveaux modules facilement pour étendre les fonctionnalités. Un module est un dossier avec une structure prédénie contenant du code Python et des chiers XML, qui permet de dénir la struc-ture de données, formulaires, rapports, menus, procédures, ux de travail, etc. Lors de la première installation, on installe le noyau d'OpenERP avec un certain nombre de modules dont module base selon de prol d'installation choisit. OpenERP est basé sur une architecture multi-tiers. La logique d'OpenERP est entiè- rement du côté serveur. Le client est un client léger ; son travail consiste à demander des données (formulaires, listes, arbres) à partir du serveur et de les renvoyer. Avec cette approche tous les développements sont réalisés sur le côté serveur. Ce qui rend Ope-nERP plus simple au développement et à la maintenance. Figure 1.5 Architecture multi-tiers d'OpenERP L'architecture du système OpenERP est 3 tiers : Un serveur de base de données PostgreSQL (qui peut contenir plusieurs bases de
  16. 16. CHAPITRE 1. PRÉSENTATION DU PROJET 8 données) pour l'enregistrement de ces données, où OpenERP utilise un Object Relational Mapping (ORM) pour la persistence de ses objets métier. Un serveur d'applications (contenant les objets de gestion, le moteur de workow, le générateur d'édition, etc.). Un serveur de présentation (appelé OpenERP Web) qui permet à l'utilisateur de se connecter à OpenERP avec n'importe quel navigateur internet. Le transport des données est réalisé via XML-RPC, c'est un protocole RPC (Remote procedure call), une spécication simple et un ensemble de codes qui permettent à des processus s'exécutant dans des environnements diérents de faire des appels de méthodes à travers un réseau. Figure 1.6 Protocole XML-RPC OpenERP adopte le modèle MVC avec une séparation stricte entre le modèle de don-n ées, la vue et les traitements. Figure 1.7 Modèle MVC Un (MVC) est une architecture de modèles utilisée en génie logiciel. Dans des applica-tions 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'aectent pas le traitement des données, et que les données peuvent être réorganisées sans changer l'interface utilisateur.
  17. 17. CHAPITRE 1. PRÉSENTATION DU PROJET 9 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 OpenERP, on peut appliquer cette sémantique de Model-View-Controller avec : Modèle : les modèles sont les objets déclarés dans OpenERP. Ils sont également des tables PostgreSQL. Vue : les vues sont dénies en chiers XML dans OpenERP. Contrôleur : le contrôleur est Python qui contrôle OpenERP. 1.3 Problématique Les stocks représentent les biens achetés, transformés ou à vendre à un moment donné. Ainsi, les principaux types de stocks sont : Le stock de marchandises. Les stocks des commerçants (revente à prot d'articles sans valeur ajoutée de transformation par l'entreprise). Le stock de matières premières qui représente les articles achetés auprès de four-nisseurs en vue d'une transformation ultérieure. Le stock des produits en cours de fabrication (semi-nis) qui représente les articles qui ne sont pas vendables en l'état car devant encore subir des transforma-tions. le stock des produits nis qui représente les articles que l'entreprise peut vendre après les avoir fabriquées. Le coût d'entrée d'un stock est constitué de : Coûts d'acquisition : ce sont les prix d'achat des matières premières, fournitures ou marchandises auquel s'ajoutent les éventuels frais de transport et de manutention, les droits de douane, les diérents taxes. Coûts de transformation que sont les coûts ajoutés au coût d'acquisition an de parvenir au coût de production déterminé par la comptabilité analytique. Coûts encourus pour amener les stocks à l'endroit et dans l'état où ils se trouvent. La valorisation des prix de revient des articles est très importante, car c'est l'un des facteurs primordiaux dans le calcul du prix de vente, ainsi c'est vital pour la rentabilité d'une entreprise. OpenERP utilise principalement deux méthodes, dans sa version standard, pour va-loriser le stock, ce qui provoque une insusance dans plusieurs cas de gestion en tenant compte de la diversité des articles et des contraintes exigées. En eet, la valorisation de stock est réalisée selon deux méthodes, chacune possède des inconvénients :
  18. 18. CHAPITRE 1. PRÉSENTATION DU PROJET 10 Méthode de coût Prix standard : Le système n'intervient pas pour changer le prix de l'article conguré par cette méthode. L'intervention du gestionnaire de stock est directe, où il eectue la mise à jour du prix de revient d'article sans tenir compte de la valeur réelle du coût de réception de cet article dans l'entrepôt de l'entreprise. En eet, la récupération de cette dernière valeur, avec les outils existants dans OpenERP pour cette méthode, est très dicile car nécessite une consultation des tous les bons de réception pour chercher dans chacune le prix unitaire de réception et la quantité pour qu'on calcule le prix de revient. Méthode de coût basée sur le Prix moyen : Le système calcule le nouveau prix de revient après chaque réception. Le cas contraire de la méthode précédente, car cette méthode calcule le coût unitaire pour un article stocké dans l'entrepôt, mais la mise à jour de prix de revient est eectué automatiquement pour chaque réception d'article sans aucun contrôle ou manipulation par le gestionnaire de stock, ce qui peut provoquer une mauvaise gestion. Nous remarquons aussi l'absence d'une méthode pour dénir le prix de revient selon le dernier coût, malgré l'importance de cette méthode pour un grand nombre d'article, où ce type de valorisation devient nécessaire aux plusieurs entreprises pour une gestion adéquate. En plus, les articles fabriqués, dans certain cas seront valoriser et revu périodi-quement et non systématiquement par le système. 1.4 Objectifs L'objectif de ce projet est de développer un module de gestion de prix de revient dans OpenERP. Ce module permet d'ajouter les insusances dans le calcul du prix de revient basé sur le dernier prix d'achat, et d'ajouter un processus de contrôle permettant au gestionnaire de stock de mieux gérer le changement des prix des articles. Ce module devrait proposer un workow pour gérer la validation périodique des changements de prix. Il est demandé aussi de faire le reporting nécessaires an de consulter l'état valorisé du stock. 1.5 Choix méthodologique Notre démarche est de comprendre le système d'information, de cerner les besoins et de proposer des solutions qui répondent à ces besoins. La méthodologie suivie est composée de deux parties : le formalise adopté et le processus adopté.
  19. 19. CHAPITRE 1. PRÉSENTATION DU PROJET 11 1.5.1 Langage de modélisation : UML Une des phases clés dans le développement d'une application est sans doute la phase de conception. Durant cette phase, nous allons essayer de présenter les principales fonc-tionnalit és à implanter, de rééchir sur l'aspect structurel de l'application et de concevoir les scénarios d'utilisation de l'application. Le but est de réduire la complexité du déve-loppement et d'avoir une vision des diérents angles de vues du système d'information. Pour ce projet, on opte pour la notation UML. UML est la forme contractée d'Unied Modeling Language, qui peut se traduire en français par langage unié pour la modélisation. UML représente l'état de l'art des lan-gages de modélisation objet. Il fournit les fondements pour spécier, construire, visualiser et décrire un système. Pour cela, UML se base sur une sémantique précise et sur une notation graphique expressive. Il dénit des concepts de base et ore également des mé- canismes d'extension de ces concepts. UML n'est pas un langage propriétaire : il est accessible à tout les fabriquant d'ou-tils, aussi les entreprises peuvent en faire usage. La volonté d'ouverture, la richesse et la notation de la dénition sémantique précise des éléments de modélisation font d'UML un langage général et simple, sans être simpliste pour autant. [3] Dans UML chaque diagramme permet d'exprimer certains points de vue d'un même problème. La combinaison de plusieurs diagrammes permettra donc d'avoir une vue com-pl ète du système. Ainsi en fonction du problème à résoudre, il convient de choisir les diagrammes adéquats à utiliser. UML dénit neuf types de diagrammes dont nous dé- taillerons ceux que nous utiliserons dans la suite : Diagramme de cas d'utilisation : Les cas d'utilisation décrivent le comportement du système du point de vue utilisateur sous la forme d'actions et de réaction. Un cas d'utilisation indique une fonctionnalité du système déclenchée par un acteur externe au système. Ce genre de diagramme permet de mettre en place et de comprendre les besoins du client. Dans le diagramme, interviennent trois éléments : les acteurs, le système et les cas d'utilisations. L'acteur représente un rôle joué par une personne ou un autre système qui interagit avec système en cours de modélisation. Un cas d'utilisation regroupe plusieurs scénarios d'utilisation du système. Diagramme de séquence : Les diagrammes de séquence permettent de représenter des collaborations entre objet selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages. Les diagrammes de séquences peuvent servir à illustrer un cas d'utilisation.
  20. 20. CHAPITRE 1. PRÉSENTATION DU PROJET 12 Diagramme de classe : Le diagramme de classe est le point central du développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs. En conception, le diagramme de classe représente la structure d'un code orienté objet ou, à un niveau de travail plus important, les modules du langage de développement. Diagramme états-transitions : Les diagrammes d'états-transitions d'UML décrivent le comportement interne d'un objet à l'aide d'un automate à états nis. Ils présentent les séquences possibles d'états et d'actions qu'une instance de classe peut traiter au cours de son cycle de vie en réaction à des évènements discrets (de type signaux, invocations de méthode). 1.5.2 Processus de développement Un processus de développement logiciel est un ensemble d'activités permettant de transformer les besoins des utilisateurs en un système logiciel. Avant d'adopter une mé- thode, il faut d'abord faire une comparaison entre les diérentes méthodes existantes, voir les points forts et les points faibles de chacune, puis déterminer celle qui va mieux dans le contexte du projet. Ci-dessous un tableau qui résume cette comparaison. Table 1.1 Tableau comparatif des méthodes de développement
  21. 21. CHAPITRE 1. PRÉSENTATION DU PROJET 13 Nous avons utilisé le Processus Simplié comme un Processus de développement logi-ciel vu qu'il était le plus adéquat à notre projet et ce pour les raisons suivantes : C'est un processus basé sur les cas d'utilisation comme le Processus Unié classique. Plus simple et facile à mettre en pratique que le PU. Ayant l'agilité de la programmation extrême. N'utilise que 20% des diagrammes UML pour modéliser 80% de l'application. La phase d'analyse de ce processus, comportant une étude du domaine (traduise par un diagramme des classes du domaine), est appropriée à l'esprit de la conception conduite par le domaine. La programmation extrême, étant une méthode agile de développement, ne s'adapte pas à notre projet vu que l'application à réaliser est dénie au début du stage. En général, le Processus Simplié est perçu comme une solution intermédiaire entre le Processus Unié et la Programmation extrême couvrant à la fois les avantages des deux processus et évitant leurs inconvénients. Le Processus Simplié est composé des phases suivantes : Étude des besoins : cette phase va être élaborée dans le chapitre3 de notre rapport. Elle consiste à délimiter le système en spéciant les besoins fonctionnels et non fonctionnels. Analyse : cette phase consiste à modéliser les besoins des utilisateurs à l'aide de diagrammes de cas d'utilisation. Elle sera élaborée dans le chapitre3. Conception : cette phase regroupe les cas d'utilisation détaillés accompagné des diagrammes de séquence détaillés ainsi que les diagrammes de classe d'activité et de déploiement. Cette phase sera détaillée dans le chapitre4. Implémentation : cette phase expose la structure générale de l'application et pré- sente les principaux modules. Conclusion Ce chapitre nous a permis de présenter le cadre général de notre projet en introduisant l'entreprise d'accueil et en expliquant le travail demandé et la méthodologie adoptée. Nous pouvons maintenant passer à l'étude de l'art.
  22. 22. Chapitre 2 État de l'art Introduction Avant de commencer l'étape du développement, nous avons cherché tout d'abord parmi les modules existants sous OpenERP, ceux qui orent des fonctionnalités exigées précé- demment dans le cahier des charges fonctionnel. Après une analyse des diérents modules, nous décrivons les modules utilisés dans notre système. 2.1 Module Gestion des Articles Dans le module responsable de gestion des produits et des listes des prix dans Ope-nERP, les articles peuvent avoir des variantes, diérentes méthodes de calcul du prix, les informations des fournisseurs, diérentes méthode de lancement de la fabrication (sur stock ou sur commande), diérentes unités de mesures, dénir le conditionnement et les propriétés. Figure 2.1 Formulaire Créer article Dans notre projet, nous mettons l'accent sur le traitement de Méthode de coût . 14
  23. 23. CHAPITRE 2. ÉTAT DE L'ART 15 Le champ marqué dans la gure de type liste déroulante qui contient les deux méthodes permettant la valorisation de prix de revient : Prix standard : Le prix de revient est mise à jour manuellement à la n de chaque période (généralement chaque année). Prix moyen : Le prix de revient est recalculé à chaque réception. Le fait de choisir la méthode de coût basé sur le Prix moyen , le champ Prix de revient devient de type readonly (en lecture seul) car la mise à jour se fait automatiquement en fonction de changement du Prix moyen . Le Prix moyen est recalculé à chaque réception selon la formule suivante : Figure 2.2 Formule de Prix moyen Le tableau 2.1 explique le processus de calcul de prix moyen lors des mouvements entrants et sortant d'un article. Table 2.1 Calcul Prix moyen Pour chaque article, il faut dénir sa catégorie, soit en choisissant une des catégories déjà créer ou on crée une nouveau. OpenERP simplie cette action, par la liste de recherche dans le formulaire de création d'article où on peut trouver la possibilité de création rapide. La gure 2.3 représente le formulaire de création d'une catégorie.
  24. 24. CHAPITRE 2. ÉTAT DE L'ART 16 Figure 2.3 Formulaire Créer Catégorie A l'aide de cette interface nous précisions le compte comptable d'article représenté dans le formulaire par la liste de sélection Compte d'entrée en stock . En eet, si la valorisation du stock est faite en temps réel, les écritures de contrepartie de tous les mouvements de stock entrants seront passées sur ce compte, sauf si un compte particulier est précisé pour l'emplacement source. C'est la valeur par défaut pour tous les articles de cette catégorie. Il est également possible de la préciser directement sur chaque article. Les comptes comptables appartiennent à un plan comptable dénit en installant le module Comptabilité et nance . 2.2 Module Comptabilité et Finance Figure 2.4 Module Comptabilité et nance Ce module ajoute les fonctionnalités comptables telles que les mouvements comptables et le plan comptable. Le plan comptable est l'ensemble des règles d'évaluation et de tenue
  25. 25. CHAPITRE 2. ÉTAT DE L'ART 17 des comptes qui constitue la norme de la comptabilité. Le plan de comptes, c'est-à-dire la liste des comptes ordonnée, est un des éléments du plan comptable. C'est à tort que le langage usuel réduit souvent le plan comptable au seul plan de comptes. Au minimum, quatre types de compte sont nécessaires pour enregistrer les évènements économiques et nanciers de l'entreprise : compte de produits, ce qui est produit ou vendu. compte de charges, ce qui est consommé ou acheté, dont le solde augmente ou diminue les capitaux propres. compte d'actifs, ce qui est possédé ou peut l'être. compte de passifs, ce qui est dû aux tiers, dont le solde représente les capitaux propres. Le tableau 2.2 décrit les principales fonctionnalités de ce module. Table 2.2 Fonctionnalités du Module Comptabilité et Finance
  26. 26. CHAPITRE 2. ÉTAT DE L'ART 18 2.3 Module Gestion des achats Figure 2.5 Module Gestion des achats Le module achat permet de créer et de suivre les commandes fournisseurs, gérer les informations fournisseurs, demandes de prix, de contrôler le processus de réception des articles et de vérier les factures des fournisseurs. Il permet aussi de créer une demande de prix lors d'un achat des articles à un four-nisseur mais que l'achat n'est pas encore conrmé. Le passage en revue est possible des demandes de prix crées automatiquement et basées sur des règles logistiques (stock mi-nimum, production à la demande, etc.). Le gestionnaire peut convertir une demande de prix en bon de commande une fois que la commande est conrmée. Ainsi sélectionner comment contrôler les factures fournisseur : sur les commandes, sur les réceptions ou par saisie manuelle. Le module achat permet de gérer facilement l'approvisionnement par les bons d'achats, et fournit des tableaux de bord et des rapports. Le tableau 2.3 décrit les principales fonctionnalités. Table 2.3 Fonctionnalités du Module Gestion des Achats
  27. 27. CHAPITRE 2. ÉTAT DE L'ART 19 Par le formulaire de la gure 2.6 le gestionnaire d'achat modélise le processus d'achat des articles, en précisant dans la page Bon de commande les diérents articles à acheter. Nous allons mettre l'accent sur cette partie qui contient les noms des articles, les quantités et les prix d'achat pour valoriser chaque prix de revient d'un article en stock. Figure 2.6 Formulaire Créer Bon de commande 2.4 Module Gestion de Production Figure 2.7 Module Gestion de production Ce module permet de couvrir la planication, les ordres, les stocks, la fabrication et l'assemblage des produits à partir de matières premières et de composants. Il gère la consommation et la production de produit selon leur nomenclature et les opérations néces-saires en machines, outils et ressources humaines en accord avec les gammes opératoires. Le module production supporte l'intégration complète et la planication des biens stockables, consommables ou des services.
  28. 28. CHAPITRE 2. ÉTAT DE L'ART 20 Le tableau 2.4 décrit les principales fonctionnalités du module production. Table 2.4 Fonctionnalités du Module Gestion de production
  29. 29. CHAPITRE 2. ÉTAT DE L'ART 21 2.5 Module Gestion de stock Figure 2.8 Module Gestion de stock OpenERP permet facilement de gérer le stock, le prélèvement, l'emballage et la li-vraison des produits. OpenERP met à la disposition des PME la valorisation des stocks en continu, méthode de gestion moderne utilisée par tous les grandes entreprises depuis plusieurs décennies. En plus OpenERP a inventé le système de double entrée de la gestion du stock per-mettant de gérer les besoins complexes très facilement : le suivi des stocks des fournisseurs / clients, une traçabilité complète, liens comptables, etc. OpenERP supporte la multi-gestion d'entrepôt basé sur la structure de localisation hiérarchique. Gérez vos propres emplacements internes, externes, lieux des clients, des fournisseurs ou des inventaires de fabrication. Le tableau 2.5 décrit les principales fonc-tionnalit és de ce module. Table 2.5 Fonctionnalités du Module gestion de stock
  30. 30. CHAPITRE 2. ÉTAT DE L'ART 22 Par l'interface de la gure 2.9 le gestionnaire de stock conrme la réception d'un bon de commande traité par le gestionnaire d'achat. A cette phase le calcule pour valoriser le stock se déclenche, d'où c'est l'une des importantes actions qu'il faut étudier dans notre projet. Figure 2.9 Interface Réception du bon de commande La barre en haut ache les états d'un bon de commande en distinguant l'état actuel. Les états d'un bon de commande sont : Brouillon : En cours. Prêt à recevoir : une fois la commande est conrmée par le gestionnaire d'achat. Reçu : quand le gestionnaire termine la réception.
  31. 31. CHAPITRE 2. ÉTAT DE L'ART 23 2.6 Processus de gestion Comme la valorisation du stock d'un article est une phase réalisée lors de la réception d'une quantité d'article à stocker, précédée par des phases représentant la cause de cette quantité. Ainsi, nous allons expliquer les processus de ces phases pour bien comprendre la démarche globale et an de dégager les points intéressant dans notre projet. 2.6.1 Réception par achat Au premier lieu, il faut créer des articles. C'est à l'aide du formulaire de création d'article (Figure 2.2). Le gestionnaire d'achat crée le bon de commande contenant les articles à acheter et en précisant la quantité et le prix unitaire (Figure 2.6). Après la conrmation du bon de commande, le gestionnaire de stock conrme la réception des articles en consultant l'interface de bon de réception (Figure 2.11) et en précisant les articles reçus à l'aide de l'assistant Recevoir article . Figure 2.10 Assistant Réception par article Lors de cette étape, les quantités achetées entre dans le stock avec changement du prix de revient. Donc il faut bien étudier cette partie dans notre projet. Nous allons nous intéresser dans cette étape du calcul du prix de revient. 2.6.2 Réception par production Comme le scénario précédent, il faut créer d'abord un article. Ce qui est diérent dans ce cas, c'est qu'il faut indiquer que l'article est obtenu par production. Ceci est eectué, en indiquant lors de la création que la méthode de fourniture est Produire . Nous allons intéresser aux ordres de fabrications an de valoriser les articles fabriqués qui seront stockés.
  32. 32. CHAPITRE 2. ÉTAT DE L'ART 24 Figure 2.11 Formulaire Créer Ordre de fabrication La liste de sélection Nomenclature permet de choisir une qu'était déjà crée ou pour créer une nouvelle nomenclature, en eet la nomenclature permet de dénir la liste des matières premières pour la fabrication d'un produit ni. Figure 2.12 Assistant Créer Nomenclature
  33. 33. CHAPITRE 2. ÉTAT DE L'ART 25 Après la création d'un article et la dénition de la nomenclature, le gestionnaire de production conrme l'ordre de fabrication ce qui provoque un mouvement des ma-ti ères premières, en attendant l'ordre de consommation an de produire l'article ar-ticle_ Production . L'ordre de consommation eectué par le gestionnaire de production. Pour chaque consommation d'un article de la nomenclature, cet article passe d'un article à consommé à un article consommé et nous allons mettre l'accent sur cette partie dans notre projet car cette action permet de dénir le coût de production d'article. Après la consommation des tous les articles de la nomenclature, le responsable de production conrme la fabrication par l'interface assistant de fabrication qui ache la quantité et le mode : Figure 2.13 Assistant Fabriquer Après la conrmation de fabrication, l'article fabriqué s'ajoute au stock avec la quan-tit é déjà précisé mais le prix de revient ne change pas. Figure 2.14 Interface Article
  34. 34. CHAPITRE 2. ÉTAT DE L'ART 26 Conclusion Dans ce chapitre nous avons étudié les diérents modules liés à notre projet et plus précisément les modules agissant sur la valorisation du stock. Ainsi nous pouvons passer aux phases d'analyse et de conception de notre module en commençant par la phase d'analyse qui correspond à la présentation de cahier de charges et les diagrammes de cas d'utilisation générales.
  35. 35. Chapitre 3 Analyse et spécication des besoins Introduction Après avoir présenté le projet précédemment et an de déterminer clairement les prin-cipales étapes à suivre. Une étude de l'existant s'avère alors nécessaire dans le but de proposer un meilleur aspect pour la réalisation. Cette étude est d'une grande utilité pour dénir les exigences demandés et surtout préciser les interactions et les intégrations à développer an de mieux présenter nos fonctionnalités aux utilisateurs. 3.1 Analyse de l'existant Une étude de l'existant est fortement indispensable. Elle permet d'extraire les insuf- sances, que les intervenants sont en train de rencontrer en utilisant les méthodes et les modules existantes. 3.1.1 Méthode de coût basé sur le Dernier prix Malgré l'importance d'une méthode de valorisation basée sur le dernier prix de ré- ception, pour plusieurs types d'articles, la version standard OpenERP n'ore pas cette possibilité qu'à travers le module reporting. Figure 3.1 Méthode de coût 27
  36. 36. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 28 3.1.2 Consultation des articles Manque au niveau des services liés à la consultation des indicateurs primordiaux pour une meilleure gestion de stock. En eet, pour chaque article le prix moyen pondéré, qui représente la valeur réel de la quantité en stock, et le dernier prix de réception, qui donne une vue approximatif à la valeur du produit dans le marché ou le coût réel de la fabrica-tion, sont nécessaire pour le gestionnaire de stock pour gérer les articles et les comparées avec le prix de revient. Ainsi l'inexistence d'un moyen pour consulter, dans la che article, l'historique de son prix de revient, an de former une idée sur son évolution en fonction de temps et les méthodes de coût utilisé. 3.1.3 Prix moyen pondéré et le dernier prix Dans ce qui précède, nous avons indiqué l'importance de ces deux valeurs pour un article. Or le module gestion des achats dans la version standard d'OpenERP ne les traite pas. 3.1.4 Valorisation du coût de fabrication d'un article Après un ordre de fabrication d'un article, le prix de revient ne change pas ; à cause de l'absence de calcul des coûts de fabrication, en tenant compte la valeur des articles consommés. La gure 2.20 montre que la valeur du prix de revient ne change pas même après la fabrication, et aucune indication sur le coût de production. 3.1.5 Changement automatique du prix de revient Absence des outils organisationnels pour contrôler et manipuler le changement de prix de revient par le gestionnaire de stock et le responsable générale, pour les articles géré par la méthode de coût basé sur le Prix moyen .
  37. 37. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 29 Figure 3.2 Changement automatique de prix de revint Cette gure est un extrait de scénario du chapitre précédent montre le changement automatique du prix de revient. Alors que pour les articles basés sur la méthode de coût Prix standard , le processus de changement de prix est eectué par papier ce qui peut provoquer plusieurs problèmes : perte de temps, perte de document, des données fausses, des erreurs de saisis, etc. 3.2 Étude de besoin Après une analyse de l'existant nous avons pu extraire les besoins pour gérer les prix au niveau du module stock et production. Dans cette section, nous allons essayer de donner une description des exigences fonctionnelles attendues 3.2.1 Besoins fonctionnels Améliorer la gestion des articles Intégrer une nouvelle méthode de coût basé sur le Dernier prix : à chaque ré- ception d'article, le prix de revient change automatiquement pour prendre comme valeur le prix unitaire de dernière réception. Consulter le prix moyen. Consulter le dernier prix. Consulter l'historique des prix de revient pour chaque article. Intégrer des méthodes de coût permettant de créer des articles avec changement de prix de revient contrôlé par le gestionnaire de stock et validé par le responsable. Améliorer la gestion de production Intégrer les traitements nécessaires pour calculer le dernier coût de fabrication et le prix moyen pour chaque stock d'article fabriqué.
  38. 38. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 30 Améliorer la gestion d'achat Intégrer les traitements nécessaires pour enregistrer le dernier prix d'achat d'un article et calculer le prix moyen pour chaque stock d'article. Gérer les demandes de changement des prix de revient An de créer un processus de changement de prix de revient dans OpenERP, il faut passer par l'intégration d'un nouveau module qui répond à certaines exigences : Création d'une demande de changement des prix, qui permet au gestionnaire de stock de préciser les articles à changer ; et en achant les informations nécessaires permettant d'orir une vue sur le changement de la valeur globale du stock, si cette demande est validé. Conrmation par le gestionnaire de stock Validation ou annulation par le respon-sable générale. Modication : la modication est permise tant que la demande n'est pas encore conrmée. Suppression demande. Consultation demande. Faciliter la recherche des demandes à travers des ltres. Réaliser le reporting nécessaire an d'obtenir des ches des demandes pour les en-treprises qui exigent la signature pour la validation. 3.2.2 Besoins non fonctionnels Les besoins non fonctionnels décrivent souvent les besoins d'utilisation qui font ré- férence à des aspects généraux de l'application. Donc pour bénécier d'une application able et ecace il faut qu'elle réponde à un certain nombre de besoins non fonctionnels : Réaliser des interfaces ergonomique et facile à utiliser, donc elles satisfont le critère de convivialité. Assurer l'homogénéité des interfaces du module à intégrer avec celles d'OpenERP. L'utilisateur doit être guidé lors de la saisie de certaines informations, an de res-pecter les formats des champs de base de données. L'utilisation du moteur workow d'OpenERP. la précision dans les messages d'erreurs. L'optimalité dans le temps de réponse et la rapidité du traitement. L'internationalisation. L'utilisation des aspects implémentés dans OpenERP : La condentialité des données. Assurer la sécurité de l'application. Utiliser les notions de sessions et authentication.
  39. 39. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 31 3.3 Diagramme de cas d'utilisation La conception sera modélisée à l'aide du langage UML (Unied Modeling Language) en raison de son formalisme relativement simple. C'est un langage qui permet une meilleure compréhension du système et qui désigne l'interface entre les diérents acteurs d'un projet commun. 3.3.1 Identication des acteurs L'analyse dans la démarche d'UML débute par la recherche des acteurs du système. En eet, un acteur est toute entité qui joue un rôle, actif ou passif, vis-à-vis le système. Un acteur peut être un utilisateur direct du système, un administrateur (assure la main-tenance) du système ou tout autre système externe avec lequel le système interagit. À ce stade nous allons déterminer les six acteurs principaux interagissant avec le système. Table 3.1 Acteurs principaux
  40. 40. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 32 3.3.2 Diagramme de cas d'utilisation global Le diagramme des cas d'utilisation est la solution UML pour représenter le modèle conceptuel et pour structurer les besoins et les objectifs. Il représente les utilisations pos-sibles du système par les diérents acteurs. Un cas d'utilisation représente un ensemble de séquence d'actions réalisées par le système et produit un résultat observable intéressant pour un acteur particulier. Nous présentons le diagramme de cas d'utilisation global et nous détaillerons par la suite les cas d'utilisation nécessitant une description plus approfondie. Cette gure représente le diagramme général de notre système : Figure 3.3 Diagramme de cas d'utilisation global Cas d'utilisation Gérer article Titre : Gérer article. Description : le gestionnaire de stock possède le privilège d'eectuer des tâches de gestion sur les articles. Il peut ajouter, modier, consulter ou supprimer des articles. Acteur : Gestionnaire de stock. Pré-condition : le gestionnaire de stock est authentié. Scénario : Le gestionnaire de stock accède au menu de gestion des articles. Le gestionnaire de stock choisit l'opération qu'il désire eectuer sur l'article. Le système vérie les contraintes relatives à cette opération. Le système enregistre les modications relatives à l'article. Le système ache l'écran de l'article en mode achage seul pour renseigner l'uti-lisateur de succès de l'enregistrement
  41. 41. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 33 Post-condition : l'article est modié suivant l'opération eectuée par le gestion-naire de stock. Cas d'utilisation Recevoir article Titre : Recevoir article. Description : Le gestionnaire de stock réceptionne les articles. Acteur : Gestionnaire de stock. Pré-condition : le gestionnaire de stock est authentié. Scénario : Le gestionnaire de stock accède au menu du bon de réception. Le gestionnaire de stock accède à l'assistant de réception. Le gestionnaire de stock conrme la réception de chaque article. Le système calcule pour chaque article le prix moyen et l'enregistre ainsi le dernier prix, et enregistre le prix de revient si la méthode d'article est Prix moyen ou Dernier prix . Le système enregistre les modications relatives au bon de réception. Post-condition : les articles du bon de commande sont stockés. Cas d'utilisation Gérer Demande de changement des prix Titre : Gérer demande de changement des prix. Description : le gestionnaire de stock possède le privilège d'eectuer des tâches de gestion sur les demandes. Il peut ajouter, modier, consulter ou supprimer des demandes. Acteur : Gestionnaire de stock. Pré-condition : le gestionnaire de stock est authentié. Scénario : Le gestionnaire de stock accède au menu Changement des demandes. Le gestionnaire de stock choisit l'opération qu'il désire eectuer sur la demande. Le système vérie les contraintes relatives à cette opération Le système enregistre les modications relatives à la demande. Post-condition : La demande est modiée suivant l'opération eectuée par le ges-tionnaire de stock.
  42. 42. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 34 3.3.3 Diagramme de cas d'utilisation Gérer article Figure 3.4 Diagramme de cas d'utilisation Gérer article Cas d'utilisation Modier méthode de coût Titre : Modier méthode de coût. Description : modier la méthode de calcul de coût. Acteur : Gestionnaire de stock Pré-condition : le gestionnaire de stock est authentié et l'article est créé. Scénario : Le gestionnaire de stock accède au menu de gestion des articles. Le gestionnaire de stock choisit l'opération modier article . Le gestionnaire de stock sélectionne une nouvelle méthode de coût. Le système modie le type d'accès au champ Prix de revient selon la nouvelle méthode choisit. Le gestionnaire de stock conrme les modications. Le système enregistre les modications relatives à l'article. Le système ache l'écran de l'article en mode achage seul pour renseigner l'uti-lisateur de succès de l'enregistrement. Post-condition : l'article est modié. Cas d'utilisation Actualiser historique Titre : Actualiser historique Description : le gestionnaire de stock ache l'historique des prix de revient déjà utilisés auparavant.
  43. 43. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 35 Acteur : Gestionnaire de stock Pré-condition : le gestionnaire de stock est authentié. Scénario : Le gestionnaire de stock accède au menu de gestion des articles. Le gestionnaire de stock choisit l'article à consulter. Le gestionnaire de stock accède à la page Historique Le gestionnaire de stock actualise l'historique. Le système ache l'historique des prix de revient de cet article. Post-condition : l'écran historique est aché. Cas d'utilisation Consulter Prix moyen Titre : Consulter Prix moyen Description : le gestionnaire de stock aura la possibilité de consulter à tout moment le prix moyen de chaque article. Acteur : Gestionnaire de stock Pré-condition : le gestionnaire de stock est authentié. Scénario : Le gestionnaire de stock accède au menu de gestion des articles. Le gestionnaire de stock choisit l'article à consulter. Le système charge les données à acher pour cet article. Le gestionnaire de stock accède à la page Informations Post-condition : Le prix moyen de l'article en stock est aché. 3.3.4 Diagramme cas d'utilisation Recevoir article Figure 3.5 Diagramme cas d'utilisation Recevoir article Cas d'utilisation Fabriquer article Titre : Fabriquer article
  44. 44. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 36 Description : Le responsable de production conrme la fabrication d'un article. Acteur : Responsable de production. Pré-condition : le gestionnaire de stock est authentié. Scénario : Le Responsable de production accède au menu des ordres de fabrications. Le Responsable de production choisit l'ordre de fabrication à traiter. Le Responsable de production conrme la fabrication. Le système déclenche les calculs nécessaires pour valoriser le coût de fabrication. Le système enregistre les modications relatives à l'article fabriqué. Post-condition : l'ordre de fabrication est terminé et la quantité de l'article est stockée. 3.3.5 Diagramme cas d'utilisation Gérer Demande de change-ment des prix par le gestionnaire de stock Figure 3.6 Diagramme cas d'utilisation Gérer demande de changement des prix Cas d'utilisation Conrmer demande Titre : Conrmer demande. Description : le gestionnaire de stock conrme la demande de changement des prix. Acteur : Gestionnaire de stock Pré-condition : le gestionnaire de stock est au-thenti é. Scénario : Le gestionnaire de stock accède au menu Changement des prix. Le gestionnaire de stock choisit la demande à conrmer. Le système vérie les contraintes relatives à cette opération. Le système modie l'état de demande à demande conrmé.
  45. 45. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 37 Le système modie le type d'accès à la demande en lecture seul. Post-condition : la demande de changement des prix est conrmée. 3.3.6 Diagramme de cas d'utilisation Créer Demande de chan-gement des prix Figure 3.7 Diagramme cas d'utilisation Créer Demande Cas d'utilisation Créer demande Titre : Créer demande Description : le gestionnaire de stock Acteur : Gestionnaire de stock Pré-condition : le gestionnaire de stock est authentié. Scénario : Le gestionnaire de stock accède au menu Changement des prix. Le gestionnaire de stock choisit l'option Créer . Le gestionnaire de stock charge la liste des articles à changer. Le gestionnaire de stock donne l'ordre pour calculer les valeurs des comptes comp-tables associé aux articles. Le système enregistre la demande avec état brouillon . Post-condition : une demande de changement des prix est créée.
  46. 46. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 38 Cas d'utilisation Charger par ajout article Titre : Charger par ajout article. Description : le gestionnaire de stock charge la liste des articles à changer. Acteur : Gestionnaire de stock. Pré-condition : le gestionnaire de stock est authentié. Scénario : Le gestionnaire de stock accède au menu Changement des prix. Le gestionnaire de stock choisit l'option Créer ou Modier une demande en état brouillon. Le gestionnaire de stock accède au menu Changement des prix. Le système vérie les contraintes relatives à cette opération. Le système enregistre les modications relatives à l'article. Post-condition : La liste des articles à changer d'une demande est chargée. Cas d'utilisation Charger par assistant Titre : Charger par assistant Description : le gestionnaire de stock charge la liste des articles à changer en utilisant un assistant. Acteur : Gestionnaire de stock Pré-condition : le gestionnaire de stock est authentié. Scénario : Le gestionnaire de stock accède au menu de Changement des prix. Le gestionnaire de stock choisit l'opération qu'il désire eectuer sur l'article. Le système vérie les contraintes relatives à cette opération. Le système enregistre les modications relatives à l'article. Post-condition : La liste des articles est chargée.
  47. 47. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 39 3.3.7 Diagramme cas d'utilisation Gérer Demande de change-ment des prix par le Manager Figure 3.8 Diagramme cas d'utilisation Gérer Demande de changement par le Manager Cas d'utilisation Valider demande Titre : Valider demande Description : le Manager valide une demande de changement des prix Acteur : Manager Pré-condition : le Manager est authentié. Scénario : Le Manager accède au menu Changement des prix Le Manager choisit la demande conrmé. Le Manger consulte la liste des articles à changer Le Manager consulte la liste des comptes comptables des articles Le Manager valide la demande Le système modie les prix de revient des articles de la liste. Le système enregistre les modications relatives à la demande. Post-condition : la demande de changement des prix est validée et les prix de revient des articles sont changés. Cas d'utilisation Annuler demande Titre : Annuler demande Description : Le Manager annule une demande de changement des prix. Acteur : Manager. Pré-condition : Le Manager est authentié. Scénario : Le Manager accède au menu Changement des prix. Le Manager choisit la demande conrmé.
  48. 48. CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS 40 Le Manger consulte la liste des articles à changer. Le Manager consulte la liste des comptes comptables des articles. Le Manager annule la demande. Le système enregistre les modications relatives à la demande. Post-condition : La demande de changement des prix est annulée. Conclusion Dans ce chapitre, nous avons présenté une étude de l'existence ainsi que les besoins fonctionnels et non fonctionnels qui ont été illustrés par des diagrammes de cas d'uti-lisations. Dans le chapitre qui suit, on se propose de faire une conception détaillée du projet.
  49. 49. Chapitre 4 Conception Introduction Après avoir spécié les besoins et xer les choix conceptuels qui seront adoptés lors de la réalisation de notre projet, nous abordons la phase de la conception. Dans ce chapitre, nous allons détailler la conception de chaque fonctionnalité à part. Cette phase de conception est primordiale dans le cycle de vie d'un logiciel : elle permet de mettre en place un modèle sur lequel nous allons s'appuyer tout au long de la phase de développement. 4.1 Diagramme de classes Le diagramme des classes identie la structure des classes d'un système, y com-pris les propriétés et les méthodes de chaque classe. Les diverses relations, telles que la relation d'héritage par exemple, qui peuvent exister entre les classes y sont également représentées. Le diagramme des classes est le diagramme le plus largement répandu dans les spécications d'UML. Ce diagramme représente les classes relatives à la conception de notre module, Ainsi que les modications apportées sur les tables d'OpenERP. Remarque : les classes en blanc présentent la conception d'OpenERP déjà existante. 41
  50. 50. CHAPITRE 4. CONCEPTION 42 Figure 4.1 Diagramme de classes
  51. 51. CHAPITRE 4. CONCEPTION 43 Description Pour mieux comprendre l'aspect d'intégration de notre module, nous allons aussi ex-pliquer les classes existantes : stock_picking Elle représente la réception et la livraison des articles : entrant dans le stock par achat ou production, ainsi les mouvements sortant du stock soit livraison (vente) ou consommation lors de la production. L'objet stock_picking représente un mouvement global composé des lignes élémentaires des mouvements de la transaction réception ou livraison). stock_move Elle représente le mouvement unitaire d'un article. C'est un élément du mouvement global stock_picking , qui précise principalement la quantité, le prix et l'emplacement pour chaque article. stock_picking_ext Hérité de la classe stock_picking . Il redénit la méthode do_partial qui est responsable de calcul du prix de revient an de contrôler le changement automatique des prix de revient, et pour enregistrer le dernier prix et aussi calculer le prix moyen pour chaque mouvement. purchase_order Représente le bon de commande fournisseur, composé par des achats des articles re-pr ésentés dans la classe purchase_order_line . La création d'un bon de commande se termine par la création d'un mouvement d'article vers le stock. purchase_order_line Elle dénit les lignes liées aux bons de commandes, qui identie l'article acheté, sa quantité et son prix unitaire. mrp_production Elle dénit l'ordre de fabrication d'un article, un article fabriqué consomme les matières premiers à partir de la nomenclature dénit dans la classe mrp_bom qui représente la nomenclature d'un article à fabriquer, où elle dénit la quantité unitaire de chaque article des matières premiers et son prix de stock. mrp_production_ext Hérité de la classe mrp_production . Elle redénit la méthode _cost_generate
  52. 52. CHAPITRE 4. CONCEPTION 44 qui est responsable du calcul du coût de fabrication d'un article, an d'enregistrer les valeurs associé à chaque fabrication et de contrôler l'aectation de prix de revient product_product C'est la classe qui représente les articles, elle dénit toutes les informations sur un article : nom, code, catégorie, méthode de coût, prix de revient, etc. product_product_ext Hérité de la classe product_product an d'ajouter, les valeurs nécessaires à la gestion du prix moyen et le dernier prix pour chaque article. Elle redénit l'attribut méthode de coût pour ajouter les nouvelles méthodes à intégrer. stock_change_price C'est la classe qui représente la demande de changement de prix de revient crée par le gestionnaire de stock, une demande est dénie par les attributs référence, date de création, total actuel(valeur actuel des tous les articles stockés associés à des comptes comptables des articles existants dans la demande), nouveau total (c'est la valeur de stock atteint si les articles de la demande change de prix de revient),et enn l'attribut état qui désigne l'état de le demande (brouillon, conrmé, annulé, validé) stock_change_price_line C'est la classe qui représente les articles à changer associés à une demande en identiant l'article, quantité en stock, le prix de revient actuel, le nouveau prix le total actuel, nouveau total et ratio pour connaitre la progression de la valeur des articles en stock une fois les prix de revient changent. stock_compte_comptable Cette classe dénit, pour une demande de changement, les comptes comptables associés aux articles ajoutés dans la demande. stock_ll_change_price Elle dénit la liste des articles à changer pour une demande en spéciant le choix des méthodes de coût à traiter (seulement les articles avec méthodes de coût Prix moyen Controlé , ou seulement les Dernier prix Controlé , ou les deux). product_history Cette classe représente l'historique des prix de revient pour tous les articles, en iden-ti ant l'article, le nouveau prix de revient aecté, la date d'aectation et la méthode de coût utilisée pour obtenir ce prix de revient.
  53. 53. CHAPITRE 4. CONCEPTION 45 4.2 Diagramme de séquence Dans le formalisme UML, un diagramme de séquence est une présentation graphique des interactions entre les objets du système selon un ordre chronologique. Un diagramme de cas d'utilisation peut seulement donner une vue générale simplié d'un cas ou d'un en-semble de cas d'utilisation et pour mieux décrire chaque cas d'utilisation nous avons utilisé le diagramme de séquence. En eet Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans la formulation UML. Ils servent à illustrer un cas d'utilisation. Dans les diagrammes de séquence, nous allons utiliser pour les requêtes traitant les objets persistais les noms des méthodes ORM : Search : ore les fonctionnalités d'une requête de sélection, elle retourne les identi- cateurs. Browse : permet de charger un tous les données d'un enregistrement. Unlink : permet de supprimer un enregistrement. Create : permet d'insérer un nouvel enregistrement. Write : permet de modier un enregistrement. 4.2.1 Diagramme de séquence Modier méthode de coût Figure 4.2 Diagramme de séquence Modier méthode de coût La gure 4.2 décrit le déroulement du cas d'utilisation Modier méthode de coût , qui apparaît dans la gure : 3.5. Le gestionnaire de stock, accède à l'écran de consultation d'article, ensuite il appuie sur le bouton Modier et il modier la méthode de coût à travers la liste des choix qui ache toutes les méthodes de coût dans OpenERP (les
  54. 54. CHAPITRE 4. CONCEPTION 46 méthodes de la version standard et les méthode ajoutées). Après le gestionnaire de stock conrme la modication en appuyant sur le bouton Enregistrer qui déclenche le traitement de modication de la méthode de coût en interagissant avec l'objet persisté. 4.2.2 Diagramme de séquence Actualiser historique Figure 4.3 Diagramme de séquence Actualiser historique La gure 4.3 décrit le déroulement du cas d'utilisation Actualiser historique , qui apparaît dans la gure : 3.4. Chaque utilisateur de l'OpenERP, peut accéder à l'écran de consultation d'article, ensuite il clique sur l'onglet de la page historique, et après il appuie sur le bouton d'actualisation qui envoie, à partir de la couche de traitement, une requête de sélection traitant l'objet persisté historique (qui contient l'historique de tous les articles) an de récupérer seulement les données liée à l'article courant. Les données seront stockées dans une table réservée pour l'achage de l'historique d'un article.
  55. 55. CHAPITRE 4. CONCEPTION 47 4.2.3 Diagramme de séquence Recevoir articles achetés Figure 4.4 Diagramme de séquence Recevoir article acheté La gure 4.3 décrit le déroulement du cas d'utilisation Recevoir article acheté , qui apparaît dans la gure : 3.5. Le gestionnaire de stock, accède à l'écran de consulta-tion d'un bon de réception non encore reçu, il appuie sur le bouton Reçu qui fait apparaître l'assistant Recevoir article qui ache les articles non reçu d'un bon de commande. Le gestionnaire de stock conrme la réception en cliquant sur le bouton rece-voir. Ce qui produit un appel à la méthode do_partail de la couche du traitement stock_picking . Récupérer, au début, les mouvements entrants en interrogeant son objet persisté stock.move , pour extraire les données des articles entrants. Ensuite calculer le nouveau prix moyen de chaque article. Finalement, mettre à jour le prix moyen et le dernier prix pour chaque article , à travers l'objet persisté Article , et modier le prix de revient si la méthode de coût de l'article n'est pas contrôlé. Pour les méthodes de coût automatique, enregistrer le changement de prix de revient à travers l'objet persisté Historique .
  56. 56. CHAPITRE 4. CONCEPTION 48 4.2.4 Diagramme de séquence Fabriquer article Figure 4.5 Diagramme de séquence Fabriquer article La gure 4.5 décrit le déroulement du cas d'utilisation Fabriquer article , qui apparaît dans la gure : 3.5. Le responsable de production, accède à l'écran de consul-tation d'un ordre de fabrication non terminé. Il appuie sur le bouton Fabriquer qui fait apparaître l'assistant Fabriquer article , en achant l'article à fabriquer ainsi sa quantité. Le responsable de production conrme la fabrication en cliquant sur le bouton Fabriquer , qui fait appel à la méthode do_produce de la couche du traitement de production. Au début, le traitement de la méthode commence par récupérer les mouve-ments des articles consommés en interrogeant son objet persisté stock.move . Ensuite extraire les données des articles consommés an de calculer le coût de fabrication et le nouveau prix moyen de cet article. A la n, faire les modications dans l'objet persisté de l'article concernant le prix moyen, dernier prix et le prix de revient selon la méthode de coût utilisé. Pour les méthodes de coût automatique, enregistrer le changement de prix de revient à travers l'objet persisté Historique .
  57. 57. CHAPITRE 4. CONCEPTION 49 4.2.5 Diagramme de séquence Charger par ajout article Figure 4.6 Diagramme de séquence Charger par ajouter article La gure 4.6 décrit le déroulement du cas d'utilisation Charger par ajout article , qui apparaît dans la gure : 3.7. Le gestionnaire de stock, accède à l'écran de création d'une demande de changement des prix, dans la liste des articles à changer il saisit le nom d'article. L'ajout d'article déclenche le traitement de la méthode on_change_product pour calculer le nouveau total et acher le prix de revient actuel et le nouveau prix de revient en interrogeant l'objet persisté Article . 4.2.6 Diagramme de séquence Charger par assistant La gure 4.6 décrit le déroulement du cas d'utilisation Charger par assistant , qui apparaît dans la gure : 3.7. Le gestionnaire de stock, accède à l'écran de création d'une demande de changement des prix. Il appuie sur le bouton Charger Liste qui fait apparaître l'assistant de chargement. Il spécie les méthodes de coût à traiter et il précise les comptes comptables des articles à changer. Ensuite il appuie sur le bouton Charger liste qui déclenche le traitement de la méthode action_consult qui permet de récupérer les articles associés aux comptes comptables précisés selon la méthode spécié. Ensuite la méthode calcule les totaux actuels et les nouveaux totaux , et les enregistre, à travers l'objet persisté de la liste des articles Articles-Demande .Enn fermer l'assistant et acher les articles à changer.
  58. 58. CHAPITRE 4. CONCEPTION 50 Figure 4.7 Diagramme de séquence Charger par assistant
  59. 59. CHAPITRE 4. CONCEPTION 51 4.2.7 Diagramme de séquence Calculer les valeurs des comptes comptables Figure 4.8 Diagramme de séquence Calculer les valeurs des comptes comptables La gure 4.8 décrit le déroulement du cas d'utilisation Calculer les valeurs des comptes comptables , qui apparaît dans la gure : 3.7. Le gestionnaire de stock, accède à l'écran de création d'une demande de changement des prix. Il accède à l'onglet compte comptable et il appuie sur le bouton calculer . Le traitement commence par parcourir la liste des articles à changer, et chercher pour chaque article son compte comptable et calculer pour ce dernier les valeurs des totaux de ses articles stockés.
  60. 60. CHAPITRE 4. CONCEPTION 52 4.2.8 Diagramme de séquence Valider demande Figure 4.9 Diagramme de séquence Valider demande La gure 4.9 décrit le déroulement du cas d'utilisation Valider demande , qui apparaît dans la gure : 3.8. Le Manager, accède à l'écran de consultation d'une demande de changement des prix conrmé, il consulte la liste des articles et la liste des comptes comptables. Après il valide la demande en cliquant sur le bouton Valider qui déclenche le traitement de la méthode action_done pour modier les nouveaux prix de revient, à travers l'objet persisté Article , et enregistrer les changements à travers l'objet persisté Historique . 4.3 Diagramme d'états-transitions Un diagramme d'états-transitions est associé à une classe et décrit les séquences d'états qu'un objet peut prendre en réponse à un évènement. L'état est une situation dans laquelle peuvent se trouver les objets d'une classe durant leur vie. Puisque un objet est toujours dans un état déni ou connu pour un certain temps, les états se caractérisent par une durée dénie dans le temps et par une stabilité par rapport au temps. Dans un état, l'objet peut satisfaire des conditions, accomplir des actions ou réagir à des évène-ments. Une classe, lorsque'elle a une dynamique non négligeable, dispose de son automate, représenté sous forme de diagramme d'états transitions. Pour élaborer ce diagramme, en premier lieu, il faut identier l'état initial et l'en-semble des états naux, ensuite il faut identier les diérents états intermédiaires et enn
  61. 61. CHAPITRE 4. CONCEPTION 53 il faut relier ces états entre eux en utilisant des transitions contrôlées par des conditions de passage. Figure 4.10 Diagramme d'état-transition Demande de changement Une demande de changement des prix, après sa création, sera chargée par les articles à changer en restant dans l'état Brouillon. Son état passera alors à l'état conrmé lorsque le gestionnaire de stock conrme l'émission au Manager et selon les décisions prises pour sa gestion, elle pourra être annulé ou validé. A tout moment la demande peut être supprimé, les états naux représentés par : Demande supprimer et Demande validé. Conclusion Ce chapitre a permis de comprendre en détails les diérentes fonctionnalités atten-dues de notre module et l'enchaînement de leur déroulement dans le temps. Ceci donne la possibilité de passer au développement de la solution. Le cinquième chapitre portera sur une description détaillée de l'environnement dans lequel notre projet a été réalisé ainsi qu'une présentation des interfaces.
  62. 62. Chapitre 5 Étude technique et Réalisation Introduction Pour le développement du système nous nous sommes basés sur le Framework Ope-nERP et les diérentes technologies qu'il utilise, et pour ajouter le système comme module au sein de cet ERP nous avons eu recours à plusieurs outils, dont la présentation est dé- taillée dans les paragraphes suivants. Nous passerons ensuite aux détails de la réalisation. 5.1 Environnement logiciel Le bon choix de l'environnement de travail est très important. Dans ce chapitre, nous nous intéressons aux choix des technologies et des environnements aidant à l'implémen-tation de notre application. 5.1.1 Outil de conception : PowerAMC An de modéliser notre travail en langage UML, nous avons utilisé un logiciel complet de modélisation intitulé Power AMC dans sa version 15.1. C'est un outil tout-en-un de mo-d élisation d'entreprise et de gestion de métadonnées destiné à documenter l'architecture d'entreprise. Figure 5.1 Logo PowerAMC 54
  63. 63. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 55 PowerAMC est un environnement graphique très simple à utiliser qui permet d'eec-tuer les tâches suivantes : Modélisation intégrée via l'utilisation de méthodologies et de notations standards : Données (E/R, Merise), Métiers (BPMN, BPEL, ebXML), Application (UML), Génération automatique de code via des Template personnalisables, SQL (avec plus de 50 SGBD), Java, NET. Fonctionnalités de reverse engineering pour documenter et mettre à jour des sys-t èmes existants, Une solution de référentiel d'entreprise avec des fonctionnalités de sécurité et de gestion des versions très complètes pour permettre un développement multiutilisa-teurs, Fonctionnalités de génération et de gestion de rapports automatisés et personnali-sables, Un environnement extensible, qui vous permet d'ajouter des règles, des commandes, des concepts et des attributs à vos méthodologies de modélisation et de codage. [9] 5.1.2 Système de gestion de base de données : PostgreSQL Nous avons utilisé PostgeSQL dans sa version 9.2 comme système de gestion de base de données relationnel objet (SGBDRO) Figure 5.2 Logo PostgreSQL C'est un outil libre disponible selon les termes d'une licence de type BSD. Comme les projets libres, PostgreSQL n'est pas contrôlé par une seule entreprise, mais est fondé sur une communauté mondiale de développeurs et d'entreprises.
  64. 64. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 56 PostgreSQL peut stocker plus de types de données que les types traditionnels : entiers, caractères, etc. L'utilisateur peut créer des types, des fonctions, utiliser l'héritage de type etc. PostgreSQL est pratiquement conforme aux normes ANSI SQL 89, SQL 92 (SQL 2), SQL 99 (SQL 3), SQL :2003 et SQL :2008. PostgreSQL est largement reconnu par son comportement stable, proche d'Oracle. Mais aussi par ses possibilités de programmation étendues, directement dans le moteur de la base de données, via PL/pgSQL. Le traitement interne des données peut aussi être couplé à d'autres modules externes compilés dans d'autres langages. 5.1.3 Éditeur de texte : Notepad++ Pour le développement en langage Python, nous n'avons pas utilisé d'environnement de développement particulier. L'utilisation d'un éditeur de texte avancé permet de rendre le code plus lisible et de fournir des fonctions supplémentaires. Le logiciel Open Source Notepad++ a donc été mon éditeur pour le développement en Python et aussi pour XML. Figure 5.3 Logo Notepad++ Notepad++ est un éditeur de code source qui prend en charge plusieurs langages. Ce programme, codé en C++ avec STL et win32 api, a pour vocation de fournir un éditeur de code source de taille réduite mais très performant. En optimisant de nombreuses fonctions tout en conservant une facilité d'utilisation et une certaine convivialité. Notepad++ ore plusieurs fonctionnalités : Coloration syntaxique et Relief syntaxique (Folding de syntaxe) Langage dénit par utilisateur PCRE (Perl Compatible Regular Expression) pour la recherche et le replacement Plan du document Auto-complétion Multi-documents (Les onglets) Multi-Vues WYSIWYG (What You See Is What You Get - verser l'impression). [10]
  65. 65. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 57 5.1.4 Éditeur de catalogues textuels : PoEdit L'internationalisation d'un logiciel consiste à préparer son adaptation à des langues diérentes. Pour traduire OpenERP ou un de ses modules c'est mettre en Français (ou autre langue) des phrases qui sont en Anglais. Pour cela nous avons utilisé l'éditeur PoEdit. Figure 5.4 Logo PoEdit PoEdit est un éditeur de catalogues textuels (chiers ayant l'extension .po). C'est une assistance précieuse à la traduction. Ce logiciel permet : de traduire automatiquement selon une base de données, de visualiser ergonomiquement dans un système de double achage la version ori-ginale et sa traduction, tout en travaillant et validant cette traduction, [11] Lors de la première utilisation, le logiciel demande à l'utilisateur de l'aider à créer une base de données qui l'aidera plus tard pour la traduction automatique. Cette opération est assez longue mais nécessaire pour une traduction automatisée. 5.2 Technologies Pour le développement du système je me suis basés sur l'ERP OpenERP et les dié- rentes technologies et Framework qu'il utilise,dont la présentation est détaillée dans les paragraphes suivants. 5.2.1 Framework OpenERP Un Framework est un ensemble de fonctions bas niveau qui permettent de gérer les besoins et concepts les plus couramment utilisés dans le développement d'un logiciel, et lui sert ainsi de base technologique.
  66. 66. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 58 Anciennement connu par Framework OpenObject , mais comme cela était source de beaucoup de confusion car beaucoup de gens se demandaient quelle était la diérence entre OpenObject et OpenERP, cette appellation a été ociellement abandonnée. Ce Framework est un environnement qui dispose d'une boite à outils complète et modulaire permettant un développement simple et rapide des applications. Pour créer un module OpenERP, la création d'un chier Python contenant la description des champs et des règles de gestion et un chier XML décrivant les écrans, c'est susant. OpenERP aussi permet la création de Wizards (sous-programmes), l'automatisation des tâches et leur planication, l'intégration de données par défaut et/ou de démonstration. Figure 5.5 Module OpenERP Le Framework d'OpenERP se distingue par l'intégration d'un ORM, un moteur de workow et un moteur de rapports et plusieurs fonctionnalités. ORM : Object Relational Mapping OpenERP utilise un ORM pour la persistance de ses objets métier. Dès ses débuts, OpenERP s'est doté d'un ORM, alors que cette technologie était encore très peu répan-due. L'ORM permet d'avoir une couche d'abstraction par rapport à la base de données ; il gère les droits d'accès et évite d'avoir à écrire le code SQL dans lequel il faut refaire toutes les relations entre les tables avec des JOIN. En eet, c'est une technique de pro-grammation qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en dénissant des correspondances entre cette base de données et les objets du langage utilisé. C'est une correspondance entre monde objet et monde relationnel. L'ORM d'OpenERP ne fonctionne qu'avec PostgreSQL.
  67. 67. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 59 Figure 5.6 ORM d'OpenERP Cette couche (notamment dans OpenERP) permet de centraliser les vérications de la validité des données lors de la sauvegarde, les vérications des droits d'accès, etc. Les objets métier sont déclarés comme des classes Python héritant de la classe osv se trouvant dans le module osv( l'Object Service OSV implémente une couche complet de mapping objet-relationnel), ce qui les rend partie de la modèle OpenERP, et persisté par la couche ORM. Figure 5.7 Objet OpenERP OpenERP a fait évoluer son ORM au fur et à mesure des versions, mais continue d'utiliser son propre ORM et n'a pas basculé vers un ORM libre standard . Cependant, il reste possible d'utiliser des requêtes SQL dans le code d'OpenERP, par exemple pour certaines parties du code où les performances sont très importantes. Moteur de workow Le workow (ux de travaux) concerne l'analyse, la modélisation et l'automatisation des ux d'information dans l'entreprise. Il s'appuie sur des outils informatiques automa-tisant la circulation des documents. Il permet ainsi d'organiser dynamiquement les tâches au sein d'un cheminement documenté, planié, contrôlable en permanence et aisément adaptable au gré des évolutions de l'environnement.
  68. 68. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 60 Il existe plusieurs types de workow : Le workow administratif, concernant les documents internes à l'entreprise (enga-gement de dépense, gestion des absences...). Le workow de production, concernant les procédures classiques de l'entreprise (prise de commande, émission de facture, gestion des réclamations des clients...). Le workow collaboratif, qui fait intervenir des acteurs internes ou externes sur un sujet commun (documentation technique, fourniture de produits complexes...). Bien que nécessitant un investissement important et la réorganisation des processus de l'entreprise, la mise en place d'un workow apporte des avantages substantiels : Diminution des délais de réaction. Augmentation de la productivité (essentiellement dans les services administratifs). Diminution des erreurs. OpenERP intègre un moteur de workow. Ceci permet de formaliser les règles métier de l'entreprise an d'automatiser la prise de décision, c'est-à-dire la branche du workow à choisir, en fonction du contexte donné. [12] Moteur de rapport Le moteur de rapport par défaut d'OpenERP est basé sur le langage RML, qui est un standard mis au point par la société anglaise ReportLab. La société ReportLab a développé une implémentation OpenSource limitée et une implémentation propriétaire payante plus complète du langage RML. OpenERP a réalisé sa propre implémentation du langage RML en développant un outil de conversion RML vers PDF et RML vers HTML. Cette implémentation est disponible dans le serveur OpenERP. Il y a 2 façons de se servir de ce moteur de rapport : coder le rapport directement en RML. Cela implique d'apprendre ce langage ; concevoir le rapport dans OpenOce ou LibreOce et transférer le chier SXW (le format de chier d'OpenOce 1.x) résultant dans un module OpenERP. Le chier est alors stocké au format SXW et converti au format RML. Si le format de sortie du rapport est le format PDF ou HTML, alors le serveur OpenERP va lire le chier RML (codé ou généré à partir du chier SXW), puis il va remplacer les champs par leur valeur, et enn il va utiliser son moteur de conversion RML2PDF ou RML2HTML pour convertir le chier RML au format PDF ou HTML.[13]
  69. 69. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 61 L'accès généralisé via les web services en XML-RPC Toutes les communications entre le Framework et les interfaces sont eectuées en XMLRPC. Les types d'objets, les écrans, les données sont transmises par ce protocole. Tous les objets d'OpenERP sont accessibles via les web services, que ce soit en lecture, écriture, création et suppression. Aussi toutes les fonctions d'OpenERP sont accessibles en web services. Cela signie par exemple que n'importe quel clic sur un bouton de l'in-terface d'OpenERP peut être fait depuis un web service. Comme l'accès via les web services est une fonction native du Framework, lors de développement d'un module spécique qui crée un nouvel objet, et un nouveau bouton, alors cet objet et ce bouton seront automatiquement accessibles en web services, sans écrire du code spéciquement pour cela. 5.2.2 Langage de programmation : Python Le Framework d'OpenERP utilise le langage Python (version 2.7) ; plus précisément, il impose que les modules soient écrits en Python et il est lui-même codé en Python. Figure 5.8 Logo Python Python est un langage de programmation libre et orienté objet, qui est connu pour être lisible et facile à utiliser pour le développeur. Il est livré avec un débugger intégré, qui permet de travailler ecacement sur les bugs. C'est un langage interprété et non compilé, ce qui implique qu'il est beaucoup moins rapide que des langages compilés comme le C ou le C++ et un peu moins rapide que des langages semi-compilés comme Java. Python dispose d'une large communauté, ce qui permet d'avoir accès à un vaste choix de librairies, matures pour la plupart.[14] Les principales caractéristiques du langage Python : Portable : Il est supporté par les diérents systèmes d'exploitation. Python pos-s ède actuellement deux implémentations. L'une, interprétée, dans laquelle les pro-grammes Python sont compilés en instructions portables, puis exécutés par une
  70. 70. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 62 machine virtuelle (comme pour Java, avec une dié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 ; Orienté objet et supporte l'héritage multiple et la surcharge des opérateurs ; Simple : Il possède une syntaxe très simple tout en combinant des types de données évolués (listes, dictionnaires. . .) ; Dynamiquement typé ; Gère ses ressources (mémoire, descripteurs de chiers...) sans intervention du pro-grammeur, par un mécanisme de comptage de références ; Gratuit et soutenu par la communauté d'utilisateurs qui tentent à l'évoluer. 5.2.3 XML OpenERP utilise XML pour la description des données, la description des interfaces, la description des rapports et la description des workow. XML (eXtensible Markup Language et en Français Langage à balises étendu, ou Lan-gage à balises extensible) 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énit un nombre limité ; Il garantit à ses utilisateurs l'indépendance de leurs documents de toute technologie propriétaire ; Il unie le monde du traitement de document et celui du Web. 5.2.4 RML OpenERP utilise une extension du XML pour dénir les rapports : le RML . Les chiers RML décrivent la structure du document ainsi que les expressions et les champs à inclure. C'est un langage XML de style pour décrire la mise en page de documents. Il permet aussi de dénir et manipuler n'importe quel aspect d'un document, y compris le contenu et le style, en utilisant des balises dont la plupart des balises sont similaires à HTML. Le contenu d'un chier RML composé principalement par trois sections.
  71. 71. CHAPITRE 5. ÉTUDE TECHNIQUE ET RÉALISATION 63 Figure 5.9 Les sections d'un chier RML 5.2.5 Fichier PO Toutes les chaines de caractères qui doivent être traduites sont stockées dans des chiers .po qui contiennent des informations sur la langue, sur l'identité des traducteurs et les phrases originales et traduites. 5.3 Réalisation 5.3.1 Gestion des articles Figure 5.10 Intégration des méthodes Nous avons intégrer trois nouveaux méthodes, an d'aider le gestionnaire de stock pour mieux gérer les articles stockables. Les méthodes ajoutées sont :

×