GU plans-reseaux.ch (public)

Pour des raisons de sécurité, livrer plus d'information sur le client dans les commandes (p. ex. si c'est la première fois qu'il commande chez un fournisseur).

Cette fonctionnalité pourrait avoir des développements à la fois sur la plateforme viageo.ch et dans l'application Extract.

• Si l'utilisateur n'a jamais fait une commande valide (= acceptée avec livraison de données) chez un organisme fournisseur ou si celle-ci date de plus de 5 ans (historique max de viageo), un message d'alerte au sommet de la vue fournisseur d'une commande https://viageo.ch/diffuser/traitement/{order-id} indique que l'utilisateur n'a jamais été livré par le fournisseur.
• Dans le cas de délégation, la vue fournisseur est une vue d'un délégataire avec potentiellement des commandes avec des produits chez plusieurs fournisseurs délégants. Dans ce cas, si au moins une commande valide a déjà été faite par le client chez au moins 1 fournisseur délégant, pas de message d'alerte.
• Un nouveau paramètre est exposé dans le service web easySDI pour Extract : Parameters.LAST_ORDER : date de la dernière commande, "none" si aucune ou commande datant de plus de 5 ans (historique max de viageo.ch)

Question ouverte
* Faut-il faire un contrôle sur le client ou sur l'organisme ? -> sur le client ! (si un client d'un organisme est "accepté", les autres clients du même organisme ne le sont pas)

Maquette

Dans Extract (sera conceptualisé complétement avec le GU d'Extract dans GitHub, quelques pistes ci-dessous)

Le but est de facilité la gestion des clients et des organismes qui commandent, notamment de rediriger le processus selon qui commande (validation, demande de plus d'info, etc.). Certain intégrateurs le font déjà, mais à la main avec une liste de GUID d'organisme et/ou client dans les règles de correspondance.

Variante 1

• Rajouter dans l'édition des règles de correspondance entre connecteur et traitement deux champs "organisme" et "client"
• Ils limitent la correspondance à l'organisme OU au client qui commande (opérateur OR, permet d'avoir des organismes et des clients)
• Ajouter une aide à la saisie pour ces deux champs : on peut chercher par nom -> drop-down list -> on peut sélectionner un ou plusieurs éléments à ajouter, on peut facilement supprimer un élément de la liste
• Si performance acceptable, l'aide à la saisie s'appuie sur des requêtes faites sur la table requests qui contient le prénom et nom des clients et leur GUID ainsi que le nom des organisme et leur GUID.
• Si performance pas acceptable, rajouter une table client et une table organisme qui sont peuplées à chaque nouvelle commande

Variante 2

• Modifier la tâche "validation opérateur" en rajoutant une condition. La tâche est exécutée seulement si la condition est remplie.
• La condition est la même que pour la variante 1, une liste d'organismes et de clients
• Leur mode de saisie est le même que pour la variante 1

Variante 3

• Ajouter la possibilité de créer des groupes de client
• Un groupe peut contenir des organismes et/ou des clients individuels
• Avec cette variante, dans les variantes 1 et 2, ce sont des groupes de clients qui sont saisis et non plus directement des organismes ou des clients.