Document de release de la version I3

   Ce document présente les évolutions survenues sur l'application Cegid XRP Ultimate Déplacements et Frais professionnels en I3.

      Afficher / Masquer le détail                                                   Format PDF

   La définition d'un modèle s'appuie sur le moteur de règles intégré au produit. Il a été enrichi de nouveaux opérateurs permettant de définir les différents composants des modèles.
La création des modèles est pris en charge par les administrateurs de la solution et s'effectue au travers du mnémonique GFREGM. Cet écran liste lors de son ouverture les éléments déjà présents.
Lors de la création d'un nouveau modèle, son code, son libellé et l'entité à laquelle il est destiné, doivent nécessairement être validés avant de lui associer des composants.

   Pour les collaborateurs, les modèles deviennent une nouvelle alternative pour la création d'une demande de déplacement, accessible uniquement depuis le menu "Nouveau déplacement" du portail.

   La sélection d'un modèle déclenche le processus de saisie.
La première étape, qui consiste à compléter, si nécessaire, l'en-tête de la demande. Elle se réalise au travers de l'écran éventuellement défini pour le modèle. Si ce n'est pas le cas, le système ouvre l'écran "par défaut" de saisie d'un en-tête de déplacement.
Après la validation de cette première étape, le système propose une liste des services, en tenant compte de la définition du modèle.
Une fois la sélection terminée, le système invite l'utilisateur à compléter les données pour chaque élément choisi.
La dernière étape, qui s'enchaîne après la finalisation de la saisie du détail des services, présente la synthèse de la demande de déplacement.
L'utilisateur peut la compléter et/ou la modifier avant de la soumettre.

GFREGM - Modèles de notes de frais et déplacements (Transaction QFIREGM)
GFAREM - Eléments d'un modèle (Transaction QFIAREM)

   Pour rendre cette option du menu "Nouveau déplacement" accessible, la valeur testée 1 de l'occurrence OPTMODDDP du paramètre AFFQDF doit être positionnée à "A".

   Depuis l'écran GFDNV, il est possible de définir tous les niveaux de contrôle que les éléments d'une classe de frais doivent franchir.
La définition d'un niveau détermine :
- Le type de contrôle (validation globale ou partielle des éléments).

   - Le numéro d'étape positionné sur un élément refusé.

   - Si lorsque l'élément a atteint le dernier niveau, les traitements après validation sont exécutés.

   - Le procédé d'affectation du ou des approbateurs pour le niveau. A ce jour, six possibilités sont disponibles pour déterminer l'origine des approbateurs :

             - Utilisateur lié au groupe de l'intervenant : l'approbateur est lu dans le texte des occurrences du paramètre GRPQTINT. L'occurrence étant celle présente sur la fiche de l'intervenant.

             - Droit de validation : les approbateurs sont affectés en parcourant les droits de validation se rapportant au collaborateur et dont l'identifiant est saisi pour le niveau.

             - Analytique des lignes : le système affecte comme approbateur l'utilisateur associé à un des gestionnaires présents sur un des axes analytiques. Il est donc nécessaire de préciser l'axe analytique contenant le gestionnaire ainsi que le n° du gestionnaire à lire. En effet, il est possible de saisir de 1 à 6 gestionnaires sur un même axe.

             - Analytique de l'intervenant : le système affecte comme approbateur l'utilisateur associé à un des gestionnaires présents sur l'axe analytique de la fiche intervenant. Comme précédemment, il faut préciser le n° du gestionnaire à lire, puisqu'un même axe peut comporter jusqu'à 6 gestionnaires.

             - Analytique de l'intervenant valide pour la période de l'élément : le principe de cette option est identique à la précédente. La différence réside dans la lecture de l'axe analytique qui s'effectue dans le mnémonique GAIS en remplacement de la fiche intervenant.

             - Recherche avancée : cette option consiste à exécuter une requête saisie depuis le mnémonique GFRQC, dont le résultat est une liste d'un ou plusieurs utilisateurs représentant les approbateurs du niveau. La saisie des requêtes est réservée à des utilisateurs avisés, ayant une connaissance du langage SQL et du schéma de la base de données.

   De plus, cette définition intègre également, l'envoi au collaborateur, via un WIM, du compte-rendu du contrôle, ainsi que l'alerte, d'un nouvel élément à contrôler destinée aux approbateurs du niveau suivant.

   Lors de l'enregistrement d'un niveau, le système crée en arrière-plan une règle dont l'objectif est d'affecter les approbateurs de chaque niveau. L'identifiant de cette règle est composé en concaténant la classe, l'établissement et le n° du niveau séparés par le caractère "-". La génération des approbateurs est matérialisée par une étape, associée à la règle, dont les caractéristiques sont déterminées suivant le procédé d'affectation utilisé pour le niveau.

   De plus, il est possible de conditionner la génération des approbateurs, en testant la valeur des données de l'élément soumis. Le résultat des tests déclenche ou non l'exécution de l'étape d'affectation des approbateurs. Ce principe permet de rendre optionnel un niveau de contrôle.

   Exemple :
L'élément doit passer un second niveau de validation uniquement si le déplacement s'effectue à l'étranger. Pour cela, il est nécessaire de tester le critère de l'élément qui remonte cette information. Si le résultat du test indique que c'est une mission étrangère, alors les approbateurs de ce niveau sont générés.
Un mnémonique dédié à l'ajout de condition (CFRCAA), a été créé. Il est accessible en synchronisation depuis le niveau de validation.

   Chacune des règles est ensuite déclenchée lors de la soumission d'un élément. Leur exécution alimente la structure des approbateurs liée à l'élément soumis.
Pour chaque ligne de données, on trouve l'identifiant de l'élément soumis, le niveau d'approbation, l'approbateur, le statut et la date du contrôle ainsi que l'identifiant de l'étape ayant généré la ligne. Le statut est positionné à la valeur "TODO" (à réaliser).

   L'élément est désormais dans le flux de validation. Ce sont donc les approbateurs de chaque niveau qui interviennent et font évoluer le statut. En effet, lorsqu'un des approbateurs d'un niveau valide le résultat de son contrôle, le statut de chaque ligne de données pour ce niveau de validation passe automatiquement à "DONE" (réalisé). La date du contrôle est mise à jour uniquement sur la ligne de données concernant l'approbateur connecté.

GFDNV - Niveaux d'approbation des classes de frais (Transaction QFIDNV)
GFDVA - Droits de validation (Transaction QFIDVA)
CKFVALN - Contrôle des notes de frais
CKFVALD - Contrôle des déplacements

   Pour utiliser ce nouveau principe, il est nécessaire de revoir le flux des classes. En effet, désormais une seule étape de validation est nécessaire. Le mnémonique associé doit obligatoirement être CKFVALN dans le cas où la classe représente des notes de frais et CKFVALD dans le cas des demandes de déplacements.
La modification des étapes peut également engendrer une modification des groupes d'étapes.
De plus, si la notion de droits de validation est utilisée pour déterminer les approbateurs d'un niveau, ils doivent être définis en amont de la création des niveaux.

   Il est également nécessaire d'exécuter le traitement TFINI en cochant l'option "Paramétrage des droits par mnémonique" qui prend en charge la création du paramétrage pour ces deux mnémoniques.

   Afin de permettre un accès simplifié à l'ensemble des documents liés à un élément et améliorer leur visualisation de nouveaux conteneurs sont mis à disposition.
En effet, et peut-être plus particulièrement dans le contexte des notes de frais, il peut s'avérer utile de pouvoir rapidement consulter les justificatifs.

   Deux nouveaux conteneurs ont été mis à disposition. Un dédié à la validation des notes de frais et le second dédié à la validation des demandes de déplacements.

   La partie de gauche est divisée en 2 panneaux.
Le premier contient la liste de tous les éléments que l'utilisateur connecté doit contrôler.
Le second est une synthèse de l'élément sélectionné dans cette liste à partir de laquelle l'approbateur positionnera le statut approprié pour chacun des éléments.

   La partie de droite est composée différemment selon que l'on traite des notes de frais ou des demandes de déplacements.

   Pour les notes de frais, le conteneur propose :
- la liste de tous les justificatifs ;
- le détail de la dépense sélectionnée depuis la synthèse ;
- la liste des participants à une réception qui est alimentée seulement dans ce contexte de dépense.

   Pour les déplacements, le conteneur propose :
- la liste de tous les justificatifs ;
- le détail de la dépense sélectionnée depuis la synthèse ;
- la liste des participants à une réception. Elle est alimentée seulement dans ce contexte.

CKFVALN - Contrôle des notes de frais
CKFVALD - Contrôle des déplacements

   Ces mnémoniques sont également appelés depuis l'espace de validation du portail.
Lorsque le système de validation par niveaux est mis en place, il est impératif d'utiliser ces mnémoniques pour définir l'unique étape de validation présente dans le flux des classes de frais
Pour ces mnémoniques, il doit également exister un paramétrage indiquant qu'ils sont utilisés dans le cadre de la validation. Pour créer cette donnée, il est nécessaire d'exécuter le traitement TFINI avec l'option "Paramétrage des droits par mnémonique".

   Toute personnalisation des écrans présents dans ces conteneurs doit être réalisée directement depuis le conteneur. Cela permet d'avoir un design spécifique pour ce contexte d'utilisation.

   L'application mobile autorise désormais la modification de dépenses saisies depuis une version Web du module.

   Jusque-là, les frais saisis hors de l'application étaient visibles dans l'application au moment de la soumission.
Désormais, ils sont présents dans l'onglet "en cours" de l'écran d'accueil et peuvent être modifiés avant d'être soumis. Il existe toutefois une restriction. Ces dépenses, saisies hors de l'application, sont forcément associées à une note de frais. Il est impossible de modifier ce rattachement.

   Il est nécessaire de télécharger la nouvelle version de l'application depuis le store lié à votre device.
Il est également impératif d'avoir installé la version I3 de l'ERP qui contient également une partie de cette évolution.