Claude
c9e1934aae
La colonne PV s'affichait vide sur toutes les lignes. Le schéma du SaaS Postgres (dépôt Apiflow, postgres/init.sql) explique pourquoi : la seule source lue jusqu'ici, `article_infosup.prix_vente_mini`, est une borne de PARAMÉTRAGE — un prix plancher, à côté de `prix_vente_maxi` et `pv_conseille` — et non le prix pratiqué. Le prix de vente vit dans `cube_pv (artnoid, site, pv)`, pendant exact du `cube_pa` déjà utilisé pour l'achat, rafraîchi chaque nuit depuis le cube MSSQL `Cube_PV`. `cube_stock` porte le même PV et sert de filet : il ne couvre que les articles ayant une ligne de stock, mais il est déjà interrogé par la Grille, une colonne de plus dans le SELECT suffit. Le prix est propre à chaque MAGASIN. La colonne suit donc le magasin consulté ; en « tous magasins » elle montre le prix commun, et s'ils divergent le plus élevé assorti d'un « ≠ » et de l'infobulle qui donne les deux. Une moyenne afficherait un prix qu'aucune caisse ne pratique, et retenir silencieusement l'un des deux ferait passer le prix d'un magasin pour celui des deux. L'en-tête devient « PV / Magasin » : « PV central » décrivait la fiche article, ce n'est plus la source. Vérifié sur build de production, prix identiques, divergents et absents : en « tous magasins » 14,90 € ≠ avec l'infobulle « Frouard (Nancy) : 13,90 € · Houdemont : 14,90 € » ; sur Frouard 13,90 €, sur Houdemont 14,90 €, sans marqueur ; « - » quand aucune source n'a de prix. La route de diagnostic compte désormais les trois sources côte à côte, de quoi confirmer sur la base réelle laquelle est renseignée. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EYGgoQCG1VCe42HzbzhAXR
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)