Trois defauts signales, trois causes distinctes.
1. LA COURBE DES MAGASINS N'APPARAISSAIT PRESQUE JAMAIS.
L'extracteur ecrivait `{ qte: 0 }` sur les mois sans vente, sans
`nbMag`. La serie exigeant les 12 mois, elle disparaissait des qu'un
produit avait un mois creux — c'est-a-dire presque toujours. Un mois
PRESENT dans le detail est un mois extrait : s'il n'a pas de nbMag,
c'est que personne n'a vendu, donc zero. Corrige a la source ET a la
lecture, pour que les caches deja ecrits repartent sans re-sync.
2. LES DEUX COURBES ETAIENT ILLISIBLES SUPERPOSEES.
Deux echelles independantes placaient la courbe des magasins AU-DESSUS
de celle des quantites : cela se lit spontanement comme « il y a plus
de magasins que de ventes », un contresens. Les series sont desormais
tracees dans DEUX BANDES distinctes alignees sur le meme axe des mois.
On compare la forme de l'une avec la forme de l'autre, sans jamais
suggerer un rapport de grandeur.
3. LES POURCENTAGES N'AVAIENT PAS DE SENS.
La pente d'une regression rapportee a la moyenne donnait « -124 % »
(une baisse ne peut pas depasser -100 %), « +1 062 % » pour 2 unites
vendues une fois dans l'annee, et surtout « +508 % » sur des dizaines
de lignes d'affilee — la signature arithmetique d'une serie nulle
partout sauf le dernier mois, ou le rapport ne depend meme plus des
quantites. On compare maintenant deux moyennes de 4 mois : variation
qui se lit comme telle, plancher a -100 %, insensible au bruit d'un
mois isole. Sans base de comparaison, aucun pourcentage n'est
invente — le produit est marque « Nouveau », et le tri le remonte en
tete au lieu de l'enterrer.
Le graphique accepte aussi des quantites negatives (retours superieurs
aux ventes sur un mois) : l'echelle part du minimum reel, le point ne
sort plus du cadre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
La courbe des quantites prend la couleur de la TENDANCE : vert, rouge, ou
gris-bleu (#94a3b8) quand elle est stable. L'indigo des magasins se
detache du vert et du rouge, mais il est trop proche du gris-bleu — or
« stable » est le cas le plus frequent.
storesColorFor() bascule sur l'ambre (#f59e0b) dans ce cas precis : gris
froid contre orange chaud, impossible a confondre.
Les deux series se distinguent desormais par TROIS canaux, pas seulement
la couleur — qui ne suffit ni en impression noir et blanc, ni pour un
daltonien :
- teinte garantie differente,
- trait pointille contre trait plein,
- points evides contre points pleins.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Une quantite qui monte parce que le produit est diffuse dans plus de
magasins ne raconte pas la meme histoire qu'une quantite qui monte a
diffusion constante. La courbe des quantites seule ne permettait pas de
distinguer un succes produit d'un simple elargissement.
- computeStoresSeries() : serie « magasins vendeurs » sur la MEME fenetre
12 mois que la tendance, avec la meme regle du tout ou rien — les 12
cles doivent etre presentes, sinon null. Un mois non extrait ne doit
pas se lire comme « zero magasin », ce qui simulerait un arret de
diffusion.
- nbMagReseauByMonth remonte du cache (metricsByMonth, deja stocke par la
sync) jusqu'a la ligne de grille.
- NetworkLineChart accepte une serie `stores` optionnelle.
DEUX ECHELLES INDEPENDANTES : les quantites se comptent en milliers, les
magasins plafonnent a ~270. Sur une echelle commune la courbe des
magasins serait ecrasee sur l'axe et ne montrerait rien. Chaque serie est
normalisee sur son propre maximum, rappele dans la legende — c'est la
FORME des deux courbes qu'on compare, pas leurs hauteurs. La courbe des
magasins est pointillee et indigo, pour ne jamais entrer en collision
avec le vert/rouge/gris de la tendance.
Branchee sur la carte de la Grille et sur celle de la fiche produit. La
sparkline de la colonne reste a une seule courbe : 46x18 px, deux traces
y seraient illisibles.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Premier run reussi : 12 mois couverts, 40 411 produits ecrits dans le
cache, statut final=success.
Ce que la sonde paginee montre enfin :
Periode « (aucune) » → master exposee : 2024-01…2026-07 (31 mois)
Sans aucune Periode selectionnee, « Quantite N » couvre 31 mois, et une
seule passe (Annee=2026) sert les 12 mois de la fenetre. L'etat libre
etait donc le bon depuis le debut ; ce sont deux defauts de l'outil de
MESURE qui le cachaient — la sonde tronquee a 60 lignes, puis le Clear
appele sur le list object. Le commentaire de choisirPeriode affirmait
l'inverse (« sans Periode la master est morte ») : il est rectifie, avec
la mesure a l'appui.
Sonde fournisseur : elle lisait 1 207 205 codes en 240 pages avant de
conclure, trois fois de suite — 87 s pour un rejet joue d'avance. La
lecture s'arrete desormais des le plafond depasse.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Le journal complet (enfin lisible) donne la cause, et elle est unique :
choix de « Periode » impossible :
{"code":-32601,"parameter":"Clear","message":"Method not found"}
extraction par date brute interrompue :
{"code":-32601,"parameter":"Clear","message":"Method not found"}
Clear et SelectValues sont des methodes de CHAMP. Je les appelais sur le
list object « Periode ». Consequence : la cartographie des periodes ET le
chemin d'extraction par date brute n'ont jamais tourne — d'ou la
couverture master annoncee a 0/12 alors que la master vit (total mesure :
11 591 263).
- Handle du champ « Periode » obtenu comme ceux d'Annee et de Date ; le
list object ne sert plus qu'a ENUMERER les valeurs.
- appliquerPeriode selectionne par texte et ne propage plus d'erreur :
une periode qu'on n'arrive pas a poser doit degrader le resultat, pas
interrompre l'extraction.
- Chaque candidat de la cartographie est isole : une valeur en echec est
notee et ignoree, elle n'emporte plus toute la carte.
Sonde fournisseur : « J009 » laissait 1 207 205 articles visibles, soit
tout le catalogue — la selection ne restreignait rien, et la
« couverture » de 97 % ne faisait que constater que le catalogue contient
nos codes. Une selection qui laisse plus de 3x les codes demandes est
desormais rejetee immediatement (elle coutait 3 x 24 s de lecture).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Une extraction Qlik produit plusieurs milliers de lignes de diagnostic.
Un terminal les tronque et n'en laisse que la fin, alors que
l'information decisive — carte du modele Qlik, champs date retenus,
choix des periodes — se trouve en TETE. Diagnostiquer sur la fin du log
revient a travailler a l'aveugle.
- src/lib/log-capture.ts : instrumente console.log/warn/error une fois,
recopie chaque ligne horodatee dans les captures ouvertes, ecrit au fil
de l'eau dans le repertoire temporaire (un job qui fait tomber le
process laisse quand meme son journal). Bornes : 200 000 lignes,
8 000 caracteres par ligne, 20 fichiers conserves.
- GET /api/logs : liste JSON ; GET /api/logs?id=<jobId> : le fichier
complet en piece jointe. Admin uniquement.
- La sync Qlik ouvre la capture AVANT son premier log et la ferme dans un
finally, avec le statut final — les deux modes (fournisseur et produit).
- Parametres : section « Journaux serveur », un bouton Telecharger par
job, le plus recent en premier, badge « en cours » pour un job vivant.
Aucun secret ne transite dans ces journaux : l'extracteur ne journalise
que le NOM du cookie de session, jamais sa valeur ni le mot de passe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Le log livre le fait qui manquait :
dimension « Mois » → 35602068 (100% du total sans filtre)
100 %, donc TOUTE la table de faits tient dans les 12 mois. Le test de
champ date « il doit faire baisser le total » etait donc structurellement
faux : n'importe quel champ correct donne 100 % quand la fenetre couvre
tout. Il rejetait les bons champs, ce qui condamnait le seul chemin sain
et renvoyait vers la dimension Mois — celle qui demultiplie les faits.
Nouveau chemin moisParDateBrute(), essaye AVANT l'agregation par
dimension :
- Type_Cal / Periode / Annee effaces : on veut les faits nus, pas un
contexte de calendrier. Plus aucun mois « inatteignable », puisqu'un
mois y est un filtre de dates.
- detection du champ date sur UN SEUL MOIS : valide si le total est non
nul ET une fraction du total (ni 0, ni 100 %).
- cube [Article Code] x 4 expressions, SANS dimension Mois : c'est elle
qui passe par le pont et rattache un fait a plusieurs contextes
(mesure : x5,3).
- 12 selections de dates, 12 cubes pagines, un point de controle par
mois.
Controle d'integrite : chaque mois doit etre servi, et la somme des 12
mois ne doit pas depasser le total sans filtre de date — une
demultiplication ferait exploser ce rapport. Sinon rien n'est ecrit.
Corrige aussi le meme test defectueux dans moisParExpressions, et permet
d'effacer Periode meme si son list object n'a pas pu etre cree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Deux defauts, l'un cachant l'autre.
1. La sonde de couverture ne lisait que les 60 premieres lignes du cube
[Mois] x Quantite N. La dimension Mois porte tout l'historique de
l'app : les mois recents tombaient hors de la premiere page et la
sonde annoncait 0/12 pour TOUTES les valeurs de Periode — alors que
la master vivait (mesure dans le meme log : total 9 721 153). C'est
ce faux zero qui faisait effacer Periode et condamnait l'extraction.
Le cube est desormais pagine integralement, et la sonde journalise
aussi ce que la master expose hors fenetre.
2. La bonne valeur de Periode DEPEND DE L'ANNEE. « Annee a date »
convient a 2026 (janvier -> mois courant) mais pas a 2025, dont on
veut les 12 mois. Le choix global ne pouvait donc satisfaire que
l'une des deux passes — ce que montrait le log : 2026 servait
2026-01..06, la passe 2025 ne servait rien.
choisirPeriode cartographie maintenant, pour chaque annee de la
fenetre, la valeur qui sert le plus de mois attendus de cette
annee-la (l'etat sans Periode etant un candidat comme un autre), et
chaque passe annuelle pose SA valeur avant de selectionner l'annee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Le log de production tranche : sans selection de Periode, les master
measures sont MUETTES. Les passes annuelles renvoyaient bien 270 056
lignes, mais toutes mesures nulles — d'ou « 0 point mensuel ajoute »
puis le refus des 12 mois.
choisirPeriode() jugeait chaque valeur de Periode SANS annee
selectionnee. « Annee a date » y parait couvrir 6/12 mois, donc etait
rejetee, donc Periode etait effacee — et tout mourait. Or avec
Annee=2025 selectionnee, la meme valeur donne l'annee 2025 COMPLETE
(l'app affiche « Du 02/01/2025 au 31/12/2025 »), et avec Annee=2026 elle
s'arrete au mois courant. L'union des deux passes fait bien 12 mois.
- La couverture d'une Periode est desormais mesuree comme l'UNION des
passes annuelles, exactement comme monthDimPath les executera.
- La meilleure valeur est CONSERVEE meme partielle ; seule une
couverture nulle justifie d'effacer.
- Annees traitees la plus recente d'abord (usage de l'app), arret des
que la fenetre est complete.
- Diagnostics : mois gagnes / encore manquants apres chaque passe, et
liste des mois manquants dans les messages d'echec.
- Une passe ne peut plus ecraser un mois servi par un zero.
Deux defauts prouves par le meme log, cote agregation directe :
- la master « Quantite N » morte vidait TOUT l'hypercube (4 expressions
valides a 6 mois, cube complet a 0 ligne) : elle est desormais sondee
et omise si morte ;
- ventilee par Mois, Sum(quantite) totalise 179 574 616 contre
33 945 285 sans dimension (x5,3) : la dimension Mois passe par le pont
de periodes et demultiplie les faits. Ce chemin est refuse plutot que
d'ecrire des ventes reseau fausses.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Le code fournisseur FF de la base SQL/API existe aussi dans Qlik : une
seule valeur y designe le meme perimetre que les dizaines de milliers de
codes articles. Comme SelectValues sur « Article Code » coute 8 a 100 s
par appel et doit etre refait a chaque passe annuelle, la bascule
supprime la partie la plus couteuse de la sync.
- ETAPE 0 : selectionnerParFournisseur() avant choisirPeriode().
- Essaie QLIK_FIELD_CODE_FOURNISSEUR puis code_fournisseur, Fournisseur,
fournisseur_code_centrale.
- Verifie la couverture reelle (Article Code visibles vs codes demandes)
et n'accepte la bascule qu'au-dela de QLIK_SUPPLIER_MIN_COVERAGE
(0.99 par defaut) ; sinon annule la selection et revient aux codes.
- Quand la bascule est retenue, plus aucun SelectValues sur Article Code
(passes annuelles et agregation par expressions).
- La sync fournisseur transmet job.fournisseur ; la sync produit (un seul
code centrale) reste inchangee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Deux remarques de l'utilisateur ont débloqué le sujet : « sur ce tableau j'ai
2024, 2025, 2026 et je sors mois par mois », et « tu mets 2026 et tu as la
comparaison N-1 ».
Type_Cal='N' ne désigne donc pas « l'année civile en cours » mais L'ANNÉE
SÉLECTIONNÉE. Il suffit d'enchaîner les années couvertes par la fenêtre (2025
puis 2026) pour reconstituer 12 mois glissants — chaque passe livrant les 5
mesures, et non la seule quantité comme « Quantité COMP ».
Ce mécanisme existait déjà (monthDimPath(yearN - 1)) mais restait sans effet :
[qlik-pw] (mois) passe N-1 terminée : 299905 → 299905 points mensuels
La sélection « Période », héritée de l'ouverture de l'app et jamais choisie par
nous (observé « Période:1/4 » dès le premier diagnostic de la session),
épinglait le contexte sur l'année en cours et annulait la sélection d'année.
- choisirPeriode() teste désormais EN PREMIER l'état sans aucune sélection de
Période — l'état dans lequel un utilisateur voit 2024/2025/2026 — et efface la
sélection dès que la couverture est incomplète.
- L'orchestration boucle sur les années de la fenêtre au lieu d'une passe
principale plus une passe N-1 dérivée de COMP.
- Chaque passe n'écrit que les mois DE LA FENÊTRE et les totaux s'additionnent
sur ces mois : deux années ne peuvent pas se doubler puisqu'elles ne partagent
aucun mois. « Quantité COMP » n'est plus utilisée.
- L'agrégation directe des faits reste en secours, et le garde-fou d'intégrité
reste actif : sans les 12 mois, le cache n'est pas écrit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Deux constats de la dernière sync.
1. AUCUNE valeur de « Période » ne porte 12 mois glissants — c'est mesuré :
« juin 2026 » 1/12, « Année à date » 6/12, « Mois à date » 0/12,
« Semaine 2026/30 » 0/12
Ce sont 4 contextes relatifs à aujourd'hui, pas des types de période. Les
master measures ne pourront donc jamais couvrir la fenêtre, et l'agrégation
directe des faits devient obligatoire.
D'où un bug du commit précédent : garder la meilleure Période (6/12) RESTREINT
les faits à 2026-01→06 et ampute l'agrégation directe, qui sait pourtant lire
tout l'historique. choisirPeriode() efface désormais la sélection quand la
couverture est incomplète, et ne la garde que si elle couvre les 12 mois.
2. Le cube à 5 mesures calculait 26 s puis rendait 0 ligne, alors que
Sum(quantite) seul donnait 35 424 324 : signature d'une mesure invalide qui
invalide tout l'hypercube, sans qu'aucun message ne dise laquelle.
validerExpression() teste maintenant chaque expression isolément sur un petit
cube [Mois] avant de construire le gros. Une expression invalide est remplacée
par la colonne neutre 0 — le cube reste exploitable et le log nomme la
coupable. Seule la quantité est bloquante.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Fusion de deux lignes de travail parallèles sur main, complémentaires et non
concurrentes :
cd2e77e selectionnerFenetreViaDimensionMois() — sélectionne les 12 mois par
qElemNumber sur la dimension maître Mois. C'est ce qui marche : les
champs Date exposés sont dissociés des faits (100 % du total avant
comme après), la dimension maître porte les vraies valeurs.
4ef0e9f garde-fou d'intégrité — refuse d'écrire le cache si la fenêtre n'est
pas entièrement couverte. C'est pourquoi le cache est resté inchangé
au lieu d'être corrompu.
726fb84 choisirPeriode() — le maillon manquant.
Le dump des expressions donne la cause de fond :
« Quantité N » = Sum({<Type_Cal={'N'}>} quantite)
« Quantité COMP » = Sum({<Type_Cal={'$(vPeriod_comp)'}…>} quantite)
Un pont de périodes duplique les lignes de faits ; Type_Cal marque la période
analysée (N) ou de comparaison (COMP), et le champ Période (4 valeurs) décide
de quelle période il s'agit. Sélectionner correctement les mois ne suffit donc
pas : sous la période par défaut, « Quantité N » rend 0 sur tout mois hors
période courante, même parfaitement sélectionné.
Orchestration fusionnée :
1. choisirPeriode() essaie chaque valeur de Période et MESURE, sur un cube
[Mois] × Quantité N, combien de mois de la fenêtre elle rend disponibles.
Aucun libellé n'est deviné.
2. Si une période couvre les 12 mois → master measures (exactes sur toute la
fenêtre). Sinon → agrégation directe des faits, en secours.
3. Dans les deux cas, la couverture des 12 mois est revérifiée avant
persistance ; sinon l'extraction est refusée et le cache laissé intact.
La tendance conserve la règle stricte de 4ef0e9f (les 12 clés explicitement
présentes, ou pas de tendance), qui écarte aussi le « +4100 % » calculé sur deux
points pour un article vendu depuis mai.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
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
Le log de la dernière sync montre batches=3 et des lignes « (rattrapage) » : le
chemin par expressions a bien tourné mais a été rejeté (quantité totale nulle),
et c'est le rattrapage qui a de nouveau recopié le total de période dans les mois
manquants — d'où les plateaux à 87 648 d'août à décembre et les « -162 % ».
- Passe de rattrapage SUPPRIMÉE. Elle ré-extrayait un mois vide en ne
sélectionnant que ses dates ; les master measures ignorant la sélection Date,
le cube lui renvoyait le total de période. Un mois qu'on ne sait pas extraire
doit rester absent, jamais rempli d'une valeur plausible.
- Le chemin par expressions vérifie maintenant qu'un champ date filtre RÉELLEMENT
les faits, ce que personne n'avait pu contrôler tant que seules des mesures
insensibles à la sélection étaient utilisées. Un total de contrôle
(Sum(quantite) sans dimension) est comparé avec et sans filtre ; un champ n'est
retenu que si le total est non nul ET strictement inférieur au total global.
Candidats : QLIK_DATE_FIELD, Date, Date calendrier, Date_Key (ce dernier
sélectionné au format AAAAMMJJ). Si aucun ne filtre, l'extraction le dit
clairement au lieu de produire une fenêtre fausse.
- Diagnostic : échantillon BRUT du cube loggué avant tout filtrage (mois brut,
mois normalisé, appartenance à la fenêtre, valeurs des cinq mesures), et
compteur de lignes écartées comme hors fenêtre. Ces deux traces distinguent une
expression invalide d'un format de dimension Mois inattendu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Le serveur Qlik est filtré par IP : injoignable depuis l'extérieur du réseau FF
(la passerelle d'egress tombe en connection timeout sur 443 comme sur 80, alors
qu'elle atteint le reste d'Internet). Impossible donc de valider à distance les
expressions par défaut ni la clé de jointure.
Ce script répond aux deux questions en une exécution, à lancer depuis le
conteneur de l'app :
- expressions réelles des master measures (CA N, Quantité N, COMP…) ;
- tableau mois par mois comparant Sum(quantite) / Sum(ca_ht) / Sum(ca_ttc) /
Count(DISTINCT [Magasin Code]) aux mesures « N », sur l'année en cours (où
elles doivent coïncider) et sur l'année précédente (où les « N » sont
censées être à 0) ;
- Article Code, article_no_centrale et article_codein côte à côte, pour
trancher la jointure avec articles.artcentrale.
Lecture seule : sélections en soft lock, objets de session détruits. Le mot de
passe vient de l'environnement, rien n'est écrit ni affiché.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Preuve arithmétique dans les logs : pour l'article 10000397784, qteReseau=164 et
caReseau=2220,75 € sont EXACTEMENT la somme de janvier à juillet 2026
(12+19+24+27+22+31+29 = 164). Et la passe de rattrapage, avec août 2025 seul
sélectionné, a renvoyé ces mêmes 164 / 2220,75 — puis les a recopiés dans les
cinq mois manquants.
« CA N » et « Quantité N » sont donc des mesures « cumul année en cours »,
insensibles au champ Date. Aucune sélection ne peut leur faire produire une
fenêtre 12 mois glissants. D'où, simultanément :
- des totaux réseau qui étaient un cumul année en cours, mois courant partiel
inclus, et non 12 mois glissants ;
- les mois de l'année précédente non couverts par « Quantité COMP » vides sur
tous les articles ;
- un rattrapage qui y recopiait le total de période.
Le chemin nominal agrège désormais directement les champs de faits, qui eux
respectent les sélections : Sum(quantite), Sum(ca_ht),
Count(DISTINCT [Magasin Code]), Sum(marge) — tous surchargeables par
QLIK_EXPR_QTE / _CA / _NBMAG / _MARGE. Un seul cube [Article Code, Mois] couvre
les 12 mois : ni passe N-1 ni rattrapage, c'est ce qu'ils compensaient. Les
totaux deviennent la somme des 12 mois de la fenêtre.
Garde-fous : « Quantité N » reste dans le cube pour calibrage et le log compare
les deux sur les mois de l'année en cours (seul périmètre où elle est juste) ;
quantité totale nulle ou erreur Engine → repli automatique sur l'ancien chemin ;
QLIK_USE_EXPR=0 le force.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Les timings de production sont sans appel : SelectValues sur « Article Code »
coûte 8 à 100 s PAR APPEL, quasi indépendamment du nombre de valeurs (le moteur
balaie un symbole de plus d'un million d'entrées). Avec 7 200 codes en lots de
300, cela faisait 24 appels, ~15 min de sync, et la session Qlik mourait avant
la fin — « Socket closed » puis « Execution context was destroyed » — en perdant
la totalité de l'extraction.
- Le chemin mensuel fait désormais UNE seule sélection pour tous les codes et un
seul cube paginé : la dimension Mois livre déjà tous les mois d'un coup, rien
n'obligeait à découper. La lecture des pages coûte ~50 ms. Repli automatique
sur les lots si l'Engine refuse (les lignes déjà lues sont retirées pour ne
pas doubler les totaux).
- rattraperMoisVides() adopte le même principe : une sélection de codes, puis
seule la fenêtre de dates change d'un mois à l'autre.
- Sonde de diagnostic de fin de sync retirée : elle refaisait une sélection
complète des codes et des 365 jours pour rien.
- Point de contrôle (cfCheckpoint) poussé après chaque passe. Si la session
meurt, l'extraction repart de là : les codes déjà traités ont des données
complètes, seul le reliquat manque. Le log signale « résultat PARTIEL ».
- Le script in-page remonte aussi ses lignes en cas d'erreur interne, et
« rows=[object Object] » dans les logs est corrigé.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Cinq mois consécutifs à 0 sur TOUS les articles n'est pas un résultat métier.
Les mesures « N » de l'app Qlik sont bornées à une année civile ; le chemin
« dimension Mois » sélectionne les 365 jours d'un coup, donc la mesure ne se
résout que sur une année et les mois de l'année précédente ressortent vides.
« Quantité COMP » ne rattrape que les mois ayant un comparable dans l'année en
cours — d'où le trou d'août à décembre 2025 observé en juillet 2026.
- La passe principale n'écrit plus de 0 pour un mois hors année N, et COMP
n'écrit rien quand elle est vide : un mois absent peut être rattrapé, un mois
à 0 se lit comme « pas de vente » et masque le trou définitivement.
- Nouvelle passe rattraperMoisVides() : tout mois resté vide pour tous les
articles est ré-extrait en ne sélectionnant QUE ses dates. La mesure se résout
alors sur la bonne année quelle que soit l'écriture de son set analysis. Elle
ne touche que le mensuel, jamais les totaux de période.
- Les expressions des master measures sont dumpées au log : sans elles,
impossible de savoir comment la mesure est bornée dans le temps.
Contournement sans redéploiement : QLIK_MONTH_DIM=0 (itération mois par mois,
plus lente mais sans trou). Les données déjà en cache gardent leurs zéros — il
faut relancer la sync pour les corriger.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
La sync de la Grille marche parce qu'elle est SEULE sur le serveur Qlik. La
recherche, elle, ouvrait une seconde session concurrente pour les mesures
pendant que la première tenait une énorme sélection : l'Engine coupait les
requêtes (code 15 « Request aborted »).
- Les mesures réseau (CA, quantité, magasins, CA/magasin, marge %) sortent
désormais du MÊME cube que l'identité, dans la même session : la fenêtre 12
mois glissants est sélectionnée sur le champ Date, les master measures sont
résolues par titre comme dans l'extraction de la Grille, et le cube est trié
par quantité réseau décroissante. Plus d'appel à
fetchNetworkMetricsPlaywright pendant une recherche.
- Sélection plafonnée à 300 libellés au lieu de 1 000 : sélectionner les 13 446
libellés contenant « tapis » prenait 81 s puis 486 s. Le cube étant trié, 300
suffisent pour remonter les meilleures ventes.
- Une seule recherche simultanée (deux jobs en parallèle aggravaient la
saturation).
- Le détail mensuel vient du cache : le cube de recherche est agrégé. L'upsert
passe les colonnes mensuelles en COALESCE pour qu'une recherche n'efface pas
un mensuel déjà extrait par une sync.
Jointure catalogue : les 40 codes ne trouvaient aucune correspondance dans
articles.artcentrale (formats différents — « Article Code » renvoie 8 chiffres,
artcentrale en a 11). Le champ article_no_centrale est maintenant remonté comme
seconde clé candidate, la jointure essaie les deux, et un échantillon des deux
clés est loggué quand aucune ne joint.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
« Unexpected token '<', "<html> <h"... is not valid JSON » : ce n'était pas du
JSON parce que ce n'était pas l'application qui répondait. La recherche enchaîne
deux allers-retours Qlik (dont une extraction mensuelle) et dépassait le délai du
proxy, qui renvoyait sa page d'erreur HTML.
- L'API passe en asynchrone, sur le modèle déjà éprouvé de POST /api/qlik/sync :
POST démarre un job et rend la main immédiatement, GET renvoie l'avancement
puis le résultat. Le client interroge toutes les 2 s et affiche l'étape en
cours (recherche des articles / extraction des ventes / rapprochement
catalogue). Deux recherches simultanées au maximum.
- Le client ne présume plus que la réponse est du JSON : les statuts 504, 502,
503, 401 et 403 sont traduits en message actionnable au lieu d'une erreur de
parsing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Les logs de production ont tranché les trois causes.
1. La recherche de list object Qlik applique un OU entre les mots : « tapis
anti » ramenait 17 696 libellés sur 1 070 645 — presque tous ne contenant
que « anti ». On cherche désormais mot par mot pour retenir le plus sélectif,
on filtre en ET côté client (tous les mots présents, insensible
casse/accents), et on ne sélectionne que les valeurs retenues.
2. Sélectionner ces 17 694 valeurs faisait abandonner le cube suivant
(code 15 « Request aborted »), d'où le repli systématique sur le catalogue
local. La sélection est maintenant plafonnée à 1 000 valeurs, faite par
numéro d'élément (SelectListObjectValues) plutôt que par texte, et les
appels Engine retentent trois fois sur code 15.
3. Les champs détectés étaient les mauvais : article_libelle_ticket (libellé
ticket tronqué) au lieu d'Article, et code_fournisseur (le code, d'où les
« F005 » affichés) au lieu de Fournisseur. Une liste de préférences précède
désormais l'heuristique, avec repli automatique sur le candidat suivant si
un champ ne ramène rien.
Aussi :
- Un repli catalogue n'est plus mis en cache 10 min : une panne Qlik passagère
se corrigeait uniquement avec « Relancer ».
- Le code 15 est traduit en message actionnable, et un terme trop large pour le
moteur est signalé au lieu d'un « aucun résultat » trompeur.
- Les logs de la page ne relaient plus le bruit du client Qlik (thèmes,
extensions).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
« Server Action "…" was not found on the server » n'est pas une panne du
snapshot : Next.js identifie chaque Server Action par un hash calculé à la
compilation, et un onglet ouvert avant un nouveau build continue d'envoyer les
anciens identifiants. La seule issue est de recharger la page.
- src/lib/stale-action.ts : détection de cette erreur + message utilisateur.
- Grille et Snapshots : au lieu d'afficher l'erreur technique brute, on propose
« Recharger la page ». Les brouillons de la Grille sont persistés
(localStorage), recharger ne perd rien.
- SuccessModal accepte `variant="error"` : icône d'alerte rouge au lieu de la
coche verte, et surtout plus de fermeture automatique au bout de 3 s — un
message d'échec doit rester lisible. Les erreurs s'affichaient jusqu'ici sous
une coche de succès.
- SuccessModal accepte une action secondaire optionnelle, et joue son animation
d'entrée en CSS au lieu d'un setState synchrone dans un effet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Symptôme : « tapis anti » renvoyait 40 articles sans rapport (mugs, miroirs,
couvertures) avec des codes centraux contigus — c'est-à-dire le début du
catalogue Qlik, pas un résultat de recherche.
Cause : SearchResults + SelectValues. On ré-injectait les qText renvoyés par la
recherche globale dans un SelectValues sur le champ, sans vérifier le retour et
sans laisser à l'Engine le temps d'évaluer la sélection. Quand la sélection
n'est pas appliquée, le cube renvoie simplement les premières lignes de la
dimension « Article Code » — soit exactement les 40 lignes demandées.
Correctifs :
- Sélection via list object : SearchListObjectFor + AcceptListObjectSearch,
c'est-à-dire le mécanisme d'un volet de filtre Qlik. Qlik applique sa propre
sémantique de recherche et sélectionne lui-même les valeurs, sans réinjection
de valeurs texte. Libellé d'abord, code centrale en repli.
- Délai d'évaluation (QLIK_SETTLE_MS, défaut 250 ms) après ClearAll, après la
recherche et après l'acceptation, comme le fait déjà l'extraction.
- Garde-fou côté client : chaque ligne du cube est revérifiée contre le terme
(tous les mots présents dans le libellé, insensible casse/accents, ou code
correspondant). Une liste sans rapport avec la recherche est pire que zéro
résultat.
- Dédoublonnage par code centrale : un article référencé chez plusieurs
fournisseurs produisait autant de lignes (vu sur « Couverture de Pique-nique »,
code 10636135, listé deux fois).
- Diagnostic : inventaire des champs, nombre de valeurs trouvées, sélections
actives et compteur de lignes écartées sont tracés dans les logs ; si tout est
écarté, l'UI dit que le filtre n'a pas été appliqué au lieu d'afficher un
« aucun résultat » trompeur.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Les intitulés des champs varient d'une app Qlik à l'autre. La détection reste
heuristique, mais l'inventaire complet des champs est désormais loggué et deux
variables d'environnement permettent de corriger le tir sans redéploiement de
code : QLIK_FIELD_ARTICLE_LIBELLE et QLIK_FIELD_FOURNISSEUR.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Recherche produit
- La page /produits interroge désormais Qlik Sense EN PREMIER
(src/lib/qlik-search.ts) : recherche globale Engine sur les champs article
(code + libellé détectés dynamiquement via FieldList), sélection des valeurs
trouvées, puis liste des Article Code correspondants.
- Les métriques réseau des articles trouvés sont extraites sur 12 mois
glissants et mises en cache (qlik_network_metrics), puis rapprochées du
catalogue FF Nancy par code centrale (pgGetProduitsByCodeCentrale).
- Repli propre sur la recherche catalogue local si Qlik est injoignable, signalé
dans l'UI. Résultats mis en cache mémoire 10 min, requête dédupliquée.
- Nouvelle route GET /api/produits/search (runtime nodejs, 300 s) ; la liste est
chargée côté client avec état de chargement, l'extraction Qlik prenant
plusieurs secondes.
Informations affichées
- Résultats : magasins vendeurs (+ % du réseau), quantité réseau, quantité par
magasin, prix moyen réseau, CA par magasin, marge %, sparkline de tendance,
fournisseur, et présence ou non au catalogue Nancy.
- Fiche : carte « Performance réseau · 12 mois glissants » en tête (8 indicateurs
+ détail mensuel qté / magasins / qté par magasin / CA / prix moyen / marge %),
puis carte « Fournisseur » dédiée, puis identité, stock, nos ventes 12 mois.
- La fiche s'ouvre aussi par code centrale (?cc=) pour les produits que le réseau
travaille et que Nancy ne référence pas — le libellé et le fournisseur Qlik
sont persistés dans le cache réseau pour ce cas.
Tendance réseau
- computeNetworkTrend reconstruit sa fenêtre depuis la date du jour : 12 mois
complets, mois en cours EXCLU (il est partiel et écrasait la pente). Les mois
absents du cache valent 0 ; ceux antérieurs à la première extraction réelle
sont écartés au lieu d'être inventés à 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
Deux régressions constatées en production sur la page /produits.
1. La recherche par libellé ne remontait rien. `ILIKE '%tapis anti-poussière%'`
exige l'accent ET le tiret exacts, alors que les libellés sont stockés en
majuscules sans accent ni ponctuation ("TAPIS ANTI POUSSIERE"). La recherche
est désormais normalisée des deux côtés (minuscules, accents retirés,
ponctuation ramenée à un espace) et fonctionne mot à mot : tous les mots
doivent être présents, dans n'importe quel ordre. « tapis poussiere » retrouve
donc « TAPIS ANTI-POUSSIÈRE », et inversement.
Postgres n'a pas unaccent() sans extension et on ne crée rien sur la base FF :
la normalisation SQL passe par translate() + regexp_replace().
2. Secteur et Famille restaient vides sur la fiche. La table `nomenclature`
n'expose en production que no_id / code / libelle / niveau / chemin_pere :
aucune FK entière vers le parent, et chemin_pere est un chemin texte, donc la
découverte automatique renvoyait null. La hiérarchie est maintenant
reconstruite par préfixe de code quand aucune colonne parent n'existe
(secteur = 2 chiffres, famille = 4, sous-famille = 6, ex "330702" → "3307" → "33").
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XR8cMbsdjXWChX8seL9NCP
Nouvelle page /produits : recherche par libellé ou par code centrale, puis
fiche complète d'un produit — identité, prix, stock par magasin, ventes sur
12 mois glissants, et l'intégralité des métriques réseau Qlik.
Jusqu'ici les données produit n'étaient accessibles que par fournisseur
(la Grille) ou par classement (Hit Parade) : aucune route n'acceptait un
codein. Les données réseau Qlik n'étaient visibles que dans six colonnes
de la grille d'arbitrage.
Deux analyses ajoutées :
- comparatif local vs réseau, ramené au magasin moyen (indice de
performance sur les quantités, seule base commune fiable — le CA local
est TTC et la base du CA Qlik n'est pas documentée, donc indicatif) ;
- opportunités de la même famille : références que le réseau vend bien et
que nous vendons peu, écart calculé par magasin.
Détail mensuel réseau enrichi : le cube Qlik renvoyait déjà CA, nb de
magasins, CA/magasin et marge % par (article, mois) mais seule la quantité
était conservée. Ces mesures sont désormais stockées dans une nouvelle
colonne metrics_by_month, sans requête Qlik supplémentaire. qte_by_month
reste inchangée — la colonne « Tendance / Réseau » de la Grille en dépend.
L'extraction Qlik peut désormais cibler un seul code centrale
(/api/qlik/sync?codeCentrale=…), ouverte à tout utilisateur connecté et
plafonnée à 3 extractions simultanées ; le mode fournisseur reste
réservé aux admins.
Refactor sans changement de comportement : les helpers de mois, le calcul
de tendance et les graphes SVG quittent heatmap-grid.tsx pour des modules
partagés, et le polling des jobs Qlik devient le hook useQlikSyncJob,
réutilisé par la Grille et par la fiche.
Les calculs de ventes reprennent le SQL canonique de la Grille (genremvt=3
avec quantités niées pour déduire les retours, stock de fin de mois pris
sur le dernier mouvement, report sur les mois sans mouvement), afin que
les chiffres des deux pages soient identiques par construction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XR8cMbsdjXWChX8seL9NCP
CA / Quantité / Nb magasins étaient pris depuis des qId d'environnement
(GUID), sans garantie qu'ils pointent la bonne mesure — les deux autres
mesures étaient déjà résolues par titre pour cette raison. Toutes le sont
désormais ('CA N', 'Quantité N', 'Magasin Ventes Nb N'), avec repli sur
l'env.
Ajout de deux logs de vérification :
- les identifiants de mesure réellement utilisés ;
- un échantillon de ligne mensuelle avec chaque valeur ÉTIQUETÉE, pour
comparer directement avec Qlik et confirmer que la courbe utilise bien
la quantité vendue et non le nombre de magasins.
Le graphe sautait de 07/25 à 01/26 : l'astuce COMP ne fournit un mois N-1
que s'il existe un mois N correspondant. L'année N s'arrêtant au mois
courant (juillet), les mois août→décembre N-1 étaient introuvables.
Ajout d'une passe complémentaire : on sélectionne le champ 'Année' sur
N-1, ce qui fait porter les mesures 'N' sur cette année → ses 12 mois
sont récupérés directement (prioritaires sur les valeurs COMP dérivées).
Les totaux réseau (CA/Qté) ne sont alimentés que par la passe principale
pour éviter tout double comptage. Passe ignorée proprement si le champ
'Année' est absent ou si elle échoue.
Résultat attendu : mois contigus 2025-08 → 2026-07 dans le modal (l'UI
garde les 12 derniers mois triés).
Le cube [Article Code, Mois] ne renvoie que les mois de l'année N (les
mesures 'N' sont nulles ailleurs → lignes supprimées). Le code cherchait
des lignes d'année N-1 qui n'existent pas, donc 'Quantité COMP' n'était
jamais exploitée → seulement ~7 mois affichés.
'Quantité COMP' étant le comparable N-1, à la ligne Mois=YYYYMM elle donne
la quantité du MÊME mois l'année précédente. On dérive donc deux points
par ligne : YYYY-MM (Quantité N) et (YYYY-1)-MM (Quantité COMP) → 12 mois
sans ligne supplémentaire ni requête en plus.
UI : l'en-tête du modal affiche le nombre RÉEL de mois disponibles au lieu
de '12 derniers mois' en dur.
Quand l'app Qlik ne peut pas se charger faute de RAM serveur (code 6
'Not enough memory to load file' / code 3002 'File corrupted' / 'Out of
memory'), le job affiche un message clair ('Serveur Qlik saturé…') au
lieu de l'erreur technique. Ce n'est pas un bug CollectFlow : le sync
échoue à l'ouverture de l'app, avant toute requête.
- Corrige le tooltip erroné 'X% (4 derniers mois vs 4 précédents)' →
'Tendance X% sur 12 mois (régression)'. Le calcul est déjà une
régression linéaire sur 12 mois ; seul le texte était resté l'ancien.
- Réduit la taille des lots du cube [Article Code, Mois] (800→300, replis
150/75) pour alléger la mémoire moteur Qlik et limiter les 'Out of
memory / File corrupted' (3002) observés sur le sync.
Le modal doit couvrir 12 mois glissants (pas seulement depuis janvier).
Comme 'Quantité N' ne couvre que l'année en cours, on réintègre la mesure
'Quantité COMP' (N-1) pour les mois de l'année précédente : mois année N
→ Quantité N, mois année N-1 → Quantité COMP. La courbe du modal affiche
donc les 12 derniers mois.
- Modal : les 12 barres remplacées par UNE seule courbe SVG des ventes
réseau mensuelles (points + quantités affichées + axe des mois).
- Sync : retrait de la mesure 'Quantité COMP' (année N-1) — trop lent à
récupérer. Retour au cube [Article Code, Mois] à 5 mesures (Quantité N).
Le détail mensuel couvre donc les mois de l'année en cours ; la tendance
(régression) se calcule sur ces mois.
UI:
- La colonne Tendance (renommée 'Réseau · 12 m') ouvre le modal au clic
(au lieu de la colonne Nb magasins, remise en simple affichage).
- Tendance calculée par RÉGRESSION LINÉAIRE (moindres carrés) sur les 12
derniers mois : robuste au bruit, % = pente×durée/moyenne. Libellé
Forte hausse/Hausse/Stable/Baisse/Forte baisse (seuils ±8% / ±25%).
Sync:
- Ajout de la mesure 'Quantité COMP' (année N-1) au cube [Article Code,
Mois] → 12 mois glissants : mois de l'année N via Quantité N, mois de
l'année N-1 via Quantité COMP. Cube 8 colonnes, PAGEM 1200 (<10000
cellules). Total réseau reste en année N (non gonflé).
Configurable : QLIK_MEAS_QTE_COMP_ID.
La sonde a prouvé que les mesures 'Quantité N' se découpent correctement
par la dimension 'Mois' (id pfGAwTs, format 'YYYYMM'). L'itération par
sélection de Date, elle, renvoyait la valeur annuelle identique chaque
mois (tendance plate + total sommé 12×).
Nouvelle extraction réseau (activée par défaut, QLIK_MONTH_DIM=0 pour
revenir à l'ancienne) : un cube [Article Code, Mois] × 5 mesures par lot
de codes (avec repli code 15 800>400>200), sélection de la fenêtre de
dates une seule fois. Chaque ligne (code, mois, ...) alimente qteByMonth
en 'YYYY-MM' et le total par somme RÉELLE des mois.
Résultat attendu : la colonne Tendance affiche enfin de vraies variations,
le modal montre les ventes réseau mois par mois, et le total réseau n'est
plus gonflé 12×. Nécessite un nouveau Sync pour re-remplir le cache.
Note : 'Quantité N' = année N, donc les mois disponibles sont ceux de
l'année en cours (pas un glissant 12 mois strict) — suffisant pour la
tendance ; on pourra ajouter 'Quantité COMP' pour compléter N-1 si besoin.
Le dump révèle une dimension 'Mois' (id pfGAwTs) et 'Période' (tKTPVU).
La sonde crée un mini-cube [Article Code, Mois] × Quantité N et logue le
format des valeurs Mois + si la quantité varie par mois — pour concevoir
le vrai découpage mensuel (dimension Mois) qui règlera tendance + total 12x.
- Chemin rapide select-all activé par DÉFAUT (fiable, aucun code 15 en
prod) — désactivable seulement via QLIK_SELECT_ALL_CODES=0. Plus besoin
de la variable d'env (elle sautait à chaque mise à jour de la stack).
- Dump diagnostic des mesures + dimensions Qlik disponibles (titre+id)
pour identifier une mesure Quantité non-annuelle / une dimension Mois,
car les mesures 'CA N'/'Quantité N' renvoient la valeur annuelle figée
(mois identiques → tendance impossible + total réseau sommé 12×).
Le sync Qlik calculait déjà les ventes réseau mois par mois mais les
sommait en un total. On conserve désormais le détail mensuel.
- Sync : accumulation additive qteByMonth { code: { 'YYYY-MM': qté } }
in-page (chemins rapide + par lots), rattachée au métrique réseau.
Reset propre en cas de repli code 15. Total inchangé.
- Stockage : colonne jsonb qte_by_month sur qlik_network_metrics
(schema + db-init ALTER), upsert + lecture.
- ProductRow.qteReseauByMonth propagé jusqu'à la grille.
- UI grille :
· colonne '% Présence réseau' remplacée par 'Tendance réseau' :
sparkline 12 mois teintée + flèche + variation % (moyenne 4 derniers
mois vs 4 précédents), triable ;
· cellule 'Nb magasins' rendue cliquable → modal des ventes réseau
mois par mois (barres, 12 derniers mois).
Nécessite un nouveau Sync Qlik pour peupler le détail mensuel (les
données déjà en cache n'ont que le total → modal 'pas encore de détail').
La sync Qlik itérait mois × lots de 150 articles, en re-sélectionnant les
mêmes Article Code à chaque lot. La SelectValues répétée (~22 s × ~120)
représentait ~72% du temps total (~60 min pour 12 mois).
Ajoute un chemin rapide (flag env QLIK_SELECT_ALL_CODES=1) qui sélectionne
TOUS les Article Code une seule fois, puis n'itère que la sélection Date
par mois avec un seul cube paginé (Article Code en dimension). Passe de
~120 SelectValues Article Code à 1, et de ~120 cubes à 12 → gain estimé
~60 min → ~5-8 min.
Repli automatique et sûr : en cas d'erreur moteur code 15, les résultats
partiels et les sélections sont réinitialisés et l'ancien chemin par lots
reprend le relais. Flag désactivé par défaut : comportement inchangé tant
qu'on n'active pas la variable. À valider sur le Qlik réel.
Ajoute un bouton dans l'en-tête de la Grille qui force le rechargement
des données depuis le serveur en ignorant le cache mémoire de 10 min
(via le paramètre URL _refresh → refresh=1 → forceRefresh). Utile pour
remonter immédiatement l'état serveur courant, notamment la colonne INIT.
Spinner pendant le chargement, désactivé si un chargement est en cours.
Corrections Hit Parade / Gestion de stock (ventes nettes par magasin,
tri stock négatif) et Grille (colonne INIT des gammes rechargée à chaque
chargement, y compris sur cache; colonne Gamme conserve le snapshot).
La colonne Gamme conserve la valeur du snapshot (comportement voulu). Mais
la colonne INIT ne se mettait pas à jour : getProductRows sert les lignes
depuis un cache mémoire de 10 min, et le client n'envoie 'refresh=1' que
sur le bouton de rafraîchissement manuel. Sur une navigation normale dans
les 10 min, codeGammeInit restait donc figé.
Correctif : sur un hit de cache, on re-requête la gamme serveur courante
(pgGetGammesByFournisseur, 1 requête légère) et on met à jour uniquement
codeGammeInit sur les lignes cachées. codeGamme (snapshot) n'est pas
touché ; les données lourdes (ventes/stock/réseau) restent cachées.
Résultat : la colonne INIT reflète toujours l'état serveur à chaque
chargement, et le marqueur 'modifié' (Gamme ≠ INIT) se résorbe dès que
le serveur rattrape la modification. La révision précédente (reconcilier
codeGamme) est annulée : la colonne Gamme reste le snapshot tel quel.
La grille rechargeait bien le gamme INIT depuis l'état live du serveur à
chaque chargement (Phase 6), mais la Phase 9 réappliquait ensuite
AVEUGLÉMENT le 'after' du dernier snapshot sur codeGamme — même quand la
modification avait déjà été appliquée sur le serveur (ou que la gamme
serveur avait évolué depuis). Résultat : la grille affichait l'ancienne
cible du snapshot au lieu de l'état serveur réel, et une modif 'en
attente' fantôme.
Désormais on ne réapplique une modif du snapshot QUE si elle est encore
réellement en attente côté serveur (change.before === gamme live). Sinon
on garde l'état serveur courant. La grille montre donc toujours où en
sont les gammes sur le serveur, et une modif disparaît du 'en attente'
dès qu'elle est appliquée côté serveur — le suivi reste juste.
Note : les brouillons locaux (localStorage) restent gérés côté client
comme du travail non sauvegardé.
Analyse de cohérence de stock sur le cas 487673 site 579 : 24 réceptions,
31 ventes brutes, 7 retours clients → 24 ventes nettes, stock final 3.
Le « 38 » affiché = 31 + 7 : signature de l'ancienne formule SUM(ABS)
qui additionnait les retours. La formule nette SUM(-qtemvt) déjà en place
donne 24 — le filtre mntmvtttc <> 0 (hypothèse de lignes fantômes 0 €)
était inutile : aucune ligne de ce type dans les données réelles. Retiré
pour rester strictement aligné sur le calcul de la Grille.
Gestion de stock : ORDER BY cs.qte (colonne affichée) au lieu de
cs.stockdispo (colonne différente) dans pgGetStockNegatif.
Cas réel : codein 487673 site 579 affichait 38 vendus au lieu de 24,
avec un CA pourtant exact (215,76 €) — mvtart contient des lignes
genremvt=3 portant une quantité mais aucun montant TTC (corrections /
régularisations), que les endpoints officiels de l'API excluent.
Ajout du filtre mntmvtttc IS NOT NULL AND <> 0 dans l'agrégation :
une vente réelle a toujours un montant TTC non nul. Validé sur
PostgreSQL local en reproduisant le cas : sans filtre 38/215,76 €
(= symptôme), avec filtre 24/215,76 € (= réalité). Le CA et les
requêtes Analytics ne changent pas (ces lignes valent 0 €).
La version précédente agrégeait les ventes avec les jointures fournisseur
(LATERAL par ligne de mouvement + fouident) dans la même passe : si
fouident contient des codes dupliqués, chaque mouvement était compté
plusieurs fois → chiffres faux sur les deux magasins, et le LATERAL
s'exécutait par mouvement (très lent).
Restructuration, validée sur 12 000 mouvements réels de l'API chargés
dans un PostgreSQL 16 local :
- CTE ventes : mvtart JOIN articles uniquement (1:1), SUM(-qtemvt) /
SUM(-mntmvtttc) / SUM(margemvt) par (codein, site) — le calcul
canonique de la Grille (pgGetMensuelByFournisseur), signes vérifiés
sur les mouvements réels (ventes négatives, genremvt=3).
- CTE attrs : libellé/fournisseur/nomenclature joints APRÈS agrégation,
dédupliqués par DISTINCT ON — aucune jointure ne peut plus fausser
les sommes (totaux invariants aux doublons artfou1/fouident injectés).
- Même principe pour pgGetCaByFournisseur, pgGetStockNegatif,
pgGetSansVente6Mois : sous-requête artfou1 DISTINCT ON au lieu du
LATERAL par ligne.
- Grille (fallback API mensuel) : Math.abs remplacé par la négation sur
qte_vendue/ca_ht (négatifs côté API) — les retours clients restent
déduits au lieu d'être inversés en positif, même convention que le SQL.
- Hit Parade (client) : ColHeader extrait hors du composant (erreur
'Cannot create components during render'), useMemo déplacés avant
exportToExcel pour préserver la mémoïsation React Compiler, variable
idx inutilisée supprimée. ESLint 0 erreur, build OK.
La requête Hit Parade divergeait du calcul canonique de la Grille :
- SUM(ABS(qtemvt)) additionnait les retours clients comme des ventes au
lieu de les déduire → quantités et CA gonflés sur le magasin ayant des
retours/avoirs sur la période (visible sur 579).
- ABS(SUM(mntmvtttc)) inversait le signe d'un CA net négatif.
- GROUP BY no_id + jointure artfou1 preference=1 non dédupliquée pouvait
produire plusieurs lignes par (codein, site), écrasées par le pivot.
Corrections :
- Hit Parade : ventes nettes SUM(-qtemvt) / SUM(-mntmvtttc), agrégation
par (codein, site), fournisseur préféré via LATERAL ... LIMIT 1,
stock agrégé par codein ; pivot en accumulation (+=) par sécurité.
- Analytics (même classe de bug) : pgGetCaByFournisseur et
pgGetCaByNomenclature passent en CA net ; jointure fournisseur
dédupliquée (LATERAL LIMIT 1) pour éviter le double comptage.
- Gestion de stock : pgGetStockNegatif et pgGetSansVente6Mois dédupliquent
le fournisseur préféré (LATERAL LIMIT 1) pour éviter les lignes en double.
Audit complet du mapping par magasin (292/579) côté client : aucun champ
inversé (hit-parade, analytics, dashboard, grid, heatmap). Build OK.
Le build Docker échouait sur le fetch de la police Inter via next/font/google
(accès réseau/TLS indisponible pendant 'next build').
- layout.tsx : charge Inter via <link> côté navigateur (plus de fetch au build),
avec fallback système ; --font-sans défini dans globals.css (@theme).
- /commandes-auto : export dynamic = 'force-dynamic' (données live DB + API,
jamais prérendues au build).
- listCadences : résilient si la DB est injoignable (retourne []).
Ajoute un onglet "Cadencier / Alertes" dans la page Commandes auto.
Depuis la liste des fournisseurs, on active un fournisseur en alerte de
commande sur un magasin (292/579) avec une fréquence en X semaines,
gérée indépendamment par magasin.
L'échéance est calculée à partir de la dernière réception réelle
(mvtart, genremvt 1/2, fournisseur principal artfou1.preference=1) +
X semaines. Statut: à commander / bientôt / OK, avec temps restant.
- Table commande_cadences (schema + db-init)
- pgGetDerniereReceptionParFournisseur (mvtart par fournisseur/site)
- Server actions CRUD (list/upsert/toggle/remove)
- UI à onglets + cadencier (ajout, édition intervalle, activer/supprimer)
Claude