6.3 KiB
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.