Moniteur Workflow

Lorsque cette case est cochée, l'utilisateur voit apparaître les notifications envoyées aux utilisateurs pour lesquels il possède une délégation exceptionnelle.

Cette case ne peut être cochée que si l'utilisateur possède au moins une délégation de ce type.

Définit le code utilisateur destinataire des événements de Workflow en attente de signature que l'on désire voir.

Il ne peut être saisi que dans deux cas :

• Si l'option Tous utilisateurs est accordée à l'utilisateur courant pour la fonction.
• Si la case Délégué exceptionnel est cochée (dans ce cas, on peut choisir l'utilisateur pour lequel on a une délégation exceptionnelle dont on désire voir les notifications).

Si ce champ ne peut pas être saisi, il est par défaut égal à la valeur courante de l'utilisateur.

Si ce champ peut être saisi, mais qu'aucune valeur ne lui est donnée, les notifications suivantes peuvent être vues :

• celles des utilisateurs pour lesquelles on a une délégation exceptionnelle si la case Délégué exceptionnel est cochée.
• celles adressées à la totalité des utilisateurs sinon.

Si cette date est renseignée, seules les données dont la date de dernière modification ou la date de création est supérieure ou égale sont prises en compte dans le traitement.

Il est à noter que, par défaut, la date proposée est la date du jour, diminuée d'un nombre de jours égal à la valeur du paramètre WRKDAY.

Si cette date est renseignée, seules les données dont la date de dernière modification ou la date de création est inférieure ou égale sont prises en compte dans le traitement.

Par défaut, cette date est égale à la date du jour.

Boutons de navigation permettant de parcourir l'ensemble des lignes du plan de travail.

Bouton qui permet d'ouvrir un écran de saisie d'un critère de sélection des lignes sous la forme d'une expression logique.

Ce critère est appliqué à tous les onglets en plus des critères spécifiques à chaque onglet.

Numéro chronologique attribué lorsqu'un Workflow est déclenché. Dans le cas d'un Workflow manuel, un numéro est attribué pour chaque enregistrement déclencheur. Dans tous les autres cas, un seul numéro chronologique est attribué par déclenchement.

Ainsi, lorsqu'une notification est envoyée à plusieurs utilisateurs à partir d'un même événement, le numéro de chrono est le même.

Définit le destinataire de la notification. Si un visa ou une signature est attendue, c'est normalement lui qui doit la faire.

Ce destinataire n'est pas forcément le destinataire qui était défini dans la règle d'origine. En effet, si la règle prévoit une délégation au premier destinataire libre, et que le destinataire de départ a défini un délégué avec pouvoir pour les dates concernées, c'est le délégué qui est destinataire de la notification (ou son délégué si lui-même a délégué...).

Lorsqu'un message est envoyé par la règle à un destinataire, son adresse de messagerie apparaît dans ce champ.

Ce numéro de chrono est attribué pour chaque ligne traitée (il y en a donc plusieurs lorsqu'on a des Workflow de type en-tête/ligne avec des regroupements).

Lorsqu'un modèle de données est attaché à la règle, et que ce modèle définit une société courante en fonction du contexte (que ce soit directement ou par l'intermédiaire d'un site), on stocke dans l'événement la société correspondante.

Cette société peut être utilisée (mais ce n'est pas obligatoire) pour définir la règle d'affectation qui déterminera les destinataires de la notification.

Ce champ vaut Non si l'utilisateur est le premier destinataire de la notification. Il vaut Oui si l'utilisateur reçoit la notification en tant que délégué non remplaçant (options Tous ou Cascade), et que par ailleurs il a pouvoir de signer (s'il n'a pas de pouvoir de signer, la notification n'apparaît pas dans le plan de travail.

Il faut noter que si ce champ vaut Oui, au moins une autre ligne portant le même numéro de chrono avec la valeur Non existe dans la table stockant les données du plan de travail (il peut y avoir d'autres lignes avec le même numéro de chrono et cet indicateur égal à Oui si plusieurs délégués avec pouvoir de signature existent). La première signature sur l'une des lignes concernées met automatiquement à jour l'ensemble des lignes portant le même numéro de chrono en les considérant comme signées.

Ce champ vaut Oui si un message a été envoyé lors de l'exécution de la règle.

Définit l'émetteur de la notification, c'est-à-dire l'utilisateur dont l'action a déclenché le Workflow. Dans un Workflow de type Signature, l'émetteur est celui qui a signé la notification précédente. Dans un Workflow autre, l'émetteur est l'utilisateur dont l'action déclenche l'envoi de la notification.

Lorsqu'une ligne du planb de travail a été signée par le déclenchement d'un lien http depuis un message, ce champ stocke l'adresse de messagerie de l'utilisateur ayant signé de la sorte.

Correspond à la date système (telle qu'elle est connue du serveur de traitement) au moment de l'exécution de l'événement de Workflow.

Correspond à l'heure système (telle qu'elle est connue du serveur de traitement) au moment de l'exécution de l'événement de Workflow.

Correspond à la valeur du champ Nature de Workflow défini sur l'événement déclencheur. Ce peut être un critère commode pour trier les lignes, pour les filtrer, ou pour les dispatcher sur différents onglets du plan de travail.

Contient le texte évalué à partir de la rubrique Texte suivi définie dans l'onglet Suivi de la règle; usuellement, on y paramètre un commentaire expliquant les circonstances du déclenchement de Workflow.

Définit le type d'événement de la règle de Workflow à l'origine de la ligne de notification dans le plan de travail.

Correspond au code événement à l'origine du Workflow, c'est-à-dire au code :

• de l'objet dans le cas d'un Workflow objet.
• de l'état dans le cas d'un Workflow de type impression.
• du modèle dans la cas d'un import ou d'un export.
• de la fonction dans le cas d'une entrée sur fonction.
• de la règle de Workflow ayant déclenché la demande de signature dans le cas d'une signature.
• du code identifiant le Workflow divers dans ce cas.

Identifie la règle de Workflow dont l'exécution a envoyé la notification.

Contient le code opération dans le contexte déclenchant :

• pour un événement objet, ce peut être C (création), M (modification... ou le code du bouton.
• pour un événement signature, le code de la règle à l'origine de la signature
• pour un import/export, les combinaisons I/E et D/F(import/export, début/fin), par exemple ID.
• pour une entrée sur fonction, le champ est vide.
• pour une impression, il est égal à C.
• pour la fin d'une tâche batch, il vaut "0" si la tâche s'est terminée sans erreur; sinon, on y trouve le numéro de statut suivi du début du message d'erreur.

Ce champ contient la date à laquelle le Workflow devra avoir été signé. Il est égal à la date de déclenchement si aucun processus de signature n'a été mis en oeuvre, ou si aucune date limite n'a été définie.

En effet, lorsque l'événement de Workflow suppose une signature :

• on peut gérer une date limite de Workflow (via la rubrique qui donne une expression calculée correspondante dans le paramétrage du Workflow).
• on peut ensuite déclencher des relances basées sur cette date limite. Ces relances se font par des règles de Worflow batch nommées WRKREM1, WRKREM2, et WRKREM2E.

Lorsqu'une relance de ce type est faite :

• on incrémente le champ Nombre de relances, ce qui permet alors de savoir combien de fois la signature a été relancée.
• on met à jour le champ Dernière date de relance, ce qui permet de connaître la date à laquelle la dernière signatiure a eu lieu.

Si ces règles batch ne sont pas utilisées, et si aucune autre règle n'a été définie pour mouvementer ces champs, le nombre de relance reste égal à 0 et la date de relance reste vide, car aucun traitement standard du Workflow ne modifie cette valeur.

Ce champ définit le niveau de signature correspondant à la notification de la ligne. Les valeurs suivantes, définies par le menu local 2922 sont possibles :

• A lire : un accusé de lecture est demandée, mais la notification n'a pas encore été lue.
• A signer : une signature est demandée, mais la notification n'a pas encore été signée.
• Lu : un accusé de lecture a été demandé, il a été saisi.
• Signé : une signature a été demandée, elle a été accordée.
• Annulé : une signature a été accordée, puis elle a fait l'objet d'une annulation de signature.

Ce champ est vide tant que l'événement n'a pas été signé. S'il l'a été, on y trouve le code réponse qui a été saisi, tel qu'il est défini dans la table diverse numéro 54.

Lorsqu'une ligne du tableau des notifications a été signée, on voit apparaître ici le code de l'utilisateur qui a signé. Il ne s'agit pas forcément du destinataire d'origine, puisqu'un autre utilisateur peut avoir pouvoir pour signer.

Lorsqu'un message incluant une demande de suivi par activation d'un lien http a été envoyé, ce champ permet de connaître l'adresse de messagerie du destinataire.

Si la notification de Workflow suppose un suivi (simple visa ou signature), ce champ permet de savoir à quelle date le suivi a été fait (il reste vide tant qu'il n'a pas été réalisé).

Si la notification de Workflow suppose un suivi (simple visa ou signature), ce champ permet de savoir à quelle heure le suivi a été fait (il reste vide tant qu'il n'a pas été réalisé).

Contient l'intitulé associé au code code motif saisi à la signature de la règle, lorsque cette saisie est possible au moment de la signature. Ceci suppose que l'on définisse une liste de motifs possibles par l'intermédiaire d'un numéro de table diverse sur la ligne de signature correspondante.

Contient le code motif saisi à la signature de la règle, lorsque cette saisie est possible au moment de la signature. Ceci suppose que l'on définisse une liste de motifs possibles par l'intermédiaire d'un numéro de table diverse sur la ligne de signature correspondante.

Lorsqu'une saisie de code motif a été prévue à la signature de la règle, on trouve dans ce champ le numéro de table diverse qui définit les motifs possibles sur la ligne de signature correspondante.

Dans le cas d'un Workflow objet, on retrouve dans ce champ la clé de l'objet (c'est le champ Clé déclenchante d'origine). Dans le cas d'un Workflow de type signature, on retrouve dans ce champ le numéro chrono à l'origine de la signature. Dans tous les autres cas, cette zone n'est pas renseignée.

Ce champ technique contient le code de la table déclenchante et le code de la clé correspondante, exactement de la même façon que pour le champ Identifiant ligne. Par contre, en cas d'événement de type signature, il reste vide, c'est-à-dire qu'il n'est pas transmis depuis la notification d'origine.

Lorsqu'une icône de retour est associée au Workflow, ce champ contient le nom de la fonction sur laquelle le retour se fait. Si la fonction est de type objet, on retrouve ensuite, séparé par un "/" de la table, la clé correspondante (les segments de clés, pour une clé en plusieurs parties, étant séparés par "~").

Ce champ technique contient, dans l'ordre, le nom de la table dans laquelle se trouve l'événement déclenchant d'origine, suivie de la clé courante liée au groupe qui a provoqué le déclenchement. Le séparateur entre table et clé est "/", le séparateur entre les segments de la clé (lorsqu'elle est composée de plusieurs champs) est "~".

Le contenu est défini de la façon suivante :

• dans le cas d'un événement de type Signature, on reprend le contenu de la notification d'origine.
• dans le cas où l'événement est de type Objet, on reprend la table principale de l'objet si elle peut être déterminée (ce qui signifie que rien n'est renseigné si c'est un Workflow générique avec un code objet vide). La clé correspond à la clé courante lors du déclenchement Workflow.
• dans tous les autres cas, la table est définie uniquement si un modèle de données est attaché au Workflow. Dans ce cas, c'est la table principale qui est renvoyée. La clé correspond à l'enregistrement courant lors du déclenchement.

Ce numéro chrono est renseigné uniquement sur les notifications liées à un événement de type Signature; il permet de connaître le numéro chronologique de l'événement d'origine, celui dont la signature a déclenché la ligne courante.

Ce champ n'est renseigné que sur les lignes associées à un événement de type Signature. Il permet de connaître le destinataire du Workflow d'origine (celui qui a effectivement reçu la notification après application éventuelle des règles de délégation : ce n'est pas forcément celui qui a signé).

Ce champ contient la date à laquelle la dernière relance de signature a été faite sur la notification. Il n'est pas renseigné si aucun processus de signature n'a été mis en oeuvre.

En effet, lorsque l'événement de Workflow suppose une signature :

• on peut gérer une date limite de Workflow (via la rubrique qui donne une expression calculée correspondante dans le paramétrage du Workflow).
• on peut ensuite déclencher des relances basées sur cette date limite. Ces relances se font par des règles de Worflow batch nommées WRKREM1, WRKREM2, et WRKREM2E.

Lorsqu'une relance de ce type est faite :

• on incrémente le champ Nombre de relances, ce qui permet alors de savoir combien de fois la signature a été relancée.
• on met à jour le champ Dernière date de relance, ce qui permet de connaître la date à laquelle la dernière signatiure a eu lieu.

Si ces règles batch ne sont pas utilisées, et si aucune autre règle n'a été définie pour mouvementer ces champs, le nombre de relance reste égal à 0 et la date de relance reste vide, car aucun traitement standard du Workflow ne modifie cette valeur.

Ce champ contient le compte du nombre de relances de signatures faites sur l'événement Workflow.

En effet, lorsque l'événement de Workflow suppose une signature :

• on peut gérer une date limite de Workflow (via la rubrique qui donne une expression calculée correspondante dans le paramétrage du Workflow).
• on peut ensuite déclencher des relances basées sur cette date limite. Ces relances se font par des règles de Worflow batch nommées WRKREM1, WRKREM2, et WRKREM2E.

Lorsqu'une relance de ce type est faite :

• on incrémente le champ Nombre de relances, ce qui permet alors de savoir combien de fois la signature a été relancée.
• on met à jour le champ Dernière date de relance, ce qui permet de connaître la date à laquelle la dernière signatiure a eu lieu.

Si ces règles batch ne sont pas utilisées, et si aucune autre règle n'a été définie pour mouvementer ces champs, le nombre de relance reste égal à 0 et la date de relance reste vide, car aucun traitement standard du Workflow ne modifie cette valeur.

Ce champ correspond au niveau de signature, lorsque des événements de signature s'enchaînent :

• il vaut 0 sur l'événement d'origine.
• il vaut 1 sur l'événement déclenché par la première signature.
• à chaque événement qui s'enchaîne, il est incrémenté de 1.

La variable LEVSIG correspondante est fréquemment utilisée dans les règles de Workflow lorsque la règle d'affectation de l'événement d'origine donne l'ensemble des signataires (1 à 9 maximum). Il suffit alors, dans l'événement d'origine comme dans les événements de signature qui s'enchaînent, de donner comme formule de destinataire USER(LEVSIG+1) pour avoir l'utilisateur numéro N dans la liste. Ceci permet notamment d'avoir des règles de signature récursives, exécutées tant qu'il reste des signataires.

Lorsqu'un Workflow envoie un message avec une icône de branchement, le contexte de connexion (dossier, serveur, service, fonction...) est défini sous forme d'un champ alphanumérique.

Ce champ technique contient ce contexte. Les différents segments de ce champ sont séparés par le caractère "/".

Identifie la clé à l'origine du circuit de Workflow. Cette clé, lorsqu'elle est composée de plusieurs parties, se présente comme une concaténation des parties de clés séparées par le caractère tilde (~).

Les valeurs de clé dépendent du contexte :

• sur un Workflow objet, il s'agit de la clé de la fiche à l'origine du déclenchement.
• sur un Workflow manuel, il s'agit de la clé de la table principale sur laquelle s'appuie le modèle de données du Workflow.
• sur un Workflow sur import/export, sur une entrée dans une fonction, rien n'est renseigné dans cette zone.
• sur un Workflow sur édition, rien n'est renseigné si l'édition est lancée depuis une fonction d'impression (impression, ou impression par groupe). Par contre, si l'édition est lancée par Fichier/Impression ou Fichier/Liste depuis un objet, la clé de la fiche est renseignée dans cette zone.
• sur un Workflow de signature, on hérite de la clé de la fiche d'origine, stocké dans la ligne de suivi à l'origine de la signature.

Définit le nombre d'utilisateurs renvoyés par la règle d'affectation, lorsqu'il y en a une.

S'il n'y en a pas, mais que la règle est de type Signature, on hérite du nombre de signataires défini dans la règle d'origine.

Si aucun règle d'affectation n'existe, la valeur retournée est 0.

Lorsque le premier événement à l'origine d'un circuit de signature est un objet, ce champ identifie le code de l'objet. Dans les autres cas, il est vide.

Il est ensuite transmis aux différents événements de signature qui pourraient s'enchaîner au premier.

Définit le premier destinataire de l'événement de Workflow. En effet, un événement peut envoyer une notification à plusieurs séries de destinataires, chacun d'entre eux étant défini par une ligne dans le tableau des destinataires. Ce champ represente le destinataire évalué par la première ligne si l'option de délégation est Non, Tous, ou Cascade. Si l'option est Le premier libre, et si l'utilisateur n'est effectivement pas présent, et a donné délégation, on retrouve dans le champ l'utilisateur délégué.

Ce champ fait partie d'un ensemble de quinze champs génériques permettant de stocker des valeurs contextuelles évaluées au moment du déclenchement du Workflow à partir de formules saisies dans le tableau nommé Contexte de l'onglet Suivi du Workflow.

Les valeur stockées dans ce tableau peuvent être utilisées :

• pour transmettre à un événement de type Signature des informations utiles au traitement de la suite du processus.
• pour faire apparaître des informations utiles dans le moniteur de workflow. Dans ce cas, en paramétrage de la transaction, on peut leur donner un titre particulier plus parlant.

Permet de définir les signataires successifs, lorsqu'une règle d'affectation de destinataires renvoie N signataires pour la règle de Workflow. Cette information est notamment utilisée pour permettre de gérer correctement les annulations de signature.

Sur les événements de type Signature pour lesquels aucune règle d'affectation n'est définie, on retrouve les signataires associés à la règle déclenchante. Ainsi, lorsque N signataires en cascade ont été définis dans la règle d'origine, et que toutes les règles de signature qui suivent n'ont pas de règle d'affectation, on peut connaître le circuit complet de signature à chaque niveau.

Il est à noter que l'on voit apparaître ici les utilisateurs définis par la règle avant l'application éventuelle de règles de délégation. Ainsi, par exemple, si le premier destinataire de la règle de signature est absent, et qu'il est remplacé, on verra dans le champ Signataire 1  le signataire d'origine, alors que dans le champ Premier destinataire, on trouvera le remplaçant à qui la demande de signature a effectivement été envoyée.