---
suivi: 1160
date: 2026-08-03
sujet: Commercial — multi-acquéreurs + référentiel matrimonial (#101)
chantier: commercialisation
type: feature
statut: poussé
hash: 299df766
fichiers:
  - app/Support/Commercial/ReferentielMatrimonial.php
  - app/Models/ReservationAcquereur.php
  - app/Models/Reservation.php
  - database/migrations/2026_08_03_140000_create_reservation_acquereurs_table.php
  - app/Services/ReservationAcquereurUpdateService.php
  - app/Services/SharePointService.php
  - app/Http/Controllers/AcquereurController.php
  - app/Http/Controllers/ReservationController.php
  - app/Http/Controllers/CommercialisationController.php
  - app/Http/Requests/UpdateAcquereurFicheRequest.php
  - resources/js/Pages/Programmes/Acquereur/Show.vue
  - resources/js/Components/Commercialisation/LotsGrillePanel.vue
  - database/data/journal_mises_a_jour_post_2026_06_12.php
  - public/build/
  - docs/suivi/SUIVI_1160_commercial_multi_acquereurs.md
---

## PROMPT ENVOYÉ

SUIVI #1160 — lot 5 commercial. Individualisation situation/régime matrimonial
et co-acquéreurs multiples (#101). Lot STRUCTUREL + migration données.
Réf. SUIVI_1154.

## SYNTHÈSE

### Fiches lues

- `SUIVI_1154` — dual JSON/FK co-acquéreur ; situation sur contact principal ;
  lecteurs AF/PDF/SharePoint/fiche/grille ; AdF = contact principal.
- `SUIVI_1158` / `SUIVI_1159` — zone série `LotsGrillePanel` + build.

### Décisions retenues

| Point | Choix |
|-------|--------|
| Facturation AdF | `reservations.contact_id` = **acquéreur principal** uniquement |
| Pivot | `reservation_acquereurs` (role, ordre, situation, régime **par personne**) |
| Legacy | `co_acquereur` / `co_contact_id` / situation contact **conservés en base**, plus écrits |
| Non mappable | valeur **conservée** (jamais NULL silencieux) + rapport |
| Recouvrement JSON+FK | FK prime ; 1 seule ligne pivot ; overlap compté |

### Mapping UI ↔ stocké ↔ back

| Libellé affiché | Valeur stockée | Libellé back |
|-----------------|----------------|--------------|
| Célibataire | `celibataire` | SITUATION_CELIBATAIRE |
| Marié(e) | `marie` | SITUATION_MARIE |
| Pacsé(e) | `pacse` | SITUATION_PACSE |
| Divorcé(e) | `divorce` | SITUATION_DIVORCE |
| Veuf(ve) | `veuf` | SITUATION_VEUF |
| Union libre | `union_libre` | SITUATION_UNION_LIBRE |
| Communauté réduite aux acquêts | `communaute_reduite_acquets` | REGIME_* |
| Communauté universelle | `communaute_universelle` | |
| Séparation de biens | `separation_biens` | |
| Participation aux acquêts | `participation_acquets` | |
| Régime étranger | `regime_etranger` | |
| Sans contrat | `sans_contrat` | |

Régime affiché seulement si situation = `marie`.

### Lecteurs à N acquéreurs

| Lecteur | Comportement retenu |
|---------|---------------------|
| `AcquereurController` / `Show.vue` | Liste N via pivot ; situation/régime par personne |
| `ReservationAcquereurUpdateService` | Sync pivot ; principal → `reservations.contact_id` |
| `GenerationAppelFondService` | **Inchangé** : `contact_id` = principal |
| PDF AF (`GenerationAppelFondPDFService`) | Contact de l’AF = principal |
| `SharePointService` | Nom dossier = tous les noms pivot joints par ` ET ` (fallback legacy) |
| `LotsGrillePanel` | Ajout/retrait dynamique N cos à la réservation ; recherche inclut pivot |

### Question Robin (non tranchée)

Si plusieurs acquéreurs, faut-il un jour facturer / rattacher les AdF à autre chose
que le principal (`appels_de_fonds.contact_id`) ? Aujourd’hui : **non**, principal seul.
À confirmer métier si besoin de co-titulaires Intacct.

### Rapport migration

Généré à l’exécution : `storage/app/migration_1160_reservation_acquereurs_report.json`
(compteurs mappées / non reconnues / co FK / co JSON / overlaps). À coller après
`migrate` prod. MySQL local indisponible au moment du lot → chiffres prod.

## DÉPLOIEMENT-TEST

1. `git pull origin main`
2. `php artisan migrate --force`
3. Lire le JSON rapport + `php artisan journal:sync` + `view:clear`
4. Tests : 29 résas à co → 2 lignes pivot ; overlap sans doublon ; 3 acquéreurs
   situations distinctes ; régime masqué hors marié ; 59 résas ouvrables ;
   fiche/PDF/SharePoint 1/2/3.

## LEÇON

Ne pas supprimer les colonnes legacy dans le même lot que la migration pivot :
valider d’abord en prod. AdF reste volontairement mono-contact (principal) —
toute facturation multi-personnes = décision Robin, pas Cursor.