Workflow Designer - Conditionner l'apposition d'un timbre en fonction de la décision sélectionnée dans une tâche de workflow
Contexte métier
Dans de nombreux processus de validation, notamment la validation de factures fournisseurs, une même tâche de workflow peut proposer plusieurs décisions à l'utilisateur :
- Valider
- Refuser
- Mettre en attente
- Retourner au demandeur
- Demander un complément d'information
- etc.
Actuellement, l'apposition de timbres dans le workflow ne permet pas de discriminer simplement les décisions concernées. Le comportement s'applique au niveau de l'activité ou du workflow et non à une décision particulière.
Cette limitation conduit les intégrateurs et les clients à mettre en œuvre des développements spécifiques afin de n'appliquer les timbres que sur certaines décisions métier.
Limites rencontrées
Dans notre cas, seuls les choix "Valider" et "Refuser" doivent provoquer l'apposition d'un timbre contenant les informations de validation.
Pour répondre à ce besoin, nous avons dû développer :
- des traitements spécifiques de collecte des décisions ;
- des tables d'historisation intermédiaires ;
- des mécanismes de rapprochement entre événements de workflow et données de timbrage.
Cette approche augmente :
- la complexité de la solution ;
- les coûts de maintenance ;
- les risques d'incohérences ;
- la sensibilité aux évolutions de la plateforme DocuWare.
Évolution souhaitée
Permettre de configurer l'apposition d'un timbre en fonction de la décision sélectionnée dans une tâche de workflow.
Exemple de paramétrage attendu
| Décision | Apposer un timbre |
| Valider | Oui |
| Refuser | Oui |
| En attente | Non |
| Retour au demandeur | Non |
| Demande d'information | Non |
Le paramétrage pourrait être réalisé :
- directement dans la définition de la tâche ;
- dans la configuration d'apposition du timbre ;
- via une condition exploitant la décision sélectionnée par l'utilisateur.
Bénéfices attendus
- Réduction significative des développements spécifiques.
- Utilisation renforcée des fonctionnalités natives DocuWare.
- Amélioration de la fiabilité des processus documentaires.
- Réduction des risques lors des montées de version.
- Simplification de l'administration des workflows.
- Réponse à un besoin récurrent rencontré dans les circuits de validation comportant plusieurs issues possibles.
Cas d'usage illustratif
Workflow : Validation de facture fournisseur
Étape : Validation 1
Décisions possibles :
- Valider
- Refuser
- Mettre en attente
Comportement attendu :
- Si la décision est Valider → apposition du timbre de validation.
- Si la décision est Refuser → apposition du timbre de refus.
- Si la décision est Mettre en attente → aucun timbre.
Workflow : Validation 2
Décisions possibles :
- Valider
- Refuser
- Retour au demandeur
Comportement attendu :
- Si la décision est Valider → apposition du timbre de validation.
- Si la décision est Refuser → apposition du timbre de refus.
- Si la décision est Retour au demandeur → aucun timbre.
Priorité métier
Cette évolution permettrait de supprimer des mécanismes compensatoires actuellement nécessaires chez plusieurs clients et contribuerait à rendre les workflows de validation plus simples, plus robustes et plus facilement maintenables sur le long terme.
Les développements spécifiques mis en œuvre aujourd'hui pour contourner cette limitation nécessitent notamment la mise en place de contrôleurs dédiés, de tables d'historisation intermédiaires et de traitements de rapprochement destinés à reconstruire l'historique des décisions devant être estampillées.
Une prise en charge native de ce besoin par DocuWare permettrait :
- d'alléger l'architecture globale des solutions ;
- de réduire les risques d'incohérences de données ;
- d'améliorer la traçabilité des validations ;
- de limiter les impacts lors des évolutions futures de la plateforme.
Thank you for sharing your idea with us. We have received it, and our product team will review it soon. Votes and comments from other users help us understand how much it matters, so feel free to share it with your colleagues.