248 lines
36 KiB
Markdown
Executable File
248 lines
36 KiB
Markdown
Executable File
# Bug risolti e validazioni
|
|
|
|
## Obiettivo
|
|
|
|
Questa sezione tiene separato il materiale di fix dal manuale generale. Qui annotiamo:
|
|
|
|
- bug corretti
|
|
- fix applicato
|
|
- stato della verifica
|
|
- eventuali controlli ancora da fare su staging
|
|
|
|
## Registro sintetico
|
|
|
|
### Import GESCON: fallback storico su `id_cond` quando il legacy sposta `cod_cond`
|
|
|
|
- Problema: in archivi come `0026` il vecchio amministratore ha riallineato i nominativi nel legacy spostando `cod_cond` tra una gestione e la successiva, mentre `id_cond` e rimasto stabile. Questo rompeva import di unita, cronologia nominativi, rate e incassi perche il dominio usava ancora `cod_cond` come chiave forte.
|
|
- Causa tecnica: `ImportGesconFullPipeline` preferiva `cod_cond` per valorizzare `unita_immobiliari.legacy_cond_id`, ricostruiva la storia `condomin` filtrando `cod_cond` e risolveva le unita di rate/incassi dal solo `cod_cond` senza ancora stabile su `id_cond`.
|
|
- Fix applicato: `app/Console/Commands/ImportGesconFullPipeline.php` ora ancora il dominio su `id_cond` / `legacy_id_cond`, usa `cod_cond` come fallback annuale e, per la cronologia `condomin`, prova prima `id_cond` e poi il nominativo (`nom_cond` / `proprietario_denominazione`) se il codice annuale non basta. La UI di `Importazione archivi` e stata anche orientata sul flusso `ultima aperta -> ritroso`.
|
|
- Stato: [P] validato su codice, helper privato e smoke test reale `0026/0001`: `extractStableLegacyCondId()` preferisce `id_cond` rispetto a `cod_cond` e l'import reale sul tenant `stabile_id=32` completa correttamente il ciclo. La verifica specifica dello shift cross-year di `cod_cond` resta pendente finche lo staging non espone piu annualita dello stesso stabile.
|
|
|
|
### Import GESCON 0026: rerun non idempotente su `rate_emesse` e `dati_bancari`
|
|
|
|
- Problema: rilanciando `gescon:import-full` su `0026 / anno 0001 / stabile_id=32` il numero righe restava stabile ma la somma di `rate_emesse` raddoppiava (`11300.27 -> 22600.54`) e `dati_bancari` cresceva a ogni rerun (`3 -> 4 -> 5`) pur trattandosi dello stesso conto `CCB`.
|
|
- Causa tecnica: nel ramo update di `stepRate()` gli importi venivano ricalcolati come `existing + importo`, quindi ogni reimport aggiungeva di nuovo lo stesso addebito; in `stepBanche()` il lookup dell'esistente usava `$iban` e `$numero` originali invece dei valori realmente risolti (`resolvedIban` e fallback `cod_cassa`), mancando il match e inserendo duplicati.
|
|
- Fix applicato: `app/Console/Commands/ImportGesconFullPipeline.php` ora rende idempotente l'update di `rate_emesse` azzerando il baseline del record al primo touch del run e aggregando solo gli eventuali duplicati della stessa esecuzione; `stepBanche()` usa i valori risolti per il match e consolida gli esatti duplicati gia presenti sullo stesso conto.
|
|
- Stato: [U] validato end-to-end su `0026 / anno 0001 / stabile_id=32` con tre esecuzioni consecutive del comando. Contatori finali: `rate_emesse=81`, `rate_emesse_sum_addebitato=11300.27`, `dati_bancari=1`, `incassi=0`.
|
|
|
|
### Staging GESCON `operazioni`: scope stabile assente e reload non idempotente
|
|
|
|
- Problema: la tab Filament `admin-filament/gescon/ordinarie` filtra `operazioni` per stabile solo se nello staging esiste `cod_stabile`. Nel database di sessione la tabella `gescon_import.operazioni` era stata creata senza quella colonna, quindi il tab Operazioni poteva mischiare scritture di stabili diversi. Al primo tentativo di riallineamento i reload slice-aware fallivano inoltre con duplicate key sulle righe gia presenti.
|
|
- Causa tecnica: `LoadGesconMdbToStaging` valorizzava `cod_stabile` e `legacy_year` solo se le colonne esistevano gia, ma non faceva evoluzione schema sulle tabelle storiche create in precedenza. In piu il caricamento di `operazioni` usava solo `insert`, quindi un reload sullo stesso `id_operaz` collassava sulla PK legacy invece di aggiornare la riga esistente.
|
|
- Fix applicato: `app/Console/Commands/LoadGesconMdbToStaging.php` ora aggiunge in best-effort le colonne di slice mancanti (`cod_stabile`, `legacy_year`) alla tabella di staging selezionata e, per `operazioni`, rende il reload idempotente con `updateOrInsert` su `id_operaz`.
|
|
- Stato: [U] validato in sessione. Reload riusciti su `0016/0914`, `0016/0913`, `0016/0912` con staging finale annotato `0016|0914|61`, `0016|0913|168`, `0016|0912|250`. Per `0026/0001` `operazioni` resta `0`, coerente con il contenuto del file annuale in questa sessione.
|
|
|
|
### Ordinarie legacy e import banca Fucino su `0016`
|
|
|
|
- Problema: `admin-filament/gescon/ordinarie` andava in `Undefined variable $query` nel mapping delle righe Operazioni. In parallelo la sezione legacy `incassi` su `0016` continuava a vedere righe duplicate perche convivevano slice annuali corrette (`legacy_year=0912/0913/0914`) e righe storiche orfane con `legacy_year=null`. Sul lato banca, i file reali Banca del Fucino arrivavano in `.xls` e la UI esponeva ancora il formato come solo `XLSX`.
|
|
- Causa tecnica: in `Ordinarie.php` era rimasta una chiamata a `$query->where(...)` dentro una `map()` dove il builder non esiste. Per `incassi` mancava una regola di preferenza per gli slice annuali annotati, quindi i record orfani di staging continuavano a inquinare UI e import dominio. La UI movimenti banca accettava di fatto Excel legacy via parser, ma non lo dichiarava esplicitamente nei form.
|
|
- Fix applicato: rimosso il riferimento fuori scope in `app/Filament/Pages/Gescon/Ordinarie.php`; `applyIncassiFilters()` e `ImportGesconFullPipeline::stepIncassi()` ora ignorano le righe `legacy_year=null` quando per lo stesso stabile esistono gia slice annotate. Nello staging `gescon_import.incassi` e stato anche eseguito un cleanup mirato che ha eliminato `1753` righe orfane nulle duplicate di slice gia ricaricate. La UI banca in `CasseBancheMovimenti` e `DatiBancariDettaglio` dichiara ora anche `.xls` e il formato `Excel XLS/XLSX`.
|
|
- Stato: [U] validato in sessione. `getOperazioniProperty()` torna a costruire un `LengthAwarePaginator`; `operazioni` duplicate esatte su `0016/0026` = `0`; `incassi` duplicate esatte su `0016/0026` = `0` dopo il cleanup dei null orphan. Importati su `0016 / stabile_id=17 / conto_id=14 / legacy_cod_cassa=CCB` `1935` movimenti banca da file Fucino, con range `2022-02-03 -> 2026-06-03`; `891` righe sono state scartate come duplicati attesi fra estratti sovrapposti.
|
|
|
|
### Consultazione legacy-aligned: gestioni visibili vs gestioni conteggiabili
|
|
|
|
- Problema: sia l'estratto conto soggetto sia la scheda unità filtravano i dati con la logica del solo `anno attivo`, mentre per il controllo legacy serve una distinzione piu precisa: anni correnti da conteggiare, ultima gestione chiusa ancora visibile per confronto, storico piu vecchio nascosto salvo filtro.
|
|
- Causa tecnica: la UI usava `AnnoGestioneContext` come unico discriminante temporale; `gestioni_contabili` non veniva usata per decidere se un esercizio fosse solo consultabile oppure ancora conteggiabile nel dovuto corrente.
|
|
- Fix applicato: e stato introdotto `app/Support/GestioneVisibility.php`. Regola attuale: anni visibili = tutte le gestioni aperte/attive + l'ultima gestione chiusa; anni conteggiabili = solo gestioni aperte/attive. `EstrattoContoSoggetto`, `UnitaImmobiliarePage` e `GestioniArchivio` usano ora questa policy per nascondere lo storico piu vecchio e togliere dal dovuto gli esercizi chiusi mantenuti solo per controllo.
|
|
- Stato: [U] validato in sessione. Per `stabile_id=17` (`0016`) la policy finale e `visible_years=[2025,2024,2023]`, `countable_years=[2025,2024]`, `closed_visible_years=[2023]`. Verifica tecnica su scheda unità: `unita_id=660` scende a `24` rate e `12` incassi visibili, `unita_id=662` a `48` rate e `62` incassi visibili, con range anni `2023 -> 2025`.
|
|
|
|
### Super Admin ACL: HUB rapido a matrice per programmi
|
|
|
|
- Problema: la gestione ACL programmi era disponibile solo nella scheda dettaglio allow/deny, poco adatta a variazioni rapide per gruppi principali.
|
|
- Causa tecnica: mancava una vista a matrice ruolo-programma che permettesse di abilitare o disabilitare velocemente la visibilita per ruolo.
|
|
- Fix applicato: `app/Filament/Pages/SuperAdmin/ProgrammiAcl.php` e `resources/views/filament/pages/super-admin/programmi-acl.blade.php` ora espongono un HUB con matrice programmi x ruoli, checkbox rapidi e reset al default catalogo; la scheda esistente e stata mantenuta come tab separata. E stata aggiunta anche una seconda tab che mostra il baseline attuale R/W per gruppi/menu, in attesa di un backend dedicato agli override granulari.
|
|
- Stato: [U] validato localmente: nessun errore editor sulla page Filament e sulla blade.
|
|
|
|
### Palazzine stabile: mappa visiva per scala, piano e adiacenze
|
|
|
|
- Problema: la vista `admin-filament/condomini/stabile?tab=palazzine` era disallineata e poco utile per gestire incidenti tecnici come perdite d acqua, dove serve capire subito chi sta accanto, sopra e sotto una unità.
|
|
- Causa tecnica: la pagina mostrava solo card riassuntive per palazzina, senza ordinamento operativo delle unita e senza una lettura per scala/piano/interno.
|
|
- Fix applicato: `app/Http/Controllers/Admin/PalazzineController.php` ora ordina le unita per scala, piano e interno; `resources/views/admin/palazzine/index.blade.php` espone una mappa per scala e per piano con card unita che mostrano adiacenze orizzontali e riferimenti verticali (`accanto`, `sopra`, `sotto`).
|
|
- Stato: [U] validato localmente: nessun errore editor su controller e blade.
|
|
|
|
### Unita immobiliare 0016: estratto vuoto con incassi presenti e relazioni correnti discordanti
|
|
|
|
- Problema: sulle unità `0016-B-4` (`unita_id=660`, `legacy_cond_id=49`) e `0016-B-5` (`unita_id=662`, `legacy_cond_id=50`) la scheda unità mostrava `Persone collegate` incoerenti e l estratto `rate & incassi` vuoto, pur avendo incassi importati per i codici legacy `49/50`.
|
|
- Causa tecnica: per `0016` non esistono righe in `rate_emesse` (`0` su `stabile_id=17`), mentre sono presenti `3789` righe nella tabella legacy `gescon_import.rate`; la pagina unità leggeva solo `rate_emesse` e costruiva gli incassi partendo dalle note delle rate emesse. In piu, quando `proprieta` e `rubrica_ruoli`/`persone_unita_relazioni` non concordavano, la sezione persone privilegiava i diritti proprietari storici.
|
|
- Fix applicato: `app/Filament/Pages/UnitaImmobiliarePage.php` ora usa un fallback legacy su `gescon_import.rate` e `incassi` quando una unità non ha `rate_emesse`; per `Persone collegate` preferisce la storia legata alla unità (`unita_immobiliare_nominativi`) e integra i `comproprietari` legacy correnti della stessa `legacy_cond_id` quando la materializzazione storica manca o è incompleta. La testata della scheda non mostra piu come etichetta un nominativo storico scaduto, ma ripiega sul codice unità.
|
|
- Stato: [U] validato via hydration diretta pagina. `unita_id=660` torna con `48` righe estratto e `38` incassi e come proprietario corrente `Le Foche Ermanno-Bianchin M.`; `unita_id=662` torna con `96` righe estratto e `78` incassi e mostra `Barone Michele` piu i comproprietari legacy correnti `Nardi Camillo e Flavia` e `Nardi Flavia`.
|
|
|
|
### Unita immobiliare 0016: payload legacy completo, CF corretti, selettore corrente e bonifica incassi
|
|
|
|
- Problema: dopo l allineamento di `0016`, la ricerca nominativi apriva la unità giusta ma il selettore restava su etichette storiche (`MASTRANGELI...`), i CF in pagina continuavano a derivare da rubrica stantia, i blocchi `cond_* / catasto_* / pertinenze_* / diritti_* / inquilin_*` non arrivavano fino alla UI e l estratto compatto mostrava ancora righe duplicate o a zero.
|
|
- Causa tecnica: `unita_immobiliare_nominativi.legacy_payload` salvava solo un sottoinsieme dei campi legacy; `gescon:materialize-persone-relazioni` privilegiava CF/contatti gia presenti in rubrica; `gescon:sync-rubrica-ruoli` non correggeva i record esistenti; `refreshUnitaOptions()` leggeva `proprieta`; nella contabilità `incassi` su `stabile_id=17` erano rimaste `936` righe duplicate extra e `207` righe a importo zero.
|
|
- Fix applicato: `ImportGesconFullPipeline` ora salva nei payload i prefissi `cond_*`, `catasto_*`, `pertinenze_*`, `diritti_*`, `inquilin_*` e usa `condomin.inquilin_contratto_dal` / `inquilin_cod_fisc`; `GesconMaterializePersoneRelazioniCommand` usa `legacy_payload` come sorgente autorevole per CF/contatti e puo correggere CF/P.IVA stantii se univoci; `GesconSyncRubricaRuoli` aggiorna la rubrica da `Persona`; `UnitaImmobiliarePage` usa il nominativo attivo di `unita_immobiliare_nominativi` nel selettore e mostra in cronologia anche CF, contratto e catasto; `resources/views/filament/pages/unita-immobiliare.blade.php` compatta l estratto in una riga principale per rata/conguaglio con `dovuto`, `pagato` e data pagamento. Sul DB `incassi` di `0016` e stata eseguita una bonifica stretta che ha eliminato tutti i duplicati esatti e tutte le righe a zero senza associazioni utili.
|
|
- Stato: [U] validato localmente sul DB. `incassi` per `condominio_id=17`: `duplicate_extra_rows = 0`, `zero_total = 0`, `remaining_total = 2102`. La UI e pronta a usare i payload completi non appena termina il rebuild `--solo=unita -> --solo=relazioni -> gescon:sync-rubrica-ruoli` in corso sulla sessione.
|
|
|
|
### Unita immobiliare 0016: estratto compatto cross-year da `rate_emissioni_dettaglio` con split `C/I`
|
|
|
|
- Problema: l estratto compatto della scheda unità continuava a leggere solo `gescon_import.rate` o le `rate_emesse` dominio, perdendo la distinzione `C/I`, il periodo reale di gestione (`2024/25`, `2025/26`) e i riferimenti avviso richiesti dal legacy; in piu `legacy_cond_id` su alcune unità (`B-4`) era ormai storico e non bastava piu per recuperare tutte le righe corrette della stessa unità.
|
|
- Causa tecnica: `UnitaImmobiliarePage` risolveva i `cod_cond` correnti da `gescon_import.condomin`, ma quando questi esistevano smetteva di considerare il `legacy_cond_id` salvato sull unità; su `0016-B-4` questo faceva perdere proprio il ramo autoritativo `cod_cond=47` di `rate_emissioni_dettaglio`. La Blade inoltre mostrava il riferimento proprietario dal set relazioni/comproprietari invece che dal record `condomin` corrente.
|
|
- Fix applicato: la pagina mantiene tutti i candidati `cod_cond` ma, per l estratto compatto da `rate_emissioni_dettaglio`, preferisce il `legacy_cond_id` salvato quando esistono righe reali sulla stessa unità/stabile; su `0016-B-4` questo ancora il rendering a `cod_cond=47`. La scheda unità continua a usare `rate_emissioni_dettaglio` come sorgente prioritaria, separa i movimenti `C/I` in Blade, raggruppa per `anno_gestione` e per il campo `Condomino di riferimento` espone `condomin.nom_cond` invece del primo non-comproprietario trovato nelle relazioni.
|
|
- Stato: [U] validato via reflection sulla pagina per `unita_id=658`. Con `gestione=2024/25` il campione autoritativo restituito ora e `52 -> 177,00`, `196 -> 177,00`, `268 -> 177,00`, `626 -> 177,00`, `697 -> 177,00`, `697 -> Conguaglio es.precedente -0,61`, `766 -> 177,00`, tutti `tipo=C`; `getLegacyCondominoRiferimentoNome()` restituisce `Barone Michele`.
|
|
|
|
### Import rate 0016: popolamento `gestioni_annuali` da `generale_stabile.mdb`
|
|
|
|
- Problema: per `0016` la staging `gescon_import.gestioni_annuali` era vuota, quindi la UI non aveva una fonte stabile per i periodi `ordinaria_dal` / `ordinaria_al` e il reload `rate` restava calendar-year biased.
|
|
- Causa tecnica: il pipeline `gescon:import-full --solo=rate` non popolava `gestioni_annuali` dal `generale_stabile.mdb` prima di materializzare piani/rate dominio.
|
|
- Fix applicato: `ImportGesconFullPipeline` ora sincronizza `gestioni_annuali` dalla tabella `anni` di `generale_stabile.mdb` all avvio dello step `rate`, salvando almeno `cartella`, `anno_ordinario`, `ordinaria_dal`, `ordinaria_al`, `riscaldamento_dal`, `riscaldamento_al` e payload raw. Nelle note delle `rate_emesse` vengono inoltre persistiti `anno_gestione`, `numero_ricevuta`, `legacy_year`, `cond_inq` e `avviso_code`.
|
|
- Stato: [P] validato sul DB con `gestioni_annuali_0016 = 6` e `rate_emesse_0016 = 2517` dopo `php artisan gescon:import-full --stabile=0016 --solo=rate`. La UI compatta usa gia la sorgente staging corretta; il dominio storico importato prima del fix avviso mantiene ancora alcuni `avviso_code` precedenti finche non si esegue un reload pulito dedicato delle sole `rate_emesse` esistenti.
|
|
|
|
### Gestioni contabili 0016: tab stabile allineato ai periodi cross-year reali
|
|
|
|
- Problema: il tab `gestioni` dello stabile continuava a mostrare esercizi dominio con periodi `01/01-31/12`, anche quando `generale_stabile.mdb -> anni` definiva esercizi reali `2024/25`, `2025/26` con date `ordinarie_dal/al`.
|
|
- Causa tecnica: `ImportGestioniFromLegacy` e la sync automatica del tab stabile creavano o selezionavano `gestioni_contabili` usando solo `anno_gestione` numerico, senza preferire la riga legacy canonica e senza applicare i periodi di `gestioni_annuali`.
|
|
- Fix applicato: `ImportGestioniFromLegacy`, `ImportGesconFullPipeline` e `GestioniStabileTable` ora derivano label e date da `gestioni_annuali`/`anni`, preferiscono la riga canonica con label cross-year (`Ordinaria 2024/25`) e nel tab stabile filtrano la sola gestione canonica per `tenant + stabile + anno + tipo`.
|
|
- Stato: [U] validato su `0016` con `php artisan gescon:import-gestioni --stabile=0016`; selezione canonica verificata via query applicativa: `2024 | ordinaria | Ordinaria 2024/25 | 2024-10-01 | 2025-09-30`, `2025 | ordinaria | Ordinaria 2025/26 | 2025-10-01 | 2026-09-30`.
|
|
|
|
### Estratto conto soggetto: esposizione vecchia numerazione legacy
|
|
|
|
- Problema: nelle `rate_emesse` rielaborate o lavorate manualmente l estratto conto soggetto mostrava il progressivo dominio ma non il riferimento legacy completo richiesto dall operatività (`Gestione 2024/25 · ricevuta n.138`).
|
|
- Causa tecnica: `EstrattoContoSoggetto` leggeva dalle note solo `n_emissione`, ignorando metadati gia presenti come `anno_gestione`, `numero_ricevuta` e `avviso_code`.
|
|
- Fix applicato: la pagina ora estrae dai metadati note `anno_gestione`, `numero_ricevuta` e `avviso_code` e rende sotto la descrizione un riferimento esplicito tipo `Gestione 2024/25 · ricevuta n.138`, con fallback su `avviso legacy` se la ricevuta manca.
|
|
- Stato: [U] validato via reflection sull helper `buildLegacyReferenceLabel()` con output `Gestione 2024/25 · ricevuta n.138`.
|
|
|
|
### Estratto conto soggetto 0016-B-4: nominativo in testata preso dal soggetto storico e non dalla unità corrente
|
|
|
|
- Problema: l URL `admin-filament/contabilita/estratto-conto/7680?vista=unita&unita_id=658` mostrava in testata `Leardini Alessandra` anche se l unità `0016-B-4` ha come riferimento corrente `Barone Michele`.
|
|
- Causa tecnica: `EstrattoContoSoggetto` usava sempre il `record` route (`soggetti.id=7680`) per nome e CF header. Per `B-4` quel record e storico: `unita_immobiliari.id=658` ha ancora `legacy_cond_id=47`, che coincide con `soggetti.old_id=47` (`Leardini Alessandra`). Le relazioni correnti dell unità sono invece `Michele Barone` proprietario e `Claudia Francioni` comproprietaria.
|
|
- Fix applicato: in `vista=unita` la pagina non si limita piu all header ma, se l unità ha un dataset legacy autoritativo in `rate_emissioni_dettaglio`, costruisce direttamente righe, gruppi, riferimento proprietario e collegamenti soggetto da quel ramo. La testata espone quindi `Barone Michele`, CF `BRNMHL69M11H501K`, `recordCondominoId=7682`, mentre le righe `2024/25` usano `numero_ricevuta` come riferimento primario (`52`, `196`, `268`, `626`, `697`, `766`) e conservano l avviso come `avviso_legacy` (`202410`, `202412`, ...).
|
|
- Stato: [U] validato via hydration diretta del ramo legacy su `unita_id=658`: `header = Barone Michele / BRNMHL69M11H501K`, `Gestione 2024/25 · ricevuta n.52`, `dovuto = 177,00`, `recordCondominoId = 7682`, `incassi_count = 56`.
|
|
|
|
### Scheda unità 0016-B-4: `Condomino di riferimento` da `condomin`
|
|
|
|
- Problema: nella scheda unità il blocco riepilogo poteva mostrare un nominativo derivato dal primo proprietario attivo non `comproprietario`, mentre per `0016-B-4` il riferimento richiesto doveva essere il dato corrente di `gescon_import.condomin`.
|
|
- Causa tecnica: la Blade costruiva `Condomino di riferimento` solo da `relazioniPerTipo['proprietari']`, che e un insieme misto di diritti, relazioni attive, archivio unità e comproprietari legacy.
|
|
- Fix applicato: `UnitaImmobiliarePage` espone ora `getLegacyCondominoRiferimentoNome()` e `getLegacyCondominoRiferimentoCodiceFiscale()`. La Blade usa quindi `condomin.nom_cond` e `condomin.cond_cod_fisc` prima delle relazioni, mentre il picker unità corrente forza la stessa anagrafica legacy autorevole.
|
|
- Stato: [U] validato su `unita_id=658` con output `Barone Michele`, CF `BRNMHL69M11H501K`, picker `0016-B-4 — Barone Michele`.
|
|
|
|
### Estratto 0016-B-4: i numeri 2024/25 correnti non coincidono col campione legacy operativo
|
|
|
|
- Problema: il campione operativo fornito dall utente per `GESTIONE ORDINARIA - Es.2024/25 - (Sc. B / Int. 4)` usa importi/ricevute come `52 -> 177,00`, `196 -> 177,00`, `268 -> 177,00`, pagamenti valorizzati (`16 gen 25`, `23 dic 25`) e conguaglio finale `-3,51`. L estratto dominio corrente non riflette questi valori.
|
|
- Evidenza tecnica: per `rate_emesse` dominio su `unita_immobiliare_id=658` nel periodo `2024-10-01 -> 2025-09-30` risultano ancora righe spezzate come `55 -> 5,00`, `56 -> 157,00`, `199 -> 5,00`, `200 -> 157,00`, `629 -> 5,00`, `630 -> 157,00`, con `importo_pagato = 0,00` sul soggetto storico `7680`. La staging autoritativa `rate_emissioni_dettaglio`, se interrogata sul ramo corretto `cod_cond=47`, `raggruppamento=99`, `anno_emissione=0913`, coincide invece col campione operativo lato righe emesse: `52`, `196`, `268`, `626`, `697`, `766` a `177,00` e `697 -> Conguaglio es.precedente -0,61`.
|
|
- Stato: [P] controllato e ristretto: il mismatch residuo e sul dominio `rate_emesse` e sulle viste che leggono ancora quel ramo, mentre la scheda unità legacy di `0016-B-4` ora usa il dataset staging autoritativo corretto.
|
|
|
|
### Incassi 0016-B-4: bonifico legacy `1.285,70` non ancora importato nel ramo applicativo
|
|
|
|
- Problema: il bonifico legacy descritto dall operatività (`protocollo=1663`, `num_incasso=350`, `data_pag=14/01/25`, `id_condomino=47`, `sc_int=B/4`, `nome_condomino=Barone Michele`, `importo=1.285,70`) deve diventare il punto di aggancio per la riconciliazione con il movimento banca Fucino del `16/01/2025`, ma oggi non e ancora disponibile nella UI applicativa.
|
|
- Evidenza tecnica: nella staging attuale non esiste ancora la tabella `gescon_import.in_da_ec`, quindi il protocollo legacy non e interrogabile in app; inoltre nella tabella applicativa `incassi` (`condominio_id=17`) non risultano ancora righe con `importo_pagato_euro/importo_pagato = 1285,70`.
|
|
- Stato: [P] controllato in sessione. Il ramo `incassi` visibile oggi per `0016-B-4` e parziale (`56` righe sull estratto legacy unità) ma non contiene ancora il pagamento cardine `1.285,70`; il prossimo passo tecnico obbligato e importare/materializzare `in_da_ec` o un suo equivalente staging prima della riconciliazione banca.
|
|
|
|
### HUB incassi 0016: staging `in_da_ec`, snapshot read-only e API interna per mini AI
|
|
|
|
- Problema: l HUB `admin-filament/contabilita/incassi` mostrava solo il ramo dominio `incassi`, quindi non c era un punto unico per vedere i movimenti legacy da estratto conto e passare un payload in sola lettura alla macchina interna `.202` / mini AI.
|
|
- Causa tecnica: mancavano sia la tabella di staging `gescon_import.in_da_ec` sia una materializzazione read-only nel dominio; inoltre la page Filament non esponeva ancora un payload aggregato o un endpoint autenticato dedicato.
|
|
- Fix applicato: `LoadGesconMdbToStaging` ora supporta `in_da_ec` con alias MDB (`Inc_da_ec`) e crea la tabella di staging se assente; `ImportGesconFullPipeline` precarica `in_da_ec` da `generale_stabile.mdb` e materializza le righe in `incassi_estratto_conto` con hash idempotente, `gestione_id`, `pattern_scala/interno` e `metadati_gescon`. `IncassiArchivio` espone una nuova sezione HUB read-only con payload JSON cumulativo e candidati `incassi` / `movimenti_bancari`, mentre `GET api/v1/incassi/hub` fornisce lo stesso snapshot via `auth:sanctum`.
|
|
- Stato: [U] validato localmente a livello runtime e sintassi. `php artisan route:list --path=api/v1/incassi/hub` registra la rotta; `IncassiHubReadService::forStabile(17, 2)` risponde correttamente con `source = gescon_import.in_da_ec` e `records_count = 0` finche lo staging non viene popolato dal MDB reale.
|
|
|
|
### Mini AI `.202`: chiamata read-only su incassi reali da `singolo_anno.mdb`
|
|
|
|
- Problema: per iniziare a lavorare su dati reali serve chiamare la macchina `.202` senza ancora automatizzare la riconciliazione, usando come primo dataset gli incassi gia importati da `singolo_anno.mdb.incassi` e i movimenti Fucino in `contabilita_movimenti_banca`.
|
|
- Causa tecnica: il primo payload HUB ripiegava solo su `in_da_ec`, oggi non popolata; inoltre il matching candidati guardava la vecchia tabella `movimenti_bancari` invece della tabella operativa usata dall import Fucino. Il primo click sul pulsante poteva inoltre fallire con `QueryException` per payload troppo grande salvato in `ai_requests.request_text` (`TEXT`, circa 64 KB).
|
|
- Fix applicato: aggiunto `MiniAiReconciliationClient`, comando `php artisan netgescon:mini-ai-incassi`, configurazione `services.mini_ai` e pulsante `Invia a mini AI` nell HUB incassi. `IncassiHubReadService` ora usa come fallback `netgescon.incassi` e cerca candidati in `contabilita_movimenti_banca`; ogni chiamata salva richiesta e risposta in `ai_requests` con contesto `incassi-hub-mini-ai`. La migration `2026_06_07_130000_expand_ai_requests_text_columns.php` porta `request_text` e `response_text` a `LONGTEXT`.
|
|
- Stato: [U] validato localmente con dry-run su `0016`: payload `task=reconcile_incassi_movimenti_bancari`, `source=netgescon.incassi`, `records_count=2`, incasso reale `inc:11172` e candidati movimento da `contabilita_movimenti_banca`. Il percorso backend del pulsante salva ora una richiesta da `290163` caratteri in `ai_requests` senza QueryException. Collaudo reale verso `.202` riuscito con `ai_request_id=2`, `status=answered`, risposta JSON valida e due suggerimenti `review` salvati.
|
|
|
|
### Mini AI `.202`: riconoscimento alias `presso/email` e caso Caschetto B-18
|
|
|
|
- Problema: il bonifico di `1.968,23` del `30/04/2026` arriva in banca come `CURATOLA ANTONIO`, senza scala/interno nella causale principale e senza nominativo `Caschetto Lucia`; il legame reale e solo nel legacy (`presso = c/o Avv. Curatola`, email `curatola.antonio@...`) della unità `0016-B-18`.
|
|
- Causa tecnica: il resolver del payload mini AI cercava solo nominativo diretto o scala/interno; non normalizzava alias distribuiti su `presso` ed email, quindi non riusciva ad attribuire il movimento a `Caschetto Lucia`.
|
|
- Fix applicato: `IncassiHubReadService` ora estrae il nominativo banca da `A VOSTRO FAVORE ... Data Regolamento` e risolve il legacy cercando token normalizzati su `nom_cond`, `proprietario_denominazione`, `presso`, `e_mail_condomino`, senza cambiare il nominativo principale dell'unità. Aggiunto anche `gescon:qa-rubrica-vuoti` e pulsante `Aggiorna vuoti da legacy` nella scheda rubrica, che compila solo dati mancanti se il match legacy e sicuro.
|
|
- Stato: [U] validato su movimento banca `15803`: dry-run produce `legacy_key=mov:15803`, `nominativo=Caschetto Lucia`, `scala=B`, `interno=18`, `candidate_rates=12`, somma `1.968,23`. Collaudo `.202` riuscito con `ai_request_id=5`, `confidence=0.98`, `allocations[]` valorizzato con le 12 rate candidate.
|
|
|
|
### QA smoke unità: perimetro esplicito obbligatorio
|
|
|
|
- Problema: `scripts/smoke_unita.php` poteva scegliere automaticamente il primo stabile disponibile su filesystem o staging, producendo verifiche riuscite sul perimetro sbagliato in ambienti multi-stabile/multi-admin.
|
|
- Causa tecnica: in assenza di argomenti lo script faceva auto-discovery del `legacy_code` dal primo archivio trovato o dal primo `cod_stabile` presente in staging.
|
|
- Fix applicato: lo script ora richiede esplicitamente `legacy_code` e fallisce con usage chiaro se non viene passato; la verifica continua a funzionare se il codice stabile e l anno sono espliciti.
|
|
- Stato: [U] validato localmente: senza argomenti restituisce usage; con `php scripts/smoke_unita.php 0016 2021 1` esegue lo smoke sul solo stabile `0016`.
|
|
|
|
### Unita immobiliare / estratto soggetto 0026: conguaglio iniziale duplicato rispetto a rate emesse
|
|
|
|
- Problema: nella scheda unità e nell estratto soggetto di `D'EVOLI Luisa` (`unita_id=1012`, tenant pulito `stabile_id=32`) il conguaglio `126,06` compariva due volte: una come `Bilancio iniziale / esercizi precedenti` da `CONG.O` e una come `rate_emesse` (`Conguaglio es.precedente2025`), portando il totale a `700,12` invece di `574,06`.
|
|
- Causa tecnica: le pagine sommano i `CONG.*` di `dettaglio_importi_tabella` senza escludere i casi gia materializzati in `rate_emesse` per la stessa unità, ruolo legacy e `anno_emissione`.
|
|
- Fix applicato: in `app/Filament/Pages/UnitaImmobiliarePage.php` e `app/Filament/Pages/Contabilita/EstrattoContoSoggetto.php` i conguagli iniziali vengono soppressi quando esiste gia una `rata emessa` di conguaglio con stessa unità, ruolo `C/I`, `anno_emissione` legacy e importo.
|
|
- Stato: [U] validato via hydration diretta pagina/estratto; `unita_id=1012` torna a `574,06`, il gruppo `Bilancio iniziale` sparisce e restano solo le tre rate emesse `224,00 + 224,00 + 126,06`.
|
|
|
|
### Unita immobiliare 0026-A-2A: inquilino mischiato ai proprietari e ruolo rate errato
|
|
|
|
- Problema: nella scheda unità dei fratelli Zazzara (`unita_id=1023`) `Pagliarini Andrea` finiva nella stessa colonna dei proprietari e veniva letto come ruolo rate `C`, anche se nel dominio e nell import legacy e l inquilino della unità.
|
|
- Causa tecnica: la pagina nuova considerava qualunque record in `proprieta` come proprietario, includendo anche `tipo_diritto = locazione`; inoltre la sezione `Persone collegate` dipendeva quasi solo da `rubrica_ruoli`, che in questo caso non copriva l inquilino pur avendo il dato corretto in `persone_unita_relazioni`.
|
|
- Fix applicato: `UnitaImmobiliarePage` ora limita il bucket proprietari ai soli diritti reali (`proprieta`, `comproprieta`, `usufrutto`, ecc.), esclude `locazione` dall owner lookup delle rate e usa `persone_unita_relazioni` come fallback per popolare `inquilini` mantenendo `ruolo_rate` persistito (`I`).
|
|
- Stato: [U] validato via hydration diretta pagina; `Fratelli Zazzara` resta unico proprietario/condomino con saldo `-1780,92`, `Pagliarini Andrea` compare in `inquilini` con `ruolo_rate = I` e le rate risultano separate (`507,75` lato inquilino).
|
|
|
|
### Supporto > Modifiche in memory exhaustion su log grandi
|
|
|
|
- Problema: la pagina `admin-filament/supporto/aggiornamento-nodo` poteva andare in `Allowed memory size exhausted` durante `loadRuntimeErrors()` quando `storage/logs/laravel.log` diventava molto grande. Sul nodo staging il caso reale era un `laravel.log` da circa `278 MB`.
|
|
- Causa tecnica: `appendFromNdjson()` e `appendFromLaravelLog()` usavano `file(...)`, quindi caricavano l intero file in RAM anche se poi la UI mostrava solo gli ultimi eventi utili.
|
|
- Fix applicato: in `app/Filament/Pages/Supporto/Modifiche.php` i lettori sono stati sostituiti con una lettura tail limitata per linee e byte (`readTailLines()`), mantenendo il comportamento della UI ma senza allocare l intero log.
|
|
- Stato: [U] riprodotto e corretto sul nodo locale `/var/www/netgescon`; validazione eseguita via reflection su `loadRuntimeErrors()` con `laravel.log` grande, picco memoria rimasto intorno a `89 MB` e `39` righe BUG caricate correttamente.
|
|
- Prevenzione: non usare aumento del `memory_limit` come rimedio principale; mantenere logrotate attivo e preferire sempre parsing incrementale o tail bounded per i file operativi letti dalla UI.
|
|
|
|
### Supporto > Modifiche con `ProgramAclService` assente su nodo staging
|
|
|
|
- Problema: la pagina `admin-filament/supporto/aggiornamento-nodo` poteva andare in `BindingResolutionException` con `Target class [App\Services\ProgramAclService] does not exist` durante `canAccess()`.
|
|
- Causa tecnica: sul nodo staging il checkout deployato non conteneva `app/Services/ProgramAclService.php`; la pagina supporto dipendeva in modo rigido da quel service anche per un semplice controllo accessi.
|
|
- Fix applicato: `Modifiche::canAccess()` usa `ProgramAclService` solo se la classe esiste e si risolve correttamente; se manca, fa fallback ai ruoli amministrativi (`super-admin`, `admin`, `amministratore`) e non blocca la pagina tecnica.
|
|
- Stato: [U] validato su `/var/www/netgescon` con service realmente assente; `App\Filament\Pages\Supporto\Modifiche::canAccess()` non genera piu eccezioni e ritorna correttamente `true` per un utente amministrativo.
|
|
- Prevenzione: nelle pagine di supporto e deploy evitare dipendenze rigide da moduli opzionali o non ancora allineati sul nodo; il pannello di recupero deve sempre avere un percorso di fallback minimale.
|
|
|
|
### Refresh nodo bloccato da permessi deploy su `resources/views/errors`
|
|
|
|
- Problema: il launcher aggiornamento nodo restava a `behind 1`, la `503` compariva solo per un attimo e la UI del launcher restava visibile con polling e pulsanti, costringendo a refresh manuali.
|
|
- Causa tecnica: `netgescon:git-sync` falliva nel passaggio `rsync` verso `/var/www/netgescon` con `Permission denied` su `resources/views/errors/.503.blade.php`; il repository sorgente arrivava al commit remoto ma il checkout applicativo non riceveva i file nuovi.
|
|
- Fix applicato: permessi riallineati su `/var/www/netgescon/resources/views/errors` e `503.blade.php` al gruppo `www-data`; il launcher ora forza anche una navigazione piena alla stessa URL quando parte il refresh con maintenance, cosi il browser mostra la `503` completa invece di restare nella UI Livewire.
|
|
- Stato: [U] validato su staging locale; `git-sync-last.json` torna `completed`, commit deploy e remoto risultano allineati (`cadb9a5` nel caso reale) e il nodo torna a `ahead 0 / behind 0`.
|
|
- Prevenzione: le directory che devono ricevere file nuovi via deploy web devono restare group-writable per il gruppo del processo PHP/web (`www-data` qui); quando una directory viene creata manualmente sul nodo, impostare subito gruppo coerente e bit setgid.
|
|
|
|
### Ripristino bootstrap pannello admin
|
|
|
|
- Problema: `AdminFilamentPanelProvider.php` era stato corrotto da una modifica incompleta e impediva il bootstrap corretto.
|
|
- Fix applicato: ripristino struttura PHP e riallineamento del provider.
|
|
- Stato: [U] risolto localmente, bootstrap Laravel nuovamente valido.
|
|
|
|
### Token CTI Panasonic e lettura configurazione piu robusta
|
|
|
|
- Problema: il flusso staging poteva fallire per risoluzione non coerente del token CTI.
|
|
- Fix applicato: `PanasonicCstaController` riallineato a `config/cti.php` con risoluzione piu robusta.
|
|
- Stato: [P] implementato e verificato in locale; su staging resta da completare la validazione end-to-end del canale reale.
|
|
|
|
### Mismatch stabile/anno in Ordinarie
|
|
|
|
- Problema: la pagina `gescon/ordinarie` poteva mostrare dati non coerenti con stabile e anno scelti nella topbar.
|
|
- Fix applicato: default anno dal contesto condiviso e centralizzazione risoluzione codice legacy stabile.
|
|
- Stato: [P] implementato e validato a livello codice; da verificare sul caso reale staging con dati utente specifici.
|
|
|
|
### Filtri acqua e servizi non coerenti con la gestione attiva
|
|
|
|
- Problema: in `condomini/servizi-utenze` e archivio letture la selezione anno/stabile non era sempre rispettata in tutte le query.
|
|
- Fix applicato: applicazione del filtro anno attivo e del contesto stabile ai blocchi acqua principali.
|
|
- Stato: [P] implementato e testato sintatticamente; serve verifica funzionale con dati annuali reali su staging.
|
|
|
|
### Tracciato tecnico SMDR e CSTA mescolato
|
|
|
|
- Problema: una sola vista tecnica rendeva meno chiaro distinguere fallback SMDR da eventi CTI/CSTA ricchi.
|
|
- Fix applicato: nuovi tab distinti in `strumenti/post-it-gestione` e vista click-to-call dedicata.
|
|
- Stato: [U] implementato; da usare come base per test operativi PBX e future integrazioni provider-agnostic.
|
|
|
|
## Validazioni eseguite nell ultimo ciclo
|
|
|
|
- `php artisan list` eseguito con esito positivo dopo gli ultimi fix applicativi
|
|
- controlli sintattici PHP sulle classi modificate senza errori
|
|
- diagnostica editor senza errori sui file toccati
|
|
- `Supporto > Modifiche`: validato il nuovo parsing tail-bounded dei log su nodo con `laravel.log` da `278 MB`, senza esaurimento memoria
|
|
|
|
## Validazioni ancora aperte
|
|
|
|
- verificare su staging la nuova tab `CTI / CSTA e Click-to-Call`
|
|
- verificare il caso reale di mismatch stabile/anno con dati staging
|
|
- usare il filtro annuale acqua per l estrazione effettiva delle fatture e confermare il perimetro dati
|
|
|
|
## Regola di aggiornamento
|
|
|
|
Ogni bug corretto va aggiornato qui in quattro righe:
|
|
|
|
1. problema osservato
|
|
2. fix applicato
|
|
3. stato verifica locale
|
|
4. stato verifica staging o nodi remoti
|