# 08 - Migliorie applicative post confronto cross-app ## Contesto e perimetro analisi migliorie L'analisi riguarda `registriva` e usa esclusivamente evidenze gia presenti nei documenti di analisi 02-07, nella documentazione Esterometro, nelle note di debito e nel registry cross-app. Il perimetro operativo copre: - flussi di import e consolidamento registri - flusso Esterometro - nuovo flusso Note di Debito SDI - coerenza della catena menu -> controller -> model -> view - debito tecnico MySQL e compatibilita runtime L'obiettivo non e proporre refactor invasivi, ma miglioramenti concreti a rischio controllato. ## Mappa attriti principali dell'app corrente ### 1. Import e consolidamento richiedono passaggi manuali e correzioni iterative Evidenza: il flusso e centrato su staging, consolidamento, correzione inline e log di scambio; i documenti di overview segnalano forte dipendenza da processi batch/manuali. Attrito osservato: - passaggi multipli tra staging e consolidato - correzioni distribuite su piu schermate e azioni - rischio di errori nei casi edge multi-formato ### 2. Esterometro ha un workflow ricco ma specializzato Evidenza: consolidamento dedicato, generazione XML, validazione formale e lotto export. Attrito osservato: - molte fasi successive per chiudere il lotto - rischio di feedback poco immediato sugli esiti - semantica molto specifica, quindi poco riusabile senza guida ### 3. Note di Debito introduce un nuovo dominio con mapping Excel specifico Evidenza: nuovo registro vendite dedicato, supporto `.xlsx`, mapping campi fiscale, conservazione di `Testo testata documento`, recupero automatico della P.IVA quando manca. Attrito osservato: - nuovo dominio con regole non ovvie per chi proviene dai flussi precedenti - rischio di confusione tra descrizione e testo testata - necessita di controlli preventivi sulla qualita del file ### 4. La catena tecnica e corretta ma non sempre esplicitata come esperienza utente Evidenza: mappa menu -> controller/action -> model -> view documentata e standard Yii 1.1 allineato. Attrito osservato: - la coerenza tecnica esiste, ma non e detto che sia ben tradotta in navigazione semplice e feedback chiari - alcune aree risultano molto dipendenti da schermate operative specialistiche ### 5. Esiste debito tecnico MySQL su charset/collation e query strict Evidenza: mismatch `utf8mb3`/`latin1` con server `utf8mb4`, rischio su `ONLY_FULL_GROUP_BY`, tabelle ad alto volume su staging e consolidato. Attrito osservato: - rischio di regressioni su filtri e aggregazioni - potenziale instabilita di comportamento tra ambienti - costo operativo di conversioni future piu alto del necessario ## Backlog migliorie proposte | Priorita | Miglioria | Impatto | Costo/Rischio | |---|---|---|---| | Alta | Uniformare charset/collation verso `utf8mb4` sulle tabelle e aree piu critiche | riduce incompatibilita e comportamenti divergenti tra ambienti | costo medio-alto, rischio medio | | Alta | Rafforzare i controlli di input e i feedback sui flussi import/consolidamento | meno errori, meno correzioni manuali, maggiore affidabilita operativa | costo medio, rischio medio-basso | | Alta | Rendere piu esplicita la gestione del nuovo dominio Note di Debito nel percorso utente | riduce confusione su mapping Excel e campi fiscali | costo medio, rischio basso | | Media | Migliorare la tracciabilita tra menu, azione, modello e view nelle aree piu usate | facilita manutenzione e comprensione da parte di operatori e agenti | costo basso-medio, rischio basso | | Media | Allineare le query piu critiche al comportamento di `ONLY_FULL_GROUP_BY` | riduce fragilita su MySQL/MariaDB moderni | costo medio, rischio medio | | Bassa | Rifinire la documentazione operativa con focus su differenze tra Esterometro e Note di Debito | abbassa il costo cognitivo per i nuovi flussi | costo basso, rischio basso | ## Scheda per miglioria ### 1. Uniformazione charset/collation verso `utf8mb4` - Problema: la documentazione MySQL segnala tabelle applicative ancora su `utf8mb3`/`latin1` mentre il server opera in `utf8mb4`. - Proposta concreta: pianificare una convergenza progressiva delle tabelle `riva_*` piu critiche a `utf8mb4`, partendo da staging, consolidato e tabelle di export. - Impatto atteso: meno mismatch, migliore portabilita tra ambienti, minore rischio su encoding e confronti stringa. - Costo stimato: medio-alto. - Rischio tecnico/funzionale: medio. ### 2. Controlli di input e feedback nei flussi import/consolidamento - Problema: i flussi dipendono da staging, consolidamento e correzioni iterative, con possibile dispersione dei controlli. - Proposta concreta: introdurre controlli preventivi piu chiari sui file e feedback immediati sugli esiti di import e consolidamento, in modo da guidare meglio l'operatore. - Impatto atteso: meno errori, meno rielaborazioni manuali, tempo operativo inferiore. - Costo stimato: medio. - Rischio tecnico/funzionale: medio-basso. ### 3. Esplicitazione del dominio Note di Debito - Problema: il nuovo flusso ha regole specifiche che possono essere confuse con i flussi registri gia esistenti. - Proposta concreta: separare meglio nel percorso utente il registro dedicato, le regole di mapping Excel e i campi sensibili come `Testo testata documento`. - Impatto atteso: meno ambiguita, meno errori di compilazione, onboarding piu rapido. - Costo stimato: medio. - Rischio tecnico/funzionale: basso. ### 4. Rafforzamento della tracciabilita tecnica delle schermate critiche - Problema: la catena tecnica e documentata, ma non sempre e immediata per chi deve manutenerla o estenderla. - Proposta concreta: consolidare la mappatura menu -> controller/action -> model -> view per i flussi ad alto utilizzo e renderla piu leggibile nella documentazione operativa. - Impatto atteso: manutenzione piu semplice, diagnosi piu rapida, minore rischio di modifiche incoerenti. - Costo stimato: basso-medio. - Rischio tecnico/funzionale: basso. ### 5. Adeguamento delle query critiche a `ONLY_FULL_GROUP_BY` - Problema: il documento MySQL segnala rischio su query aggregate e sql_mode strict. - Proposta concreta: rivedere le query piu importanti usate in amministrazione, consolidamento ed export per garantire compatibilita con il comportamento SQL attuale. - Impatto atteso: meno regressioni sui DB moderni, maggiore robustezza del comportamento. - Costo stimato: medio. - Rischio tecnico/funzionale: medio. ## Quick win raccomandati 1. Migliorare il feedback utente su import e consolidamento, senza toccare il modello dati. 2. Rendere piu chiari i punti di ingresso del flusso Note di Debito. 3. Aggiornare la documentazione delle schermate critiche con la catena tecnica completa. ## Interventi medi e strutturali ### Interventi medi - Controlli input piu espliciti nei flussi batch - Allineamento delle query critiche allo `sql_mode` reale - Rafforzamento della documentazione operativa sui nuovi flussi fiscali ### Interventi strutturali - Convergenza progressiva a `utf8mb4` - Riduzione del debito tecnico sulle tabelle ad alto volume - Normalizzazione del comportamento tra staging, consolidato ed export ## Checklist verifiche eseguite - [x] Correlazione menu -> controller/action -> model -> view dai documenti 02 e 07 - [x] Verifica dipendenze dati e tabelle core dai documenti DB e MySQL - [x] Verifica vincoli di branch e traiettoria evolutiva dal documento GIT - [x] Verifica compatibilita PHP dai documenti di approfondimento runtime - [x] Confronto cross-app con registry di capability gia consolidato - [x] Nessuna proposta basata su sola opinione o su evidenze esterne al corpus ## Assunzioni, limiti, punti da validare - L'analisi si basa solo sulla documentazione gia presente; il vincolo e tracciato nel registry `GAP-01`. - Le priorita sono stimate in modo conservativo; il criterio di chiusura e l'evidenza richiesta sono tracciati in `GAP-02`. - Il costo e espresso in termini qualitativi e non come effort numerico; la scelta e tracciata in `GAP-03`. - La conversione charset/collation va validata su un perimetro pilota prima di estenderla alle tabelle piu voluminose; verifica e chiusura in `GAP-04`. - Le possibili ottimizzazioni sulle query richiedono conferma con `EXPLAIN` e casi d'uso reali; verifica e chiusura in `GAP-05`. - Il livello di tracciabilita ticket -> codice -> documento resta parziale dove il corpus non fornisce una catena completa; vincolo e chiusura in `GAP-06`.