coog version 24.14 released

April 09, 2024 Release notes

First development from coog advance in this new version 24.14! A regulatory topic integrated into the product roadmap as part of the new coog advance premium upgrade offer, and which has been implemented by coopengo since the first quarter of 2024: 3-click termination.

Discover the latest developments in coog’s major cross-functional feature: task management.

coog advance

Functionality reserved for customers who have subscribed to the coog advance premium upgrade package.

Regulatory

Termination in 3 clicks

Context: implementation of the decree on the technical modalities for terminating contracts electronically.

Online cancellation must be possible if, on the day of cancellation, the contract can be concluded electronically (as soon as the insurance, mutual or provident institution offers online subscription to one of its products, cancellation in 3 clicks must be available).

Developments

Parameterization of reasons for cancellation available in the context of 3-click cancellation

New “Configuration self-care” tab in Companies

Delivery of a new termination-specific rider in 3 clicks, with the option of configuring the requested documents

New rider delivered by default

Delivery of a new task type and scope of activity

New default task type


New activity field delivered by default

Delivery of three APIs:

  • Product descriptionAPI to return possible reasons for termination and associated document types,
  • API for returning third-party contracts based on the information entered,
  • API for creating cancellation request tasks.

3-click cancellation request integration mechanism: following validation of a cancellation request by a policyholder (individual contract) or a company (group contract), a task is automatically created in coog, along with a cancellation rider in draft form, enabling the user to carry out checks before validating the rider.

Job content received by API

coog Back-Office

Transversal functions

Task management

Enhanced functionality for distributing management activities, storing documents and indexing them.

Addition of activity fields

Business need: facilitate distribution by team, but also record activity-specific elements in the task.

Example: a link to a claims file for the claims activity, a link to a contract for the contracts activity.


Business needs: simple access to tasks by status, assignment and business activity scope, for an overview of what needs to be processed.

Evolution of the entry point with the addition of new tabs


Business need: identify tasks whose qualification has been completed and which can be assigned.

Add “To be assigned” status


Business need: define the data required to set a task to ‘completed’ status, in order to guide users’ work.

Add activity fields and validation rules for task status transitions


Add “Linked attachments” and “Tasks” linked records to different objects

Business need: easy access to tasks and attachments linked to a business object, to quickly search for information.


Add a linked record to add actions to the toolbar

Business need: add a button in the toolbar to display attachments for tasks linked to the currently displayed object.

Example: from a claim record, display the attachments of the various tasks in the claim area linked to this claim.


Business need: to be able to search for all tasks according to certain criteria.

Added contract, third party and claim fields to the task list view so that these fields can be searched.


Add a batch to archive tasks


Implementation of task creation API and task repository (types and reception channels).

Business requirement: to be able to create a task via API and add one or more attachments to it, so that they can be stored in the coog tool.


Business requirement: automatically create a task when certain events occur, such as the integration of rejected transfers.

Add one action per event type to create tasks


Business need: restrict access to certain tasks according to the team to which the user belongs.

Use the team concept to restrict the visibility of a field of activity


Third-party

Support La Poste’s hexasmal repository for updating zip codes

Upgrade

Creation of two postal address loading batches for :

  • Retrieve updated information from the La Poste repository via the API and generate a file,
  • Load a repository file, whether manually deposited or generated from the repository call.


Contracts

Search by policyholder by entering the name directly in the quick search bar

Evolution: it is no longer necessary to use the filter criteria in the Contracts and Group Contracts entry points to search for a policyholder.


Issue Madelin certificate at end of tax period

Evolution: when the period type for periodic reports is “Last fiscal year”, it is possible to choose a batch execution date.


Enhancing the schedule with risk analysis

Evolution

Display surcharges linked to risk analysis on schedules, pending customer feedback. These modifications can be retrieved from the desktop publishing module.


Claims

Claims reporting batch added

Business requirement: every first working day of the month, it is necessary to retrieve the previous month’s claims statistics.

Evolutions :

  • Creation of 2 batches to generate statistics files,
  • Delivery of a mail template.


Display of bank accounts for pre-existing payments in the context of a claim

Evolution: change the behavior of the “Bank account” field on indemnities to display the account on which the benefit payment was made.


Billing

Added settings for automatic calculation of breakdown rates

Context

In self-billing, a receipt is generated, the amount of which is equal to the total amount collected. This amount is then allocated to the various guarantees by means of a rate. Until now, this breakdown rate was calculated manually by the user.

Upgrade: automatic calculation based on the rate schedule.


Payment

Manual processing of rejected payments

Evolution

This enables the actual date to be entered when processing rejected payments manually. A control is also activated to prevent the entry of dates in the future. By default, the current date is displayed.


Modify the posting date of a rejected payment with the date of rejection (SEPA)

Context

When integrating SEPA rejection files (camt054), the rejection date is the direct debit date.

Changes

Use of the rejection creation date contained in file camt54 to populate the direct debit rejection date. If this tag is missing, the date of the file integration will be used.


New action added to payment logs

Evolution: addition of the “Re-present N day after rejection” action following a direct debit rejection.


Fonction publique

Mise en œuvre du précompte sur pension au format utilisé par le Groupe Caisse des Dépôts

Contexte

La Direction Générale des Finances Publiques (DGFiP) a lancé en 2021 un programme de restructuration du Service des Retraites de l’Etat (SRE). Les 17 Centres de Gestion des Retraites (CGR) chargés du contrôle et du paiement des pensions gérées par le SRE vont être regroupés en 4 CGR. À missions inchangées, le SRE est engagé dans une démarche de simplification et de concentration de son réseau de paiement. Dans ce cadre, le SRE a lancé un projet de refonte de son SI de paiement de retraite. Il a été décidé de mutualiser le SI paiement du SRE « PEZ » et du Groupe Caisse des Dépôts « OCAPI » (Outillage du Calcul des Allocations, Pensions et Indemnités) dans un même outil.

Évolutions

Captures d’écran réalisées dans le client léger de coog

Création d’un type de journal de paiement OCAPI


Création du mode de quittancement précompte sur pension OCAPI


Chaînes de batch dédiées à la création et à l’intégration des rejets de paiement OCAPI


Comptabilité

Automatiser la création de l’année fiscale

Évolution : ajout d’un batch permettant de créer les années fiscales.

 

 

 

Simplifier et automatiser la création des années fiscales


Amélioration de l’assistant de renouvellement des périodes des journaux

Évolution : lors du renouvellement des périodes, coog affiche désormais les périodes créées par l’assistant.


Documents

Éditique

Permettre de rechercher et remplacer le code inséré dans les fichiers ODS

Évolution : à l’image de ce qui a été mis en place pour les fichiers ODT, il est possible de rechercher les valeurs des balises hyperliens dans les modèles de courrier et de les remplacer par de nouvelles valeurs sans devoir créer un nouveau modèle de courrier.


Moteur de règles

Ajout de deux fonctions du moteur de règles pour calculer les indemnités liées à un préjudice ou fait générateur particulier

  • montant_indemnise_prejudice_assure_terme(prejudice,date) qui reprend l’ensemble des indemnisations pour un code de préjudice passé en paramètre
  • montant_indemnise_evenement_assure_terme(evenement,date) qui reprend l’ensemble des indemnisations pour un code d’événement passé en paramètre

Ajout d’une fonction du moteur de règles retournant le code du distributeur : code_distributeur()


Ajout de fonctions dans le moteur de règles pour les documents requis

Évolution : ajout des fonctions donnee_document_contrat et donnee_document_assure dans le moteur de règles afin de pouvoir récupérer les réponses renseignées dans les questionnaires en correspondance et déclencher la demande de documents complémentaires.


Ajout des types de documents aux paramètres du moteur de règles

Évolution : ajout de l’onglet “Types de documents” permettant de glisser & déposer directement dans la règle le code du document souhaité.

Évolution de la fonction _re_number_of_covered_elements

Besoin métier : permettre la gestion des bordereaux d’appel de cotisation pour les contrats collectifs des filiales.

Contexte : il est nécessaire de disposer d’une fonction permettant de récupérer le nombre d’éléments couverts au niveau des filiales de l’entreprise cliente.

Évolution

Cette fonction prend en compte deux paramètres optionnels :

  • Code du descripteur de risque à considérer (ses variants seront pris en compte si applicables),
  • Date à laquelle l’élément doit être couvert pour être pris en compte.

Ajout d’un paramètre à la fonction nombre_total_jours_indemnisation_personne_couverte du moteur de règles pour filtrer les types de préjudices

Évolution : enrichissement de la fonction existante permettant de renseigner une liste de code descripteur de préjudice.


Ajout de la nouvelle fonction du moteur de règles : prime_de_base_et_surprime_autres_garanties

Évolution : ajout une nouvelle fonction qui retourne les montants des primes de garanties paramétrées avec les surprimes incluses.


Noyau technique

Amélioration des performances du batch de recalcul et requittancement des contrats

Nouveau batch de recalcul des contrats


Ajout de paramètres fonctionnels sur le batch de requittancement


Nouvelle chaine batch de vérification des points d’entrée (menus) et vues

Évolution

Création de batch de vérification :

  • Des points d’entrée,
  • Des vues liste et formulaire et des champs / boutons présents sur la vue.

Ajout d’un batch et d’un assistant permettant de vérifier les chemins des répertoires

Évolution : création d’un batch et d’un assistant permettant de vérifier les chemins ou les répertoires d’entrée / de sortie paramétrés.

Batch


Assistant


Permettre de relancer manuellement une opération échouée de batch autant de fois que souhaité

Contexte : lorsqu’un batch est en erreur, il était bloqué après trois exécutions.

Évolution : il est désormais possible de relancer manuellement un batch sans limite du nombre d’exécution.


Ajout d’informations sur les dernières exécutions de chaînes sur l’écran de la configuration de plan batch

Évolutions

Plusieurs ajouts sur la configuration des plans batch :

  • Icône suivant le statut de la dernière exécution de la chaîne,
  • Date de la dernière exécution OK,
  • Bouton pour ouvrir le dernier run,
  • Enregistrement lié (relate) depuis la configuration de plan batch vers les dernières exécutions de batch de la chaîne.


Fonctionnalité permettant un traitement plus précis de l’exécution du batch d’import de fichiers

Évolution :

Lorsqu’un enregistrement du fichier de rejet SEPA ne peut pas être intégré, cela ne bloque pas l’intégration des autres enregistrements. Techniquement, le fichier est découpé en plusieurs extraits.

Nouveau point Extraits de fichiers SEPA


Permettre de redémarrer Celery depuis coog

Contexte

Dans les environnements de production, il arrive régulièrement qu’il soit nécessaire de redémarrer Celery (par exemple pour débloquer un traitement long / suite à une coupure de connexion à la base de données). Actuellement, il est nécessaire de passer par un processus de livraison complet, avec les délais de déploiement qui vont avec.

Évolution : il est désormais possible d’effectuer cette action directement depuis coog.


Ajout d’un champ de texte pour inspecter les tâches actives de Celery depuis coog

Évolution : dans le menu “Statut Celery”, un nouvel onglet “Tâches actives” a été créé qui va lancer la commande inspect active de Celery.


SSO / SAML

Évolution

coog supporte l’authentification des utilisateurs auprès d’un service externe via le protocole SAML pour les fournisseurs d’authentification Google / ADFS. Pour l’instant, seule l’authentification d’utilisateurs existants est supportée.


Migration

Création d’un outillage de plus en plus sécurisé pour les run de migration

Évolution : dans le cadre des run de migration, la méthodologie coopengo évolue grâce à la création de batch permettant de mettre à disposition des clients utilisateurs les comptages et vérifications directement depuis l’application coog.

Création d’un premier batch permettant d’alimenter une base HDS au format intermédiaire (staging) depuis les fichiers déposés par les clients utilisateurs de coog sur des répertoires sftp

 

Ajout d’un assistant pour purger et supprimer les tables de migration sur la base intermédiaire


Création de plusieurs batch de chargement (migrator) permettant de charger les données dans coog


Ajout de la catégorie à la souscription sur les descriptions des risques

Contexte

Avec l’ajout des variants de descripteurs de risques, il est maintenant possible de séparer fonctionnellement les descripteurs de risques.

Toutefois, l’initialisation automatique du premier risque couvert ne fonctionne pas à partir du moment où il y a plus d’un descripteur de risque configuré sur le produit.

Évolution

Ajout d’une nouvelle catégorie permettant d’alimenter en automatique les risques couverts sur un contrat.

La catégorie “Principal” sera le descripteur de risque par défaut sur les contrats. Les autres risques couvert seront de type “Secondaire”.


coog API

API : Ajout du support des ReplicaSet MongoDB

Évolution : Création d’une variable d’environnement permettant d’assurer la compatibilité avec l’ancienne méthode de connexion à MongoDB


Extension de l’API GraphQL Image contrat (B2B) avec la liste des comptes bancaires de prestation des éléments couverts


Ajout de données complémentaires, du régime local et des informations santé pour les tiers et éléments couverts dans les modèles GraphQL B2B et B2C


Extraire la liste des contrats / devis liés à un réseau de distribution, ainsi que les contrats des enfants du nœud de distribution

Besoin métier : consulter les contrats par le code du réseau de distribution.