Claude 4a56584a27 fix(qlik): les master measures ignorent la sélection Date — agrégation directe des faits
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
2026-07-31 06:27:33 +00:00

CollectFlow

CollectFlow est une application de révision d'assortiment et d'analyse de performances des produits en point de vente, conçue pour consolider les données issues de plusieurs fournisseurs et magasins.

Prérequis

  • Node.js 18+ (pour le développement local)
  • Docker et Docker Compose (pour le déploiement conteneurisé)
  • PostgreSQL 16+

Lancer avec Docker

Le projet est configuré pour tourner dans un conteneur Docker optimisé (mode standalone de Next.js). Note : Vous devez disposer d'une base de données PostgreSQL séparée (le conteneur ne lance que l'application web).

1. Démarrer l'application

À la racine du projet, lancez :

npm run docker:build
# ou directement
docker-compose up -d --build

L'application sera accessible sur http://localhost:5643.

L'application sera attachée au réseau Docker externe nginx_default afin d'être exposée derrière votre reverse proxy Nginx. Assurez-vous que ce réseau existe (docker network create nginx_default).

2. Arrêter l'application

npm run docker:down
# ou directement
docker-compose down

Développement Local (Sans Docker)

Si vous préférez développer en local, vous devrez configurer votre propre base de données PostgreSQL.

  1. Installer les dépendances :
npm install
  1. Configurer la connexion DB : Allez sur la page des Paramètres (/settings) dans l'application pour configurer l'accès à votre PostgreSQL local.

  2. Lancer le serveur de développement :

npm run dev

Structure du Projet (BMAD)

Ce projet respecte l'architecture BMAD (Business, Model, Application/API, Data) :

  • src/features/* : Logique métier (Business) isolée par feature (ex: grid, snapshots)
  • src/types/* : Interfaces TypeScript (Model)
  • src/app/* : Routeurs Next.js UI et endpoints d'API (Application/API)
  • src/db/* : Schémas Drizzle ORM et connexions (Data)
S
Description
No description provided
Readme
4.6 MiB
0 Stars 1 Watchers 0 Forks
Languages
TypeScript 93.9%
JavaScript 3.6%
HTML 1.4%
CSS 1%
Dockerfile 0.1%