Le projet en un coup d’œil
Le même produit devait être retrouvé dans les commandes, les offres, les entrepôts, les achats et les calculs financiers sans mélanger les comptes.
Une synthèse ouvre l’enquête, puis chaque onglet approfondit un domaine précis avec ses propres filtres, règles et volumes de lecture.
Le produit devient le contexte stable depuis lequel comparer ses trois univers de vente et choisir le bon parcours opérationnel.
Un produit vendeur traverse plusieurs réalités en même temps. Il possède un SKU et parfois un GTIN ou un identifiant ERP ; il apparaît dans des commandes B2B, marketplace ou e-commerce ; il porte des offres par canal, existe dans plusieurs stocks, dépend d’un coût d’achat et peut recevoir une règle de TVA particulière selon le pays. Chercher une seule référence revient donc à suivre plusieurs chaînes qui ne parlent pas spontanément le même langage.
Dawap a construit dans Ciama un poste de contrôle centré sur cette identité produit. Sa première vue rapproche chiffre d’affaires hors taxes, marge, offres, stock, historique commercial et répartition entre trois univers. Sept onglets prolongent ensuite cette lecture : commandes, offres, stocks, rentabilité, achats fournisseurs, configuration de TVA et alias de rapprochement.
Cette étude de cas montre comment notre approche du reporting marketplace vendeur devient opérationnelle à l’échelle d’un SKU. Le projet ne promet pas une décision automatique : il réunit les faits, protège la frontière entre les comptes et conduit l’utilisateur vers la vue spécialisée qui lui permet de vérifier ou de corriger la situation.
1. Ciama, un cockpit où le produit relie plusieurs flux de vente
Conserver une identité stable pendant que les usages se spécialisent
Ciama consolide des données venues de l’ERP, des marketplaces, des sites e-commerce et des chaînes logistiques. Dans ce paysage, un produit ne se résume pas à sa fiche catalogue : il est aussi l’objet auquel sont rattachés une ligne de commande, une offre, un stock d’entrepôt, une ligne d’achat et un calcul de marge.
Le besoin était de disposer d’un point d’entrée commun sans affaiblir la précision de chaque métier. Les ventes demandent une chronologie et des statuts ; les offres demandent un canal, un prix, un état et un stock ; la rentabilité demande de distinguer valeurs réelles et estimées ; la TVA demande un pays et une portée d’application.
La réponse prend la forme d’un espace Product Control Center. Le SKU reste visible dans son bandeau, accompagné de l’état du produit, de son GTIN et de son stock. Le menu garde en permanence les huit parcours disponibles. L’utilisateur sait ainsi sur quelle référence il travaille, même lorsqu’il passe d’une analyse de ventes à une règle fiscale.
Chaque contrôleur commence par retrouver le produit puis vérifie qu’il appartient bien au compte de l’utilisateur connecté. Un identifiant valide dans un autre compte ne suffit donc jamais à ouvrir ses données. Cette frontière répétée dans chaque vue est une propriété structurante du projet, pas un simple détail d’interface.
2. Faire grandir la vue produit au rythme des données réellement disponibles
D’octobre 2025 à mars 2026, du premier lien avec les offres au poste de contrôle complet
Le socle moderne apparaît fin octobre 2025 avec une vue produit alimentée par les offres liées. Les jours suivants ajoutent les lignes de commande, les indicateurs annuels et les premiers calculs de marge. Le produit devient progressivement plus qu’une entrée de catalogue : il reçoit sa propre histoire commerciale.
Début novembre, les alias apportent un mécanisme de rapprochement lorsque la source utilise une autre référence que le SKU principal. Les vues produit, marque et catégorie évoluent ensemble, puis la lecture B2B rejoint les flux marketplace. Fin novembre, la destination de livraison complète l’analyse avec un classement géographique.
En mars 2026, la chaîne achats fournisseurs et la vue de marge se renforcent, la présentation devient un véritable cockpit et la configuration de TVA rejoint le parcours produit. Le 17 mars, les navigations et les recherches sont harmonisées ; le 18 mars, leur couverture applicative est étendue. Cette date marque la version cohérente racontée ici.
Cette progression impose un choix éditorial et produit : la synthèse ne doit afficher que les éléments transverses, tandis que chaque domaine conserve une vue dédiée. La livraison est donc moins un écran monolithique qu’une architecture de navigation autour d’une identité sûre.
3. Avant le poste de contrôle : reconstituer un produit depuis ses traces
Une identité commune, mais des questions réparties dans plusieurs domaines
La question « que se passe-t-il sur ce produit ? » ouvre rarement une recherche unique. La baisse de vente peut venir d’un canal absent, d’une offre sans stock, d’un coût d’achat qui dégrade la marge, d’une commande remboursée ou simplement d’un changement de répartition entre B2B, marketplace et e-commerce.
Sans point d’entrée commun, l’utilisateur doit d’abord retrouver le bon SKU dans chaque liste, mémoriser la période observée et comparer des résultats qui ne portent pas toujours la même définition. Un chiffre d’affaires agrégé n’explique pas une ligne de commande ; un stock total ne dit pas dans quel entrepôt se trouve la quantité ; un prix d’offre n’est pas une marge.
Le risque n’est pas seulement le temps de navigation. Une équipe peut rapprocher deux homonymes, regarder un alias comme s’il s’agissait d’un autre produit ou tirer une conclusion à partir d’un seul univers de vente. Plus les canaux augmentent, plus l’identité et le contexte doivent rester visibles pendant l’enquête.
Le projet part donc d’une contrainte sobre : tout doit commencer par le produit du compte courant, mais chaque réponse doit rester produite par le domaine compétent. Cette règle fournit le fil conducteur des huit vues.
4. Transformer le SKU en point de départ du diagnostic
Réunir les faits sans confondre synthèse et action métier
Le premier objectif était de stabiliser le contexte. L’état actif, le SKU, le nom, le GTIN, l’identifiant ERP et le stock accompagnent la navigation. L’utilisateur conserve ainsi les repères essentiels lorsqu’il ouvre les commandes, les offres ou les achats du produit.
Le deuxième objectif consistait à comparer les trois univers de vente selon une même grille. Chiffre d’affaires hors taxes, marge, taux de marge, nombre de lignes expédiées et progression du calcul de marge doivent pouvoir être lus pour le B2B, les marketplaces et l’e-commerce, puis rapprochés du total.
Le troisième objectif était de préserver la profondeur. Une synthèse peut montrer les dernières commandes et un aperçu des offres ; elle ne remplace ni une recherche paginée, ni un détail financier, ni une matrice de TVA. Les onglets spécialisés devaient donc rester accessibles depuis le même bandeau produit.
Enfin, le projet devait soutenir la décision sans inventer d’alerte. Une donnée absente reste absente, une valeur estimée reste distinguée d’une valeur réelle et un stock global ne devient pas artificiellement un stock diffusable. La confiance vient de ces frontières autant que du nombre d’indicateurs.
5. Organiser huit vues autour d’un bandeau produit permanent
Overview, Orders, Offers, Stocks, Profit, Procurement, VAT Config et Settings
L’architecture présente huit entrées. Overview rassemble les informations transverses. Orders ouvre les lignes de commande. Offers isole les offres reliées. Stocks descend vers les enregistrements d’entrepôt. Profit détaille la rentabilité. Procurement remonte aux lignes d’achats fournisseurs. VAT Config porte les taux par pays. Settings expose les alias.
Cette navigation donne une place explicite à chaque responsabilité. Le produit sert de racine, mais les données ne sont pas aplaties dans un objet universel. Une commande garde son canal et sa date d’achat ; un stock garde son entrepôt ; une règle de TVA garde son pays ; un alias garde la référence qui a permis le rapprochement.
Le bandeau affiche l’état actif ou désactivé, le GTIN lorsqu’il existe et le stock du produit. Les huit onglets conservent le même identifiant dans leurs routes. Cette continuité réduit le risque de quitter involontairement la référence analysée au cours d’une investigation.
La frontière de compte est vérifiée à l’ouverture de chaque parcours. Le menu commun améliore l’ergonomie, mais il ne remplace pas ce contrôle côté serveur. L’autorisation reste attachée au produit demandé, quelle que soit la vue utilisée.
6. Faire de la synthèse une carte d’orientation, pas un rapport sans fin
Quatre KPI, plusieurs temporalités et trois univers comparables
La première rangée présente quatre montants hors taxes : le chiffre d’affaires total puis ses composantes B2B, marketplace et e-commerce. Pour les trois univers, la part dans le total est calculée seulement lorsque le total est positif. Une activité nulle ne produit donc pas une division trompeuse.
La carte d’identité réunit image, nom, état, SKU, marque, catégorie, GTIN, identifiant ERP, stock et dernière mise à jour. À côté, une table résume total hors taxes, mois courant, marge totale, taux de marge par univers et coût d’achat moyen hors taxes. Ces données donnent les premières pistes sans masquer leur nature.
La temporalité est volontairement multiple. Une courbe compare les douze mois de l’année courante à l’année précédente. Une seconde restitue le chiffre d’affaires par année. Le cycle de vente distingue expédié, à expédier et remboursé, tandis qu’une courbe mensuelle sépare B2B, marketplace et e-commerce.
Le tableau transverse reprend pour chaque univers le chiffre d’affaires, la marge, le taux, le nombre de lignes, les lignes expédiées et la progression du calcul de marge. Deux extraits de dix lignes terminent la lecture : les commandes les plus récentes et les dix plus récentes dont la marge a été calculée.
7. Garder l’identité produit explicable dans chaque rapprochement
SKU principal, GTIN, identifiant ERP et alias ne jouent pas le même rôle
Le SKU principal identifie le produit dans Ciama. Le GTIN apporte une référence standard lorsqu’il est renseigné. L’identifiant ERP permet de conserver le lien avec la source de gestion. Aucun de ces champs n’est remplacé par un autre dans l’interface : leurs rôles restent visibles.
Cette distinction devient importante lorsqu’une place de marché, un site ou un historique de commande emploie une référence différente. L’alias relie alors cette valeur au produit interne au lieu de créer silencieusement une seconde identité. L’onglet Settings restitue les alias associés au compte et au produit.
Le projet ne prétend pas que toutes les relations sont parfaites. Une offre ou une ligne non rapprochée ne peut pas apparaître comme si elle appartenait au produit. La vue montre ce qui est effectivement lié ; les outils de qualité et de normalisation restent responsables des corrections en amont.
Cette prudence évite une fausse unification. Le poste de contrôle n’assemble pas les données sur la seule ressemblance d’un libellé. Il s’appuie sur les relations persistées et sur un produit dont le compte a été vérifié.
8. Passer de l’agrégat aux lignes de commande du produit
Recherche, statut, canal et période dans une liste paginée
L’onglet Orders fixe d’abord le compte et le produit dans sa recherche. L’utilisateur peut ensuite saisir un terme, sélectionner un statut, un canal, une année et un mois. Les résultats sont triés par date d’achat décroissante par défaut, avec cent lignes par page.
Ce parcours répond à une limite volontaire de la synthèse. Les dix dernières lignes donnent un signal récent, mais elles ne suffisent pas à étudier une période ou un canal précis. La vue détaillée conserve les facettes choisies et donne accès au volume total de résultats.
Le produit reste ainsi le filtre non négociable, tandis que la question métier peut varier : retrouver une commande, isoler les lignes expédiées, comparer un mois ou examiner un canal. Le cockpit ne transforme pas ces lignes en simples points de courbe.
La même chronologie alimente aussi la liste des années disponibles pour le produit. Les filtres proposés partent donc de son histoire commerciale réelle plutôt que d’un calendrier arbitraire.
9. Examiner les offres reliées sans confondre aperçu et couverture exhaustive
Une vue produit paginée, distincte de la matrice multi-canal
La synthèse restitue jusqu’à cent offres reliées au produit. L’onglet Offers reprend ce périmètre avec une pagination de cent résultats et un filtre d’activité. Le tri par défaut privilégie le chiffre d’affaires TTC converti de l’année en cours, afin de faire remonter les offres commercialement significatives.
Chaque offre conserve son canal, son SKU, son état, son stock, son prix et les données financières disponibles. La page ne renomme pas toutes les offres en « actives » lorsque le filtre n’est pas appliqué : elle montre la relation existante, puis laisse l’utilisateur restreindre la lecture.
La liste des canaux du compte permet également de signaler ceux qui ne figurent pas dans les offres chargées. Cette indication reste une aide de navigation, pas une preuve de couverture exhaustive lorsque la pagination intervient. La véritable comparaison produit-canal appartient à l’Offer Listing Matrix.
Cette frontière évite de raconter deux fois le même projet. Ici, l’enjeu est d’ouvrir les offres depuis le contexte d’un produit. La matrice spécialisée, elle, croise plusieurs produits, stocks et canaux pour repérer des écarts de diffusion.
10. Descendre du stock produit vers ses implantations
Cinquante enregistrements par page, ordonnés par quantité
Le stock affiché dans le bandeau fournit un repère global. L’onglet Stocks interroge les enregistrements rattachés au compte et au produit, avec cinquante résultats par page et un tri décroissant sur la quantité. Un filtre permet d’isoler leur état actif.
Cette descente est nécessaire car une quantité produit ne répond pas à toutes les questions logistiques. La disponibilité peut être répartie entre plusieurs implantations et chaque stock garde sa propre relation avec l’entrepôt. Le détail ne doit pas être déduit d’un nombre agrégé.
Le poste de contrôle fournit donc la transition : voir qu’un produit possède ou non du stock, puis ouvrir la distribution réelle pour comprendre où il se trouve. Il ne calcule pas à lui seul la quantité diffusable sur chaque marketplace.
Pour les opérations qui doivent préparer un réassort ou piloter un stock cible par offre, les modules spécialisés prennent le relais. La fiche produit conserve son rôle de contexte et de diagnostic initial.
11. Séparer la lecture de marge de la simple lecture du chiffre d’affaires
Valeurs réelles, estimations et lignes financières restent identifiables
L’onglet Profit part par défaut des lignes expédiées du produit. Il accepte une recherche et des filtres de statut, canal, année et mois, puis affiche cent lignes par page. Cette granularité permet de revenir du KPI vers les ventes qui le composent.
La page calcule sa synthèse à partir des agrégats mensuels disponibles et utilise les valeurs portées par le produit lorsque le taux agrégé manque. Le mécanisme de résolution privilégie la marge réelle, puis l’estimation, puis la valeur consolidée disponible. L’origine n’est donc pas aplatie.
Pour chaque ligne, les commissions, frais de livraison, coûts d’achat et marges utilisent eux aussi la valeur réelle lorsqu’elle existe, sinon l’estimation correspondante. Les erreurs qui bloquent un calcul restent accessibles. Cette règle protège la lecture contre un taux apparemment précis mais construit sur une donnée absente.
Les offres du produit ayant un stock positif complètent la synthèse, ordonnées par marge totale. Le projet de détail de marge par offre approfondit ensuite le choix entre dernière vente et moyenne glissante sans surcharger ce poste de contrôle.
12. Relier le produit vendu aux lignes d’achats fournisseurs
Une chronologie d’approvisionnement consultable depuis la même référence
L’onglet Procurement recherche les lignes d’achats fournisseurs du compte et du produit. Une recherche libre complète ce périmètre ; les résultats sont triés par date d’achat décroissante et paginés par cent. La vue restitue donc la matière d’approvisionnement réellement reliée au produit.
Ce lien ferme une boucle importante. Le coût et la marge ne vivent pas séparément du sourcing : l’utilisateur peut partir d’un produit vendu, examiner sa rentabilité puis consulter les achats qui documentent son approvisionnement. Le passage ne nécessite pas de retrouver manuellement une autre référence fournisseur.
La page n’affirme pas qu’une ligne d’achat détermine automatiquement le coût de chaque vente. Elle expose la relation et sa chronologie. Les méthodes de valorisation, moyennes d’achat et calculs de marge conservent leurs propres règles.
Le référentiel fournisseurs et achats Odoo raconte le parcours dans l’autre sens : partir du fournisseur pour retrouver son historique d’achats. Les deux vues se complètent sans se confondre.
13. Configurer une exception de TVA au niveau du produit et du pays
Taux catalogue par défaut, surcharge explicite et portée choisie
VAT Config construit une matrice à partir des pays qui possèdent des taux actifs dans le catalogue fiscal. Pour chaque pays, la page retrouve le taux standard, affiche les options disponibles et sélectionne la surcharge du compte et du produit lorsqu’elle existe.
Choisir le taux standard supprime la surcharge correspondante. L’utilisateur peut aussi réinitialiser un pays ou toutes les exceptions du produit. Dans ce dernier cas, les taux standards par pays redeviennent la référence et un recalcul ciblé est envoyé pour chaque périmètre supprimé.
Lors de l’enregistrement, la portée est demandée : appliquer la modification à partir de maintenant ou l’étendre aux commandes existantes. Dans le second cas, les champs de TVA des lignes concernées sont réécrits pour le compte, le produit et le pays, puis leur recalcul est placé dans la chaîne de traitement.
Le contrôle d’accès est doublé lors de la réinitialisation d’une surcharge isolée : l’exception doit appartenir au même compte et au même produit. Une référence transmise depuis un autre périmètre est refusée au lieu d’être supprimée.
14. Rendre visibles les références qui convergent vers le même produit
Une mémoire du rapprochement, distincte de l’identité principale
L’onglet Settings charge les alias associés au produit et au compte connecté. Il permet de comprendre pourquoi une référence provenant d’une commande ou d’une offre a été rattachée au SKU principal, sans remplacer celui-ci dans la fiche.
Cette visibilité est utile lorsque les canaux historiques n’emploient pas tous le même identifiant vendeur. Au lieu de laisser le rapprochement dans une règle invisible, le poste de contrôle montre les valeurs qui convergent vers l’objet commun.
La vue reste volontairement consultative dans ce parcours. La création et la correction des alias relèvent des processus de gestion et de qualité en amont. Le diagnostic peut constater la relation sans offrir une mutation improvisée au milieu d’une analyse commerciale.
L’alias constitue ainsi un garde-fou contre les doublons conceptuels, mais pas une garantie absolue de qualité. Une relation erronée doit être corrigée ; une relation absente ne doit pas être inventée à partir d’un nom ressemblant.
15. Assumer les frontières qui rendent la vue fiable
Contexte commun, calculs spécialisés et absences visibles
Le premier arbitrage consiste à ne pas transformer Overview en copie de toutes les listes. Les offres et les commandes récentes y servent d’aperçu ; leurs écrans dédiés prennent en charge la pagination et les filtres. Cette séparation maintient une première lecture praticable.
Le deuxième arbitrage porte sur les niveaux d’agrégation. Le stock produit n’est pas présenté comme la disponibilité détaillée de chaque entrepôt. Le chiffre d’affaires ne remplace pas les lignes de vente. La marge totale ne masque pas la distinction entre frais réels et estimés.
Le troisième concerne les trois univers. B2B, marketplace et e-commerce partagent un tableau et des courbes, mais ne deviennent pas un canal unique. Leurs montants, marges, volumes et progressions de calcul restent séparés avant d’être rapprochés du total.
Enfin, le poste de contrôle ne crée pas un diagnostic automatique à partir de quelques couleurs. Il donne les faits nécessaires pour formuler une hypothèse, puis ouvre le domaine où elle peut être confirmée. Ce refus du raccourci est central pour une décision défendable.
16. Livrer par couches puis harmoniser l’ensemble du parcours
Des fondations d’octobre 2025 à la cohérence applicative de mars 2026
La livraison commence par les relations les plus structurantes : produit, offres et lignes de commande. Les agrégats annuels et la marge arrivent ensuite, puis les alias, les trois univers de vente et les destinations de livraison enrichissent la compréhension du produit.
Les achats fournisseurs, le cockpit enrichi et la TVA rejoignent le parcours en mars 2026. Chaque ajout conserve la vérification du compte et son écran spécialisé. L’extension fonctionnelle ne contourne donc pas les frontières mises en place dans les premières vues.
L’harmonisation finale porte sur les bandeaux, les tables, les recherches, les routes de tri et la navigation entre les onglets. Elle est accompagnée d’une couverture applicative élargie le 18 mars. L’objectif est de vérifier le parcours complet, pas seulement la présence de champs dans un gabarit.
La vie du projet reste visible dans sa construction : chaque nouveau flux peut rejoindre le produit s’il possède une relation et une responsabilité claires. Le poste de contrôle est extensible, mais l’ajout d’une donnée n’est pas automatique ; il doit améliorer une décision identifiée.
17. Passer d’une recherche dispersée à une enquête structurée
Un avant-après observable sans fabriquer de KPI client
Avant cette architecture, la recherche démarrait dans le domaine où l’anomalie semblait se manifester : commandes pour une baisse de ventes, offres pour une absence de diffusion, stocks pour une rupture ou finance pour une marge faible. Il fallait ensuite reconstruire le lien avec la même référence dans les autres chaînes.
Après la livraison, le produit fournit un contexte permanent et une synthèse commune. L’utilisateur voit la répartition des ventes, les temporalités, la marge, les offres et les derniers événements, puis choisit l’onglet qui correspond à son hypothèse. Le chemin de vérification devient reproductible.
La transformation la plus tangible tient à la continuité des identités. SKU, GTIN, identifiant ERP et alias restent distingués, tandis que les vues sont toutes bornées par le compte et le produit. Le risque de poursuivre l’enquête sur une autre référence ou un autre périmètre diminue structurellement.
Les décisions gagnent aussi en explicabilité. Une recommandation de réassort peut être ramenée aux stocks et aux ventes ; une alerte de marge aux lignes financières ; une exception fiscale au pays et à sa portée. Le cockpit ne remplace pas le raisonnement, il lui donne une piste vérifiable.
18. Le scénario terrain qui mobilise les huit vues
Un produit vend encore, mais sa contribution marketplace décroît
La synthèse d’un SKU montre que son chiffre d’affaires total reste alimenté par le B2B et l’e-commerce, tandis que la part marketplace se contracte. La comparaison mensuelle confirme que le mouvement ne vient pas seulement d’un décalage entre deux jours. Ce premier constat reste une orientation, pas encore une cause.
L’utilisateur ouvre Orders et filtre la période ainsi que les canaux concernés. Il vérifie les statuts et les dernières lignes. Offers lui permet ensuite de retrouver les offres liées et leurs niveaux de stock ; Stocks précise dans quelles implantations les quantités sont enregistrées.
Si la diffusion semble correcte, Profit permet d’examiner les frais, le coût d’achat et les marges réelles ou estimées. Procurement restitue les achats fournisseurs du produit. VAT Config vérifie enfin qu’une exception de taux par pays n’introduit pas une incohérence sur les ventes concernées.
Settings ferme la vérification identitaire en exposant les alias. À chaque étape, le SKU et le compte restent le contexte. Le résultat n’est pas une cause décidée d’avance, mais une enquête complète qui élimine ou confirme successivement les hypothèses.
19. Documenter ce que le poste de contrôle ne prétend pas résoudre seul
Une preuve plus crédible parce que son périmètre reste net
La vue produit n’est pas un PIM complet. Elle affiche les attributs nécessaires au contexte et les relations utiles au pilotage, mais ne remplace pas les workflows de création, d’enrichissement ou de diffusion d’un catalogue.
Elle n’est pas non plus la matrice exhaustive de couverture des offres. Une liste paginée au niveau d’un produit aide à consulter les offres reliées ; la comparaison systématique entre produits, canaux et stocks appartient à son module dédié.
Les graphiques n’expliquent pas automatiquement une variation. Ils reposent sur les données consolidées disponibles et doivent être lus avec les lignes sous-jacentes. De même, une marge estimée ne devient jamais une marge réelle par sa seule présence dans un KPI.
Enfin, la page ne mesure pas une amélioration commerciale attribuable au cockpit. Sa preuve tient aux fonctions livrées, aux contrôles de périmètre, aux volumes de consultation et à la chaîne de navigation vérifiable. Aucun pourcentage de gain client n’est ajouté sans mesure disponible.
20. Relier le poste de contrôle aux outils qui approfondissent chaque décision
Reporting transverse, couverture des offres, marge et achats fournisseurs
Le dashboard de ventes multicanal fournit le mouvement inverse : il commence par la vue d’ensemble B2B, marketplaces et e-commerce, puis aide à repérer les produits qui méritent une analyse individuelle.
L’Offer Listing Matrix approfondit la couverture produit-canal et les stocks. Le détail de marge par offre compare les méthodes de valorisation lorsqu’une décision de prix demande davantage que le KPI produit.
Le référentiel fournisseurs et achats ouvre enfin la chaîne depuis Odoo et le fournisseur. Ensemble, ces projets forment un maillage fonctionnel : chacun répond à une question précise et la vue produit conserve le contexte lorsque l’enquête change de domaine.
Cette articulation prolonge notre reporting marketplace vendeur. La donnée agrégée sert à trouver le sujet ; le poste de contrôle réunit ses dimensions ; les modules spécialisés permettent ensuite de vérifier et d’agir sans perdre l’identité de départ.
21. Conclusion
Le produit devient utile lorsqu’il relie les métiers sans les confondre
Ce projet donne à chaque SKU une place stable entre catalogue, ventes, offres, stocks, marge, achats, fiscalité et rapprochements. La synthèse offre les premières réponses ; les sept autres vues conservent la précision nécessaire pour poursuivre l’enquête.
Sa qualité tient autant aux frontières qu’aux fonctionnalités : vérification du compte dans chaque parcours, distinction des trois univers, séparation du stock global et des implantations, priorité aux valeurs financières réelles et visibilité des estimations ou des absences.
C’est ainsi que Dawap conçoit un reporting marketplace vendeur réellement opérationnel : partir d’un signal consolidé, retrouver le produit concerné, descendre jusqu’aux faits et garder une décision explicable à chaque étape.
