Intégration et Généricité: Modèle ADROIT

ERP5

Dans le site de ERP5, on peut trouver la définition suivante [I.36] « ERP5 est un progiciel orienté production (utilisé en industrie de production : automobile par exemple), il est édité par la société NEXEDI et est développé en langage PYTHON avec comme serveur d'application ZOPE.

ERP5 comporte 3 problématiques :

Ø Un modèle d'unification des flux informationnels de l'entreprise

Ø Un système de base de données d'objets actifs

Ø Un mécanisme de distribution des données fondé sur la synchronisation

La première problèmatique qui consiste en un modèle d'unification des flux informationnels (modèle théorique) comporte cinq concepts (classes) qui sont : Ressource (resource), noeud (node), mouvement (movement), élément (item), chemin (path).

Path (Chemin)

Planification

Approvisionnement

Resource (Ressource)

Argent

Matériaux

Service

Compétence

Item (Elément)

Logistique

Traçabilité

Node (Noeud )

Machine

Personne

Organisation

Movement (Mouvement)

Commande

Livraison

Transaction

Ordre de production

Modèle d'unification des flux informationnels

( modèle de gestion intégré ).

Une ressource (Resource) décrit une ressource abstraite dans le processus de gestion. Elle est un descripteur d'objets tangibles (matière première, papier, eau, électricité.) ou intangibles

( argent, compétence, temps ).

Un noeud (Node) définit l'identité d'un acteur d'un processus de gestion. Il peut aussi définir un lieu ou un emplacement qui peut recevoir une quantité de ressources et en recevoir. Il peut représenter une personne, une organisation, un stock, un compte, un atelier etc.... Il peut stocker ou transformer des ressources, exemple : dans un atelier de métallurgie, une matière première peut être transformer en un produit fini. Le stock est un type de noeud. Un compte bancaire peut recevoir de l'argent mais il peut aussi en donner.

La classe Node (Noeud) est l'une des plus importantes classes de ERP5.

Chaque noeud à une capacité et une capacité consiste en :

Ø Définir la quantité maximale de ressources qu'un noeud peut garder. Il est définit par un ensemble d'inéquations qui doivent être satisfaites par le stock. Chaque équation prend une quantité d'une ressource donnée comme variable et la capacité du noeud comme paramètre.

Ø Définir la quantité maximale ou minimale de ressource qu'un noeud peut produire. Il est aussi définit à travers un ensemble d'inéquations.

Exemple : Pour l'organisation au niveau noeud, il faut prendre en considération les mouvements qui viennent ou partent du noeud.

Ø un mouvement qui arrive au noeud augmente le niveau du stock.

Ø un mouvement qui part du noeud diminue le niveau du stock.

Ø un mouvement qui part du noeud et ne va nulle part est une consommation de ressource.

Ø un mouvement qui part de nulle part et arrive au noeud est une production de ressource.

Pour calculer le niveau du stock, il faut voire l'historique, ajouter les quantités sorties et soustraire les entrées.

Il existe la notion de méta noeud qui représente une collection d'autres noeuds. Par exemple une compagnie est un noeud, un projet est en même temps un noeud et une ressource.

Un méta noeud peut recevoir des mouvements en entrées et envoyer des mouvements en sorties comme un noeud le fait.

Le méta noeud est principalement pratique si l'on veut implémenter une organisation au niveau méta sans affecter les détails de l'organisation au niveau noeud. L'organisation de la compagnie devrait alors requérir un changement de source et de destination de mouvements à partir du niveau méta noeud à chaque fois qu'une organisation plus détaillée est requise.

Les méta noeuds sont une agrégation de règles pour des mouvements à côté du comportement habituel d'un noeud.

Une agrégation de mouvements de méta noeud consiste en un ensemble de mouvements qui sont reliés dans un noeud ou à un noeud qui ne sont pas contenus dans un méta noeud.

Le mouvement (Movement) décrit le mouvement de ressources entre deux noeuds en un moment donné et à une heure donnée. Par exemple, on peut avoir un envoi de matière première du stock vers le magasin; un mouvement autre mouvement peut représenter le transfert de l'argent d'un compte vers un autre.

Les mouvements peuvent inclure des sous mouvements générés par des règles de gestion (le coût pour l'obtention d'un mouvement entre noeud source et un noeud stock).

Les mouvements peuvent aussi être associé à d'autres mouvements à travers des causalités. La collection complète de mouvements avec des dates passées et des dates futures représente l'organisation complète de l'entreprise parce que les mouvements ont un commencement et une fin.

Toutefois, les mouvements sont des objets ERP5 de bas niveau. Par conséquent, les mouvements sont rassemblés ensemble dans des livraisons. Les livraisons sont des documents qui sont utilisés en pratique pour gérer l'organisation d'une compagnie.

La classe Movement permet d'implémenter un modèle ERP5 de comptabilité universel. Les instances de la classe Movement sont utilisées dans différentes situations.

Ø orders : ces instances utilisées comme objet documentaire pour définir des quantités dans des orders.

Ø deliveries : les mouvements suivent la trace de l`actuel transfert de ressources dans le passé (comptabilité) ou dans le futur (planning/ budgétisation)

Par exemple : Les objets suivants sont des orders:

Ø Bon de commande (document envoyé à un fournisseur quand il a besoin de marchandises).

Ø Ordre de vente (document envoyé à un client pour lui signifier la confirmation d'une vente).

Ø Ordre de production document envoyé à un magasin pour confirmer que nous avons besoin d'une opération ou d'un service).

Les orders permettent de décrire une cible, mais peuvent être utilisée pour compter la réalité d'un actuel transfert de quantité.

Les cas suivant ne sont pas des délivrances : une délivrance de monnaie entre deux comptes abstraits, une délivrance de marchandises expédiées, une délivrance de marchandises reçues, une délivrance de service, une délivrance de monnaie entre deux comptes réels

Le chemin (Path) correspond au chemin pour un noeud d'accéder à la ressource dont il a besoin éventuellement. Le prix et les profiles commerciaux peuvent être attachés à un noeud afin de définir le prix par défaut d'une ressource achetée à un fabricant donné.

Il peut aussi définir le chemin pour un atelier d'obtenir des ressources d'un stock. Un path a toujours une date de début et une date de fin. Le chemin peut aussi représenter la tâche attribuée à une personne dans un projet temporaire.

Dans certaines entreprises, en particulier dans les compagnies de services, les personnes sont attribuées à des projets pour une certaine période (consultation) ou les personnes sont envoyées à des clients pour une certaine période donnée (exemple : un centre de réparation d'ordinateur). Ces situations peuvent être représentées dans ERP5 par l'utilisation de Path temporaire avec une date de début et une date de fin données.

L'élément (Item) est une instance physique d'une ressource. Les mouvements de ressources sont décomposés en éléments ayant chacun un numéro de série.

Un mouvement peut être étendu en une série de mouvements traçables à travers des items. Les items permettent aussi de définir comment une quantité de ressources donnée est actuellement expédiée ou transportée (traçabilité d'une ressource). Exemple : colis, numéros de série d'items dans chaque conteneur.

La deuxième problématique consiste en un système de base de données d'objets actifs, au lieu de stocker des données dans une base de données relationnelle, ERP5 utilise la base de données Zope. On peut donc interroger la base d'objets ERP5 au moyen de requêtes SQL.

La troisième problématique est le mécanisme de distribution des données fondé sur la synchronisation, on trouve que le fonctionnement de ERP5 est distribué et permet la répartition des données sur plusieurs sites.

Ainsi la combinaison des trois innovations décrit en haut et le caractère libre de ERP5 forment son caractère générique.

Dans ERP5, le modèle abstrait inclut les notions de variations et de transformations qui permettent la mise en oeuvre de modifications complexes.

Les  variations  sont utilisées par ERP5 pour représenter les possibles modifications d'une ressource donnée : par exemple : couleur, la taille, la vitesse etc...

ERP5 a la possibilité de gérer plusieurs variations pour une ressource donnée. Par exemple : un ordinateur peut être construit avec 128 Mo ou 256 Mo. La notion de variations permet avec une simple description de ressources et une collection de paramètres optionnels pour définir des millions de variations d'un produit sans créer des millions d'enregistrements dans la base de donnée et sans avoir à créer un numéro de produit pour chaque produit.

Le variantage permet de parer à toute complication induite par la législation de chaque pays.

Les variations sont très pratiquées dans les industries telles que : les ordinateurs (taille mémoire, taille disque dur, vitesse processeur), costumes (couleur et taille), bus (couleur, moteur, options)

Les variations sont particulièrement utilisées pour définir des ressources complexes résultant de

transformations successives. Chaque transformation est représentée comme une collection de transformations.

Une transformation est utilisée pour représenter une ressource complexe fabriquée à partir de la transformation de plusieurs ressources. Plutôt que de suivre un modèle hiérarchique, ERP5 utilise un modèle de diffusion.

Ainsi, afin de d'implémenter le choix d'une ressource, l'équivalence de ressources permet de définir une ressource parmi un groupe de ressources. L'équivalence de ressources est très utilisée pour implémenter l'équivalence de classes de ressources obtenues à partir de plusieurs sources.

Les transformations dans le modèle ERP5 sont instanciées par les causalités de mouvements réels entre noeuds. La seule causalité qui existe dans un processus de fabrication complexe est la causalité résultante de la définition d'une transformation. En particulier, le stock qui est un type de noeud n'a pas de causalité.

Le contenu du modèle ERP5

Le système ERP est une base de données de documents qui contient une collection de dossiers dont chacun implémente un module de gestion.

Chaque dossier contient une documentation autonome et éventuellement des sous- dossiers.

L'expérience de ERP5 est basée sur la métaphore d'un gros fichier avec beaucoup de feuilles dont chacune contient toutes les infos nécessaires pour décrire le type de transaction ou de gestion d'un document. Les documents sont comme des objets simples avec peu d'attributs. Des objets pourraient agir comme des conteneurs afin de tenir d'autres objets simples.

Il existe une relation entre la gestion du contenu du modèle ERP5 et le modèle abstrait de ERP5.

ERP5 fonctionne avec un serveur d'application ZOPE, donc il est nécessaire de connaître le fonctionnement de ce serveur.

Nous donnons ci-dessous le tableau de correspondance des documents ERP5 et les objets instanciés à partir des 5 classes.

Classes		Objets
NODE	N	Node	Amount	Profile	MetaNode
MOVEMENT	M	Movement	Delivery	Order	Transformations
RESOURCE	R	Resource	MetaRessource
PATH	P	Path
ITEM	I	Item	Container	Tracking

Avantages

L'ERP5 a l'avantage de n'utiliser que cinq classes qui représentent le modèle de classe. Avec ce modèle, ERP5 représente toute l'entreprise sauf le coté gestion de la clientèle ( CRM).

OFBIZ

Le projet Ofbiz a été lancé en 2001, suite à une demande client, pour offrir une solution eCommerce. Le modèle de données est basé sur une référence, the Data Model Resource Book. Lui même issu de très nombreuses expériences clients. Dés le départ, les composants catalogue, acteur et commande ont été conçus pour être extensibles et s'adapter à des environnements complexes. Au fur et à mesure que les besoins augmentent, l'apparition d'autres composants devient une nécessité : Stock, GPAO (Production Service et Projet ), comptabilité.

Ofbiz est écrit en java et utilise une approche entité-relation par soucis de simplicité et de généricité au niveau de la couche de données Entity Engine. Aux liaisons qui existent entre les différentes tables.

L'entité dans Ofbiz correspond aux tables d'une base de données. Les entités sont représentées par des classes dont le stéréotype est « entity ».

L'attribut dans Ofbiz correspond aux champs de la table. L'association correspond aux relations entre tables.

Ce modèle a l'inconvénient de s'attacher plus aux données qu'à la dynamique du système. Pour pallier à cet inconvénient, un projet nommé Néogia dont l'objectif est de fournir des outils de génération permettant de développer des applications Ofbiz à l'aide d'une modélisation UML dont l'avantage est d'avoir une vision globale de l'architecture du composant à créer.

Ofbiz intègre les modules de gestion suivants : Supply Resource Management (SCM), Customer Relationship Management (CRM),  Manufacturing Resource Planning (MRP), Content Management System (CMS), eCommerce .

OfBiz (Open for Business) est un progiciel métier de gestion d'entreprise. Il est orienté

e-commerce et est organisé suivant un modèle client/serveur. Son interface graphique est séparée de la partie métier et utilise une interface de type web dynamique.

Son architecture est de type modulaire. Ces composants sont réutilisables et un composant est le plus petit élément de l'architecture OfBiz. Un composant peut fournir un ensemble de ressources permettant de construire une application OfBiz. Les ressources peuvent être un jeu de données, un modèle de données, des services, une application web ou du code java. L'architecture de OfBiz est composée de plusieurs composants. Ces composants regroupés entre eux forment un progiciel de gestion intégré et sont classés en trois niveaux d'abstraction (le framework, les applications de base, et les applications de haut niveau).

Cette approche composant a permis une meilleure réutilisation des composants logiciels, un développement modulaire plus rapide. Ce type d'architecture permet aussi de remplacer un composant par un autre dans le cas où il existe plusieurs implémentations différentes.

Ofbiz se décompose en deux parties : le serveur et les composants.

Ø Le serveur, ou base, propose un environnement d'exécution homogène et performant pour les applications qu'il fait tourner. Il fournit tout un ensemble de mécanismes de gestion de cache et de pools de connexions qui permettent une meilleure montée en charge et une meilleure réactivité du système.

Ø Les composants, quant à eux, représentent les plus petites briques logicielles gérées par le serveur. Ils fournissent un ensemble de ressources permettant de construire tout ou une partie d'une application Ofbiz. Ces ressources peuvent être : un jeu de données, un modèle de données, des services, une application web. Un composant est en général spécialisé pour une fonctionnalité donnée.

Le composant composant Entity Engine se charge de la gestion des données de tous les autres composants Ofbiz. Les données sont représentées selon un modèle entité-relation compatible avec des bases de données relationnelles. Le principal objectif de ce composant est d'éliminer tout code spécifique à la persistance des données dans un système transactionnel. Les deux principales caractéristiques de ce composant sont :

L'accès aux données via une interface unique, le « GenericDelegator ». supporte l'accès transparent à plusieurs bases de données.

Le « GenericDelegator » est le coeur de l'Entity Engine. Il est considéré comme une interface qui permet d'effectuer des opérations de création, d'enregistrement, de suppression, de recherche et de mise en cache des données. Les définitions des entités sont lues au démarrage du serveur et ce dernier vérifie leur validité et leur cohérence par rapport aux bases de données sous-jacentes. Si des différences existent, l'Entity Engine peut créer automatiquement les tables, les champs et les relations manquantes.

Le Service Engine est l'équivalent de l'Entity Engine pour les traitements des composants Ofbiz. Il permet de lancer des services sans avoir besoin de connaître leur localisation et leur implémentation.

Le ControlServelet est l'élément clé de la communication entre les utilisateurs et les applications web Ofbiz. Il est implémenté selon le modèle MVC ( Modèle-Vue-Controleur).

L'architecture de OfBiz en composants est représentée ci-dessous.

Comptabilité Générale

Comptabilité Analytique

Comptabilité Tiers

Trésorerie

Gestion Commerciale

Gestion Maintenance

Employé-Ressource

Humaine

Gestion Projet

Relation Client

Relation Fournisseur

Gestion du Service

E-Commerce

Catalogue produit

Gestion d'Achat

Gestion de Production

Article

Acteur

Ordre

Stock

Tâche

Comptabilité

Commun

Contenu

Services

Entity

ECA

Workflow

J2EE Container

SGBD

Java OS

Sécurité

Composants applicatifs de base

Composants applicatifs techniques

Composants techniques de base

Architecture de OfBiz détaillée

Les principales entités de OfBiz qui permettent la modélisation pour chaque composant sont :

Ø Content ou Contenu gèrent les documents. Cette entité est utilisée pour enregistrer et manipuler les contenus généraux et les bases de connaissances. Cette entité inclut la séparation de l'information et l'organisation des données utilisées dans les structures comme les arbres, les listes ou les maps d'objets.

Ø Security ou Sécurité : Cette entité sert à contrôler l'accès aux données. Elle inclut les mots de passe, les logins et les permissions. La gestion plus complète de la sécurité est réalisée par l'entité « Party » permettant à un groupe d'utilisateurs de voir et modifier certaines données, à un autre d'interdire tout accès ou encore de ne lui autoriser qu'un accès en lecture.

Ø Party ou Acteur : Cette entité peut représenter une personne, un groupe (entreprise, fournisseur, client ...). Un acteur a un rôle (client, fournisseur, employé etc...).

Type d'acteur

Groupe d'acteurs

Personne

Nom de la société

Raison sociale

NINIEA

------

Nom, Prénom

Adresse

Profession

--------------

Rôle d'acteur

Client

Fournisseur

Fournisseur

Organisation des acteurs

Un type de données en relation avec « Party » est le mécanisme des numéros de téléphone, adresses de courriels ou les URL.

Ø Product ou Produit : Cette entité contient les informations sur les produits (biens et services) commercialisés ou utilisés dans l'entreprise. Les biens peuvent être des matériaux bruts, des produits semi-finis ou finis. Product définit un produit et non l'instance d'un produit.

Pour cela il y a les éléments d'inventaire ou éléments du stock. Ceux-ci indiquent où un produit est entreposé, le statut du produit et un numéro de série ou une quantité disponible et une quantité dans le stock.

La figure suivante montre les relations entre les produits.

Types d'articles

Produits finis

Produits immatériels

Services

Matière première

Sous-ensemble

Mots-clef

Catégories

Références

Contenu

Emplacements

Stock

Magasins de stock

Caractéristiques

Attributs

Articles associés

Fig : Organisation des produits

Un produit peut être organisé en catégories ou en nomenclatures. Il peut appartenir à une catégorie et une catégorie peut être membre d'une catégorie mère. Un produit peut aussi être associé avec un autre pour donner des packages ou des variantes.

Les catégories de produits peuvent être associées à différents catalogues. Un catalogue de produit est un point de départ pour toutes les informations sur un ensemble de produits à commercialiser.

Plusieurs produits peuvent être associés à un produit comme peuvent l'être les coûts. Différents prix peuvent être définis pour différentes monnaies, différents stocks ou magasins et pour différentes périodes de l'année (période normale et période des fêtes de Noël pour les jouets par exemple).

Ø Order ou Commande : Cette entité permet de gérer les ventes et les achats et toutes les

informations relatives à une commande. Elle permet aussi la gestion des retours de marchandises.

Une demande pour un produit peut être suivie et être éventuellement transformée en nécessité qui peut être utilisé pour créer un « Work Effort » défini ci-dessous, qui va satisfaire le besoin. La demande faite, une demande de confirmation peut être établie qui, une fois acceptée par le client, peut être utilisée pour créer une commande. Une fois la requête satisfaite, une facture peut être créée à partir de la commande. Les factures font partie de la comptabilité (entité Accounting).

Une commande consiste en un entête et des lignes qui décrivent les détails et les ajustements (taxes, frais de ports, réductions et autres).

Type d'ordre

Vente/atcat

Suivi statut avec

le workflow

Paiement

- Compte client

- mode paiement

Lignes d'ordre

- Statut

- Calcul du prix

- Promotions

- Quantité

- .......

Acteur

- coordonnées

- destinataires

Expéditions

- Dates

- Transporteur

- conditions

Gestions des ordres

Réf. ordre n° xxx

Statut

date

Facturation-Paiement

Mode de paiement xxx

Acteurs

Coordonnées livraison

Données d'ordre commercial

Expédition

Transporteur

Condition

Date

Lignes d'ordres

Article Statut Quantité Prix Solde total

xxx xxxx 1 99

Total ligne

Frais d'expédition

999

99

TVA

99

Gestion des Ordres

Facility ou contact : peut être un bâtiment ou un emplacement physique ( stocks, magasins, docks, bureaux, pièces de bâtiments ). Un facility aura un contact associé comme une adresse et un numéro de téléphone.

Ce composant gère aussi la gestion dynamique des stock tel que l'inventaire, les mouvements de stock. L'inventaire du stock est réalisé par un ajustement des quantités réelles pour chaque ligne de stock.

Ø Shipment ou Expédition : Cette entité gère les réceptions et les expéditions ainsi que les entrées et sorties de stock. Un Shipment est composé de ShipmentItem, chacun représentant une certaine quantité d'un produit à expédier. Shipment fait aussi le lien avec les services des transporteurs pour le suivi des colis et des livraisons.

Ø Accounting ou comptabilité : Cette entité est organisée par date et sur les principes sur la comptabilité analytique et le plan comptable.

Clients

Compte client

Commande

Expédition

Acteurs

Rôle :

- Facture

-

Facture

Paiement

Limite de crédit

Terme de paiement

Coordonnées

Gestion de la Comptabilité

Ø Marketing : Permet de suivre les campagnes de marketing et les informations reliées tels les contacts (courriels, listes de diffusions ou téléphoniques).

Ø Work Effort ou Tâche : Elle est une tâche, une phase d'un projet, quelque chose à faire et même, une gamme (un processus semi-automatique qui implique des activités automatiques réalisées par la machine et manuelles réalisées par une personne ou par un dispositif externe contrôlé par une personne) ou une activité d'une gamme.

Une gamme est un type particulier de « Work Effort ».

Stock Stock

OF : ordre de fabrication

Découpe

Perçage

Assemblage

Sortie de composant entrée de l'article fabriqué Nomenclature

Lancement

o manuel

o proposition du MRP

(organisation des ressources industrielles )

GAMME DE FABRICATION

calendrier

Gestion de gamme

Ø Human Ressources ou Ressources humaines : Cette entité permet de gérer et de suivre les responsabilités, les compétences, salaires et autres informations en relation avec la gestion du personnel.