# 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