Quelle entreprise gère des millions d’articles?
En règle générale, l’ERP permet à une entreprise de suivre l’ensemble de ses activités et en particulier de ses produits. Si il n’est pas rare d’avoir des millions de clients, des millions de commandes, il est beaucoup plus rare d’avoir des millions d’article dans son catalogue de produits.
Généralement, ce sont les distributeurs qui sont confrontés à cette problématique. Mais avec une offre de place de marché qui se développe chez de plus en plus d’entreprise, cette problématique est en passe de se diffuser chez de plus en plus d’acteurs.
Quels produits importer dans son ERP?
Tous les articles à la vente doivent être facilement disponibles dans l’ERP pour être en capacité de faire une vente quitte à le commander dans la foulée chez un fournisseur, voire à mettre en place une solution de drop shipping qui va permettre de livrer directement le client sans passer par ses entrepôts.
Aussi un distributeur va facilement avoir besoin de gérer un catalogue de plusieurs millions de produits pour être en capacité à répondre à la demande de ses clients. Pour constituer cette base de données, il va devoir intégrer en continue des informations des fournisseurs avec lesquels il travaille et avoir une solution pour synchroniser en continue les produits et les prix.
Automatiser l’intégration des produits.
Pour alimenter l’ERP, les fournisseurs avec lesquels un grossiste travaille vont lui fournir la liste à jour de leurs produits soit sous forme de fichier (généralement au format CSV) soit sous forme de Webservices. A charge donc pour le distributeur d’avoir une solution pour intégrer ces informations dans son outil manuellement ou via des programmes « automatiques ».
Principales difficultés pour l’intégration
Les formats sont différents pour chaque fournisseur
S’il est est possible d’utiliser des normes pour les échanges d’information et de mettre en place des échanges électroniques automatiques (EDI), de nombreux échanges se font selon des protocoles non normés qui nécessitent de paramétrer les échanges partenaire par partenaire.
Pour résoudre cette difficulté, certains acteurs peuvent jouer le rôle d’intégrateur et fournir des flux d’information selon un format unique ce qui facilite l’intégration. Ce sont par exemple des solutions mise en place au sein d’une industrie pour faciliter les échanges.
Une autre solution est de définir son propre format pivot capable de couvrir les différents cas de figure. techniquement, on peut par exemple créer un format de type CSV avec des en-têtes de colonnes définis et développer un programme d’import avec des règles de gestion (colonnes obligatoires, contrôle de cohérence, …). Il faut ensuite mettre en forme les fichiers reçus selon ce format en adaptant les en-têtes des fichiers reçus. Important, le programme d’importation doit prendre en compte les en-têtes des colonnes et non leur numéro de colonne.
Les produits n’ont pas d’identifiant unique
L’utilisation de codes barre obtenus par des organismes de normalisation (EAN par exemple) est de nature à garantir une unicité des produits. Malheureusement, la présence de code barre n’est pas systématique. Par ailleurs, certains code barre sont générés directement par le fournisseur (unicité au sein du fournisseur) sans recours à un organisme de normalisation et peuvent conduire à des problèmes d’unicité.
Il est donc souvent nécessaire de reconstruire une clef d’unicité pour identifier chaque produit. Pour cela, on peut utiliser un couple d’information Fabricant / Référence Unique chez le Fabricant.
Il faut donc avoir des mécanismes dédiés pour:
- gérer les identifiants unique, les construire si nécessaire
- rapprocher les produits à partir de règles de priorité (code barre, code fournisseur, …)
Le prix est difficile à obtenir
Les informations fournies sont soit des prix d’achat auprès du fournisseur, soit des prix de vente (Prix Public Conseillé). Il faut choisir une référence commune à l’ensemble du système, c’est souvent c’est le prix de vente qui est le meilleur choix pour un distributeur; en particulier si l’entreprise a plusieurs fournisseurs pour le même produit, le prix de vente (Prix Public Conseillé) peut servir de base commune pour les calculs des prix d’achat, avec des conditions d’achat différentes.
Dans certains cas, le distributeur reçoit de son fournisseur un prix d’achat accompagné du prix de vente (Prix Public Conseillé)
On doit alors construire des règles pour passer d’un prix de vente à un prix d’achat ou inversement d’un prix d’achat à un prix de vente. Pour cela, on utilise des règles avec des coefficients pour garantir une marge.
Il y a donc de nombreux calculs à effectuer à chaque nouvel import de fichier:
- Préparation des prix de vente avec des dates d’effet (date de début et date de fin)
- Création des variables pour les coefficients permettant de passer du prix de vente au prix d’achat ou inversement
- Préparation des prix d’achat auprès du fournisseur.
Illustration avec l’ERP Odoo
Odoo est une fantastique boite à outils qui peut être personnalisée pour fonctionner avec un gigantesque catalogue de distributeur. Comme la plupart des systèmes modernes, Odoo fonctionne avec une gestion d’Objets Relationnels (ORM) synchronisé avec une base de données PostgreSQL. Ces objets doivent être créés et mis à jour en fonction des imports.
La base de données PostgreSQL n’est pas le facteur limitant car elle peut gérer d’énormes quantités de données représentant les objets. Par contre, le modèle objet Odoo est en charge de créer, valider et synchroniser les objets avec plusieurs facteurs limitants:
- stocker temporairement en mémoire les objets
- vérifier toutes les règles sur les champs (présence, nature, longueur, …)
- vérifier toutes les règles de dépendance des objets liés
- assurer que les instructions sont bien exécutée dans une seule transaction avec un rollback possible en cas de problème
Atout 1 : Travailler en batch, en asynchrone
Pour soulager les traitements, notamment pour éviter de traiter les informations de plusieurs dizaines ou centaines de milliers d’articles, il convient de réduire la complexité:
- les informations sont séparées en plus petits batch (1000 articles par exemple)
- le traitement est traité en asynchrone
Les traitements en asynchrone peuvent en particulier être envoyés à un serveur dédié à des traitements lourds pour ne pas impacter le travail des utilisateurs.
Réalisation technique
Pour intégrer dans Odoo, on peut utiliser des modules Open Source existants. Queue Job offre la possibilité d’avoir un serveur dédié aux traitements lors en asynchrone; on utilise des batch de 1000 produits construits à partir des fichiers importés.
Atout 2 : Mettre en place des requêtes en SQL
Après chaque nouvel import, il y a des informations qui doivent être mises à jour à partir de calculs (comme par exemple la conservation des marges entre le prix de vente et le prix d’achat). L’ORM n’est pas nécessairement performant pour exécuter des mises à jour en parcourant tous les objets.
Réalisation technique
Comme PostgreSQL le permet, il est possible d’imbriquer des requêtes (recursive queries) afin de faire une première passe pour sélectionner les information et une deuxième pour faire une mise à jour. L’exemple suivant illustre une mise à jour des prix de vente à partir des prix d’achat en une seule requête:
query = sql.SQL("""
WITH partner_planned AS (
SELECT product_price.id as product_price_id, product_supplierinfo.id,
product_supplierinfo.product_tmpl_id, product_supplierinfo.min_qty,
product_supplierinfo.date_start,
product_supplierinfo.price AS buy_price,
brand_discount.percent_rate AS rate
from product_supplierinfo
INNER JOIN product_price
ON product_supplierinfo.product_tmpl_id = product_price.product
AND product_supplierinfo.date_start = product_price.date_start
INNER JOIN product_template
ON product_template.id = product_supplierinfo.product_tmpl_id
INNER JOIN brand_discount
ON brand_discount.id = product_template.brand_discount_id
WHERE brand_discount.id IN %(discount_ids)s
AND brand_discount.based_on_sell_price = False
FOR UPDATE NOWAIT
)
UPDATE product_price
SET price = ROUND( (100.0 + rel.rate) / 100.0 * rel.buy_price, 2 )
FROM partner_planned rel
WHERE product_price.id = rel.product_price_id
""")
self.env.cr.execute(query, {'discount_ids': tuple(discounts.ids)})Atout 3 : Planifier les traitements
Pour intégrer les mises à jour, il est fréquent que les partenaires mettent à disposition les informations en libre service : dossier FTP pour aller chercher les informations, Webservice à interroger, … Il convient donc d’aller fréquemment chercher les nouvelles informations pour mettre à jour l’ERP.
Réalisation technique
Odoo intègre une gestion de tâche planifiées (Cron task) qui peut être lancée en fonction du temps de rafraichissement des informations (toutes les 5 minutes, tous les jours). Il suffit donc de créer un script pour transformer les information reçues, d’ajouter un moyen de se s’authentifier et de se connecter chez le partenaire et de planifier la tâche.
Conclusion
Plusieurs implémentations de systèmes Odoo avec des millions d’articles, des dizaines de millions de prix ont été réalisées par des mission réalisées par le cabinet Belgalli.
(missions de conseil pour des distributeurs et des grossistes)
L’utilisation des principes exposés ici permet d’affirmer qu’il est possible de travailler avec des volumétries énormes dans un ERP. Le fait de s’appuyer sur Odoo offre l’avantage de bénéficier d’une formidable boite à outils et de ne pas devoir développer un système entier « du sol au plafond » ni de devoir accéder à des « super calculateurs » mais travailler avec d’extraordinaires volumétries nécessite d’utiliser une sorte de « secret sauce »
