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.).

Implementation of a cache mechanism for token APIs

Context: for each API call using a token for authentication, the validity of the token in the database had to be checked each time. This impacted performance.

Evolution: add a caching mechanism to the function, so that token validity is no longer systematically checked.

Stop storing binary data in errors

Need

ir.error ‘ files store all the variables involved in an error. In some cases (e.g. document editing), this can include binary data with very large data volumes (unzipped ODT files).

Evolution: truncate binary data in coog errors stored in base.

Added tools for setting OAuth 2.0 authentication parameters.

Evolution: enable authentication via the OAuth 2.0 standard.

Improving the reliability of simulation tools

Context / Business need

In some cases, it is necessary to simulate transactions. The current approach is to create a new transaction on which a rollback is performed at the end of execution.

Evolutions :

  • Improve robustness and reliability of simulation mechanics
  • Unify simulation uses

Add tools to optimize loading of CSV files / arbitrary data

Context / Business need: there is a frequent need to load CSV files.

Evolution: optimize file loading with a tool that automatically checks file format, expected data in each column, etc.

Script management from the coog interface

Context / Business need

Data recovery is a delicate operation for coog SaaS customers, for security reasons.

Evolution

Delivery of recovery scripts. These scripts are launched directly from the application by coog users or support teams. This improves monitoring of data recovery execution, and facilitates operation.

Add a shortcut for updating batch configurations

Context: when batch configurations are delivered via XML, the configuration is not updated.

Business need: modify batch configuration following a database update.

Evolution: create an action on the batch configuration which, starting from the batch name, retrieves the associated XML and updates the data according to what’s in the XML.

Replace GTK grouped export and revision difference plugin with a wizard

Evolution: creation of a wizard for debugging, grouped export and revision viewing functions integrated into coog without having to install plugins, thus enabling JSON exports from 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.

Implement periodic coog error cleanup batch

Business requirement: in order to stabilize the size of the ‘ir.coog_error’ object table, it needs to be cleaned periodically.

Evolution: create an ‘error.clean’ batch to define a processing date and a retention period in days (7 by default) to delete all errors created during the period.

Addition of an anonymization mechanism for “Dict” fields

Business need: following the evolution delivered in 23.14 on anonymization scripts, it is necessary to be able to configure data by data which fields are to be anonymized.

Evolution: addition of two new fields for additional data and the configuration of detail lines.

A field for choosing between three anonymization strategies (Do nothing / Clean / Force a value).

  • Do nothing: keep existing values.
  • Clean: keep the key but value with an empty string.
  • Force: replace the key with the selected value.

A field displayed for text data: selection to force a value if the corresponding strategy is selected.

The default value is “Clean”.

Insured space (B2C)

Addition of a manual Web identity creation mechanism

Context

The insured space is created by the event type actions “Web identity creation” and “Generate personal space email”.

Currently, if the subscriber has no email, an error is raised and the subscription is blocked at the last stage, with no possibility of activating the contract.

Business needs

  • Condition the creation of the insured space on the presence of an email address for the subscriber. Parameters can be set to define this condition.
  • Creation of a management act to manually launch the creation of the policyholder space.

Changes

  • If the policyholder has no email, do not create a Web identity/personal space, the manager is notified of the failure of the policyholder space initialization request.
  • Addition of an action button “Manual creation of member space (insured)” on the third party.

coog API

ReplicaSet MongoDB support added

Context: implementation of ReplicaSet MongoDB in Claranet’s production environment (Coreye), to improve the availability and fault tolerance of coog API services.

Evolution

Added support for MongoDB ReplicaSet in the following coog-portal API modules:

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

Add document types to the Contract Query API

Context: in the GraphQL Quotation API, it is currently not possible to know which covered item a document request relates to.

Enhancements

Addition, in addition to the existing ‘documentRequestLines’ field, of a ‘contractDocuments ‘ field containing only document requests relating to the contract (subscriber).

Addition of a ‘coveredDocuments ‘ field containing only requests related to covered items (requests in this second list have a new covered field).

Evolution of APIs for creating and updating distribution networks

Developments

In the APIs for creating intermediaries (brokers, for example), the following information has been added:

Communication preference and email for communication with intermediaries such as brokers

Accounting auxiliarization code

Commercial products

Email intermediary slips (brokers)

Creation of commission protocols:

  • Plan code,
  • Additional data,
  • Start date / end date,
  • Intermediary (broker).

The following information is added to the APIs for updating intermediaries:

  • Commercial products to be added,
  • List of commercial products to be withdrawn,
  • Email brokers’ slips,
  • List of protocols to be closed,
  • List of protocols to be reopened.

Retrieve documents filtered by document type from the GraphQLAPI

Context / Business need: retrieve documents on contracts and/or claims from the policyholder’s personal space (B2C).

Evolution: set up a filter to retrieve documents by type.

Addition of fields on the GraphQL B2CAPI (insured personal space)

Evolution

Notification status added

Addition of contract receipts for a given date interval:

  • Receipt number,
  • Receipt periodicity (periodic / aperiodic).

If periodic: receipt period, status, total amount and amount before and after tax, then receipt and tax lines.

Add policyholder relationships with start and end dates.

Bank accounts and benefit reimbursement bank account:

    • Account holder,
    • IBAN,
    • BIC code,
    • Bank name,
    • Start and end dates.

Adding fields to the GraphQL B2BAPI

Evolution

Enrichment of the contract consultation API with the following information:

Contract creation date

Third-party communication preference information

Bank accounts and benefit reimbursement bank account:

  • Account holder,
  • IBAN,
  • BIC code,
  • Bank name,
  • Start and end dates.

Noemization status

Relationship between policyholder and subscriber, with start and end dates.

Guarantees subscribed to, and additional data for setting the parameters (typing) of the associated guarantee offered.

Contract commission protocol code

Add contract-related fields via GraphQL

Scope of application: health and personal protection.

Evolution

Retrieve all contract information from coog. This makes it possible to integrate coverage information into a third-party tool.

Sub-status field added to GraphQLAPI for contracts

Evolution: sub-status / termination reason added for terminated contracts.