2. Bijvoegsel

2.1. A partir du package

2.1.1. Invocation et échange de données par le contexte

Idem consultation

2.1.2. Réalisation avenant dans le module compagnie

Un avenant à une police se déroule dans le module de la compagnie avec les données de la compagnie.
Seul le numéro de police sera récupéré du package via l’échange contextuel ou comme paramètre lors de l’invocation.

De ce fait, le courtier n’a pas de traces de l’avenant dans le package tant que la compagnie n’a pas envoyé de bloc retour.

Ce retour d’information est important parce que le courtier peut dès lors refermer son dossier.

D’autre part, l’avenant peut être mis à l’examen par le back-office. Il est important de déposer une trace chez le courtier en envoyant un bloc retour.

2.1.2.1. Affaire acceptée par la compagnie

Si l’affaire est acceptée par la compagnie, elle envoie un bloc retour immédiat.
Ce bloc retour peut être complet (recommandé) ou provisoire (si la compagnie n’est pas en mesure d’envoyer toutes les informations – exemple primes au comptant qui sont disponibles après l’exécution de programmes batch dans la compagnie).

2.1.2.2. Affaire mise à l’examen par la compagnie

Aujourd’hui, si l’affaire est mise à l’examen, le courtier n’a pas de trace dans son package de l’avenant réalisé dans la compagnie.

Nous recommandons que la compagnie envoie un bloc retour provisoire avec un état de l’acceptation dûment complété (attribut ATT+A055 : « état acceptation » dans TELEBIB2).

Le package intègre ce bloc retour provisoire comme un « projet » ou ne l’intègre pas ; ceci est paramétrable dans le package.

Après examen dans la compagnie, cette affaire peut être :

• acceptée : envoi d’un bloc retour définitif
• refusée : envoi d’un bloc retour avec statut « Affaire refusée par la compagnie»

2.1.3. Intégration Bloc Retour

Le bloc retour définitif est un ensemble d'un message décrivant la nouvelle situation du contrat dans tous ses détails (comparable au contenu des conditions spécifiques en version papier), et d'un message décrivant le contenu de la quittance au comptant, et éventuellement d'un ou plusieurs messages permettant de véhiculer les "documents annexes".

Dans ce message "contrat" sont repris les montants primes sur base annuelle (on y mise la charge totale annuelle - dans le cas d'échéances mensuelles on y mentionne donc le total des 12 échéances y compris les frais de fractionnement).
Ces montants primes y sont repris comme des totaux au niveau du contrat, et y sont repris au niveau des garanties. Et y sont repris au niveau des sous-graranties si jugé opportun.

Dans ce message "quittance" sont repris les montants propres à la quittance.
Ces montants primes y sont repris comme des totaux au niveau de la quittance, et y sont repris au niveau des garanties. Et y sont repris au niveau des sous-graranties si jugé opportun.

La structuration des objets de risque et des garanties reflète celle du contrat.

Ainsi on a une "photo" de la nouvelle situation du contrat et une représentation adéquate de la transaction financière en résultant.

Ce BBP 2 élabore ce qui se passe avec ce message "contrat".

Le BBP 16 élabore ce qui se passe avec ce message "quittance".

Notre "objet technique - document annexé" (MCI M9730) décrit le véhicule pour ces documents annexes.

2.1.3.1. Généralités

La compagnie envoie toutes les données d’un contrat.

Seules les données reprises dans le bloc retour mettront à jour la base de données du courtier.

Lorsque les données du courtier sont plus détaillées que celle de la compagnie, nous recommandons à la compagnie de s’en souvenir lors de l’échange contextuel. Cette information ne sera pas restituée dans le bloc retour.

Cette manipulation évitera au courtier de manipuler cette donnée à l’aide d’un filtre d’intégration.
(On demande donc ici aux compagnies de faire l’effort de se souvenir des manipulations lors de la réception d’un échange contextuel, et de manipuler en sens inverse ces données lors de la génération du bloc retour...)

Pour commencer l’intégration d’un avenant, les données suivantes doivent être retrouvées dans le package :

• Le code OCA de la compagnie
• Le code producteur

Par sous rubrique, nous allons détailler quelles sont les règles d’intégration :

• Identification de la sous rubrique
• Données qui font partie de la sous rubrique
• Application d’un filtre d’intégration

2.1.3.2. Données administratives du contrat

Identification

• Le numéro de contrat
• Si le contrat n’est pas retrouvé dans le package, le courtier aura la possibilité de rechercher un contrat dans son package.
• Cette situation doit être exceptionnelle et doit permettre d’intégrer un bloc retour même s’il y a un problème de numérotation des contrats.
• Si le contrat n’est toujours pas retrouvé, il faut encore permettre au courtier de décider d’intégrer l’avenant sans situation antérieure.
• Ces situations ne se présenteront en principe pas si le courtier met à jour ses polices à l’aide des quittances provenant des compagnies.
• Si le contrat est retrouvé, une nouvelle version du contrat sera créée. La situation précédente passe en historique.
• Le courtier pourra dès lors consulter l’évolution d’un contrat.

Données

• Voir les MIG (Message Implementation Guide) du Telebib.

Filtre

• Les données de la compagnie étant plus précises, il n’y aura pas de filtre d’intégration.
• Les données du bloc retour remplaceront celles du package sans manipulations..

2.1.3.3. Données du preneur d’assurances

Remarque

• S’il y a changement d’adresse, nous recommandons de l’encoder dans le package de sorte que la modification puisse être envoyée à toutes les compagnies en une fois à l’aide de la requête structurée (MIG M0410 : « demande de modification des renseignements client »).

Identification

• Lors d’un avenant, lorsque le contrat est retrouvé, le preneur l’est également.

Données

• Voir les MIG du Telebib.

Filtre

• Les données du courtier peuvent être plus complètes.
• Le filtre d’intégration présentera les différences.
• Les données du courtier sont prioritaires par défaut.

2.1.3.4. Objet de risque Auto – véhicule/remorque

Identification

• Numéro de PVA et numéro de suite PVA - fichier « Febiac » (identification univoque)
• Marque + châssis (identification univoque)
• Plaque + marque + année de construction
• Plaque + marque

Si l’objet de risque est trouvé à l’aide de l’identification univoque, les données du courtier seront en principe remplacées par celles du bloc retour (mais le courtier a encore toujours la possibilité de choisir un autre objet).

Si plusieurs objets de risque répondent aux critères de recherche, ils seront présentés au courtier et il aura la possibilité d’en sélectionner un parmi la liste ou de créer un nouvel objet de risque à partir des données du bloc retour.

Si aucun objet de risque ne répond aux critères, un nouvel objet de risque sera en principe créé à partir des données du bloc retour (mais le courtier pourrait encore opter pour un objet déjà appartenant au preneur, il faudrait donc lui présenter ces objets).

Données

• Voir les MIG du Telebib.

Filtre

• Les données de la compagnie sont plus complètes.
• Le filtre d’intégration présentera les différences.
• Données de la compagnie sont prioritaires par défaut.

2.1.3.5. Objet de risque Auto – Conducteur habituel

Identification

• Si le preneur d’assurance = le conducteur habituel : il n’y a pas de données à intégrer.
• Sinon : voir processus de la nouvelle affaire pour identifier un intervenant.

Données

• Voir les MIG du Telebib.

Filtre

• Les données du courtier peuvent être plus complètes.
• Le filtre d’intégration présentera les différences.
• Les données du courtier sont prioritaires par défaut.

2.1.3.6. Objet de risque Incendie – Immeuble

Identification

• Numéro d’identification de la rue du fichier DEDALE
• Rue + n° de rue + n° de boîte + code postal + localité (identification univoque)
• Rue + n° de rue

Si l’objet de risque est trouvé à l’aide de l’identification univoque, les données du courtier seront en principe remplacées par celles du bloc retour, mais le courtier a encore la possibilité de choisir un autre objet.

Si plusieurs objets de risque répondent aux critères de recherche, ils seront présentés au courtier et il aura la possibilité d’en sélectionner un parmi la liste ou de créer un nouvel objet de risque à partir des données du bloc retour.

Si aucun objet de risque ne répond aux critères, un nouvel objet de risque sera en principe créé à partir des données du bloc retour, mais le courtier pourrait encore opter pour un objet déjà appartenant au preneur, ou même un tout autre objet, il faudrait donc lui présenter ces objets, ou lui permettre d’y accéder.

Données

• Voir les MIG du Telebib.

Filtre

• Les données de la compagnie sont plus complètes.
• Le filtre d’intégration présentera les différences.
• Données de la compagnie sont prioritaires par défaut.

2.1.3.7. Objet de risque RCF – Famille (Vie Privée)

Identification

• Objet de risque RCF
• Si l’objet de risque est trouvé, il n’y a pas de modification.
• (Particularité : 1 seule donnée -> on garde toujours le même objet de risque)
• Sinon, l’objet de risque est créé à partir des données reprises dans le bloc retour.

Données

• Voir les MIG du Telebib.

Filtre

• Pas d’application.

2.1.3.8. Garanties

Identification

• Nous considérons que le bloc retour contient toutes les garanties.
• Les données de la compagnie remplacent les données du package.

Données

• Voir les MIG du Telebib.

Filtre

• Pas d’application.

2.1.3.9. Données de la quittance (au comptant)

Il n’y a pas de processus d’intégration automatique des primes de la quittance.

Celles-ci sont affichées et le courtier doit les valider avant mise à jour.

2.2. A partir du système de publication des services

Même processus que l’avenant confectionné par le module de la compagnie en partant du package.

2.3. L'information "motif rédaction de l'avenant"

Ceci est très utile à la reconnaissance de modifications typiques et multiples, sans devoir instaurer trop de codifications spécifiques/détaillées.

Un exemple: Depuis la nouvelle loi sur les pensions complémentaires du 15/12/2015, applicable depuis le 01/01/2016, une grande majorité de contrats groupe, EIP, ADE, ne peuvent plus être liquidés qu’à la prise de pension légale des affiliés, soit à 65 ans pour le moment. Or, par le passé, de nombreux contrats ont été conclus avec un terme de 60 ans. Ce terme, bien que contractuel, ne peut plus, (sauf exception visée dans les mesures transitoires), être respecté, et donc si les affiliés ne peuvent prendre leur pension légale avant 65 ans, les compagnies sont légalement obligées de prolonger les contrats jusqu’à 65 ans.

Tel motif peut être décrit textuellement / brièvement / de manière uniforme.