Les évolutions
Le protocole EBICS 3.0
Sycomore offre en avance de phase les messages essentiels du protocole EBICS sur sa version 3.0. on retrouvera ainsi les messages d’enrôlement INI,HIA,HPB,PUB,HCS,HCA de transferts FUL,FDL et d’infos HEV.
L’ouverture officielle du service est planifiée pour la fin de l’année. Contactez votre banque si vous souhaitez bénéficier de cette version du protocole.
Cette évolution ne concerne en aucune façon les connexions déjà établies en version EBICS 2.4 qui sont définies aujourd’hui avec toutes les banques.
En savoir plus sur le protocole EBICS3.0
Test de connexion à un serveur EBICS
Un nouveau bouton Tester a été ajouté sur l’écran de définition du serveur. Il permet de vérifier la connexion à la banque avec les propriétés définies URL et HostId .
Il permet également de vérifier que le serveur gère la version du protocole EBICS définie (cas de l’EBICS 3.0).
Ajout du BTF EBICS 3.0 aux transferts autorisés EBICS
Dans la version 3 du protocole EBICS, la structure BTF remplace le format de fichier.
Par défaut, le transfert autorisé EBICS utilise le BTF défini pour le type de fichier associé au transfert.
Il peut être surchargé au niveau du transfert, on parle alors de BTF personnalisé.
Le tableau listant les transferts d’un serveur EBICS 3.0 a également été adapté pour afficher les informations du BTF de chacun des transferts listés :
Je souhaite paramétrer ma connexion EBICS3.0
Gestion de widgets sur la page d’accueil
La page d’accueil des abonnements peut maintenant être organisé avec un ensemble de widgets.
L’utilisateur a la possibilité d’afficher/masquer les widgets qu’il souhaite voir sur la page d’accueil, il peut aussi placer chaque widget à l’endroit qu’il souhaite sur la page.
Le positionnement des widgets est automatiquement sauvegarder afin qu’il puisse être restitué à sa prochaine connexion.
Réagencement de l’écran d’édition d’un transfert
Les 2 champs Libellé du transfert préalablement nommé Type de transfert et Référence externe, auparavant dans l’encart Paramètres protocolaires de l’écran, ont été déplacés dans l’encart Type de fichier dorénavant nommé Description.
Ce réarrangement permet ainsi de mieux distinguer les données liées au protocole des données liées au transfert lui-même. Il a été appliqué à tous les transferts, pour tous les protocoles et tous les types de fichier.
La fiche d’un FQA a également été modifier pour pour regrouper les informations liées au transfert dans le cadre informations
Le FileFormat est donné à titre indicatif, il n’est plus surchargeable à partir du FQA. pour les transferts EBICS, il reste modifiable pour les transferts WEB et HUB
Attribution de l’état final d’un relevé change
L’état attribué à une réception va prendre la valeur "ETAT FINAL" dans les cas suivants :
- Un relevé a été reçu et contrôlé OK
- Un relevé a été reçu, contrôlé OK puis qualifié
- Un relevé a été reçu, contrôlé OK, qualifié puis intégré
- Le retour de la banque indique qu’il n’y a pas de relevés disponibles.
L’état "ERREUR" sera attribué pour toute autre erreur technique ou protocolaire.
Filtre de recherche des comptes émetteurs en saisie
La sélection du compte émetteur a été modifiée sur les écrans de saisie ( standard, unitaire et modèle) afin de permettre la recherche par saisie d’une chaine de caractères.
La liste des comptes éligibles s’affiche dès la saisie de 3 caractères.
La recherche se fait sur le numéro de compte (IBAN) et sur le libellé du compte.
Nous avons donné une priorité à l’affichage du numéro de compte, le libellé est affiché au survol du compte.
Nouveaux Web services de gestion des banques
Quatre nouveaux web services, permettant de gérer les banques, ont été ajoutés à l’application post-ws-exploitation. Ils offrent la possibilité aux utilisateurs habilités d’ajouter, modifier, lire et supprimer une banque en prenant également en compte les paramètres Serveurs et ses transferts associés.
La description de ces nouveaux web services est à votre disposition sur simple appel au support.
Configuration du sélecteur automatique de FQA et association d’une remise à un FQA
Configuration du sélecteur de FQA
L’écran de configuration du composant de sélection des FQA a été refondu afin de faciliter la gestion des abonnements disposant de beaucoup de FQA.
L’écran dispose désormais de critères de filtre facilitant la sélection des FQA affichés et regroupe les FQA par type de fichier.
Règle d’association à un FQA
Un fichier qui est déposé sans sélection de FQA et qui ne peut être associé à aucun FQA défini pour son type, prendra l’état "ERREUR". La remise ne pourra pas être associée manuellement à un FQA.
Nouveau champ dans l’import de partenaires
Pour avoir le même comportement dans la webapp et dans le batch pour l’import des partenaires dont on ne peut valider le BIC (ex : partenaire étranger dont le code pays ne possède pas de référentiel IBAN), un nouveau champ a été ajouté dans le fichier d’import : FORCEBIC. Ce champ n’est utilisé qu’en cas d’erreur de validation du BIC par rapport à l’IBAN. Il peut prendre les valeurs :
- 0 : le bic ne sera pas forcé et une erreur sera remontée
- 1 : le bic sera forcé et le compte enregistré
Nouveaux Icones dans la liste des fichiers reçus
Afin d’améliorer la restitution des informations concernant l’état des fichiers téléchargés depuis les serveurs bancaires, des icones ont été ajoutés pour illustrer le statut des réceptions.
Pour nos exploitants
Ajout d’un champ SIRET sur les abonnements
Un champ siret a été ajouté sur la fiche des paramètres de l’abonnement. Ce champ n’est pas obligatoire mais s’il est renseigné, un contrôle est effectué pour vérifier que le siret est correct.
Au niveau des webservices, le siret a aussi été ajouté dans le flux représentant l’abonnement.
Web service d’ajout d’un document sur un abonnement
Un web service REST permettant d’uploader un fichier et de l’ajouter à un abonnement a été ajouté.
Le web service SOAP d’ajout de document a quant à lui été supprimé.
Nouveau protocole EBICS 3.0
Activation du connecteur au niveau de la plateforme
Une nouvelle option a été ajoutée permettant d’activer les transferts EBICS 3.0 sur la plateforme.
Cette option est activée par défaut, elle est visible et modifiable côté exploitant sur l’écran Configuration > Fonctionnalités, encart "Connecteurs Transfert".
Ajout du module fonctionnel EBICS 3.0
Un nouveau module fonctionnel a été ajouté, permettant d’activer ou non les transferts en EBICS 3.0 pour chacun des abonnements.
Ce nouveau module fonctionnel est activé par défaut pour les nouveaux abonnements et a été activé sur tous les abonnements actuels de la plateforme.
Ajout de la version EBICS dans le flux WS d’un serveur bancaire
De manière à déterminer la version du protocole EBICS d’un serveur bancaire (EBICS 2.4 vs EBICS 3.0), un nouveau tag Version a été ajouté à l’élément ConnecteurEBICS.
Afin d’assurer la rétro-compatibilité avec l’existant, il est optionnel et accepte les valeurs suivantes :
•EBICS_24 pour un connecteur EBICS 2.4, valeur par défaut
•EBICS_30 pour un connecteur EBICS 3.0
Considération technique
Les échanges avec les serveurs bancaires s’exécutent à partir du module backend.
L’application Web IHM métier effectue des appels WS Rest vers le backend lorsqu’une communication avec un serveur EBICS 3.0 est nécessaire.
Le flux de données WS
Le flux de données des WebServices gérant les transferts autorisés a également été mis à jour de manière à pouvoir définir un BTF personnalisé à un transfert EBICS 3.0.
La structure suivante a été ajoutée à l’élément TransfertEbics définissant un transfert EBICS au sein d’un serveur EBICS :
"xml<BtfEbicsPersonnalise>
<BtfServiceName/> <!-- Nom du service, obligatoire, 3 caractères strictement -->
<BtfServiceOption/> <!-- Option du service, facultatif, entre 3 et 10 caractères -->
<BtfScope/> <!-- Scope, facultatif, valeurs possibles : BIL, FR, DE, CH, BIL -->
<BtfMessageName/> <!-- Nom du message, obligatoire, entre 1 et 10 caractères -->
<BtfMessageVersion/> <!-- Version du message, facultatif, 2 chiffres strictement -->
<BtfMessageVariant/> <!-- Variance du message, facultatif, 3 chiffres strictement -->
<BtfMessageFormat/> <!-- Format du message, facultatif, entre 1 et 4 caractères -->
<BtfContainer/> <!-- Conteneur, facultatif, 3 caractères strictement -->
</BtfEbicsPersonnalise>"Nombre de connexions simultanées d’un même utilisateur
Il est désormais possible de configurer la plateforme pour autoriser ou interdire deux accès simultanés via un même login. Ainsi, si un utilisateur possède une session d’ouverte sur la plateforme, ce paramètre permettra soit d’autoriser l’ouverture d’une nouvelle session, soit de l’interdire.
A noter que pour des raisons de sécurité, l’ouverture de plusieurs sessions simultanées sur l’IHM web d’un utilisateur métier est interdite.
Il est préconnisé de valoriser ces deux paramètres à true pour simplifier l’accès aux web services.
post:
authentification:
ws:
exploitant:
# Indique si un exploitant est autorisé à se connecter plusieurs fois en parallèle sur la plateforme dans le cadre des appels par Web Service.
connexionsMultiple: true
utilisateurMetier:
# Indique si un utilisateur métier est autorisé à se connecter plusieurs fois en parallèle sur la plateforme dans le cadre des appels par Web Service.
connexionsMultiple: trueNouvelle configuration de plateforme pour passer le dépôt en erreur en cas d’échec d’association de FQA
Une nouvelle propriété a été ajoutée dans la configuration des fonctionnalités de la plateforme (côté Exploitant, écran Configuration > Fonctionnalités).
Située dans la zone Configuration du workflow Aller > Dépôts de fichiers, elle permet de mettre directement le dépôt en erreur lorsqu’aucun FQA n’a pu lui être associé par le sélecteur automatique de FQA.
Ce comportement est le comportement par défaut, il faut donc désactiver l’option pour que le dépôt ne passe pas en erreur et pour autoriser un utilisateur habilité à sélectionner un dépôt manuellement.
Possibilité de définir un format de fichier pour les transferts Hub Cedricom
Un nouveau champ Format fichier, non obligatoire est disponible pour les transferts autorisés des serveurs de type Hub Cedricom. Il est utilisé pour surcharger le type du fichier lors de la récupération d’un fichier via le Hub Cedricom.
Les web services d’import et d’export de Transferts autorisés ont été mis à jour.
Le champ FormatFichier peut être précisé dans le flux d’un transfert autorisé TransfertHubCedricom. Lors de l’export d’un transfert autorisé de type TransfertHubCedricom, le champ FormatFichier est présent uniquement s’il est renseigné.
Refonte du stockage des remises et opérations
Cette version intègre une refonte du stockage d’une partie des données relatifs aux fichiers bancaires. Cette refonte implique des scripts de migration de la base de données importants qui adressent les tables les plus volumineuses de la plateforme.
Activation/désactivation unitaires des traitements de purge
De nouveaux paramètres ont été ajoutés à la configuration du batch contrôlant les purges des données.
Ces paramètres modiables à chaud permettent de contrôler de manière unitaire les différents traitements de purge par donnée ciblée.
Par défaut, l’ensemble des traitements sont activés. Si le batch de purge est lancé, ils seront exécutés séquentiellement les uns à la suite des autres.
purgeFichiesBancairesOrphelins:
depots:
depotsObsoletes:
depotsSupprimesLogiquement:
receptions:
receptionsObsoletes:
receptionsSupprimeesLogiquement:
fichiersQualifiesSupprimesLogiquement:
releves:
relevesSupprimesLogiquement:
tresorerie:
ecrituresTresoSupprimeesLogiquement:
fqrSupprimesLogiquement:
fluxRetoursSupprimesLogiquement:
purgeLogiqueComptesDestinatairesOrphelins:
purgeComptesTiersSupprimesLogiquement:
purgeTiersSupprimesLogiquement:
purgeComptesEmetteursSupprimesLogiquement:
purgeDocumentsObsoletesAssociesAAbonnements:
purgeEntitesSupprimeesLogiquement:
purgeAbonnementsSupprimesLogiquement:
reglementsSaisisSupprimesLogiquement:
purgeRgltsPourTiersOuComptesSupprimes:
purgeModelesReglementsSaisieSupprimesLogiquement:
purgeCrConversionOrphelins:
purgeCrGenerationOrphelins:
purgeOperationsOrphelines:
purgeConversionsSupprimeesLogiquement:
purgeConversionsObsoletes:Nouveau champ technique sur les dépôts
Un nouveau champ libre informationsTechniques est disponible sur les dépôts afin de véhiculer des informations (flux Json par exemple) entre sa création et la récupération du détail d’un dépôt par WS.
Sycomore fait ici office uniquement de passe-plat, ce champ n’est pas utilisé par l’application.
Dans le cas de l’utilisation du champ informationsTechniques pour véhiculer un flux Json, il est nécessaire d’échapper les doubles quotes. Le flux Json retourné sera lui aussi échappé.
Enrichissement des flux Json d’une remise
Le champ donneurOrdre, représentant le donneur d’ordre, a été ajouté au flux d’une remise. La documentation du web service de consultation des remises d’un dépôt est disponible ici :
Accès aux remises d’un dépôt
Contrôle de la volumétrie des fichiers reçus
La plateforme met à disposition des exploitants un moyen de contrôler la volumétrie de l’historique des réceptions et des fichiers associés sur leur abonnement au niveau du workflow retour (décorrélé des traitements de purge de la plateforme).
Ainsi, dés la réception d’un nouveau fichier, la plateforme pourra purger les fichiers les plus anciens de l’historique de l’abonnement. Cette purge automatisée, intégrée au Workflow Retour, est contrôlable au niveau de la plateforme.
Configuration des fonctionnalités du Workflow Retour
Les propriétés permettant de contrôler la conservation des réceptions via le workflow retour sont accessibles aux utilisateurs exploitants habilités dans l’écran de configuration des fonctionnalités de la plateforme.
Par défaut, cette fonction n’est pas activée sur la plateforme.
Gestion des doublons dans le Workflow Retour
Une nouvelle fonctionnalité a été ajoutée au workflow retour. Il s’agit de la détection et de la gestion de doublons suite au transfert du fichier.
Ainsi, si un même fichier est récupéré depuis un serveur bancaire, il est désormais possible pour un utilisateur habilité de configurer son Flux Retour afin que les doublons soient détectés et mis de côté.
Cela permet d’économiser en terme de ressources (traitements) sur la plateforme, et évite de notifier les clients pour des fichiers déjà intégrés.
Cette fonctionnalité permettra en outre d’intégrer des fichiers plusieurs fois par jour, par exemple des relevés de compte intradays, et de ne pas les retraiter si les nouveaux fichiers sont inchangés.
Activation de la gestion des doublons au niveau plateforme
L’activation de la gestion des doublons sur le workflow retour peut être effectuée par un utilisateur exploitant habilité via l’écran de configuration des fonctionnalités de la plateforme.
Configuration de la gestion des doublons pour un flux retour
L’option Gestion des doublons, ajoutée à l’écran de configuration d’un flux retour, permet d’indiquer la stratégie de gestion à appliquer lorsqu’un relevé de compte est identifié comme doublon lors de son intégration dans le module de Gestion des relevés (l’identification des doublons se fait sur les date de début et de fin du relevé) :
- Option Doublon non traité : Si le nouveau relevé est identifié comme étant un doublon, alors il est marqué comme étant un doublon et ses opérations ne sont pas intégrées.
- Option Annule et remplace (coché par défaut) : Si le nouveau relevé est identifié comme étant un doublon, alors l’ancien relevé, ainsi que ses opérations, est supprimé et le nouveau module est intégré. Les soldes en valeur et en date d’opération sont recalculés.
Priorité des flux qualifiés aller dupliqués
Un nouveau champ "FQA dupliqués plus prioritaires" a été ajouté dans la vue de création / modification d’un flux qualifié aller.
Il indique si les flux qualifiés aller fils seront plus prioritaires que celui-ci dans l’ordre de prise en charge du composant d’affectation automatique du flux qualifiés aller à un dépôt. Ce champ n’est pas modifiable si le flux qualifié est un flux qualifié restreint et que l’utilisateur n’a pas l’habilitation de gestion des flux qualifiés restreints sur l’entité concernée.
Cette fonction n’est pas utilisée pour nos clients SYCOMORE.
Configuration des flux qualifiés aller parents
Un nouveau champ "FQA dupliqués plus prioritaires" a été ajouté dans la vue de création / modification d’un flux qualifié aller.
Il indique si les flux qualifiés aller fils seront plus prioritaires que celui-ci dans l’ordre de prise en charge du composant d’affectation automatique du flux qualifiés aller à un dépôt. Ce champ n’est pas modifiable si le flux qualifié est un flux qualifié restreint et que l’utilisateur n’a pas l’habilitation de gestion des flux qualifiés restreints sur l’entité concernée.
Import / Export des flux qualifiés aller
Le champ "FQA dupliqués plus prioritaires" a été ajouté dans les flux XML et Json décrivant un flux qualifié aller. Ce champ est facultatif.
En xml, ce champ s’appelle FqaDupliquesPrioritaires et en Json fqaDupliquesPrioritaires.
Configuration du composant de sélection d’un flux qualifié aller
Sur la modification de la priorité de prise en charge par le composant de sélection automatique de FQA, si un flux qualifié aller dispose d’un flux qualifié aller parent (c’est à dire s’il a été dupliqué), alors la valorisation du champ « FQA dupliqués plus prioritaires » du parent et des ancêtres supérieurs est prise en compte.
Un message d’erreur s’affiche lorsque l’on tente de mettre une priorité moins élevée au FQA que celle du FQA parent si l’option « FQA dupliqués plus prioritaires » de ce parent est activée.
Suppression de notions obsolètes
Suppression de la notion niveau d’assistance
La notion "niveau d’assistance" n’étant plus utilisée, elle a été supprimée. Le menu permettant de configurer ces niveaux d’assistance a donc été supprimé, ainsi que l’attribut associé dans un abonnement. Toutes les tables et colonnes liées dans la base de données ont été supprimées.
Suppression du module fonctionnel de saisie d’ordres d’encaissement de prélèvements
Le type de fichier "Prélèvement domestique France" ("PRE") étant devenu obsolète, le module fonctionnel en permettant la saisie a été supprimé.
Il en résulte qu’il n’est plus possible de créer de remises et d’opérations ayant ce type de fichier.
Les éventuels modèles de remises et opérations saisis sur la plateforme pour ce type de fichier ont donc été supprimés.
Il reste toutefois possible d’importer des fichiers possédant ce type de fichier.
Suppression du protocole de transfert ETEBAC3
Le protocole de transfert ETEBAC3 n’est plus géré sur la plateforme.
Tous les transferts, serveurs bancaires, FQA, FR et FQR associés à ce protocole ont été supprimés de la plateforme.
La clé de propriété url.ws.etebac n’est plus utilisée.
Export de FQA au format CSV
Il est désormais possible d’exporter une liste de FQA au format CSV.
La configuration de l’export est à définir côté exploitant dans l’écran de configuration des fonctionnalités de la plateforme, section Configuration du Workflow Aller, encart Divers.
Pour tout complément technique consulter la documentation en ligne technique de Sycomore.
L’export au format CSV peut se faire de 2 manières :
- Via l’appel d’un web service
- Via un nouveau lien ajouté à l’écran listant les FQA
Les FQA exportés sont les FQA affichés à l’écran, répondant alors aux critères de recherche définis
Déport des traitements des dépôts
Le traitement des fichiers déposés dans le workflow aller peut désormais être délégué à l’application backoffice (post-batchs) en fonction de différents critères :
- Le type de création du dépôt (par IHM, Web Service, Conversion…)
- En fonction de la taille du fichier
- En fonction du paramétrage appliqué aux applications
Si la taille du fichier dépasse la valeur indiquée dans le paramètre Limite de parsing asynchrone (écran d’exploitation Configuration > Paramètres techniques, onglet Gestion dépôts), alors le traitement du dépôt est pris en charge par l’application backoffice.
Attention : le traitement de gestion des dépôts doit donc être démarré sur l’application batch.
Gestion synrchone / asynchrone des dépôts
La prise en charge synchrone ou asynchrone par l’application web des dépôts est configurable via l’écran d’exploitation Configuration > Paramètres techniques, onglet Gestion dépôts en valorisant les paramètres suivants :
- Limite de parsing synchrone
- Limite de parsing asynchrone
- Limite de prise en charge
Forçage de la prise en charge par le batch
Il est possible de forcer la prise en charge des dépôts suite à leur création à l’application contenant les traitements backoffices (conteneurBatchs). cela permet de décharger l’application web IHM de ces traitements, nottamment du parsing des fichiers.
Pour celà, il suffit de valoriser les paramètres suivants avec post_conteneurBatchs au lieu de post_webapp_ihm :
- ccom.post.workflowAller.traitements.postCreation.delegation.creePar.conversion.appCible
- ccom.post.workflowAller.traitements.postCreation.delegation.creePar.webservice.appCible
- ccom.post.workflowAller.traitements.postCreation.delegation.creePar.ihmUpload.appCible
- ccom.post.workflowAller.traitements.postCreation.delegation.creePar.ihmSaisie.appCible
- ccom.post.workflowAller.traitements.postCreation.delegation.creePar.tresorerie.appCible
Relance des réceptions en erreur / NON IMPLEMENTE
Sur l’écran d’activation des relances des Flux Retours, les cas d’erreur et de fichier non disponible sont maintenant correctement dissociés.
Les relances sur erreur et sur fichier non disponible ont été implémentées pour les réceptions HUB et SFTP (la fonction était déjà en place pour l’EBICS). Les relances des réceptions sont configurées avec les paramètres suivants :
- ccom.post.workflowretour.transfert.hub.nbRelancesMax
- ccom.post.workflowretour.transfert.hub.delaiRelancesMs
- ccom.post.workflowretour.transfert.sftp.nbRelancesMax
- ccom.post.workflowretour.transfert.sftp.delaiRelancesMs
Par défaut, le nombre de relances est positionné à 0 et le délai de relance à 1800000 Ms (soit 30 minutes).
Une remarque sur cet article ?