mirror of
https://github.com/R0m1k3/CollectFlow.git
synced 2026-10-11 17:26:32 +02:00
fix(qlik): piloter le champ Période du modèle au lieu de lutter contre lui
Le dump des expressions donne enfin la cause de fond :
« Quantité N » = Sum({<Type_Cal={'N'}>} quantite)
« Quantité COMP » = Sum({<Type_Cal={'$(vPeriod_comp)'}…>} quantite)
« Magasin Ventes Nb N » = Count({<Type_Cal={'N'}>} Distinct ventes_code_site)
L'app n'est pas un modèle « faits + calendrier ». Un pont de périodes duplique
les lignes de faits : Type_Cal='N' marque celles de la période analysée, 'COMP'
celles de la période de comparaison, et le champ Période (4 valeurs, une
sélectionnée) décide de quelle période il s'agit. Tout en découle :
- sélectionner Date ne change rien (mesuré : 100 % du total avant comme après),
le périmètre venant du pont de périodes et non du champ date ;
- « Quantité N » ne couvre que la période courante, d'où août→décembre vides ;
- « Quantité COMP » ne couvre que les mois ayant un comparable, d'où
janvier→juillet de l'année précédente ;
- Sum(quantite) brut additionne les lignes N ET COMP : il double compte, il ne
pouvait pas servir de substitut.
choisirPeriode() essaie donc chaque valeur de Période, mesure sur un cube
[Mois] × Quantité N combien de mois de la fenêtre elle rend réellement
disponibles, et garde la meilleure. Aucun libellé n'est deviné : c'est la
couverture mesurée qui décide, et elle est tracée. Si aucune valeur ne couvre
les 12 mois, les mois manquants restent absents du cache.
Aussi :
- Les mois réellement couverts reçoivent un zéro EXPLICITE quand l'article n'a
pas vendu ; la tendance ne retient que les mois présents comme clés. Un article
vendu depuis mai voyait sa tendance calculée sur deux points (« +4100 % »).
- Les diagnostics du chemin d'extraction sont répétés en fin de sync
([qlik-pw][diag]) : ils étaient au début d'un log de plusieurs milliers de
lignes.
- QLIK_USE_EXPR passe à désactivé par défaut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
This commit is contained in:
3 files changed
+249
-46
No files matched your search
@@ -78,6 +78,50 @@ QLIK_FIELD_FOURNISSEUR=<nom exact du champ fournisseur>
|
||||
|
||||
Sans champ libellé exploitable, la recherche fonctionne encore par code centrale.
|
||||
|
||||
## Le modèle est piloté par `Période` / `Type_Cal` — pas par `Date`
|
||||
|
||||
**C'est l'explication de fond**, obtenue en dumpant les expressions réelles :
|
||||
|
||||
```
|
||||
« Quantité N » = Sum({<Type_Cal={'N'}>} quantite)
|
||||
« CA N » = Sum({<Type_Cal={'N'}>} $(vCA_vat))
|
||||
« Quantité COMP » = Sum({<Type_Cal={'$(vPeriod_comp)'}$(vConstantCOMP)>} quantite)
|
||||
« Magasin Ventes Nb N » = Count({<Type_Cal={'N'}>} Distinct ventes_code_site)
|
||||
```
|
||||
|
||||
L'app n'est pas un modèle « faits + calendrier » classique. Un **pont de périodes**
|
||||
duplique les lignes de faits : `Type_Cal='N'` marque celles de la période
|
||||
analysée, `'COMP'` celles de la période de comparaison. Et c'est le champ
|
||||
**`Période`** (4 valeurs, une sélectionnée) qui décide de quelle période il s'agit.
|
||||
|
||||
Tout ce qu'on observait en découle :
|
||||
|
||||
| Symptôme | Cause |
|
||||
|---|---|
|
||||
| Sélectionner `Date` ne change rien (100 % du total avant/après) | Le périmètre vient du pont de périodes, pas du champ date |
|
||||
| Août→décembre vides sur tous les articles | « Quantité N » ne couvre que la période courante (janvier→juillet) |
|
||||
| Janvier→juillet de l'année précédente renseignés | Ce sont les mois que « Quantité COMP » sait atteindre |
|
||||
| `Sum(quantite)` brut inexploitable | Il additionne les lignes N **et** COMP : il double compte |
|
||||
|
||||
La solution n'est donc pas de contourner le modèle mais de **le piloter** :
|
||||
`choisirPeriode()` essaie chaque valeur de `Période`, mesure sur un cube
|
||||
`[Mois] × Quantité N` combien de mois de la fenêtre elle rend réellement
|
||||
disponibles, et garde la meilleure. Aucun libellé n'est deviné — c'est la
|
||||
couverture mesurée qui décide :
|
||||
|
||||
```
|
||||
[qlik-pw][diag] valeurs de « Période » : ["Année en cours","12 mois glissants","Mois","Semaine"]
|
||||
[qlik-pw][diag] Période « Année en cours » → 7/12 mois de la fenêtre [...]
|
||||
[qlik-pw][diag] Période « 12 mois glissants » → 12/12 mois de la fenêtre [...]
|
||||
[qlik-pw][diag] Période retenue : « 12 mois glissants » (12/12 mois)
|
||||
```
|
||||
|
||||
Si aucune valeur ne couvre les 12 mois, l'extraction le dit et les mois manquants
|
||||
restent **absents** du cache — jamais remplis d'une valeur plausible.
|
||||
|
||||
`QLIK_USE_EXPR=1` réactive l'ancien essai par agrégation directe des faits ; il
|
||||
est désactivé par défaut puisque `Sum(quantite)` double compte.
|
||||
|
||||
## ⚠️ Les master measures « N » ignorent la sélection Date
|
||||
|
||||
**Constat de production, vérifié arithmétiquement.** Avec août 2025 seul
|
||||
|
||||
Reference in new issue
Block a user