Sortie de la version 23.41 de coog

14 oct. 2023 Release note

Nouveauté majeure de coog 23.41 : pouvoir gérer automatiquement des demandes de documents à une fréquence déterminée et ainsi maintenir les couvertures des assurés – comme par exemple maintenir les enfants majeurs sous condition sur un contrat.

Cette nouvelle version de coog comprend également de nombreuses améliorations de l’ergonomie pour aider les gestionnaires et les équipes paramétrage : comme un nouvel onglet dans la configuration d’avenant ou encore les usages des données complémentaires. L’objectif de ces évolutions est de favoriser l’autonomie des utilisateurs de coog dans le paramétrage produit (time to market).

coog Back-Office

Moteur de règles

Ajout d’un message dans l’assistant d’usages d’une règle

Contexte : suite à la livraison de coog 23.14, l’assistant permet de retrouver si une règle est utilisée et dans quel contexte.

Évolution : ajout d’un message indiquant que la règle n’est utilisée par aucun objet.

Permettre à l’utilisateur d’ordonner les traces du moteur de règles par date de création

Besoin métier : permettre aux utilisateurs d’ordonnancer les traces du moteur de règles par date de création pour retrouver plus rapidement les traces d’exécution.

Évolution : mise en place d’un ordonnancement par date des traces moteur de règles.

Ajout d’un filtre sur les données complémentaires de type tiers

Contexte : les données des règles « Contexte par défaut » ne remontent pas les données complémentaires des tiers assurés mais uniquement la donnée complémentaire du souscripteur.

Besoin métier : pouvoir définir si la donnée complémentaire retournée par une règle est celle du souscripteur ou celle de l’assuré.

Évolution

Génération de deux accesseurs pour les données complémentaires de type tiers :

  • Souscripteur,
  • Élément couvert.

Désactivation en masse du mode debug des règles

Contexte

Aujourd’hui, il est nécessaire de repasser sur chaque règle pour désactiver le mode debug, de plus la suppression des traces d’erreur doit être réalisée manuellement sur chaque règle.

Évolution

Création d’un batch de nettoyage des traces d’erreur permettant :

  • L’ajout d’une action afin de désactiver le mode debug de toutes les règles en une seule fois,
  • L’ajout d’un batch de nettoyage des traces d’erreur du moteur de règles.

Mise à jour des règles de paramétrage

Contexte : nécessité d’ajouter de nouvelles fonctions dans le moteur de règles pour les règles interrogées par API lambda.

Évolutions

Création d’une entrée “Référentiel paramétrage“ dans le moteur de règles.

Ajout de fonctions dans le moteur de règles seulement dans le contexte d’outillage.

  • ‘donnee_complementaire_garantie()’ : qui permet de retourner la donnée complémentaire correspondante à la garantie.
  • ‘donnee_complementaire_protocole_commissionnement()’ : qui permet de retourner la donnée complémentaire du protocole de commissionnement.
  • ‘taxe_valeur()’ : qui permet de retourner la valeur de la taxe.

Gestion des tables de référence

Périmètre d’application : assurance collective.

Contexte : cette évolution est à destination des équipes paramétrage.

Besoin métier

Il est fréquent qu’un grand nombre de produits utilise des tables avec la même structure mais avec des lignes en entrée qui varient selon les formules (par exemple, la nature d’un arrêt de travail va conditionner un crédit d’indemnisation). De ce fait, il existe autant de table que de produit.

Il s’agit de disposer de tables dont la structure est créé à partir d’un modèle et dont la référence dans les règles et les courriers est unique afin de ne pas démultiplier les règles / les modèles de courriers.

Évolution : création de modèles de tables commun à tous les produits / formules et dont le contenu est défini sur le paramétrage des formules de garanties ou à la souscription du contrat.

Ajout de valeurs multiples dans les tables

Contexte

Fonctionnalité à destination des paramétreurs afin de réduire leur charge de paramétrage. L’implémentation des tables ne retournait qu’une seule valeur. Pour les règles nécessitant plusieurs conditions, il est donc nécessaire de créer plusieurs tables.

Exemple de cas métier : l’ancienneté de l’assuré conditionne la durée de franchise et le taux de remboursement.

Évolution : permettre de ne créer qu’une seule table pour retourner plusieurs valeurs issues d’une table.

Mettre à jour les dimensions sur une cellule

Contexte : aujourd’hui, il n’est pas possible d’ajouter une dimension à une table existante, il est nécessaire de devoir créer une nouvelle table avec les dimensions.

Évolution : un assistant “Mettre à jour les cellules”, disponible sur les cellules de la table, permet de renseigner une valeur pour la nouvelle dimension sur toutes les cellules de la table.

Rechercher / remplacer dans les règles

Contexte / Besoin : mettre à jour les règles après modification d’une fonction du moteur de règles.

Évolution : rechercher / remplacer dans toutes les règles par syntaxe Python.

Processus

Ajout des processus à la vue du produit

Contexte / Besoin métier : pouvoir paramétrer le processus de souscription directement sur le produit afin d’éviter les oublis et rendre le paramétrage plus fluide.

Évolution

Ajout d’un paramétrage sur le produit pour définir le processus de souscription à utiliser.

Pour éviter les oublis, il ne sera pas possible de valider le paramétrage d’un produit si aucun processus n’est paramétré.

Autoformater les champs XML sur les processus

Contexte

Lors du paramétrage d’étape ou de processus de gestion, il est possible de saisir des en-tête, pied de page et description de vue au format XML. Le contrôle existant est réalisé uniquement sur la validité du contenu du XML.

Évolution : autoformater les champs XML sur les processus et les étapes lors de la sauvegarde de ces champs pour faciliter la lecture.

Tiers

Ajout d’un deuxième champ email sur le tiers

Contexte : pouvoir gérer plusieurs adresses email pour les intermédiaires du réseau de distribution. Les intermédiaires, comme les courtiers ou les agents généraux, peuvent avoir plusieurs adresses email actives à la même date.

Besoin métier

Certains intermédiaires du réseau de distribution souhaitent recevoir les communications liées aux éléments financiers (bordereaux, par exemple) sur une adresse email distincte de celle recevant les communications des contrats (confirmation de l’activation d’un contrat, information de mise en demeure d’un assuré, etc.).

Évolution

Un nouveau champ email “Contact principal” de l’intermédiaire est créé. Ce dernier est dissocié du champ email “Facture”. Il est désormais possible de définir par modèle de courrier l’adresse à utiliser.

L’API de création / modification du réseau de distribution est également enrichie.

Ajout d’un contrôle sur la présence d’un email

Contexte : avoir des données cohérentes concernant les informations de communication des tiers.

Besoin métier : lorsque le tiers souhaite être contacter uniquement par email, un contrôle doit vérifier la présence d’une adresse mail active sur le tiers.

Évolutions

En création de tiers (ou modification directe de la fiche tiers), si « Email » est renseigné dans un des 3 champs suivants :

  • “Mode de communication de gestion de contrat”,
  • “Mode d’envoi des décomptes almerys”,
  • “Mode d’envoi des courriers de gestion almerys” ,

Et qu’aucun mail n’est présent sur la fiche tiers, alors un message bloquant apparait.

Ce contrôle est également appliqué lors des avenants de modification des préférences de communication.

Évolutions du compte tiers

Besoin métier : pouvoir justifier rapidement le compte tiers et la balance de tiers.

Évolutions

Enrichissement de l’assistant compte tiers afin d’afficher les paiement en cours pour justifier la balance consolidée.

Il est également possible de filtrer la balance par compte comptable (compte à payer / compte à recevoir).

Ajout d’un enregistrement lié vers les tâches depuis un tiers

Besoin métier : accéder aux tâches créées directement depuis un tiers.

Évolution : ajout d’un enregistrement lié depuis le tiers pour accéder rapidement aux tâches de ce tiers.

Contrats

Ajout de la colonne “Édité par” en vue liste sur les devis

Contexte

Certains gestionnaires procèdent aux vérifications des devis provenant de l’Outil d’Aide à la Vente. Ils contrôlent par exemple les pièces justificatives, sans activer les contrats.

Besoin métier : voir au premier coup d’œil le gestionnaire qui a édité le devis.

Évolution

Afin de permettre aux gestionnaires de reprendre les devis concernés, une colonne “Édité par” est désormais visible dans le point d’entrée “Devis” après la colonne “Produit”.

La valeur de la colonne “Édité par” sera alimentée avec l’identifiant (user) du gestionnaire ayant repris le devis pour réaliser les contrôles.

Amélioration de la vue « Organisation » pour les contrats collectifs

Contexte : la vue “Organisation” permet d’afficher des informations en lien avec l’organisation des contrats et des relations entre personnes morales.

Besoin métier

Les groupes de population auxquels sont rattachés les éléments couverts doivent être identifiables. Il s’agit de pouvoir visualiser un contrat multi groupes de populations et sociétés.

Évolution : rendre exploitable la vue “Organisation” grâce aux nœuds contrats et les nœuds relations.

Gestion des niveaux de relations d’entreprise

Contexte

Les assistants lancés pour lier les filiales au contrat ne gèrent qu’un seul niveau de relations “Sociétés fille de”.

Évolution

Les contrats peuvent désormais gérer 3 niveaux de relations d’entreprise :

  • Société mère,
  • Société fille,
  • Société fille de société fille (en général l’établissement secondaire de société fille).

Modification des données complémentaires sur un risque couvert

Contexte / Besoin métier

Le client utilisateur de coog souhaite modifier sa tarification tous les [X] ans.

Cette tarification est définie au moment de la souscription et fonction des données complémentaires du descripteur de risque et de la date de condition.

Certaines questions / réponses peuvent varier dans le temps (cycle de vie du produit / des garanties).

Le paramétrage de certaines données complémentaires est donc soumis à un versioning temporel (date début / date fin).

Évolutions

Création de variantes de données complémentaires pour pouvoir récupérer les données complémentaires depuis l’éditique ou depuis le moteur de règles en utilisant la donnée complémentaire de référence.

Ajout d’une notion de date de début et de date de fin sur les variantes de donnée complémentaire de type “Risque couvert“ pour identifier qu’il faut automatiser la sélection d’une variante au moment de la souscription / avenant en fonction de celle valide vis à vis de la date de condition.

Permettre le renouvellement désynchronisé d’un ensemble de contrats

Évolution : suppression du blocage pour le renouvellement d’un ensemble de contrats (Santé et Prévoyance) à une date différente.

Avenants Contrats

Ajout d’un onglet « Définitions d’avenants » dans la configuration d’avenant unitaire

Besoin métier : afficher les définitions d’avenants utilisées dans la configuration d’un avenant unitaire.

Évolution : ajout d’un onglet qui permet de savoir sur quels avenants, l’avenant unitaire est utilisé.

Ajout d’un avenant unitaire de gestion des informations d’un tiers

Besoin métier : tracer fonctionnellement la modification d’adresse du tiers ou de ses coordonnées bancaires.

Évolutions

  • Ajout d’un avenant de gestion des informations du tiers
  • Mise en place d’un contrôle : dès lors que l’avenant est activé la mise à jour des informations n’est plus possible directement sur la fiche tiers.

Permettre de reprendre un avenant depuis la liste des avenants générés

Besoin : pouvoir reprendre dans la vue liste les avenants pré-initialisés à la suite d’un précédent avenant.

Évolution : mise en place d’un bouton en vue liste.

Modification d’un message d’erreur lorsque l’on appartient pas au groupe d’application d’un avenant

Évolution : suite à l’ajout de la notion de groupe d’application sur les définitions d’avenants, le message a été enrichi.

Ajout d’un nouvel avenant de masse à partir d’un modèle de modification de contrat

Évolution : ajout d’un avenant de remplacement de formule prenant en charge la gestion des garanties et les données complémentaire des garanties.

Simulation d’ajout d’élément couvert sur un contrat

Besoin métier : pouvoir tarifer l’ajout d’un bénéficiaire sans création du tiers dans coog.

Évolution

Pouvoir saisir un tiers sans consommation d’une séquence de tiers (le tiers ne sera donc pas disponible dans la base tiers) afin de simuler un avenant d’ajout de bénéficiaire.

  • En cas de déclinaison de l’avenant, le tiers inactif sera supprimé.
  • En cas de validation de l’avenant, le code tiers définitif sera généré.

Sinistres

Création de l’assistant de ratio S / P

Besoin : mettre à disposition le ratio S / P (Sinistres payés / Primes encaissées) pour chaque contrat actif ou résilié.

Évolution

Le paramétrage de la configuration sera réalisé par garantie.

Ajouter des méthodes pour récupérer un montant calculé sur une période au niveau des ‘contract.option’ :

  • Montant encaissé HT,
  • Montant encaissé TTC,
  • Montant appelé HT,
  • Montant appelé TTC,
  • Montant de prestation décaissé,
  • Montant de prestation liquidé (y compris la date de prise en compte).

Évolution de la logique du paramétrage des délégations de l’assureur

Contexte : à ce jour, il est obligatoire de paramétrer une délégation pour l’assureur même en cas de délégation totale.

Évolution

Désormais, une liste vide est interprétée comme une délégation totale. Si des lignes sont renseignées, on ne force plus à être exhaustif (délégation totale par défaut).

Réglementaire

RGPD

Amélioration de l’assistant de génération des scripts d’anonymisation

Contexte : évolution qui s’inscrit dans la continuité de la création de l’assistant permettant de générer un script d’anonymisation (livraison en 23.14).

Besoin : pouvoir réaliser l’anonymisation d’une base de donnée directement depuis coog.

Évolution : ajout de l’algorithmie dans l’assistant d’anonymisation et reprise de l’ancien script d’anonymisation.

Emprunteur

Ajout d’un nouveau champ “Agence” si l’organisme prêteur est une banque

Contexte : évolution qui s’inscrit dans la continuité de l’ajout d’un nouveau champ “Agence” si l’organisme prêteur est une banque (livraison en 23.14).

Évolution : amélioration de la vue utilisée pour la recherche d’adresse de l’organisme prêteur dans l’avenant afin d’obtenir la même expérience de saisie qu’en souscription.

Ajout des montants différentiels sur les incréments de palier de prêt

Contexte

Lors du calcul des cotisations, seul le capital initial du prêt est obligatoire à la saisie. Cependant, cela n’est pas suffisant en cas d’évolution du prêt, de rachat partiel ou de déblocage de fonds successifs.

Besoin : pouvoir saisir manuellement un montant d’augmentation ou de diminution du montant nominal du prêt sur un palier de prêt.

Évolutions :

  • Ajout d’un nouveau champ pour définir les types de palier,
  • Ajout d’un nouveau champ sur les paliers pour permettre la saisie d’augmentation ou de diminution du montant nominal,
  • Ajout d’une fonction dans le moteur de règles pour récupérer le montant nominal à une date donnée.

Santé

Ajout de la notion de Travailleur Non Salarié (TNS)

Périmètre d’application : uniquement le module Santé.

Contexte : suite à l’absorption du Régime Social des Indépendants (RSI) par le régime général, la gestion des TNS nécessite de gérer une information complémentaire sur le tiers pour la gestion des attestations “Loi Madelin”.

Évolution : ajout d’un booléen sur les données de régime santé pour indiquer que le tiers est Travailleur Non Salarié.

Ajout de la notion de période fiscale

Périmètre d’application : uniquement le module Santé.

Besoin métier : il est nécessaire de pouvoir gérer les exercices fiscaux décalés dans le cadre de la génération des attestations “Loi Madelin” pour les TNS.

Évolutions :

  • Création d’un champ “Date d’exercice fiscal”,
  • Ajout d’un nouveau champ booléen sur le contrat pour savoir si le souscripteur est TNS et s’il a payé l’ensemble de ses cotisations sur le dernier exercice fiscal,
  • Création d’une méthode pour récupérer les quittances dans les modèles de courrier, les quittances concernées par l’attestation fiscale par l’exercice fiscal,
  • Création d’un nouveau type de période pour les rapports périodiques (dernière année fiscale).

NOÉMIE

Gestion du refus de Noémisation par ouvrant droit dans l’avenant

Besoin métier : pouvoir refuser la Noémisation ouvrant droit par ouvrant droit.

Évolution : enrichissement de l’avenant de modification de la Noémisation pour permettre de refuser ou d’accepter la Noémisation ouvrant droit par ouvrant droit.

Générer un modèle de courrier uniquement pour certains codes de retour NOÉMIE

Besoin métier : suite à un rejet de Noémisation, il peut être nécessaire de générer un courrier pour informer l’assuré.

Évolution : lors de la création d’une action par type d’évènement, il est désormais possible de filtrer les codes rejet NOÉMIE pour lesquels il est nécessaire d’adresser un courrier à l’assuré.

almerys

Gestion des régimes spéciaux dans le flux V3

Périmètre d’application : interface almerys pour la gestion des prestations Santé.

Besoin métier : afin de gérer les taux de remboursement du Régime Obligatoire (RO) pour les assurés du régime Alsace Moselle, il est nécessaire de communiquer l’information à almerys.

Évolution : création d’une liste des régimes spéciaux pour indiquer la notion de régime local et alimenter la balise ‘REGIME_SPECIAL’ du flux V3.

Ajout de la Noémisation de l’ouvrant-droit hors contrat de l’assuré

Périmètre d’application : interface almerys pour la gestion des prestations Santé.

Besoin métier : dans le cadre des contrats santé, il est possible d’ajouter un ayant droit sur un contrat sans que l’ouvrant droit ne soit couvert par ce même contrat afin de réaliser la Noémisation

Évolution : utiliser la notion de relation pour alimenter la V3 et permettre la Noémisation de l’ayant-droit.

Facturation

Cotisations

Supprimer le champ séquence de mandat SEPA du produit

Évolution : la séquence de mandat SEPA est paramétrée directement sur la configuration comptable et non plus sur le produit.

Correction et amélioration du système de lettrage automatique

Contexte

Le lettrage automatique est effectué dans l’ordre suivant (ascendant) :

  • Date d’échéance,
  • Date de la ligne (comptable),
  • Date de création (technique).

Cependant, les frais ne sont jamais lettrés en automatique. Dans certains cas, les dates sont identiques.

Évolution : ajouter le montant dans le tri afin de lettrer le maximum possible, même si toutes les dates sont identiques dans le cas d’un recalcul.

Ajout d’une action de dé-lettrage / re-lettrage des quittances d’un contrat

Contexte / Besoin métier : permet de remettre d’équerre les quittances d’un contrat avec l’argent disponible.

Exemple de cas d’utilisation : il est possible de générer 20 quittances sur le contrat avec l’assistant de génération, d’encaisser un chèque couvrant la totalité, puis via cet assistant de payer toutes les quittances en une seule fois.

Évolution : ajout d’une action de re-lettrage sur les quittances de contrat.

Ajout d’un journal de quittancement par défaut sur la configuration comptable

Contexte : le journal de quittancement utilisé implicitement est le premier journal typé produit (type revenue).

Évolution : ajout d’un journal produit par défaut sur la configuration comptable.

Simulation de la date de prélèvement en cas de suspension de paiement

Besoin métier : afficher sur les courriers de type échéancier la somme des impayés sur la prochaine échéance de prélèvement (théorique), selon la date de prélèvement paramétré sur le moyen de paiement.

Évolution

Simulation de la date de prélèvement de la quittance lorsque :

  • Le contrat n’est pas chuté (état actif ou suspendu).
  • La quittance est à l’état émis, mais pas en cours de prélèvement avec : date d’échéance < J, date de prélèvement = null.
  • Le mode de paiement du contrat est prélèvement, et l’état des prélèvement est suspendu.

Utilisation de filtres d’action sur les évènements de relances

Contexte : dans la continuité de l’évolution livrée en 23.14 pour permettre l’utilisation des filtres sur les actions par type d’évènement.

Évolution : pouvoir utiliser les données contrat lors de l’exécution d’une règle de filtre d’action par type d’évènement pour les évènements de relance.

Ajout de détails d’événements lors du traitement de la mise en demeure

Contexte

Lors du traitement de la génération des courriers de relance, le montant affiché se base sur des données évoluant dans le temps (réconciliation, re-quittancement, encaissement, …). La justification du montant indiqué dans le courrier est rendue difficile.

Évolution : pouvoir visualiser les balances utilisées lors de la mise en demeure (même plusieurs mois après) afin de pouvoir construire des reporting représentatifs de ce qui a été envoyé aux clients.

Comptabilité

Rechercher des lignes de mouvement sur les comptes d’attente

Périmètre d’application : cotisations collectives en déclaratif.

Contexte : dans le cadre des cotisations collectives, les encaissements sont réalisés sur un compte d’attente sans affectation automatique.

Évolution

Permettre de visualiser les lignes encaissées qui sont en attente d’une affectation ou d’un remboursement. La recherche est possible par personne morale ou par montant.

Commissions

Ajout d’un compte de paiement par défaut des intermédiaires sur la configuration comptable

Évolution : mise en place d’une compte à payer par défaut sur la configuration comptable pour le paiement des commissions.

Exemple : un courtier ne possède pas de compte, c’est le compte par défaut qui sera utilisé.

Correction de la méthode de calcul de la date de commissionnement

Correction : dans le cadre de versement des commissions aux intermédiaires de distribution (courtiers), corriger le comportement de la méthode de commission “Au paiement”, suite à une modification dans le framework Tryton.

Documents

Gestion des documents périssables

Contexte / Besoin métier

Dans le cadre de la gestion des contrats, il est parfois nécessaire de gérer des demandes de documents à une fréquence déterminée (par exemple annuellement) pour maintenir la couverture des assurés sur leurs contrats.

Si le document est reçu et conforme, l’assuré est maintenu sur le contrat. À défaut de réception, l’assuré concerné peut être radié.

Exemple d’application

Dans le cadre des contrats santé, les assurés de type enfant peut être couvert par le contrat jusqu’à leur 18 ans sans condition.

De 18 ans à 25 ans, ils doivent justifier d’une poursuite d’étude pour pouvoir être maintenu sur le contrat. Chaque année, à partir des 18 ans, nous devons donc demander à l’assuré de nous adresser son certificat de scolarité.

Évolutions

Enrichissement du paramétrage des types de documents

Ajout d’un champ booléen “Périmable” sur les types de documents

Permettre de paramétrer une règle de date de fin de validité du document

Ajout d’un nouveau modèle “Configuration de lancement d’avenant”

Ajout d’une procédure de demande de pièce permettant de définir :

  • La fréquence des relances à partir de la première demande de pièce (exemple : 2 mois, 60 jours, 10 jours , etc. ),
  • Un nombre maximum de relances,
  • Pour les documents périmables, une nouvelle pièce sera demandé avant la péremption (fin de validité de la pièce jointe) selon un champ dédié : “Délai avant la péremption pour la première demande”.

Enrichissement du moteur de règles :

  • Ajout d’une fonction dans le moteur de règles permettant de connaitre la date de fin de validité de la pièce jointe,
  • Ajout de deux fonctions dans le moteur de règles, ‘documents_demandes_assure’ et ‘documents_recus_assure’, afin de lister les documents par élément couvert actif à la date d’exécution de la règle.

Enrichissement de la gestion des documents requis

Lors de la création des lignes de documents requis (en souscription – y compris par API – ou suite à un avenant sur contrat) :

  • Si le type de document utilise une procédure, coog calculera une “Date de prochaine demande de pièce”
  • Lors de la réception d’une pièce jointe, si une date de fin de validité est calculé ou renseigné manuellement, coog recalculera la date de prochaine demande de pièce (exemple : 3 mois et demi avant la fin de validité).

Création d’un nouveau batch chargé de générer les courriers de demande de pièces.

Paramétrage d’un avenant à appliquer automatiquement lors de la réception du document. Cela permet, par exemple, de recalculer automatiquement les dates de fin des garanties lors de la réception d’un justificatif.

Validation du répertoire de sortie des modèles de courrier

Évolution : mise en place d’un contrôle sur le format du répertoire d’export pour les modèles de courriers, si ce champs comporte des caractères interdits par UNIX.

Ajout d’en-tête paramétrable lors de l’émission d’email

Besoin métier : afin de gérer la classification des emails dans le serveur, il est nécessaire d’ajouter un header spécifique pour les envois d’email.

Évolution : mise en place d’un en-tête paramétrable sur la société.

Utiliser la configuration d’email de la société par défaut

Contexte : lors du paramétrage de modèle de courrier de type email, le paramétrage de la configuration email doit être réalisé sur chaque modèle de courrier en plus de la configuration email sur la société.

Évolution

Par défaut, les modèles de courrier de type email bénéficient du paramétrage de la configuration réalisée sur la société. Il sera possible de surcharger ce paramétrage sur chaque modèle de courrier.

Éditique

Enrichissement du message d’erreur lors de la génération d’un courrier

Contexte : Lorsque la génération d’un courrier échoue, le message d’erreur généré est générique et ne précise pas le nom du courrier en échec.

Évolution : enrichissement du message pour ajouter le code du courrier en erreur.

Forcer la configuration « Scinder les documents »

Évolution : coog choisit automatiquement le bon comportement pour la case “scinder les documents” sur les modèles courriers de type bordereau (assureur et courtiers), ainsi que pour les rapports assureurs.

Ajout d’un filtre de type règle sur les modèles de courriers

Contexte / Besoin métier

Faciliter le paramétrage des modèles de courrier afin de le rendre plus accessible à des profils métier.

Conditionner la génération du courrier de façon plus fine.

Évolution : enrichir les critères de filtre des modèles de courrier avec la possibilité d’utiliser le moteur de règles pour filtrer les conditions d’édition des courriers.

GED

Permettre la configuration d’une GED externe sur une société

Évolution : ajout d’une configuration GED sur la société pour paramétrer le lien avec une GED externe.

Rapports

Ajout d’un batch de nettoyage des demandes d’extraction

Contexte

Lors d’extraction réalisée via le module ‘extractor‘, de nombreuses entrées sont créées. Ces entrées une fois traitées n’ont pas de raison d’être conservées dans l’application.

Évolution

Création d’un nouveau traitement batch ‘extraction.request.clean_up‘ prenant une date de traitement comme paramètre et un délai en jours d’avance par rapport à la date de traitement.

Ce traitement supprime toutes les ‘extraction.request‘ dont le champ traitement est inférieur à la date de traitement – délai.

Noyau technique

Ajout des versions de produit

Besoin métier : pouvoir versionner les conditions générales sur un produit

Évolutions :

  • Ajouter une méthode depuis le contrat pour récupérer la version du produit qui nous intéresse à partir d’une date,
  • Ajouter une fonction du moteur de règles permettant de récupérer le code de la version produit (à la date de condition du contrat).

Gestion des données complémentaires variantes de descripteur de risque

Contexte : cette évolution est à destination des équipes paramétrage.

Besoin métier

Dans coog, le descripteur de risques porte de nombreuses données complémentaires (groupe de population cadres / non cadres en assurance collective par exemple).

L’objectif est de ne pas démultiplier les règles et les courriers.

Exemple de cas métier en assurance individuelle : Au moment de souscription d’un contrat, des questions sont posées à l’assuré en lien avec la personne physique (fumeur / non fumeur, sport à risque, etc.).

Potentiellement, les réponses proposées aux questions peuvent être dépendantes de l’assureur.

Évolutions

Mettre en place une notion d’héritage pour les données complémentaires.

Cela permet pour un descripteur de risque d’avoir toutes les combinaisons possibles grâce à la création de variantes.

Le gestionnaire a à sa disposition des références uniques.

Techniquement, cette évolution restreint le champ des possibles. La maintenance est alors facilitée.

Ajout des usages d’une donnée complémentaire

Contexte

Il est impossible de savoir depuis une donnée complémentaire où cette dernière est utilisée (sur quel produit, quelle garantie ou prestation). 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 donnée complémentaire est utilisée depuis cette dernière et non plus depuis les différents objets de paramétrage.

Évolution : depuis les données complémentaire, création d’un ou plusieurs liens vers les garanties, produits et prestations sur lesquels elles sont paramétrées.

Interdiction de la suppression des logs d’événements, à l’exception des devis supprimés

Contexte : un utilisateur ayant les habilitations nécessaires peut supprimer une ligne dans les logs d’évènement.

Évolution : interdire la suppression des lignes dans les logs d’évènements, y compris pour l’administrateur. Cette suppression sera toute fois autorisée pour les logs d’évènement des devis supprimés.

Ajout d’un assistant de test des configurations d’email sur les sociétés

Évolution

Création d’un assistant permettant de tester la configuration (header, format, protocole, …) des emails.

Mise en place d’un mécanisme de cache pour les API token

Contexte : lors de chaque appel API utilisant un token pour l’authentification, la vérification de la validité du token dans la base de données était effectuée à chaque fois. Cela impactait les performances.

Évolution : ajouter un mécanisme de cache sur la fonction pour ne plus vérifier systématiquement la validité du token.

Ne plus stocker les données binaires dans les erreurs

Besoin

Les ‘ir.error ‘stockent l’intégralité des variables d’une erreur levée. Dans certains cas (édition de documents notamment), cela peut inclure des données binaires avec de très gros volumes de données (fichiers ODT dézippés).

Évolution : tronquer les données binaires dans les erreurs coog stockées en base.

Ajout de l’outillage pour paramétrer l’authentification OAuth 2.0

Évolution : permettre l’authentification via la norme OAuth 2.0.

Renforcement de la fiabilité de l’outillage de simulation

Contexte / Besoin métier

Dans certains cas, il est nécessaire de simuler des opérations. L’approche actuelle est de créer une nouvelle transaction sur laquelle un retour en arrière est effectué en fin d’exécution.

Évolutions :

  • Améliorer la robustesse et fiabiliser la mécanique de simulation
  • Unifier les usages de simulation

Ajout d’outillage permettant d’optimiser le chargement de fichier CSV / de données arbitraires

Contexte / Besoin métier : il est fréquent d’avoir besoin de charger des fichiers CSV.

Évolution : optimiser le chargement de fichier grâce à un outil qui va vérifier automatiquement le format de fichier, les données attendues dans chaque colonne, etc.

Gestion des scripts depuis l’interface coog

Contexte / Besoin métier

La reprise de données est une opération délicate pour les clients utilisateurs coog SaaS pour des raisons de sécurité.

Évolution

Livraison de script de reprise. Ces scripts sont lancés directement depuis l’application par les client utilisateur de coog ou les équipes support. Cela améliore le suivi de l’exécution des reprises de données, l’exploitation est facilitée.

Ajout d’un raccourci pour la mise à jour des configurations de batch

Contexte : lors de la livraison des configuration de batch via XML, la configuration n’est pas mise à jour.

Besoin métier : modifier la configuration d’un batch suite à une mise à jour de la base de données.

Évolution : créer une action sur la configuration de batch qui va à partir du nom du batch retrouvé le XML associé et mettre à jour les données en fonction de ce qui est dans le XML.

Remplacer le plugin GTK d’export groupé et de différence de révisions par un wizard

Évolution : création d’un assistant pour les fonctionnalités de debug, d’export groupé et de visualisation des révisions intégrées dans coog sans avoir à installer des plugin rendant ainsi possible les exports JSON depuis SAO

Implémenter le batch de nettoyage périodique des erreurs coog

Besoin métier : afin de stabiliser la taille de la table des objets ‘ir.coog_error’, cette dernière doit être nettoyer périodiquement.

Évolution : création d’un batch ‘error.clean’ permettant de définir une date de traitement et un délai de rétention en jours (7 par défaut) permettant de supprimer toutes les erreurs créées dans la période.

Ajout d’un mécanisme d’anonymisation de champs “Dict”

Besoin métier : suite à l’évolution livrée en 23.14 sur les scripts d’anonymisation, il est nécessaire de pouvoir configurer données par données lesquelles doivent être anonymisées.

Évolution : ajout de deux nouveaux champs sur les données complémentaires et la configuration des lignes de détails.

Un champ permettant de choisir parmi trois stratégies d’anonymisation (Ne rien faire / Nettoyer / Forcer une valeur).

  • Ne rien faire : conserver les valeurs existantes.
  • Nettoyer : conserver la clé mais valoriser avec une chaîne vide.
  • Forcer : remplacer la clé par la valeur sélectionnée.

Un champ affiché pour les données texte : sélection permettant de forcer une valeur si la stratégie correspondante est sélectionnée.

La valeur livrée par défaut est “Nettoyer”.

Espace assuré (B2C)

Ajout d’une mécanique de création manuelle d’identité Web

Contexte

L’espace assuré est créé par les actions par type d’événement “Création des identités Web” et “Générer l’email de l’espace personnel”.

Actuellement, si le souscripteur n’a pas d’email, une erreur est levée et la souscription est bloquée à la dernière étape sans possibilité d’activer le contrat.

Besoins métier

  • Conditionner la création de l’espace assuré en fonction de la présence d’un email sur le souscripteur. Un paramétrage permettra de définir cette condition.
  • Création d’un acte de gestion permettant de lancer manuellement la création de l’espace assuré.

Évolutions

  • Si l’assuré n’a pas d’email, ne pas créer d’identité Web / d’espace personnel, le gestionnaire est notifié de l’échec de la demande d’initialisation de l’espace assuré.
  • Ajout d’un bouton d’action “Création manuelle de l’espace adhérent (assuré)” sur le tiers.

coog API

Ajout du support des ReplicaSet MongoDB

Contexte : mise en place ReplicaSet MongoDB dans l’environnement de production Claranet (Coreye), afin d’améliorer la disponibilité et la tolérance aux pannes des services coog API.

Évolution

Ajout du support des ReplicaSet MongoDB dans les modules API de coog-portal suivants :

  • ‘coog-api’,
  • ‘coog-gateway’,
  • ‘coog-api-identity-manager’.

Ajout de types de documents dans l’API de consultation de contrats

Contexte : dans l’API des devis GraphQL, il n’est actuellement pas possible de savoir à quel élément couvert se rapporte une demande de document.

Évolutions

Ajout, en plus du champ existant ‘documentRequestLines’, d’un champ ‘contractDocuments’ ne contenant que les demandes de document qui se rapportent au contrat (souscripteur).

Ajout d’un champ ‘coveredDocuments’ ne contenant que les demandes liées à des éléments couverts (les demandes dans cette seconde liste ont un nouveaux champ covered).

Évolution des API de création et de mise à jour des réseaux de distribution

Évolutions

Dans les API de création des intermédiaires (courtiers par exemple), ajout des informations suivantes :

Préférence de communication et email pour communication avec l’intermédiaire comme le courtier

Code d’auxiliarisation comptable

Produits commerciaux

Email bordereaux intermédiaires (courtiers)

Création des protocoles de commissionnement :

  • Code plan,
  • Données complémentaires,
  • Date de début / date de fin,
  • L’intermédiaire (courtier).

Dans les API de mise à jour des intermédiaires, ajout des informations suivantes :

  • Produits commerciaux en ajout,
  • Liste des produits commerciaux à retirer,
  • Email bordereaux des intermédiaires (courtiers),
  • Liste des protocoles à clore,
  • Liste des protocoles à rouvrir.

Récupérer les documents filtrés par type de document sur l’API GraphQL

Contexte / Besoin métier : récupérer dans l’espace personnel de l’assuré (B2C) des documents sur les contrats et / ou les sinistres.

Évolution : mise en place d’un filtre pour récupérer des documents en fonction de leurs typologies.

Ajout de champs sur l’API GraphQL B2C (espace personnel assuré)

Évolution

Ajout du statut de la Noémisation

Ajout des quittances de contrat pour un intervalle de date donnée :

Numéro de quittance,

Périodicité de la quittance (périodique / apériodique).

Si périodique : la période de la quittance, le statut, le montant total et le montant hors taxe et le montant des taxes, puis les lignes de quittances et de taxes.

Ajout des relations des assurés avec le souscripteur avec les dates de début et de fin

Les comptes bancaires et le compte bancaire de remboursement des prestations :

  • Titulaire du compte,
  • IBAN,
  • code BIC,
  • Nom de la banque,
  • Date de début et date de fin.

Ajout de champs sur l’API GraphQL B2B

Évolution

Enrichissement de l’API de consultation des contrats avec les informations suivantes :

La date de création du contrat

Les informations de préférence de communication du tiers

Les comptes bancaires et le compte bancaire de remboursement des prestations :

  • Titulaire du compte,
  • IBAN,
  • Code BIC,
  • Nom de la banque,
  • Date de début et date de fin.

Le statut de la Noémisation

Les relations des assurés avec le souscripteur avec les dates de début et de fin

Les garanties souscrites les données complémentaires de paramétrage (typage) de la garantie offerte associée

Le code du protocole de commissionnement du contrat

Ajout de champs liés aux contrats via GraphQL

Périmètre d’application : Santé et Prévoyance.

Évolution

Récupérer l’exhaustivité des informations d’un contrat dans coog. Cela permet notamment d’intégrer des informations de couverture dans un outil tiers.

Ajout du champs sous-statut dans l’API GraphQL des contrats

Évolution : ajout du sous-statut / motif de résiliation pour les contrats résiliés.