Cours etude cas_erp_seance2

Etude de cas d’intégration d’un SI sous OpenERP

Décembre 2010 – ENSIAS - Mohamed BENYAHIA

Objectif du cours

• Comprendre les étapes d’intégration d’un SIsous un ERP

2

• Comprendre comment paramétrer, modifier,ajouter des fonctionnalités dans OpenERP

• Etudier le framework de développementd’OpenERP

Plan du cours

• Introduction à la démarche d’intégration d’un ERP

• Architecture d’OpenERP

3

• Prise en Main et paramétrage d’OpenERP

• Framework de développement : notions de base

• TP1:Développement d’un nouveau module

• Framework de développement : notions avancées

• TP2 : Enrichissement du module du TP1

Plan du cours

Introduction à la démarche d’intégration d’un ERP


4






Introduction démarche d’intégration d’un ERP

5

Elaboration du périmètre

Recueil des données

Choix de la solution ERPChoix de la solution ERP

Analyse de l’écart

Implémentation

Mise en production et maintenance

6

PartenairesProcessus opérationnels

Processus management

Objectifs Stratégie SMQ Mesures et améliorations

Introduction démarche d’intégration d’un ERP �Elaboration du périmètre

Clients

Partenaires

Fournisseurs Processus vente

Processus marketing Processus Facturation

& Recouvrement

Processus réalisation

Processus support

Processus Achat

Clients

Processus Gestion SI

ProcessusGestion matériel

ProcessusRH

Partenaires

Processus Finance


7



Choix de la solution ERP

Ateliers de travail

Consultation d’un registre de procédures



Implémentation


registre de procédures

Consultation de SI existant (écrans, …)

Référentiel de données


8




Identification des critères

Analyse qualitative, Choix de la solution ERP


Implémentation


Analyse qualitative, quantitative, multicritère

Choix de la solution


9




Comparaison entre les processus de

l’entreprise et leur éventuelle



Implémentation


éventuelle implémentation dans

la solution choisie

Rapport d’analyse


10

Paramétrage

Paramétrage + modification

Développement spécifique

Rapport d’analyse de l’écart

Res

sou

rces

+

cha

rge

de

tra

va

il


11





Implémentation


Le but de ce cour


12





Implémentation


Plan du cours


Architecture d’OpenERP

13







14

• OpenERP est basé sur une architectureclient/serveur

• Le langage de programmation d’openEPR est lelangage Python

� Introduction

langage Python

• OpenERP utilise des techniques issues de laProgrammation Orienté Objet

• OpenERP utilise PostgreSQL pour l’enregistrementde ces données


15

• OpenERP utilise un “Object Relational Mapping”(ORM) pour la persistence de ses objets métier

• OpenERP offre deux interfaces clients : GTK clientet Web client

� Introduction

et Web client

• OpenERP utilise ReportLab pour la génération desrapports en (PDF)

• OpenERP utilise XML pour : la description desdonnées, la description des interfaces, ladescription des rapports, et le transport desdonnées via XML-RPC


16

OpenERP Server OpenERP Client

Bus.Object

Bus. Object

Bus. Bus. Object User

WindowsTrees

Forms

� Client /Serveur

Bus. Object

Base Module

Object

ORM

Webservice

XML-RPCRPC

interfaceCore

User Interface

base

Postgres DB


17

� Client /Serveur

• La logique d’OpenERP est entièrement du côté serveur.

• Le client est très simple ‘client léger’; son travail consisteà demander des données (formulaires, listes, arbres) àpartir du serveur et de les renvoyer.partir du serveur et de les renvoyer.

• Avec cette approche tous les développements sontréalisés sur le côté serveur.


18

� Python

• Langage de programmation interprété

• Langage de programmation orienté objet

class nom_classe_fille(nom_classe_mere):attribut1 = ...

Attribut de classe...def __init__(self): # constructeur

self.nom = ‘Karim’ ….

def obj_method(self, params):…..

def classe_method(params):…..

non_classe_fille()

Constructeur +attribut de l’objet

Méthode d’objet

Méthode statique

Instanciation de l’objet


19

� XML/RPC

XML-RPC est un protocole RPC (Remote procedure call), unespécification simple et un ensemble de codes qui permettent à desprocessus s'exécutant dans des environnements différents de fairedes appels de méthodes à travers un réseau.

HTTP

Client

Code to

XML

XML to

CodeServeur

<sd:getBookPrice><isbn>0321146182</isbn>

</sd:getBookPrice>

<sd:getBookPriceResponse><result>24.99</result>

</sd:getBookPriceResponse>

HTTP

Requête Réponse

XML-RPC


20

� Object Relational Mapping (ORM)

ORMLes objets de l’application

save(params)Search(params)…..

InsertSelect

Tables relationnelles

…..

• Un mapping objet-relationnel est une technique de programmation quicrée l'illusion d'une base de données orientée objet à partir d'une base dedonnées relationnelle en définissant des correspondances entre cette base dedonnées et les objets du langage utilisé.

• C’est une correspondance entre monde objet et monde relationnel

• Cette couche (notamment dans OpenERP) permet de centraliser lesvérifications de la validité des données lors de la sauvegarde, les vérificationsdes droits d’accès, ….

Plan du cours



21

Prise en Main et paramétrage d’OpenERP





Plan du cours



22


Framework de développement : notions de base





23

� Structure modulaire

• OpenERP possède une structure modulaire qui permetd’ajouter de nouveau modules facilement pour étendreles fonctionnalités

• Lors de la première installation, on installe le noyaud’OpenERP + un certain nombres de modules dont led’OpenERP + un certain nombres de modules dont lemodule ‘base’ selon de profil d’installation choisit

• De nouveau modules peuvent être développé,moyennement une connaissance de Python, XML , et dela structure d’un module OpenERP

• Tous les modules sont localisé dans le répertoire ‘server/addons’


24

� Structure d’un module

Pour créer un nouveau modules, il suffit de suivre lesétapes suivantes:

▫ Créer un sous répertoire dans le répertoire ‘addons’

▫ Créer un fichier d’initialisation ‘__init__.py’▫ Créer un fichier d’initialisation ‘__init__.py’

▫ Créer un fichier de description ‘__terp__.py’

▫ Créer un fichier Python pour définir les objets métier

▫ Créer les fichiers XML pour définir les interfaces, lesdonnées de démonstration, et la description des menus

▫ Optionnellement on peut créer des rapports, des wizards oudes processus métiers


25

� fichier __init__.py

• Le fichier __init_.py est exécuté au lancement duserveur OpenERP, et est utilisé pour indiquer au serveurles fichiers python à charger

• Si vous créer un fichier ‘module.py’ qui contient la• Si vous créer un fichier ‘module.py’ qui contient ladescription de vos objets, vous devez alors écrire dans cefichier la ligne suivante :

▫ import module


26

� fichier __terp__.py

• __terp__.py est le fichier de description du module il estcomposé des éléments suivants :

▫ name � le nom du module

▫ version � la version du module▫ version � la version du module

▫ description � la description du module

▫ author � l’auteur du module

▫ website� website du module

▫ license � license du module (default:GPL-2)

▫ depends � la liste des modules dont dépend le module

▫ update_xml � fichiers à charger à la mise à jour du module

▫ Active � true ou false (installable à la création de la base)


27

� définition des objets

• Tous les ressources d’OpenERP sont des objets (menus, rapport, factures, partenaires, …)

• OpenERP contrôle les données de ces objets à travers un ORM

• Le nom des objects est par convention hiérachique

class account_invoice( ):class account_invoice_line():class account_transfer():

Nom du module Nom de l’objet


28


• Pour définir un nouveau objet il suffit de définir une nouvelle classepython et de l’instancier. La classe doit hériter de la classe osv setrouvant dans le module osv

• Un objet est défini à travers la déclaration de certains attributstatique prédéfini, dont deux sont obligatoires :_name, et _columns

Description python statique

Instanciation de l’objet

class name_of_the_object(osv.osv):_name = ’name.of.the.object’_columns = { ... }_inherit=_constraints =_sql_constraints=_order=...

name_of_the_object()

Héritage de l’objet osv


29


• _name = nom de l’objet

• _columns = les attributs de l’objets

• _inherit = le nom de l’objet dont hérite l’objet en cours

• _constraints = les contraintes de l’objet• _constraints = les contraintes de l’objet

• _sql_constraints = sql contraintes sur l’objet

• _order = le nom des attributs de l’objet utilisé pour ordonner les résultats derecherche

• _defauts = valeurs par défaut des attributs de l’objet

• _sql = code sql éxécuté lors de la création de l’objet

• _table = nom de la table sql, la valeur par défaut étant la valeur de ‘_name’ oùles points ‘.’ remplacé par un underscor ‘_’


30

� définition des attributs de l’objet

• Les objets peuvent contenir trois catégories d’attributsqui sont défini dans le champs _columns:

▫ Les types simples : Entiers, Booléen, String, …▫ Les types simples : Entiers, Booléen, String, …

▫ Les relations : permettent de définir des relations entreobjets (one2many, many2one,…)

▫ Les fonctions : permettent de définir des attributs qui nesont pas persisté dans la base de données mais calculés aumoment de leur appel


31

� définition des attributs de l’objet : les types simples

• Booléen : fields.boolean(’Field Name’ [, Optional Parameters]),

▫ Ex: ‘received’ = fields.boolean('Received', readonly=True, select=True),

• Integer : fields.integer(’Field Name’ [, Optional Parameters]),

▫ Ex: ‘numero': fields.integer('N° de l\'entrée'),

• Float: fields.float(’Field Name’ [, Optional Parameters]),

▫ Ex: 'debit': fields.float('Débit', digits=(16,2)),

• Char : fields.char(’Field Name’, size=n [, Optional Parameters]),

▫ Ex: 'libelle': fields.char('Libellé de l\'opération', size=200),

• Text : fields.text(’Field Name’ [, Optional Parameters]),


32

� définition des attributs de l’objet : les types simples

• Date : fields.date(’Field Name’ [, Optional Parameters]),

▫ Ex: 'date_operation': fields.date('Date opération'),

• Datetime : fields.datetime(’Field Name’ [, Optional Parameters]),

▫ Ex: 'date_planned': fields.datetime('Scheduled date', required=True),

• Selection: fields.selection(((’key_or_value’, ’string_to_display’),

... ), ’Field Name’ [, Optional Parameters]),

▫ Ex: 'invoice_method': fields.selection([('manual','Manual'),('order','FromOrder'),('picking','From Picking')], 'Invoicing Control', required=True,help="From Order: a draft invoice will be pre-generated…..." ),


33

� définition des attributs de l’objet : les types ‘Relations’

• many2one : permet de mettre en relation l’objet en cours avecun objet parent

▫ Syntaxe : fields.many2one(’other.object.name’, ’Field Name’, optionalparameter)

▫ Ex: 'location_id': fields.many2one('stock.location', 'Destination',▫ Ex: 'location_id': fields.many2one('stock.location', 'Destination',required=True),

• one2many : permet de mettre en relation l’objet en cours avecses objets dérivés

▫ Syntaxe : fields.one2many(’other.object.name’, ’Field relation id’,’Fieldname’, optional parameter)

▫ Ex: ‘address’: fields.one2many(‘res.partner.address’, ‘partner_id’,‘Contacts’),


34

� définition des attributs de l’objet : les types ‘Relations’

• many2many: permet de définir une relation plusieurs à plusieurs

entre l’objet en cours et un autre objet

▫ Syntaxe : fields.many2many(’other.object.name’, ’relation object’,’other.object.id’, ’actual.object.id’, ’Field Name’)’other.object.id’, ’actual.object.id’, ’Field Name’)

� ‘other.object.name’ est l’autre objet de la relation

� ‘relation object’ est la table qui fait le lien

� ‘other.object.id’ et ‘actual.object.id’ sont les noms des champs utilisés dansla table de relation

▫ Ex: ’category_id’: fields.many2many( ’res.partner.category’,’res_partner_category_rel’, ’partner_id’, ’category_id’, ’Categories’),


35

� définition des attributs de l’objet : les types ‘fonctions’

• Un champ de type fonction est un champ qui est calculépar une fonction ( à l’opposition d’un champ récupéré dela base de données)

▫ Syntaxe : fields.function(fnct [, Parameters]),▫ Syntaxe : fields.function(fnct [, Parameters]),

• Les paramètres principales sont :

▫ fnct : le nom de la fonction qui calcule la valeur du champ

▫ type : est le type de retour de la fonction

▫ store: indique si on veut enregistrer le champ dans la base de données

▫ method: indique si le champ est calculé par une méthode d’objet ou uneméthode statique de classe

▫ fnct_inv : le nom de la fonction qui permet d’écrire la valeur du champdans la base au cas où store=true


36


La signature de la méthode qui calcule la valeur du champ est :

• Si le paramètre ‘Method’=true

▫ def fnct(self, cr, uid, ids, field_name, arg, context)

• Si le paramètre ‘Method’=false

▫ def fnct(cr, table, ids, field_name, arg, context)▫ def fnct(cr, table, ids, field_name, arg, context)

La signature de la méthode qui enregistre la valeur du champ dans labase de données est :

• Si le paramètre ‘Method’=true

▫ def fnct(self, cr, uid, ids, field_name, field_value, arg, context)

• Si le paramètre ‘Method’=false▫ def fnct(cr, table, ids, field_name, field_value, arg, context)


37


Exemple :

'minimum_planned_date':fields.function(_minimum_planned_date, fnct_inv=_set_minimum_planned_date,method=True,store=True, string='Planned Date',type='datetime', help="This is computed as thetype='datetime', help="This is computed as theminimum scheduled date of all purchase order lines'products."),


38

� les méthodes d’ORM

• Create: permet de créer une nouvelle ressource, etretourner son identifiant

Signature : def create(cr, uid, vals, context={}),▫ Où: vals est un dictionnaire {nom_du_champ:valeur}▫ Où: vals est un dictionnaire {nom_du_champ:valeur}

▫ Cette fonction retourne l’identifiant de la ressource qu’on vient de créer

create(cr, uid,{’name’: ’Email sent through mass mailing’,’partner_id’: partner.id,’description’: ’The Description for Partner Event’})


39


read: permet de lire les valeurs des attributs d’une ressource des identifiant passés en paramètres

Signature : def read(self, cr, uid, ids, fields=None, context={})Signature : def read(self, cr, uid, ids, fields=None, context={})

▫ Où : ids est la liste des identifiants à lire

▫ fields la liste des champs à lire

▫ Cette fonction retourne un tableau sous la forme [{‘name_of_the_field’: value, ...}, ...]

read(cr, uid, ids, [’name’,’category_id’], context=context)


40


search: permet de chercher des ressources selon des critères passés en paramètres

Signature: def search(self, cr, uid, args, offset=0, limit=2000,

order=None, context=None, count=False)

▫ Où : args est une liste de critères de recherche sous la forme[(‘name_of_the_field’, ‘operator’, value),

▫ Les opérateurs possibles sont

� =, >, <, <=, >=

� IN

� LIKE, ILIKE

� child_of

▫ Cette fonction retourne la liste des identifiants des ressources correspondants aux critères

search(cr, uid, [(’category_id’, ’=’, ’Customer’)])


41


browse: permet de récupérer les ressources à travers leurs identifiants

Signature: def browse(self, cr, uid, select, offset=0, limit=2000)

▫ Où : select est soit :

� Entier représentant l’identifiant de la ressource

� Liste d’entier représentant la liste des ressources

▫ Cette fonction retourne l’objet ou la liste des objets correspondants aux identifiants passé en paramètre

browse(cr, uid, contact_id)


42


write: permet de modifier les valeurs des champs d’une ressource

Signature : def write(self, cr, uid, ids, vals, context={})

▫ Où : ids est la liste des identifiants d’objet à modifier

▫ Vals: un tableau des champs à modifier et leurs valeurs sous la forme

� {‘name_of_the_field’: value, ...}

▫ Cette fonction retourne true si l’opération est réussi

write(cr, uid, ids, {’state’:’cancel’})


43

� les vues

• Deux types de vues sont les plus utilisés dans OpenERP:

▫ Les formulaires

▫ Les listes▫ Les listes


44

� les vues : les formulaires

• Chaque champ est précédé par un libellé

• les champs sont placé de gauche à droite et de haut en bas, dans l’ordre de bas, dans l’ordre de leur définition dans la vue

• Chaque page est divisé en 4 colonnes


45


• Une page de formulaire peut contenir une zone avec plusieurs colonnes qui correspond à un champ ‘one2many’ (exemple la zone encadré en bleu)

• On peut aussi découper un groupe de colonnes en un nombre de sous colonnes comme indiqué dans la zone encadrée en vert


46


• On peut aussi diviser la pages en plusieurs onglets comme indiqué ci-dessus dans la zone encadré en bleu


47

� les vues : les listes

• Les listes sont utilisé pour visualiser les données de plusieurs ressources en même temps

• Les vues listes sont plus simples que les formulaires et ont moins d’options


48

� les vues : mise en œuvre

• les vues sont définis dans des fichiers XML possédant la structure suivante

<?xml version="1.0"?><openerp>

<data>[view definitions]

</data></openerp>

• Il existe principalement trois tags pour la définition des vues dans OpenERP :

▫ Les tags <record> avec l’attribut model=”ir.ui.view”, qui contiennent la définition des vues

▫ Les tags <record> avec l’attribut model=”ir.actions.act_window”, qui fait une correspondance entre les actions et les vues

▫ Les tags <menuitem> qui permettent de créer des menus, et sous-menu et les fait correspondre à des actions

</openerp>


49


• Les tags <record> avec l’attribut model=”ir.ui.view”, va contenir plusieurs sous-tag de type <field> pour définir la vue

Une vue de type formulaire <record model="ir.ui.view" id="view_nom_form">

<field name="name">nom.du.formulaire</field> <field name="name">nom.du.formulaire</field> <field name="model">nom.objet.metier </field> <field name="type">form </field>

<field name="arch" type="xml"> <form string=‘libellé du formulaire’>

<field name="name" select="1"/><field name="periode" select="1" required="True" />…..

</form></field>

</record>

Formulaire


50


• Les tags <record> avec l’attribut model=”ir.ui.view”, va contenir plusieurs sous-tag de type <field> pour définir la vue

Une vue de type liste <record model="ir.ui.view" id="view_nom_tree">

<field name="name">nom.du.formulaire</field> <field name="name">nom.du.formulaire</field> <field name="model">nom.objet.metier </field> <field name="type">tree </field>

<field name="arch" type="xml"> <form string=‘libellé du formulaire’>

<field name="name"/><field name="periode" />…..

</form></field>

</record>

Liste


51


Les attributs du tag <field>:• select : utilisable ou non en recherche

• readonly : oui ou non

• required: oui ou non

• nolabel : un champ avec un libellé ou non • nolabel : un champ avec un libellé ou non

• invisible : un champ et libellé invisible

• domain: restreint les ressources selon un critère par exemple: domain="[('code','=', 'cash')]"

• on_change: définie une fonction qui est appellé quand la valeur du champ en cours change

• attrs: définit les valeurs de certain attributs du champ en cours en fonction d’autre champs, par Ex; attrs="{'readonly':[('periode','=','')]}"


52

� les vues : les tags de groupement dans un formulaire

• <notebook> : permettent de séparer une page de formulaire en

plusieurs onglets

▫ <notebook colspan="4">....</notebook>

• <group> permet de regrouper des colonnes et les diviser ensuite enplusieurs colonnesplusieurs colonnes

Les attributs sont :

▫ Colspan, le nombre de colonnes à utiliser

▫ Col, le nombre de colonne à diviser

▫ String : ajoute un encadré avec le libellé fourni par cet attribut

Exemple: <group col="3" colspan="2"> ….</group>

• <separator> ajoute une ligne de séparation

▫ <separator string="Links" colspan="4"/>


53

� les vues : les actions et menus

Après définition des formulaires et des listes on définit les actions etles menus comme suit

<record model="ir.actions.act_window" id="action_nom"> <field name="name">nom de l’action</field> <field name="name">nom de l’action</field> <field name="res_model">nom.objet</field> <field name="view_type">form</field> <field name="view_mode">form,tree</field>

</record>

<menuitem parent="menu_parent" id="menu_nom" action="action_nom"/>

Plan du cours



54



TP1:Développement d’un nouveau module




55

� Cahier de charge

Notre client est un établissement hôtelier qui désire avoir une solutionunique pour sa gestion interne :

• Comptabilité générale, Comptabilité analytique, Gestion des achats,Gestion des stocks, Gestion des ressources humaines

• Gestion Hôtelière:

▫ Gestion des chambres d’hôtel

▫ Gestion des réservations

▫ Gestion des équipements

▫ …….


56


• Après étude des besoins de votre client (fonctionnalités,nombre d’utilisateur, budget, …) vous proposer à votreclient d’implémenter son système d’information sousOpenERP

• Après recueil des données et analyse de l’écart, vous vous• Après recueil des données et analyse de l’écart, vous vousapercevez que la plus part des fonctionnalitésdemandées à part la gestion de l’hôtel est implémentablemoyennement un paramétrage ou des ajustementmineurs

• Vous décider alors de développez votre nouveau moduleOpenERP de gestion hôteliere


57


Le module de gestion Hôteliere devra comporter lesfonctionnalités suivantes:

• L’administration des données des chambres de l’hôtel

• La gestion des équipements des chambres

• La gestion des réservations

• ……


58

� L’administration des données des chambres d’hôtel

Dans la partie d’administration des données des chambres d’hôtel, on doitpouvoir:

• Ajouter une nouvelle chambre et renseigner ces informations

▫ Numéro de la chambre � chaine de 64 caractères, obligatoire▫ Statut � sélection (Disponible, Réservée, En maintenance)▫ Statut � sélection (Disponible, Réservée, En maintenance)▫ Nombre de pièces � Entier▫ Date d’inscription � date▫ Etage � sélection (Premier, Deuxième, Troisième, Quatrième)▫ Vue� sélection (Intérieure, Extérieure)

• Consulter la liste des chambres

• Modifier les informations d’une chambre

• Effectuer une recherche multicritères


59


• Créer un répertoire hotel sous ‘server/addons’

• Dans ce répertoire créer les fichiers suivants :

▫ __init__.py � pour le chargement du module

▫ __terp__.py � pour décrire votre module

▫ hotel.py � pour définir vos objets métiers

▫ hotel_view.py � pour définir les interfaces desformulaires et des listes


60

Correction


Correction


61

� L’administration des données des équipements

Chaque chambre d’hôtel contient un nombre d’équipement, le client veutrépertorier tous les équipements d’une chambre, pour cela on doit créer unmenu pour la gestion des équipements pour :

• Ajouter un nouveau équipement et l’affecter à une chambre avec lescaractéristiques suivantes :

▫ Code � chaine de 10 caractères, obligatoire▫ Code � chaine de 10 caractères, obligatoire▫ Statut � sélection (Bon état, Nouveau, A remplacer)▫ Catégorie� chaine de 64 caractères, obligatoire▫ Date de mise en service � date▫ libelle � chaine de 64 caractères, obligatoire▫ Id_chambre� référence vers la chambre où se trouve l’équipement

• Consulter la liste des équipements

• Modifier les informations d’un équipement

• Effectuer une recherche multicritères


62


CorrectionCorrection


63


Le client désire classifier les équipements selon des catégories:

Ajouter un objet nature possédant les propriétés suivantes:

▫ Code : chaine de 10 caractères, obligatoire

▫ Libelle : chaine de 64 caractères, obligatoire

▫ Equipements : liste des équipements appartenant à la catégorie

Les fonctionnalités demandées sont l’ajout, la modification, lasurpression, la liste, la recherche


64




65


Le client voudrait ajouter la règle de gestion suivante:

▫ Ajouter un attribut ‘date d’entrée en service’

▫ Ajouter un attribut ‘date de remplacement’

▫ Quand le statut du dossier est ‘A remplacer’ , le systèmedoit rendre le champ ‘date de remplacement ’ obligatoire


66




67

� L’administration des données des réservations

Pour gérer les réservations on doit créer un objetréservation possédant les attribut suivants :

▫ Numéro de la réservation � entier

▫ Date de début � date▫ Date de début � date

▫ Date de fin � date

▫ Nombre de jours � entier

▫ Nom � chaine de 64 caractères

▫ Prénom � chaine de 64 caractères

▫ Téléphone � chaine de 64 caractères

▫ CIN � chaine de 10 caractères

▫ Référence de la chambre


68

Correction


Correction


69


Le client exige d’ajouter la règle de gestion suivante àl’objet reservation :

• La date de fin > date de début


70




71


Le client voudrait ajouter la règle de gestion suivante àl’objet reservation :

• La date de fin doit se calculer automatiquement enfonction de la date de début + nombre de jourfonction de la date de début + nombre de jour

• La date de fin doit être affiché juste après la saisie de ladate de début et du nombre du jours


72

Correction


Correction

Cours etude cas_erp_seance2

Documents

Transcript of Cours etude cas_erp_seance2