Notes de version Élap Finance v2.3

Nouvelles fonctionnalités

• Mise à disposition de l’objet de gestion “Demande de Comptabilisation” (DCO) avec son accueil dédié en remplacement des OD de type “Demande de comptabilisation”.

      Pour 2023, la numérotation des DCO commencera à 2023100000.

• Mise à disposition de l’objet de gestion “Demande de correction” (DCr-D) avec son accueil dédié en remplacement des OD de type “Classique”.

      Pour 2023, la numérotation des DCr-D commencera à 2023100000.

• Mise à disposition de l’objet de gestion “Demande de Versement Comptable” avec son accueil dédié en complément des DV existantes et en remplacement des mouvements de trésorerie pouvant être réalisés avec une ancienne OD “Classique”

• Pour les OCB et OHCB soumis à l’infocentre, il n’est plus possible de créer de nouvelle OD à partir de l’application. Leur création via Web Service reste possible pendant une période de transition. Une migration des interfaces utilisant les API de création d’OD devra être effectuée par vos soins vers les API des nouveaux objets de gestion. 

• Mise à disposition de l’interface de configuration des accès techniques aux services de transmission des données pour Infinoé ;
• Mise à disposition de la fonctionnalité de test de connexion et de récupération de l’état de fonctionnement d’Infinoé “Etat santé” ;
• Mise à disposition de l’interface de consultation du journal d’échange avec Infinoé

• Un nouveau module optionnel de “Demandes Budgétaires” permet de saisir les lignes budgétaires de manière décentralisée par Organisation Budgétaire. Chaque demande budgétaire dispose de son propre workflow de validation, ce qui permet un dialogue de gestion entre les services demandeurs, qui compléteront les demandes, et le service financier qui les arbitre et consolide. L’ensemble des lignes saisies dans les demandes budgétaires sont consolidées nativement dans le BI ou BR lié à la demande. Nous vous invitons à vous rapprocher du service commercial si vous êtes intéressé par une présentation de ce module.

• Il est désormais possible de dupliquer un accord cadre.

• Mise à disposition d’un report standard d’analyse du délai global de paiement des DP. Par défaut, il est visible par les utilisateurs possédant le rôle de responsable de la trésorerie.

• Nouvelles API permettant la création de Marchés et d’Accords Cadre : 
  • Création des en-têtes de marché ;
  • Création des en-têtes d’accord cadre ;
  • Ajout des fournisseurs sur les marchés.
• API d’import des DPRR ;
• API d’import des Demandes de Versement Comptable ;
• API d’import des Demandes de Correction diverses ;
• API d’import des Demandes de Comptabilisation ;

• Possibilité d’ajouter des liens hypertextes vers des documents externes dans le menu complément des pièces, via la fonctionnalité “Lier un document externe” au-dessus de l’ajout des pièces jointes ;
• Mise à disposition d’un écran de paramétrage des types de documents et des métadonnées pour préparer l’envoi en GED.

Améliorations

• Il est désormais possible de séparer les montants demandés par les services des montants arbitrés par la direction et ainsi de garder la traçabilité des demandes initiales.

• Nouvelle condition de workflow permettant de tester la donnée renseignée dans la zone “montant maximum” de l’accord cadre.

• Pour les EPS/FPT, lorsqu’un mandat est pris en charge, l’EJ liquidé passe automatiquement à l’étape “Soldé” s’il ne reste plus rien à liquider
• Nouvelles conditions de workflow permettant de tester la procédure de consultation et la présence d’une date de livraison d’un EJ.

• Pour les EPS/FPT, lorsqu’un mandat est pris en charge, le SF liquidé passe automatiquement à l’étape “Liquidé” s’il ne reste plus rien à liquider.

• Amélioration d’un message d’erreur indiquant que l’on souhaite liquider dans la DP plus que le montant TTC de la facture.

• Pour les EPS/FPT, la saisie de code TVA et de Montant TVA n’est plus autorisée sur les titres de nature “Ordre” ;
• Le message d’erreur indiquant que l’on ne peut pas valider un titre avec un code du référentiel “Origine” désactivé est plus précis afin de mieux indiquer à l’utilisateur la cause de l’erreur.

• Il est désormais possible de saisir une réimputation sur une DRv en cas de nécessité de changement de référentiel d’une année sur l’autre.

• Amélioration des temps d’affichage et d’enregistrement des liquidations ;
• Pour les EPS/FPT, les liquidations permettant de payer des avances en investissement ;
• Pour les EPS/FPT, les liquidations indiquent à l’aide d’un pictogramme d’information à côté des coordonnées bancaires si le tiers possède un tiers d’affacturage afin d’éviter les erreurs lors de leur sélection. 

• Pour les EPS/FPT, il est maintenant possible d’annuler ou de réduire un titre complètement encaissé.

• Réduction du temps de traitement de la validation des encaissements des titres ayant déjà été préalablement encaissés plusieurs fois.

• Réduction importante du temps de génération des reports ;
• Les reports du “suivi des engagements” et de “l’extraction des tiers” ne sont plus limités à 10 000 enregistrements en export Excel. En revanche, la visualisation à l’écran des données reste elle limitée à 10 000 lignes ;
• Le report standard de “suivi des engagements” écarte désormais les pièces en brouillon ;
• Le report standard de “suivi des accords-cadres” affiche désormais une colonne reprenant la procédure de consultation de l’accord cadre. De plus, il a été optimisé pour afficher les données plus rapidement ;
• Le report standard du “suivi d’un accord-cadre” affiche désormais les DRv, les DPA et leurs montants régularisés, les liquidations, les retenues et leurs montants régularisés .

• Si vous avez un report personnalisé qui est limité à 10 000 enregistrements en restitution, alors vous pouvez contacter le support client Élap afin que cette limite soit supprimée. 

• Le grand livre budgétaire permet de filtrer sur les nouveaux objets de gestion.

• Les assistants de saisie des codes analytiques se chargent plus rapidement ;
• Amélioration des détections et des messages d’erreurs liés aux contrôles des paramètres INFINOÉ ;
• Dans le référentiel “Opération”, les opérations de type “opération pour compte de tiers” doivent obligatoirement avec un code INFINOÉ sauf si un ascendant hiérarchique de l’opération en possède déjà un.

• Amélioration des messages d’erreurs lors de l’import de titres de recette afin de rendre plus explicite l’anomalie et d’en faciliter la correction.

• Modification importante du système de validation des objets de gestion permettant à l’application de mieux gérer les opérations en parallèle. Cela va améliorer l‘expérience utilisateur lorsque de multiples opérations sont lancées simultanément. Plus il y a d’utilisateurs utilisant en même temps l’application, plus l’amélioration sera ressentie ;
• Optimisation de la base de données permettant une exécution plus rapide de certaines requêtes de l’application. 

Corrections

• Le fil d’actualité n’était plus alimenté à la suite d’un changement fonctionnel de notre partenaire de diffusion de flux d’information. Cela a nécessité le changement de partenaire et une modification de code dans l’application. Avec cette version, vous retrouverez les liens vers les notes de version et autres notifications d’informations de Élap Finance.

• Le dossier de présentation budgétaire agrégé des autorisations budgétaires (T2) d’un BR ne tenait pas compte des montants du COFI N-1 des SACD ;
• Dans un organisme multi-établissement, la sauvegarde d’un BR provoquait une erreur si un BI était en cours de modification dans un autre établissement ;
• Lors de la saisie d’un BR sur une imputation existante, si on voulait modifier une saisie précédemment enregistrée sur le BR en remettant la colonne “Nouveau” avec la valeur de la colonne “En cours”, alors la modification n’était pas prise en compte lors de l’enregistrement de la pièce ;
• Pour les OHCB, les prévisions budgétaires négatives n’étaient pas présentes dans l’export du BI.

• Lorsque l’on utilisait plus de deux fois la fonctionnalité de duplication de l’imputation budgétaire, alors seules les trois premières lignes du tableau étaient enregistrées dans la pièce ;
• Il était possible de sélectionner dans les imputations une Opération qui n’était pas paramétrée comme “saisissable en exécution”.

• Il était possible de sélectionner dans les imputations une Opération qui n’était pas paramétrée comme “saisissable en exécution”.

• Il n’était pas possible de recommencer à créer une DP depuis la fiche d’une facture si une précédente DP utilisant cette facture était à l’étape de workflow “Annulée” ;
• Dans l’écran d’accueil des factures, la colonne type de pièce est désormais systématiquement renseignée quel que soit le type de facture.

• La clôture d’un accord cadre n’était pas possible à la suite d’un message d’erreur indiquant qu’un SF n’était pas soldé alors que ce n’était pas le cas.

• Correction d’un problème de consommation de CP dans le cas d’un paiement partiel d’une DP régularisant une DPA ;
• Correction d’une erreur lors de la prise en charge d’une DP avec retenues qui entraînait un défaut de consommation de CP lors du lettrage de la DP ;
• Suivant un certain ordre de manipulation, il était possible de modifier la date de service fait d’une DP alors qu’elle devait être fixée par le SF en cours de liquidation ;
• Si l’entête d’une DP faisait référence à un accord cadre, alors les contrôles sur les champs date de service fait, date de réception et moyen de règlement n’étaient plus effectués lors de la sortie de brouillon de la pièce ;
• Les DP qui régularisent une DPA avec une retenue de cession ne pouvaient plus être payées ;
• Pour les OHCB, dans la fiche DP, la colonne “Charge Budg” n’était plus alimentée. Elle le restait dans l’accueil des DP ;
• Si une DP était reliée à un marché possédant une tranche sans numéro de lot, alors le numéro de marché n’était pas correctement indiqué dans l’entête de la DP. Le contexte de liquidation de DP dans le cadre du marché n’était alors pas bien remonté à la connaissance de l’utilisateur ce qui pouvait déclencher des incompréhensions de restriction de saisie.

• Lors d’un changement de tiers sur l’entête d’une liquidation (duplication, erreur en brouillon, …) la zone des coordonnées bancaires n’était pas réinitialisée avec les informations du nouveau tiers ;
• Les montants ventilés sur une liquidation pouvaient être repris à partir des pourcentages saisis sur l’EJ, ce qui amenait à des ventilations différentes de celles de l’EJ en fonction des arrondis.

• Le rejet de prise en charge de mandat n’était pas possible dans une organisation à plusieurs établissements.

• Mauvais enregistrement des données en monnaie de consolidation dans le cas où le prix unitaire a plus de décimales que la monnaie de consolidation. (Cela pouvait indirectement fausser l’équilibre de la balance dans le FEC).

• Pour les OHCB, il était demandé de procéder à une réimputation lors de l’encaissement d’une DRv n-1 alors qu’il n’y en avait pas besoin ;
• Il n’était pas possible de valider une DRv faite sur un EJ / Marché à cause du montant de la pièce qui ne pouvait pas être indiqué dans les imputations ;
• Pour les OHCB, la modification avant prise en charge d’une DRv ne remet plus la comptabilité d’AE en brouillon.

• Les DV pouvaient être rejetées en brouillon alors qu’elles étaient sélectionnées dans une pièce de trésorerie en cours de validation (paiement ou encaissement).

• Dans l’écran de lettrage, après la sélection de plusieurs lignes avec la touche MAJ du clavier, le bouton “Lettrer” restait grisé en indiquant à tort que la sélection n’était pas équilibrée.

• Les montants négatifs de TVA déductible (ex : DRV) n’était pas pris en compte dans les calculs de l’onglet « Synthèse » > « TVA déductible ».

• Correction d’un problème pouvant bloquer la création d’une pièce de paiement d’une DP si cette dernière possède de nombreuses lignes et qu’une réduction du montant à payer est effectuée ;
• Pour un établissement ayant des Organisation Budgétaire en commun avec un autre établissement, et si elle était paramétrée en limitatif sur un des établissements mais que l’axe OB n’était surveillé en exécution sur l’autre, alors ce dernier voyait tout de même un message bloquant de dépassement de CP lors de la tentative de validation d’un paiement sur cette OB.

• Les paiements en attente étaient additionnés à la place d’être soustrait dans le solde potentiel.

• Lors de la réimputation d’un objet de gestion portant plusieurs lignes qui ont la même imputation budgétaire, il est possible de demander à appliquer la réimputation sur l’ensemble des lignes de la pièce. Cette option présentait une anomalie l’empêchant de fonctionner correctement.

• Pour les OCB, le fichier EFE présentait un problème de totalisation en cas d’utilisation de la nature CAS Pension.

• Dans le grand livre comptable, si la période sélectionnée ne commençait pas au 01/01/n alors le solde progressif n’était pas correct ;Dans la recherche multicritère, un filtre sur un compte provoquait une erreur empêchant l’affichage du résultat ;L’export du résultat d’une consultation analytique était en erreur si un filtre par date était appliqué.

• Correction du report de la matrice utilisateur qui pouvait indiquer de mauvaises habilitations d’organisations budgétaires pour certains utilisateurs.

• Correction de l’outil de reprise de données Chorus Pro qui tombait en erreur lorsque l’on voulait supprimer plusieurs lignes ;
• Dans certains cas, bien qu’il existe un siren corroborant, l’association entre le tiers Chorus Pro et le tiers dans Élap Finance ne se faisait pas ;
• Dans certains cas, la récupération et la mise à jour de l’information d’obligation de présence d’un numéro d’EJ ou de la liste des “codes services” d’un tiers Chorus ne se faisait pas ;
• En cas de modification dans la fenêtre de paramétrage technique de Chorus Pro, le mot de passe pouvait être remplacé par un mot de passe enregistré dans le gestionnaire de mot de passe du navigateur sans que l’utilisateur ne s’en rende compte.

• Lorsqu’une DRv était saisie sur un compte paramétré dans le plan comptable comme générant des fiches d’immobilisation, la DRv n’était pas exportée à sa validation dans le fichier csv pour import des « documents comptables » dans SAGE ou AGE 11 ;
• Dans l’écran de suivi des imports, les informations concernant les imports de facture depuis Chorus Pro n’étaient plus visibles ;
• Dans l’écran de suivi des imports, les imports de titre n’affichaient pas correctement le statut lorsqu’une anomalie intervenait empêchant d’en récupérer le détail ;
• Dans l’écran de suivi des imports, pour les imports utilisant l’identification par Token, l’utilisateur d’importation était systématiquement indiqué comme étant “Sneg Support” alors que ce n’était pas le cas.

• Lorsque l’on effectuait des appels en masse des services d’import, il était possible de tirer deux fois le même numéro de pièce.