Configurazione di un Processo Base - Approvazione Preventivo

DESCRIZIONE DEL FLUSSO

Alla creazione di un preventivo con Stadio Preventivo = “Creato”, il processo si scatenerà e presenterà ai componenti del gruppo “Direzione” un process helper in modalità popup richiedendone la compilazione.

In caso di conferma verrà inviata una notifica interna di avviso all’assegnatario del preventivo (che corrisponde al commerciale che sta gestendo il preventivo).

Invece in caso di rifiuto verrà inviata una mail di avviso sempre all’assegnatario del preventivo (che corrisponde al commerciale che sta gestendo il preventivo) contenente eventuali note/commenti interni utili alla revisione dello stesso.

Se entro due giorni il popup non verrà compilato da nessun utente, il sistema invierà una mail di sollecito ai componenti del gruppo.

Nel caso in cui si verificasse un errore SMTP nell’invio della mail di mancata approvazione, il sistema avviserà i componenti del gruppo “Reparto IT” tramite l’invio di una notifica interna.

ELEMENTI NECESSARI NEL PROCESSO

Per fare questo processo ci serviranno gli elementi elencati qui di seguito:

-Condition Task

-Action Task

-Timer Boundary Event

-Gateway

-End Event

Se il loro funzionamento non è chiaro consigliamo prima di consultare il capitolo 2 del manuale dei processi.

CONFIGURAZIONE DIAGRAMMA DI FLUSSO

Utilizziamo gli elementi citati in precedenza per impostare un diagramma come quello mostrato nella Figura 1



Figura 1

CONFIGURAZIONE DEI SINGOLI ELEMENTI DEL FLUSSO

Procediamo con la configurazione dei singoli elementi che compongono il flusso del processo.

Partiamo dalla Condition Task "Creazione preventivo".

Nella sezione "Quando eseguire il controllo" selezioniamo l'opzione "Alla creazione” per far partire il processo solamente alla creazione del preventivo con Stadio Preventivo = “Creato” (Figura 2).

Figura 2

Nella UserTask “PH richiesta approvazione” configuriamo un process helper al fine di richiedere all’utente le informazioni necessarie all’approvazione del preventivo.

Configurazione blocco “Process Helper”:

-nel campo “Assegnato a” inseriamo staticamente il gruppo “Direzione”

-nel campo “Collegato a” inseriamo l’id del preventivo

-nel campo “Nome Processo” indichiamo il nome che verrà attribuito al processo in questo specifico step, quindi inseriamo la parte statica “PH richiesta approvazione” seguita dal valore della variabile “Numero Preventivo”

-nel campo “Azione richiesta” inseriamo una breve descrizione dell’attività da svolgere

-spuntiamo il campo checkbox “Mostra nell’entità collegata” per far attivare la modalità popup del process helper

Il risultato sarà quello mostrato in Figura 3.

Figura 3

Configurazione form dinamica:

Nella form dinamica creiamo un solo Blocco chiamato “Informazioni Preventivo” (vedi Figura 4) con i seguenti campi:

1 ”Azione” (campo picklist) con i seguenti valori: “vuoto”, “APPROVARE” e “NON APPROVARE” (vedi Figura 5)

2 “Note interne” (campo area di testo)

Figura 4



Figura 5

Configurazione azione Resetta Form Dinamica

Andiamo a creare un’azione di “Resetta Form Dinamica” per fare in modo che vengano resettati i valori dei campi presenti nella form nel caso in cui venga forzata la ri-compilazione del process helper (vedi Figura 6).

Figura 6

Nella Condition Task “Controllo PH richiesta approvazione” andiamo ad eseguire un controllo sul campo “Azione” della form del process helper per indirizzare il processo nel ramo relativo al valore inserito dall’utente (vedi Figura 7)

Figura 7

Nel bordo in basso a destra della task andiamo a posizionare un Timer Boundary Event (Figura 8) e procediamo con la sua configurazione inserendo 2 giorni di intervallo temporale (Figura 9)

Per approfondimenti consultare il capitolo 2.3 del manuale dei processi.

Figura 8



Figura 9

Al Timer Boundary Event andiamo a collegare la SendTask “Invio notifica di sollecito alla Direzione” in modo da inviare una notifica interna ai componenti del gruppo “Direzione” nel caso in cui il processo rimanga fermo sulla Condition Task “Controllo PH richiesta approvazione” per più di 2 giorni (Figura 10)

Per approfondimenti consultare la sezione 3.4 del manuale dei processi.



Figura 10

Nel gateway successivo andiamo ad associare ad ogni gruppo di condizioni (inserite nella Condition Task “Controllo PH richiesta approvazione”) il ramo corrispettivo da percorrere (vedi Figura 11)



Figura 11

Configurazione degli elementi successivi al ramo “APPROVARE”

Nella SendTask “Invio notifica interna ad assegnatario preventivo” configuriamo l’invio di una notifica interna all’assegnatario del preventivo (che corrisponde al commerciale che sta gestendo il preventivo) per avvisarlo dell’avvenuta approvazione del preventivo (Figura 12).

Per approfondimenti consultare la sezione 3.4 del manuale dei processi.



Figura 12

Anche l’endEvent deve essere configurato, in quanto, abbiamo coinvolto un process helper nel processo, quindi si rende necessario andare ad attivare un process helper al suo interno per impostare lo stato del processo in “Terminato” (vedi Figura 13)

Figura 13

Configurazione degli elementi successivi al ramo “NON APPROVARE”

Nella SendTask “Invio mail ad assegnatario preventivo” configuriamo l’invio di una mail all’assegnatario del preventivo (che corrisponde al commerciale che sta gestendo il preventivo) per avvisarlo della mancata approvazione del preventivo (Figura 14).

Per approfondimenti consultare la sezione 3.5 del manuale dei processi.

Figura 14

Nella ScriptTask “PH di appoggio per raccolta esito invio mail” andiamo ad attivare un process helper, al fine di sfruttarne la form dinamica per storicizzare il risultato dell’invio della mail (Figura 15).

Nello specifico, per ogni azione di “Invio mail” configurata all’interno del processo, il sistema mette a disposizione le seguenti due variabili (Figura 16 e 17):

- ”Esito positivo?” → viene restituito 1 nel caso in cui NON sia presente alcun tipo di errore SMTP, in caso contrario viene restituito 

-”Messaggio di errore” → viene restituita la descrizione dell’errore SMTP riscontrato

Figura 15



Figura 16



Figura 17

Nella Condition Task “Controllo risultato invio mail” andiamo ad eseguire un controllo sul campo “Esito positivo?” della form del process helper per indirizzare il processo nel ramo relativo all’esito dell’invio mail (vedi Figura 18)



Figura 18

Nel gateway successivo andiamo ad associare ad ogni gruppo di condizioni (inserite nella Condition Task “Controllo risultato invio mail”) il ramo corrispettivo da percorrere (vedi Figura 19)



Figura 19

Configurazione degli elementi successivi al ramo “Ok”

Anche l’endEvent deve essere configurato, in quanto, abbiamo coinvolto un process helper nel processo, quindi si rende necessario andare ad attivare un process helper al suo interno per impostare lo stato del processo in “Terminato” (vedi Figura 20)



Figura 20

Configurazione degli elementi successivi al ramo “Ko”

Nella SendTask “Invio notifica interna a reparto IT” configuriamo l’invio di una notifica interna al gruppo “Reparto IT” per segnalare l’anomalia riscontrata sull’invio della mail (Figura 21)

Per approfondimenti consultare la sezione 3.4 del manuale dei processi.

Figura 21

Anche l’endEvent deve essere configurato, in quanto, abbiamo coinvolto un process helper nel processo, quindi si rende necessario andare ad attivare un process helper al suo interno per impostare lo stato del processo in “Terminato” (vedi Figura 22)

Figura 22