Project

General

Profile

Support #26215

Saisie par le guichet : pouvoir contrôler l'affichage des champs dans le résumé sur le FO d'une demande saisie en BO

Added by Stéphane Laget 11 months ago. Updated 11 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
07 Sep 2018
Due date:
% Done:

0%

Patch proposed:
No
Planning:
No
Demande du club utilisateur:
No

Description

L'affichage du résumé de la demande dans le FO affiche tous les champs qui ont été saisis.
Avec un fonctionement avec le guichet (ou saisie back-office), cela pose problème à l'usage.

Serait-il possible de contrôler l'affichage des champs dans le résumé de la demande avec le champ "condition" (en mettant par exemple la condition is_in_backoffice) ?

Cas rencontré à Grenoble :
Un agent saisit une demande via welco suite à un appel téléphonique d'un usager.
Dans le formulaire welco, certains champs sont réservés aux agents et sont inclus directement dans le formulaire (origine de la demande, marquée la demande comme traitée, type de suivi...).
Une fois la demande saisie par l'agent, l'usager peut suivre sa demande sur le FO grâce au code de suivi qui lui est envoyé.
Il se trouve que dans le résumé de la demande, il voit tous les champs saisis, y compris des champs réservés à l'administration.

D'aucuns pourraient suggérer : il suffit de mettre ces champs dans le WF via un formulaiore de backoffice.
Mais non, car les agents à Grenoble ont lourdement insisté pour ne pas multiplier les étapes de saisie (notamment le nb de pages), et souhaitent donc saisir ces champs dans le formulaire, au moment où ils le remplissent avec l'usager au téléphone.

History

#1 Updated by Thomas Noël 11 months ago

Stéphane Laget a écrit :

Serait-il possible de contrôler l'affichage des champs dans le résumé de la demande avec le champ "condition" (en mettant par exemple la condition is_in_backoffice) ?

Les conditions d'affichage sur les champs pilotent l'affichage du champ lors de la saisie du formulaire. Il n'y a pas de condition sur l'affichage du champ par la suite : tous les champs saisis font partie de la demande et sont affichés dans le résumé de celle-ci (et on ne peut pas ré-utiliser la notion de condition d'affichage à ce moment).

Quant aux données de traitement, il s'agit comme leur nom l'indique, de données de traitement, et donc ne peuvent être gérées que dans le workflow.

Bref en l'état actuel il n'y a pas de possibilité dans Publik pour ce qui est imaginé ici : c'est un concept vraiment nouveau qui est demandé, qui sort du cadre "la demande" / "son traitement".

#2 Updated by Stéphane Laget 11 months ago

Lorsque l'on aborde une réflexion multi-canale (mode guichet, saisie BO, courrier (soyons fous.)..), c'est pourtant un point important.
La personne qui saisie est différente de la personne qui suit la demande sur le FO.
Cependant (tu noteras mon effort de ne pas employer le "en même temps" macronien), est-ce que le fait de prendre en compte les conditions sur les champs dans le réumé de la demande sur le FO a un impact énorme ?
Il y aura-t-il beaucoup d'effets collatéraux non désirés ?

#3 Updated by Frédéric Péters 11 months ago

Il y aura-t-il beaucoup d'effets collatéraux non désirés ?

Oui. (imaginons par exemple une page conditionnée par la disponibilité de places)

~~

Mais peut-on imaginer un truc très simple, comme on a "afficher dans le listing", étendre cette option façon :

reprendre ce champ dans :
  [x] listing backoffice [ ] résumé frontoffice [x] résumé backoffice

#4 Updated by Thomas Noël 11 months ago

Moi j'ai quand même du mal à comprendre... Si ça fait partie de la demande, pourquoi cacher la chose à l'usager ? Après tout, c'est lui qui a donné l'information... Tu as un exemple qui me fera changer d'avis ? ;)

#5 Updated by Stéphane Laget 11 months ago

En l'espèce (Grenoble) :
J'ai par ex/ un champ "marquée comme traitée" qui a pour effet de directement fermer la demande en "traitée" dans le WF lorsqu'il est égal à Oui, essentiellement parce que l'information demandée a été donnée au moment de la saisie de la saisie du formulaire.
Souvent la demande doit être "traitée" (ce qui justifie son suivi et donc j'ai dans l'historique un champ : "marquée comme traitée = non" ce qui fait bizarre pour l'usager.

On peut aussi avoir des qualifications "techniques" en fonction de ce que nous raconte l'usager et que l'administration ne veut pas exposer à l'usager (par ex/ Plainte sur la TOEM), si ces champs sont remplis via le formulaire, ils sont alors vus par l'usager.
La solution consistant à les saisir via une étape du WF est coûteuse pour l'agent (temps d'enregistrement, clic supplémentaire...).

#6 Updated by Thomas Noël 11 months ago

Stéphane Laget a écrit :

En l'espèce (Grenoble) :
J'ai par ex/ un champ "marquée comme traitée" qui a pour effet de directement fermer la demande en "traitée" dans le WF lorsqu'il est égal à Oui, essentiellement parce que l'information demandée a été donnée au moment de la saisie de la saisie du formulaire.
Souvent la demande doit être "traitée" (ce qui justifie son suivi et donc j'ai dans l'historique un champ : "marquée comme traitée = non" ce qui fait bizarre pour l'usager.

Il suffit de positiver la chose et ça passe, "Cette demande nécessite un traitement particulier ultérieur : oui/non" et hop.

On peut aussi avoir des qualifications "techniques" en fonction de ce que nous raconte l'usager et que l'administration ne veut pas exposer à l'usager (par ex/ Plainte sur la TOEM), si ces champs sont remplis via le formulaire, ils sont alors vus par l'usager.
La solution consistant à les saisir via une étape du WF est coûteuse pour l'agent (temps d'enregistrement, clic supplémentaire...).

Ok, pigé l'idée.

Reste que c'est quand même un détournement des principes, où une partie du traitement se trouve en fait dans les données de la demande... et un jour on risque de s'en mordre les doigts...

Je ne suis pas très chaud pour bricoler, je serais pour plutôt essayer de creuser une simplification de la saisie. Par exemple les champs conditionnels & co, d'accélérer la saisie de la demande proprement dite (avec l'objectif "tout sur une seule page")...

S'il fallait aller vers une vraie solution, pour moi, ça serait de permettre la saisie de certaines données de traitement, quand on est dans une saisie backoffice.

#7 Updated by Stéphane Laget 11 months ago

je plussoie

#8 Updated by Stéphane Laget 11 months ago

... Mais la solution proposée par Fred parait plus simple à mettre en oeuvre et répond au besoin.

#9 Updated by Pierre Cros 11 months ago

De mon côté je suis vraiment réticent à l'idée d'ajouter une option sur TOUS les champs pour couvrir une exigence que je n'ai jamais rencontrée et qui me semble apporter de la confusion.

Ne pas saisir dans le formulaire des choses que le demandeur ne doit pas voir, c'est facile à comprendre et ça m'irait assez bien que ça reste comme ça.

Si les agents de Grenoble veulent saisir des infos de traitement dans le formulaire au lieu de le faire là où ça doit être fait (dans l'interface de traitement), ils doivent accepter que les infos soient affichées au demandeur (il me semble possible de travailler pour que ce qui est affiché ne soit pas trop perturbant pour le demandeur).

#10 Updated by Stéphane Laget 11 months ago

Le problème n'est pas tellement Grenoble, on leur a expliqué que c'était comme ça, et ils s'y ferront.
Mais pour autant leur argument reste valable.
C'est la prise en compte des spécificités du mode multi-canal qui est en jeu ici, avec l'acceptation du fait que lorsqu'une demande est saisie par un agent pour le compte d'un usager ce n'est pas la même chose que lorsque c'est l'usager qui saisit lui-même la demande.
Aujourd'hui les CT fonctionnant en mode multi-canal avec Publik ne sont pas si nombreuses que ça, mais cela va changer.

#11 Updated by Pierre Cros 11 months ago

Le samedi 08 septembre 2018 à 18:17 +0200, a écrit :

Aujourd'hui les CT fonctionnant en mode multi-canal avec Publik ne sont pas si nombreuses que ça, mais cela va changer.

C'est pas faux, je comprends mieux le sens de la demande. Reste que ça m'embête de faire des traitements dans le formulaire.

Also available in: Atom PDF