michele/netgescon-day0
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
cadb9a5fcc
netgescon-day0/docs/support/ASSISTENZA-TECNOREPAIR-MDB.md

5.8 KiB
Raw Blame History

Assistenza TecnoRepair MDB

Stato iniziale

  • Il file MDB nel workspace e leggibile da Linux con mdb-tools.
  • Archivio verificato: Miki-Bug-workspace/screenshot/Assistenza gestionale/Archivi/TecnoRepairDB.mdb.
  • Obiettivo Day0: usare l'MDB come sorgente legacy leggibile e portare gestione clienti, fornitori e schede riparazione dentro NetGescon senza scrivere direttamente nel file Access.

Tabelle lette dal file reale

Anagrafiche principali

  • TClienti Campi chiave: ID, NomeCognome, NumeroTelefono, TelFisso, Email, CodFis, PIVA, Indirizzo, Citta, Cap, Prov, Annotazioni.
  • TFornitori Campi chiave: ID, RagioneSociale, PIVA, Annotazioni.
  • TCommittenti Campi chiave: ID, Codice, Committente, Telefono, Email, PIVA, Utente, Pwd.
  • TCentriAss Campi chiave: ID, RagioneSociale, Telefono, Email, PIVA, indirizzo completo.

Schede assistenza e allegati

  • TApparecchi Campi chiave: ID, NumeroScheda, DataIngresso, ID_Cliente, ID_CentroAss, Cod_Committente, Modello, SerialNumber, SerialNumber2, CodiceProdotto, DifettoSegnalato, DescrizioneRiparazione, StatoRiparazione, ID_StatoRip, NomeOperatore, NomeTecnicoRiparatore, DataOrdine, NumOrdine, CodiceRMA, CodicePIN, CodiceSblocco, Comunicazioni, FileAllegato1.
  • TAllegati Campi chiave: ID, ID_Scheda, NumAllegato, FileAllegato.

Tabelle di supporto gia viste

  • TTelefono
  • TMarche
  • TTipiApparecchi
  • TTipoIntervento
  • TTipoGuasto
  • TStatoRip
  • TLavorazioni
  • TRicambi*

Mappa proposta verso NetGescon

Primo livello, non distruttivo

  • TClienti -> rubrica tecnica / contatti assistenza
  • TFornitori, TCentriAss, TCommittenti -> fornitori e partner assistenza
  • TApparecchi -> archivio schede manutenzione/riparazione legacy da collegare a fornitore, cliente e ticket
  • TAllegati -> allegati scheda legacy

Regola tecnica consigliata

  • leggere dall'MDB in sola lettura
  • normalizzare dentro tabelle/appositi modelli NetGescon
  • non scrivere direttamente nel file .mdb da Linux come archivio operativo principale

Motivo:

  • la lettura e gia affidabile
  • la scrittura diretta su Access/MDB fuori da Windows/Access resta fragile
  • NetGescon deve diventare il layer operativo e storico principale

Collegamenti operativi gia individuati

  • TApparecchi.ID_Cliente -> TClienti.ID
  • TApparecchi.ID_CentroAss -> TCentriAss.ID
  • TApparecchi.Cod_Committente -> TCommittenti.ID o Codice da verificare in import
  • TAllegati.ID_Scheda -> TApparecchi.ID

Prossimo step pragmatico

  1. creare staging NetGescon per clienti_assistenza_legacy, fornitori_assistenza_legacy, schede_assistenza_legacy, schede_assistenza_allegati_legacy
  2. importare il file TecnoRepair in sola lettura
  3. collegare TClienti e TFornitori alla rubrica/fornitori NetGescon con matching su telefono, email, CF/PIVA
  4. esporre in UI la scheda riparazione collegata a cliente, fornitore e ticket/intervento

Primo slice disponibile in Day0

  • Tabelle staging create:
    • assistenza_tecnorepair_schede_legacy
    • assistenza_tecnorepair_allegati_legacy
    • product_serials
  • Nuovo flag fornitore: fornitori.is_tecnorepair_primary
  • Nuovo comando import:
    • php artisan tecnorepair:import-legacy {amministratore} --force-primary
    • opzionale: --fornitore-id= oppure --fornitore-term=NETHOME
  • Nuova pagina Filament:
    • Supporto > Assistenza Legacy
    • elenco filtrabile con colori per stato, dettaglio scheda, seriali e allegati legacy

Note operative del comando

  • default MDB:
    • /home/michele/netgescon/netgescon-day0/Miki-Bug-workspace/screenshot/Assistenza gestionale/Archivi/TecnoRepairDB.mdb
  • import collega di default le schede al primo fornitore dello stesso amministratore che matcha NETHOME
  • con --force-primary il fornitore collegato viene marcato come centro TecnoRepair principale
  • l'import resta idempotente sul vincolo imported_from_path + legacy_id

Decisione corrente

  • Si: NetGescon puo leggere l'MDB subito.
  • Si: possiamo usare l'MDB come sorgente legacy di partenza.
  • No: non conviene usare la scrittura diretta verso MDB come modello operativo principale.

Scrittura DB TecnoRepair: risposta pragmatica

La risposta dipende dal tipo reale di archivio che vogliamo aggiornare.

Caso A: file Access .mdb

  • Lettura: si, gia fattibile e stabile con mdb-tools.
  • Scrittura operativa diretta: no, non e il canale consigliato.
  • Motivo: la scrittura su MDB da Linux resta troppo fragile per diventare il backoffice quotidiano di produzione.

Caso B: database SQL o staging NetGescon derivato da TecnoRepair

  • Si, questo e il modello consigliato.
  • NetGescon diventa il sistema di lavoro.
  • TecnoRepair legacy resta sorgente iniziale o archivio da sincronizzare con connettori dedicati.

Modello consigliato per rubrica e sincronizzazione cellulare

Per ottenere gestione coerente tra NetGescon, telefono e Google Contacts:

  1. rubrica unica NetGescon come sorgente operativa principale
  2. sincronizzazione verso Google Contacts per il mobile
  3. import/sync da TecnoRepair verso NetGescon sui contatti legacy
  4. eventuale export di ritorno verso sistemi esterni solo tramite bridge controllato, non con scrittura diretta nel file MDB

Questo approccio permette:

  • una sola maschera rubrica condivisa per tutti i ruoli
  • aggiornamenti coerenti anche da cellulare
  • audit e storicizzazione in NetGescon
  • minore rischio di corruzione archivio legacy

Decisione operativa aggiornata

  • rubrica condivisa: si
  • sincronizzazione con Google Contacts: si, come canale mobile consigliato
  • scrittura diretta nel file TecnoRepairDB.mdb: no, da evitare come processo ordinario
  • scrittura su tabelle NetGescon/staging SQL con bridge di sincronizzazione: si, e il percorso corretto