Document de release de la version H5.01

   Ce document présente les évolutions survenues sur l'application Cegid XRP Ultimate Déplacements et Frais professionnels en H5.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.

   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.

   Les administrateurs de la solution accèdent aux modèles depuis le mnémonique GFREGM, à partir duquel ils peuvent consulter les éléments existants et également en définir de nouveaux. Lors de la création d'un nouveau modèle, son code et son libellé 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 de notes de frais, accessible uniquement depuis le menu "Nouvelle note de frais" du portail.

   La sélection d'un modèle déclenche le processus de saisie.
La 1ère étape, qui consiste à compléter, si nécessaire, l'en-tête de la note de frais se réalise au travers de l'écran défini pour le modèle.
Après la validation de cette 1ère étape, le système propose une liste de natures de dépense, en tenant compte de la définition du modèle.
Une fois la sélection des frais terminée, le système invite l'utilisateur à compléter les données pour chaque élément choisi.
La dernière étape, qui s'enchaine après la finalisation de la saisie du détail des dépenses, présente la synthèse de la note. 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)

   Dès sa création, le modèle est utilisable par les collaborateurs autorisés.

   Le portail propose une nouvelle option pour la création d'une note de frais. Cette alternative permet de générer une note depuis une demande de déplacement.

   Cette option affiche les demandes de déplacement de l'intervenant, filtrées à partir de la période choisie. En cliquant sur le bouton "Transformer", le système exécute les différentes règles associées à l'évènement "Clic sur le bouton Transformer". L'objectif de l'ensemble de ces règles est de générer une note de frais en reprenant des informations de la demande de déplacement sélectionnée. Elles sont donc principalement composées d'étapes réalisant l'affectation des données de l'en-tête.

   Une fois la note créée, le système affiche son détail. Le collaborateur peut la compléter et/ou la modifier avant de la soumettre.
Chaque donnée de la note, affectée par la règle, affranchit le collaborateur de cette saisie qui peut alors se concentrer sur ses déclarations.

GKFREG - Générateur de règles (Transaction QFIREG)

   La 1ère étape consiste à créer la règle de transformation et de l'associer à l'évènement "clic sur le bouton Transformer". Par défaut, une règle de ce type est livrée en standard. Elle peut être mise en place au travers du traitement d'initialisation (TFINI)

   La politique de remboursement est gérée au travers de règles de remboursement qui utilisent le système de variables. Ces variables représentent le montant des forfaits ou des plafonds mais également les coefficients et constantes appliqués dans les barèmes kilométriques.

   Des écrans dédiés à la gestion de ces types de variables permettent de faciliter l'administration de la politique de remboursement.

   Gestion des forfaits et plafonds:
A l'ouverture cette transaction affiche les forfaits ou plafonds valide à la date du jour. Cette recherche sélectionne les variables dont la propriété "Montant forfait ou plafond" est active. Une clause est ajoutée pour remonter les natures associées au type de remboursement (forfait ou plafond) sélectionné.
Les forfaits et plafonds peuvent être définis par lieu et/ou selon une caractéristique des intervenants. Le fait de préciser ces informations pour les valeurs de la variable, permet de définir les exceptions. Le cas général est représenté par la valeur de la variable où ces données ne sont pas renseignées. Dans ce cas, le système affiche les libellés suivants :
   - "Tous lieux" lorsque le montant du forfait ou plafond est identique quel que soit le lieu.
   - "Autres lieux" lorsque le montant du forfait ou plafond est différent suivant le lieu. Ce libellé est alors affiché sur la ligne représentant le cas général.
   - "Toutes populations" lorsque le montant du forfait ou plafond est identique quel que soit le collaborateur.
   - "Autres populations" lorsque le montant du forfait ou plafond est différent suivant le collaborateur. Ce libellé est alors affiché sur la ligne représentant le cas général.

   Barème kilométrique:
Cette transaction est adaptée pour gérer des barèmes reposant sur le modèle de celui proposé par l'administration fiscale. Les tranches, les coefficients et les constantes sont définis au travers de variables. La recherche effectuée s'appuie sur le préfixe du code de ces variables. Il est possible de définir son propre barème en modifiant le nombre de tranches et/ou en personnalisant les variables utilisées pour définir les bornes de ces tranches ainsi que les coefficients et constantes.
Le pré-requis pour gérer ce barème personnalisé, est de définir un préfixe pour chaque type de variable (borne, coefficient, constante) et de les suffixer par un chiffre en corrélation avec le palier auxquelles elles sont associées.
Exemple avec le barème de l'administration fiscale:
Préfixe des variables représentant :
   - les bornes: QUA-BORNEPALIER
   - les coefficients: QUA-COEFFPALIER
   - les constantes: QUA-CSTEPALIER
Variables représentant les coefficients : QUA-COEFFPALIER1, QUA-COEFFPALIER2, QUA-COEFFPALIER3
Variables représentant la constante : QUA-CSTEPALIER2
Le barème de l'administration fiscale, fait seulement apparaître une constante au niveau du second palier.
Variables représentant les bornes : QUA-BORNEALIER1, QUA-BORNEPALIER2

   Seuls 10 paliers sont pris en charge.

Mnémonique: GFGFP (Transaction QFIGFP)
Mnémonique: CFBIK (Transaction QFCBIK)

   L'interface entre un outil de réservation et notre solution peut être réalisée à partir d'un fichier. C'est le cas avec l'outil Néo édité par KDS. Les informations extraites de ce fichier, permettent de générer des demandes de déplacements auxquelles sont associés les différents de segments de voyage réservés. Cette intégration permet d'engager les montants et éventuellement d'impacter des budgets. De plus, les demandes de déplacements peuvent être utilisées pour initier les notes de frais liées aux déplacements.

   Suite à l'analyse du descriptif des informations contenues dans ce fichier, seules quelques informations sont extraites de chacune des lignes. Certaines sont reportées sur l'en-tête ou les lignes de la demande de déplacement. Elles permettent d'affecter l'objet, les dates de début et fin de mission de l'en-tête ainsi que les dates de début et fin, le montant et la devise des lignes de la demande. D'autres sont utilisées pour appliquer des règles de gestion.

   Traitement des lignes
Chaque ligne du fichier correspond à une réservation, d'un billet d'avion ou de train, de nuitées d'hôtel ou d'une location de véhicule et contient l'identifiant du voyage (PNR: Passenger Name Record) auquel elle est associée. Le traitement gère un en-tête de demande pour chaque PNR différent présent dans le fichier.
Si le voyage traité n'est pas annulé, le traitement poursuit par la gestion de la réservation elle-même matérialisée par une ligne associée à la demande. Dans le cas contraire, il annule la demande de déplacement générée.
A chaque ligne de demande générée, un complément, stockant l'identifiant KDS du segment de voyage, est généré. Dans le cas où un enregistrement de ce type existe dans la base de données, le traitement met à jour la ligne. Dans le cas contraire, il génère une nouvelle ligne et l'associe à la demande.

    Affectations particulières réalisées sur l'en-tête:
La classe de frais et l'établissement sont issus de la soumission.
Le PNR (Passenger Name Record) qui est l'identifiant du dossier de voyage est stocké dans le texte 2 de l'en-tête. Le paramètre 1 contient l'information indiquant si le dossier contient un ou plusieurs éléments ne respectant pas la politique de voyage. Le paramètre 3 stocke le statut du voyage.
L'intervenant affecté sur une nouvelle demande est recherché à partir du login qu'il possède pour accéder à l'outil de réservation. Le traitement recherche donc dans la base de données l'intervenant dont la zone informations est alimentée avec le login lu sur la ligne de fichier.

    Affectations particulières réalisées sur les lignes:
Le paramètre 1 stocke l'information indiquant si le segment respecte la politique de voyage. le CGR analytique est le résultat de la concaténation de plusieurs colonnes du fichier. La nature de dépense est lue dans le référentiel voyage en tenant compte du type du segment de voyage.

TFKDS - Intégration des ddes de déplacement issues de KDS (Transaction QFTKDS)

   A fréquence régulière, l'outil de réservation extrait les nouvelles réservations ainsi que celles dont le statut a évolué depuis le dernier échange. Cette extraction doit être mise à disposition de notre solution et accessible par le serveur de traitement. Il est donc nécessaire de mettre en place un système d'échange des fichiers. Cette partie doit être étudiée avec le prestataire voyage retenu.
La zone informations, présente sur chaque fiche intervenant, doit contenir le login du collaborateur utilisé pour la connexion à l'outil de réservation.
Le référentiel voyage doit être renseigné pour effectuer la correspondance entre une nature de dépense et chaque type de segment de voyage.

   Afin d'alléger la saisie d'une nouvelle note de frais, le collaborateur peut s'appuyer sur une entité existante afin d'en extraire une partie des données pour les reprendre sur la note.
Les entités qu'il est possible de traiter sont:
   - les ordres de mission matérialisés par des commandes de ventes;
   - les projets et les éléments (phases, tâches) qui peuvent y être rattachés.

   Cette fonctionnalité est gérée au travers du système de règles. Les règles possèdent une nature dédiée à cette fonctionnalité particulière.

   Elles sont composées d'étapes dont les opérateurs déterminent:
   - Les données de l'en-tête qui sont obligatoires;
   - les natures de dépense proposées;
   - le masque adapté à la saisie de l'en-tête.

   Un opérateur, disponible uniquement dans le contexte des ordres de mission, permet d'indiquer si le CGR A est totalement ou partiellement repris sur la note.
De même, un autre opérateur permet de sélectionner la classe de frais pour laquelle la règle est valide.

   Afin de s'affranchir de certains concepts associés aux règles, une interface dédiée à ce type de règles a été créée. Elle est accessible depuis le mnémonique GFREGE.

   Cette fonctionnalité est disponible uniquement depuis le portail, à partir du menu "Nouvelle note de frais".
Après avoir validé la sélection de l'entité et la typologie de la note, le système recherche les différents éléments orientant la création de la note de frais et engage un processus de saisie, calqué sur celui décrit pour les modèles de notes de frais.

GFREGE - Génération depuis un ordre de mission ou un projet (Transaction QFIREGE)

   Ce service est destiné à être appelé depuis un intranet par exemple, afin que le collaborateur soit informé du statut de ses notes et ses déplacements.

   Le détail des informations remontées par ce service est disponible ici

   L'appel à ce service doit être réalisé par un développement. Les données remontées tiennent compte de l'utilisateur connecté. Il est donc impératif d'être authentifié avant tout appel. La méthode d'authentification diffère suivant l'infrastructure de chaque client.

   Après l'élaboration et la validation d'une règle, il peut être utile de pouvoir l'exporter d'un environnement de test afin de l'importer vers un environnement de production.

   L'export d'une règle consiste à stocker dans un fichier temporaire les informations de toutes les entités composant une règle (règles, étapes, associations règle-étape).
Le fichier généré est au format csv. La 1ère colonne de chaque ligne indique à quelle entité les données de la ligne sont rattachées. Les valeurs de cette colonne sont:

       - "QFREG" lorsqu'il s'agit des informations de la règle

       - "QFERP" lorsqu'il s'agit des informations d'une étape. Les données de l'association règle-étape sont également stockées sur ces lignes.

    L'import s'appuie sur le fichier généré depuis l'export pour créer la règle sur l'environnement cible. Lors du traitement d'une ligne "QFERP", l'outil vérifie s'il existe dans la base de données, une étape possédant les mêmes caractéristiques (opérateur et définition des opérandes). Si cette étape existe elle est automatiquement associée à la règle. Dans le cas contraire l'outil prend en charge sa création avant de l'associer.

GFREG - Règles (Transaction QFIREG)

   Pour faciliter le contrôle de notes de frais, il est intéressant de repérer en amont les éventuelles incohérences qu'elles comportent. Pour cela des règles, effectuant des tests sur les données des notes de frais, ont été créées. Elles génèrent des alertes qui sont affichées lors du contrôle de la note.
Ces alertes permettent d'attirer l'attention de l'approbateur sur des déclarations potentiellement source d'incohérence ou de fraude.

   Le but est de générer des alertes afin que l'approbateur prête une attention particulière aux déclarations potentiellement incorrectes. Les tests, réalisés sur les données des notes de frais, représentent un contexte que l'on estime incohérent et/ou frauduleux. Le résultat des tests conditionne alors la génération des alertes.
Exemple: On peut vouloir contrôler le montant dépensé et générer une alerte lorsqu'il dépasse un seuil fixé. La règle compare, dans ce cas, le montant dépensé saisi avec le seuil défini.

   Cette fonctionnalité est réalisée au travers de règles de contrôle d'en-tête ou de ligne suivant les données testées.
Comme toutes les règles, elles comportent des étapes en charge:
   - de réaliser les contrôles nécessaires.
   - de générer l'alerte souhaitée. Les alertes sont matérialisées par des compléments dont le type est spécifié par l'opérande 1 de l'étape. La valeur testée 1 de cette occurrence du paramètre TCDQFCDF doit être égale à 'AG' (Alerte générée).

   La liste des règles créées est disponible ici

GFREG - Règles (Transaction QFIREG)

   La 1ère étape consiste à générer les règles permettant de réaliser les audits souhaités. Elle s'effectue depuis la forme détail "Génération de règles" du mnémonique GFREG.
Après la création des règles, il est nécessaire de définir leur exécution.
Certaines des règles proposées nécessitent une adaptation au contexte de chacun.

   La règle QUA-ALERTECATEGORIE génère une alerte en fonction de la catégorie de l'intervenant. Il est nécessaire de définir au travers de la variable QUA-CATEGORIEFRAUDE et de ses valeurs les catégories des intervenants régulièrement "fraudeurs".

   La règle QUA-ALERTEDEPENSEWE génère une alerte lorsque la dépense est réalisée un week-end. La recherche du jour s'appuie un calendrier. Il est nécessaire de définir le code du calendrier utilisé au travers de la valeur de la variable QUA-CALENDARID.

   La règle QUA-ALERTEMNTDEPENSE génère une alerte lorsque le montant de la dépense dépasse un certain seuil. Ce seuil est précisé par la valeur de la variable QUA-SEUILDEPENSE.

   La règle QUA-ALERTENOUVEAU génère une alerte pour les déclarations des collaborateurs récemment embauchés. La règle compare la date d'entrée dans la société précisée sur la fiche intervenant à la date du jour. Elle considère l'embauche récente lorsque la différence entre ces dates   est inférieure à 6 mois. Chacun peut avoir une définition différente d'une embauche récente. Pour personnaliser cette notion, la règle doit être dupliquée. Un nouveau test entre la date d'entrée et la date du jour doit alors associé à la règle dupliquée.

   La règle QUA-ALERTETVA génère une alerte pour que l'approbateur prête attention à la saisie de la TVA lorsque la nature de dépense permet de la récupérer. Il est nécessaire, pour chacune de ces natures, de positionner à 'O' la valeur de la variable QUA-RECUPTVA qui est lue lors de l'exécution de la règle.

   L'intégration de cette solution a été réalisée pour l'application ainsi que la version HTML5 du portail.

    Depuis l'application mobile:
Le collaborateur ajoute un frais à partir d'une photo. Le système lui demande le type de dépense qu'il déclare et active l'appareil photo du mobile. Après la validation de la photo, l'analyse du document est déclenchée. Quelques secondes après, l'application affiche le détail de la dépense, complété avec le résultat de l'interprétation des données issues du justificatif.
Cette étape permet au collaborateur de vérifier l'exactitude des informations avant d'enregistrer la dépense. Au cours de ce process, le justificatif est également stocké en GED. Il est associé à la dépense et sera transmis lors de sa soumission.

    Depuis la version desktop:
Pour utiliser cette fonctionnalité, le collaborateur doit avant tout disposer d'une image du justificatif de la dépense.
Elle est disponible au travers de l'option "Justificatif" du menu "Ajouter un frais" présent dans le détail d'une note.
Le choix de cette entrée du menu, déclenche l'ouverture d'un explorateur de fichiers permettant de choisir le fichier image d'un justificatif. Après avoir validé la sélection du fichier, le système déclenche l'analyse du document et ajoute un frais "genérique" à la note de frais. Le collaborateur accède ensuite au détail de ce frais afin de spécifier la nature de dépense appropriée et vérifier les données issues du justificatif.
Le fichier image est stocké dans la GED et associé à la ligne de frais générée.

GFTLFP - Frais professionnel déclaré (Détail) (Transaction QFITLFP)

   Pour la version desktop, l'option doit être active. Pour cela la valeur testée 1 de l'occurrence OPTJUS du paramètre doit être positionnée à 'A'.
Il est nécessaire de créer une nature de dépense avec la caractéristique "analyse justificatif" active. Cette création peut être prise en charge par l'option "Natures de dépense" du traitement d'initialisation du module.

   Les forfaits et plafonds sont définis au travers de variables dont la caractéristique "Montant forfait ou plafond" est activée. Leur montant est fixé par une valeur de la variable représentant le forfait ou le plafond. Lors de cette saisie, la devise doit désormais être précisée. Cette valeur est ensuite recherchée lors du calcul du remboursement de la dépense.

   Dans le cas où les forfaits ou plafonds sont exprimés en devise, cela induit que des déplacements sont effectués à l'étranger. Les valeurs des variables doivent donc porter, en plus de la notion de nature de dépense, au minimum la notion de lieu. Cette notion doit également être présente sur les notes de frais afin que le système valorise correctement la variable lue par la règle de remboursement liée à la nature de dépense.

GFVAR - Variables (Transaction QFIVAR)
GFVAV - Valeurs des variables (Transaction QFIVAV)

   Il est nécessaire:

       - de créer l'ensemble des variables permettant de gérer les forfaits et plafonds que l'on souhaite gérer en devise.

       - de saisir les valeurs numériques des variables représentant les forfaits et les plafonds en précisant la devise.

       - de créer la ou les règles de remboursement prenant en compte les nouvelles variables créées avant de les associer aux différentes natures de dépense.

   La facturation des frais de déplacements à un client s'opère en générant une commande de ventes, au travers du traitement de génération de commande TFGCV qui s'appuie sur le paramétrage défini.
Pour compléter la réponse à cette problématique, différentes évolutions ont été apportées au niveau du paramétrage et du traitement. Elles concernent l'affectation du prix tarif, du libellé de la ligne de commande et les données de l'en-tête de la commande.

   Affectation du prix tarif de la ligne de vente
le prix unitaire est toujours calculé à partir du montant de remboursement réellement effectué. Avant d'être copié dans le prix TTC de la ligne de vente, il est éventuellement divisé par la quantité de la ligne. Le fait d'affecter les prix TTC des lignes de commande favorise la corrélation entre les montants des lignes de commande et de frais. Ce principe induit que la classe de tarifs de la commande exprime les prix en TTC.

    Affectation des données de l'en-tête
Pour facilement faire le lien entre la mission et la commande de vente, des éléments de la note de frais peuvent être repris sur la commande. Cette fonctionnalité est réalisée au travers d'une règle exécutée par le traitement. Les étapes qui la composent ont pour but de renseigner une information de l'en-tête de la commande de vente générée. Ces étapes sont toutes créées sur le même schéma. Elles possèdent le même opérateur "Affecter l'en-tête de ventes", l'opérande 1 de type champ lié à une occurrence du paramètre ZONSVT représentant l'ensemble des informations gérées. L'opérande 2 définit la valeur affectée au champ de l'en-tête.

   Affectation du libellé de la ligne de commande
L'intitulé proposé sur les lignes correspond à celui des articles. Or, les articles affectés peuvent être "génériques" et leur libellé peu explicite. Il peut alors s'avérer utile de reporter le libellé de la ligne de frais dans celui de la ligne de commande afin que le client puisse facilement identifier les frais qui lui sont facturés.

GFGCD - Génération des commandes (Transaction QFIGCD)
TFGCV - Génération des commandes de ventes (Transaction QFTGCV)

   Il est nécessaire de revoir le paramétrage de la génération de commande en fonction des affectations à réaliser. De plus, pour enrichir la commande avec des données de la note de frais, il est indispensable de créer une règle permettant ces affectations supplémentaires.

   Ajout des colonnes :
RINQFGCD - Recopie du libellé de la ligne de frais (Obligatoire)

   Ajout des colonnes :
DCLQFTST - Détail à la classe de frais (O/N) (Obligatoire)
DINQFTST - Détail à l'intervenant (O/N) (Obligatoire)
DNAQFTST - Détail à la nature de dépense (O/N) (Obligatoire)

   Ajout des colonnes :
INDQFWGC - Intitulé de la ligne

   Modification des colonnes :
CAVQFLDF - Ligne à refacturer (O/N) : devient obligatoire

   Modification des colonnes :
CAVQFTLF - Ligne à refacturer (O/N) :