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 SI
sous un ERP
2
• Comprendre comment paramétrer, modifier,
a...
Plan du cours
• Introduction à la démarche d’intégration d’un ERP
• Architecture d’OpenERP
3
• Prise en Main et paramétrag...
Plan du cours
Introduction à la démarche d’intégration d’un ERP
• Architecture d’OpenERP
4
• Prise en Main et paramétrage ...
Introduction démarche d’intégration d’un ERP
5
Elaboration du périmètre
Recueil des données
Choix de la solution ERPChoix ...
6
Partenaires
Processus opérationnels
Processus management
Objectifs Stratégie SMQ Mesures et améliorations
Introduction d...
Introduction démarche d’intégration d’un ERP
7
Elaboration du périmètre
Recueil des données
Choix de la solution ERP
Ateli...
Introduction démarche d’intégration d’un ERP
8
Elaboration du périmètre
Recueil des données
Choix de la solution ERP
Ident...
Introduction démarche d’intégration d’un ERP
9
Elaboration du périmètre
Recueil des données
Choix de la solution ERP
Compa...
Introduction démarche d’intégration d’un ERP
10
Paramétrage
Paramétrage +
modification
Développement
spécifique
Rapport
d’...
Introduction démarche d’intégration d’un ERP
11
Elaboration du périmètre
Recueil des données
Choix de la solution ERPChoix...
Introduction démarche d’intégration d’un ERP
12
Elaboration du périmètre
Recueil des données
Choix de la solution ERPChoix...
Plan du cours
• Introduction à la démarche d’intégration d’un ERP
Architecture d’OpenERP
13
• Prise en Main et paramétrage...
Architecture d’OpenERP
14
• OpenERP est basé sur une architecture
client/serveur
• Le langage de programmation d’openEPR e...
Architecture d’OpenERP
15
• OpenERP utilise un “Object Relational Mapping”
(ORM) pour la persistence de ses objets métier
...
Architecture d’OpenERP
16
OpenERP Server OpenERP Client
Bus.
Object
Bus.
Object
Bus. Bus.
Object User
WindowsTrees
Forms
C...
Architecture d’OpenERP
17
Client /Serveur
• La logique d’OpenERP est entièrement du côté serveur.
• Le client est très sim...
Architecture d’OpenERP
18
Python
• Langage de programmation interprété
• Langage de programmation orienté objet
class nom_...
Architecture d’OpenERP
19
XML/RPC
XML-RPC est un protocole RPC (Remote procedure call), une
spécification simple et un ens...
Architecture d’OpenERP
20
Object Relational Mapping (ORM)
ORM
Les objets de
l’application
save(params)
Search(params)
…..
...
Plan du cours
• Introduction à la démarche d’intégration d’un ERP
• Architecture d’OpenERP
21
Prise en Main et paramétrage...
Plan du cours
• Introduction à la démarche d’intégration d’un ERP
• Architecture d’OpenERP
22
• Prise en Main et paramétra...
Framework de développement : notions de base
23
Structure modulaire
• OpenERP possède une structure modulaire qui permet
d...
Framework de développement : notions de base
24
Structure d’un module
Pour créer un nouveau modules, il suffit de suivre l...
Framework de développement : notions de base
25
fichier __init__.py
• Le fichier __init_.py est exécuté au lancement du
se...
Framework de développement : notions de base
26
fichier __terp__.py
• __terp__.py est le fichier de description du module ...
Framework de développement : notions de base
27
définition des objets
• Tous les ressources d’OpenERP sont des objets (men...
Framework de développement : notions de base
28
définition des objets
• Pour définir un nouveau objet il suffit de définir...
Framework de développement : notions de base
29
définition des objets
• _name = nom de l’objet
• _columns = les attributs ...
Framework de développement : notions de base
30
définition des attributs de l’objet
• Les objets peuvent contenir trois ca...
Framework de développement : notions de base
31
définition des attributs de l’objet : les types simples
• Booléen : fields...
Framework de développement : notions de base
32
définition des attributs de l’objet : les types simples
• Date : fields.da...
Framework de développement : notions de base
33
définition des attributs de l’objet : les types ‘Relations’
• many2one : p...
Framework de développement : notions de base
34
définition des attributs de l’objet : les types ‘Relations’
• many2many: p...
Framework de développement : notions de base
35
définition des attributs de l’objet : les types ‘fonctions’
• Un champ de ...
Framework de développement : notions de base
36
définition des attributs de l’objet : les types ‘fonctions’
La signature d...
Framework de développement : notions de base
37
définition des attributs de l’objet : les types ‘fonctions’
Exemple :
'min...
Framework de développement : notions de base
38
les méthodes d’ORM
• Create: permet de créer une nouvelle ressource, et
re...
Framework de développement : notions de base
39
les méthodes d’ORM
read: permet de lire les valeurs des attributs d’une
re...
Framework de développement : notions de base
40
les méthodes d’ORM
search: permet de chercher des ressources selon des
cri...
Framework de développement : notions de base
41
les méthodes d’ORM
browse: permet de récupérer les ressources à travers le...
Framework de développement : notions de base
42
les méthodes d’ORM
write: permet de modifier les valeurs des champs d’une
...
Framework de développement : notions de base
43
les vues
• Deux types de vues sont les plus utilisés dans OpenERP:
▫ Les f...
Framework de développement : notions de base
44
les vues : les formulaires
• Chaque champ est
précédé par un libellé
• les...
Framework de développement : notions de base
45
les vues : les formulaires
• Une page de formulaire peut contenir une zone...
Framework de développement : notions de base
46
les vues : les formulaires
• On peut aussi diviser la pages en plusieurs o...
Framework de développement : notions de base
47
les vues : les listes
• Les listes sont utilisé pour visualiser les donnée...
Framework de développement : notions de base
48
les vues : mise en œuvre
• les vues sont définis dans des fichiers XML pos...
Framework de développement : notions de base
49
les vues : mise en œuvre
• Les tags <record> avec l’attribut model=”ir.ui....
Framework de développement : notions de base
50
les vues : mise en œuvre
• Les tags <record> avec l’attribut model=”ir.ui....
Framework de développement : notions de base
51
les vues : mise en œuvre
Les attributs du tag <field>:
• select : utilisab...
Framework de développement : notions de base
52
les vues : les tags de groupement dans un formulaire
• <notebook> : permet...
Framework de développement : notions de base
53
les vues : les actions et menus
Après définition des formulaires et des li...
Prochain SlideShare
Chargement dans…5
×

Cas integration open_erp

2 265 vues

Publié le

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 265
Sur SlideShare
0
Issues des intégrations
0
Intégrations
180
Actions
Partages
0
Téléchargements
226
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Cas integration open_erp

  1. 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 2 • 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 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
  4. 4. Plan du cours Introduction à la démarche d’intégration d’un ERP • Architecture d’OpenERP 4 • 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 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. 6. 6 Partenaires Processus 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 Processus Gestion matériel Processus RH Partenaires Processus Finance
  7. 7. Introduction démarche d’intégration d’un ERP 7 Elaboration du périmètre Recueil des données Choix de la solution ERP Ateliers de travail Consultation d’un registre de procédures Choix de la solution ERP Analyse de l’écart Implémentation Mise en production et maintenance registre de procédures Consultation de SI existant (écrans, …) Référentiel de données
  8. 8. Introduction démarche d’intégration d’un ERP 8 Elaboration du périmètre Recueil des données Choix de la solution ERP Identification des critères Analyse qualitative, Choix de la solution ERP Analyse de l’écart Implémentation Mise en production et maintenance Analyse qualitative, quantitative, multicritère Choix de la solution
  9. 9. Introduction démarche d’intégration d’un ERP 9 Elaboration du périmètre Recueil des données Choix de la solution ERP Comparaison entre les processus de l’entreprise et leur éventuelle Choix de la solution ERP Analyse de l’écart Implémentation Mise en production et maintenance éventuelle implémentation dans la solution choisie Rapport d’analyse
  10. 10. Introduction démarche d’intégration d’un ERP 10 Paramétrage Paramétrage + modification Développement spécifique Rapport d’analyse de l’écart Ressources+ chargedetravail
  11. 11. Introduction démarche d’intégration d’un ERP 11 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 Le but de ce cour
  12. 12. Introduction démarche d’intégration d’un ERP 12 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
  13. 13. Plan du cours • Introduction à la démarche d’intégration d’un ERP Architecture d’OpenERP 13 • 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 14 • OpenERP est basé sur une architecture client/serveur • Le langage de programmation d’openEPR est le langage Python Introduction 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 15 • 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 Introduction 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 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-RPC RPC interface Core User Interface base Postgres DB
  17. 17. Architecture d’OpenERP 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 sont réalisés sur le côté serveur.
  18. 18. Architecture d’OpenERP 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. 19. Architecture d’OpenERP 19 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 Client Code to XML XML to Code Serveur <sd:getBookPrice> <isbn>0321146182</isbn> </sd:getBookPrice> <sd:getBookPriceResponse> <result>24.99</result> </sd:getBookPriceResponse> HTTP Requête Réponse XML-RPC
  20. 20. Architecture d’OpenERP 20 Object Relational Mapping (ORM) ORM Les objets de l’application save(params) Search(params) ….. Insert Select Tables relationnelles ….. • 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 21 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 22 • 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 23 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 led’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 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, 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 25 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• 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 26 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▫ 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 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. 28. Framework de développement : notions de base 28 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 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. 29. Framework de développement : notions de base 29 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• _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 30 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 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 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. 32. Framework de développement : notions de base 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','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 33 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',▫ 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 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 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 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é de la 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 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 36 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)▫ 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 37 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 thetype='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 38 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}▫ 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 39 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={})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 40 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 41 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 42 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 43 les vues • Deux types de vues sont les plus utilisés dans OpenERP: ▫ Les formulaires ▫ Les listes▫ Les listes
  44. 44. Framework de développement : notions de base 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 debas, 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 45 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 46 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 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. 48. Framework de développement : notions de base 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. 49. Framework de développement : notions de base 49 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="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. 50. Framework de développement : notions de base 50 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="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. 51. Framework de développement : notions de base 51 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• 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 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 en plusieurs 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. 53. Framework de développement : notions de base 53 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="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"/>

×