Cours etude cas_erp_seance2

3 177 vues

Publié le

2 commentaires
4 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
3 177
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
272
Commentaires
2
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Cours etude cas_erp_seance2

  1. 1. Etude de cas d’intégration d’un SI sous OpenERPDécembre 2010 – ENSIAS - Mohamed BENYAHIA
  2. 2. 2Objectif 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. 3Plan 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. 4Plan du coursIntroduction à 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. 5Introduction 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. 6Introduction 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. 7Introduction 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. 8Introduction 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. 9Introduction 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. 10Introduction démarche d’intégration d’un ERP ParamétrageRapportd’analyse Paramétrage +de l’écart modification charge de travail Ressources + Développement spécifique
  11. 11. 11Introduction 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. 12Introduction 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. 13Plan du cours• Introduction à la démarche d’intégration d’un ERPArchitecture 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. 14Architecture 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. 15Architecture 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. 16Architecture 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. 17Architecture 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. 18Architecture 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. 19Architecture 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 sexé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. 20Architecture 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 lillusion dune base de données orientée objet à partir dune 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. 21Plan du cours• Introduction à la démarche d’intégration d’un ERP• Architecture d’OpenERPPrise 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. 22Plan du cours• Introduction à la démarche d’intégration d’un ERP• Architecture d’OpenERP• Prise en Main et paramétrage d’OpenERPFramework 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. 23Framework 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. 24Framework 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. 25Framework 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. 26Framework 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. 27Framework 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. 28Framework 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. 29Framework 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. 30Framework 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. 31Framework 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 lentré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 lopération, size=200), • Text : fields.text(’Field Name’ [, Optional Parameters]),
  32. 32. 32Framework 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. 33Framework 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. 34Framework 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. 35Framework 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. 36Framework 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. 37Framework 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. 38Framework 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. 39Framework 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. 40Framework 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. 41Framework 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. 42Framework 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. 43Framework 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. 44Framework 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. 45Framework 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. 46Framework 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. 47Framework 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. 48Framework 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. 49Framework 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. 50Framework 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. 51Framework 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. 52Framework 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. 53Framework 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. 54Plan 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 baseTP1:Développement d’un nouveau module• Framework de développement : notions avancées• TP2 : Enrichissement du module du TP1
  55. 55. 55TP1: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. 56TP1: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. 57TP1: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. 58TP1: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. 59TP1: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
  60. 60. 60TP1:Développement d’un nouveau module L’administration des données des chambres d’hôtel Correction
  61. 61. 61TP1: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
  62. 62. 62TP1:Développement d’un nouveau module L’administration des données des équipements Correction
  63. 63. 63TP1: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
  64. 64. 64TP1:Développement d’un nouveau module L’administration des données des équipements Correction
  65. 65. 65TP1: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
  66. 66. 66TP1:Développement d’un nouveau module L’administration des données des équipements Correction
  67. 67. 67TP1: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
  68. 68. 68TP1:Développement d’un nouveau module L’administration des données des réservations Correction
  69. 69. 69TP1: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
  70. 70. 70TP1:Développement d’un nouveau module L’administration des données des équipements Correction
  71. 71. 71TP1: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
  72. 72. 72TP1:Développement d’un nouveau module L’administration des données des réservations Correction

×