Archives du mot-clé Modélisation

ODOO 8 – Article / Variante / Catégorie d’article

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 :

 
* Petite précision concernant les champs "Code barre EAN13" et "Référence interne" :
   - si l'article ne comporte pas de variantes , ces champs apparaissent dans l'onglet Information" de l'article

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

   ... et non plus dans l'article

Architecture ODOO

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".

Quel formalisme pour modéliser un processus ? (2/3)

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".

Workflow versus Processus (1/3)

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 !!

Objets fonctionnels principaux

Intéressons nous aux 2 objets principaux du logiciel :

Partenaire

Un partenaire est un tiers qui est en relation avec l'entreprise.
C'est un objet très générique qui peut désigner une personne ou une entité :
  • client,
  • fournisseur,
  • sous-traitant,
  • contact d'une entité elle-même partenaire (client, fournisseur ...)
  • employé de l'entreprise
Cet objet se nomme res.partner
Il est possible de catégoriser les partenaires à l'aide du champ « étiquette » issu de la relation « n-n » res.partner.category
H2 { margin-bottom: 0.21cm; }H2.western { font-family: "Arial",sans-serif; font-size: 14pt; font-style: italic; }H2.cjk { font-size: 14pt; font-style: italic; font-weight: normal; }H2.ctl { font-family: "Lohit Hindi"; font-size: 14pt; font-style: italic; }P { margin-bottom: 0.21cm; }P.western { font-family: "Arial",sans-serif; }P.cjk { font-size: 10pt; }A:link { }

Produit

Cet objet se nomme product.product
Le libellé français est Article
Un article est soit un bien, soit un service.
Dans le cas d'un bien, il peut-être stockable ou consommable.
Un article est configuré dans une nomenclature de produits (relation « n-n » product.category).
Il est soit produit par l'entreprise, soit approvisionné par un ou plusieurs fournisseurs.
On peut représenter cet objet et ses relations par le diagramme suivant :