Le repli sur l'API FF n'a rien trouvé pour 503996 : /dernier-fournisseur
appelé sans magasin ne renvoie pas l'entrée de Houdemont. Seul
`?site=579` donne P024 PUCKATOR BV (entrée du 29/09/2026), et la fiche
de l'article n'a aucun fournisseur.
On interroge désormais l'appel sans magasin, `?site=292` et `?site=579`,
et on retient l'entrée la plus récente. On choisit aussi, parmi les
articles renvoyés par /api/articles?codein=, celui dont le codein est
bien celui demandé. Le tableau de bord en profite (même fonction).
Le test reproduit la réponse de l'API pour 503996 ; il échoue sur
l'ancien code.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhSZx8CCuqoKrDw7unFqGq
Les articles récents (503996, 504022, 504025, 505349…) n'ont aucune ligne
artfou1 dans la recopie FF : ni référence, ni fournisseur. Le Hit Parade
et les pages Stock les affichaient en « Sans fournisseur ».
Les lignes restées « Sans fournisseur » après la requête SQL sont
complétées par l'API FF en direct, avec la règle du tableau de bord :
fournisseur de la dernière entrée en stock, sinon celui du référentiel.
Au plus 200 articles par chargement (12 en parallèle), réponses gardées
en mémoire le temps du cache FF pour ne pas réinterroger l'API à chaque
onglet.
Le test d'intégration sert une fausse API FF et vérifie que l'article
absent de la base est complété ; il échoue sans le repli.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhSZx8CCuqoKrDw7unFqGq
Les pages Stock (stock négatif, stock sans vente, sans vente depuis 6 mois)
joignaient obligatoirement le fournisseur principal (artfou1.preference = 1)
et sa fiche fouident : un article sans principal — ou sans aucune ligne
artfou1, comme le codein 504202 — était purement retiré de la liste.
Les jointures deviennent facultatives et le fournisseur suit partout la même
règle : le principal, sinon le fournisseur référencé le plus récent, sinon
celui des données du réseau (cache Qlik, par code centrale), sinon
« Sans fournisseur ». Même repli pour le CA par fournisseur, la dernière
réception (cadencier), le Hit Parade, la recherche produit et les
opportunités. Dans la recherche, ce repli ne masque plus le fournisseur
que Qlik vient de renvoyer.
Test d'intégration opt-in (FF_FOURNISSEUR_TEST_DATABASE_URL) qui rejoue les
quatre cas ; il échoue sur l'ancien code (1 article listé sur 4).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhSZx8CCuqoKrDw7unFqGq
L'API api.ffnancy.fr exige désormais une clé (401 « Clé d'API requise »).
- Nouveau champ « Clé d'API » dans Paramètres → API FF Nancy, stocké dans
data/.db-config.json (ffApiKey), jamais renvoyé au navigateur ; vide =
conserver la clé enregistrée. Repli sur la variable FF_API_KEY.
- Tous les appels à l'API FF envoient l'en-tête X-API-Key (ff_get, proxy
commandes-auto, publicités, /api/diag, test de connexion).
- Le test de connexion signale explicitement une clé manquante ou refusée.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KdY28Lq8Q8xX4RZsAvWRQ7
Depuis le passage au serveur Rust, la mise à jour réseau d'un fournisseur
(ex. Sovacom) échouait sur « Request timed out » : chromiumoxide coupe toute
commande de page au bout de 30 s, en dur (REQUEST_TIMEOUT de CommandFuture),
sans tenir compte du request_timeout du navigateur. Or toute l'extraction
Qlik tient dans un seul Runtime.evaluate de plusieurs minutes. Playwright,
côté TS, n'avait pas cette limite.
PageQlik::evaluer lance désormais le script sans l'attendre, puis relève son
résultat par des évaluations courtes (20 ms → 1 s). Aucune commande CDP
n'approche plus les 30 s, quelle que soit la durée de l'extraction ; la
recherche produit, qui passe par la même fonction, en profite aussi.
Tests :
- tests/faux-qlik : faux Qlik Sense (HTTPS, NTLM → ticket → cookie, page
avec jeton CSRF, mini-moteur Engine) ;
- extraction_faux_qlik (ignoré par défaut) : extraction complète de bout en
bout avec un vrai Chromium, y compris contre celui de l'image de prod ;
- fenetre_identique_au_ts : fenêtre 12 mois identique à l'ancien TS.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DTseDg4hw2m9tGUJsqPt57
Depuis le passage à Rust, toutes les extractions Qlik échouaient au bout
d'environ 32 s : chromiumoxide abandonne toute commande CDP après 30 s,
constante codée en dur dans CommandFuture, quel que soit request_timeout.
L'extraction tenait dans un seul Runtime.evaluate attendant la promesse.
Le script est désormais lancé sans être attendu, son résultat rangé dans
window, puis relevé toutes les 500 ms par des évaluations courtes. Les
erreurs in-page (pile comprise) et la perte du contexte remontent comme avant.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NjmvaJ5VTadoufBQ8a57no
La page Synchronisation n'affichait qu'un badge « Échec » alors que l'erreur
est enregistrée par fournisseur : elle apparaît désormais dans la colonne
Remarque. Sur la Grille, l'erreur du bouton réseau reste affichée jusqu'à la
tentative suivante (elle s'effaçait après 4 s et était masquée hors très
grands écrans). L'extraction Qlik de nuit ouvre un journal téléchargeable
dans Paramètres, comme la synchro manuelle.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NjmvaJ5VTadoufBQ8a57no
Le Hit Parade, la recherche produit et les opportunités n'acceptaient que
artfou1.preference = 1 : un article dont la préférence n'est pas renseignée
dans FF (ou posée sur une ancienne fiche du même codein) s'affichait en
« Sans fournisseur ». On prend désormais le principal s'il existe, sinon le
fournisseur référencé le plus récent ; le Hit Parade cherche sur toutes les
fiches du codein.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WT49YnjumAVBjCB4EUXNL1
- /api/produits/search (POST démarre un job, GET suit l'avancement) : Qlik
d'abord, repli catalogue FF (source: "db"), cache mémoire 10 min des seuls
résultats Qlik exploitables, une recherche Qlik à la fois.
- /api/produits/opportunites : produits de la même famille, local vs réseau.
- Page produit-fiche (?codein= ou ?cc=) : getProduitFiche /
getProduitFicheByCodeCentrale, report du stock de fin de mois.
- normalizeMargePct (compare-reseau) et types JSON identiques au client.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LG2LLJuswrrTTPKJmunEVf
- product_rows.rs : getProductRows complet (7 requêtes FF en parallèle,
métriques réseau Qlik, report du dernier snapshot, filtre gamme Y,
rattrapage d'un magasin par l'API FF), branché sur rows_cache (calculs en
cours partagés, compteur d'enregistrements, compléments par magasin),
instantané grid_rows resservi s'il date du mois (rafraîchi au-delà de 20 h),
persistance non bloquante ; getStorePatch ; get_product_rows_for_sync pour la
synchro nocturne et le préchauffage.
- store_patch.rs : buildStorePatchEntries.
- enrich.rs (api-enrich) et api_gammes.rs (affecterGammes, lireCorpsJson).
- Routes /api/grid/rows (NDJSON), /api/grid/rows/store-patch, /api/v1/grid
(diffusion complète sans limit), /products/search, /products/{codein},
/products/{codein}/gamme, /gammes, /fournisseurs, /network/{codeCentrale}.
- store.rs : upsert_grid_rows_shared, écriture par lots depuis les lignes
partagées du cache (sans copie intégrale).
Écart volontaire : après un calcul à la demande, /api/v1 attend la fin de
l'écriture de l'instantané avant de le relire (le TS ne l'attendait pas et
pouvait répondre à tort « aucun article »).
Test d'intégration sur la base ff_fixture (GRID_FF_TEST_DATABASE_URL) : calcul,
cache, instantané, complément magasin via une fausse API FF, enrichissement et
toutes les routes (session et clé d'API).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LG2LLJuswrrTTPKJmunEVf
Portage de tout ce qui, dans la Grille, ne dépend ni de la base FF ni de Qlik :
- types.rs : ProductRow et types associés, JSON identique à JSON.stringify
(camelCase, champs facultatifs omis, entiers sans décimale, NaN → null) et
relecture sans perte des payloads grid_rows écrits par la version Node ;
- store.rs : grid_rows (upsert par lots de 200 + purge, instantané, report des
gammes, requêtes filtrées/triées/paginées via QueryBuilder et liste blanche
de tri, fiche, fournisseurs, fraîcheur, nomenclatures) ;
- rows_cache.rs : cache mémoire 10 min des lignes calculées (clé, LRU,
patchGridRowsCache, invalidation, calculs en cours, compléments par magasin) ;
- network_trend.rs, months.rs, store_patch.rs : logique pure testée ;
- gammes_a_valider.rs, enregistrer.rs, snapshots.rs : actions getSnapshots,
deleteSnapshot, saveSnapshot, saveDraftChanges, getGammesAValider,
rejeterGammesAValider (validation zod reproduite, mêmes messages) ;
- exports.rs : /api/export/excel et /api/export/modified-gammes
(rust_xlsxwriter, mêmes feuilles, styles, largeurs et formats) ;
- api_schemas.rs, zod.rs : schémas /api/v1, issues zod 4 à l'identique ;
- api_v1.rs, openapi.rs : /api/v1/nomenclatures et /api/v1/openapi.json
(document identique octet pour octet à celui de la version Node).
Écart volontaire : listGridNomenclatures groupe par position (GROUP BY 1) ; la
requête drizzle répétait left(code3, $n) avec un autre paramètre et échouait
systématiquement sous PostgreSQL.
Test d'intégration (grid_rows, snapshots, gammes à valider) activé par
GRID_TEST_DATABASE_URL.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LG2LLJuswrrTTPKJmunEVf
Le serveur étant réécrit en Rust, l'interface devient une application
React 19 côté navigateur, compilée par Vite dans dist/ et servie par le
serveur Rust (STATIC_DIR). Composants, styles et logique cliente
inchangés : seule la plomberie Next.js est remplacée.
- Outillage : Vite 8, @vitejs/plugin-react, Tailwind 4 via PostCSS,
React Router 7 (mode déclaratif), index.html, src/main.tsx, alias @/,
proxy /api → localhost:5643 en développement, ESLint sans plugin Next.
- Adaptations (src/shims) : next/link, next/navigation (useRouter avec
refresh, usePathname/useSearchParams suivant aussi les replaceState de
l'interface), next-auth/react (session lue sur /api/auth/session,
déconnexion par /api/auth/logout).
- Actions serveur → POST /api/actions/{nom} (src/lib/rpc.ts) : mêmes noms,
mêmes signatures, mêmes types. La connexion passe par /api/auth/login.
- Pages → table des routes (src/router.tsx) : données lues sur
/api/pages/{nom} avec Suspense (loading.tsx au premier chargement,
page conservée pendant une navigation ou un router.refresh()),
error.tsx en frontière d'erreur, not-found.tsx, titres d'onglet,
pages d'administration réservées aux administrateurs.
- Suppression du code serveur Next.js (routes /api, accès base, Qlik,
authentification, middleware…) ; types utiles à l'interface recopiés
dans src/types/ff.ts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LG2LLJuswrrTTPKJmunEVf
- ff::pg : portage complet de pg-ff-client.ts (mêmes requêtes SQL, fragments
dynamiques via QueryBuilder, lectures tolérantes, caches process de la
colonne parent de nomenclature et du lien mvtart → fournisseur).
- ff::api : client de l'API FF Nancy (URL résolue Paramètres → env → défaut,
mémorisée 30 s ; délai FF_API_TIMEOUT_MS), pagination, mensuel, référentiel,
commandes, normalisation du statut de synchro.
- ff::cache : getFournisseursCached / getDerniereReceptionCached.
- ff::diagnostic : diagnostiquer_api_ff (DNS, refus, délai, code HTTP).
- Routes /api/ff-status, /api/diag, /api/diag/stock-fournisseur, /api/test-db,
/api/commandes-auto ; actions de la Grille et du cadencier ; pages dashboard,
analytics, hit-parade, stock-negatif, commandes-auto, publicites.
- Test d'intégration (FF_TEST_DATABASE_URL) avec fausse API FF : toutes les
requêtes et tous les appels HTTP joués sur une base de test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LG2LLJuswrrTTPKJmunEVf
Le logiciel de mise à jour des gammes refuse les fichiers trop gros
(ex. 28 590 lignes). L'export est désormais découpé en plusieurs
fichiers (_partie_1_sur_6, …) à intégrer un par un.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011jxxh5X1FHMUPFu2S2JpyT
Sur un écran très large, la colonne de libellé absorbait tout l'espace en
trop : le nom du fournisseur se retrouvait à un millier de pixels de ses
chiffres. Le tableau prend désormais la largeur de son contenu (défilement
au-delà de l'écran) et l'option « grow » devient « label » : largeur
naturelle, retour à la ligne au-delà de 28rem.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FaniLFvegAZNXFrFFSStqa
DataTable gagne quatre options de colonne :
- grow : la désignation prend la largeur restante, les chiffres restent
groupés au lieu de s'étirer sur un écran large ;
- sticky : Code et Désignation restent visibles au défilement horizontal
(désignation bornée à 45 % de la largeur sur mobile) ;
- group : en-tête commun par magasin et trait de séparation entre groupes ;
- highlight : fond teinté pour le groupe « Total nos magasins ».
Toutes les lignes alternent désormais de couleur, survol teinté.
Appliqué à Meilleures ventes (Référence déplacée après la Désignation),
Ventes par mois et Publicités.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FaniLFvegAZNXFrFFSStqa
LogiFlow
Claude