14 avr. 2023 Release note
Focus sur le réglementaire dans cette nouvelle version de coog !
coog 23.14 est marquée notamment par la création – dans le cadre d’un projet collectif majeur – du module DSN et de sa génération des fiches de paramétrage.
Le module Prest’IJ est quant à lui amélioré dans son processus d’inscription des entreprises et de ses salariés.
Le domaine métier comme la Santé et le module NOEMIE ne sont pas en reste dans cette nouvelle version avec la gestion du double rattachement et du refus de noémisation dès la souscription d’un contrat.
coog Back-Office
Réglementaire
DSN
Génération des fiches DSN
Besoin métier : pouvoir générer les fiches DSN pour mise à disposition sur Net-entreprises.
Évolutions :
- Dans “Société”, ajout d’une nouvelle configuration afin de préparer le flux DSN.
- Sur chaque produit (dans l’onglet DSN du laboratoire), il est possible de paramétrer une configuration DSN à l’aide d’une règle de mapping.
Règle de transcodage DSN (défaut) livrée en standard
- Génération (automatiquement suite à un acte de gestion et/ou manuellement) des fiches DSN au format XML et PDF depuis coog.
Génération et consultation d’une fiche DSN depuis le souscripteur d’un contrat collectif
Permettre la réinscription Prest’IJ depuis une fiche d’inscription
Contexte :
La purge périodique de la base GESTIP est réalisée sur les données considérées comme obsolètes :
- Les couvertures dont la date de fin est antérieure à la date du jour – 33 mois et qui n’ont pas été modifiées depuis 24 mois,
- Les assurés auxquels aucune couverture n’est rattachée et qui n’ont pas été modifiés depuis 24 mois,
- Les entreprises auxquelles aucun assuré n’est rattaché et qui n’ont pas été modifiées depuis 30 mois.
Cependant, pour certaines entreprises, il est nécessaire d’inscrire des salariés après la purge réalisée par la Caisse Nationale d’Assurance Maladie (CNAM).
Besoin métier : pouvoir relancer l’inscription de l’entreprise après une purge pour permettre l’inscription des salariés.
Évolution : activer le bouton “Relancer le processus d’inscription” pour les entreprises ayant un statut Prest’IJ « Déclaration confirmée » permettant de renvoyer une inscription à la CNAM.
Santé
NOEMIE
Permettre le refus de noémisation à la souscription d’un contrat
Contexte : le refus de noémisation de la part de l’assuré était possible uniquement par la saisie d’un avenant sur un contrat déjà existant.
Besoin métier : la saisie du refus de noémisation doit être possible dès la souscription.
Évolution : ajout d’une case à cocher permettant d’indiquer que l’assuré ne souhaite pas activer la noémisation dans le cadre du processus de souscription des contrats Santé.
almerys
Gestion de la double noémisation d’un tiers
Périmètre d’application : interface almerys pour la gestion des prestations Santé.
Contexte : il est nécessaire de générer deux flux V3 (un à J et un à J+1) pour informer almerys et gérer le double rattachement d’un ayant-droit (mineur non émancipé) à deux ouvrants-droit (parents) au sens Régime Obligatoire (RO) du terme.
Besoin métier : activer à J les droits RO et informer l’organisme de Tiers Payant du rattachement de l’enfant à ses deux parents dès lors qu’ils sont couverts sur le même contrat.
Évolution : alimentation des balises V3 nécessaires au double rattachement.
Permettre la modification des préférences de communication du tiers
Périmètre d’application : interface almerys pour la gestion des prestations Santé.
Contexte :
Aujourd’hui, il n’est pas possible d’indiquer dans le flux V3 les préférences de communication de l’assuré (envoi postal ou email). Les balises du flux V3 permettant d’indiquer à almerys ces informations étaient par défaut alimentées avec la valeur email.
Besoin métier :
Pouvoir communiquer à almerys les préférences de communication de l’assuré pour le mode d’envoi des relevés de prestations et des courriers de gestion.
Cette information doit faire l’objet d’un envoi de flux V3 en cas de modification des préférences.
Évolutions :
- Ajout de deux données « Mode d’envoi des décomptes almerys » et « Mode d’envoi des courriers de gestion almerys » sur la fiche du tiers,
- Alimentation des balises du flux V3,
- Mise en place d’un avenant permettant de modifier les préférences de communication de l’assuré afin d’informer almerys de cette modification,
- Ajout des deux données dans les API.
Emprunteur
Ajout d’un nouveau champ “Agence” si l’organisme prêteur est une banque
Périmètre d’application : ce nouveau champ est disponible seulement pour les banques organisées en agences (régionales, par exemple) lors de l’ajout d’un prêt dans le processus de souscription.
Contexte :
À la saisie d’un prêt, le nom de l’organisme prêteur et l’adresse doivent être renseignés. Pour les réseaux bancaires organisés en agences, le gestionnaire avait accès à la liste des adresses des agences sans pouvoir déterminer à quelle agence correspondait l’adresse.
Besoin métier : avoir accès depuis la banque à l’ensemble de ses agences existantes via leurs dénominations et pouvoir filtrer sur le nom de l’agence souhaitée.
Évolution : ajout d’un nouveau champ “Agence” permettant d’accéder à la liste des agences disponibles pour la banque choisie afin de sélectionner l’agence souhaitée.
Ignorer la vérification sur le chevauchement des garanties d’assurance Emprunteur
Évolution : lever le contrôle de vérification du chevauchement des garanties non applicable en assurance Emprunteur.
Contrats
Gestion des interlocuteurs de cotisations et de prestations
Besoin métier :
Gestion de la notion d’interlocuteurs de cotisations et de prestations qui regroupe, pour une ou plusieurs personnes morales couvertes par un contrat collectif, les notions de tiers, moyen de contact et coordonnées bancaires.
Pour chaque contrat collectif, l’interlocution cotisations/prestations peut être :
- Centralisée (une seule et unique personne morale en tant qu’interlocuteur),
- Décentralisée (chaque personne morale est l’interlocuteur de ses propres cotisations/prestations),
- Mixte (regroupement d’interlocutions au niveau des personnes morales),
- Déléguée (l’interlocuteur n’est pas une personne morale couverte par le contrat mais un autre tiers).
Évolutions :
- Ajout dans le processus de souscription d’un wizard permettant de saisir les interlocuteurs de cotisations et de prestations et le mode de gestion,
- Ajout d’un avenant permettant de modifier les interlocuteurs en cours de vie du contrat.
Amélioration de la mécanique d’événements liés aux bordereaux d’appel
Contexte : les événements liés aux bordereaux sont générés mais consultables uniquement depuis l’enregistrement lié “Logs d’événements” du contrat.
Besoin métier : avoir accès aux événements (génération, validation, émission, paiement du bordereau) directement depuis les bordereaux d’appel.
Évolutions :
-
Ajout de logs d’événements depuis le point d’entrée “Bordereaux d’appel”,
-
Ajout de nouveaux événements : “Affectation d’un paiement” et “Désaffectation d’un paiement”.
Avenants
Ajout d’éléments de modèles de modification de contrat
Évolutions :
Ajout des modèles d’avenant permettant de :
- Modifier les données complémentaires d’une garantie,
- Modifier les données complémentaires d’un contrat,
- Résilier un contrat.
Ajout de la notion de groupes d’application sur les définitions d’avenants
Contexte :
Les définitions d’avenant peuvent être rattachées à des groupes d’utilisateurs pour restreindre les accès. Cependant, si une définition d’avenant est liée à un groupe, l’ensemble des utilisateurs rattachés peut saisir et appliquer l’avenant.
Besoin : pour éviter les risques de fraude, il doit être possible de séparer les droits de saisie d’un avenant des droits d’application d’avenant.
Évolution : mise en place de groupes d’application pour définir les groupes qui peuvent appliquer l’avenant.
L’avenant reste en brouillon et un utilisateur avec les droits pourra le reprendre pour l’appliquer.
Permettre la résiliation de formules complémentaires via l’avenant de modification des formules
Contexte :
L’avenant permet de souscrire une nouvelle formule complémentaire. Cependant, si l’on souhaite :
- Changer de formule complémentaire, cela ne résilie pas les anciennes garanties de la précédente formule;
- Résilier une formule complémentaire, aucune action ne le permet.
Pour rappel, une formule complémentaire est une formule regroupant des garanties non-obligatoires. Cette formule complémentaire est liée à une formule souscrite sur le contrat.
Besoin métier : pouvoir remplacer ou résilier les formules complémentaires, respectivement en changeant la formule complémentaire par avenant ou en sélectionnant « Vide » pour résilier la formule.
Évolution : refonte de l’avenant de modification des formules pour permettre la résiliation ou le changement de formule dans un seul avenant.
Sinistres
Ajout d’identifiant et de numéro externe sur les sinistres
Besoin métier : lors de la délégation de gestion des prestations, le délégataire peut avoir son propre identifiant.
Évolution : ajout de champs “Identifiants” sur les sinistres afin de stocker une référence externe.
Ajout d’une règle sur les prestations pour permettre la saisie des périodes d’indemnisation dans le futur
Périmètre d’application : création manuelle des prestations – ne s’applique pas aux périodes créées par batch (exemple : prolongation d’une rente).
Contexte :
Aujourd’hui, l’assistant de saisie des périodes bloque la saisie de prestation dans le futur. La date de fin de la période doit être inférieure ou égale à la date du jour.
Besoin métier : la saisie de prestation dans le futur doit être possible afin de pouvoir enregistrer des prestations avec une date de fin supérieure à la date du jour.
Exemples d’application : réception d’un arrêt de travail le 06/04/2023 pour une période du 01/04/2023 au 25/05/2023.
Il est désormais possible de saisir la date de fin de l’arrêt de travail au 25/05/2023 sans avoir besoin de découper les périodes.
Évolution : création d’un nouveau type de règle et livraison d’une règle par défaut permettant de définir le délai maximum d’anticipation autorisé.
Sur la prestation, il est possible de définir la règle à appliquer.
Création d’un batch de génération des remboursements de sinistre
Contexte : la mise en place de la saisie des prestations dans le futur implique que la génération des quittances de remboursement de sinistre soit décorrélée de la validation des périodes d’indemnisation.
Besoin métier :
Les prestations doivent pouvoir être saisies, sans que les quittances soient générées automatiquement pour les périodes à venir. Il est également nécessaire de pouvoir consulter les quittances à venir pour un tiers donné.
Évolution :
- Ajout d’un batch de génération des remboursements de sinistre “claim.indemnification.invoice” : ce batch traitera les périodes d’indemnisation dont l’état est “Valide” et sélectionnera les indemnisations dont la date de début est inférieur ou égale à la date passée en paramètre du batch.
Ajout d’un point d’entrée “Indemnisations” présentant l’ensemble des périodes d’indemnisation. Il sera possible de filtrer sur les statut “Validée”.
Ajout du découpage des périodes d’indemnisations au date de paiement de prêt
Périmètre d’application : Prestations Emprunteur.
Contexte : lors de la saisie de période de prestation, les périodes saisies ne correspondent pas forcément aux dates de paiement des prêts.
Besoin métier : les prestations doivent être découpées en automatique par coog afin que les périodes correspondent aux dates de paiement du prêt sur lequel les prestations sont saisies.
Évolution : l’assistant de saisie des périodes d’indemnisation découpe en automatique les périodes d’indemnisation aux mêmes dates que les dates de paiements des prêts.
Possibilité de filtrer avec une liste de code de préjudice la fonction du moteur de règles « date_de_fin_du_precedent_sinistre »
Contexte : la fonction du moteur de règles vérifie uniquement la présence d’un sinistre (tout préjudice confondu).
Évolution : ajout d’un paramètre optionnel dans la fonction du moteur de règles.
Ce paramètre permettra de filtrer via une liste de codes de préjudices afin de limiter la recherche si besoin.
Exemple d’application : mise en place d’une règle d’éligibilité complexe qui vérifie le délai entre deux indemnisations.
Lorsqu’un assuré a bénéficié d’une période d’indemnisation pour une incapacité temporaire de travail (ITT), une nouvelle prise en charge est possible au titre d’une nouvelle ITT après une reprise d’activité professionnelle rémunérée d’au moins X mois consécutifs. Une nouvelle indemnisation au titre de la perte d’emploi peut être prévue à l’issue d’une reprise d’activité salariée d’au moins X mois consécutifs.
Ajout d’un point d’entrée pour les bordereaux de délégation
Périmètre d’application : prestations Santé – intégration des prestations payées par le service de Tiers- Payant.
Contexte : les factures payées par le délégataire sont accessibles dans le menu “Factures fournisseur” qui regroupe l’ensemble des factures payées par des tiers.
Besoin métier : à l’intégration des prestations Santé payées par le délégataire, il est nécessaire de pouvoir visualiser uniquement les quittances liées par un paiement du délégataire.
Évolution : création d’un nouveau menu permettant de visualiser les quittances des prestations payées par le délégataire.
Rendre disponible la date de reprise en gestion dans le moteur de règles
Périmètre d’application : prestations collectives.
Contexte : la date de reprise de gestion est saisissable sur les contrats collectifs mais non utilisable à des fins de paramétrage.
Besoin métier : rendre disponible la date de reprise en gestion dans le moteur de règles pour l’utiliser lors de la sélection médicale, du calcul de franchise, de prestation , …
Évolution : ajout de la fonction dans le moteur de règles.
Exemple d’application :
Suite à la souscription d’un contrat collectif, le nouvel assureur détermine s’il reprend les sinistre ou uniquement les revalorisations. La date de reprise doit être utilisée dans les règles pour calculer la prestation.
Facturation
Cotisations
Affichage d’un message d’erreur à l’annulation d’un mouvement créé par une facture
Contexte : l’annulation d’un mouvement comptable sur une quittance à l’état “Émise” a pour effet de passer la quittance à l’état “Payée” (comptablement, les mouvements s’annulent bien).
Évolution : mise en place d’un message d’erreur pour informer l’utilisateur que l’annulation n’est pas réalisable.
Ajout de types d’événement pour la suspension et la dé-suspension des paiements
Contexte : les contrats en suspension de paiement sont difficilement identifiables.
Besoin métier : enrichir la traçabilité des contrats en suspension et/ou dé-suspension des paiements.
Évolution : ajout de types d’évènement pour la suspension et/ou dé-suspension des paiements.
Exemple d’application :
Suite au rejet d’un paiement, les prélèvements sont suspendus sur le contrat. Cette suspension sera disponible dans les logs d’évènements.
Ajout des taxes optionnelles sur les garanties de produit
Contexte : si la taxe appliquée sur une garantie dépend de critères afférent à l’assuré ou au contrat, il était nécessaire de paramétrer autant de garanties que de profils de taxe.
Besoin métier : faire varier sur une même garantie le taux de taxe appliqué en fonction de critères tels que le régime, une donnée complémentaire, etc.
Exemple d’application : en Santé, les garanties souscrites par les assurés du régime général sont soumises à une TSCA de 13,27 %, alors que les garanties souscrites par les assurés rattachés au régime agricole (MSA) sont soumises à un TSCA de 6,27 %.
Évolutions :
- Ajout de la notion de taxe optionnelle sur les garanties,
- Utilisation du moteur de règle pour définir les conditions d’application de la taxe.
Gestion des grilles tarifaires
Périmètre d’application : contrats collectifs avec mode de tarification standard.
Contexte : aujourd’hui, la tarification des contrats standards et sur-mesure était saisie lors de la souscription du contrat.
Besoin métier :
- Pouvoir saisir de façon simple et rapide les taux ou forfaits de cotisations applicables à chaque garantie/groupe de population – soit au niveau du contrat (tarification sur-mesure), soit au niveau du produit (tarification à l’offre),
- Pouvoir générer les fiches DSN (cf. Réglementaire).
Exemple d’application :
En Santé collective, pour un produit standard, il n’est plus nécessaire de renseigner sur chaque contrat les tarifs des forfaits pour chaque groupe de population.
Évolutions :
- Nouvelle notion d’usage dans les données complémentaires : “Composante de la structure de cotisation”. Des données complémentaires sont obligatoires sur les garanties pour pouvoir générer les grilles tarifaires. Il est possible de paramétrer quels éléments sont à prendre en compte dans la tarification (exemple donnée complémentaire ‘collège’ sur le groupe de population.
- coopengo livre par défaut deux données complémentaires : types et assiettes de cotisations.
-
Création d’un assistant permettant d’exporter au format csv les grilles tarifaires pour les renseigner hors outil (fonctionnalité d’export/import).
-
Création d’un outillage pour agréger les cotisations par groupe de population (nouveaux écrans + alimentation des bordereaux d’appel de cotisation pour obtenir le taux global TA/TB plutôt que le taux par garantie).
Étape 1 – Sélection du type de grille
-
Choix des garanties
-
Choix des groupes de population
-
Choix du type et si cela est pertinent de l’assiette de cotisation
Étape 2 – Possibilité de renseigner les taux directement dans l’interface ou de générer le CSV
Étape 3 – Récupération du CSV
Étape 4 – Mise à jour du CSV dans Excel puis import
Étape 5 – Fichier utilisé et ajouté au produit
Comptabilité
Ajout d’un assistant pour la création d’un produit comptable
Commissions
Ajout de la fonction ‘code_courtier’ dans le moteur de règles
Besoin métier : pouvoir ajouter dans le moteur de règles des conditions de calcul de commissions liées à un courtier pour pouvoir mutualiser le paramétrage cross-courtiers.
Évolution : ajout une fonction dans le moteur de règles permettant d’accéder au code du courtier dans un contexte de commissionnement.
Permettre aux règles de calcul de la date de paiement du précompte de fonctionner avec la méthode de paiement comptabilisé
Périmètre d’application : plan de commission précompté.
Contexte :
Dans le paramétrage du précompte sur les plans de commissionnement, il est possible de configurer la date à laquelle le précompte doit être versé de deux façons différentes :
- Utilisation d’une règle permettant de calculer la date de paiement des commissions précomptées,
- Case à cocher “À la première quittance payée”.
Ces deux modes de fonctionnement sont exclusifs.
Besoin métier : pouvoir paramétrer une règle de date de versement du précompte à la date d’effet du contrat.
Toutefois le précompte ne pourra pas être versé avant que la première quittance soit payée.
Évolution : lever l’exclusivité entre les deux modes de calcul.
Affichage des données complémentaires dans le nom d’enregistrement du protocole de commission
Périmètre d’application : ce fonctionnement s’applique uniquement pour les plans de commission linéaires.
Contexte :
Par défaut, le nom du protocole de commission est celui du plan de commission dans coog. Si un utilisateur souhaite paramétrer trois protocoles de commissions linéaires, il doit paramétrer trois plans de commissions (exemple : linéaire 5, linéaire 10, linéaire 15) et y associer trois protocoles de commissions.
Évolution :
L’objectif de cette évolution est de paramétrer un plan de commission linéaire et d’y associer trois protocoles de commission – chacun ayant une donnée complémentaire précisant le taux de commission.
De ce fait, la valeur de la donnée complémentaire est jointe au nom du plan de commission lors de la souscription d’un contrat.
Bénéfice : optimiser le paramétrage des plans et des protocoles de commissionnement.
Documents
Création d’un batch pour annuler les doublons de demandes de production de document
Contexte :
En gestion, les événements déclencheurs génèrent une demande de production de document. Si plusieurs avenants de même type sont réalisés dans la même journée, il est fréquent que plusieurs demandes de production de document soient générées.
Évolution : création d’un batch “report_production_request_batch_cancel_duplicates”.
Ce traitement passera les demandes de production de document en doublon à l’état “Annulé”. Les conditions de détection de doublon :
- Les demandes de documents sont à l’état “À traiter”,
- Le modèle de courrier est identique,
- Le contexte est identique,
- L’évènement générateur de la demande de production de document est identique,
- La date de création est différente de la date de création de la demande de production de document la plus récente.
Permettre l’impression de risques couverts à partir de l’assistant d’impression
Contexte : Les courriers sont éditables depuis un tiers, un sinistre ou un contrat, mais il n’est pas possible de générer un courrier pour un seul ou plusieurs éléments couverts d’un contrat.
Besoin métier : avoir la possibilité d’imprimer un courrier pour un contrat ou pour un seul élément couvert du contrat.
Évolution :
Depuis le wizard de génération de courrier, il est possible de sélectionner un modèle de type “Contrat” ou “Risque couvert”. La liste des courriers disponibles sera filtrée par modèle.
Ajout de la catégorie et de la famille de document
Contexte : un document dans coog était défini par sa variante et non dans l’absolu.
Besoin métier : permettre de regrouper les documents comme les formalités administratives ou médicales et de les rechercher plus rapidement.
Exemple d’application : un questionnaire médical spécifique à un assureur pourra appartenir à la catégorie « Questionnaire de santé » et à la famille “Formalités médicales”.
Évolution :
- Ajout de nouvelles notions de catégorie et de famille de documents pour regrouper les types de documents,
- Mise à jour de l’API de simulation pour retourner les documents requis regroupés par catégorie.
Processus
Gestion des tâches
Ajout d’une mécanique de modification de tâche terminée
Contexte : les tâches terminées dans coog étaient disponibles uniquement en lecture seule.
Besoin métier : modifier les informations d’une tâche terminée lorsque par exemple une erreur est constatée.
Évolution : nouveau bouton soumis à habilitation permettant de modifier une tâche terminée.
Ajout d’un champ de résumé sur le modèle de tâche
Contexte : la création de tâche ne permet pas de saisir du texte pour contextualiser la tâche.
Besoin métier : permettre la saisie d’information à destination du gestionnaire et d’accéder rapidement aux informations essentielles d’une tâche.
Évolution : nouveau champ de description en saisie libre et au format texte.
Moteur de règles
Amélioration de la mécanique des règles de filtre
Contexte :
Les règles de filtre dans les actions par type d’évènement permettent de filtrer les conditions d’application des actions par type d’évènement. Le contexte de la règle ne renvoi pas les informations permettant de filtrer sur des objets métier.
Besoin métier : pouvoir appliquer les règles de filtre sur des objets métiers (contrat, prestation, …).
Évolution : ajout dans la règle des contextes de l’objet modèle de la règle de filtre avec la clé correspondante de l’objet:
Développement d’une nouvelle mécanique puissante du moteur de règles, interrogeable par API
Approche méthodologique de l’évolution :
Lambda est le terme utilisé dans coog. On peut aussi parler de règle sur-mesure.
Évolution :
Ajout d’un mécanisme d’API qui permet de paramétrer dans coog des règles interrogeables via API. Les règles mises à disposition n’accèdent pas aux données stockées dans coog.
L’objet “LambdaAPI” se basera dans un premier temps sur un appel au rule_engine. L’algorithme de ces règles n’aura accès, en terme de données, qu’aux éléments suivants :
-
Paramètres (
rule_engine.rule_parameter) de la règle en question, -
Méthode du menu type “Outils”,
-
Tables,
-
Autres règles qui respecteront les mêmes contraintes.
Une API de documentation donnera la liste des règles et décrira les paramètres attendus en entrées.
Une API d’exécution de ces règles permettra de demander à coog d’exécuter N appels à ces règles, avec les paramètres fournis dans la requête API, et coog retournera autant de résultat d’exécution.
Assistant permettant de retrouver si une règle est utilisée et dans quel contexte
Contexte :
Il est impossible de savoir depuis une règle du moteur de règles où cette règle est utilisée (sur quels produits, garanties ou prestations). Il est nécessaire de parcourir les différents objets de paramétrage pour connaître ce lien.
Besoin métier : visualiser directement sur quel objet de paramétrage la règle est utilisée depuis la règle et non plus depuis les différents objets de paramétrage.
Évolution : depuis les règles du moteur de règles, création d’un ou plusieurs liens vers les garanties, produits et prestations sur lesquels elles sont paramétrées.
Une fonction récupère la donnée complémentaire sur la garantie offerte si elle n’est pas déjà présente sur la garantie souscrite
Besoin métier : afin de mettre en place des règles complexes s’appuyant sur les données complémentaires de type métier “garantie”, il est nécessaire de récupérer dans le moteur de règle les données complémentaires pour toutes les garanties souscrites.
Évolution : la fonction du moteur de règles “donnee_complementaire_autre_garantie_contrat” donne accès au typage garantie.
Exemple d’application : pour la mise en place d’une règle d’éligibilité, il est nécessaire de récupérer les données complémentaire de type métier “garantie”.
Noyau technique
Ajout d’un assistant qui génère le script d’anonymisation
Contexte : l’anonymisation des bases de données d’un client se fait via un script “en dur” stocké sur Docker.
Ce script ne fait pas partie de l’application à proprement parler, et ne dispose d’aucun mécanisme permettant d’éventuelles surcharges pour le compléter avec des données spécifiques.
Besoin métier : permettre de générer ce script, en l’adaptant à l’environnement sur lequel il sera lancé (modules installés, données spécifiques du client, …).
Évolution :
- Identifier les champs susceptibles de contenir des données nécessitant une anonymisation à l’aide d’un nouveau paramètre “sensitivity” valorisé à “non_sensitive” ou “sensitive_party”,
- Création d’un assistant permettant de télécharger un script d’anonymisation au format SQL.
Ce script est lançable sur une copie de la base de données depuis laquelle il a été généré afin d’anonymiser l’ensemble des données à caractère personnel.
“Non” : seules les données seront anonymisées.
“Tout effacer” : les données seront anonymisées et les versions de révision seront supprimées.
Ajout d’outillage de configuration basique pour OpenTelemetry
Évolution :
Mise en place d’OpenTelemetry pour :
- Avoir un mécanisme de logs centralisé standard,
- Suivre les appels entre les différents composants de coog,
- Pouvoir exploiter des statistiques/pattern d’utilisation.
Renommage des points d’entrée
Contexte : éviter les doublons des noms des menus composant l’application.
Évolution : ajout de menu parent pour contextualiser le résultat notamment dans la barre de recherche rapide.
Ajout d’un bouton pour annuler l’exécution planifiée d’un batch, d’une chaîne, ou d’un plan batch
Contexte : pour arrêter l’exécution ou la planification d’un batch, il faut supprimer le job puis le run, et cela même si le run possède plusieurs jobs.
Évolution : ajout d’un bouton permettant d’arrêter en une seule action la planification ou l’exécution d’un batch, d’une chaîne de batch ou d’un plan batch.
Activation de l’historique technique par défaut sur les objets de configuration
Périmètre d’application : tous les objets de paramétrage sauf les réseaux de distribution et les protocoles de commissionnement.
Contexte : pouvoir visualiser les modifications effectuées sur les objets de paramétrage.
Évolution : ajout d’un objet de visualisation de l’historique des informations de paramétrage.
Ajout d’un champ texte pour afficher une version formatée de la trace d’appels
Évolution : dans le point d’entrée “Erreurs”, il est désormais possible d’obtenir la trace d’appel au format texte.
Ajout d’un bouton pour exporter le rapport de l’erreur dans le menu Erreurs
Contexte :
L’activation du gestionnaire d’erreur permet de stocker les erreurs applicatives avec leur détail. Il est possible d’exporter via JSON ces erreurs pour les intégrer et les visualiser dans n’importe quel environnement.
Besoin métier : pouvoir générer l’export, sans avoir à installer le plugin export/import.
Évolution : ajout d’un bouton pour pouvoir exporter l’erreur au format JSON sans activation de plugin complémentaire.
coog API
Ajout de l’API de notification d’événements externes
Périmètre d’application : L’API ne sera utilisable que sur des événements « CUSTOM » et non pas avec des événements livrés par coog.
Besoin métier :
Un outil du SI externe souhaite envoyer des événements à coog. Ces événements pourront être branchés sur des actions.
Évolution :
Ajout d’une méthode à surcharger sur les type d’événement. Si on tente de notifier un événement présent dans cette liste, alors coog renverra une erreur de « Event type not found« .
Ajout du support des ReplicaSet MongoDB
Besoin métier : simplifier la gestion et assurer la compatibilité avec l’ancienne méthode de connexion à MongoDB.
Évolution : ajout une variable d’environnement qui permet de gérer les connexions en ReplicaSet sans modifier le comportement actuel avec les anciennes variables (lorsque cette variable sera utilisée, les précédentes variables ne seront pas prise en compte et seule la nouvelle variable sera utilisée).
Ajout des champs ID et date de fin sur l’API qui liste les produits commerciaux
Évolution : ajout dansl’API RPC des produits commerciaux (model.api.product.list_commercial_products) des champs :
- “commercial product id”,
- “technical product id”,
- “commercial product end date”.
Ajout des ressources Web sur l’API des produits commerciaux
Besoin métier : afficher les produits commerciaux regroupés par famille.
Évolution : renvoi des “web.ui.resource” dans l’API “list_commercial_products”.
Ajout de l’API V2 de fermeture des sinistres
Besoin métier :
La fermeture d’un dossier de prestation dans un outil externe doit redescendre dans coog. Le motif de fermeture/sous statut doit également être transmis.
Évolution : ajout de l’API de fermeture des sinistres.
Ajout d’une API pour la création et la mise à jour des prestations Santé
Besoin métier : la création et la mise à jour des prestations Santé depuis un outil externe doit redescendre dans coog.
Évolution : ajout d’une API de création et de mise à jour des prestations Santé.
GraphQL
Ajout d’une API GraphQL de recherche de tiers par IBAN
Besoin métier : les informations des comptes bancaires doivent être récupérées par les SI externes ou un espace assuré.
Évolution : ajout d’une API de recherche des comptes bancaires via un filtre obligatoire sur l’IBAN.
Ajout d’un point d’entrée de devis sur B2B GraphQL
Besoin métier : les requête GraphQL ne remontent pas les devis.
Évolution : ajout dans le “b2b_dashboard_query” du point d’entrée Devis (ces derniers seront disponibles en-dessous du point d’entrée contrats).
Création du point d’entrée GraphQL pour consulter les régimes et les caisses d’affiliation
Contexte : un Front veut pouvoir charger depuis coog les informations du référentiel des Régimes Obligatoires et les organismes de rattachement.
Évolution : création d’une API GraphQL de référentiel permettant d’interroger les référentiels.
coog Front-Office
Espace assuré (B2C)
Ajout d’une mécanique d’emailing pour l’espace personnel
Contexte : ajout d’un processus sécurisé et automatisé de création d’espace assuré.
Évolution : nouvelle mécanique de création de l’espace personnel de l’assuré via l’envoi d’un email depuis le Front.