82 lines
6.3 KiB
Markdown
82 lines
6.3 KiB
Markdown
Ho analizzato struttura attuale: coesistono tre dimensioni gestione sovrapposte (gestioni, gestioni_contabili, anni_gestione) e codice/import usa già gestioni_contabili per pipeline multi‑year mentre UI/admin e contabilita_registrazioni usano ancora gestioni (id_gestione). Serve unificare prima di proseguire con mapping partita doppia e import massivi.
|
||
|
||
Problema attuale (sintesi)
|
||
Doppione concettuale: gestioni (per stabile, con id_gestione) vs gestioni_contabili (per tenant, multi‑tipo O/R/S, protocollo).
|
||
Alcune tabelle (conti_bancari, incassi, movimenti_bancari, ritenute, incassi_estratto, staging) già puntano a gestioni_contabili.
|
||
Altre (contabilita_registrazioni + movimenti storici + bilanci + saldi piano_conti) puntano a gestioni (id_gestione).
|
||
Terzo asse: anni_gestione presente in import staging (anno_gestione_id) creando ulteriore ridondanza.
|
||
Manca stabile_id in gestioni_contabili, ma requisito funzionale vuole legame diretto Gestione ↔ Stabile per isolamento logico e ripartizioni millesimali.
|
||
Obiettivo unificazione
|
||
Canonizzare UNA sola tabella: estendere gestioni_contabili aggiungendo stabile_id e sostituendo gradualmente gestioni + anni_gestione. Rinominare il modello GestioneContabile → Gestione (facendo soft alias di transizione) oppure introdurre service layer GestioneResolver fino a refactor completo.
|
||
|
||
Piano operativo (fasi atomiche)
|
||
Estensione schema
|
||
Migration alter gestioni_contabili: add stabile_id (FK stabili), add indici, unique (tenant_id, stabile_id, anno_gestione, tipo_gestione, numero_straordinaria).
|
||
Colonne di gestioni mancanti da valutare: percentuale_fondo_riserva, flags millesimi, note (se servono portarli ora o demandare).
|
||
Mappatura dati esistenti
|
||
Costruire tabella temporanea mapping gestioni.id_gestione → gestioni_contabili.id (nuovo) per aggiornare FK.
|
||
Popolare gestioni_contabili da gestioni mancanti (solo se non già create) generando protocollo_prefix coerente (OYYYY / RYYYY / SYYYY-n).
|
||
Aggiornamento FK
|
||
Migrare campi gestione_id nelle tabelle che puntano a gestioni (id_gestione) sostituendoli con riferimenti a gestioni_contabili.id usando mapping.
|
||
Per contabilita_registrazioni & balances: rename colonna gestione_id → gestione_contabile_id (temporaneo), poi aggiungere nuova gestione_id FK verso gestioni_contabili, copiare valori e infine rinominare al nome definitivo gestione_id (pulizia).
|
||
Deprecazione tabelle legacy
|
||
Marcate come read-only gestioni e anni_gestione; dopo validazione creare view compatibilità: CREATE VIEW gestioni AS SELECT id as id_gestione, stabile_id, anno_gestione, tipo_gestione as stato, ... FROM gestioni_contabili (solo se necessario a UI finché non refactor).
|
||
Refactor applicativo
|
||
Aggiornare model GestioneContabile (aggiunta relazione stabile) e creare trait/alias Gestione per retrocompatibilità.
|
||
Aggiornare controller / form che usano Gestione (UI) per leggere nuova tabella (o view).
|
||
Pulizia codice import
|
||
MultiYearGesconImportService e ImportGesconMdbCommand: includere stabile_id nella create/update (resolvendo da tenant_id + maybe parametro).
|
||
Rimuovere uso anni_gestione nelle nuove staging se non aggiunge semantica; sostituire anno_gestione_id con gestione_id.
|
||
Consolidamento piano conti saldi
|
||
piani_conti_saldi puntare a gestioni_contabili.id (se ora usa id_gestione).
|
||
Test & validazione
|
||
Query coerenza: per ogni stabile e anno garantire set {ordinaria, riscaldamento} + eventuali straordinarie enumerabili; no duplicati unique.
|
||
Bilanci/registrazioni: totale entrate-uscite invariato previo e post migrazione per un campione.
|
||
Script/Migrations da generare (bozza)
|
||
A. 2025_xx_xx_xxxxxx_alter_gestioni_contabili_add_stabile_id.php
|
||
|
||
add stabile_id FK nullable
|
||
add columns (usa_millesimi_generali, etc.) se decidiamo subito
|
||
update stable_id via join su gestioni legacy (mapping temporaneo dove anno/tipo combaciano)
|
||
make stable_id not nullable dopo popolamento
|
||
add composite unique
|
||
B. 2025_xx_xx_xxxxxx_backfill_gestioni_contabili_from_gestioni.php
|
||
|
||
Inserisce record mancanti.
|
||
C. 2025_xx_xx_xxxxxx_migrate_fk_to_gestioni_contabili.php
|
||
|
||
Per ogni tabella legacy con gestione_id → map & enforce FK nuova.
|
||
D. (Opzionale) 2025_xx_xx_xxxxxx_create_view_gestioni_legacy.php
|
||
|
||
Assunzioni (ragionevoli)
|
||
tenant_id corrisponde all’amministratore proprietario degli stabili elencati (1 tenant → N stabili).
|
||
Ogni record gestioni legacy ha tipo_gestione compatibile con enum target (eventuale mapping: 'attiva' stato vs tipo_gestione diverso; qui usiamo tipo_gestione da colonna se esiste o default 'ordinaria').
|
||
Edge cases da gestire
|
||
Gestione straordinaria multiple stesso anno (numero_straordinaria null → assegnare progressivo).
|
||
Gestione legacy priva di data_fine (impostare 31/12 anno_gestione).
|
||
Duplicati già presenti in gestioni_contabili che collide con inserimento (usare updateOrCreate e loggare).
|
||
Record figli con gestione_id orfano (abortare migr FK se non mappabile → report).
|
||
Proposta immediata (micro‑step sicuro)
|
||
Creare migration A (aggiunta stabile_id + campi minimi) senza ancora spostare tutto.
|
||
Aggiornare Model GestioneContabile per relazione stabile e fillable.
|
||
(Facoltativo subito) Service di lookup GestioneResolver centralizzando getBy(stabile, anno, tipo, n_stra).
|
||
Posso procedere generando migration A + aggiornamento model + stub GestioneResolver.
|
||
|
||
Confermi che:
|
||
|
||
Canonizziamo gestioni_contabili.
|
||
Aggiungiamo stabile_id (obbligatorio).
|
||
Manteniamo (per ora) tenant_id (serve per multi-tenant cross-stabili).
|
||
Portiamo subito i tre boolean millesimi + note (così evitiamo seconda alter) ?
|
||
Rispondi “ok procedi” (o specifica modifiche) e applico direttamente le patch. Se vuoi vedere prima il diff logico posso fornirlo.
|
||
|
||
Requisiti coperti (stato)
|
||
Unificazione dimensione gestione: piano definito (Pending implementazione).
|
||
Multi‑tipo O/R/S + N_STRA: già in gestioni_contabili, esteso con stabile (Planned).
|
||
Evitare proliferazione: stesura percorso deprecazione (Planned).
|
||
Piano conti/paContinrtita doppia: dipende dalla unificazione (Next dopo migrazione).
|
||
Pipeline MDB → staging → mapping: in attesa consolidamento gestione (Blocked until unificazione).
|
||
Registri (RA, banca, ecc.): già puntano alla nuova gestione, beneficiano unificazione (Implicit).
|
||
Millesimi e voci spesa: allineamento dopo stabile_id in gestione (Next).
|
||
Riconciliazione automatica: nessun impatto negativo, semplifica filtro per stabile (Future refinement).
|
||
Fammi sapere se procedo direttamente con le modifiche. |