Des changements étant apparus en v8, il me parait intéressant de faire un point rapide sur les 3 objets :

• article
• variante
• catégorie d'article

Voici un schéma qui présente ces objets et leurs relations (avec leur cardinalité).
Le nom du "business object" est indiqué entre parenthèses.

Ce qui peut surprendre est que "article" correspond au BO "product.template" et que "variante" correspond à "product.product".

 La vision "utilisateur" de ces 3 objets est la suivante :

 

   - si l'article comporte des variantes, ces champs apparaissent dans chaque variante

   ... et non plus dans l'article

 

L'architecture ODOO (versions 6 à 8)  peut être modélisée par le schéma suivant :

La "brique" IHM de l'architecture ODOO correspond au modèle 3 décrit dans l'article de la société OCTO sur le sujet :

PS: l'architecture "Front Web" des nouveaux modules CMS et eCommerce apparus avec la version 8, diffère sensiblement de cette architecture avec l'apparition dans Odoo, du framework Twitter Bootstrap qui entre autres, permet de répondre aux exigences "Responsive Web Design".

Les questions habituelles concernant un processus sont  :

• Comment vu des utilisateurs, est-il implémenté dans OpenERP ?
• Si ce processus ne convient pas au client, quel est l'écart ?
• Quels sont les impacts sur OpenERP d'une modification de processus ?

Pour répondre à ces questions, la représentation graphique "processus" proposée par OpenERP (vue dans l'article précédent) ne me suffit pas, surtout pour décliner les impacts applicatifs et techniques, d'une modification de processus.

Aussi, après avoir essayé UML, je pense avoir trouvé pour m'aider, une solution de modélisation avec le standard Archimate .
Ce standard de modélisation a été élaboré par "The Open Group" et est utilisable concrètement via le logiciel libre Archi.

J'utiliserai pour modéliser les processus OpenERP, la représentation des 2 couches  :

• "métier" : processus et rôle
• "applicative" : service, workflow, wizard, table OpenERP, journaux comptables ...

* exemple de modélisation (domaine assurance)

Dans la suite, j'utiliserai l'outil Archi pour ses possibilités de représentation graphique mixte "métier/applicatif" mais je ne serai pas forcément rigoureux dans l'application du formalisme "Archimate".

Avant de rédiger quelques articles sur les processus et workflow, j'aimerai préciser ce que sont dans OpenERP, les workflow et les processus.

=> Un workflow définit le comportement d'un "objet" OpenERP (ex: bon de commande, facture, ordre d'appro ...) par une succession de transitions et d'activités.
Il est implémenté dans un moteur de workflow propre à OpenERP.
* exemple : workflow d'une facture

Un workflow est l'entité applicative et technique qui permet d'implémenter un processus. Une modification de processus s'implémente par la modification d'un ou plusieurs workflow et ceci sans modification de code python mais uniquement en ajoutant/modifiant/supprimant des activités ou transitions.
Un workflow est souvent instancié suite à la création d'un nouvel enregistrement de la table (objet) dont il dépend.

=> Un processus OpenERP est la vision utilisateur d'un processus métier.
Un processus est transverse à l'entreprise et adresse généralement plusieurs "objets" OpenERP.
Les processus principaux (vente, achat, facturation ...) sont représentés graphiquement en activant le mode "développeur"
* exemple : vente

Cette représentation graphique ne sert qu'à représenter ces processus mais aucune modification n'est possible.
Elle permet juste d'aider les utilisateurs à comprendre comment sont implémentés en standard dans OpenERP, les processus  principaux.
Pour modifier un processus, il faut identifier et modifier les workflow correspondant aux "objets" OpenERP intervenant dans le processus.

!! la représentation "processus" n'existe plus dans ODOO depuis la version 8 !!