Ciama : comparer la marge des offres par dernière vente ou moyenne glissante

1. Ciama, un cockpit où chaque offre accumule un historique de ventes

Transformer des lignes financières dispersées en revue de catalogue

Les offres d’un compte peuvent provenir de plusieurs canaux et être reliées à des produits, marques et catégories différents. Chaque vente apporte son prix, son taux de TVA, ses frais de canal, son transport, son coût d’achat et sa marge.

Ces informations sont précieuses mais leur granularité naturelle est la ligne de commande. Une offre très active possède de nombreuses observations ; une offre récente peut n’en avoir qu’une ; une offre jamais vendue ne possède aucun point financier exploitable.

Le besoin était donc de construire un format commun sans prétendre que toutes les offres disposaient du même historique. Le rapport devait conserver une ligne pour chaque offre, puis laisser vides les mesures qu’aucune vente éligible ne permet de renseigner.

Il devait également offrir deux lectures différentes : le dernier cas unitaire connu pour une photographie concrète, et une moyenne récente pour lisser les variations d’une vente isolée. Ces modes ne sont pas fusionnés ; l’utilisateur choisit celui qui correspond à sa revue.

2. Choisir une observation, générer hors requête puis rendre le fichier téléchargeable

Une chaîne de reporting séparée du calcul transactionnel

Le chantier a d’abord défini les quinze colonnes nécessaires à une revue : identifiant de l’offre, mode de traitement logistique, canal, produit, marque, catégorie, date, prix TTC, taux de TVA, prix HT, commission, transport, achat, marge et taux de marge.

Deux requêtes financières ont ensuite été isolées. La première retrouve la ligne unitaire la plus récemment créée dont la marge a été calculée. La seconde agrège les mêmes mesures sur une fenêtre de 30, 60 ou 90 jours et conserve la date de vente la plus récente de la période.

La génération a été déplacée dans un traitement asynchrone. La demande crée d’abord un rapport en attente ; le worker passe ce rapport en génération, parcourt les offres, écrit le fichier puis marque la fin avec son nom, sa durée, son nombre de lignes et une progression à cent pour cent.

Enfin, l’écran conserve l’historique des rapports du compte. Un téléchargement n’est proposé que lorsque le statut est terminé et que le fichier existe encore. Cette séparation protège l’interface d’un export volumineux et donne une trace de chaque production.

3. Avant le projet : comparer les offres imposait de recomposer les ventes

Une vue détaillée ne remplace pas une extraction homogène

Ciama savait déjà calculer la finance d’une ligne de commande et afficher la marge dans les écrans de vente. Cette profondeur permet d’expliquer un cas précis, mais elle oblige à connaître d’avance l’offre ou la commande à ouvrir.

Une revue de catalogue procède dans l’autre sens. Elle doit partir de toutes les offres, appliquer une règle de sélection identique, puis faire ressortir celles dont les coûts ou la marge se distinguent.

Un simple export des offres n’aurait pas suffi : le prix courant d’une offre ne raconte pas les frais réellement observés dans une vente. À l’inverse, exporter toutes les lignes de commande aurait multiplié les lignes et mélangé les volumes, périodes et quantités.

Le rapport devait donc assumer une convention. Soit retenir une observation unitaire récente, soit calculer une moyenne sur une fenêtre choisie. La valeur vient des ventes ; l’unité de sortie reste l’offre.

4. Parcourir toutes les offres du compte dans un ordre stable

Une ligne de sortie par offre, y compris sans vente éligible

Le générateur charge les offres qui appartiennent au compte du rapport et les trie par identifiant croissant. Il ne limite pas ce passage à une marketplace, une marque ou une catégorie particulière.

Cette portée permet une revue complète du catalogue présent dans Ciama. Le canal exporté sur chaque ligne garde l’origine visible et permet ensuite de filtrer le fichier dans un tableur.

Le nombre d’offres devient le nombre de lignes attendu du rapport. Il est enregistré dès le début, avant que les mesures financières ne soient recherchées, puis utilisé pour calculer la progression.

Une offre sans observation éligible n’est pas supprimée. Ses six colonnes d’identité restent présentes et ses neuf colonnes financières restent vides. L’absence de donnée devient ainsi un résultat de contrôle à part entière.

5. Retenir la dernière vente unitaire dont la marge a été calculée

Une photographie concrète plutôt qu’un prix théorique

Le mode par défaut recherche, pour chaque offre, une ligne de commande dont la quantité vaut exactement un et dont le calcul de marge est marqué comme effectué. Parmi ces lignes, la plus récemment créée est retenue.

Le rapport utilise la date d’achat de la commande pour dater l’observation. Il exporte ensuite prix TTC, taux de TVA, prix HT, commission, transport, achat, marge et taux de marge.

La contrainte quantité égale à un évite de comparer directement une ligne agrégée de plusieurs unités à une autre. Elle a cependant une conséquence claire : une offre vendue uniquement par quantités supérieures à un peut ne produire aucune mesure dans ce mode.

Cette photographie ne prétend pas représenter une moyenne habituelle. Elle répond à une question précise : quelle est la dernière équation financière unitaire exploitable connue pour cette offre ?

6. Lisser les observations sur 30, 60 ou 90 jours

Une seconde lecture pour réduire le poids d’une vente isolée

Les trois modes de moyenne utilisent une fenêtre qui commence à minuit, 30, 60 ou 90 jours avant la génération. Les lignes doivent appartenir au compte, à l’offre, porter un calcul de marge et avoir une quantité égale à un.

Chaque mesure est moyennée séparément : prix TTC, TVA, prix HT, commission, transport, achat, marge et taux de marge. La date exportée correspond à la vente la plus récente rencontrée dans la fenêtre.

Le calcul choisit la valeur réelle d’un coût ou de la marge lorsqu’elle existe, puis sa variante estimée. Les observations disponibles peuvent donc combiner ces deux niveaux de preuve avant la moyenne.

Ce mode produit une tendance descriptive, pas une reconstitution comptable pondérée par quantité. Comme seules les lignes unitaires sont retenues et que chaque colonne reçoit sa propre moyenne, le fichier doit être utilisé pour comparer puis diagnostiquer.

7. Garder seulement les lignes dont la finance a été traitée

Ne pas utiliser une vente brute comme si sa marge était prête

Les deux requêtes exigent que le marqueur de calcul financier de la ligne soit actif. Une ligne importée mais pas encore agrégée ne devient donc pas une observation valide pour ce rapport.

Cette règle évite de mélanger un prix disponible avec des coûts encore en attente. Si aucune ligne ne passe le filtre, les cellules financières de l’offre restent vides au lieu d’afficher des zéros.

La recherche reste limitée au compte et à l’offre. Une vente reliée au même produit mais à une autre offre ne sert pas de repli, même si son prix paraît proche.

Le rapport travaille ainsi à la bonne granularité : l’offre définit le canal et l’identité commerciale ; la ligne de commande fournit l’observation financière réellement rattachée à cette offre.

8. Réunir quinze colonnes pour replacer la marge dans son contexte

Six dimensions d’identité et neuf mesures financières

Les six premières colonnes identifient l’offre : identifiant, mode de traitement par le vendeur ou la plateforme, canal, produit, marque et catégorie. Les relations absentes restent vides.

Les neuf suivantes décrivent l’observation : date, prix TTC, taux de TVA, prix HT, frais du canal, transport, achat, marge et taux de marge. Les montants sont arrondis à deux décimales.

Cette organisation permet de filtrer d’abord un canal ou une famille, puis de comparer les composantes financières. Une marge faible peut être rapprochée du coût d’achat, du transport ou de la commission sans quitter la ligne.

Le fichier ne contient pas le stock, les retours, un seuil de marge, la concurrence ou une recommandation de prix. Ces données n’appartiennent pas au contrat de ce rapport.

9. Utiliser le réel en priorité, puis l’estimation disponible

Une règle de repli utile dont la limite reste assumée

Pour la commission, le transport et l’achat, le générateur consulte d’abord le champ financier réel. S’il est vide, il utilise le champ estimé ; dans le mode dernière ligne, certains anciens champs de la ligne peuvent servir de dernier repli.

La marge et son taux suivent le même principe : réel avant estimé, puis ancienne valeur disponible pour la dernière ligne. Ce comportement augmente le nombre d’offres renseignées dans une revue.

Le fichier final ne contient toutefois pas de colonne indiquant l’origine de chaque valeur. Une commission réelle et une commission estimée occupent la même colonne. Le rapport ne doit donc pas être présenté comme une pièce comptable certifiée.

Les vues détaillées de Ciama conservent cette distinction et les causes de blocage. Après avoir repéré une offre dans l’export, l’utilisateur doit y revenir pour qualifier le niveau de preuve avant une décision sensible.

10. Encadrer la demande avec des choix fermés

Quatre calculs et deux formats, avec des valeurs de repli sûres

Le formulaire propose quatre modes : dernière ligne, moyenne 30 jours, moyenne 60 jours et moyenne 90 jours. Toute autre valeur reçue est remplacée par la dernière ligne.

Le format peut être CSV ou Excel compatible. Une valeur inconnue revient au CSV. Le nombre de jours n’est transmis que pour les trois moyennes et reste limité aux fenêtres autorisées.

La demande crée immédiatement un rapport rattaché au compte, avec un identifiant unique, sa date, son type et un état en attente. Elle ne tente pas de construire le fichier dans la réponse du navigateur.

L’utilisateur revient sur la liste des rapports avec une confirmation. Le traitement peut ensuite avancer indépendamment du chargement de la page.

11. Générer le fichier hors de la requête utilisateur

Un worker qui porte les offres, les calculs et l’écriture

Le message transmis au worker contient le compte, le rapport, le mode de calcul, l’éventuelle fenêtre et le format. Le worker valide à nouveau ces choix avant de commencer.

Il vérifie que le compte et le rapport existent puis que le rapport appartient bien au compte demandé. L’état passe alors de « en attente » à « en génération » avec une progression initiale à zéro.

Les offres sont parcourues une par une. Après chaque groupe de dix, ou sur la dernière offre, le pourcentage est recalculé et enregistré. Une génération longue peut donc être suivie sans attendre la fin du fichier.

Une exception fait passer le rapport en erreur. Un succès enregistre le chemin, le nom, l’heure de fin, la durée en secondes et une progression de cent pour cent.

12. Produire un CSV natif ou un tableau lisible par Excel

Deux sorties adaptées au tri, avec une différence technique assumée

Le CSV est écrit ligne par ligne avec l’en-tête commun puis une ligne par offre. Il convient aux imports, aux traitements automatisés et aux tableurs capables de gérer le séparateur du fichier.

Le format proposé comme Excel porte l’extension .xls, mais son contenu est un tableau HTML encodé en UTF-8. Excel peut l’ouvrir et conserver la mise en tableau ; il ne s’agit pas d’un classeur binaire natif.

Dans cette version compatible Excel, le taux de marge reçoit une couleur : rouge sous zéro, jaune de zéro à moins de vingt pour cent, vert à partir de vingt pour cent. Cette couleur facilite le balayage visuel, sans devenir une règle de décision enregistrée.

Le nom du fichier contient le mode, le format et l’horodatage de génération. Deux rapports successifs restent ainsi distinguables dans l’espace du compte.

13. Conserver l’historique de génération dans le cockpit

Date, statut, progression, volume, durée et fichier

La page liste uniquement les rapports Offer Margin Detail du compte connecté, du plus récent au plus ancien. Chaque ligne montre sa date de demande et son état.

La progression, le nombre d’offres, la durée et le nom de fichier donnent des repères opérationnels. Une génération encore en cours ne ressemble pas à un fichier absent sans explication.

Quatre états structurent le cycle : en attente, en génération, terminé ou en erreur. Leur couleur permet de distinguer rapidement un traitement disponible d’un passage qui demande une vérification.

L’historique ne stocke pas les quinze colonnes dans la page. Il référence le fichier produit et les métadonnées nécessaires pour le retrouver ou constater qu’il n’est pas prêt.

14. Autoriser le téléchargement seulement après la fin réelle

Un fichier terminé, référencé et encore présent

Le bouton de téléchargement apparaît uniquement lorsque le rapport est terminé et qu’un chemin de fichier a été enregistré. Les autres états affichent une action indisponible.

La route de téléchargement relit le rapport et vérifie qu’il appartient au compte de l’utilisateur. Un identifiant appartenant à un autre compte produit une ressource introuvable.

Elle vérifie ensuite le statut, le chemin et l’existence physique du fichier. Un rapport terminé dont le fichier a été déplacé ou supprimé n’envoie pas une réponse vide.

Lorsque tous les contrôles passent, le serveur renvoie le fichier avec son nom enregistré et une disposition de pièce jointe. Le navigateur peut alors le télécharger sans exposer son chemin interne.

15. Isoler rapport, fichier et calcul dans le compte demandeur

Trois contrôles avant qu’une donnée financière ne sorte

La demande prend le compte de l’utilisateur authentifié et l’associe au rapport. L’écran ne recherche ensuite que les rapports possédés par ce même compte.

Le worker compare l’identifiant du compte du message à celui du rapport avant d’accéder aux offres. Le fichier est rangé dans un répertoire propre à ce compte puis dans le sous-ensemble Offer Margin Detail.

Le téléchargement répète le contrôle de propriété. La connaissance d’un identifiant de rapport ne suffit donc ni à voir son statut dans une autre vue ni à récupérer son fichier.

Les requêtes de lignes financières ajoutent elles aussi le compte à l’offre. Cette redondance protège la revue lorsque plusieurs vendeurs emploient des identifiants d’offres proches.

16. Les arbitrages qui rendent le rapport utile sans le surpromettre

Choisir une convention explicite plutôt qu’un score opaque

Le premier arbitrage garde une ligne par offre, même en l’absence de vente éligible. Le fichier sert ainsi à détecter les trous de données autant qu’à comparer les marges renseignées.

Le deuxième sépare la dernière observation des moyennes. Une photographie et une tendance répondent à des questions différentes ; le rapport ne les additionne pas dans un indice unique.

Le troisième limite l’échantillon aux quantités unitaires et aux lignes dont la finance a été calculée. Cette homogénéité exclut volontairement certaines ventes au lieu de mélanger des montants non comparables.

Le quatrième privilégie le réel puis l’estimation, mais reconnaît que l’export ne porte pas encore cette provenance. La revue identifie une offre ; la vue détaillée reste nécessaire pour valider la décision.

17. Rendre visibles les limites de la version livrée

Une photographie financière, pas un moteur de repricing

Le rapport parcourt toutes les offres du compte et ne propose pas de filtre préalable par canal, marque ou catégorie. Ces dimensions sont exportées pour être filtrées après génération.

Les moyennes ne sont pas pondérées par quantité puisque seules les lignes de quantité égale à un sont retenues. Elles moyennent chaque composante séparément et ne remplacent pas un compte de résultat agrégé.

Le fichier ne distingue pas les coûts réels des coûts estimés, ne montre pas les causes de blocage et n’expose pas le détail des achats ayant fourni le coût. Ces preuves restent disponibles dans les écrans financiers dédiés.

Aucun seuil métier, alerte, prix recommandé, action de repricing ou décision de diffusion n’est produit. Une couleur dans le tableau compatible Excel facilite la lecture ; elle ne déclenche rien.

18. Ce qui change après la livraison

La revue de marge devient reproductible et partageable

Le commerce peut demander une photographie de la dernière vente unitaire ou choisir une fenêtre identique pour toutes les offres. La méthode de sélection n’a plus besoin d’être reconstruite dans un tableur.

La finance reçoit les mêmes quinze colonnes dans un ordre stable. Canal, produit, marque et catégorie donnent les axes de tri ; prix, TVA et coûts fournissent l’équation à contrôler.

Les offres sans observation restent visibles. Une cellule vide signale qu’aucune ligne unitaire calculée ne répond au mode choisi, ce qui permet de distinguer absence de donnée et marge nulle.

La génération asynchrone rend le traitement observable : état, progression par groupes de dix, nombre de lignes et durée. L’utilisateur n’a pas à maintenir une page ouverte pendant la construction.

Enfin, l’export devient une porte d’entrée vers la profitabilité marketplace. Il sert à repérer et partager ; les vues de commande, d’offre et les détecteurs spécialisés servent ensuite à expliquer.

19. Le scénario terrain qui résume le projet

Comparer une photographie récente avec une tendance de 90 jours

Une équipe prépare sa revue mensuelle. Elle demande d’abord un rapport basé sur la dernière ligne unitaire. Le traitement passe en génération, affiche sa progression puis rend un CSV contenant toutes les offres du compte.

Une offre ressort avec une marge négative alors que sa marque paraît globalement rentable. L’équipe génère un second rapport sur 90 jours et filtre les deux fichiers sur l’identifiant concerné.

La moyenne récente reste positive : la dernière observation constitue donc un écart à comprendre, pas encore une nouvelle règle de prix. Le fichier montre que le transport et le coût d’achat ont changé sur cette ligne.

Avant d’agir, le responsable ouvre la vue détaillée de l’offre et de la vente. Il vérifie si ces coûts sont réels ou estimés, retrouve leur origine et contrôle la quantité. Le rapport a trouvé le cas ; la vue en établit la preuve.

Si la marge négative se confirme, le cas peut rejoindre le Profit Leak Detector ou une décision de prix cadrée. Offer Margin Detail n’a pas pris cette décision à la place de l’équipe.

20. Relier le rapport aux vues de marge complémentaires

Dernière observation, agrégat et alerte interviennent à des niveaux différents

Le projet de marge par commande marketplace décrit le calcul transactionnel qui alimente les lignes utilisées par le rapport.

La marge par produit, marque et catégorie répond à la lecture regroupée. Offer Margin Detail conserve au contraire une sortie par offre.

Le Profit Leak Detector porte la recherche d’anomalies et leur classement. Le présent rapport fournit une comparaison exportable sans attribuer lui-même une sévérité.

Dans Ciama Marketplace, ces briques forment un parcours : calculer la vente, comparer les offres, ouvrir le détail, puis traiter une fuite ou encadrer une action de prix.