3 avril 2026 – Release Notes

À l’occasion de la sortie de cette dernière version de coog, nous avons le plaisir de vous présenter :

  • le nouveau portail donnant accès à l’ensemble des documentations et aux informations liées à l’usage de nos API,
  • l’enrichissement d’API existantes,
  • la création de nouvelles API, notamment pour les espaces RH de nos clients finaux en assurance collective.

Nous exposons également dans cette annonce de version des avancées sur le réglementaires. Plusieurs évolutions sont notamment livrées pour la DSN (Déclaration Sociale Nominative), concernant le traitement de fiabilisation des encaissements / affectations.

coog API

Création d’un nouveau portail API

Besoin : centraliser au même endroit l’ensemble des informations utiles, pour les clients utilisateurs d’API coog.

Évolution : mise à disposition, via VPN, d’un nouveau portail donnant accès à l’ensemble des documentations et aux informations liées à l’usage des API coog.

  • Documentation REST – API v2 et v3
    • Les documentations REST sont accessibles via une interface Swagger / OpenAPI avec :
      • Un mode non authentifié permettant une consultation libre,
      • Un mode authentifié permettant de tester les Endpoints.
  • Documentation GraphQL – API v4 (GraphiQL)
    • Les APIs GraphQL disposent d’une interface GraphiQL, permettant :
      • D’explorer le schéma,
      • De tester les requêtes de consultation.

Contrats

Enrichissement des API contrats

Évolution : ajout du statut (résilié, actif, suspendu) de l’élément couvert dans les API contrats.

Utilisation de ROLLBACK TO SAVEPOINT de PostgreSQL pour les simulations contrats

Besoin

Actuellement, certains traitements sont déclenchés au Commit* de la transaction. De ce fait, le premier Commit peut déclencher des traitements asynchrones alors que la transaction d’origine continue de travailler. Ce qui donne lieu à des problèmes d’accès concurrents entre la transaction d’origine et la tâche asynchrone.

Évolution : utilisation du mécanisme de ROLLBACK TO SAVEPOINT de la base de données PostgreSQL.

*L’anglicisme Commit est un terme technique PostgreSQL (base de données) qui désigne l’enregistrement effectif d’une transaction.

Facturation

Paiement

Nouvelle API permettant de consulter les remboursements de sinistres

Besoin : permettre de rechercher les remboursements de sinistres pour pouvoir les afficher sur un espace RH.

Évolution

Création d’une API permettant de consulter :

  • Les informations du remboursement (account.invoice),
  • Les tiers (destinataire du paiement et bénéficiaire),
  • La société parente,
  • Les informations de paiements (virement / chèque, …),
  • Les détails d’indemnisations,
  • Les informations des lignes et notamment le lien avec la période d’indemnisation.

Les filtres pour rechercher les remboursements sont les suivants :

  • La date de facturation,
  • Le destinataire du paiement sur la quittance,
  • La société parente.

Sinistres

Enrichissement de l’API de création des sinistres

Évolution : création des relations entre tiers lors de la création des dossiers sinistres.

Tâches

Évolution de l’action par type d’évènement de création de tâche

Contexte

Lors de la création d’une tâche en automatique dans le cadre d’une action par type d’évènement ou par API, la tâche est créée en brouillon. Elle doit être passée manuellement au statut à affecter.

Évolution : pouvoir paramétrer le statut de la tâche dans les actions par type d’évènement pour éviter un traitement manuel.

Tiers

Nouvelle API permettant de consulter les tiers

Évolution : création d’une API permettant de récupérer l’ID coog d’un tiers sur la base d’une recherche par identifiant externe de tiers.

Nouvelle API d’ajout d’identifiant externe sur les contrats

Évolution : pouvoir ajouter les identifiants de contrat en cours de vie.

Propagation des modifications d’adresse dans les avenants de Tiers par API

Évolution : enregistrement d’une date de fin à J-1 sur l’ancienne adresse lors de la saisie d’un avenant de changement d’adresse.

Propagation de la création d’adresse aux relations via API

Évolution

Propagation d’un avenant de changement d’adresse sur l’ensemble des tiers en relation avec le souscripteur du contrat.

Concrètement, l’utilisateur API a la main. Il liste les codes tiers sur lesquels il veut propager les nouvelles adresses.

Nouvelle API permettant de modifier les informations de protection sociale

Évolution

Création d’une API permettant de modifier :

  • Les données de protection sociale (grand régime, caisse, …),
  • Le top TNS,
  • La période d’exercice fiscal.

Enrichissement des API d’avenant

Évolution

Ajout de deux avenants :

  • Modification date de naissance,
  • Modification numéro de Sécurité sociale.

coog Back-Office

Réglementaire

DSN

Prélèvement DSN

Besoin

Dans le cadre de la DSN, il arrive que le montant contenu dans l’ordre de prélèvement soit différent du montant de la balance de tiers.

La présence d’une balance de tiers négative ne doit pas impacter les montants de prélèvements, les montants à prendre en compte sont les montants contenus dans la DSN transmise.

Évolutions

  • Création d’une nouvelle méthode de traitement

  • Création d’un nouveau Batch de traitement qui permet d’intégrer les paiements DSN qui généreront (selon le paramétrage) des prélèvements SEPA. Un deuxième Batch intègre les affectations DSN qui assignent ces paiements aux bordereaux d’appel, permettant de les payer automatiquement.

Base de cotisation DSN

Évolution

Création de traitements permettant de :

  • Lire les informations salariales qui servent d’assiette aux cotisations du contrat collectif,
  • Les extraire au moyen d’une mécanique d’amorçage,
  • Les charger sur les éléments couverts des salariés du contrat collectif.

Ces informations seront disponibles dans le moteur de règles afin d’estimer les montants des bordereaux d’appel par exemple.

SEPA

Enrichissement des contrôles de présence du BIC lors des amorces de mandat SEPA

Besoin

Suite à l’exécution du Batch de création des mandats SEPA, il n’est pas possible de créer un mandat SEPA si l’amorce du mandat contient un BIC alors que la personne morale n’en possède pas. Le Batch account.payment.sepa.mandate.create échoue avec une erreur : “Aucune banque trouvée avec le BIC.”

Évolution

Les règles de création de mandat évoluent pour prendre en compte les différents cas :

  • Si présence du BIC dans l’amorce et absence de BIC sur la personne morale, le mandat sera créé.
  • Si présence du BIC dans l’amorce et présence du même BIC sur la personne morale, le mandat sera créé.
  • Si présence du BIC dans l’amorce et présence d’un BIC différent sur la personne morale, levée d’une erreur.
  • Si absence de BIC dans l’amorce, le mandat sera créé.

Ces règles s’appliquent également sur les mandats révoqués.

PASRAU

Ajout d’un contrôle de cohérence sur le NIR

Évolution : ajout du contrôle de la cohérence entre le NIR et le code INSEE de la commune de naissance pour vérifier si les chiffres de 6 à 10 du NIR correspondent au code INSEE de la commune de naissance.

Gestion des régularisations

Besoin : pouvoir générer le bloc S21.G00.56 – Régularisation du prélèvement à la source permettant de déclarer les régularisations dans les flux PASRAU introduit par la norme P20V02.

Évolution : enrichissement de l’assistant de saisie des régularisations pour pouvoir sélectionner les types d’erreurs.

Les balises alimentées dans le flux PASRAU dépendront du type d’erreur sélectionné sur la régularisation.

Contrats

Contrats collectifs

Assistant de gestion des interlocuteurs de prestations

Évolution : création d’une action à partir du contrat permettant de modifier les interlocuteurs de prestation sans devoir passer par l’assistant de gestion des interlocuteurs de cotisation.

Avenants contrats

Batch de suppression des brouillons d’avenants obsolètes

Évolution : création d’un Batch permettant de supprimer les avenants en brouillon selon une durée paramétrable.

Santé

almerys

Consolidation des mouvements du flux V3

Besoin : en cas de multiplication des avenants sur un même tiers, il est nécessaire d’adresser un mouvement unique.

Évolution : consolider l’ensemble des évènements sur un tiers pour envoyer une image unique dans le flux V3.

Demander l’édition d’une carte de Tiers payant

Évolution : création d’une action depuis un contrat pour pouvoir demander l’édition d’une carte de Tiers payant depuis un contrat.

Noémie

Enrichissement des logs d’événement

Besoin : enrichissement du log d’événement en cas de rejet ou de signalement Noémie.

Évolution : ajout du code rejet et du libellé dans le log d’évènement Noémie.

Enrichissement des mouvements 929

Évolution : pouvoir intégrer les retours 929 de type “M” (Modification) en complément des type “A” (Annulation) et “C” (Création).

Les mouvements de type “M” seront intégrés dans les mouvements 929 non rapprochés.

Tiers

Contrôle de modification du RIB sur un tiers

Évolution : ajout d’un message d’erreur à l’ajout d’un compte bancaire sur un tiers si ce compte bancaire appartient à un tiers de configuration.

Affichage de la date de signature sur la vue liste des mandats d’une personne morale

Avenants tiers

Autoriser le changement d’information RO (régime obligatoire) à une date antérieure à la date du jour dans le cadre de la gestion Noémie

Exemple

Proposer un nouvel avenant unitaire permettant de modifier le régime spécial (Alsace-Moselle par exemple) et / ou l’information TNS avec une date d’effet antérieure. Cela permet de recalculer le contrat Santé et répercuter les conséquences tarifaires sans avoir à impacter la noémisation.

Blocage des prestations après le décès de l’assuré

Évolution : mise en place d’un message bloquant pour empêcher la saisie, le calcul et le paiement d’une prestation à tort, lors du calcul d’une prestation sur un assuré décédé.

Ajout d’un enregistrement lié sur les préjudices

Évolution : ajout d’un enregistrement lié sur les préjudices pour visualiser les prestations liées à ce préjudice.

Évolution du traitement de calcul automatique des rentes

Besoin

Certaines prestations récurrentes de type rente peuvent nécessiter une intervention gestionnaire ponctuelle. En effet, la poursuite du calcul ou le montant à régler nécessite des prises de décision et des saisies d’éléments complémentaires par exemple.

Exemple de cas métier

Les rentes Éducation sont versées tant que le bénéficiaire poursuit ses études. Le versement de la rente nécessite donc de demander chaque année un certificat de scolarité. En cas de non réception, le paiement est bloqué.

Évolutions :

  • Création d’une règle pour bloquer automatiquement les prestations de type rente,
  • Création d’un nouveau Batch de blocage du calcul des rentes,
  • Création d’un assistant pour bloquer manuellement les rentes,
  • Création d’une date de clôture sur les prestations délivrées (le Batch de calcul automatique des rentes ne prend plus en compte les prestations clôturées).

Création d’un évènement pour la facturation d’une prestation

Évolution : création d’un événement pour la facturation d’une prestation afin de pouvoir brancher une action.

Gestion des aggravations

Besoin : pouvoir déclarer des aggravations sur les préjudices (exemple : passage d’incapacité en invalidité) tout en réduisant les actions du gestionnaire.

Évolution

Création d’un assistant de déclaration d’une aggravation permettant :

  • De terminer le préjudice aggravé / initial et, éventuellement, de fermer son dossier sinistre,
  • D’ouvrir un nouveau préjudice dans le dossier existant ou dans un nouveau dossier.

Les informations suivantes sont reportées :

  • La date de début du nouveau préjudice (cette date est par défaut le lendemain de la fin du préjudice clôturé),
  • La date de survenance du sinistre initial,
  • Le montant des différents salaires de l’assuré ainsi que ses primes,
  • Les prestations annexes,
  • Les éventuelles données complémentaires lorsqu’elles sont identiques entre les deux préjudices.

Cotisations

Création de réduction commerciale sans période définie

Évolution : la date de fin de la réduction commerciale devra être saisie lors de l’ajout de la réduction commerciale sur le contrat.

Paybox

Mise en place du protocole 3D Secure V2

Évolution : intégration de la version 2 de la norme 3D Secure lors des communications avec Paybox.

Facturation

Comptabilité

Enrichissement du fichier de comptabilité analytique

Évolution

Ajout d’informations permettant de rapprocher les lignes de comptabilité générale et celles de comptabilité analytique :

  • Un indicateur permettant d’identifier que la ligne fait l’objet d’un détail analytique ainsi que l’ID du détail,
  • L’ID de la ligne de comptabilité générale afin de permettre d’identifier facilement le regroupement.

Documents

Assistant de modification de date de demande de document sinistre

Besoin : dans le cadre des dossiers sinistres, la date de demande de document est alimentée à la date du jour d’ouverture du sinistre. Cependant dans certains cas, cette date ne correspond pas et la demande de document n’est pas correcte.

Évolution : création d’un assistant permettant de modifier la date de demande de documents.

Enrichissement de la gestion des relances de documents demandés

Besoin : faire évoluer la procédure de relance de document pour ne plus faire démarrer la relance de demande de document le jour de la création de la demande.

Évolutions

Ajout d’un champ pour définir le délai pour la première demande.

Les champs existants suivants ont été réorganisés sur la vue pour plus de lisibilité :

  • Le délai avant la péremption de la 1ère demande,
  • La fréquence des relances,
  • Le nombre maximum de relance.

Enrichissement du flux Bdoc

Évolutions

  • Flux contrats : ajout de la date d’ajournement de la décision médicale.
  • Flux paiements regroupés : ajout de la date de rejet.

Signature électronique

Utilisation des ancres pour les documents Docusign

Besoin : remplacement de l’utilisation des coordonnées par un mécanisme d’ancrage sur les documents.

Évolution : ajout du mécanisme d’ancrage pour la signature et la date de celle-ci.

Moteur de règles

Enrichissement de la fonction “Nombre d’autres contrats souscrits”

Besoin : pouvoir créer une règle de validation de contrat en s’appuyant sur le statut (exemple : “Résilié”) et le sous-statut (exemple : “Résiliation contentieuse”).

Évolution : création d’une fonction du moteur de règles prenant en paramètre le code produit, le statut et le sous-statut du contrat.

Création d’une fonction du moteur de règles pour récupérer les numéros de sinistres des tiers

Évolution : création d’une fonction du moteur de règles pour récupérer le numéro d’un sinistre.

Création d’une fonction du moteur de règles pour le calcul des périodes

Besoin : faciliter le paramétrage des règles de prestations en découpant les périodes automatiquement.

Évolution : création d’une nouvelle fonction du moteur de règles pour permettre le découpage automatique.

Noyau technique

Amélioration de l’ergonomie du paramétrage des vues

Évolution

Utiliser un éditeur de code pour afficher le code XML :

  • Des étapes et des vues personnalisées des processus,
  • Des Templates des modèles de courrier de type HTML.

Ajout de Warning sur le Batch account.payment.create

Évolution : mise en place de Warning sur le traitement Batch account.payment.create en cas d’anomalie d’exécution.

Permettre la génération de rapport de stock par Batch

Évolution : générer les rapports de stock (contrat, bénéficiaire, sinistre) par Batch.

Enrichissement des conditions de déclenchement des Batch

Besoin : pouvoir paramétrer le déclenchement des Batch à des dates définies.

Évolution : création de nouvelles conditions de déclenchement de Batch via le moteur de règles.

Ajout d’un point d’entrée “Statut CRON”

Évolution : création d’un point d’entrée “Statut CRON” permettant de visualiser les éventuelles erreurs avec le CRON.

Création d’un Relate pour les actions planifiées

Évolution : création d’un Relate sur les actions planifiées pour consulter les précédentes actions réalisées.

Notification utilisateurs

Évolution

Création d’un assistant permettant d’envoyer une notification à l’ensemble des utilisateurs de coog. L’utilisateur doit avoir préalablement autorisé les notifications sur son navigateur. Les notifications peuvent informer les utilisateurs d’un redémarrage, de la fin d’une tâche asynchrone, …

Création d’événement de fin de Batch

Besoin : lever des évènements lorsqu’un Batch unitaire est terminé et plus uniquement une chaîne.

Évolution : création de 3 nouveaux types d’événements.

Ajout d’une action administrateur pour nettoyer le cache

Besoin

Certaines modifications de paramétrage ou traitements d’anomalies nécessitent de redémarrer le Back-Office. Cette action a des impacts (coupure de production, par exemple). Il est nécessaire de pouvoir vider le cache sans nécessiter de redémarrage.

Évolution : création d’une action pour vider tous les caches.

Enrichissement du Batch extraction-request

Évolution : regrouper les lignes par tiers afin de prendre en compte toutes les versions pour un même tiers.

Migration

Assistant de décomptes des éléments migrés

Besoin : extraire rapidement le nombre de lignes de migration créées suite à l’exécution du Batch de création de Stagging, ainsi que le nombre d’éléments créés suite à l’exécution des Batchs de migration.

Évolution : création d’un assistant permettant de compter les éléments migrés par traitement.

Création d’un Batch de contrôle des données complémentaires

Besoin : migrer les données complémentaires en appliquant les contrôles liés au paramétrage.

Évolution : création d’un Batch qui va comparer les données complémentaires paramétrées sur les modèles (exemple produit) et les comparer avec celles présentes sur les enregistrements (exemple contrat).

coog advance

PASRAU

Enrichissement du point d’entrée Bordereaux PASRAU

Besoin : visualiser rapidement le montant d’un bordereau PASRAU.

Évolution : afficher des montants liés au prélèvement à la source et aux contributions sociales en vue liste.