Vai al contenuto

Integrazione Dorotech in SafeOps - Analisi e Fase 1

1. Mappa di cio che esiste gia e va riusato

Accesso utenti e permessi

  • SafeOps usa gia Flask-AppBuilder con ruoli FAB e profili tenant.
  • Il perimetro permessi e gia gestito in app/__init__.py e nei moduli IAM/multitenancy.
  • Per Dorotech conviene riusare i profili esistenti e mappare i ruoli funzionali su:
  • ROLE_PROFILE_COMMERCIALE
  • ROLE_PROFILE_GESTIONE
  • ROLE_PROFILE_TECNICO
  • eventuale tenant_admin / supervisione

Clienti e referenti

  • Cliente esiste gia in anagrafiche/models.py.
  • Cliente contiene gia:
  • nome
  • indirizzo
  • CAP
  • comune/provincia/stato
  • email
  • PEC
  • SDI
  • telefono
  • partita IVA / codice fiscale
  • note
  • tipologie cliente
  • ClienteMeta esiste gia per campi extra non strutturali.
  • I referenti cliente esistono gia come funzionalita UI in ClienteView.assign_referenti, referenti_modal, referenti_overview.
  • Esistono anche policy documentali per tipologia cliente:
  • TenantTipologiaDocumentoPolicy

Commerciale

  • CommercialeTrattativa esiste gia in commerciale/models.py.
  • contiene cliente, amministratore, stato, valore, scadenza, preventivo/contratto
  • CommercialeOfferta esiste gia in commerciale/models.py.
  • contiene collegamento a trattativa e servizio
  • documento offerta
  • firmato commerciale
  • note e stato
  • CommercialeRichiestaServizio esiste gia in commerciale/models.py.
  • e gia il contenitore piu vicino al concetto di pratica operativa / ordine / richiesta documenti
  • CommercialeRichiestaMilestone esiste gia in commerciale/models.py.
  • e gia utilizzabile come struttura minima per scadenze / step documentali

Documentale e checklist

  • Documento, Categoria, Allegato esistono gia.
  • Documento ha gia data_scadenza.
  • Categoria ha gia scadenza_predefinita.
  • ClienteDocsChecklistView esiste gia e copre:
  • checklist documenti per cliente
  • upload
  • replace
  • policy required/optional/recommended
  • vista demo dinamica

Dorotech

  • Esiste gia un nucleo Dorotech dedicato:
  • CommercialeDorotechSigla
  • CommercialeDorotechPratica
  • CommercialeDorotechBene
  • CommercialeDorotechChecklistItem
  • CommercialeDorotechEvento
  • Esiste gia una API/view Dorotech:
  • CommercialeDorotechApiView in commerciale/views.py
  • Esiste gia un workspace UI:
  • commerciale_dorotech_demo.html
  • Esistono gia helper per:
  • protocollo offerta Dorotech
  • numero ordine Dorotech
  • generazione documenti offerta/ordine/richiesta documenti/report finale
  • workflow di transizione

2. Gap funzionali reali rispetto al processo Dorotech

Gia coperto parzialmente

  • autenticazione utente personale
  • anagrafica cliente
  • checklist documenti
  • documentale
  • offerta/pratica Dorotech
  • ordine Dorotech
  • eventi/storico pratica
  • scadenze minime via milestone e data scadenza documento

Mancanze vere

  • Dorotech oggi e separato e ancora troppo "workspace/API" rispetto a un modulo FAB pulito.
  • Il nucleo Dorotech non e integrato bene nel menu operativo standard.
  • Non c'e ancora una chiara cucitura fra:
  • CommercialeOfferta
  • CommercialeTrattativa
  • CommercialeRichiestaServizio
  • CommercialeDorotechPratica
  • Gli stati Dorotech e gli stati offerta generali non sono ancora allineati in modo esplicito.
  • La tipologia lavoro Dorotech esiste gia come sigla, ma non e ancora esposta come semplice tabella gestionale FAB.
  • La trasformazione offerta -> ordine/pratica esiste a livello Dorotech, ma non e ancora resa come azione standard amministrativa leggibile.
  • La checklist documenti Dorotech esiste, ma non e ancora appoggiata in modo sistematico al documentale cliente esistente.
  • Le scadenze sono coperte da strutture compatibili, ma manca una vista operativa Dorotech leggera dedicata.

3. Proposta tecnica minimamente invasiva

Scelta architetturale

  • Non creare un nuovo dominio parallelo.
  • Riutilizzare il commerciale esistente come backbone:
  • Cliente
  • CommercialeTrattativa
  • CommercialeOfferta
  • CommercialeRichiestaServizio
  • CommercialeRichiestaMilestone
  • Documento / Categoria
  • Tenere CommercialeDorotechPratica come estensione verticale Dorotech solo dove aggiunge valore:
  • sigla lavoro
  • bene/macchina
  • checklist Dorotech
  • storico eventi Dorotech
  • documenti Dorotech generati

Nome del contenitore operativo

  • Nel progetto esiste gia CommercialeRichiestaServizio.
  • Per Fase 1 conviene usare:
  • Offerta = CommercialeOfferta
  • Ordine/Pratica operativa = CommercialeRichiestaServizio
  • Pratica Dorotech = verticale opzionale collegata alla richiesta, non sostitutiva

Impatto minimo

  • Estendere i modelli esistenti, non raddoppiare tabelle base.
  • Creare solo cio che manca davvero:
  • storico eventi offerta minimale
  • piccolo allineamento stati e campi date
  • view FAB Dorotech pulite
  • tipologie lavoro esposte da CommercialeDorotechSigla

4. Piano implementativo a step piccoli e sicuri

Step 0 - hardening

  • Portare la creazione schema Dorotech fuori dal runtime view bootstrap.
  • Spostare le tabelle Dorotech esistenti in Alembic.

Step 1 - nucleo Fase 1

  • Riutilizzare accesso e ruoli esistenti.
  • Riutilizzare Cliente e referenti.
  • Estendere CommercialeOfferta per workflow Dorotech semplice.
  • Aggiungere azione FAB Accetta e crea ordine/pratica.
  • Creare/rendere visibili view FAB:
  • Dorotech Clienti
  • Dorotech Offerte
  • Dorotech Pratiche
  • Dorotech Tipologie lavoro
  • Riutilizzare ClienteDocsChecklistView per documenti richiesti/ricevuti.
  • Riutilizzare CommercialeRichiestaMilestone per scadenza lavoro e reminder.

Step 2 - raffinamento

  • Workflow commerciale piu leggibile.
  • timeline/eventi offerta
  • dashboard React solo se serve davvero

5. Codice da implementare in Fase 1

Modelli da riusare senza duplicare

  • Cliente
  • CommercialeTrattativa
  • CommercialeOfferta
  • CommercialeRichiestaServizio
  • CommercialeRichiestaMilestone
  • CommercialeDorotechSigla
  • CommercialeDorotechPratica
  • CommercialeDorotechChecklistItem
  • CommercialeDorotechEvento

Campi da aggiungere a modelli esistenti

CommercialeOfferta

Aggiunte consigliate: - workflow_type String(40) default generic_offer - numero_progressivo Integer nullable - anno_riferimento Integer nullable - tipologia_codice String(16) nullable - data_invio Date nullable - data_sollecito Date nullable - solleciti_count Integer default 0 - data_esito Date nullable - motivo_esito Text nullable

Stati da allineare: - bozza - inviata - in_attesa - sollecitata - accettata - rifiutata - annullata

CommercialeRichiestaServizio

Aggiunte minime consigliate: - workflow_type = "dorotech_order" per distinguere il ramo Dorotech - data_prevista_lavoro Date nullable - data_scadenza_lavoro Date nullable - note_tecniche Text nullable - note_amministrative Text nullable - dorotech_pratica_id Integer nullable FK a commerciale_dorotech_pratica

CommercialeDorotechPratica

Gia buona. Non allargherei molto in Fase 1. Al massimo: - offerta_id FK a commerciale_offerta

Nuove tabelle minime realmente utili

commerciale_offerta_evento

Serve per storico essenziale offerta senza sporcare note. Campi: - id - tenant_key - offerta_id - user_id - event_type - from_state - to_state - message - payload_json - created_at

Questa e la sola nuova tabella core che consiglio davvero in Fase 1.

Migrazione Alembic

Creare una migration che: - aggiunge i campi a commerciale_offerta - aggiunge i campi minimi a commerciale_richiesta_servizio - crea commerciale_offerta_evento - opzionalmente aggiunge FK offerta_id a commerciale_dorotech_pratica

View / menu / API

FAB classico

Nuove/estese view: - CommercialeDorotechSiglaView - menu: Dorotech > Tipologie lavoro - CommercialeDorotechPraticaView - menu: Dorotech > Pratiche - CommercialeOffertaDorotechView - meglio come filtro su CommercialeOfferta con workflow_type="dorotech" - menu: Dorotech > Offerte - CommercialeRichiestaServizioDorotechView - filtro su richieste/pratiche Dorotech - menu: Dorotech > Ordini / Pratiche

Proposta minima: - Dorotech - Clienti - punta a ClienteView con filtro tipologia Dorotech se disponibile - Offerte - Pratiche - Tipologie lavoro - Checklist documenti - link riuso ClienteDocsChecklistView

React

  • Non necessario in Fase 1.
  • Tenere React opzionale solo per una pipeline commerciale futura.

6. Note di compatibilita con SafeOps

  • Coerente con Flask-AppBuilder e i ModelView gia esistenti.
  • Coerente con il DB SQLAlchemy/MySQL gia in uso.
  • Riutilizza il documentale esistente.
  • Riutilizza checklist documenti e categorie.
  • Riutilizza milestone/reminder per scadenze.
  • Evita di introdurre un "secondo gestionale".
  • Evita di toccare il resto dei flussi RAS/commerciali gia esistenti.

7. TODO futuri separati dal core

  • dashboard pipeline offerte per stato
  • KPI commerciale Dorotech
  • reminder automatici per solleciti offerta
  • modelli documenti richiesti per sigla lavoro
  • timeline grafica pratica
  • assegnazione tecnico piu avanzata
  • calendario pianificazione lavori dedicato

Scelta consigliata per partire subito

Fase 1 reale: 1. consolidare schema Dorotech via Alembic 2. aggiungere i campi minimi a CommercialeOfferta 3. aggiungere commerciale_offerta_evento 4. aggiungere azione Accetta e crea pratica 5. esporre menu FAB Dorotech pulito 6. riusare checklist documenti cliente e milestone esistenti

Questa e la strada con il miglior rapporto tra impatto basso, riuso alto e valore operativo.