8.1 Modifica gestione stati

Con riferimento al diagramma di flusso riportato al Cap.7 del presente documento, si specifica che verrà modificata la gestione del flusso vitale di una Variante per adeguarsi alle richieste. Per rendere più chiare le modifiche da apportare, si riporta, in maniera semplificata, un altro diagramma di flusso che mette a confronto la vecchia gestione con la nuova:

Come deducibile dallo schema di cui sopra, a cambiare notevolmente sarà la gestione dell’approvazione della Variante: in GISFO, infatti, si gestiva sia l’approvazione economica che l’approvazione operativa, demandando rispettivamente al FM e al DL le specifiche tipologie di approvazione. Una volta ottenute, la variazione veniva considerata approvata e si procedeva all’archiviazione (ovviamente, nel caso di rifiuto da parte di DL o FM, la variazione veniva considerata rifiutata).

Nel nuovo flusso, invece, GISFO gestirà la sola approvazione operativa della variante, che dovrà essere data sia dal DL che dal FM. Una volta ottenute le due approvazioni, GISFO dovrà procedere alla comunicazione con P+ per richiedere l’approvazione economica della variante stessa. Si specifica che, in maniera analoga a quanto succede as is, se non venisse data l’approvazione operativa da parte del DL e/o del FM, la variante verrebbe considerata Rifiutata e se non venisse data l’approvazione economica da parte di P+, ugualmente la variante verrebbe considerata Rifiutata.

Si specifica, infine, che lo stato conclusivo di una Variante sarà l’Approvazione Economica (vd. diagramma di flusso Cap.7) e la successiva archiviazione dell’area dipenderà dall’eventuale redazione del campo ‘Permessi necessari’ (vd. diagramma di flusso Cap.7 e Par.7.8).

Le modifiche apportate al flusso, ovviamente, impatteranno anche alcune delle label riportate nelle varie GUI in GISFO preposte alla gestione dei dati riferiti alle varianti (comprese quelle implicitamente indicate nel diagramma di flusso di cui sopra).

Si riporta quindi di seguito il mockup della scheda di dettaglio di una Variante, con indicati i vari campi all’interno della scheda la cui label verrà cambiata per adeguarsi al nuovo flusso:

Come deducibile dallo schema di cui sopra, verranno modificate le seguenti label:

•          Tasto azione “Approvazione economica” à “Approvazione operativa FM”
•          Tasto azione “Approvazione operativa” à “Approvazione operativa DL”
•          Tab “Dettaglio variazione complessa” à “Dettaglio Variante”
•          Nella sezione inferiore della scheda di dettaglio:

o    “Approvazione economica” à “Approvazione operativa FM”

o    “Data approvazione economica” à “Data approvazione operativa FM”

o    “Approvazione operativa” à “Approvazione operativa DL”

o    “Data approvazione operativa” à “Data approvazione operativa DL”

Si pone l’attenzione sul nuovo tasto action ‘Ritorna “In Lavorazione”’ che sarà accessibile al DL e al FM e permetterà a questi due gruppi di utenza di riportare la Variante nello stato ‘In Lavorazione’, nel caso in cui lo ritenessero necessario.

Si pone anche l’attenzione sul campo ‘Giorni di proproga’ (vd.tabella cmt_variant al Cap.6) che sarà compilato a cura dell’utente riportando, appunto, i giorni di proroga. Verrà inserito un groovie di controllo su questo campo, all’avvio dell’azione di richiesta di approvazione, che verifichi che sia effettivamente compilato (sarà accettato anche il valore 0). Nel caso in cui però il campo sia lasciato vuoto, verrà presentato all’utente un warning bloccante di questo tipo: ‘Non è possibile richiedere l’approvazione di una Variante senza compilare il campo “Giorni di proroga”. Compilare questo campo e riprovare.’.

Si reputa infine opportuno riportare in questa sede uno schema dei vari stati adottati (non un diagramma di flusso), di competenza di GISFO, di P+ o di entrambi. Ognuno di questi stati sarà notificato al sistema non coinvolto nel processo di turno tramite WS (vd.Par.8.7 del presente documento):