Claude
5fee5bc058
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
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.
- Installer les dépendances :
npm install
-
Configurer la connexion DB : Allez sur la page des Paramètres (
/settings) dans l'application pour configurer l'accès à votre PostgreSQL local. -
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)