> For the complete documentation index, see [llms.txt](https://guideadmin.margipro.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guideadmin.margipro.com/supervision/comparaison-historiques-prix.md).

# Comparaison des historiques de prix entre sites

La fenêtre d'historique des prix propose une comparaison multisite commune aux pages **Prix**, **Tableau de bord**, **Marges** et **Paramètres → Ingrédients**.

## Périmètre d'accès

La liste des sites est toujours limitée à l'entreprise courante :

* un administrateur voit tous les sites de l'entreprise ;
* un gérant ou un acheteur ne voit que les sites présents dans ses affectations ;
* les politiques RLS Supabase restent le contrôle effectif des lectures.

Un site accessible mais sans historique pour le produit est affiché en grisé dans le sélecteur. Il n'est pas ajouté au graphique ni aux comparaisons.

## Sources de données

Le chargement est centralisé dans `src/shared/lib/price-history.ts`.

| Historique | Source                 | Filtres appliqués                                                                                                                                                                             |
| ---------- | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Achat      | `invoice_lines`        | Même entreprise, même produit et, quand elle est connue, même unité. Les lignes `is_excluded_from_aggregates = TRUE` sont exclues.                                                            |
| Vente      | `invoice_line_margins` | Même entreprise, même sous-produit et même `option_id`. Seules les marges validées avec un prix strictement positif sont retenues ; les lignes de facture exclues des agrégats sont ignorées. |

Les données sont triées par date de facture, puis par ordre d'import de la facture et de la ligne. Cette règle est partagée avec les pastilles de variation.

## Modes d'affichage

### Par site

Le graphique affiche une courbe par site sélectionné. Le tableau conserve le détail facture par facture d'un seul site, choisi sous le graphique. La moyenne MargiPro reste affichée lorsqu'elle est disponible.

### Comparer les achats

Le tableau croise les fournisseurs et les sites sélectionnés. Chaque cellule affiche le dernier prix connu du fournisseur sur le site, sa date et le nombre de factures disponibles.

La ligne **Dernier prix** reprend le dernier achat de chaque site, tous fournisseurs confondus. Le surcoût est calculé par rapport au prix le plus bas de la ligne, seulement entre valeurs de même unité et avec un prix de référence strictement positif.

### Comparer les ventes

Le tableau affiche le dernier prix validé de chaque site, la date, le nombre de factures et l'écart par rapport au site courant lorsqu'il reste sélectionné. Les options de maturation sont comparées séparément.

## Impact cumulé

Pour les historiques d'achat, l'impact est calculé séparément sur chaque site puis additionné. Tous les sites utilisent la même date de fin de période : la date la plus récente parmi les séries affichées. Les périodes proposées sont 1, 3, 6 et 12 mois.

Cette méthode évite de comparer un achat d'un site avec l'achat précédent d'un autre site.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://guideadmin.margipro.com/supervision/comparaison-historiques-prix.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.