> ## Documentation Index
> Fetch the complete documentation index at: https://docs.solya.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Modèle de données

> Données maîtres vs entités gérées par l'application, les couches d'analyse et les énumérations de statut de plan.

Les données de Solya se divisent en **données d'analyse** (ingérées, principalement en lecture, sur Databricks) et
**données gérées par l'application** (créées dans Solya, sur PostgreSQL). Voir
[Architecture](/fr/developers/architecture).

## Données maîtres (ingérées)

Le catalogue et les entités transactionnelles sont remplis par l'ETL de la plateforme données à partir des systèmes POS
(Polaris, Kezia) et sont **en lecture seule** dans l'application. Elles sont limitées à l'organisation.

| Entité                                                                        | Nature                                      |
| ----------------------------------------------------------------------------- | ------------------------------------------- |
| Magasins, marques, produits, variantes de produits, collections, fournisseurs | Dimensions de catalogue                     |
| Articles d'inventaire                                                         | Identité de stock produit × magasin         |
| Lignes de ventes, lignes de commande, lignes de mouvement                     | Faits transactionnels                       |
| Ledger de stock, snapshot de stock                                            | Stock au fil du temps / point dans le temps |

### Couches d'analyse

La plateforme données expose celles-ci comme des tables **silver** (nettoyées/normalisées) et **gold**
(prêtes à l'emploi métier) — p. ex. `fact_sales_lines`, `fact_order_lines`,
`fact_movement_lines`, `stock_ledger`, `stock_snapshot`, les dimensions `dim_*`,
les résumés `*_shop_analytics`, `sales_forecasts` et `decision_vector`. L'application les lit
pour les tableaux de bord, les KPIs, la recherche, les alertes et les recommandations.

```mermaid theme={null}
graph LR
  subgraph analytics["Données analytiques (Databricks) — Lecture seule"]
    direction TB
    pos["Systèmes POS<br/>(Polaris, Kezia)"]
    etl["Pipeline ETL"]
    silver["Couche Silver<br/>(normalisée)"]
    gold["Couche Gold<br/>(métier)"]

    pos --> etl
    etl --> silver
    silver --> gold
  end

  subgraph app["Données gérées par app (PostgreSQL) — Créées dans Solya"]
    direction TB
    plans["Plans<br/>d'inventaire"]
    rules["Règles métier<br/>& Ensembles"]
    budget["Enveloppes<br/>budgétaires"]
    curves["Courbes<br/>de taille"]
    alerts["Alertes & Tags"]
    workflows["Workflows"]
    audit["Journal d'audit"]
  end

  gold -->|lire| plans
  gold -->|lire| rules
  gold -->|lire| budget
  gold -->|lire| alerts
  
  style analytics fill:#e8f5e9,stroke:#2e7d32,color:#000
  style app fill:#e3f2fd,stroke:#1565c0,color:#000
```

<Note>
  Parce que les données de catalogue sont ingérées, vous ne créez pas de magasins/produits/variantes dans l'application —
  elles arrivent par l'ingestion. Voir la [Couche données](/fr/data-layer/overview).
</Note>

## Données gérées par l'application (créées dans Solya)

Tout ce que vous créez se trouve dans PostgreSQL et est limité à l'organisation : plans d'inventaire et leurs
articles, règles métier et jeux de règles, enveloppes budgétaires, courbes de tailles, calendriers de démarque,
contraintes fournisseurs, politiques d'approbation/retour, listes org, alertes, étiquettes et règles de tagging,
workflows, paramètres, modèles de navigation et le journal d'audit. Chaque nouvelle table documente comment
ses données sont remplies, modifiées et à quel accès elles sont soumises.

## Énumérations de statut de plan

Les statuts exacts par type de plan (utilisés par l'API et surfacés dans l'interface utilisateur) :

| Plan                | Statuts                                                     |
| ------------------- | ----------------------------------------------------------- |
| Réassort            | `DRAFT → VALIDATED → SENT → RECEIVED → CLOSED`              |
| Rééquilibrage       | `DRAFT → VALIDATED → SENT`                                  |
| Démarque            | `DRAFT → VALIDATED → CLOSED`                                |
| Pré-saison          | `DRAFT → VALIDATED → SENT → CLOSED`                         |
| Retour fournisseur  | `DRAFT → SENT → CREDITED → CLOSED`                          |
| Échange fournisseur | `DRAFT → PROPOSED → AGREED → IN_TRANSIT → SETTLED → CLOSED` |

Le **statut d'article de plan** est partagé : `TO_REVIEW` et `READY_FOR_ORDER`. Les plans côté fournisseur
portent des énumérations supplémentaires — **codes de raison** de retour (p. ex. défaut, dommage en transit, mauvais
SKU/quantité, rappel, échec QC, autre), **types de source** de retour (réassort, pré-saison) et **côtés**
d'échange (retour, réception).

<Note>
  Ces valeurs de statut sont des identifiants stables sur lesquels vous pouvez brancher. Le cycle de vie conceptuel
  (transitions réversibles, moments de décision, approbations) est décrit dans
  [Plans d'inventaire → Cycle de vie](/fr/inventory-plans/lifecycle).
</Note>