04 avril 2025 – Release notes

Deux sujets coog advance livrés dans cette version 25.14 : la lutte contre la fraude documentaire avec le développement d’une API pour s’interfacer avec un expert anti-fraude et l’approfondissement du module RGPD avec un premier chantier technique indispensable.

Sans oublier deux autres nouveautés majeures disponibles en standard pour tous les utilisateurs de coog : la mise en œuvre de la fiscalité sur les prestations décès en prévoyance et le développement d’une interface avec Docusign pour la signature électronique des documents.

coog advance

Fonctionnalités réservées aux contributeurs de l’offre de maintenance évolutive.

Lutte contre la fraude documentaire

Développement d’une interface avec une solution anti-fraude

Contexte : les acteurs de l’assurance ont besoin d’analyser certains types de documents afin de lutter contre la fraude.

Évolution

Pour répondre à ce besoin, coopengo a choisi de créer un connecteur standard avec CTMS, l’expert anti-fraude depuis 25 ans, pour :

  • Analyser les types de documents suivants
    • Documents d’identité
      • Carte nationale d’identité
      • Passeport
      • Titre de séjour
    • IBAN / le RIB
      • Exemples : vérifier que l’IBAN pour les prestations n’a pas déjà été enregistré avec une autre identité, qu’il appartient bien à la personne saisie, etc.
    • Justificatifs de domicile
      • Selon des modèles de documents des principaux énergéticiens, opérateurs de télécom
        • Ex. : justificatif d’abonnement EDF, ENGIE.
      • Taxe foncière, avis d’impôt (vérification du “code barre” 2D-Doc)
      • Autres documents de manière brute (quittance de loyer, attestation d’hébergement, fournisseur d’eau, etc.)
  • Détecter les falsifications
  • Et permettre aux acteurs de l’assurance de les investiguer

Qui est CTMS ? Plus d’infos en cliquant ici

Réglementaire

Approfondissement du module RGPD

Contexte

Il s’agit d’une première étape technique dans le cadre de l’approfondissement du module RGPD à différents niveaux.

L’archivage intermédiaire repose dans coog sur l’inactivation des tiers.

Ce qui implique deux besoins métier :

  • Gestion des habilitations autour de l’accès aux tiers inactivés
  • Réflexion sur la performance et l’architecture technique

L’archivage définitif est basé sur l’anonymisation des données.

Ce qui implique également :

  • Optimisation des règles d’anonymisation voire de suppression réelle
  • Protection des données de santé portées par des documents médicaux

Évolutions

Catégoriser les données au niveau des champs et différencier les données à caractère personnel du paramétrage en vue de :

  • Fiabiliser l’anonymisation,
  • Avoir des règles d’anonymisation client par client.

Cas d’usage

Mettre à disposition du support et des développeurs des bases des données qui contiennent le paramétrage de production client sans données à caractère personnel grâce à un nouvel outil d’extraction (cf. Outil d’échantillonnage de données dans Noyau technique) en vue d’optimiser le traitement des demandes clients.

Exemple : corriger une anomalie plus rapidement grâce à l’extraction des données anonymisées d’un contrat depuis le menu d’administration.

À noter, cette évolution est aujourd’hui disponible uniquement pour les contrats. Demain, il sera possible d’extraire les données anonymisées d’un sinistre ou d’un tiers.

Ajout d’un batch de mise à jour des risques LCB-FT de l’ensemble des tiers

Évolution : création d’un batch permettant de vérifier la population existante sur la base de données.

Ce batch est disponible pour l’interface standard avec BeCLM ou pour tout autre partenaire.

coog Back-Office

Fonctionnalités disponibles en standard pour l’ensemble des utilisateurs de coog.

Sinistres

Mise en œuvre de la fiscalité sur les prestations décès (Art. 990i et 757b)

Contexte : appliquer les droits de succession et/ou le prélèvement forfaitaire prévus dans les articles 757b et 990i du Code général des impôts sur les prestations décès.

Évolutions

  • Création des deux dispositifs fiscaux
  • Livraison de règles en standard pour :
    • L’article 990i
      • Calcul des retenues en fonction des tranches du capital à verser
      • Calcul des primes versées après le 13 octobre 1998 et antérieurs aux 70 ans de l’assuré
      • Gestion des exonérations au titre de l’article 990i du CGI
      • Gestion des capitaux déjà imposés (dans et hors coog)
    • L’article 757b
      • Gestion des demandes de justificatifs fiscaux

  • Évaluation de la fiscalité pour chaque bénéficiaire lors de la saisie d’une prestation décès

Enrichissement de l’avenant “Changement de compte bancaire de prestations”

Évolution : pouvoir créer un compte bancaire directement via un IBAN depuis l’avenant “Changement de compte bancaire de prestations” disponible sur le tiers.

Amélioration de l’ergonomie de l’assistant de calcul des indemnisations

Évolution : affichage des détails d’une indemnisation directement en vue formulaire lorsqu’il n’y a qu’un seul bénéficiaire.

Exemple avec un seul bénéficiaire

Exemple avec plusieurs bénéficiaires

Calcul automatique des taxes sur les indemnisations

Besoin métier : automatisation du choix des contributions sociales à retenir sur les prestations à verser.

Exemple

Les prestations ITT sont soumises aux prélèvements sociaux dans le cadre de PASRAU. Le taux de CSG à appliquer sera calculé en automatique par coog grâce à l’utilisation d’une règle.

Évolution

Création des objets suivants :

  • Situations fiscales,
  • Champ sur les tiers pour alimenter la situation fiscale,
  • Fonction du moteur de règles pour déterminer les taxes à appliquer en fonction de la situation fiscale sur le tiers,
  • Règle sur le paramétrage de la prestation pour calculer en automatique les contributions à appliquer.

Gestion du versement des prestations (échu ou à échoir)

Contexte : pour certaines prestations, notamment en collectif, il est nécessaire de pouvoir déterminer la périodicité du versement des prestations (échue ou à échoir).

Évolution

Ajout d’un mode de versement des prestations sur le paramétrage des prestations :

  • En individuel, la valeur est renseignée par défaut à “Échue”,
  • En collectif, la valeur “À sélectionner sur le contrat” permettra de définir le mode de versement lors de la saisie du contrat.

Ajout de nouvelles fonctions dans le moteur de règles qui retournent le total des indemnisations payées par type « capital » et « période »

Évolutions :

  • Création d’une fonction du moteur de règles « total_des_capitaux_sur_ce_sinistre » qui renvoie le total des indemnisations de type capital présentes sur un sinistre,
  • Création d’une fonction du moteur de règles « total_des_periodes_sur_ce_sinistre » qui renvoie le total des indemnisations de type période présentes sur un sinistre.

Ajout d’un bouton « Nouvelle indemnisation » sur la vue formulaire des bénéficiaires

Évolutions :

  • Ajout d’un “nœud” bénéficiaire dans la vue arborescente des dossiers sinistres,
  • Ajout d’un bouton permettant de lancer l’assistant de saisie d’indemnisation dans la vue formulaire des bénéficiaires.

Les demandes de décisions peuvent être révisées depuis le préjudice d’un sinistre

Contexte : pouvoir demander une nouvelle décision d’analyse médicale suite à une aggravation, par exemple, tout en conservant la décision initiale pour traçabilité.

Évolution : ajout d’un bouton “Nouvelle demande de décision“ sur les préjudices.

Gestion des documents périssables sur les sinistres

Contexte

Dans la continuité de la fonctionnalité de gestion des documents périssables livrée en 23.41, les documents périssables peuvent désormais être appliqués aux dossiers sinistres.

Évolutions :

  • Création d’un point d’entrée pour le paramétrage des procédures de relance,
  • Création d’un nouveau batch chargé de générer les courriers de demande de pièces.

Ajout de données complémentaires aux demandes de décisions sinistres

Contexte : dans le cadre des demandes de décision médicale lors de l’étude des dossiers sinistres, il peut être nécessaire de gérer des données complémentaires pour le médecin conseil (taux d’IPP par exemple).

Évolutions

  • Création d’un nouveau type métier pour les données complémentaire : type de demande de décision.
  • Ajout des données complémentaires dans le processus de gestion des demandes de décisions sinistres

Ajout d’une fonction dans le moteur de règles (valeur_reduite_contrat)

Évolution : cette fonction retourne le montant total de la valeur réduite (reduction_value) de toutes les garanties actives sur le contrat.

Documents

Signature électronique

Développement d’une interface standard avec Docusign

Évolutions

  • Création d’un module « docusign_electronic_signature » et gestion des données d’authentification via une clé d’intégration, une clé secrète et une paire de clés RSA
  • Ajout d’un bouton de génération de l’url de validation pour permettre l’accès de coog à Docusign
  • Gestion de la génération des enveloppes Docusign par document à signer
  • Consultation du statut de la demande de signature
  • Ajout d’une route de callback pour mettre à jour le statut de la signature
  • Possibilité de mettre à jour manuellement le statut de la signature

Tout autre connecteur peut être développé.

Éditique

Ajout du champ « Aide » dans la vue formulaire des paramètres de courrier

Évolution : pouvoir paramétrer des aides à destination des utilisateurs pour la saisie des paramètres de courrier.

Générer un flux générique Bdoc par défaut pour les contrats

Évolution : mise à disposition, dans coog, un flux XML de type Bdoc pour les courriers des contrats présentant les informations principales d’un contrat, pour le périmètre métier de la prévoyance.

Enrichissement de la fonction « get_future_invoices »

Évolution : ajout d’une colonne payment_amount qui permet d’afficher le montant restant à payer sur les lignes à payer.

Contrats

Finalisation automatique des analyses de risque à la réception du dernier document requis via API

Contexte : acceptation des surprimes par les assurés via API.

Évolution

Lorsque l’analyse de risque est soumis à un accord sous condition, un document requis bloquant est créé dans coog (un document qui reprend la nouvelle proposition d’assurance à signer).

Dès réception du document par API (via signature électronique par exemple), l’acceptation est automatiquement enregistrée avec la date de réception du document, et permet d’activer le contrat sans intervention d’un gestionnaire.

Remboursement automatique des trop perçus lors de la résiliation d’un contrat

Évolution

Mise en place d’une mécanique de remboursement automatique des trop-perçus suite à la résiliation ou à la renonciation (sans effet) d’un contrat enregistré avec prélèvement grâce à la création d’un nouveau batch (en cas d’échec sur un contrat, une tâche est automatiquement créée pour permettre le remboursement manuel du trop-perçu

Ajout d’un bouton sur la vue formulaire du contrat pour permettre la génération manuelle d’une carte de Tiers Payant

Évolution

Générer manuellement une demande d’édition de carte TP en dehors de tout avenant. La carte TP sera éditée avec les informations présentes à date dans coog.

Ajouter des réductions de type mois gratuits sur les contrats

Contexte : dans le cadre de certaines opérations promotionnelles, il est nécessaire de proposer des mois gratuits à la souscription d’un contrat.

Évolution

En plus des réductions commerciales en pourcentage de la cotisation ou en montant, il est désormais possible de paramétrer des mois gratuits. Ces réductions pourront être d’un mois complet ou d’un pourcentage de la cotisation pendant X mois.

Ajout d’un batch qui avance automatiquement le processus de souscription d’un contrat

Contexte

Lorsque les devis sont injectés par API, il arrive que ces derniers soient bloqués à l’étape de demande de document. Une fois les documents reçus il est nécessaire pour les utilisateurs de coog de reprendre les devis et de les faire avancer manuellement.

Évolution : création d’un batch qui vérifie sur chaque devis si l’état peut être avancé sans intervention de l’utilisateur.

Initialisation de la date d’effet d’un avenant lorsque la définition choisie utilise l’avenant unitaire “Gestion de la fréquence”

Évolution : alimentation de la date d’effet de l’avenant avec la date du lendemain de la dernière quittance payée.

Gestion des surprimes en pourmillage

Évolutions

  • Sur une garantie, il sera possible de paramétrer une règle qui renverra le montant assuré. Cette règle pourra par exemple renvoyer simplement le contenu d’une donnée complémentaire.
  • Sur les garanties souscrites pour lesquelles il existent une règle de montant assuré, et seulement sur celle ci, il sera possible de saisir une surprime avec le type de calcul “Pourmillage sur montant assuré”.
  • API : ajout du champ “Pourmillage sur montant assuré” dans la consultation GraphQL d’une garantie souscrite.

Moteur de règles

Affichage des écarts d’algorithme entre les versions d’une règle

Évolution

Il est désormais possible de comparer deux versions d’une règle.

  • Une ligne verte représente la nouvelle version de la règle.
  • Une ligne rouge représente l’ancienne version de la règle.
  • Une ligne bleue représente un ajout.

Ajout d’un avertissement dans le cas d’une erreur

Évolution : les lignes avec une erreur de syntaxe ou de conversion sont identifiables plus rapidement.

Noyau technique

Outil d’échantillonnage de données

Contexte : dans le cadre des analyses et corrections d’anomalies, il arrive que les développeurs doivent récupérer des données contextualisées imitant les conditions de l’erreur rencontrée par le client.

Évolution

Création d’un wizard accessible uniquement aux utilisateurs administrateurs :

  • Un assistant d’extraction des données retournant un JSON lisible par coog comprenant le contexte d’exécution ainsi que les données a réinjecter,
  • Un assistant permettant d’anonymiser ces données,
  • Un assistant pour insérer ces données dans une base de configuration propre.

 Autoriser une chaîne de batch à continuer malgré l’échec d’un batch

Évolution : ajout d’un paramétrage permettant d’exécuter ou non les batch suivants un batch en erreur dans une chaîne.

Ajout d’un assistant permettant de télécharger les logs d’exécution d’une exécution de batch

Contexte

Les logs sont exportables opération par opération. Un batch avec plusieurs opérations nécessite de réaliser plusieurs fois la même action.

Évolution : ajout d’une action permettant de télécharger tous les logs fonctionnels de toutes les opérations d’un batch.

Cotisations

Ajout d’un batch de délettrage automatique

Contexte et cas d’usage

Certains cas de gestion peuvent générer un manque dans le lettrage :

  • Un prélèvement au 5 octobre est indiqué comme réussi
  • Le 1er novembre, envoi de la bande de prélèvement du 5 novembre 2024.
  • Le 5 novembre, le prélèvement du 5 novembre est notifié réussi
  • Le 7 octobre, un rejet de prélèvement est reçu pour le prélèvement du 5 octobre
  • La quittance d’octobre sera donc non lettrée tandis que la quittance de novembre sera lettrée.

Évolution

Création du batch « Délettrage automatique des quittances de contrat » dans la chaîne de lettrage, qui détectera les contrats sur lesquels il existe des manques de lettrage . Sur chaque contrat détecté par ce batch, le traitement consistera à dé-lettrer toutes les quittances qui suivent le premier manque, puis réétudier et recommencer jusqu’à ce qu’il n’y ait plus de manque.

Le re-lettrage des contrats sera assuré par le batch suivant dans la chaine (batch existant “Lettrage automatique des quittances contrat”).

Commissions

Ajout de nouveaux champs journaux dans la configuration financière

Contexte : différencier le journal comptable à utiliser pour les bordereaux de commission courtier et les bordereaux de commission assureur.

Évolutions

Ajout de deux nouveaux champs dans la configuration financière :

  • Journal comptable pour les bordereaux assureurs de prime,
  • Journal comptable pour les bordereaux courtiers.

Migration

Ajout de points d’entrée pour permettre la consultation des données du berceau de migration

Contexte : faciliter le travail d’analyse sur les données de staging lors des run de migration.

Évolution : ajout des points d’entrée pour consulter les données migrées, ce point d’entrée contiendra l’ensemble des enregistrements migrés/à migrés.

Lorsqu’un enregistrement est en erreur, un champ permet de savoir pourquoi l’enregistrement est en erreur, l’enregistrement devient alors modifiable pour apporter la correction nécessaire.

Ajout de nouveaux traitements de migration

Évolutions

Création de nouveaux traitements de migration pour prendre en compte :

  • Les prestations annexes,
  • Les éléments couverts racine,
  • Les analyses de risque de niveau contrat,
  • Les exclusions d’option,
  • Les bénéficiaires sur les garanties des contrats.

Mise à jour des traitements de migration existants

Évolutions

  • Mandats SEPA : ajout d’un statut de mandat par défaut.
  • Contrat : prise en charge des formules de garantie.
  • Réductions commerciales : prise en compte des réductions de type contrat et garantie.
  • Lignes de quittance : gestion des exonérations.
  • Tiers : prise en charge du pays du décès.

coog API

API de mise à jour des réseaux de distribution

Évolution : la mise à jour du champ « block_payments » à “Oui” n’implique plus la fermeture du protocole de commissionnement.

Mise à jour de l’API existante de création de relevé

Contexte : permettre d’intégrer des relevés sur des journaux différents.

Évolutions :

  • Possibilité d’identifier le journal sur lequel créer le relevé,
  • Les objets « party » et « contract » peuvent être identifiés grâce un « code/number » ou un « id ».

Mise à jour de l’API de consultation contrat

Évolution

L’API permet désormais de récupérer :

  • La catégorie et la famille d’un document requis sur les documents requis,
  • Le détail d’une analyse de risque d’un contrat.

Création d’API afin de visualiser dans coog un document stocké dans un outil externe

Évolution

Création d’un écosystème d’API pour permettre de manipuler dans coog des documents stockés dans une GED externe :

  • API de visualisation,
  • API d’intégration de la référence du document de la GED externe.

API de pièces jointes (Attachments) : créer, récupérer et télécharger les pièces jointes.

Évolution

Création d’une API permettant de gérer les pièces jointes :

  • Télécharger,
  • Mettre à jour,
  • Supprimer des fichiers.