Le projet en un coup d’œil
Une commande pouvait être consultée seule, mais il manquait un parcours simple pour retrouver un partenaire puis parcourir ses achats dans leur ordre opérationnel.
Ciama collecte les partenaires qualifiés comme fournisseurs, conserve leur identité externe par compte et les rend accessibles depuis une recherche dédiée.
Chaque fiche ouvre un historique paginé avec statut d’achat, état de livraison, date, montant converti, nombre de lignes et accès au détail.
Un cycle de réapprovisionnement ne commence pas dans une courbe de stock. Il dépend aussi de partenaires réels et de commandes d’achat déjà engagées. Pour comprendre où en est l’approvisionnement, l’équipe doit pouvoir partir d’un fournisseur, retrouver les achats associés et ouvrir rapidement l’objet qui porte le statut, la date ou le montant à contrôler.
Ciama disposait progressivement des partenaires issus d’Odoo puis des commandes fournisseur et de leurs lignes. Dawap a transformé ces objets séparés en un parcours cohérent : un annuaire limité au compte connecté, une recherche par nom, une identité externe conservée et une fiche fournisseur qui présente son historique d’achats du plus récent au plus ancien.
Ce projet constitue une fondation concrète du réapprovisionnement marketplace. Il ne décide pas combien commander et ne note pas les fournisseurs. Il rend la relation entre le partenaire ERP et les commandes déjà présentes dans Ciama assez claire pour que les équipes contrôlent l’engagement avant de piloter la réception.
1. Ciama, le produit Dawap qui relie ERP, achats et opérations
Donner une identité durable au fournisseur avant d’agréger son activité
Ciama Marketplace est développé par Dawap pour réunir les opérations d’un vendeur multicanal : commandes, offres, stocks, produits, fournisseurs et achats. Dans cette chaîne, le partenaire fournisseur ne peut pas rester un simple texte répété sur chaque commande. Il doit devenir une entité retrouvable, protégée par le compte et reliée aux achats qui lui appartiennent.
La source actuellement prise en charge pour cette collecte est Odoo, dans sa version 19 ou dans la version déclarée comme la plus récente. Ciama interroge les partenaires dont le rang fournisseur est supérieur à zéro et récupère leur identifiant, leur nom ainsi que plusieurs informations de contact dans la réponse source.
Le périmètre conservé comme référentiel opérationnel est volontairement plus étroit : identifiant Ciama, compte, fournisseur de données, connexion utilisée, nom, identifiant externe, état actif et date de mise à jour. Les coordonnées reçues ne sont pas exposées dans l’annuaire du back-office décrit ici.
Cette distinction protège la qualité du récit et celle du produit. Une donnée accessible dans une réponse ERP n’est pas automatiquement une fonctionnalité utilisée. Le projet prouve le rapprochement fournisseur-achats ; il ne transforme pas des champs techniques disponibles en promesses commerciales non livrées.
2. Construire le référentiel par incréments vérifiables
De l’annuaire initial à une synchronisation Odoo cadrée dans le temps
Le premier annuaire fournisseurs apparaît le 11 novembre 2025. Le 6 mars 2026, le parcours s’enrichit de la fiche fournisseur et de la liste des commandes associées. Entre le 7 et le 11 mars, la collecte est restructurée autour des connexions et des capacités actives ; le 17 mars, la présentation du centre fournisseurs est complétée.
Le 18 juin 2026, la gestion des fenêtres temporelles Odoo est normalisée. Cette dernière étape rend cohérente la sélection des partenaires modifiés entre deux bornes et fixe la date de référence publique de cette version du projet.
La synchronisation courante part des connexions dont la capacité fournisseurs est activée. Elle écarte une connexion inactive ou dont les identifiants n’ont pas été validés, puis vérifie que le fournisseur de données est actif, disponible, de type ERP et identifié comme Odoo.
Une reprise historique complète le fonctionnement courant. Elle découpe une période demandée en intervalles traités du plus récent au plus ancien et journalise un parent ainsi que ses sous-traitements. Le référentiel peut ainsi être initialisé sur une profondeur choisie sans confondre le rattrapage avec la collecte des changements récents.
3. Avant le référentiel : retrouver un achat sans vue partenaire
Une commande identifiable, mais pas encore un historique fournisseur
Les achats peuvent être consultés individuellement, mais une équipe travaille rarement sur une commande isolée. Elle cherche aussi à savoir si le même fournisseur porte d’autres commandes, quels statuts se répètent et quelles échéances composent la relation en cours. Sans point d’entrée partenaire, cette lecture demande de filtrer et de rapprocher manuellement les résultats.
Le nom seul ne suffit pas à fiabiliser ce rapprochement. Il peut évoluer dans l’ERP, être orthographié différemment ou ressembler à celui d’une autre entité. L’identifiant externe Odoo constitue le repère stable qui permet de reconnaître le même partenaire au fil des synchronisations.
Le contexte du compte est tout aussi important. Plusieurs organisations peuvent exploiter Ciama avec leurs propres connexions ERP. Un même identifiant numérique Odoo n’a de sens qu’à l’intérieur de la bonne source et du bon compte ; le réutiliser sans cette frontière créerait des rapprochements dangereux.
Le projet devait donc résoudre trois problèmes simples mais structurants : collecter les partenaires réellement qualifiés comme fournisseurs, leur attribuer une identité durable dans Ciama et ouvrir depuis chacun d’eux la liste exacte des achats qui lui sont rattachés.
4. Faire du fournisseur un objet opérationnel de Ciama
Retrouver, qualifier et parcourir sans créer un CRM achats fictif
Le premier objectif était de rendre les fournisseurs consultables dans un annuaire dédié. Une recherche par nom et un classement alphabétique devaient permettre de retrouver rapidement un partenaire, même lorsque le compte en comporte plusieurs dizaines ou centaines.
Le deuxième objectif consistait à préserver le lien avec Odoo. Chaque entrée devait conserver l’identifiant externe, le fournisseur de données et la connexion qui l’a alimentée. La synchronisation pouvait alors mettre à jour le même objet au lieu d’ajouter un doublon à chaque passage.
Le troisième objectif était de relier le partenaire à son activité d’achat réelle. La fiche fournisseur devait filtrer les commandes par compte et par fournisseur, les classer par date décroissante et laisser l’utilisateur ouvrir le détail qui fait foi.
Enfin, le projet devait rester fidèle à son périmètre. Il ne s’agissait ni d’un portail de négociation ni d’un score de performance fournisseur. Aucun délai contractuel, contact opérationnel, condition de paiement ou minimum de commande n’est utilisé pour recommander une décision.
5. Sélectionner les partenaires fournisseurs dans Odoo
Une règle source explicite plutôt qu’une liste importée sans critère
La collecte interroge le modèle des partenaires Odoo et retient ceux dont le rang fournisseur est strictement positif. Ce critère sépare les partenaires reconnus par l’ERP comme fournisseurs des contacts qui n’ont pas ce rôle dans le cycle d’achat.
Pour chaque résultat, la réponse contient l’identifiant Odoo, le nom, les téléphones, l’adresse électronique, le numéro de TVA, la nature personne ou société et l’indicateur fournisseur. Ces champs constituent la matière reçue par le connecteur, mais seule une partie alimente aujourd’hui l’entité consultable dans Ciama.
Le nom et l’identifiant externe sont obligatoires pour créer une entrée. Un résultat sans identifiant n’est pas traité ; un nom vide provoque un refus explicite lors de l’ajout ou de la mise à jour. Ces deux garde-fous évitent de fabriquer une fiche impossible à reconnaître ou à synchroniser ensuite.
La collecte est paginée côté Odoo. Elle poursuit les lectures tant qu’une page complète est retournée, puis s’arrête sur la première page incomplète ou vide. Le référentiel n’est donc pas limité à la taille visible de l’annuaire web : pagination de collecte et pagination de consultation remplissent deux rôles différents.
6. Reconnaître le même fournisseur à chaque synchronisation
Associer compte et identifiant externe avant de choisir ajout ou mise à jour
Lorsqu’un partenaire arrive depuis Odoo, Ciama recherche d’abord une entrée qui partage le compte et l’identifiant externe. Si aucune n’existe, un nouvel identifiant interne est créé. Si elle existe, l’objet est mis à jour en conservant sa continuité dans le produit.
Cette clé de rapprochement évite de dépendre du nom. Un changement de raison sociale ou une correction typographique peut être répercuté sur la fiche existante sans casser les liens déjà construits avec les commandes fournisseur.
La fiche conserve également la connexion et le fournisseur de données associés. Cette information prépare le diagnostic lorsqu’un partenaire ne se met plus à jour : l’équipe peut relier l’objet consulté à la capacité de synchronisation qui l’alimente.
L’ajout comme la mise à jour passent par un traitement asynchrone. La collecte compte les partenaires lus, les créations demandées et les mises à jour demandées, tandis que chaque objet suit ensuite son propre traitement. Ce découpage évite qu’un fournisseur isolé transforme tout le lot en opération monolithique.
7. Limiter la collecte courante aux changements récents
Une fenêtre glissante de deux heures et une reprise historique séparée
Lorsque la commande planifiée est déclenchée, elle construit une fenêtre allant de l’instant courant aux deux heures précédentes. Odoo filtre alors les partenaires sur leur date de modification, bornée de chaque côté, et les renvoie du plus récemment modifié au plus ancien.
Ce chevauchement temporel privilégie la continuité : une modification proche d’une exécution peut être revue au passage suivant sans créer de doublon, puisque l’identité compte-identifiant externe décide ensuite entre ajout et mise à jour.
La collecte ne démarre que pour une capacité suppliers_sync active. Elle vérifie ensuite la connexion, ses identifiants, le statut du fournisseur de données, son type ERP, son identité Odoo et la version prise en charge. Une configuration incomplète est écartée avant l’appel distant.
Pour initialiser ou réparer une période plus longue, une commande historique accepte des bornes et un pas de découpage. Elle produit des intervalles du plus récent au plus ancien, crée une trace globale puis une trace pour chaque intervalle. Cette séparation rend le rattrapage explicite sans modifier la logique du flux courant.
Partenaires dont le rang fournisseur est positif
Capacité active et identifiants validés
Compte plus identifiant externe stable
Nom, activité, source et mise à jour
Commandes filtrées puis ouvertes dans leur détail
8. Retrouver un fournisseur dans un annuaire limité au compte
Recherche par nom, ordre alphabétique et cinquante résultats par page
L’écran principal présente cinquante fournisseurs par page et les classe par nom croissant par défaut. L’utilisateur peut inverser cet ordre ou rechercher une suite de caractères dans le nom. Le nombre de résultats affichés et le total du compte accompagnent la pagination.
Chaque ligne montre le nom, l’état actif et la date de dernière mise à jour. Le tableau possède aussi des emplacements pour le nombre d’achats, les totaux hors taxes, l’encours, les opportunités, le pays et la devise lorsque ces informations ont effectivement été alimentées.
Ces colonnes secondaires ne sont pas utilisées comme preuve de performance dans cette étude. Le flux fournisseurs actuel synchronise l’identité, l’activité et la source ; il ne recalcule pas lui-même les agrégats financiers. Les afficher ne suffit donc pas à garantir leur fraîcheur sur chaque installation.
L’action proposée depuis l’annuaire est volontairement simple : ouvrir la fiche. Il n’existe pas dans ce parcours de bouton pour noter un partenaire, modifier ses conditions ou déclencher une commande. Le référentiel sert à retrouver et contextualiser avant d’entrer dans l’achat concerné.
9. Ouvrir une fiche fournisseur sobre et traçable
Nom, identifiant externe, activité puis commandes associées
La fiche reprend le nom du fournisseur, son identifiant externe Odoo et son état actif. Ces trois informations suffisent à confirmer que l’utilisateur consulte le bon partenaire avant de parcourir ses achats.
Le choix d’une en-tête concise évite de simuler une fiche relation fournisseur complète. Les adresses, contacts, conditions, délais et documents contractuels ne sont pas présentés alors que le référentiel ne les exploite pas encore comme données métier fiables.
Sous cette identité, Ciama exécute une recherche de commandes avec deux contraintes systématiques : le compte connecté et l’identifiant interne du fournisseur. La relation n’est donc pas reconstruite à partir d’un nom ressemblant ; elle utilise le lien enregistré sur l’achat.
Une URL portant l’identifiant d’un autre compte est refusée. La vérification intervient avant la recherche des commandes, ce qui empêche à la fois d’afficher le partenaire et d’interroger son historique.
10. Parcourir jusqu’à cent commandes par page
Les achats les plus récents d’abord, avec les deux dimensions de statut
L’historique fournisseur présente cent commandes par page et les ordonne par date d’achat décroissante. L’utilisateur commence ainsi par les engagements les plus récents, puis peut naviguer dans les pages ou modifier le tri sur la date, le nom ou le montant.
Chaque ligne affiche le nom de la commande, son statut d’achat et son statut de livraison. Ces deux statuts restent séparés : une commande confirmée peut suivre un cycle logistique distinct, et une livraison terminée ne signifie pas la même chose qu’un achat annulé.
La date d’achat, le montant TTC converti et le nombre de lignes complètent la lecture. Le montant converti facilite une comparaison dans l’interface, mais la fiche ne le présente pas comme un coût produit, une marge ou une valorisation du reliquat encore à recevoir.
Le dernier élément est l’accès au détail de la commande. C’est là que l’utilisateur retrouve les lignes et les informations qui font foi. La fiche fournisseur reste un index contextualisé : elle accélère le passage du partenaire à l’achat sans dupliquer l’édition de la commande.
11. Protéger le référentiel à trois niveaux
Compte dans la collecte, compte dans la recherche et contrôle sur la fiche
La première frontière est créée lors de la synchronisation. Le compte vient de la connexion ERP activée, et la recherche d’un fournisseur existant associe systématiquement ce compte à l’identifiant externe Odoo.
La deuxième frontière se trouve dans l’annuaire. Le filtre de compte est ajouté par le serveur à chaque recherche ; il ne dépend pas d’un paramètre choisi dans le navigateur. La pagination et le total sont calculés sur ce même périmètre.
La troisième frontière protège la fiche. Après avoir chargé le fournisseur demandé, Ciama compare son compte à celui de l’utilisateur. En cas d’écart, l’accès est refusé avant toute construction de l’historique.
Enfin, la recherche des commandes répète les filtres de compte et de fournisseur. Cette redondance utile évite de considérer le contrôle de la fiche comme une permission implicite sur une requête plus large. Chaque étape conserve son propre périmètre explicite.
12. Les arbitrages qui rendent la preuve crédible
Préférer une base étroite et exacte à une fiche fournisseur décorative
Le premier arbitrage est de ne pas confondre données reçues et données exploitées. Odoo peut renvoyer courriel, téléphone, mobile ou TVA ; le référentiel présenté ici ne les transforme pas encore en carnet de contacts. Le projet se concentre sur ce qui est réellement utilisé.
Le deuxième est de garder l’achat comme objet de référence. Les statuts et montants ne sont pas copiés dans une mémoire fournisseur parallèle. Ils sont recherchés à la consultation, puis l’utilisateur ouvre la commande pour vérifier ou corriger le détail.
Le troisième est de séparer le référentiel du moteur de réapprovisionnement. Connaître les achats d’un fournisseur n’autorise pas à calculer une quantité à commander : ventes, stock, horizon et règles logistiques relèvent d’un autre projet Ciama.
Le quatrième est de ne pas convertir les colonnes disponibles en score. Le nombre de commandes ou le montant cumulé ne mesure pas la ponctualité, la qualité ou la fiabilité d’un fournisseur. Une véritable notation demanderait des définitions, des événements et une période de référence supplémentaires.
13. Documenter les limites avant d’étendre le produit
Aucun délai, minimum d’achat ou fournisseur alternatif inventé
La fiche ne connaît pas le délai contractuel du fournisseur. Elle montre les dates portées par les commandes, mais ne calcule ni délai moyen observé ni promesse de livraison future. Ces notions ne doivent pas être déduites d’une simple chronologie d’achats.
Elle ne stocke pas non plus de minimum de commande, de condition de franco, de palier tarifaire ou de condition de paiement dans le périmètre présenté. Le réassort ne peut donc pas être validé automatiquement à partir de cette seule vue.
Aucune relation de fournisseur principal ou alternatif par produit n’est exposée. La liste des commandes montre ce qui a été acheté à ce partenaire ; elle ne prouve pas qu’il est le meilleur, le seul ou le prochain fournisseur possible pour chaque référence.
Enfin, les agrégats visibles dans l’annuaire dépendent d’une alimentation distincte de la collecte des partenaires. Tant que leur calcul de bout en bout n’est pas démontré sur l’installation, la preuve commerciale reste centrée sur l’identité, l’activité, la date de mise à jour et l’historique filtré.
14. Ce qui change pour la revue des achats
Moins de recherche dispersée, davantage de contexte avant l’action
L’équipe dispose d’un point d’entrée stable pour retrouver un partenaire. Elle n’a plus besoin de partir d’un numéro de commande déjà connu : une recherche partielle sur le nom suffit à ouvrir la bonne fiche, puis l’identifiant Odoo confirme l’identité.
L’historique recentre ensuite la revue. Les achats récents apparaissent en premier avec leur double statut, leur date, leur montant et leur nombre de lignes. Une anomalie peut être qualifiée avant d’ouvrir le détail, sans perdre la relation fournisseur.
Le parcours améliore aussi la continuité des synchronisations. Un nom modifié dans Odoo met à jour le fournisseur reconnu par son identifiant externe au lieu de fragmenter l’historique sous plusieurs libellés. Les commandes restent rattachées au même objet interne.
Enfin, les frontières fonctionnelles deviennent plus claires. Le référentiel répond à « qui fournit et quels achats lui sont liés ? ». Le Planner répond à « quelle demande préparer ? ». Le Purchase Pipeline répond à « qu’est-ce qui reste en cours de réception ? ». Cette séparation réduit les interprétations erronées.
15. Le scénario terrain qui résume le projet
Retrouver toutes les commandes récentes d’un partenaire avant une relance
Une équipe constate qu’une commande fournisseur mérite une vérification, mais elle veut d’abord savoir si d’autres achats récents concernent le même partenaire. Elle ouvre l’annuaire et recherche une partie de son nom.
La ligne trouvée confirme l’état actif et la dernière mise à jour. L’équipe ouvre la fiche, compare l’identifiant externe avec sa référence Odoo puis parcourt les commandes classées de la plus récente à la plus ancienne.
Les statuts d’achat et de livraison permettent de distinguer une commande engagée d’une livraison déjà terminée ou d’un achat annulé. Le nombre de lignes et le montant converti donnent assez de contexte pour sélectionner la commande à examiner, sans être confondus avec un score fournisseur.
L’utilisateur ouvre enfin le détail de l’achat concerné. Toute correction reste attachée à cette commande et à ses lignes. Lors de la consultation suivante, la fiche fournisseur retrouve ces mêmes objets ; aucun tableau parallèle n’a dû être rapproché manuellement.
16. Relier le référentiel au cycle complet de réassort
Préparer la demande, suivre l’achat puis contrôler la réception
Le Replenishment Planner marketplace intervient en amont. Il projette une demande depuis les ventes et le stock, sans utiliser de délai ou de minimum fournisseur absent de ses données.
La présente fiche apporte l’identité du partenaire et le parcours de ses achats. Une fois la commande engagée, le Purchase Pipeline Command Center agrège les commandes ouvertes, les montants, les quantités reçues, les échéances et les produits encore attendus.
Après la réception, l’analyse du stock entrepôt permet de contrôler la disponibilité observée et le risque de rupture. Chaque projet traite ainsi une étape différente au lieu de prétendre qu’un écran fournisseurs couvre toute la chaîne.
Enfin, l’intégration API Odoo replace ce référentiel dans son architecture : connexion validée, sélection des objets, fenêtres de synchronisation, identité externe et reprise historique. C’est cette continuité technique qui rend la lecture métier durable.
17. Conclusion
Un bon référentiel commence par une relation que l’on peut expliquer
Ce projet ne cherche pas à impressionner avec une fiche fournisseur surchargée. Il résout une relation essentielle : un partenaire qualifié dans Odoo devient un fournisseur stable dans Ciama, puis sa fiche ouvre uniquement les commandes rattachées au bon compte et au bon objet.
La valeur tient autant aux choix qu’aux fonctionnalités. Le nom ne sert pas de clé, les comptes restent séparés, la synchronisation courante et l’historique ont deux parcours distincts, et les informations non exploitées ne sont pas présentées comme des capacités livrées.
Cette base renforce notre accompagnement en réapprovisionnement marketplace : connaître le fournisseur, retrouver ses achats, suivre ce qui reste à recevoir puis vérifier le stock revenu disponible, avec une preuve claire à chaque étape.
