Paramétrage et développement spécifique des modules odoo (OpenERP) Partie 1

Paramétrage et développement spécifique
des modules odoo (OpenERP)
Réalisé par : Ait Mlouk Addi
Blog : http://aitmlouk-addi.blogspot.comSite web : http://www.aitmlouk-addi.infoaitmlouk@gmail.com

Plan
Prise en main
Configuration et paramétrage
Modules personnalisé
Introduction
Conclusion
Développement spécifique
Prise en main et paramétrage d’odoo
(OpenERP)

• Prise en main complet d’odoo
• Configuration complète
• Caractéristiques techniques complète
• Savoir crée un module personnalisé
• Savoir développer un module spécifique
2
Prise en main complet d’odoo Configuration complète Module personnalisé Module spécifique Conclusion
Prise en main et paramétrage d’OpenERP

Configuration Odoo
Partie 1: Prise en main

• Démarrer le serveur
• Créer une nouvelle base de données formation, mot de passe admin
• Se connecter à la nouvelle base
de donnée

• Activer les menus de la configuration avancée :
• Configuration -> Utilisateurs -> Modifier l’utilisateur -> Onglet droits d’accès
• Cocher Caractéristiques techniques
• Administration -> sélectionner l’option Configuration
• Actualiser la page
• Installer des modules

Pour une simple modification au niveau d’un module sous odoo on peut passez tous simplement par Des objets
et vues personnaliser et en crée les objets comme suite :
• Configuration -> structure de la base de donnée -> Modèle puis crée un objet

Apres la définition de l’objet il reste a définir les champs comme suite :

Et les menus comme suite :

Apres que nous terminons notre module personnalisé on enregistre le module en question et on rafraichir la page pour
que les modification soit apparaitre comme suite :

Le mode développeur
Le mode développeur permet de debugger les modules afin d’identifier les objet , champs, vues, menus …
techniquement Il est utiliser par un développeur pour identifier plus de détailles sur les objets … qui servira a
paramétrer et a modifier les modules stocker dans la base de donnée et pas dans le code source. Pour activer le
mode développeur on procède comme suite :
Administrator -> Apropos de l’OpenERP

Pour debugger un module ou un objet on passe par le menu Déboguer et en choisie l’action qui convient.

Développement spécifique d’un module
Les différents phase d’un ERP
Un ERP possède généralement trois phases de travail :

Architecture modulaire sous odoo (openerp)
• Tous les modules d’OpenERP sont créés au-dessous du répertoire
openerp7/openerp/addons

Architecture modulaire sous odoo
• Structure standard d’un module sous odoo

Structure d’un module Odoo
• Les étapes suivantes sont nécessaires pour créer un nouveau module :
• Créer un package python dans le répertoire /addons portant le nom de votre module (required)
• Créer un fichier de description du module : __openerp__.py (required)
• Créer le fichier Python contenant les modèles (Classes + Méthodes) (required)
• Créer des fichiers .XML pour définir les menus, les vues et les actions (required)
• Créer des fichiers .XML qui téléchargent des données de démonstration
• Créer éventuellement des rapports, des assistants (Wizard) ou des flux de travail (Workflow).

Obligatoires
__init__.py Initialisation du package Python
__openerp__.py La fiche descriptive du module
module.py Les classes Python, les objets du module
module_view.xml Les vues (Formulaires, listes, graph,…), menus et actions
Optionnels
demo Données de test et de démonstration
i18n Fichiers de traduction – Internationalisation
report Définition des rapports
security Déclaration des groupes et des droits d’accès
workflow Définition des workflow
wizard Définition des assistants

__init__.py
• C'est le fichier qui permet a OpenERP de charger notre module.
Le contenu de ce fichier est très simple :
import nom_module

__openerp__.py
• name : le nom de votre module ;
• version : la version du module ;
• category : la catégorie dans laquelle vous classez votre module ;
• sequence : c'est un nombre qui permet de définir l’ordre de votre module dans la liste des modules. 1, il sera en haut, 100 il sera en bas
• author : l'auteur du module ;
• description : la description complète du module ;
• depends : les dépendances votre module ;
• data : les fichiers à charger ;
• installable : si votre module est installable ou non ;
• application : laissez à False. Votre module ne sera pas reconnu comme une application. C'est OpenERP qui délivre les certificats qui qualifient
votre module d'application ;
• auto_install : laissez à False, nous l'installerons à la main.

# -*- coding: utf-8 -*-
{
'name' : "nom de module",
'author' : "auteur",
'version' : "0.1",
'description' : "description…",
'website' : "site web ou blog si il existe …",
'category' : "catégorie de module",
'summary' : "les mots clef de description",
'sequence' : 0,
'depends' : ['base'],
'update_xml' : [
#'travaux_view.xml',
],
'demo_xml' : []
'installable' : True,
'application' : False,
'auto_install' : False,
}
Exemple de fichier de description du module
__openerp__.py (Squelette)

Exercice 1 :Exemple de création de module
• Créer un module vide formation_travaux
• Créer les fichiers obligatoires __init__.py et __openerp__.py
• Redémarrer le serveur
• Installer le module à partir du menu
• Configuration -> Modules -> Modules installés
• Lancer l’installation du module on cliquant sur installé

# -*- coding: utf-8 -*-
{
'name' : "Formation Gestion des travaux",
'author' : "Ait-Mlouk Addi",
'version' : "0.1",
'description' : "Module de gestion des travaux sous odoo",
'website' : "www.aitmlouk.esy.es",
'category' : "Maintenance",
'summary' : "Travaux, Taches, Incidents",
'sequence' : 0,
'depends' : ['base'],
'update_xml' : [
#'travaux_view.xml',
],
'demo_xml' : []
'installable' : True,
'application' : False,
'auto_install' : False,
}
Réponse
__openerp__.py

Les classes
Partie 2
Les classes

La couche Model
• Le Framework Object Service (OSV) met en œuvre une couche complète de Mapping Objet Relationnel.
• Il permet aux développeurs de mettre en place l’architecture SQL de base.
• Les objets métier sont déclarés comme des classes Python qui héritent de la classe osv.osv, ce qui les rend
une partie du modèle OpenObject modèle, et qui seront automatiquement persistés par la couche ORM.
Les classes

Les types des champs de l’ORM
• Un objet peut avoir 3 types de champs
• Simple : Integers, Floats, Date, Booleans, Char, Text, Binary…
• Relationnel : Représente les relations entre les objets (one2many, many2one, many2many)
• Fonctionnel : Des champs stocké ou non-stockés à la base de donnée, il sont calculés à la
volé comme des fonctions Python
Les classes

Champssimple
boolean(...), integer(...), date(...), datetime(...)
time(...), float(…)
Exemple :
'active': fields.boolean('Active'),
'priority': fields.integer('Priority'),
'start_date': fields.date('Start Date'),
char(string,size,translate=False,..)
text(string,size,translate=False,..)
• translate: True si le champs peut être traduit par l’utilisateur
• size: la taille maximum d’un champs caractère (→41,45)
selection(values, string, ...) ‘status' :fields.selection([('open','Open'),('closed','Closed')],'Status',
required=True, translate=True),
binary(string, filters=None, ...)
Un champs pour stocker des fichiers ou des images
• filters: Filtres optionnels sur le nom du fichier
'picture':fields.binary('Picture',filters='*.png,*.gif')
Champsrelationnel
many2one(obj, ondelete='set null', …)
Relation vers l’objet courant
• obj: Le nom _name de l’objet destination (requis)
• ondelete: e.g. 'set null', 'cascade', Voir la documentation PostgreSQL
one2many(obj, field_id, …)
L’inverse de many2one
• field_id: field name of inverse many2one
many2many(obj, rel, field1, field2, …)
Relation bidirectionnel multiple entre deux classes
• rel: Le nom SQL de la table associative (requis)
• field1: Le nom du champs de l’objet actuel dans la table associative (requis)
• field2: Le nom du champs de l’objet destination dans la table associative (requis)
Les classes

• Un champ de type fonction est un champ qui est calcule par une fonction ( a 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 calcule par une méthode d’objet ou une méthode statique de classe
• fnct_inv : le nom de la fonction qui permet d’ecrire la valeur du champ dans la base au cas ou store=true
définition des attributs de l’objet : les types ‘fonctions’
Les classes

• Tous les ressources d’OpenERP sont des objets (menus, rapport, factures, partenaires, …)
• OpenERP contrôle les données de ces objets a travers un ORM
• Le nom des objets est par convention hiérarchique
définition des objets
class account_invoice():
class account_invoice_line():
class account_trensfer():
Nom du module Nom de l’objet
Les classes

• 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éfinie a travers la déclaration de certains attribut statique prédéfini, dont deux sont obligatoires
:_name, et _columns
class object_name(osv.osv):
_name = 'object.name'
_description = u"object description"
_inherit ='inherit.object.name'
_columns ={…}
_constraints =
_sql_constraints =
_order =
Object_name()
Héritage de l’objet osv
Description python statique
Instanciation de l’objet
Les classes

• _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 utilise pour ordonner les résultats de recherche
• _defauts = valeurs par défaut des attributs de l’objet
• _sql = code sql exécute lors de la création de l’objet
• _table = nom de la table sql, la valeur par défaut étant la valeur de ‘_name’ ou les points «.» remplace par
un underscor « _ »
Les classes

Create: permet de créer une nouvelle ressource, et retourner son identifiant.
Signature : def create(cr, uid, vals, context={}), ou
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’}
)
35
les méthodes d’ORM : create
Les classes

read: permet de lire les valeurs des attributs d’une ressource des identifiant passes en paramètres
Signature : def read(self, cr, uid, ids, fields=None, context={}), ou
ids : est la liste des identifiants a lire
fields : la liste des champs a lire
Cette fonction retourne un tableau sous la forme [{‘name_of_the_field’: value, ...}, ...]
read(cr, uid, ids, [’name’,’category_id’], context=context)
les méthodes d’ORM : read
Les classes

search: permet de chercher des ressources selon des criteres passes en parametres
Signature:
def search(self, cr, uid, args, offset=0, limit=2000, order=None, context=None, count=False), Ou
args : est une liste de critères de recherche sous la forme [(‘name_of_the_field’, ‘operator’, value),
Les operateurs 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’)])
37
les méthodes d’ORM : search
Les classes

browse: permet de récupérer les ressources a travers leurs identifiants
Signature: def browse(self, cr, uid, select, offset=0, limit=2000) , Ou 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 passe en paramètre
browse(cr, uid, contact_id)
38
les méthodes d’ORM : browse
Les classes

write: permet de modifier les valeurs des champs d’une ressource
Signature : def write(self, cr, uid, ids, vals, context={}), Ou
ids : est la liste des identifiants d’objet a modifier
vals : un tableau des champs a 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’})
39
les méthodes d’ORM : browse
Les classes

La couche Model
L’architecture d’une classe (Model) vide
class classe_name(osv.osv):
_name = 'object.name'
_description = u"object description"
_columns = {
'field1' : fields.char(u'Numéro', size=32, required=True),
'field2' : fields.many2one('object.name', u'Responsable', required=True),
…
}
_defaults = {
'field': lambda self, cr, uid, context: '/',
}
Classe_name()
# -*- coding: utf-8 -*-
from openerp.osv import fields, osv
Les packages et el éléments nécessaires pour créer un model
Les classes

Exercice 2 : Exemple de création des classes
• Créer un nouveau fichier travaux.py dans le module formation_travaux
• Importer les packages du framework osv
• Créer une classe formation_work dans le fichier travaux.py
• Redémarrer le serveur
• Mettre à jour le module à partir du menu
• Configuration -> Modules -> Modules installés
• Lancer la mise à jour du module on cliquant sur Mettre à jour
• Ouvrer le gestionnaire PgAdmin et vérifier dans votre base de données si la table
formation_work a été bien créée.
Les classes

Réponse
L’architecture d’une classe (Model) vide
travaux.py
class formation_work(osv.osv):
_name = 'formation.work'
_description = u"This is for managing works"
_columns = {
'name' : fields.char(u'Numéro', size=32, required=True),
'responsable': fields.many2one('hr.employee', u'Responsable', required=True),
'user' : fields.many2one('res.users',u'Note', translate=True),
'line_ids' : fields.many2one('formation.work.line', u'maintenance', required=True)
}
_defaults = {
'name': lambda self, cr, uid, context: '/',
}
formation_work()
# -*- coding: utf-8 -*-
Les packages nécessaires pour créer un model
Les classes

Exercice 3
• Créer une nouvelle classe formation_work_line dans le fichier travaux.py
• Ajouter des champs relationnels dans les deux classes (formation_work et
formation_work_line) pour représenter la relation suivante,
formation_work
name (char)
responsable (many2one)
user(many2one)
line_ids (many2one)
formation_work_line
name (char)
maintenance (one2many)
description (text)
* 1
many2one
one2many
Les classes

Réponse 1 :
L’architecture d’une classe formation_work
travaux.py
class formation_work(osv.osv):
_name = 'formation.work'
_description = u"This is for managing works"
_columns = {
'name' : fields.char(u'Numéro', size=32, required=True),
'responsable': fields.many2one('hr.employee', u'Responsable', required=True),
'user' : fields.many2one('res.users',u'Note', translate=True),
'line_ids' : fields.many2one('formation.work.line', u'maintenance', required=True)
}
_defaults = {
}
formation_work()
# -*- coding: utf-8 -*-
Les classes

Réponse 2 :
L’architecture d’une classe formation_work_line
travaux.py
class formation_work_line(osv.osv):
_name = 'formation.work.line'
_description = u"This is for managing works line"
_columns = {
'name' : fields.char(u'Nom', size=32, required=True),
'maintenance' : fields.one2many('formation.work', u'Maintenance', required=True),
'description' : fields.text(u'Description', translate=True),
}
_defaults = {
}
formation_work_line()
# -*- coding: utf-8 -*-
Les classes

vues, actions et Menus
Partie 2
Vues, Actions et Menus

Structure des modules Odoo
• Structure standard d’un module sous OpenERP

Les Vues
• Déclaration générique d’une vue :
<record model="ir.ui.view" id="VIEW_ID">
<field name="name">VIEW.NAME</field>
<field name="model">PYTHON.CLASS.NAME</field>
<field name="arch" type="xml">

</field>
</record>
• name nom de la vue (nomination séparée par des point)
• model modèle d'objet sur lequel la vue est définie (comme res_model dans les actions)
• type form, tree, graph, calendar, search, gantt, kanban
• arch architecture de la vue

La vue Formulaire (Form)
• Exemple de la vue formulaire

• Déclaration XML

<record model="ir.ui.view" id="formation_work_form">
<field name="name">formation.work.form</field>
<field name="model">formation.work</field>
<form string="Travaux">
<field name="name" />
<field name="responsable" />
<field name="user" />
<field name="line_ids" />
</form>
</field>
</record>

• Déclaration XML ( API Version 7)
<record model="ir.ui.view" id="formation_work_form">
<field name="name">formation.work.form</field>
<form string="Tables" version="7.0">
<sheet>
<h1>
<label for="name" string="Numéro" />
</h1>
<label for="user" string="Utilisateur" />
<field name="description" />
</sheet>
</form>
</field>
</record>

• Les attributs communs à tous les éléments :
• string : label de l'élément ;
• nolabel : mettre à 1 pour cacher l'étiquette du champ ;
• colspan : nombre de colonnes sur lesquelles le champ doit s'étendre ;
• rowspan : nombre de lignes sur lesquelles le champ doit s'étendre ;
• col: nombre de colonnes que cet élément doit allouer à ses éléments enfants ;
• invisible : mettre à 1 pour cacher cet élément complètement ;

• Déclaration XML (Sheet, h1 + Group + Notebook)

La vue Liste (Tree)
• Exemple de la vue liste (Tree)

La vue Liste (Tree)

<record model="ir.ui.view" id="formation_work_tree">
<field name="name">formation.work.tree</field>
<tree string= "Travaux">
<field name="description" />
</tree>
</field>
</record>

La vue Liste (Tree)

La vue Kanban (Vignette)
• Cette vue représente les données sous forme de colonnes / petite vignette regroupées par un critère.
• Les vue Kanban sont personnalisable avec des balises HTML ou QWeb
• Qweb : Un langage de Template HTML développé par OpenERP qui permet de définir une structure portable
des composantes HTML.

La vue Kanban (Vignette)
<record model="ir.ui.view" id="formation_work_tree">
<field name="name">formation.work.kanban</field>
<kanban>
<templates>
<t t-name="kanban-box">
<div class="oe_module_vignette" style="background:#EEE">
<div class="oe_module_desc">
<h2><a type="edit"><field name="name"/></a></h2>
<ul>
<li><strong><field name="description"/></strong></li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>

La vue Kanban (Colonnes)

Menus et actions
• Les menus principales permette à l’utilisateur d’accéder au module
• Chaque module est dispose d’un menu principale et d’autres sous menus
• Les menus et leurs actions sont déclarés à l’intérieur d’un fichier xml : ( travaux_view.xml)

Menus et actions
Menu sans action
Menu 1 avec action
Menu principal
Menu 2 avec action

• Structure de la vue travaux_view.xml vide
<?xml version="1.0" encoding="UTF-8"?>
<openerp>
<data>
[views definitions]
[actions definitions]
[menus definitions]
</data>
</openerp>
Actions et menus
Pour les bonnes pratique il est préférer de séparer les menus dans
un fichier xml (menu_views.xml) a fin de facilité la maintenance.

Actions
• La déclaration XML d’une action est la suivante
• model : la table (base de données) pour stocker des actions
• id : Identifiant de l’action dans la table ir.action.act_windows, il doit être unique
• name : Le nom de l’action (requis)
• res_model : Le model (classe python) objet de la vue (requis)
• view_mode : La liste des modes alloués pour visualiser les enregistrements
<record model="ir.actions.act_window" id="work_action_work">
<field name="name">Works</field>
<field name="res_model">formation.work</field>
<field name="view_mode">tree,form</field>
</record>

Menus
• La déclaration XML d’un menu principal, niveau 1
• La déclaration d’un menu niveau 1.1 (Sans action = non cliquable)
• La déclaration d’un menu niveau 1.1.1 (menu cliquable avec action)
• REMARQUE : Avant d’utiliser les menus cliquables, il faut définir l’action action="[ACTION_ID]" qui va être déclenchée.
<menuitem id="work_menu_root" name="Traveaux" />
<menuitem id="work_menu" parent="work_menu_root" name="Traveaux" />
<menuitem id="works_work_menu" parent="work_menu" name="Traveaux" action="[ACTION_ID]" />

Exercice 3 (Création des menus)
Travaux
Travaux
Tache
Travaux
formation.work.line
formation.work

Réponse :
<menuitem id="work_menu_root" name="Traveaux" />
<menuitem id="work_menu" parent="work_menu_root" name="Traveaux" />
<menuitem id="works_work_menu" parent="work_menu" name="Traveaux" action="[ACTION_ID]" />
<menuitem id="works_task_menu" parent="work_menu" name="Tache" action="[ACTION_ID_TASK]" />

Sécurité
Partie 3
Sécurité

Sécurité
• Les utilisateurs et les rôles sont des points critiques en matière de sécurité interne dans
OpenERP.
• OpenERP propose plusieurs concepts de sécurité concernant les rôles des utilisateurs :
• Utilisateur: une personne identifiée par son login et mot de passe. Notez que tous les
employés d'une entreprise ne sont pas nécessairement les utilisateurs OpenERP, un
utilisateur est une personne qui accède à l'application.
• Groupe: un groupe d'utilisateurs qui a des droits d'accès. Un groupe donne ses droits
d'accès à ses utilisateurs. Ex: responsable des ventes, comptable, etc
• Règles de sécurité: une règle qui définit les droits d'accès d'un groupe donné. Les règles
de sécurité sont fixées à une ressource donnée, par exemple le modèle de facturation.
Sécurité

Groupes
• La création des groupes peut se faire d’une manière graphique (Configuration ->
Utilisateurs -> Groupes) ou avec des fichiers de données XML
Sécurité
Méthode graphique

• Exemple de fichier XML de groups
<?xml version="1.0" encoding="utf-8"?>
<openerp>
<data noupdate="1">
<record id="group_work_manager" model="res.groups">
<field name="name">work/ Manager</field>
<field name="comment">Manager of works</field>
<field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
</record>
<record id="group_work_user" model="res.groups">
<field name="name">Restaurant / user</field>
<field name="comment">userof restaurant</field>
<field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
</record>
</data>
</openerp>
Sécurité
Groupes

Les états de sortie
report
états de sortie

internationalisation
• Odoo (Openerp) possède deux types de rapport:
• Rapports et statistiques: ce sont des données calculées, souvent représentés sous la forme
graphiques.
• Etat de sortie: ils sont utilisés pour imprimer des documents du système. Le résultat est
généralement un PDF généré par une sélection effectuée sur l'écran. En outre, OpenERP
vous permet d'ouvrir ces rapports dans OpenOffice.org.
reports

• Pour la représentation des menus d’impression on définie un fichier xml comme suite :
<?xml version="1.0" encoding="utf-8"?>
<openerp>
<data>
<report auto ="False" id="report_formation_travaux" model="formation.work" name="formation.work"
rml="formation_travaux/report/travaux.rml" string="Fiche de Travau" usage="default"/>
</data>
</openerp>

• Le parseur
import timefrom openerp.report import report_sxw
class madrassa_travaux(report_sxw.rml_parse):
def __init__(self, cr, uid, name, context=None):
super(madrassa_travaux, self).__init__(cr, uid, name, context=context)
self.line_no = 0
self.localcontext.update({
'time': time,
'line_no':self._line_no,
})
report_sxw.report_sxw('report.formation.work', 'formation.work',
'addons/formation_travaux/report/travaux.rml', parser=madrassa_travaux, header="external")

Internationalisation
i18n

Exercice 5 (Internationalisation)
• Exporter la Template de traduction du module formation_travaux
• Configuration -> Importer / Exporter -> Exporter une traduction
• Sélectionner le module formation_travaux
• Cliquer sur Exporter
• Télécharger le fichier formation_travaux.po
• Créer un sous répertoire i18n à l’intérieur le dossier du module
• Coller le fichier formation_travaux.po dedans
• Créer une copie du fichier avec le nom fr.po
• Ouvrer l’éditeur Poedit et traduire les messages du fichier fr.po en français
• Enregistrer et redémarrer le serveur, puis lancer un mise à jour du module.
• Si la base de données est installée en français, le module va prendre en
considération le fichier fr.po

Paramétrage et développement spécifique
des modules odoo (OpenERP) Partie 1
Réalisé par : Ait-Mlouk Addi
Site web : http://www.aitmlouk-addi.info/
Blog : http://aitmlouk-addi.blogspot.com
Twiter: https://twitter.com/aitmlouk
Viadeo: http://ma.viadeo.com/fr/profile/addi.mlk
Linkedin: https://www.linkedin.com/pub/addi-ait-mlouk/56/850/32a
Youtube: https://www.youtube.com/user/mloukaddi/videos
Github: https://github.com/aitmlouk
Slidshare: http://fr.slideshare.net/mloukaddi/
aitmlouk@gmail.com
Conclusion
Laboratoire GIESI

Paramétrage et développement spécifique des modules odoo (OpenERP) Partie 1

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Paramétrage et développement spécifique des modules odoo (OpenERP) Partie 1

Similaire à Paramétrage et développement spécifique des modules odoo (OpenERP) Partie 1 (20)

Paramétrage et développement spécifique des modules odoo (OpenERP) Partie 1