Monitor Workflow

• Delegato eccezionale (campo DELEXP)

Quando questa casella viene selezionata, l'utente vede apparire le notifiche inviate agli utenti per le quali fruisce di una delega straordinaria.

Questa casella può essere selezionata soltanto se l'utente fruisce almeno di una delega di questo tipo.

• Destinatario mail (campo USER)

Definisce il codice utente destinatario degli eventi di Workflow in attesa di approvazione che si desidera vedere.

Può essere inserito soltanto in questi due casi:

• Se l'opzione Tutti gli utenti è autorizzata all'utente corrente per la funzione.
• Se la casella Delegato straordinario è selezionata (in questo caso, è possibile scegliere l'utente per il quale si ha una delega straordinaria della quale si desidera visualizzare le notifiche).

Se questo campo non può essere inserito, è di default uguale al valore corrente dell'utente.

Se tale campo può essere inserito, ma non gli è fornito alcun valore, le notifiche seguenti possono essere visualizzate:

• quelle degli utenti per i quali si ha una delega straordinaria se la casella Delega straordinariaè selezionata.
• altrimenti quelle indirizzate alla totalità degli utenti.

• Data inizio (campo DATDEB)

Se questa data viene indicata, saranno considerati dall'elaborazione i soli dati la cui data di ultima modifica o data di creazione sia maggiore o uguale.

Vi è da notare che, di default, la data proposta è la data del giorno, diminuita di un numero di giorni uguali al valore del parametro WRKDAY.

• Data fine (campo DATFIN)

Se questa data viene indicata, saranno considerati dall'elaborazione i soli dati la cui data di ultima modifica o data di creazione sia minore o uguale.

Di default, questa data è uguale alla data del giorno.

• campo PAGFIR

Bottoni di navigazione che permettono di scorrere l'insieme delle righe del piano di lavoro.

• campo PAGPRV

• campo PAGNXT

• campo PAGLST

• campo W

• campo PAGCUR

• campo SAICRI

Bottone che permette di aprire una videata di inserimento di un criterio di selezione delle righe sotto forma di una espressione logica.

Questo criterio viene applicato a tutti i folder oltre ai criteri specifici ad ogni folder.

• Crono (campo CHRONO)

Numero cronologico attribuito quando un Workflow viene attivato. Nel caso di un Workflow manuale, viene attribuito un numero per ogni record attivato. Negli altri casi, viene attribuito un solo numero cronologico per attivazione.

Così, quando una notifica viene inviata a più utenti a partire da uno stesso evento, il numero crono è lo stesso.

• Destinatario mail (campo DEST)

Definisce il destinatario della notifica. Se è atteso un visto o un'approvazione, è lui generalmente che lo deve effettuare.

Questo destinatario non è obbligatoriamente il destinatario che è stato definito nella regola d'origine. Effettivamente, se la regola prevede una delega al primo destinatario libero, e se il destinatario di partenza ha definito una delega con potere per le relative date, è il delegato che è destinatario della notifica (o suo delegato se egli stesso ha delegato...).

• Email destinatario (campo EMAIL)

Quando un messaggio è inviato dalla regola a un destinatario, il suo indirizzo di posta appare in questo campo.

• N° workflow (campo NUMGRP)

Questo numero crono viene attribuito ad ogni riga elaborata (se ne ha quindi molti quando si hanno dei Workflow di tipo testata/riga con dei raggruppamenti).

• Società (campo CPY)

Quando un modello di dati è collegato alla regola e tale modello definisce una società corrente in funzione del contesto (sia direttamente o tramite un sito), si memorizza nell'evento la società corrispondente.

Questa società può essere utilizzata (ma non è obbligatorio) per definire la regola di assegnazione che determinerà i destinatari della notifica.

• Delegato (campo DELEGUE)

Questo campo vale No se l'utente è il primo destinatario della notifica. Vale Si se l'utente riceve la notifica in quanto delegato non sostitutivo (opzioni Tutti o Cascata), e che inoltre ha potere di firma (se non ha potere di firma, la notifica non appare nel piano di lavoro.

Occorre notare che se tale campo vale Si, almeno un'altra riga che porta lo stesso numero crono con il valore No esiste nella tabella che aggiorna i dati del piano di lavoro (possono esserci altre righe con lo stesso numero crono e tale flag uguale a Si se esistono più delegati con potere di firma). La prima firma su una delle righe relative aggiorna automaticamente l'insieme delle righe che portano lo stesso numero crono considerandole come approvate.

• Invio mail (campo ENVOI)

Questo campo vale Si se è stato inviato un messaggio durante l'esecuzione della regola.

• Mittente (campo EMETTEUR)

Definisce l'emittente della notifica, ovvero l'utente la cui azione ha attivato il Workflow. In un Workflow di tipo Firma, l'emittente è colui che ha firmato la notifica precedente. In un altro Workflow, l'emittente è l'utente la cui azione attiva l'invio della notifica.

• Email mittente (campo MAIENV)

Quando una riga del piano di lavoro è stata approvata per l'attivazione di un legame http da un messaggio, questo campo salva l'indirizzo di posta dell'utente della qualità che ha firmato.

• Data emissione (campo DATENV)

Corrisponde alla data di sistema (come quella riconosciuta dal server di elaborazione) al momento dell'esecuzione dell'evento di Workflow.

• Ora emissione (campo TIMENV)

Corrisponde all'ora di sistema (come quella riconosciuta dal server di elaborazione) al momento dell'esecuzione dell'evento di Workflow.

• Natura workflow (campo NATURE)

Corrisponde al valore del campo Natura Workflow definito sull'evento attivante. Questo può essere un criterio comodo per ordinare le righe, per filtrarle o per smistarle su diversi folder del piano di lavoro.

• Testo avanzamento (campo TEXSUI)

Contiene il testo valorizzato a partire dal campo Testo controllo definito nel folder Controllo della regola; generalmente, si parametrizza un commento che spiega le circostanze dell'attivazione di Workflow.

• Tipo evento (campo TYPEVT)

Definisce il tipo d'evento della regola di Workflow all'origine della riga di notifica nel piano di lavoro.

• Codice evento (campo CODEVT)

Corrisponde al codice evento all'origine del Workflow, ossia al codice:

• dell'oggetto nel caso di un Workflow oggetto.
• della stampa nel caso di un Workflow di tipo stampa.
• del modello nel caso di un import o un export.
• della funzione nel caso di un'entrata sulla funzione.
• della regola di Workflow avendo attivato la richiesta di firma (approvazione) nel caso di una firma.
• di un codice che identifica il Workflow diverso in questo caso.

• Codice workflow (campo CODWRK)

Identifica la regola di Workflow la cui esecuzione ha inviato la notifica.

• Operazione (campo OPERATION)

Contiene il codice operazione nel contesto attivante:

• per un evento oggetto, può essere C (creazione), M (variazione... o il codice del bottone.
• per un evento firma, il codice della regola all'origine della firma
• per un import/export, le combinazioni I/E e D/F (import/export, inizio/fine), per esempio ID.
• per un'entrata sulla funzione, il campo è vuoto.
• per una stampa, è uguale a C.
• per il termine di un job batch, vale "0" se il job è terminato senza errori, altrimenti, è presente il numero di stato controllo dell'inizio del messaggio d'errore.

• Termine firma (campo DATMAXSIG)

Questo campo contiene la data alla quale il Workflow dovrà essere approvato. E' uguale alla data di attivazione se nessun processo di approvazione/firma è stato attuato, o se nessuna data limite è stata definita.

Infatti, quando l'evento di Workflow presuppone una firma:

• si può gestire una data limite di Workflow (attraverso il campo che fornisce una espressione calcolata corrispondente nella parametrizzazione del Workflow).
• si possono in seguito attivare dei solleciti basati su questa data limite. Questi solleciti si fanno utilizzando delle regole di Worflow batch chiamate WRKREM1, WRKREM2, e WRKREM2E.

Quando viene effettuato un sollecito di questo tipo:

• si incrementa il campo Numero di solleciti, il che permette allora di sapere quante volte è stata sollecitata la firma.
• si aggiorna il campo Ultima data di sollecito, il che permette di conoscere la data alla quale è stata apposta l'ultima firma.

Se queste regole batch non vengono utilizzate, e se non è stata definita nessuna regola per movimentare questi campi, il numero di solleciti resta uguale a 0 e la data di sollecito resta nulla, poiché nessun programma standard del Workflow modifica questo valore.

• Flag firma (campo FLGSIG)

Questo campo definisce il livello di firma corrispondente alla notifica della riga. I valori possibili, definiti dal menu locale 2922, sono i seguenti:

• Da leggere: si richiede una conferma di lettura e la notifica non è ancora stata letta.
• Da firmare: si richiede una firma e la notifica non è ancora stata frimata.
• Letta: si richiede una conferma di lettura che è stata inserita.
• Firmata: si richiede una firma, la quale è stata accordata.
• Annullata: è stata accordata una firma, la quale è stata poi annullata.

• Risposta (campo ACTSIG)

Questo campo è vuoto finché l'evento non è stato approvato. Se lo è stato, si trova il codice risposta che è stato inserito, come viene definito nella tabella diversa numero 54.

• Resp. visti (campo USRSIG)

Quando una riga del riquadro delle notifiche è stata approvata, si vede apparire qui il codice dell'utente che ha firmato. Non si tratta obbligatoriamente del destinatario origine, poiché può avere potere di firma anche un altro utente.

• Email firmatario (campo MAISIG)

Quando un messaggio, che include una richiesta di controllo per attivazione di un legame http, è stato inviato, questo campo permette di conoscere l'indirizzo di posta del destinatario.

• Data firma (campo DATSIG)

Se la notifica di Workflow ammette un controllo (semplice visto o firma), questo campo permette di sapere a quale data il controllo è stato effettuato (rimane vuoto finché non è stato creato).

• Ora firma (campo TIMSIG)

Se la notifica di Workflow ammette un controllo (semplice visto o firma), questo campo permette di sapere a quale ora il controllo è stato effettuato (rimane vuoto finché non è stato creato).

• Causale risposta (campo REASON)

Contiene la descrizione associata al codice causale inserito alla firma della regola, quando tale inserimento è possibile al momento della firma. Ciò presuppone che si definisca un elenco di causali possibili tramite l'intermediario di un numero di tabella diversa sulla riga di firma corrispondente.

• Codice causale (campo REACOD)

Contiene il codice causale inserito alla firma della regola, quando tale inserimento è possibile al momento della firma. Ciò suppone che si definisca un elenco di causali possibili tramite l'intermediario di un numero di tabella diversa sulla riga di firma corrispondente.

• N° causale (campo REANUM)

Quando un inserimento di codice causale è stato previsto alla firma della regola, è presente in questo campo il numero di tabella diversa che definisce le causali possibili sulla riga di firma corrispondente.

• Chiave attivante (campo CLEOBJ)

Nel caso di un Workflow oggetto, è presente in questo campo la chiave dell'oggetto (è il campo Chiave attivante d'origine). Nel caso di un Workflow di tipo firma, è presente in questo campo il numero crono all'origine della firma. Per tutti gli altri casi, questo campo non è indicato.

• Tabella attivante (campo IDENTREF)

Questo campo tecnico contiene il codice della tabella attivante e il codice della chiave corrispondente, esattamente allo stesso modo che per il campo Identificativo riga. Invece, in caso d'evento di tipo firma, resta vuoto, ovvero non è trasmesso dalla notifica d'origine.

• Identificativo ritorno (campo IDENTRET)

Quando un'icona di ritorno viene associata al Workflow, questo campo contiene il nome della funzione sulla quale si effettua il ritorno. Se la funzione è di tipo oggetto, si ritrova di seguito, separata da un "/" dalla tabella, la chiave corrispondente (i segmenti di chiavi, per una chiave in più parti, sono stati separati da "~").

• Identificativo riga (campo IDENTGRP)

Questo campo tecnico contiene, nell'ordine, il nome della tabella nella quale si trova l'evento attivante d'origine, seguito dalla chiave corrente legata al gruppo che ha provocato l'attivazione. Il separatore tra tabella e chiave è "/", il separatore tra i segmenti della chiave (quand'essa è composta da più campi) è "~".

Il contenuto è definito nel seguente modo:

• nel caso di un evento di tipo Firma, si riporta il contenuto della notifica d'origine.
• nel caso in cui l'evento è di tipo Oggetto, si riprende la tabella principale dell'oggetto se può essere determinata (ciò significa che nulla è indicato se è un Workflow generico con un codice oggetto vuoto). La chiave corrisponde alla chiave corrente durante l'attivazione Workflow.
• in tutti gli altri casi, la tabella viene definita esclusivamente se un modello di dati è collegato al Workflow. In questo caso, è la tabella principale che è rinviata. La chiave corrisponde al record corrente durante l'attivazione.

• Crono origine (campo NUMORG)

Questo numero crono viene indicato esclusivamente sulle notifiche legate ad un evento di tipo Firma; permette di conoscere il numero cronologico dell'evento origine, quello la cui firma ha attivato la riga corrente.

• Destinatario origine (campo USRORG)

Questo campo è indicato soltanto sulle righe associate ad un evento di tipo Firma. Permette di conoscere il destinatario del Workflow origine (quello che ha effettivamente ricevuto la notifica dopo l'eventuale applicazione delle regole di delega: non è obbligatoriamente lui che ha firmato).

• Data sollecito (campo DATREL)

Questo campo contiene la data alla quale è stato effettuato l'ultimo sollecito di approvazione/firma sulla notifica. Non è indicato se nessun processo di approvazione è stato attuato.

Infatti, quando l'evento di Workflow presuppone una firma:

• si può gestire una data limite di Workflow (attraverso il campo che fornisce una espressione calcolata corrispondente nella parametrizzazione del Workflow).
• si possono in seguito attivare dei solleciti basati su questa data limite. Questi solleciti si fanno utilizzando delle regole di Worflow batch chiamate WRKREM1, WRKREM2, e WRKREM2E.

Quando viene effettuato un sollecito di questo tipo:

• si incrementa il campo Numero di solleciti, il che permette allora di sapere quante volte è stata sollecitata la firma.
• si aggiorna il campo Ultima data di sollecito, il che permette di conoscere la data alla quale è stata apposta l'ultima firma.

Se queste regole batch non vengono utilizzate, e se non è stata definita nessuna regola per movimentare questi campi, il numero di solleciti resta uguale a 0 e la data di sollecito resta nulla, poiché nessun programma standard del Workflow modifica questo valore.

• N° sollecito (campo NBRREL)

Questo campo contiene il conteggio del numero di solleciti di firme effettuati sull'evento Workflow.

Infatti, quando l'evento di Workflow presuppone una firma:

• si può gestire una data limite di Workflow (attraverso il campo che fornisce una espressione calcolata corrispondente nella parametrizzazione del Workflow).
• si possono in seguito attivare dei solleciti basati su questa data limite. Questi solleciti si fanno utilizzando delle regole di Worflow batch chiamate WRKREM1, WRKREM2, e WRKREM2E.

Quando viene effettuato un sollecito di questo tipo:

• si incrementa il campo Numero di solleciti, il che permette allora di sapere quante volte è stata sollecitata la firma.
• si aggiorna il campo Ultima data di sollecito, il che permette di conoscere la data alla quale è stata apposta l'ultima firma.

Se queste regole batch non vengono utilizzate, e se non è stata definita nessuna regola per movimentare questi campi, il numero di solleciti resta uguale a 0 e la data di sollecito resta nulla, poiché nessun programma standard del Workflow modifica questo valore.

• Livello firma (campo LEVSIG)

Questo campo corrisponde al livello di approvazione/firma, quando si concatenano degli eventi di firma.

• vale 0 sull'evento origine.
• vale 1 sull'evento attivato dalla prima firma.
• ad ogni evento che si concatena, è incrementato di 1.

La variabile LEVSIG corrispondente è frequentemente utilizzata nelle regole di Workflow quando la regola d'assegnazione dell'evento origine fornisce l'insieme dei firmatari (da 1 a 9 massimo). E' sufficiente, nell'evento origine come negli eventi di firma che si concatenano, fornire come formula di destinatario USER(LEVSIG+1) per avere l'utente numero N nella lista. Ciò permette generalmente d'avere delle regole di firma ricorrenti, eseguite finché rimangono dei firmatati.

• Icona di ritorno (campo CONTXT)

Quando un Workflow invia un messaggio con un icona di installazione, il contesto di connessione (dossier, server, servizio, funzione...) viene definito sotto forma di un campo alfanumerico.

Questo campo tecnico contiene tale contesto. I diversi segmenti di tale campo sono separati dal carattere "/".

• Ritorno ufficio (campo CONTXTSYRA)

• [Retour mobile] (campo CONTXTMOBI)

• Chiave attivante d'origine (campo CLEDEC)

Identifica la chiave all'origine del circuito di Workflow. Questa chiave, quand'essa viene composta da più parti, si presenta come una concatenazione delle parti di chiavi separate dal carattere tilde (~).

I valori di chiave dipendono dal contesto:

• su un Workflow oggetto, si tratta della chiave della scheda all'origine dell'attivazione.
• su un Workflow manuale, si tratta della chiave della tabella principale sulla quale si appoggia il modello di dati del Workflow.
• su un Workflow su import/export, su un'entrata in una funzione, nulla è indicato in questo campo.
• su un Workflow su stampa, non è indicato nulla se la stampa viene lanciata da una funzione di stampa (stampa, o stampa di gruppo). Altrimenti, se la stampa viene lanciata per File/Stampa o File/Lista da un oggetto, la chiave della scheda viene indicata in questo campo.
• su un Workflow di firma, si eredita la chiave della scheda origine, salvata sulla riga di controllo all'origine della firma.

• Numero firmatari (campo NBRUSR)

Definisce il numero d'utenti rinviati dalla regola d'assegnazione, quando ne esiste una.

Se non ne esiste una, ma la regola è di tipo Firma, si eredita un numero di firmatari definito nella regola origine.

Se non esiste alcuna regola d'assegnazione, il valore riproposto è 0.

• Oggetto (campo ABROBJ)

Quando il primo evento all'origine di un circuito di firma è un oggetto, questo campo identifica il codice oggetto. Negli altri casi , è vuoto.

E' successivamente trasmesso ai diversi eventi di firma che potranno concatenarsi al primo.

• Primo destinatario (campo USRTOP)

Definisce il primo destinatario dell'evento di Workflow. In effetti, un evento può inviare una notifica a più serie di destinatari, ciascuno di loro essendo definiti da una riga nel riquadro dei destinatari. Questo campo rappresenta il destinatario valorizzato dalla prima riga se l'opzione di delega è No, Tutti, oCascata. Se l'opzione èIl primo liberoe se l'utente non è effettivamente presente e ha dato delega, si ritrova nel campo l'utente delegato.

• Contesto 1 (campo VALCTX1)

Questo campo fa parte di un insieme di quindici campi generici che permettono di salvare dei valori contestuali valorizzati al momento dell'attivazione del Workflow a partire da formule inserite nel riquadro denominato Contesto del folder Controllo del Workflow.

I valori salvati in questo riquadro possono essere utilizzati:

• per trasmettere ad un evento di tipo Firma delle informazioni utili all'elaborazione dell'avanzamento del processo.
• per far apparire delle informazioni utili nel monitor di workflow. In questo caso, nella parametrizzazione della transazione, è possibile fornirgli un titolo particolare più parlante.

• Contesto 2 (campo VALCTX2)

• Contesto 3 (campo VALCTX3)

• Contesto 4 (campo VALCTX4)

• Contesto 5 (campo VALCTX5)

• Contesto 6 (campo VALCTX6)

• Contesto 7 (campo VALCTX7)

• Contesto 8 (campo VALCTX8)

• Contesto 9 (campo VALCTX9)

• Contesto 10 (campo VALCTX10)

• Contesto 11 (campo VALCTX11)

• Contesto 12 (campo VALCTX12)

• Contesto 13 (campo VALCTX13)

• Contesto 14 (campo VALCTX14)

• Contesto 15 (campo VALCTX15)

• Resp. visti 1 (campo USRSIG1)

Permette di definire le firme successive, quando una regola di assegnazione di destinatori rinvia N firme per la regola di Workflow. Questa informazione è normalmente utilizzata per permettere di gestire correttamente gli annullamenti di firma.

Sugli eventi di tipoFirma per i quali nessuna regola di assegnazione è definita, si ritrovano le firme associate alla regola attivante. così, quando N firmatari in cascata sono stati definiti nella regola d'origine e tutte le regole di firma che seguono non hanno delle regole di assegnazione è possibile conoscere il circuito di firma a ogni livello.

E' da notare che vengono visualizzati gli utenti definiti dalla regola prima dell'applicazione eventuale di regole di delega. Così, per esempio, se il primo destinatario della regola di firma è assente, ed è rimpiazzato, non si vedrà nel campoFirmatario 1la firma d'origine, mentre nel campo Primo destinatariosi troverà il sostituto al quale la domanda di firma è stata effettivamente inviata.

• Resp. visti 2 (campo USRSIG2)

• Resp. visti 3 (campo USRSIG3)

• Resp. visti 4 (campo USRSIG4)

• Resp. visti 5 (campo USRSIG5)

• Resp. visti 6 (campo USRSIG6)

• Resp. visti 7 (campo USRSIG7)

• Resp. visti 8 (campo USRSIG8)

• Resp. visti 9 (campo USRSIG9)