Document de release de la version H2.01

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

      Afficher / Masquer le détail                                                   Format PDF

   Cette nouvelle interface fonctionne aujourd'hui dans un mode "pour soi-même". C'est à dire que les éléments saisis ou affichés sont seulement ceux de l'intervenant associé à l'utilisateur connecté. La saisie des frais ne peut donc pas être déléguée.
Ce portail est accessible depuis:
- son mnémonique GKFFDP;
- la connexion à Qualiac®, en utilisant un thème "Frais professionnels" qui ouvre automatiquement ce mnémonique avec une charte graphique différente.

   A l'ouverture, une synthèse du portefeuille de dépenses, de l'utilisateur s'affiche sous forme de grille. Son contenu peut être trié par date, catégorie ou statut. Cette dernière option lui permet de voir les frais, précédemment déclarés, qui sont refusés. La sélection d'une ligne de frais, entraine l'ouverture du détail de cette ligne.
L'utilisateur navigue dans le portail via un menu, sous forme de liste, et des boutons.
- Le menu, permet de choisir les éléments consultés (le portefeuille de ses dépenses ou l'historique de ses déclarations).
- un bouton, permet d'ajouter de nouvelles dépenses.
- un bouton, permet de soumettre son portefeuille.

   Après avoir cliqué sur le bouton "ajouter des frais", un écran listant l'ensemble des natures disponibles s'affiche. Leur affichage est conditionné par le paramètre INI associé au mnémonique (CFHNADK).
Une fois la saisie terminée, le bouton "retour au portefeuille", ramène l'utilisateur à la synthèse de son portefeuille.

   Détail de la saisie des frais L'ensemble de dépenses saisies depuis le portail sont stockées dans les lignes de frais de transfert. Elles sont rattachées à l'en-tête de la note de transfert dont la classe possède la catégorie "ST" (Saisie temporaire). Cet en-tête est créé automatiquement lors de la 1ère saisie du collaborateur. Une fois la 1ère saisie, du collaborateur, réalisée, cet en-tête doit rester présent. La définition de la classe de "saisie temporaire" doit permettre la modification de la devise de dépense.

   La soumission des frais, est accessible depuis le portefeuille via le bouton "soumettre". Lors du clic sur ce bouton, un message avertit l'utilisateur que le système va répartir ses dépenses dans une ou plusieurs notes de frais, afin de pouvoir les soumettre. Cette ventilation automatique est régie par une règle dont l'objectif est d'associer chaque ligne du portefeuille à une note de frais. Une fois terminé, l'utilisateur voit apparaitre le résultat de ce traitement, qui correspond au portefeuille des dépenses trié par note de frais. Si la répartition proposée convient au collaborateur, il lui suffit de soumettre la (les) note(s) remplie(s). Dans le cas contraire, il aura la possibilité de la modifier et même de créer une note dédiée pour certaines de ses dépenses.

   Détail de la ventilation des frais
La règle qui permet d'affecter les dépenses à une note effectue des recherches dans la base de données afin de retrouver les notes auxquelles les dépenses peuvent être liées. La recherche des notes s'effectue au moyen d'une requête complexe dont les différentes clauses permettront d'affiner la sélection. Cette requête doit être définie via le mnémonique GFRQC.
Si une et une seule note répond à ces critères, la dépense est automatiquement associée à celle-ci. Si la dépense n'a pu être affectée à une note, la règle prend en charge la création d'une note de transfert modèle que le collaborateur n'aura plus qu'à compléter. La ligne traitée sera alors liée à cette note modèle. La note ainsi que les lignes seront transférées vers les structures d'exploitation lors de la soumission de la note. L'établissement et l'intervenant de la note de transfert générée par la règle, sont affectés automatiquement, respectivement avec l'établissement de connexion et l'intervenant associé à l'utilisateur connecté.

   La règle de soumission des frais doit obligatoirement avoir une nature "génération d'en-tête" et être associée à l'évènement "Soumission des frais". Une seule règle peut être déclenchée sur cet évènement.
Voici un exemple de règle, livré en standard.

   L'historique des déclarations sélectionne les éléments envoyés dans le circuit de validation. C'est à dire les éléments que l'intervenant a précédemment soumis. Cette sélection est affinée avec la période saisie. L'historique affiche donc les éléments soumis au cours de la période saisie. La requête, exécutée pour la recherche, s'appuie sur la date à laquelle les éléments ont été soumis. Cela revient à dire, avec le vocabulaire Qualiac®, la date à laquelle les éléments ont passé l'étape de soumission. Il est donc important que la définition de cette étape précise que son passage est stocké dans l'historique.

   Ce portail fonctionne uniquement pour soi-même. Les seules données connues, pour la recherche des éléments d'un intervenant, sont l'établissement et l'utilisateur de connexion. Il est donc impératif que le code de l'utilisateur connecté soit associé à un et un seul intervenant.

   L'utilisation de ce portail nécessite la création d'une classe de frais dont la catégorie est "ST" (saisie temporaire).

   De même, les natures de dépenses affichées lors de la saisie, sont celles possédant la caractéristique "nature de dépenses générique". Il donc important de définir correctement les natures. De plus, lorsque les autorisations entre classe, natures de dépense et intervenant sont gérées, les natures présentes dans ces autorisations doivent posséder, dans leur définition, la nature de dépense générique qui leur est associée. Ce lien permet de remplacer, sur les lignes de frais saisies, une nature générique par une nature autorisée pour la classe de frais. Cette substitution est effectuée lors de la soumission.

   L'affichage des en-têtes des notes de frais est réalisé via le mnémonique GFNDFP. Ce dernier prend en compte le paramétrage des droits par mnémonique. Il est donc nécessaire de créer les droits pour ce mnémonique en précisant qu'il est destiné à la saisie des notes pour l'utilisateur de l'intervenant.

   Les règles permettant de générer des en-têtes sont désormais exécutables depuis le traitement d'exécution d'une règle, qu'il soit défini comme une étape par classe ou non.

   La génération d'un en-tête d'une note de frais peut s'avérer utile particulièrement dans le cas où les demandes de déplacement sont gérées.
Lorsque la période de mission, saisie sur une demande de déplacement validée, a débutée, le collaborateur qui effectue la mission engage, dans la plupart des cas, des frais pour des services qui n'ont pu être anticipés avant son départ. Il déclarera alors ces dépenses à son retour. Pour lui faciliter le travail, la note à laquelle les dépenses seront associées, peut être créée via une règle de génération d'en-tête, déclenchée grâce à un traitement d'exécution de règles systématisé.
La règle définit un modèle de note de frais en s'appuyant sur les données de la demande de déplacement ou sur une des entités présentes sur cette dernière. Pour que le traitement sélectionne la règle, cette dernière doit être associée, dans GFARN, à l'évènement TNDF correspondant au traitement d'un en-tête.

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

   Si le traitement d'exécution des règles doit être une étape, il est nécessaire de la créer et la rattacher aux classes de frais pour lesquelles cette règle a une influence. Si le traitement s'exécute hors étape il sera préférable de l'intégrer à un enchaînement, comprenant notamment un traitement de constitution de listes, qui sélectionnera les demandes de déplacement en cours de réalisation.
Cette liste sera ensuite soumise au traitement d'exécution de règles.
Une systématisation permettra de déclencher cet enchaînement à une fréquence régulière.

   Le paramétrage de la génération des commandes permet d'affecter seulement quelques zones (classe, établissement, fournisseur, devise, dépôt, dates et marché) de l'en-tête de la commande. Il peut s'avérer utile de reprendre des données de l'entité du module QDF sur les en-têtes des commandes d'achats générées. Ce paramétrage peut alors être complété en utilisant une règle d'affectation des en-têtes d'achats.

   Les règles associées à cette nature complètent le paramétrage de la génération des commandes d'achats afin de reporter une information de l'entité traitée sur la commande générée.
Toutefois, l'ensemble des zones de l'en-tête d'achats ne sont pas traitées. Seules celles représentées par les occurrences du paramètre ZONSAC peuvent être affectées par ces règles.

   Il est donc nécessaire de créer une règle, dont la nature est "l'affectation d'en-têtes d'achats" comprenant des étapes dont l'opérateur affecte une donnée de l'en-tête achats.
La règle doit ensuite être associée à un évènement, "génération de commande d'achats " dédié et déclenché lors de la génération des commandes d'achats.

   Exemple : On souhaite reporter dans l'objet des commandes générées la classe, le numéro et le sous-numéro de l'entité traitée.
   Pour la création de cette règle, il faut créer une étape qui, au moyen d'une requête, concatène la classe, le numéro et le sous-numéro et l'affecte à l'objet de la commande. Ensuite, il faut créer la règle, à laquelle on lie cette étape, puis l'associer à l'évènement "Génération commande d'achats".

GFREG - Règles (Transaction QFIREG)
GFERP - Etapes (Transaction QFIERP)
TFGCA - Génération des commandes d'achats (Transaction QFTGCA)

   Une édition dédiée aux demandes de déplacement a été créée.

   L'édition des demandes de déplacement s'appuie sur l'édition des notes de frais puisque le programme accède aux mêmes structures de données. Le mnémonique permettant d'y accéder est EFDDP.
Dans cette édition dédiée, le récapitulatif est modifié. Pour les demandes de déplacement, outre le montant total des services réservés, on retrouve le montant avancé, le montant des frais que la société devra directement régler aux fournisseurs ainsi que le montant que la société devra rembourser au collaborateur.

   Cette édition peut être une étape des classes de frais liées aux demandes de déplacement. Dans ce cas, il sera de l'inclure dans le flux de chacune de ces classes.
Il est également possible d'y accéder depuis le bouton "Editer" présent dans les écrans des demandes de déplacement. Il est alors nécessaire de positionner le mnémonique de l'édition utilisée dans les droits par mnémonique (GFPDM) pour chacun des mnémoniques permettant la saisie des demandes.

   L'ensemble des données ajoutées ne sont pas gérées actuellement, elles le seront à l'avenir.

   A l'heure actuelle, seules les données suivantes sont gérées:
- La caractéristique "nature générique"
- Nature de dépense générique associée
- Les informations concernant l'affichage des notes saisie depuis le portail.
Les 2 premières données sont liées et sont principalement utilisées dans la nouvelle interface de saisie des frais, mais ont également un impact dans les conteneurs existants.

   Dans la nouvelle interface, l'utilisateur commence par la saisie de ses dépenses. Il ne se préoccupe pas de la note à laquelle elle sera liée lors de la soumission. C'est pourquoi la bibliothèque de frais sélectionne uniquement les natures génériques. Lors de la soumission, ses dépenses sont rattachées à une note, elle-même liée à une classe de frais. Si cette classe gère les autorisations entre classe-natures de dépense-intervenant, les natures de dépense présentes sur les lignes devront éventuellement être modifiées en fonction des autorisations définies.

   Exemple
Prenons l'exemple d'une classe NDF gérant les autorisations et d'un frais "billet d'avion", représenté par les différentes natures de dépenses suivantes:
AVION la nature générique.
AVION-NDF la nature autorisée pour la classe NDF ayant comme nature générique associée AVION.
Lors de la saisie, la nature présente sur la ligne est AVION. Lors de la soumission, cette dépense est rattachée à une note dont la classe est NDF. Il est donc nécessaire de remplacer la nature AVION par AVION-NDF qui est celle autorisée pour la classe de frais. Cette substitution est rendu possible car la définition des autorisations n'autorise pas d'avoir 2 natures ayant la même nature générique.

   Dans les conteneurs existants, l'impact se situe également au niveau de la bibliothèque de frais et plus particulièrement lorsque la classe de la note de frais ne gère pas les autorisations entre classe-natures de dépense-intervenant. Dans ce cas, la bibliothèque sélectionne uniquement les natures génériques. Il est donc important de revoir la définition des natures en fonction du mode de saisie utilisé et du paramétrage des autorisations mis en place.

GFNAD - Natures de dépense (Transaction GFNAD)

   Lors de la génération depuis le sas, la position fiscale présente sur l'en-tête est affectée depuis la donnée du sas si elle est présente sinon depuis le lieu de visite. Désormais, si ces données n'ont pas permis de renseigner cette information de l'en-tête, le programme l'affecte en lisant l'occurrence par défaut du paramètre TYPOETVA.

TFTNF - Intégration des notes de transfert (Transaction QFTTNF)

   Les requêtes exécutées lors de la recherche des entités à valider ainsi que les requêtes des WIMs informant les différents signataires ont évoluées. Les modifications permettent de prendre en compte les différents cas que les signataires exceptionnels permettent désormais de gérer.

   Ces différentes requêtes priorisent les signataires. En effet, seuls les signataires exceptionnels associés à l'entité pour un niveau de validation seront autorisés à la valider. Si pour un niveau de validation, le paramétrage indique que le signataire alternatif, présent sur l'entête de l'entité, est prioritaire, lui seul aura la capacité de la valider. Si pour un niveau de validation aucun signataire exceptionnel n'est positionné et si aucun paramétrage de la classe indique que le signataire alternatif est prioritaire, alors le paramétrage des droits utilisateurs sera pris en compte pour déterminer les signataires de chaque entité.

   Les requêtes prennent désormais en compte l'ensemble de ces cas afin:
- d'afficher les éléments, en cohérence avec le paramétrage défini, dans les écrans de validation.
- d'envoyer le mail aux personnes qui doivent réellement valider les éléments, dans le cas des WIMs.

GFNDF - Notes de frais (Transaction QFINDF)
GFDDP - Demandes de déplacement (Transaction QFIDDP)

   Un lien est désormais crée entre l'entité annulée et la pièce d'annulation.

   Le traitement génère un lien entre l'écriture d'annulation et l'entité annulée. Le type de lien, affecté lors de cette création, est lu dans la donnée "type d'évènement annulation" de la gestion des types d'évènement pour le traitement d'annulation utilisé et la ventilation comptable ayant permis la génération de l'écriture à annuler.

TFANN - Annulation des notes de frais (Transaction QFTANN)

   Il est nécessaire de paramétrer un type d'évènement associé au traitement d'annulation et à la ventilation comptable utilisée pour la génération de l'écriture comptable afin que ce dernier puisse lire la donnée "type d'évènement annulation" lui permettant de créer le lien.

   Dans le cas des délégations en "cascade" certains droits n'étaient pas correctement mis à jour.

   La recopie des droits d'un utilisateur ne s'effectuait pas dans un cas précis des délégations. Lorsque l'utilisateur B donne ses droits à l'utilisateur C, ce dernier récupère les autorisations de l'utilisateur B. Si par la suite, via une nouvelle délégation, l'utilisateur A donne ses droits à l'utilisateur B, ce dernier récupère les autorisations de l'utilisateur A.
Or l'utilisateur B a lui-même déléguait précédemment ses droits à l'utilisateur C. Il est donc normal que ce dernier récupère également les droits de l'utilisateur A. Cette dernière recopie de droits ne fonctionnait pas jusqu'à présent. L'utilisateur C possédait uniquement les droits de l'utilisateur B.
Le correctif permet désormais de gérer ces délégations en "cascade" en effectuant les mises à jour nécessaires.

GFEDU - Equivalences de droits utilisateurs (Transaction QFIEDU)

   Le traitement générant les commandes d'achat calcule désormais le prix unitaire affecté sur les lignes d'achats à partir des montants de TVA présents sur les lignes de frais, lorsqu'ils sont renseignés. Ceci permet d'être en cohérence avec le module achats qui gère uniquement des prix hors taxe sur les lignes de commande.

   Jusqu'à présent le traitement générant les commandes d'achats (TFGCA) reportait le montant présent sur les lignes de frais dans le prix unitaire des lignes d'achats. Or le prix de ces lignes doit être saisi sans taxe. Désormais si la ligne de frais possède un montant de TVA, le prix affecté sur la ligne de la commande, est calculé à partir de ce montant de TVA.

TFGCA - Génération des commandes d'achats (Transaction QFTGCA)

   Ajout des colonnes :
NEHQFDDU - N° interne de l'équiv. d'héritage

   Ajout des colonnes :
AH1QFNAD - Affich. dans les cnt. HTML5 des notes (Obligatoire)
NH1QFNAD - N° mosaïque dans le portail des déplacements (Obligatoire)
AM1QFNAD - Déduction titre restaurant (O/N) (Obligatoire)
NM1QFNAD - N° formulaire de validation en mobilité (Obligatoire)
AH2QFNAD - Affichage portail HTML5 des notes (Obligatoire)
NH2QFNAD - Idt affichage dans le portail HTML5 des notes (Obligatoire)
AM2QFNAD - Affich. dans mobilité des demandes (Obligatoire)
NM2QFNAD - N° formulaire dans la mobilité des demandes (Obligatoire)
AP1QFNAD - Affich. dans le portail des demandes (Obligatoire)
NP1QFNAD - N° mosaïque dans le portail des demandes
AH3QFNAD - Affich. dans cnt. HTML5 des demandes (Obligatoire)
NH3QFNAD - Idt affich. dans les conteneurs HTML5 des demandes (Obligatoire)
AM3QFNAD - Affichage mobilité HTML5 des demandes (Obligatoire)
NM3QFNAD - Idt affich. dans la mobilité HTML5 des demandes (Obligatoire)
AH4QFNAD - Affichage portail HTML5 des demandes (Obligatoire)
NH4QFNAD - Idt affichage dans le portail HTML5 des demandes (Obligatoire)
NAGQFNAD - Nature générique (O/N) (Obligatoire)
NGAQFNAD - Nature de dépense générique associée
NFKQFNAD - Service ou dépense représenté par la nature (Obligatoire)
IMNQFNAD - Image affichée en mobilité
RGSQFNAD - Regroupement statistique
NFAQFNAD - Nature de dépense favorite (O/N) (Obligatoire)
TX1QFNAD - Complément 1
TX2QFNAD - Complément 2
TX3QFNAD - Complément 3
TX4QFNAD - Complément 4
TX5QFNAD - Complément 5

   Modification des colonnes :
TAFQFNAD - Affichage dans les conteneurs des notes :
AFFQFNAD - N° mosaïque dans les conteneurs des notes :
TACQFNAD - Affichage dans le portail des notes :
CDFQFNAD - N° mosaïque dans le portail des notes :
TCDQFNAD - Affichage dans la mobilité des notes :
CDDQFNAD - N° formulaire de saisie en mobilité :
TADQFNAD - Affichage dans les cnt. des demandes :
DDPQFNAD - N° mosaïque les conteneurs des demandes :