feat(v2.0.3): Marchés hybrides et améliorations multiples

Fonctionnalités principales : 1. Marchés hybrides - Onglet Mercurial - Ajout onglet Mercurial avec style distinct (vert, gras, blanc) - Affichage des produits mercuriaux pour marchés hybrides - Filtrage automatique des produits "Hors Marché 999" - Documentation Phase 2 avec CAS 1 et CAS 2 de marchés hybrides - Règles métier pour validation différenciée (devis 100% mercurial vs mixte) 2. Corrections bugs - Fix flag chkChange sur onglet "Sélection Produits" (callback asynchrone) - Plus d'alerte intempestive après sauvegarde des produits 3. Outils de déploiement - Nouveau script deploy-file.sh pour déploiement unitaire (DEV/PROD) - Amélioration deploy-cleo.sh 4. Gestion multi-contacts (v2.0.3) - Contrôleur AJAX cjxcontacts.php - Script migration clients_contacts - Documentation complète 5. Documentation - Mise à jour TODO.md avec Phase 2 marchés hybrides - Mise à jour README.md v2.0.3 - Ajout RULES.md - Ajout migration_clients_contacts.sql 6. Nettoyage - Suppression fichiers obsolètes (conf_new.php, conf_old.php, uof_linet_20250911.sql) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-05 15:40:06 +01:00
parent 443b0509df
commit a4d1c22a93
22 changed files with 11544 additions and 178178 deletions
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -4,15 +4,6 @@

 ### Module Devis

-#### 6. ✅ Modifier un devis archivé (TERMINÉ - 12/09/2025)
-**Priorité**: Haute  
-**Description**: Permettre la modification d'un devis archivé et son renvoi pour traitement sans nécessiter de duplication.  
-**Tâches**:
- [x] Ajouter un bouton "Réactiver" sur les devis archivés (statut 20)
- [x] Permettre le changement de statut d'archivé vers "En cours"
- [x] Conserver l'historique de réactivation dans `devis_histo`
- [x] Adapter les droits selon les rôles (RR, DV, DIR-CO)
-
 #### 8. Dupliquer une ligne produit
 **Priorité**: Moyenne  
 **Description**: Permettre la duplication d'une ligne produit dans un même devis (utile pour les gratuités).  
@@ -36,19 +27,9 @@
 - [ ] Paginer les résultats de recherche
 - [ ] Export des résultats en Excel

-#### 19. Gestion des contacts multiples
-**Priorité**: Haute  
-**Description**: Permettre la gestion de plusieurs contacts par client.  
-**Tâches**:
- [ ] Créer une table `clients_contacts`
- [ ] Migration des contacts existants vers la nouvelle structure
- [ ] Interface CRUD pour les contacts
- [ ] Sélecteur de contact à la création/modification de devis
- [ ] Historique des contacts par devis
-
 #### 21. Actualisation tarifaire
-**Priorité**: Moyenne  
-**Description**: Permettre l'actualisation des prix selon la dernière grille tarifaire.  
+**Priorité**: Moyenne
+**Description**: Permettre l'actualisation des prix selon la dernière grille tarifaire.
 **Tâches**:
 - [ ] Ajouter un bouton "Actualiser les tarifs"
 - [ ] Comparer les prix actuels avec la grille en vigueur
@@ -56,8 +37,73 @@
 - [ ] Recalculer automatiquement les marges
 - [ ] Tracer l'actualisation dans l'historique

+#### 22. Marchés hybrides et onglet Mercurial
+**Priorité**: Haute
+**Description**: Ajouter un onglet "Mercurial" dans la page devis pour les marchés de type hybride, listant tous les produits du marché.
+
+**Tâches - Phase 1 (Onglet Mercurial)** :
+- [x] Identifier le type de marché du devis sélectionné
+- [x] Détecter si le marché est de type "hybride"
+- [x] Ajouter un nouvel onglet "Mercurial" dans l'interface devis (au niveau de l'onglet Produits)
+- [x] Récupérer tous les produits associés au marché
+- [x] Filtrer les produits "Hors Marché 999"
+- [x] Afficher la liste des produits dans l'onglet Mercurial
+- [x] Gérer l'affichage/masquage de l'onglet selon le type de marché
+
+**Tâches - Phase 2 (Améliorations visuelles et règles métier)** :
+- [ ] **Visibilité de l'onglet Mercurial** : Rendre l'onglet "Mercurial" visuellement distinct (couleur de fond différente, par exemple) pour qu'il soit clairement identifiable par les commerciaux
+
+**Types de marchés hybrides** :
+Deux cas de marchés hybrides doivent être gérés différemment :
+
+**CAS 1 - Mercuriale sans remise** :
+- Liste mercuriale en prix nets SANS remise applicable sur ces références
+- Reste du catalogue disponible avec possibilité de remises en autonomie
+
+**CAS 2 - Mercuriale avec remise possible** :
+- Liste mercuriale en prix nets AVEC possibilité de remises sur ces références
+- Reste du catalogue disponible avec possibilité de remises en autonomie
+
+**Règles communes aux 2 cas** :
+- Quand le devis contient UNIQUEMENT des références mercuriales → pas de demande d'accord nécessaire, le RR peut valider directement
+- Quand le devis contient références mercuriales + catalogue général → seules les références du catalogue sont concernées par les seuils de marge et peuvent générer une demande d'accord
+- Si geste commercial souhaité sur un devis 100% mercurial → utiliser le champ "Demande geste commercial" existant
+
+**Tâches - Paramétrage base de données** :
+- [ ] Ajouter un champ dans la table `marches` pour définir le type de marché hybride :
+  - `type_mercurial` (ENUM ou INT) : NULL = non hybride, 1 = CAS 1 (sans remise), 2 = CAS 2 (avec remise)
+- [ ] Modifier la fiche marché pour permettre la sélection du type de marché hybride
+
+**Tâches - Logique métier de validation** :
+- [ ] Détecter si un devis contient uniquement des produits mercuriaux
+- [ ] Détecter si un devis contient un mix mercurial + catalogue
+- [ ] Adapter le calcul des seuils de marge :
+  - Si devis 100% mercurial → pas de vérification de seuil, validation RR directe
+  - Si devis mixte → calculer les seuils uniquement sur les produits du catalogue général
+- [ ] Bloquer/autoriser les remises sur produits mercuriaux selon le type de marché (CAS 1 vs CAS 2)
+- [ ] Tester le workflow complet avec les 2 types de marchés hybrides
+
 ### Module SAP

+#### 13. Import et contrôle des clients SAP
+**Priorité**: Haute
+**Description**: Contrôler les nouveaux clients créés dans la base CLEO et vérifier la correspondance avec la base SAP.
+**Tâches**:
+- [ ] Identifier le script/contrôleur d'import des clients SAP
+- [ ] Analyser la structure des données importées
+- [ ] Mettre en place un système de contrôle de correspondance
+  - [ ] Vérifier l'unicité du `clients.code` (identifiant SAP)
+  - [ ] Détecter les doublons potentiels (nom, adresse)
+  - [ ] Signaler les incohérences entre SAP et CLEO
+- [ ] Créer un rapport d'import avec :
+  - [ ] Nombre de clients importés
+  - [ ] Nombre de clients mis à jour
+  - [ ] Nombre d'anomalies détectées
+- [ ] Gestion des cas particuliers :
+  - [ ] Client existe dans CLEO mais pas dans SAP
+  - [ ] Client existe dans SAP mais code différent dans CLEO
+  - [ ] Contacts orphelins après import
+
 #### 14. Gestion de la prise en charge
 **Priorité**: Haute  
 **Description**: Ajouter la traçabilité de la prise en charge et du transfert EDI.  
@@ -117,65 +163,7 @@

 ### Plan de migration - État d'avancement

-#### ✅ Phase 0 - Refactoring base de données (COMPLÉTÉ - 12/09/2025)
- [x] Script de migration SQL créé
- [x] Table `y_pages` migrée depuis `uof_frontal`
- [x] Table `z_logs` créée dans `cleo`
- [x] Base `cleo` créée avec toutes les tables
- [x] Données migrées de `uof_linet` vers `cleo`
- [x] Références à `uof_frontal` supprimées
- [x] Classe Database PDO créée
- [x] Variables d'environnement `.env` implémentées
- [x] Tests validés en DEV
-
-#### ✅ Phase 1 - Environnement DEV IN3 (COMPLÉTÉ - 12/09/2025)
- [x] Container `maria3` créé sur IN3
- [x] MariaDB 11.4 installé et configuré
- [x] Base `cleo` migrée vers `maria3`
- [x] Configuration pointant vers `maria3` (IP: 13.23.33.4)
- [x] Application testée et fonctionnelle
- [x] MariaDB supprimé de `dva-front`
- [x] Script de déploiement optimisé (`deploy-cleo-fast.sh`)
-
-#### Phase 2 - Préparation PROD IN4 (À FAIRE)
-**Export depuis IN3:**
- [ ] Exporter le container `dva-front` depuis IN3
-  ```bash
-  incus export dva-front dva-front-export.tar.gz
-  ```
- [ ] Exporter le container `maria3` depuis IN3
-  ```bash
-  incus export maria3 maria3-export.tar.gz
-  ```
-
-**Import sur IN4:**
- [ ] Importer `dva-front` comme `pra-front` sur IN4
-  ```bash
-  incus import dva-front-export.tar.gz pra-front
-  ```
- [ ] Importer `maria3` comme `maria4` sur IN4
-  ```bash
-  incus import maria3-export.tar.gz maria4
-  ```
- [ ] Configurer les IPs et paramètres réseau sur IN4
- [ ] Adapter le fichier `.env` pour l'environnement PROD
-
-#### Phase 3 - Migration des données PROD (À FAIRE)
- [ ] Effectuer une sauvegarde complète des bases PROD sur IN2/nx4
- [ ] Exporter les données de `uof_frontal` et `uof_linet` depuis IN2/nx4
- [ ] Utiliser le script de migration SQL pour fusionner les données
- [ ] Importer les données fusionnées dans `maria4` sur IN4
- [ ] Configurer `pra-front` pour pointer vers `maria4`
- [ ] Tests de validation en pré-production
-
-#### Phase 4 - Bascule PROD (À FAIRE)
- [ ] Planifier la fenêtre de maintenance
- [ ] Arrêter l'application sur IN2
- [ ] Synchronisation finale des données vers IN4/maria4
- [ ] Basculer le DNS/proxy vers IN4
- [ ] Valider le fonctionnement en production
- [ ] Monitoring post-migration (48h)
- [ ] Décommissionner IN2 après période de stabilisation
+✅ **Migration complétée** - Toutes les phases (0 à 4) sont terminées.

 ### Configuration technique

@@ -207,6 +195,81 @@ DB_PASSWORD=<PROD_PASSWORD>  # À sécuriser
 - [ ] Scripts de backup automatisés à mettre en place
 - [ ] Réplication master-slave pour haute disponibilité (optionnel)

+## Modification Contacts Clients - Migration vers clients.code
+
+### Contexte
+La relation entre `clients_contacts` et `clients` utilise actuellement `clients.rowid` comme clé étrangère.
+Cela pose problème lors des imports SAP qui peuvent écraser ou modifier les `rowid`.
+Il faut migrer vers `clients.code` (identifiant SAP immuable) pour garantir l'intégrité des relations.
+
+### Plan de correction
+
+#### 1. Vérification préalable
+- [ ] Lire la structure actuelle de la table `clients`
+  - [ ] Confirmer que `code` est de type INT
+  - [ ] Vérifier la contrainte UNIQUE sur `code`
+  - [ ] Vérifier l'index sur `code`
+- [ ] Lire la structure de `clients_contacts`
+  - [ ] État actuel de `fk_client`
+  - [ ] Contraintes de clé étrangère existantes
+- [ ] Vérifier les données existantes
+  - [ ] Nombre de contacts déjà enregistrés
+  - [ ] Cohérence des relations actuelles
+
+#### 2. Modification de la structure
+- [ ] Supprimer la contrainte FK actuelle sur `clients_contacts.fk_client`
+- [ ] Modifier le type de `clients_contacts.fk_client` pour correspondre à `clients.code`
+- [ ] Ajouter la nouvelle contrainte FK référençant `clients.code`
+  - [ ] `ON DELETE CASCADE`
+  - [ ] `ON UPDATE CASCADE`
+- [ ] Vérifier/ajouter index UNIQUE sur `clients.code` si nécessaire
+
+#### 3. Migration des données
+- [ ] Créer un script de migration SQL
+- [ ] Sauvegarder les données actuelles de `clients_contacts`
+- [ ] Convertir les `fk_client` (rowid → code)
+- [ ] Valider la cohérence des données migrées
+- [ ] Tester l'intégrité référentielle
+
+#### 4. Adaptation du code applicatif
+- [x] ✅ Contrôleur `cjxcontacts.php`
+  - Aucune modification nécessaire (utilise déjà `fk_client` de manière générique)
+- [x] ✅ Contrôleur `cjxdevis.php`
+  - `load_clients_devis` : modifié pour retourner `clients.code`
+  - `save_new_client` : modifié pour utiliser `newCode` au lieu de `newClientId`
+- [x] ✅ JavaScript `jdevis.js`
+  - Fonction `autocompleteClient` : modifiée pour utiliser `list[i]['code']` au lieu de `list[i]['rowid']`
+  - `loadContactsClient(list[i]['code'])` : passe maintenant le code SAP
+- [ ] **Import clients SAP** : À TRAITER EN PRIORITÉ
+  - [ ] Fichier concerné : identifier le contrôleur/script d'import
+  - [ ] Lors de l'import, si un client existe déjà (même `code`), mettre à jour ses infos SANS changer le `code`
+  - [ ] Gérer la mise à jour des contacts : les contacts existants doivent conserver leur lien via `fk_client = code`
+  - [ ] Si import d'un nouveau client : créer avec le `code` SAP fourni
+  - [ ] IMPORTANT : Ne jamais modifier `clients.code` après création (immuable)
+
+#### 5. Tests et validation
+- [ ] Tests de création de contact
+- [ ] Tests de modification de contact
+- [ ] Tests de suppression de contact (soft delete)
+- [ ] Tests de sélection de contact dans un devis
+- [ ] Simuler un import SAP et vérifier la stabilité des relations
+
+### Notes techniques
+```sql
+-- Exemple de modification FK
+ALTER TABLE clients_contacts
+  DROP FOREIGN KEY fk_clients_contacts_client;
+
+ALTER TABLE clients_contacts
+  ADD CONSTRAINT fk_clients_contacts_client
+  FOREIGN KEY (fk_client)
+  REFERENCES clients(code)
+  ON DELETE CASCADE
+  ON UPDATE CASCADE;
+```
+
+---
+
 ## Améliorations techniques prioritaires

 ### Sécurité
@@ -252,26 +315,15 @@ DB_PASSWORD=<PROD_PASSWORD>  # À sécuriser

 ## Notes de développement

-### Structure de la table `clients_contacts` (à créer)
-```sql
-CREATE TABLE clients_contacts (
-    rowid INT PRIMARY KEY AUTO_INCREMENT,
-    fk_client INT NOT NULL,
-    nom VARCHAR(100),
-    prenom VARCHAR(100),
-    fonction VARCHAR(100),
-    telephone VARCHAR(20),
-    mobile VARCHAR(20),
-    email VARCHAR(255),
-    principal TINYINT DEFAULT 0,
-    active TINYINT DEFAULT 1,
-    date_creat DATETIME,
-    fk_user_creat INT,
-    date_modif DATETIME,
-    fk_user_modif INT,
-    FOREIGN KEY (fk_client) REFERENCES clients(rowid)
-);
-```
+### ✅ Structure de la table `clients_contacts` (CRÉÉE - v2.0.3)
+Table créée et opérationnelle avec :
+- Clé étrangère vers `clients` avec CASCADE
+- Gestion du contact principal (un seul par client)
+- Soft delete via champ `active`
+- Traçabilité (date_creat, fk_user_creat, date_modif, fk_user_modif)
+- Index sur fk_client, principal et email
+- Contrainte UNIQUE sur rowid
+- Voir `docs/migration_clients_contacts.sql` pour la structure complète

 ### Modifications table `devis` pour SAP
 ```sql
@@ -285,24 +337,36 @@ ALTER TABLE devis ADD COLUMN erreur_transfert_edi TEXT;

 ## Résumé de l'état actuel

-### ✅ Réalisations (v2.0.2 - 12 septembre 2025)
+### ✅ Réalisations
+**v2.0.1 (12 septembre 2025)**
 1. **Migration DEV complétée** : Architecture séparée application/BDD
 2. **Base unique `cleo`** : Fusion réussie de 3 bases en une seule
 3. **Sécurité renforcée** : PDO, requêtes préparées, variables d'environnement
 4. **Container `dva-front`** : MariaDB supprimé, application PHP uniquement
 5. **Container `maria3`** : Base de données centralisée opérationnelle
-6. **Audit de sécurité complété** : 14 vulnérabilités SQL identifiées et corrigées
+
+**v2.0.2 (12 septembre 2025)**
+1. **Audit de sécurité complété** : 14 vulnérabilités SQL identifiées et corrigées
   - 8 critiques (fonction autocomplete, injections dans cjxpost.php, mclients.php, mdevis.php)
   - 6 moyennes (cjxdevis.php, cjxexport.php, cjximport.php, mexpxls.php)
-7. **Fonctionnalité Réactivation devis** : Bouton permettant de réactiver les devis archivés (statut 20 → 1)
+2. **Fonctionnalité Réactivation devis** : Bouton permettant de réactiver les devis archivés (statut 20 → 1)
+
+**v2.0.3 (21 octobre 2025)**
+1. **Gestion multi-contacts par client** : Table `clients_contacts` opérationnelle
+2. **Interface CRUD complète** : Modale Bootstrap avec création/modification/suppression de contacts
+3. **Contrôleur AJAX `cjxcontacts.php`** : 5 endpoints sécurisés avec requêtes préparées
+4. **Intégration dans les devis** : Sélecteur de contact avec affichage des infos en lecture seule
+5. **Gestion automatique du contact principal** : Un seul contact principal par client
+6. **Soft delete** : Prévention de la suppression du dernier contact actif

 ### 🎯 Prochaines étapes prioritaires
-1. **Migration PROD vers IN4** : Export/Import des containers vers `pra-front` et `maria4`
-2. **Fonctionnalités métier** : Points 14, 16 (voir sections ci-dessus)
-3. **Sécurité XSS** : Audit et correction des failles XSS potentielles
-4. **Tests** : Mise en place de tests automatisés de sécurité
+1. **Nettoyage BDD** : Supprimer les anciens champs contact de la table `clients` (après validation)
+2. **Migration PROD vers IN4** : Export/Import des containers vers `pra-front` et `maria4`
+3. **Fonctionnalités métier** : Points 8, 14, 16, 21 (voir sections ci-dessus)
+4. **Sécurité XSS** : Audit et correction des failles XSS potentielles
+5. **Tests** : Mise en place de tests automatisés de sécurité

 ---

-*Document mis à jour le 12 septembre 2025*  
-*Version 2.0.2 - Sécurité SQL complète*
+*Document mis à jour le 21 octobre 2025*
+*Version 2.0.3 - Gestion multi-contacts*