UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
Cours etude cas_erp_seance2
1. Etude de cas d’intégration
d’un SI sous OpenERP
Décembre 2010 – ENSIAS - Mohamed BENYAHIA
2. 2
Objectif du cours
• Comprendre les étapes d’intégration d’un SI
sous un ERP
• Comprendre comment paramétrer, modifier,
ajouter des fonctionnalités dans OpenERP
• Etudier le framework de développement
d’OpenERP
3. 3
Plan du cours
• Introduction à la démarche d’intégration d’un ERP
• Architecture d’OpenERP
• 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
4. 4
Plan du cours
Introduction à la démarche d’intégration d’un ERP
• Architecture d’OpenERP
• 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
5. 5
Introduction démarche d’intégration d’un ERP
Elaboration du périmètre
Recueil des données
Choix de la solution ERP
Analyse de l’écart
Implémentation
Mise en production et maintenance
6. 6
Introduction démarche d’intégration d’un ERP
Elaboration du périmètre
Processus management
Objectifs Stratégie SMQ Mesures et améliorations
Processus opérationnels
Partenaires
Clients
Processus marketing Processus
Processus Facturation
Clients
réalisation & Recouvrement
Partenaires
Fournisseurs Processus vente
Processus support
Processus Processus Processus Processus
Processus
RH Finance Gestion Gestion SI
Achat
matériel
7. 7
Introduction démarche d’intégration d’un ERP
Elaboration du périmètre
Ateliers de travail
Recueil des données
Consultation d’un
registre de procédures
Choix de la solution ERP
Consultation de SI
existant (écrans, …)
Analyse de l’écart
Implémentation
Référentiel de
Mise en production et maintenance données
8. 8
Introduction démarche d’intégration d’un ERP
Elaboration du périmètre
Identification des
Recueil des données critères
Analyse qualitative,
Choix de la solution ERP
quantitative,
multicritère
Analyse de l’écart
Implémentation
Choix de la solution
Mise en production et maintenance
9. 9
Introduction démarche d’intégration d’un ERP
Elaboration du périmètre
Comparaison entre les
Recueil des données processus de
l’entreprise et leur
éventuelle
Choix de la solution ERP
implémentation dans
la solution choisie
Analyse de l’écart
Implémentation
Rapport d’analyse
Mise en production et maintenance
10. 10
Introduction démarche d’intégration d’un ERP
Paramétrage
Rapport
d’analyse Paramétrage +
de l’écart modification
charge de travail
Ressources +
Développement
spécifique
11. 11
Introduction démarche d’intégration d’un ERP
Elaboration du périmètre
Recueil des données
Choix de la solution ERP
Analyse de l’écart
Implémentation Le but de ce cour
Mise en production et maintenance
12. 12
Introduction démarche d’intégration d’un ERP
Elaboration du périmètre
Recueil des données
Choix de la solution ERP
Analyse de l’écart
Implémentation
Mise en production et maintenance
13. 13
Plan du cours
• Introduction à la démarche d’intégration d’un ERP
Architecture d’OpenERP
• 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
14. 14
Architecture d’OpenERP
Introduction
• OpenERP est basé sur une architecture
client/serveur
• Le langage de programmation d’openEPR est le
langage Python
• OpenERP utilise des techniques issues de la
Programmation Orienté Objet
• OpenERP utilise PostgreSQL pour l’enregistrement
de ces données
15. 15
Architecture d’OpenERP
Introduction
• OpenERP utilise un “Object Relational Mapping”
(ORM) pour la persistence de ses objets métier
• OpenERP offre deux interfaces clients : GTK client
et Web client
• OpenERP utilise ReportLab pour la génération des
rapports en (PDF)
• OpenERP utilise XML pour : la description des
données, la description des interfaces, la
description des rapports, et le transport des
données via XML-RPC
16. 16
Architecture d’OpenERP
Client /Serveur
OpenERP Server OpenERP Client
Bus. Bus. Forms
Object Object
Trees Windows
Bus. Bus.
Object Object User
Interface
XML-RPC
RPC base
Base Module Webservice Core
interface
ORM
Postgres DB
17. 17
Architecture d’OpenERP
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.
• Avec cette approche tous les développements sont
réalisés sur le côté serveur.
18. 18
Architecture d’OpenERP
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 Constructeur
self.nom = ‘Karim’ +attribut de l’objet
….
def obj_method(self, params): Méthode d’objet
…..
def classe_method(params):
….. Méthode statique
non_classe_fille() Instanciation de l’objet
19. 19
Architecture d’OpenERP
XML/RPC
XML-RPC est un protocole RPC (Remote procedure call), une
spécification simple et un ensemble de codes qui permettent à des
processus s'exécutant dans des environnements différents de faire
des appels de méthodes à travers un réseau.
HTTP XML
Code
Client to to Serveur
XML Code
XML-RPC
Requête Réponse
<sd:getBookPrice> <sd:getBookPriceResponse>
<isbn>0321146182</isbn> <result>24.99</result>
</sd:getBookPrice> </sd:getBookPriceResponse>
20. 20
Architecture d’OpenERP
Object Relational Mapping (ORM)
Les objets de Tables
ORM relationnelles
l’application
save(params) Insert
Search(params) Select
…..
• Un mapping objet-relationnel est une technique de programmation qui
crée l'illusion d'une base de données orientée objet à partir d'une base de
données relationnelle en définissant des correspondances entre cette base de
donné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 les
vérifications de la validité des données lors de la sauvegarde, les vérifications
des droits d’accès, ….
21. 21
Plan du cours
• Introduction à la démarche d’intégration d’un ERP
• Architecture d’OpenERP
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
22. 22
Plan du cours
• Introduction à la démarche d’intégration d’un ERP
• Architecture d’OpenERP
• 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
23. 23
Framework de développement : notions de base
Structure modulaire
• OpenERP possède une structure modulaire qui permet
d’ajouter de nouveau modules facilement pour étendre
les fonctionnalités
• Lors de la première installation, on installe le noyau
d’OpenERP + un certain nombres de modules dont le
module ‘base’ selon de profil d’installation choisit
• De nouveau modules peuvent être développé,
moyennement une connaissance de Python, XML , et de
la structure d’un module OpenERP
• Tous les modules sont localisé dans le répertoire
‘server/addons’
24. 24
Framework de développement : notions de base
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 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, les
données de démonstration, et la description des menus
▫ Optionnellement on peut créer des rapports, des wizards ou
des processus métiers
25. 25
Framework de développement : notions de base
fichier __init__.py
• Le fichier __init_.py est exécuté au lancement du
serveur OpenERP, et est utilisé pour indiquer au serveur
les fichiers python à charger
• Si vous créer un fichier ‘module.py’ qui contient la
description de vos objets, vous devez alors écrire dans ce
fichier la ligne suivante :
▫ import module
26. 26
Framework de développement : notions de base
fichier __terp__.py
• __terp__.py est le fichier de description du module il est
composé des éléments suivants :
▫ name le nom 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. 27
Framework de développement : notions de base
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
Nom du module Nom de l’objet
class account_invoice( ):
class account_invoice_line():
class account_transfer():
28. 28
Framework de développement : notions de base
définition des objets
• Pour définir un nouveau objet il suffit de définir une nouvelle classe
python et de l’instancier. La classe doit hériter de la classe osv se
trouvant dans le module osv
• Un objet est défini à travers la déclaration de certains attribut
statique prédéfini, dont deux sont obligatoires :_name, et _columns
class name_of_the_object(osv.osv): Héritage de l’objet
_name = ’name.of.the.object’ osv
_columns = { ... }
_inherit=
Description python
_constraints = statique
_sql_constraints=
_order=
...
name_of_the_object() Instanciation de
l’objet
29. 29
Framework de développement : notions de base
définition des objets
• _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
• _sql_constraints = sql contraintes sur l’objet
• _order = le nom des attributs de l’objet utilisé pour ordonner les résultats de
recherche
• _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. 30
Framework de développement : notions de base
définition des attributs de l’objet
• Les objets peuvent contenir trois catégories d’attributs
qui sont défini dans le champs _columns:
▫ Les types simples : Entiers, Booléen, String, …
▫ Les relations : permettent de définir des relations entre
objets (one2many, many2one,…)
▫ Les fonctions : permettent de définir des attributs qui ne
sont pas persisté dans la base de données mais calculés au
moment de leur appel
31. 31
Framework de développement : notions de base
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. 32
Framework de développement : notions de base
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','From
Order'),('picking','From Picking')], 'Invoicing Control', required=True,
help="From Order: a draft invoice will be pre-generated…..." ),
33. 33
Framework de développement : notions de base
définition des attributs de l’objet : les types ‘Relations’
• many2one : permet de mettre en relation l’objet en cours avec
un objet parent
▫ Syntaxe : fields.many2one(’other.object.name’, ’Field Name’, optional
parameter)
▫ Ex: 'location_id': fields.many2one('stock.location', 'Destination',
required=True),
• one2many : permet de mettre en relation l’objet en cours avec
ses 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. 34
Framework de développement : notions de base
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.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 dans
la table de relation
▫ Ex: ’category_id’: fields.many2many( ’res.partner.category’,
’res_partner_category_rel’, ’partner_id’, ’category_id’, ’Categories’),
35. 35
Framework de développement : notions de base
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é de
la base de données)
▫ 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 une
méthode statique de classe
▫ fnct_inv : le nom de la fonction qui permet d’écrire la valeur du champ
dans la base au cas où store=true
36. 36
Framework de développement : notions de base
définition des attributs de l’objet : les types ‘fonctions’
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)
La signature de la méthode qui enregistre la valeur du champ dans la
base 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. 37
Framework de développement : notions de base
définition des attributs de l’objet : les types ‘fonctions’
Exemple :
'minimum_planned_date':fields.function(_minimum_pla
nned_date, fnct_inv=_set_minimum_planned_date,
method=True,store=True, string='Planned Date',
type='datetime', help="This is computed as the
minimum scheduled date of all purchase order lines'
products."),
38. 38
Framework de développement : notions de base
les méthodes d’ORM
• Create: permet de créer une nouvelle ressource, et
retourner son identifiant
Signature : def create(cr, uid, vals, context={}),
▫ 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. 39
Framework de développement : notions de base
les méthodes d’ORM
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={})
▫ 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. 40
Framework de développement : notions de base
les méthodes d’ORM
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. 41
Framework de développement : notions de base
les méthodes d’ORM
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. 42
Framework de développement : notions de base
les méthodes d’ORM
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. 43
Framework de développement : notions de base
les vues
• Deux types de vues sont les plus utilisés dans OpenERP:
▫ Les formulaires
▫ Les listes
44. 44
Framework de développement : notions de base
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
leur définition dans
la vue
• Chaque page est
divisé en 4 colonnes
45. 45
Framework de développement : notions de base
les vues : les formulaires
• 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. 46
Framework de développement : notions de base
les vues : les formulaires
• On peut aussi diviser la pages en plusieurs onglets comme indiqué ci-dessus
dans la zone encadré en bleu
47. 47
Framework de développement : notions de base
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. 48
Framework de développement : notions de base
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
49. 49
Framework de développement : notions de base
les vues : mise en œuvre
• 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="model">nom.objet.metier </field>
<field name="type">form </field> Formulaire
<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>
50. 50
Framework de développement : notions de base
les vues : mise en œuvre
• 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="model">nom.objet.metier </field>
<field name="type">tree </field> Liste
<field name="arch" type="xml">
<form string=‘libellé du formulaire’>
<field name="name"/>
<field name="periode" />
…..
</form>
</field>
</record>
51. 51
Framework de développement : notions de base
les vues : mise en œuvre
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
• 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. 52
Framework de développement : notions de base
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 en
plusieurs 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. 53
Framework de développement : notions de base
les vues : les actions et menus
Après définition des formulaires et des listes on définit les actions et
les menus comme suit
<record model="ir.actions.act_window" id="action_nom">
<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"/>
54. 54
Plan du cours
• Introduction à la démarche d’intégration d’un ERP
• Architecture d’OpenERP
• 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
55. 55
TP1:Développement d’un nouveau module
Cahier de charge
Notre client est un établissement hôtelier qui désire avoir une solution
unique 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. 56
TP1:Développement d’un nouveau module
Cahier de charge
• Après étude des besoins de votre client (fonctionnalités,
nombre d’utilisateur, budget, …) vous proposer à votre
client d’implémenter son système d’information sous
OpenERP
• Après recueil des données et analyse de l’écart, vous vous
apercevez que la plus part des fonctionnalités
demandées à part la gestion de l’hôtel est implémentable
moyennement un paramétrage ou des ajustement
mineurs
• Vous décider alors de développez votre nouveau module
OpenERP de gestion hôteliere
57. 57
TP1:Développement d’un nouveau module
Cahier de charge
Le module de gestion Hôteliere devra comporter les
fonctionnalité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. 58
TP1:Développement d’un nouveau module
L’administration des données des chambres d’hôtel
Dans la partie d’administration des données des chambres d’hôtel, on doit
pouvoir:
• 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)
▫ 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. 59
TP1:Développement d’un nouveau module
L’administration des données des chambres d’hôtel
• 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 des
formulaires et des listes
61. 61
TP1:Développement d’un nouveau module
L’administration des données des équipements
Chaque chambre d’hôtel contient un nombre d’équipement, le client veut
répertorier tous les équipements d’une chambre, pour cela on doit créer un
menu pour la gestion des équipements pour :
• Ajouter un nouveau équipement et l’affecter à une chambre avec les
caractéristiques suivantes :
▫ 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
63. 63
TP1:Développement d’un nouveau module
L’administration des données des équipements
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, la
surpression, la liste, la recherche
65. 65
TP1:Développement d’un nouveau module
L’administration des données des équipements
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ème
doit rendre le champ ‘date de remplacement ’ obligatoire
67. 67
TP1:Développement d’un nouveau module
L’administration des données des réservations
Pour gérer les réservations on doit créer un objet
réservation possédant les attribut suivants :
▫ Numéro de la réservation entier
▫ 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
69. 69
TP1:Développement d’un nouveau module
L’administration des données des réservations
Le client exige d’ajouter la règle de gestion suivante à
l’objet reservation :
• La date de fin > date de début
71. 71
TP1:Développement d’un nouveau module
L’administration des données des réservations
Le client voudrait ajouter la règle de gestion suivante à
l’objet reservation :
• La date de fin doit se calculer automatiquement en
fonction de la date de début + nombre de jour
• La date de fin doit être affiché juste après la saisie de la
date de début et du nombre du jours