---
suivi: 1179
date: 2026-08-04
sujet: SRU — nettoyage doublons dates (notif / expir)
chantier: commercialisation
type: feature
statut: poussé
hash: 1e71c680
fichiers:
  - app/Http/Requests/UpdateAcquereurFicheRequest.php
  - app/Http/Controllers/ReservationController.php
  - resources/js/Pages/Programmes/Acquereur/Show.vue
  - resources/js/Components/Commercialisation/LotsGrillePanel.vue
  - tools/diag/diag_sru_notif_sans_envoi_1179.php
  - tests/Unit/SruNettoyageSaisie1179Test.php
  - database/data/journal_mises_a_jour_post_2026_06_12.php
  - public/build/
  - docs/suivi/SUIVI_1179_sru_nettoyage_doublons_dates.md
---

## PROMPT ENVOYÉ

SUIVI #1179 — jumelle #1178 : retirer doublons dates SRU (expir réflexion,
notif vs envoi), ordre chronologique du bloc, moins de champs saisissables
malgré l’ajout réception ; aucune écriture données / recalcul / bascule statut.

## SYNTHÈSE

### Fiches lues
- `SUIVI_1178` — réception = `date_ar_client` ; calcul fiable/estimée ; questions
  Robin sur notif vs envoi et `date_expir_reflexion`.
- `SUIVI_1156` — avait distingué expir_reflexion ≠ fin délai (usage réel
  contredit par Mélanie).
- `SUIVI_1176` / `#1172` / `#1177` — lecture seule de `date_sru_fin_delai`
  (échéance, retards, résumé) : inchangée.

### OBJET 1 — date_expir_reflexion
Retirée de la saisie (fiche + grille + whitelist + store/update). Colonne
conservée. 0/61 en prod — aucun impact données.

### OBJET 2 — notif vs envoi → issue (a) MÊME NOTION pratique
**Origine instruite :**
| Colonne | Apparition | Écriture | Pilote J+10 |
|---------|------------|----------|-------------|
| `date_notif_sru` | 2026-05-12 `clients` → résa 13/05 | saisie ERP (pas ImportPegao) | non |
| `date_sru_envoi` | 2026-05-13 `acquereur_fiche…` ; seed migration depuis notif si envoi null | saisie + Observer | oui (repli si pas AR) |

Mélanie ne distingue pas les deux ; 11 dossiers notif sans envoi → pas de fin
calculée. **Issue (a)** : seul `date_sru_envoi` reste saisissable ; `date_notif_sru`
en lecture seule si renseignée (37 valeurs conservées à l’écran) ; bandeau ambre
si notif sans envoi/réception.

### OBJET 3 — décompte saisissables
| | Champs |
|--|--------|
| **AVANT** (#1178) | 6 : notif · envoi · réception · expir_reflexion · preuve · sru_statut |
| **APRÈS** | 4 : envoi · réception · preuve · sru_statut |
| Lecture seule | fin de délai (calculée) · ancienne notif si présente |

`sru_statut` reste saisissable (#1176 : purge = fait juridique, pas auto).

### OBJET 4 — bloc chronologique
envoi → réception → fin (RO) → statut → preuve (+ notif RO si présente).
Plus de dispersion avec « Suivi administratif ».

### Garde-fous
Aucune migration DDL. Aucun recalcul des 26 `date_sru_fin_delai`. Aucun
basculement `sru_statut`. Chemins échéance/retard/alertes inchangés (même
colonne). Anti-silence #1156 : hints si post de clés retirées.

### Liste des 11 (notif sans envoi)
À produire en lecture seule en prod :
`php tools/diag/diag_sru_notif_sans_envoi_1179.php`
(MariaDB local indisponible au moment du lot — coller la sortie dans cette
fiche / synthèse après run prod.)

## DÉPLOIEMENT-TEST

1. `git pull origin main` ; `php artisan optimize:clear` ; `view:clear` ; `journal:sync`
2. **Pas de migrate**
3. Tests 1–9 du prompt + diag 11 + KPI remises + `commercial:coherence-reservation-lots`

## LEÇON

Quand l’assistante commerciale ne distingue pas deux libellés, ce n’est pas un
problème de documentation : c’est un doublon fonctionnel. Le #1156 avait raison
sur le plan théorique (deux colonnes) et tort sur l’usage réel (une seule saisie
utile). Conserver la colonne, retirer l’écran.