Le projet en un coup d’œil
Les statuts d’achat, les livraisons, les lignes produit et les montants devaient être rapprochés pour comprendre l’engagement encore ouvert.
Ciama agrège commandes ouvertes, valeur convertie, retards, progression des réceptions, fournisseurs et produits encore attendus.
Les listes courtes font émerger les prochaines échéances et les plus gros volumes en attente sans créer un second registre de tâches.
Entre une décision de réassort et le retour du stock disponible, plusieurs réalités coexistent : la commande fournisseur est ouverte, une partie de la marchandise peut avoir été reçue, certaines lignes possèdent une date estimée et d’autres commandes ont déjà dépassé leur date sans être clôturées. Une simple liste d’achats ne suffit pas à donner une vue juste de cet entre-deux.
Ciama centralisait déjà les fournisseurs, les commandes d’achat et leurs lignes produit. Dawap a créé le Purchase Pipeline Command Center pour répondre à une question opérationnelle : que reste-t-il réellement en cours ? La page calcule les engagements ouverts, rapproche quantités commandées et reçues, classe les produits encore attendus et met en avant les échéances.
Cette brique de réapprovisionnement marketplace ne fabrique pas un workflow artificiel d’alertes et d’assignations. Elle transforme les objets d’achat existants en lecture commune, puis renvoie vers la commande ou le fournisseur pour agir à la source.
1. Ciama, le produit Dawap qui relie ventes, stock et achats
Suivre le réassort après la décision et avant la remise à disposition
Ciama Marketplace est développé par Dawap pour réunir les opérations d’un vendeur multicanal : catalogue, offres, commandes clients, stocks, fournisseurs et achats. Le réapprovisionnement traverse plusieurs de ces domaines, mais chaque étape doit conserver sa propre responsabilité.
Le Replenishment Planner prépare un volume de demande à partir des ventes récentes. Le Purchase Pipeline intervient après l’arbitrage : une commande fournisseur existe, possède une date, un statut d’achat, un statut de livraison, un montant converti et des lignes de marchandise. C’est ce changement d’état qui justifie un projet distinct.
Chaque ligne peut porter un produit, une quantité commandée, une quantité livrée, une valeur convertie et une date estimée de réception. Au niveau de la commande, le fournisseur et les statuts donnent le contexte. Le command center agrège ces deux niveaux sans remplacer les fiches détaillées.
Le besoin n’était donc pas de créer une nouvelle base d’actions. Il consistait à rendre les engagements existants lisibles au premier regard : combien de commandes restent ouvertes, quelle valeur elles représentent, quelle part des unités a été reçue et où se concentrent les quantités attendues.
2. Construire la vue autour du cycle réel d’un achat
Définir précisément « ouvert », « en retard », « reçu » et « restant »
Le chantier a été livré les 17 et 18 mars 2026. Le premier incrément a installé le contrôleur, les agrégats et l’interface complète ; le second a stabilisé la présentation. La date publique retient la version cohérente du 18 mars.
Dawap a commencé par définir le périmètre ouvert. Une commande est comptée comme ouverte si son statut d’achat n’est ni annulé ni canceled et si son statut de livraison n’est pas delivered. La valeur ouverte applique le même filtre à son montant TTC converti.
Le calcul de réception travaille ensuite sur les lignes dont la commande n’est pas marquée livrée. Il additionne quantité commandée et quantité reçue, borne le restant à zéro puis calcule un pourcentage de progression. Les produits sont regroupés pour faire remonter les plus gros volumes encore attendus.
Enfin, l’interface a été conçue comme une synthèse en lecture seule. Elle ne modifie pas les statuts, ne crée pas de commentaire et n’assigne pas de responsable. Les liens conduisent aux commandes et fournisseurs existants, afin que toute correction reste portée par l’objet qui fait foi.
3. Avant le pipeline : des commandes visibles, un engagement encore diffus
Le statut d’un achat ne suffisait pas à résumer ses réceptions
Une liste de commandes permet de retrouver un fournisseur ou une date, mais elle ne répond pas immédiatement à la question de l’encours. Une commande non annulée peut être totalement livrée, partiellement reçue ou encore sans réception. Ces situations ne doivent pas produire le même signal.
À l’inverse, regarder uniquement les lignes produit fragmente la lecture. Une réception de cinquante unités n’a pas le même sens selon la quantité commandée, l’échéance, le fournisseur et l’état global de l’achat. L’équipe a besoin des deux niveaux simultanément.
Les montants posent un troisième problème. Les achats peuvent venir de différentes sources, mais Ciama conserve une valeur convertie qui permet de les additionner. Sans agrégat commun, l’engagement financier reste réparti entre plusieurs fiches et difficile à rapprocher de la marchandise en chemin.
Le projet devait donc produire une photographie, pas une nouvelle transaction. L’enjeu était de calculer la vue depuis les commandes et les lignes existantes, de rendre chaque définition explicite et de permettre à l’utilisateur de revenir à la source lorsqu’un chiffre demande une correction.
4. Faire tenir le pipeline d’achat dans une seule lecture
Réunir engagement, échéance, réception et concentration du risque
Le premier objectif était de compter les commandes réellement ouvertes selon une règle stable, puis d’additionner leur montant TTC converti. Ces deux indicateurs donnent l’ampleur du pipeline en nombre et en valeur sans mélanger les achats annulés ou déjà livrés.
Le deuxième objectif consistait à suivre la marchandise. Quantité commandée, quantité reçue, quantité restante et taux de réception devaient partager le même périmètre pour éviter un pourcentage séduisant mais impossible à expliquer.
Le troisième objectif était temporel : isoler les commandes dont la date est passée et présenter les prochaines dates d’achat ou de réception. La page devait distinguer le retard de l’avenir proche au lieu de réduire toutes les commandes ouvertes à une même liste.
Le quatrième objectif était de montrer où se concentre l’encours : quels produits représentent les plus grandes quantités à recevoir et quels fournisseurs portent la plus forte valeur ouverte. Cette hiérarchie aide à commencer la revue au bon endroit sans produire un score arbitraire.
5. Définir « ouvert » à partir de deux statuts
Ne pas confondre vie de la commande et avancement de sa livraison
Ciama conserve un statut d’achat et un statut de livraison. Le pipeline considère une commande ouverte lorsque le premier n’est ni cancel ni cancelled et que le second n’est pas delivered. Une valeur absente reste dans le périmètre, car elle signifie que le cycle n’est pas explicitement fermé.
Cette double condition alimente le nombre de commandes ouvertes, leur valeur convertie et le classement des fournisseurs. Elle évite qu’une commande encore marquée active mais totalement livrée continue à gonfler l’encours principal.
Le retard reprend le même périmètre, puis ajoute une date d’achat strictement antérieure au moment de consultation. Le chiffre met ainsi en évidence les commandes ouvertes dont l’échéance portée par Ciama est dépassée. Il ne mesure pas un retard fournisseur certifié si la date source a un autre sens métier.
Les répartitions par statut d’achat utilisent une règle légèrement différente : elles excluent les commandes annulées mais conservent les autres, y compris lorsque leur livraison est terminée. La fiche publique ne mélange donc pas ce panorama avec l’indicateur d’encours strict.
6. Quatre repères pour ouvrir la revue
Volume d’achats, valeur, progression des unités et échéances dépassées
Le premier indicateur affiche le nombre de commandes ouvertes selon la double règle d’achat et de livraison. Le deuxième additionne leur montant TTC converti en euros. L’équipe obtient immédiatement le volume administratif et l’engagement financier associé.
Le troisième mesure la progression de réception. Ciama divise la somme des quantités reçues par la somme des quantités commandées pour les lignes dont la commande n’est pas marquée delivered. Le résultat est arrondi à un chiffre après la virgule et accompagné des deux totaux.
Le quatrième compte les commandes ouvertes dont la date est déjà passée. Il ne tente pas d’évaluer la gravité ou le nombre de jours de retard. Sa couleur d’alerte invite à ouvrir la liste d’achats et à vérifier les objets concernés.
Ces quatre cartes sont calculées à la demande depuis le compte connecté. Elles ne dépendent ni d’un cache analytique séparé ni d’un saisie spécifique au command center. Le chiffre reflète donc les statuts et quantités portés par les objets opérationnels au moment de la consultation.
7. Présenter les douze prochains achats datés
Une liste courte ordonnée par date croissante
La première table récupère jusqu’à douze commandes dont la date d’achat est égale ou postérieure au moment de consultation et dont le statut d’achat n’est pas annulé. Les commandes sont classées de la plus proche à la plus lointaine.
Chaque ligne montre le nom de l’achat, son identifiant externe, le fournisseur, le statut d’achat, le statut de livraison, la date et le montant converti. Deux badges distincts préservent la différence entre décision d’achat et avancement logistique.
Un bouton ouvre la commande détaillée. Le command center ne propose pas de modifier le statut dans la table, ce qui réduit le risque d’une correction sans contexte. La fiche d’achat reste l’endroit où contrôler ses lignes et ses informations sources.
Cette liste ne prétend pas regrouper toutes les commandes ouvertes : elle est volontairement limitée et orientée vers les dates futures. Le compteur global et les autres blocs complètent cette fenêtre, tandis que la recherche d’achats conserve la vue exhaustive.
8. Faire remonter les quatorze prochaines lignes attendues
Regarder la date de livraison au niveau du produit
La seconde table travaille sur les lignes de commande dont la date estimée de livraison est renseignée et n’est pas passée. Elle retourne jusqu’à quatorze résultats, classés par date croissante, avec le produit et son fournisseur.
La quantité en attente est calculée ligne par ligne en soustrayant la quantité livrée de la quantité commandée. Cette vue rapproche donc une échéance avec un volume, ce qu’une liste limitée aux en-têtes de commande ne pourrait pas faire.
Le traitement ne retire pas automatiquement une ligne entièrement reçue si sa date reste future et si le statut global n’a pas été actualisé. Cette limite rappelle la responsabilité de la donnée source : le tableau reflète les objets enregistrés et ne corrige pas silencieusement leur cycle.
L’image du produit et le nom du fournisseur facilitent la reconnaissance pendant une revue. En l’absence d’image ou de relation complète, la ligne reste présente avec un repère neutre, car une donnée visuelle manquante ne doit pas masquer une réception datée.
9. Rapprocher la marchandise commandée et reçue
Une synthèse des lignes dont la livraison n’est pas clôturée
La synthèse compte les lignes actives du périmètre et le nombre de produits distincts associés. Elle additionne ensuite les quantités commandées et livrées. La quantité en attente est la différence entre ces deux sommes, bornée à zéro pour éviter un restant négatif en cas de sur-réception.
Le taux de progression est calculé seulement lorsque la quantité commandée est positive. En l’absence de volume, il reste à zéro. Cette garde évite une division impossible et garde le comportement compréhensible sur un compte encore vide.
La valeur affichée dans ce bloc additionne les montants convertis des lignes rattachées à des commandes non livrées. Elle ne retranche pas une part proportionnelle déjà reçue. La fiche la décrit donc comme valeur des lignes en cours, et non comme valorisation comptable exacte du reliquat physique.
Ce cadrage est important : le pipeline donne une lecture opérationnelle de réception. Il ne remplace ni la comptabilité fournisseur, ni la valorisation du stock, ni une réconciliation de factures. Chacun de ces sujets demanderait des règles et des sources supplémentaires.
Fournisseur, date, statuts et valeur convertie
Produits, quantités et dates estimées
Quantités livrées rapprochées des quantités commandées
Restant borné, valeur ouverte et échéances
Retour vers la commande ou le fournisseur qui fait foi
10. Classer les dix plus gros volumes produit en attente
Repérer où la marchandise non reçue se concentre
Ciama regroupe les lignes par nom, identifiant externe et image produit lorsque la commande parente n’est pas marquée delivered. Pour chaque groupe, il additionne quantité commandée, quantité reçue et valeur convertie.
Le restant est calculé comme la différence entre commandé et livré, avec un minimum de zéro. Les groupes sont ensuite triés en mémoire du plus grand restant au plus petit, et les dix premiers alimentent le tableau.
Cette méthode fait émerger les références qui pèsent le plus en unités dans les réceptions en cours. Elle ne mesure ni leur marge, ni leur vitesse de vente, ni le coût d’une rupture. Ces facteurs peuvent changer la priorité métier, mais ils ne sont pas présentés comme présents dans le classement.
La valeur convertie est montrée à côté du volume afin de donner un second repère. Un produit important en unités peut représenter un montant limité, et inversement. L’équipe dispose des deux lectures sans qu’un score les fusionne arbitrairement.
11. Voir les huit fournisseurs qui portent le plus de valeur ouverte
Regrouper les commandes non annulées et non livrées par partenaire
Le classement fournisseurs applique le même périmètre ouvert que les deux premiers indicateurs. Il groupe les commandes par fournisseur, compte les achats et additionne leur montant TTC converti.
Les résultats sont triés par valeur décroissante et limités à huit. Le lien ouvre directement la fiche fournisseur lorsque la relation existe ; un libellé neutre conserve malgré tout les commandes dont le partenaire n’est pas correctement rattaché.
Cette vue permet d’identifier une concentration de l’encours et de commencer la revue par les partenaires qui portent le plus de valeur. Elle ne constitue pas un score de performance fournisseur : aucun délai réel, taux de service ou historique de qualité n’entre dans le calcul.
Un bloc voisin répartit également les commandes par statut d’achat, avec leur nombre et leur valeur. L’équipe peut ainsi lire le pipeline sous deux angles complémentaires : étape du cycle et concentration par fournisseur.
12. Les arbitrages qui évitent un faux workflow
Préférer une vue fidèle aux achats à une couche de tâches non alimentée
Le premier arbitrage est de ne pas transformer chaque commande en alerte séparée. Les statuts, dates et quantités existent déjà sur les objets d’achat. Les agréger évite une seconde source qu’il faudrait synchroniser, assigner puis clôturer en parallèle.
Le deuxième maintient plusieurs définitions adaptées aux blocs. Les indicateurs d’encours excluent les commandes livrées ; la liste des achats futurs se concentre sur la date et le statut d’achat ; les réceptions futures travaillent au niveau des lignes. La page ne prétend pas qu’un filtre unique répond à toutes les questions.
Le troisième borne les listes. Douze achats, quatorze réceptions, dix produits et huit fournisseurs donnent une synthèse exploitable au premier écran. La limite est visible dans le rôle de la page : détecter où ouvrir le détail, pas remplacer les recherches exhaustives.
Le quatrième assume une interface en lecture seule. Aucun commentaire, priorité, assignation ou clôture n’est créé dans ce command center. Ce choix réduit la promesse fonctionnelle, mais rend chaque chiffre traçable vers une commande ou une ligne réellement présente dans Ciama.
13. Séparer calculs, agrégats et présentation
Un contrôleur léger appuyé sur des recherches dédiées au pipeline
Le contrôleur prépare la date de référence et demande chaque indicateur à une recherche dédiée. Les règles d’ouverture, de retard, de regroupement et de somme restent au plus près des données, plutôt que d’être recalculées dans le gabarit d’affichage.
Toutes les recherches sont limitées au compte connecté. Si aucun compte n’est disponible, la page reçoit des collections vides et des indicateurs à zéro au lieu d’interroger un périmètre indéfini. Ce comportement protège la frontière des données jusque dans l’état vide.
La quantité restante et le pourcentage de réception sont bornés pour éviter des valeurs impossibles. Les montants absents retombent à zéro et les statuts absents reçoivent un libellé explicite dans les répartitions. La synthèse reste affichable même lorsque les données sources sont partielles.
Une vérification applicative protège l’accès à la route, tandis que le découpage des recherches rend les définitions contrôlables séparément. La livraison concentrée sur deux jours a permis de construire le cockpit complet puis d’en stabiliser la présentation sans étendre artificiellement son périmètre.
14. Ce qui change après la livraison
Une revue de l’encours qui commence par les bons objets
L’équipe n’a plus besoin d’ouvrir chaque commande pour connaître le volume du pipeline. Le nombre d’achats ouverts, leur valeur et la progression de réception installent une lecture commune avant d’entrer dans les exceptions.
Les échéances deviennent visibles à deux niveaux. Les commandes dépassées alimentent l’alerte globale ; les achats et lignes de réception à venir sont ordonnés par date. La revue distingue ce qui demande une vérification immédiate de ce qui doit être surveillé prochainement.
Les concentrations émergent sans calcul manuel. Les produits sont classés par quantité restante et les fournisseurs par valeur ouverte. Une personne peut choisir son angle — risque logistique ou engagement financier — puis ouvrir la source correspondante.
Enfin, la page évite d’inventer une mémoire parallèle. Les corrections de statut, de quantité ou de fournisseur continuent à vivre sur les achats. Le command center se met à jour depuis ces mêmes données et reste une synthèse plutôt qu’un système concurrent.
15. Le scénario quotidien qui résume le projet
Comprendre un encours élevé avant d’appeler le fournisseur
Le Purchase Pipeline affiche plusieurs commandes ouvertes et une progression de réception inférieure au niveau attendu. Le compteur de retards indique qu’au moins une date est dépassée, tandis que la liste des produits en attente concentre une grande partie du volume sur une référence.
L’équipe repère le fournisseur parmi les partenaires portant le plus de valeur ouverte. Elle ouvre ensuite la commande depuis la table des achats, vérifie ses deux statuts et contrôle les quantités livrées sur les lignes concernées.
Si la marchandise a été reçue mais que le statut global n’a pas été mis à jour, la correction se fait sur la commande. Si la réception est réellement partielle, l’équipe utilise la date estimée et l’identifiant externe pour qualifier la relance fournisseur. Le tableau n’a pas créé une tâche redondante.
Au prochain affichage, les agrégats reflètent la source corrigée. Une commande passée à delivered sort de l’encours principal ; ses lignes cessent d’alimenter la synthèse de marchandise et les classements ouverts. La vue retrouve sa cohérence sans rapprochement manuel entre deux outils.
16. Relier préparation, engagement et retour en stock
Trois projets distincts autour du même cycle de réassort
Le Replenishment Planner marketplace intervient avant l’achat. Il projette les ventes récentes d’un entrepôt et prépare une feuille de revue ; il ne suit pas les commandes déjà engagées.
Le référentiel fournisseurs et achats explique le socle qui porte les partenaires, commandes et lignes utilisés ici. Le command center transforme ces objets en synthèse transversale.
L’analyse du stock entrepôt reprend le cycle après la réception : disponibilité observée, historique et date de rupture estimée. Elle permet de contrôler si la marchandise attendue devient bien exploitable.
La page automatisation des flux marketplace replace enfin ce suivi dans le système vendeur : collecter les sources, normaliser statuts et montants, puis superviser les écarts qui demandent une action humaine.
17. Conclusion
Le réassort ne s’arrête pas lorsque la commande est envoyée
Ce projet donne une place claire à la période la moins visible du cycle : la marchandise est commandée, mais pas encore entièrement reçue. Ciama rapproche alors engagements ouverts, quantités, dates, produits et fournisseurs sans inventer une couche de tâches qui doublerait les achats.
La force du command center tient à ses définitions. Une commande ouverte, un retard, une quantité restante et un taux de réception sont calculés selon des règles lisibles. Les limites des listes et de la valorisation sont assumées, ce qui permet d’utiliser la page comme une synthèse plutôt que comme une vérité comptable universelle.
C’est aussi notre manière d’accompagner le réapprovisionnement marketplace : projeter la demande, suivre l’engagement fournisseur, contrôler la réception puis remettre une donnée de stock fiable à disposition des canaux.
