Workflow RAS Mapping Tecnico¶
Scopo¶
Mappare il flusso RAS target sulle entita' gia presenti in SafeOps, per capire:
- cosa esiste gia';
- cosa va riusato;
- cosa va introdotto senza rompere il modello attuale.
Questo documento va letto insieme a:
Entita' da Riutilizzare¶
1. CommercialeRichiestaServizio¶
Ruolo corretto:
- ingresso del flusso;
- contenitore della richiesta amministratore;
- stato operativo principale lato richiesta;
- payload dei dati precompilati e completati dal portale;
- allegati iniziali;
- log degli eventi.
Campi gia utili:
workflow_typestatopayload_jsonattachments_jsonassigned_agente_idtrattativa_iddocumento_idticket_id
Uso consigliato:
- mantenere qui lo stato di avanzamento alto livello della richiesta;
- non spostare qui la logica di preventivazione dettagliata;
- usare il record come "contenitore master" del flusso RAS.
2. CommercialeTrattativa¶
Ruolo corretto:
- contenitore commerciale;
- presa in carico commerciale;
- collegamento a listino, agente e offerta.
Uso consigliato:
- usarla quando la richiesta passa da
richiesta_inviataain_carico_commerciale; - mantenerla come layer commerciale, non come contenitore di documenti firmati o pagamento.
3. CommercialeOfferta¶
Ruolo corretto:
- documento commerciale economico;
- calcolo del prezzo da listino;
- breakdown economico;
- eventuale conversione ad attivazione.
Uso consigliato:
- riusarla come base per il
modulo d'ordine; - non duplicare un secondo modello economico parallelo.
Nota:
- oggi e' gia il punto piu vicino al "preventivo/prezzo da listino";
- il
modulo d'ordineva trattato come documento governato prodotto a partire dall'offerta.
4. Documento¶
Ruolo corretto:
- repository dei file del flusso;
- upload/download e versioning;
- documenti firmati;
- template renderizzati.
Uso consigliato:
- usare
Documentoper: - modulo d'ordine inviato al portale;
- modulo firmato ricaricato dall'amministratore;
- conferma d'ordine;
- lettera di incarico;
- documento tecnico finale firmato dal tecnico.
Nota:
- non serve un nuovo storage model dedicato al RAS;
- serve solo classificare bene i documenti e agganciarli alla richiesta giusta.
5. CommercialeTecnicoIncarico¶
Ruolo corretto:
- assegnazione tecnica;
- incarico al tecnico;
- pubblicazione incarico;
- perimetro operativo del tecnico.
Uso consigliato:
- usarlo per il tratto:
lettera_incarico_emessatecnico_assegnatoappuntamento_da_fissareintervento_in_esecuzione
Nota:
- e' gia il modello migliore per l'assegnazione al tecnico;
- non conviene introdurre un secondo modello "ordine operativo" separato.
Mappa Stato Target -> Entita' Attuale¶
| Stato target | Entita' primaria | Stato/campo attuale | Esito |
|---|---|---|---|
richiesta_bozza_admin |
portale/admin form | non persistito formalmente | da introdurre solo lato UI/sessione |
richiesta_inviata |
CommercialeRichiestaServizio |
nuova |
gia coperto |
in_carico_commerciale |
CommercialeRichiestaServizio + CommercialeTrattativa |
presa_in_carico / trattativa.stato=richiesta|contatto |
da consolidare |
modulo_ordine_generato |
CommercialeOfferta + Documento |
nessuno | da introdurre |
modulo_ordine_inviato |
Documento |
nessuno | da introdurre |
modulo_ordine_firmato_admin |
Documento + CommercialeRichiestaServizio |
nessuno | da introdurre |
modulo_ordine_confermato_commerciale |
CommercialeRichiestaServizio |
nessuno | da introdurre |
in_carico_operativo |
CommercialeRichiestaServizio |
in_lavorazione possibile riuso |
da consolidare |
conferma_ordine_generata |
Documento |
nessuno | da introdurre |
inviato_a_fatturazione |
CommercialeRichiestaServizio |
nessuno | da introdurre |
in_attesa_pagamento |
CommercialeRichiestaServizio |
nessuno | da introdurre |
pronto_per_lettera_incarico |
CommercialeRichiestaServizio |
nessuno | da introdurre |
lettera_incarico_emessa |
Documento + CommercialeTecnicoIncarico |
parziale tramite incarico | da consolidare |
tecnico_assegnato |
CommercialeTecnicoIncarico |
stato incarico |
gia parziale |
appuntamento_da_fissare |
CommercialeTecnicoIncarico |
nessuno esplicito | da introdurre |
intervento_in_esecuzione |
CommercialeTecnicoIncarico |
parziale | da consolidare |
intervento_completato |
CommercialeTecnicoIncarico / Documento |
parziale | da consolidare |
documento_tecnico_generato |
Documento |
gia possibile | da governare |
documento_tecnico_firmato |
Documento |
gia possibile | da governare |
documento_tecnico_ricaricato |
Documento |
gia possibile | da governare |
Mappa per Blocco di Flusso¶
Blocco 1. Richiesta Amministratore¶
Punto di ingresso corretto:
ClienteView.request_ras- alternativa backoffice da
CommercialeAmministratoreClienteView.new_ras_request
Gia coperto:
- controllo contratto amministratore;
- risoluzione servizio da listino;
- prefill dati condominio;
- raccolta payload e allegati;
- creazione
CommercialeRichiestaServizio; - assegnazione commerciale;
- apertura
CommercialeTrattativaperworkflow_type = ras_quote.
Da fare:
- distinguere in modo formale campi:
- precompilati;
- richiesti;
- mancanti;
- notificare anche la
reteoltre al commerciale; - formalizzare
richiesta_inviatacome stato di business e non solo come logica implicita.
Blocco 2. Commerciale e Modulo d'Ordine¶
Punto corretto:
CommercialeRichiestaServizioCommercialeTrattativaCommercialeOfferta
Gia coperto:
- aggancio a listino;
- apertura offerta/preventivo RAS;
- pricing da servizio/listino.
Da fare:
- generare
modulo d'ordinecomeDocumentoderivato dall'offerta; - segnare quando il documento e' stato:
- generato;
- inviato all'amministratore;
- ricaricato firmato;
- confermato dal commerciale.
Scelta consigliata:
- non introdurre un nuovo modello
ordine; - usare
CommercialeOffertaper il contenuto economico; - usare
Documentoper il file firmabile; - usare
CommercialeRichiestaServizio.statoper il checkpoint di flusso.
Blocco 3. Operativo e Fatturazione¶
Punto corretto:
CommercialeRichiestaServiziocome stato master;Documentoper conferma d'ordine;- integrazione fatturazione come evento/dispatch;
CommercialeTecnicoIncaricoper l'esecuzione.
Da fare:
- introdurre stato
in_carico_operativo; - generare
conferma d'ordine; - tracciare
inviato_a_fatturazione; - gestire flag tenant:
incarico immediatoincarico dopo pagamento
Scelta consigliata:
- il pagamento non deve vivere in
CommercialeTecnicoIncarico; - deve vivere come checkpoint sulla richiesta master o su una integrazione dedicata.
Blocco 4. Lettera di Incarico e Tecnico¶
Punto corretto:
CommercialeTecnicoIncaricoDocumento
Gia coperto:
- struttura incarico tecnico;
- perimetro tecnico attivo;
- pubblicazione incarico.
Da fare:
- legare formalmente l'incarico alla richiesta RAS;
- generare
lettera di incaricocome documento; - tracciare:
- tecnico selezionato;
- lettera emessa;
- appuntamento richiesto;
- intervento avviato;
- intervento completato.
Stati da Introdurre con Priorita'¶
Priorita' 1: richiesta/commerciale¶
Da introdurre su CommercialeRichiestaServizio.stato:
richiesta_inviatain_carico_commercialemodulo_ordine_generatomodulo_ordine_inviatomodulo_ordine_firmato_adminmodulo_ordine_confermato_commerciale
Priorita' 2: operativo/fatturazione¶
in_carico_operativoconferma_ordine_generatainviato_a_fatturazionein_attesa_pagamentopronto_per_lettera_incarico
Priorita' 3: tecnico¶
lettera_incarico_emessatecnico_assegnatoappuntamento_da_fissareintervento_in_esecuzioneintervento_completatodocumento_tecnico_generatodocumento_tecnico_firmatodocumento_tecnico_ricaricato
Decisioni Tecniche Consigliate¶
1. Stato master unico¶
Lo stato principale del flusso deve vivere su CommercialeRichiestaServizio.
Motivo:
- e' l'entita' che nasce dal portale amministratore;
- e' gia il contenitore della richiesta;
- e' il punto piu naturale per dashboard e code operative.
2. Nessun nuovo modello "ordine"¶
Non conviene introdurre subito una nuova tabella dedicata a:
- modulo d'ordine;
- conferma d'ordine;
- lettera di incarico.
Conviene invece usare:
CommercialeOffertaper il lato economico;Documentoper i file;- metadati/document type per distinguere i documenti del workflow.
3. Payment gate come regola tenant¶
La biforcazione:
- incarico subito;
- incarico dopo pagamento;
va modellata come configurazione tenant, non come logica hardcoded nella view.
4. Audit eventi obbligatorio¶
Ogni passaggio di stato deve generare log su:
CommercialeRichiestaServizioLog- piu eventuali note documento/incarico
Questo evita di perdere il filo tra commerciale, operativo e tecnico.
Sequenza di Implementazione Consigliata¶
- consolidare
CommercialeRichiestaServizio.statocon i nuovi stati RAS; - agganciare
CommercialeOffertaalla generazione delmodulo d'ordine; - aggiungere upload/validazione del modulo firmato dall'amministratore;
- introdurre
in_carico_operativo+conferma d'ordine; - introdurre il gate
after_payment; - agganciare
CommercialeTecnicoIncaricoalla richiesta RAS con lettera di incarico.
Questa e' la sequenza piu prudente:
- massimizza il riuso del codice esistente;
- evita nuove tabelle inutili;
- rende il flusso governabile per step.