coog version 23.41 released

Oct. 14, 2023 Release notes

A major new feature of coog 23.41 is the ability to automatically manage document requests at a set frequency, thereby maintaining policyholder cover – for example, keeping adult children conditionally covered under a policy.

This new version of coog also includes a number of ergonomic enhancements to help managers and parameterization teams, such as a new tab for rider configuration and the use of additional data. The aim of these evolutions is to encourage coog users’ autonomy in product parameterization (time to market).

coog Back-Office

Rules engine

Add a message to the rule usage wizard

Context: following the release of coog 23.14, the wizard can be used to find out whether a rule is being used and in what context.

Evolution: a message indicating that the rule is not used by any object has been added.

Allow users to order rule engine traces by creation date

Business need: enable users to order rule engine traces by date of creation, for faster retrieval of execution traces.

Evolution: implement date-based ordering of rule engine traces.

Addition of a filter for additional third-party data

Context: “Context by default” rules do not return the additional data of third-party insureds, but only the additional data of the policyholder.

Business need: define whether the additional data returned by a rule is that of the policyholder or that of the insured.

Evolution

Generation of two accessors for complementary third-party data:

  • Policyholder,
  • Item covered.

Mass deactivation of rules debug mode

Context

Today, it is necessary to replay each rule to deactivate debug mode, and error traces must be deleted manually on each rule.

Evolution

Creation of an error trace cleanup batch allowing :

  • Add an action to disable debug mode on all rules at once,
  • The addition of an error trace cleanup batch for the rules engine.

Update of parameterization rules

Context: need to add new functions to the rules engine for rules queried by API lambda.

Evolutions

Creation of a “Settings repository” entry in the rules engine.

Functions added to the rules engine in the tooling context only.

  • guarantee_complementary_data()’: returns the complementary data corresponding to the guarantee.
  • commissioning_protocol_additional_data()’: returns the additional data for the commissioning protocol.
  • tax_value()’: returns the tax value.

Management of reference tables

Scope: group insurance.

Context: this upgrade is intended for parameterization teams.

Business need

A large number of products frequently use tables with the same structure, but with input lines that vary according to the formulas (for example, the nature of a work stoppage will condition a compensation credit). As a result, there are as many tables as there are products.

The aim is to have tables whose structure is created from a model, and whose reference in rules and correspondence is unique, so as to avoid duplicating rules and correspondence models.

Evolution: creation of table models common to all products/formulas, whose content is defined in the benefit formula settings or when the contract is taken out.

Adding multiple values to tables

Context

Feature for parameterizers to reduce their parameterization workload. Tables were implemented to return a single value. For rules requiring several conditions, it is therefore necessary to create several tables.

Business case example: the insured’s seniority determines the deductible period and the reimbursement rate.

Evolution: create a single table to return multiple values from a single table.

Update dimensions on a cell

Context: today, it’s not possible to add a dimension to an existing table; you have to create a new table with the dimensions.

Evolution: an “Update cells” wizard, available on table cells, allows you to enter a value for the new dimension on all table cells.

Search/Replace in rules

Context/Requirement: update rules after modifying a rule engine function.

Evolution: search / replace in all rules using Python syntax.

Processes

Add processes to the product view

Context/Business need: to be able to parameterize the subscription process directly on the product to avoid oversights and make parameterization more fluid.

Evolution

Addition of a setting on the product to define the subscription process to be used.

To avoid oversights, it will not be possible to validate product settings if no process is set.

Autoformatting XML fields on processes

Context

When setting up steps or business processes, it is possible to enter headers, footers and view descriptions in XML format. The existing check is performed only on the validity of the XML content.

Evolution: auto-format XML fields on processes and steps when saving these fields, to make them easier to read.

Third party

Add a second email field for third parties

Context: manage multiple email addresses for intermediaries in the distribution network. Intermediaries, such as brokers or general agents, may have several active email addresses at the same time.

Business need

Some intermediaries in the distribution network wish to receive communications relating to financial elements (slips, for example) on an email address separate from the one receiving contract communications (confirmation of contract activation, policyholder formal notice information, etc.).

Evolution

A new “Main contact” email field has been created for intermediaries. This is dissociated from the “Invoice” email field. It is now possible to define the address to be used by mail template.

The API for creating/modifying the distribution network has also been enhanced.

Add a check on the presence of an email

Context: to have consistent data concerning third-party communication information.

Business need: when a third party wishes to be contacted by email only, a control must check the presence of an active email address on the third party.

Developments

When creating a third party (or directly modifying the third party file), if “Email” is entered in one of the following 3 fields:

  • “Contract management communication mode”,
  • “almerys statement dispatch mode”,
  • “almerys management mail dispatch mode”,

If no e-mail is present on the third-party record, a blocking message appears.

This check is also applied when modifying communication preferences.

Third-party account developments

Business need: to be able to quickly justify third-party accounts and balances.

Developments

Enrichment of the third-party account assistant to display payments in progress to justify the consolidated balance.

It is also possible to filter the balance by accounting account (account payable/account receivable).

Add a linked record to tasks from a third party

Business need: access tasks created directly from a third party.

Evolution: add a linked record from the third party to quickly access the third party’s tasks.

 

Contracts

Added “Edited by” column in list view for quotes

Context

Some managers check quotes from the Sales Support Tool. For example, they check the supporting documents, without activating the contracts.

Business need: see at a glance which manager edited the quote.

Evolution

To enable managers to retrieve the quotes concerned, an “Edited by” column is now visible in the “Quote” entry point, after the “Product” column.

The value of the “Edited by” column will be populated with the identifier (user) of the manager who took over the quotation to carry out the checks.

Enhanced “Organization” view for group contracts

Context: the “Organization” view is used to display information relating to the organization of contracts and relationships between legal entities.

Business requirement

The population groups to which the elements covered belong must be identifiable. The aim is to be able to view a contract across multiple population groups and companies.

Evolution: make the “Organization” view usable thanks to the contract and relationship nodes.

Managing corporate relationship levels

Context

The wizards launched to link subsidiaries to the contract manage only one level of “Subsidiary company” relationships.

Evolution

Contracts can now manage 3 levels of corporate relationships:

  • Parent company,
  • Daughter company,
  • daughter company of daughter company (usually the daughter company’s secondary establishment).

Modification of additional data on a covered risk

Context / Business need

The coog customer wishes to modify his pricing every [X] years.

This pricing is defined at the time of underwriting and depends on the additional data of the risk descriptor and the condition date.

Some questions/answers may vary over time (product/guarantee life cycle).

The setting of certain additional data is therefore subject to versioning over time (start date/end date).

Evolutions

Creation of additional data variants to enable additional data to be retrieved from desktop publishing or from the rules engine using the reference additional data.

Addition of a notion of start date and end date for “Covered risk” type additional data variants, to identify the need to automate the selection of a variant at the time of subscription/endorsement, depending on which variant is valid with respect to the condition date.

Enable out-of-sync renewal of a set of contracts

Evolution: removal of the block for renewing a set of contracts (health and personal protection) on a different date.

Endorsements Contracts

Add an “Endorsement definitions” tab to the unit endorsement configuration.

Business need: display rider definitions used in unit rider configuration.

Evolution: added a tab that lets you know on which endorsements the unitary endorsement is used.

Add a unitary rider to manage third-party information.

Business need: functionally track changes to a third party’s address or bank details.

Evolutions

  • Addition of a third-party information management rider
  • Implementation of a control: once the rider is activated, it is no longer possible to update information directly on the third-party record.

Enable the transfer of a rider from the list of generated riders

Requirement: to be able to retrieve pre-initialized endorsements from the list view.

Evolution: introduction of a button in the list view.

Modification of an error message when not belonging to the application group of a rider

Evolution: following the addition of the notion of application group on rider definitions, the message has been enriched.

Addition of a new mass rider from a contract amendment template

Evolution: addition of a formula replacement rider, taking over the management of guarantees and complementary guarantee data.

Simulation of adding a covered item to a contract

Business need: to be able to price the addition of a beneficiary without creating the third party in coog.

Evolution

To be able to enter a third party without using a third party sequence (the third party will therefore not be available in the third party database) in order to simulate an endorsement to add a beneficiary.

  • If the rider is declined, the inactive third party will be deleted.
  • If the rider is validated, the definitive third-party code will be generated.

Claims

Creation of the S/P ratio wizard

Requirement: provide the S / P ratio (Claims paid/Premiums received) for each active or cancelled contract.

Evolution

The configuration will be parameterized by cover.

Add methods to retrieve an amount calculated over a period in ‘contract.option’:

  • Amount collected excluding VAT,
  • Amount collected incl. VAT,
  • Called amount excl,
  • Called amount incl. VAT,
  • Amount disbursed,
  • Amount paid out (including date taken into account).

Evolution of the logic for setting the insurer’s delegation parameters

Context: at present, it is compulsory to set up a delegation for the insurer, even in the case of total delegation.

Evolution

From now on, an empty list is interpreted as total delegation. If lines are filled in, there is no longer any need to be exhaustive (total delegation by default).

Regulatory

RGPD

Enhanced anonymization script generation wizard

Context: evolution in line with the creation of the wizard for generating an anonymization script (delivered in 23.14).

Requirement: to be able to anonymize a database directly from coog.

Evolution: algorithm added to anonymization wizard and old anonymization script reused.

Borrower

New “Agency” field added if lender is a bank

Context: evolution in line with the addition of a new “Agency” field if the lending institution is a bank (delivered in 23.14).

Evolution: improvement of the view used to search for the lender’s address in the endorsement, to obtain the same input experience as in underwriting.

Adding differential amounts to loan increments

Context

When calculating contributions, only the initial loan capital must be entered. However, this is not sufficient in the event of loan evolution, partial redemption or successive release of funds.

Need: to be able to manually enter an increase or decrease in the nominal loan amount on a loan tier.

Evolutions :

  • Addition of a new field to define tier types,
  • Addition of a new field on tiers to enable entry of increases or decreases in the nominal amount,
  • Addition of a function in the rules engine to retrieve the nominal amount at a given date.

Health

Addition of the concept of Travailleur Non Salarié (TNS) (self-employed worker)

Scope of application: Health module only.

Context: following the absorption of the Régime Social des Indépendants (RSI) by the Régime Général, the management of TNS requires additional information on the third party for the management of “Loi Madelin” certificates.

Evolution: addition of a Boolean to health plan data to indicate that the third party is a Travailleur Non Salarié.

 

Tax period concept added

Scope of application: Health module only.

Business requirement: need to be able to manage staggered tax years for the generation of “Loi Madelin” certificates for TNS (self-employed workers).

Evolutions :

  • Creation of a “Fiscal year date” field,
  • Addition of a new Boolean field on the contract to determine whether the subscriber is a TNS and has paid all his contributions for the last fiscal year,
  • Creation of a method for retrieving receipts from mail templates, with receipts concerned by the tax certificate for the fiscal year,
  • Creation of a new period type for periodic reports (last fiscal year).

NOEMIE

Managing the refusal of Noemisation by entitlement holder in the rider

Business need: to be able to refuse entitlement Noemisation by entitlement holder.

Evolution: enhancement of the Noemisation modification rider to enable refusal or acceptance of Noemisation by entitlement holder.

Generate a letter template only for certain NOÉMIE return codes

Business need: following a Noemisation rejection, it may be necessary to generate a letter to inform the policyholder.

Evolution: when creating an action by event type, it is now possible to filter NOEMIE rejection codes for which it is necessary to send a letter to the policyholder.

almerys

Management of special schemes in V3 flow

Scope: almerys interface for managing healthcare benefits.

Business requirement: in order to manage the reimbursement rates of the Régime Obligatoire (RO) for policyholders under the Alsace Moselle scheme, it is necessary to communicate the information to almerys.

Evolution: creation of a list of special schemes to indicate the notion of local scheme and feed the ‘REGIME_SPECIAL’ tag in the V3 flow.

Addition of Noemisation of the insured’s non-contractual rightful claimant.

Scope: almerys interface for managing healthcare benefits.

Business need: in the context of healthcare contracts, it is possible to add a rightful claimant to a contract without the rightful claimant being covered by the same contract, in order to perform Noemisation.

Evolution: use the notion of relationship to feed V3 and enable Noémisation of the rightful claimant.

Billing

Contributions

Remove the SEPA mandate sequence field from the product

Evolution: the SEPA mandate sequence is set directly on the accounting configuration and no longer on the product.

Correction and improvement of automatic lettering system

Context

Automatic lettering is performed in the following order (ascending):

  • Due date,
  • Line date (accounting),
  • Creation date (technical).

However, expenses are never automatically lettered. In some cases, the dates are identical.

Evolution: add the amount to the sort to letter as much as possible, even if all dates are identical in the case of a recalculation.

Add a de-/re-lettering action for contract receipts

Context/Business need: enables contract receipts to be squared with available funds.

Example use case: you can generate 20 receipts on the contract with the generation wizard, cash a check covering the entire amount, then use this wizard to pay all the receipts at once.

Evolution: addition of a re-lettering action on contract receipts.

Add a default release journal to the accounting configuration

Context: the release journal used implicitly is the first product-typed journal (revenue type).

Evolution: add a default product journal to the accounting configuration.

Direct debit date simulation in the event of payment suspension

Business requirement: display on schedule-type mailings the sum of unpaid amounts on the next (theoretical) direct debit due date, according to the direct debit date set on the means of payment.

Evolution

Simulation of direct debit date when :

  • The contract has not fallen (active or suspended status).
  • The receipt has been issued, but is not being debited with: due date < D, debit date = null.
  • The contract payment method is direct debit, and the direct debit status is suspended.

Use of action filters on dunning events

Context: in line with the evolution delivered in 23.14, to enable the use of filters on actions by event type.

Evolution: to be able to use contract data when executing an action filter rule by event type for dunning events.

Adding event details when processing a formal notice

Context

When dunning letters are generated, the amount displayed is based on data that evolves over time (reconciliation, resettlement, collection, etc.). This makes it difficult to justify the amount indicated in the letter.

Evolution: to be able to view the balances used at the time of the reminder (even several months later), so as to be able to build reports that are representative of what was sent to customers.

Accounting

Search for transaction lines on suspense accounts

Scope of application: declarative group contributions.

Context: for collective contributions, cash receipts are made on a suspense account without automatic allocation.

Evolution

Allows you to view collected lines awaiting allocation or reimbursement. Search by legal entity or amount.

Commissions

Default intermediary payment account added to accounting configuration

Evolution: implementation of a default payable account on the accounting configuration for commission payments.

Example: if a broker has no account, the default account will be used.

Correction of commission date calculation method

Correction: in the framework for paying commissions to distribution intermediaries (brokers), correct the behavior of the “On payment” commission method, following a modification in the Tryton framework.

Documents

Managing perishable documents

Context / Business need

As part of contract management, it is sometimes necessary to manage document requests at a specific frequency (e.g. annually) to maintain policyholder coverage on their contracts.

If the document is received and compliant, the policyholder is maintained on the contract. If the document is not received, the policyholder may be deregistered.

Example of application

In the case of health insurance policies, children can be covered by the policy up to the age of 18, without any conditions.

Between the ages of 18 and 25, they must prove that they are continuing their studies in order to remain on the contract. Every year, from the age of 18 onwards, we have to ask the policyholder to send us his or her school attendance certificate.

Developments

Enhanced document type settings

Addition of a Boolean field “Perishable” on document types

Enable the setting of a document expiry date rule

Addition of a new “Rider launch configuration” template

Add a document request procedure to define :

  • The frequency of reminders from the first part request (e.g.: 2 months, 60 days, 10 days, etc.),
  • A maximum number of reminders,
  • For expired documents, a new part will be requested before the expiry date (end of validity of the attached part) according to a dedicated field: “Time to expiry date for first request”.

Enhancement of the rules engine:

  • Addition of a function in the rules engine to find out the attachment’s expiry date,
  • Addition of two functions in the rules engine, ‘documents_demandes_assure’ and ‘documents_recus_assure’, to list documents by covered element active on the rule execution date.

Enhanced management of required documents

When creating lines of required documents (during underwriting – including by API – or following a contract amendment):

  • If the document type uses a procedure, coog will calculate a “Next document request date”.
  • When an attachment is received, if an end-of-validity date is calculated or entered manually, coog will recalculate the next document request date (e.g. 3.5 months before end-of-validity date).

Creation of a new batch to generate part request letters.

Set up a rider to be applied automatically when the document is received. This makes it possible, for example, to automatically recalculate warranty expiry dates when a document is received.

Validation of mail template output directory

Evolution: introduction of a check on the format of the export directory for mail templates, if this field contains characters forbidden by UNIX.

Add a customizable header when sending emails

Business requirement: in order to manage email classification in the server, it was necessary to add a specific header for email sending.

Evolution: implementation of a customizable header for the company.

Use default company email configuration

Context: when setting up email-type mail templates, the email configuration must be set on each mail template in addition to the company email configuration.

Evolution

By default, email mail templates benefit from the configuration set on the company. It will be possible to override this setting on each mail template.

Desktop publishing

Error message enrichment during mail generation

Context: When mail generation fails, the error message generated is generic and does not specify the name of the failed mail.

Evolution: Enrich the message to add the code of the mail in error.

Force “Split documents” configuration

Evolution: coog automatically selects the correct behavior for the “Split documents” checkbox on the “Slip” mail templates (insurer and brokers), as well as for insurer reports.

Add a rule filter to mail templates

Context/Business need

Facilitate mail template parameterization to make it more accessible to business profiles.

Condition mail generation more precisely.

Evolution : Enhance mail template filter criteria with the possibility of using the rules engine to filter mail editing conditions.

EDM

Enable configuration of an external EDM on a company

Evolution: add an EDM configuration on the company to set up the link with an external EDM.

Reports

Add extraction request cleanup batch

Context

When extracting data using the ‘extractor‘ module, numerous entries are created. Once processed, these entries have no reason to be kept in the application.

Evolution

Creation of a new batch process ‘extraction.request.clean_up’ taking a processing date as parameter and a delay in days in advance of the processing date.

This process deletes all ‘extraction.requests’ whose processing field is less than the processing date – delay.

Technical core

Adding product versions

Business need: versioning of product terms and conditions

Evolutions :

  • Add a method from the contract to retrieve the product version of interest from a date,
  • Add a rules engine function to retrieve the product version code (at the contract condition date).

Management of additional risk descriptor variant data

Context: this evolution is intended for parameterization teams.

Business need

In coog, the risk descriptor carries a large amount of additional data (e.g., management/non-management population group in group insurance).

The aim is to avoid duplicating rules and correspondence.

Example of a business case in individual insurance: When a policy is taken out, the policyholder is asked a number of questions relating to his or her personal details (smoker/non-smoker, high-risk sport, etc.).

The answers to these questions may depend on the insurer.

Developments

Introduce a notion of inheritance for additional data.

This enables all possible combinations of a risk descriptor to be created, thanks to the creation of variants.

The manager has access to unique references.

Technically, this evolution restricts the field of possibilities. It also facilitates maintenance.

Adding additional data uses

Context

It is impossible to know from an item of additional data where it is used (on which product, guarantee or service). It is necessary to go through the various parameterization objects to find this link.

Business need: visualize directly on which parameter object the additional data is used from the additional data, rather than from the various parameter objects.

Evolution: create one or more links from additional data to the benefits, products and services on which they are configured.

Prohibit deletion of event logs, except for deleted quotes

Context: a user with the necessary authorizations can delete a line in event logs.

Evolution: forbid deletion of lines in event logs, including for the administrator. However, deletion will be authorized for the event logs of deleted quotes.

Addition of an email configuration test wizard for companies

Evolution

Creation of a wizard for testing email configuration (header, format, protocol, etc.).

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.