Document de release de la version H1.01

   Ce document présente les évolutions survenues sur le module Qualiac® Déplacements et Frais professionnels en H1.01.

      Afficher / Masquer le détail                                                   Format PDF

   Aucune modification de paramétrage n'est nécessaire pour que le fonctionnement soit comme avant le passage de la release.

   Ce traitement permet d'annuler une note de frais (ou demande de déplacement) déjà comptabilisée ou ayant généré une commande d'achats ou de ventes. Afin de s'assurer que l'ensemble des conditions, permettant l'annulation, sont réunies, différents contrôles sont effectués sur les entités liées.
Une demande ou une note peut être annulée seulement si :
- la commande de ventes, à laquelle elle est liée, n'est ni expédiée, ni facturée ;
- la commande d'achats, à laquelle elle est liée, est également annulée ;
- aucune pièce associée à l'entité n'est déjà soldée ;
- elle ne comporte pas de lignes cumulées.
Pour une demande de déplacement, une vérification supplémentaire est effectuée. Afin d'être annulée, la demande ne doit pas être associée à une note de frais.

   Si l'annulation est réalisée, il peut s'avérer utile de prévenir les personnes qui sont en rapport avec cette entité. Pour les alerter, il est possible de paramétrer une requête WIM qui sera exécutée en fin de traitement et enverra un mail aux personnes concernées.

TFANN - Annulation des notes de frais (Transaction QFTANN)

   Il faut ajouter l'étape au flux de la classe de frais traitée.

   La première action du traitement est de rechercher la prochaine étape de validation du flux, que l'entité traitée doit franchir.

   Si l'option "validation pour soi-même" est soumise, le traitement vérifie :
- que l'utilisateur exécutant le traitement est le même que celui associé à l'intervenant présent sur l'entité traitée ;
- que cet utilisateur est autorisé à valider pour l'intervenant auquel il est associé.
Si ces deux critères sont vérifiés, l'entité peut franchir l'étape de validation suivante. Son étape est alors positionnée à l'étape de validation franchie.

    Si l'option "validation si pas de signataire" est soumise, le traitement vérifie l'existence d'un ou plusieurs signataires pour l'étape de validation trouvée en début de traitement. Si aucun signataire n'est défini, le traitement considère que l'entité n'a pas besoin d'être contrôlée, et son étape est positionnée à l'étape de validation franchie.

   Pour illustrer ces options, prenons l'exemple d'un flux avec les étapes suivantes :
- Saisie de la note (étape n° 200) ;
- Soumission de la note (étape n° 250) ;
- Traitement de validation automatique (étape n° 300) ;
- Validation (étape n° 400) ;
- Transfert en comptabilité (étape n° 900).

   L'utilisateur USER1 est autorisé à valider les notes de l'intervenant associé à ce même utilisateur. Ce qui revient à dire que USER1 est autorisé à valider pour lui-même.
L'utilisateur USER1 est autorisé à valider les notes du collaborateur X lorsque celles-ci dépassent 200 EUR.

   Après avoir saisi une note le concernant, USER 1 la soumet. Le traitement de validation automatique est déclenché automatiquement en fonction de la définition du flux de la classe (étape suivante de l'étape de soumission). En s'appuyant sur le paramétrage des droits, le traitement retrouve les autorisations de USER1 et peut donc faire évoluer la note jusqu'à l'étape de validation.
Le collaborateur X saisit une note dont le montant est de 150 EUR. Le traitement de validation automatique est déclenché automatiquement en fonction de la définition du flux de la classe (étape suivante de l'étape de soumission). Le traitement ne retrouve pas de signataire pour cette note car son montant est inférieur au seuil précisé lors de la définition des droits. La note évolue alors jusqu'à l'étape de validation.

TFVAU - Validation automatique (Transaction TFVAU)

   Ce traitement doit être une étape du flux de la classe de frais. Cette étape doit obligatoirement avoir une étape précédente obligatoire qui doit correspondre soit au traitement de soumission soit à un mnémonique de validation.

   Il s'agit d'un traitement par étape, il permet d'effectuer une règle de contrôle ou de modification.
En fonction des besoins, il sera nécessaire d'associer la règle, via la définition d'exécution des règles, au moment opportun.
En effet, seules les règles dont le moment d'exécution est "traitement d'un en-tête" ou "traitement d'une ligne", sont sélectionnées par le traitement.
En fin de processus, l'étape de l'entité traitée est mise à jour. Toutefois, si la règle exécute un test qui s'avère incorrect et que dans ce cas une erreur est déclenchée, l'étape de l'entité traitée n'évolue pas.

TFXRG - Exécution d'une règle (Transaction QFTXRG)

   Il suffit d'ajouter une étape contenant le traitement dans le flux de la note de frais

   Il s'agit d'un traitement hors étape, il permet d'effectuer une règle de contrôle ou de modification.
Ce traitement peut être exécuté pour une note de frais (ou demande de déplacement) ou une liste.
En fonction des besoins, il sera nécessaire d'associer, via la définition d'exécution des règles, au moment opportun. En effet, seules les règles dont le moment d'exécution est traitement d'un en-tête ou traitement d'une ligne, sont sélectionnées.
Dans ce cas, le traitement ne fait aucune mise à jour d'étape de l'entité traitée.

TFXRE - Exécution d'une règle hors étape (Transaction QFTXRE)

   De nouvelles fonctionnalités ont été ajoutées aux règles.
Lorsqu'une demande de déplacement est transformée en note de frais, à partir d'une règle, il est désormais possible de sélectionner les lignes de la demande que l'on souhaite importer dans la note générée.
De même un nouvel opérateur permet de générer un complément de frais de type anomalie.

   L'opérateur "insérer un en-tête" associé aux étapes d'action, dont le principal objectif est de générer l'en-tête de la note de frais à partir des données présentes sur une demande de déplacement, permet désormais de sélectionner les lignes de la demande qui seront reprises sur la note de frais générée. Le critère de sélection des lignes est le type de paiement. Il doit être précisé dans la zone texte de l'opérande 1 de l'étape.

   Exemples :
- Si on ne souhaite pas importer de lignes, il faut saisir la valeur 'N' ;
- Si on souhaite importer uniquement les lignes dont le type de paiement est remboursé, alors on saisit 'R' dans le texte de l'opérande 1 ;
- Si on souhaite importer les lignes dont le type de paiement est avance (A) et remboursé (R) alors il faut saisir 'AR' dans le texte de l'opérande 1 ;
- Si on souhaite importer toutes les lignes quel que soit son type de paiement, alors on doit saisir '*' dans le texte de l'opérande 1.

   Les règles de contrôle et de modification (d'en-têtes et lignes) permettent d'insérer une anomalie au niveau de l'entité traitée (en-tête ou ligne). L'anomalie est insérée en tant que compléments de frais. Ces compléments de frais doivent avoir un type "anomalie" correspondant à une occurrence du paramètre TCDQFCDF, dont la valeur testée 1 vaut AG (anomalie générée).

   Les anomalies peuvent servir par exemple à identifier les demandes de déplacement soumises qui ne respectent pas la politique de voyage. Ainsi elles peuvent aiguiller le valideur dans son choix mais aussi être utilisées pour effectuer des statistiques.

   Au niveau de cette étape on doit saisir les 2 opérandes :
- Le premier est le type de complément à affecter, cela permet par exemple de répertorier plusieurs type d'anomalies ;
- Le second est la zone texte dont la valeur sera reprise dans les informations complémentaires de l'anomalie créée.

GFREG - Règles (Transaction QFIREG)
GFERP - Etapes (Transaction QFIERP)

   Import des lignes de frais
Si une règle de génération d'en-tête est déjà définie, cette dernière possède une étape qui effectue la création de ce nouvel en-tête. Si vous souhaitez ajouter l'import de certaines lignes, il faut modifier cette étape de création et lui préciser la valeur du type de paiement des lignes que vous désirez retrouver sur le nouvel en-tête.

   Le principe d'affectation des signataires exceptionnels s'appuie sur le système des règles existant. Les données d'une note ou d'une demande pourront être utilisées comme critère permettant de déterminer le ou les signataires qui seront alors liés à la note ou demande traitée, via une structure dédiée. A l'identique des natures de règles existantes, les règles d'affectation de signataires peuvent combiner différents critères afin de déterminer les signataires appropriés.
Ces règles doivent être associées aux différentes classes de frais pour lesquelles on souhaite gérer des exceptions de signature. Cette association permet également de déterminer le niveau de validation pour lequel l'exception est valide. Une structure dédiée permet d'associer à une classe de frais des règles d'affectation de signataires.
Toutefois, un signataire alternatif peut être renseigné sur la note ou la demande. Cette donnée peut être saisie ou affectée via une règle d'une autre nature (modification d'un en-tête par exemple), appliquée au cours du cycle de vie de la note ou la demande. Dans la structure gérant le lien entre les classes de frais et les règles, il est possible d'indiquer pour un et un seul niveau de validation, que le signataire alternatif présent sur la note ou la demande est le signataire prioritaire.

   Ces différentes règles sont exécutées lors de la soumission de la note ou de la demande. Le traitement sélectionne les règles associées à la classe de la note ou de la demande soumise. Ainsi les différents signataires exceptionnels, sont positionnés à chaque niveau de validation présent dans le flux de la classe de frais. Ces signataires exceptionnels deviennent alors prioritaires sur les signataires « habituels » qui possèdent éventuellement un droit de validation défini depuis les droits utilisateurs.

GFARS - Association classe-règles d'affectation signataire (Transaction QFIARS)
CFSIE - Signataires exceptionnels (Transaction CFSIE)

   Lors de la proposition d'un CGR à partir de la transaction de proposition de clé analytique. Dans le champ correspondant au CGR de l'entité de recherche, on distingue CGR segment et CGR combinaison.

   Si l'entité de recherche la donnée contient un CGR de type combinaison (ne possédant pas de numéro de segment), alors on ne prend que la partie renseignée entre les positions dans GFPCL. S'il s'agit d'un segment, on le prend en entier.
Cette modification va permettre ainsi de pouvoir proposer plusieurs segments consécutifs du CGR du frais à partir d'une même entité.

GFPCL - Propositions de clé analytique pour les frais (Transaction GFPCL)

   Afin de pouvoir réserver depuis l'outil de réservation, l'utilisateur doit posséder un profil voyageur stocké dans l'outil. Ce profil recense des informations d'authentification mais également les préférences de voyages de l'utilisateur, ses adresses (bureau, personnelle, etc.), ses différentes cartes de fidélité et d'abonnement, ses documents (passeport, carte d'identité, etc.). L'ensemble de ces données sont prises en compte lors des réservations. Les cartes d'abonnement, par exemple, permettent à l'utilisateur de bénéficier de meilleurs tarifs.
Toutes les données du profil sont issues de la base Qualiac® et sont synchronisées avec la base de l'outil de réservation. La 1ère étape pour utiliser ce module consiste donc à saisir dans Qualiac® les profils des différents collaborateurs susceptibles de se déplacer et de les synchroniser avec l'outil.
Pour réserver les différents services qui lui seront utiles lors d'un déplacement, l'utilisateur doit tout d'abord saisir sa demande de déplacement dans la base Qualiac®. C'est à partir de cette demande enregistrée, que l'utilisateur accède au site de réservation en appuyant sur le bouton "Réserver". Un nouvel onglet du navigateur s'ouvre alors. Une fois la sélection des services terminée, l'utilisateur se déconnecte du site. Lors du retour sur l'onglet du navigateur contenant l'application Qualiac®, un bouton permet d'actualiser la demande. Cette mise à jour interroge l'outil de réservation et rapatrie les différents services choisis par l'utilisateur afin de les associer à la demande de déplacement.
A cet instant, les services réservés sont en attente de validation, tout comme la demande de déplacement. Lorsque celle-ci est approuvée par la personne en charge de la supervision des voyages de l'utilisateur, une requête est émise vers l'outil de réservation afin que le statut des différentes réservations évolue également vers cet état d'approbation. C'est à cet instant que les réservations sont transmises à l'agence de voyage afin d'émettre les billets des vols et trains sélectionnés.

Pour la définition du profil voyageur :
- GINTE - Intervenants (Transaction QTIINT)
- GFPVC - Profil voyageur : Cartes de crédit (Transaction QFIPVC)
- GFPVD - Documents du profil voyageur (Transaction QFIPVD)
- GFPVP - Préférences voyageur (Transaction QFIPVP)
- GFPVR - Cartes d'abonnement et de fidélité (Transaction QFIPVR)
- GFPVT - Téléphones (Transaction QFIPVT)

Un conteneur rassemblant l'ensemble de ces transactions a été créé, il est accessible depuis le mnémonique GKFPRV.

Pour le paramétrage des accès à l'outil de réservation :
GFISE - Services externes (Transaction QFIISE)

Pour réserver en ligne : Le conteneur utilisé pour la saisie des demandes de déplacement.

Pour valider les réservations effectuées en ligne : Le conteneur utilisé pour la validation des demandes de déplacement.

   Il est nécessaire de souscrire un contrat avec la société Amadeus ainsi qu'avec une agence de voyage.
Une fois ces contrats finalisés, il est nécessaire de paramétrer les accès à l'outil de réservation via GFISE. Vous devez également renseigner les occurrences du paramètre GDS-AM qui complètent les données permettant l'accès à l'outil.

   Modification de la taille des colonnes tx1qfcdf, tx2qfcdf, tx3qfcdf, tx4qfcdf, tx5qfcdf de 20 à 240 caractères.
- tx1qfcdf    varchar(240)         Texte 1
- tx2qfcdf    varchar(240)         Texte 2
- tx3qfcdf    varchar(240)         Texte 3
- tx4qfcdf    varchar(240)         Texte 4
- tx5qfcdf    varchar(240)         Texte 5

   Modification de la taille des colonnes tx1qftcf, tx2qftcf, tx3qftcf,tx4qftcf, tx5qftcf de 20 à 240 caractères.
- tx1qftcf    varchar(240)         Texte 1
- tx2qftcf    varchar(240)         Texte 2
- tx3qftcf    varchar(240)         Texte 3
- tx4qftcf    varchar(240)         Texte 4
- tx5qftcf    varchar(240)         Texte 5