Créer un rapport de ventes hebdomadaire depuis votre base
Préparez une revue commerciale qui explique les ventes, les remboursements et la contribution de chaque segment client.
Par l'équipe Datarelix · Publié le · Mis à jour le · Vérifié le
Un rapport de ventes hebdomadaire demande une définition plus précise qu’un total intitulé « chiffre d’affaires ». Choisissez entre commandes passées, paiements encaissés et revenu comptabilisé, puis définissez la période et les remboursements. Ces choix déterminent la requête et le sens du résultat ; dans Datarelix, vous les énoncez dans la question elle-même lorsque vous interrogez la base en langage naturel.
Il vous faut une connexion autorisée aux tables ou vues utiles.
Définir la mesure et la semaine
L’exemple couvre les commandes payées datées du lundi 31 août au dimanche 6 septembre 2026. L’intervalle commence le 31 août à 00:00 et s’arrête avant le 7 septembre à 00:00, en UTC. Les montants sont en euros hors taxes. Le segment client est celui enregistré lors de la commande.
Les remboursements sont ceux enregistrés sur ces commandes au 10 septembre. Un remboursement effectué cette semaine pour une ancienne commande relève d’un autre rapport sur les mouvements de trésorerie. Convenez de cette distinction avant de comparer les totaux, et consignez-la comme contexte du schéma et définitions métier pour garder les questions suivantes cohérentes.
| Commande | Segment | Montant payé, EUR | Remboursements à la date de revue, EUR |
|---|---|---|---|
| 101 | Retail | 120 | 20 |
| 102 | Retail | 80 | 0 |
| 103 | Wholesale | 300 | 50 |
| 104 | Wholesale | 200 | 0 |
Les quatre commandes appartiennent à la semaine. Le montant payé est de 700 EUR, les remboursements de 70 EUR et la différence de 630 EUR.
Demander le tableau
Pour les commandes payées datées du 31 août au 6 septembre 2026, en UTC, affiche le montant payé et les remboursements sur ces commandes enregistrés avant le 11 septembre. Utilise les euros hors taxes et le segment enregistré sur la commande. Présente la différence dans une colonne séparée.
Si vos commandes sont dans PostgreSQL, interroger PostgreSQL en langage naturel décrit les accès nécessaires. Cet exemple PostgreSQL regroupe les remboursements par commande avant la jointure. Plusieurs remboursements ne doivent pas dupliquer le montant d’origine :
WITH refunds_per_order AS (
SELECT order_id, SUM(amount_eur) AS refund_eur
FROM refunds
WHERE refunded_at < TIMESTAMPTZ '2026-09-11 00:00:00+00'
GROUP BY order_id
)
SELECT o.segment_at_order,
SUM(o.paid_value_eur) AS paid_value_eur,
SUM(COALESCE(r.refund_eur, 0)) AS refund_eur,
SUM(o.paid_value_eur - COALESCE(r.refund_eur, 0)) AS after_refunds_eur
FROM orders o
LEFT JOIN refunds_per_order r ON r.order_id = o.order_id
WHERE o.paid_at IS NOT NULL
AND o.ordered_at >= TIMESTAMPTZ '2026-08-31 00:00:00+00'
AND o.ordered_at < TIMESTAMPTZ '2026-09-07 00:00:00+00'
GROUP BY o.segment_at_order;
Le calcul suppose que paid_value_eur contient le montant payé hors taxes convenu, que l’identifiant de commande est unique et que la table des remboursements contient des remboursements réalisés. Des remboursements en attente, des paiements partiels ou plusieurs devises demandent d’autres règles. Ne cumulez pas plusieurs devises sans base de conversion définie.
Contrôler le résultat
| Segment | Montant payé, EUR | Remboursements, EUR | Après remboursements, EUR |
|---|---|---|---|
| Retail | 200 | 20 | 180 |
| Wholesale | 500 | 50 | 450 |
Les deux segments totalisent 630 EUR après remboursements. Si la commande 103 possède deux remboursements de 30 et 20 EUR, son montant initial de 300 EUR doit rester compté une seule fois. Faites vérifier ce cas et les dates limites par une personne qui maîtrise SQL, avec vérifier le SQL et les résultats générés par IA.
Vos contrôles métier portent sur le sens des segments, le traitement des paiements saisis tardivement et le total de référence utilisé par l’équipe commerciale. Un écart peut venir de la définition, des données ou de la requête.
Répartir les contrôles de la revue
Le responsable commercial confirme s’il s’agit d’une cohorte de commandes ou des paiements et remboursements reçus pendant la semaine. L’analyste vérifie la clé de commande, le segment à la date de commande et l’agrégation des remboursements multiples. Gardez la même définition dans le titre du graphique et le rapport de rapprochement.
Conservez des exemples aux deux bornes de semaine et une commande avec plusieurs remboursements. Pour un paiement saisi tardivement, décidez de son inclusion et de la date de revue. Si l’historique de segment ou statut manque, documentez cette limite sans reconstituer le passé à partir du seul profil actuel du client.
Réutiliser le rapport
Demandez un graphique en barres du montant après remboursements par segment. Les valeurs doivent être Retail 180 et Wholesale 450. Ajoutez le graphique vérifié à un tableau de bord Datarelix privé. Conservez les remboursements dans un graphique séparé si l’équipe doit les examiner.
La requête fixe la semaine et la date de revue des remboursements. Un rapport hebdomadaire évolutif demande des dates relatives explicites ; les totaux historiques peuvent changer avec de nouveaux remboursements. L’actualisation manuelle relance le calcul conservé. Les images exportées restent des instantanés.
Suivez le parcours des tableaux de bord ou connectez votre source pour commencer par une semaine dont vous pouvez rapprocher les totaux.