|
|
|
2. Bijvoegsel
- 2.1. Vanuit het beheerspakket
- 2.1.1. Aanspreking en contextuele gegevensuitwisseling
Idem raadpleging
|
2. Avenant
- 2.1. A partir du package
- 2.1.1. Invocation et échange de données par le contexte
Idem consultation
|
.
|
- 2.1.2. Aanmaak bijvoegsel in de module van de verzekeraar
Een bijvoegsel aan een polis maakt men aan in de module van de verzekeraar, met de gegevens van de verzekeraar.
Enkel het polisnummer komt uit het beheerspakket, via de contextuele uitwisseling, of als parameter in de aanspreking van de module.
Hierdoor heeft de makelaar in zijn beheerspakket geen spoor van dat bijvoegsel zolang de verzekeraar geen antwoordrecord verzonden heeft.
Deze wederkerige informatie is belangrijk omdat ze het de makelaar mogelijk maakt zijn dossier terug te sluiten.
Het is echter ook mogelijk dat het bijvoegsel in onderzoek in de back-office van de verzekeraar blijft hangen, Ook dan is het belangrijk hiervan een spoor bij de makelaar te laten via de verzending van een antwoordrecord.
|
- 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. Zaak aanvaard door de verzekeraar
Als de verzekeraar de zaak aanvaardt dan stuurt deze onmiddellijk een antwoordrecord.
Dit antwoordrecord kan volledig zijn (wat aanbevolen is) of kan voorlopig zijn (als het voor de verzekeraar onmogelijk is dadelijk alle informatie uit te geven - bijvoorbeeld de contante premies die slechts beschikbaar zijn nadat batch programmas uitgevoerd zijn binnen de systemen van de verzekeraar).
|
- 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. Zaak in onderzoek bij de verzekeraar
Als de zaak in onderzoek geplaatst wordt heeft de makelaar vandaag in zijn beheerspakket geen spoor van het bijvoegsel in opmaak bij de verzekeraar.
We bevelen aan dat de verzekeraar dan een voorlopig antwoordrecord stuurt met daarin de status van aanvaarding duidelijk weergegeven (attribuut ATT+A055 : « status aanvaarding » in TELEBIB2).
Het beheerspakket integreert dat voorlopig antwoordrecord ofwel niet, ofwel als een "project"; dit is dan binnen het beheerspakket parametreerbaar gedrag.
Na onderzoek binnen de verzekeraar kan de zaak dan :
- aanvaard worden : verzending van een definitief antwoordrecord
- geweigerd worden : verzending van een antwoordrecord met de status "zaak geweigerd door de verzekeraar"
|
- 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. Integratie Antwoordrecord
Het definitief antwoordrecord is een geheel bestaande uit een bericht dat de nieuwe situatie van het contract in al zijn details weergeeft (vergelijkbaar met de inhoud van de bijzondere voorwaarden op papier), en een bericht dat de inhoud van de contante kwijting weergeeft, en eventueel één of meerdere berichten waarin "bijgevoegde documenten" getransporteerd worden.
In dat "contract"-bericht worden de premiebedragen op jaarbasis vermeld (men doelt op de jaarlijkse totaalkost - voor maandelijkse inning
geeft men dan het totaal van de 12 vervaldagen en inbegrepen de splitsingskosten).
Die premiebedragen staan daar op het contract-niveau als totalen, en staan op het niveau van de individuele waarborgen. En staan op het niveau van de sub-waarborgen indien nuttig.
In dat "kwijting"-bericht worden de bedragen eigen aan de kwijting vermeld.
Die premiebedragen staan daar op het kwijting-niveau als totalen, en staan op het niveau van de individuele waarborgen. En staan op het niveau van de sub-waarborgen indien nuttig.
De structurering qua risico-objecten en waarborgen weerspiegelt deze van het contract.
Zo heeft men een "foto" van de nieuwe contract-situatie, en een gepaste weergave van de financiële transactie die ermee gepaard gaat.
Dit BBP 2 detailleert wat er gebeurt met dit "contract" bericht.
BBP 16 detailleert wat er gebeurt met het "kwijting" bericht.
En ons "technisch object - bijgevoegd document" (MCI M9730) beschrijft het vehikel voor die bijgevoegde documenten.
|
- 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. Algemeenheden
De verzekeraar verstuurt alle informatie van een contract.
Enkel de gegevens aanwezig in het antwoordrecord zullen de databank van de makelaar bijwerken.
Indien de gegevens van de makelaar meer detail vertonen dan deze van de verzekeraar, bevelen we de verzekeraar aan dit verschil op het ogenblik van de contextuele uitwisseling bij the houden. Die informatie zal dan niet via het antwoordrecord terug gegeven worden.
Deze werkwijze laat toe te vermijden dat de makelaar dergelijke informatie moet manipuleren via een integratiefilter.
(Men vraagt hier dus aan de verzekeraar de inspanning zich te herinneren wat zijn manipulaties waren op het ogenblik van de ontvangst van de contextuele uitwisseling, en dan bij de aanmaak van het antwoordrecord die manipulaties in omgekeerde zin te laten spelen...)
Om de integratie van een bijvoegsel te kunnen aanvatten moeten de volgende gegevens in het beheerspakket te vinden zijn :
- De CDV code van de verzekeraar
- De code van de producent (het producentenrekeningnummer)
We zullen per sub-rubriek en in detail vertellen welke de spelregels qua integratie zijn :
- Identificatie van de sub-rubriek
- Gegevens die deel uitmaken van de sub-rubriek
- Toepassing van een integratiefilter
|
- 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. Administratieve contractgegevens
- Identificatie
Het contractnummer
Het contract wordt niet gevonden in het beheerspakket; de makelaar krijgt dan daar de mogelijkheid een contract op te zoeken.
Dat geval is de uitzondering, en het laat toe een antwoordrecord te integreren, zelfs in het geval dat er een probleem is met de nummering van het contract.
Als het contract nog steeds niet te vinden is, dan nog moet men de makelaar toelaten te beslissen over de integratie van het bijvoegsel zonder voorafgaandelijke versie.
Die gevallen komen in principe niet voor als de makelaar zijn polissen bijwerkt met behulp, van de kwijtingen aangeleverd door de verzekeraars.
Het contract wordt gevonden, en een nieuwe contractversie wordt aangemaakt. De vorige versie gaat in de historiek.
De makelaar kan zo de evolutie van een contract consulteren
- Gegevens
Zie de MIG (Message Implementation Guide) in Telebib.
- Filter
De gegevens van de verzekeraar zijn de meest exacte, er is geen integratiefilter van toepassing.
De gegevens van het antwoordrecord vervangen deze in het beheerspakket, zonder verdere manipulatie.
|
- 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. Gegevens verzekeringnemer
- Opmerking
Voor een adreswijziging raden we aan deze in het beheerspakket in te geven zodat de wijziging aan alle verzekeraars via één manipulatie kan verzonden worden met behulp van het gestructureerde bericht/vraag (MIG M0410 : « aanvraag wijziging klantgegevens »).
- Identificatie
Als voor een bijvoegsel het contract gevonden wordt, dan is dat ook zo voor de verzekeringnemer.
- Gegevens
Zie de MIG in Telebib.
- Filter
De gegevens van de makelaar kunnen vollediger zijn.
De integratiefilter laat de verschillen zien.
De gegevens van de makelaar krijgen de voorkeur (defaultkeuze).
|
- 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. Risico-object Auto – voertuig/aanhangwagen
- Identificatie
- PVG nummer en PVG volgnummer - « Febiac » bestand (éénduidige identificatie)
- Merk + chassis (éénduidige identificatie)
- Plaat + merk + bouwjaar
- Plaat + merk
Als het risico-object éénduidig geïdentificeerd is, dan worden de gegevens in het bezit van de makelaar in principe vervangen door deze van het antwoordrecord (maar de makelaar kan toch nog steeds een ander risico-object kiezen).
Als meerdere risico-objecten voldoen aan de zoeksleutels, dan worden deze aan de makelaar getoond en kan deze één uit de lijst kiezen, of kan deze een nieuw risico-object aanmaken vertrekkende van de gegevens van het antwoordrecord.
Als geen enkel risico-object voldoet aan de zoeksleutels, dan maakt hij in principe een nieuw risico-object aan vertrekkende van de gegevens van het antwoordrecord (maar de makelaar zou nog kunnen kiezen voor een risico-object dat al aanwezig is voor de verzekeringnemer, men moet de makelaar dus deze objecten tonen).
- Gegevens
Zie de MIG in Telebib.
- Filter
De gegevens van de verzekeraar zijn vollediger.
De integratiefilter laat de verschillen zien.
De gegevens van de verzekeraar krijgen de voorkeur (defaultkeuze).
|
- 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. Risico-object Auto – Gewoonlijke bestuurder
- Identificatie
Indien de verzekeringnemer = de gewoonlijke bestuurder : dan moeten er geen gegevens geïntegreerd worden.
Anders : zie het proces voor nieuwe zaken aangaande de identificatie van een tussenkomende partij.
- Gegevens
Zie de MIG in Telebib.
- Filter
De gegevens van de makelaar kunnen vollediger zijn.
De integratiefilter laat de verschillen zien.
De gegevens van de makelaar krijgen de voorkeur (defaultkeuze).
|
- 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. Risico-object Brand – Gebouw
- Identificatie
- Identificatie nummer van de straat in het DEDALE bestand
- Straat + (huis)n° + bus n° + postcode + gemeente (éénduidige identificatie)
- Straat + (huis)n°
Als het risico-object éénduidig geïdentificeerd is, dan worden de gegevens in het bezit van de makelaar in principe vervangen door deze van het antwoordrecord (maar de makelaar kan toch nog steeds een ander risico-object kiezen).
Als meerdere risico-objecten voldoen aan de zoeksleutels, dan worden deze aan de makelaar getoond en kan deze één uit de lijst kiezen, of kan deze een nieuw risico-object aanmaken vertrekkende van de gegevens van het antwoordrecord.
Als geen enkel risico-object voldoet aan de zoeksleutels, dan maakt hij in principe een nieuw risico-object aan vertrekkende van de gegevens van het antwoordrecord (maar de makelaar zou nog kunnen kiezen voor een risico-object dat al aanwezig is voor de verzekeringnemer, of zelfs voor een totaal ander object, men moet de makelaar dus deze objecten tonen of hem hem toelaten er op te komen).
- Gegevens
Zie de MIG in Telebib.
- Filter
De gegevens van de verzekeraar zijn vollediger.
De integratiefilter laat de verschillen zien.
De gegevens van de verzekeraar krijgen de voorkeur (defaultkeuze).
|
- 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. Risico-object BAG – Gezin (Privaat Leven)
- Identificatie
Als het risico-object gevonden wordt, dan zijn er geen wijzigingen.
(Bijzonderheid : 1 enkel gegeven -> men behoudt altijd hetzelfde risico-object)
Anders maakt men het risico-object aan vertrekkende van de gegevens van het antwoordredord.
- Gegevens
Zie de MIG in Telebib.
- Filter
Niet van toepassing.
|
- 2.1.3.7. Objet de risque RCF – Famille (Vie Privée)
- Identification
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. Waarborgen
- Identificatie
We gaan er van uit dat het antwoordrecord alle waarborgen bevat.
De gegevens van de verzekeraar vervangen deze van het beheerspakket.
- Gegevens
Zie de MIG in Telebib.
- Filter
Niet van toepassing.
|
- 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. Gegevens van de (contant-)kwijting
Er is geen proces van automatische integratie van premies vanuit de kwijting.
Deze worden getoond en de makelaar moet ze valideren vooraleer ze te integreren.
|
- 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. Vanuit het services/modules publicatiesysteem
Het proces is gelijk aan dat voor het bijvoegsel aangemaakt door de module van de verzekeraar vertrekkende vanuit het beheerspakket.
|
- 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. De informatie "reden opstellen van bijvoegsel"
Dit is erg nuttig om de eerder stereotype (veelvuldig voorkomende) bewerkingen te kunnen herkennen, zonder daarom al te specifieke coderingen te moeten voorzien. Een voorbeeld:
Sinds de nieuwe wet op de aanvullende pensioenen van 15/12/2015, van kracht sinds 01/01/2016, mogen een grote meerderheid van de contracten groep (2de, 3de pijler) niet langer worden geliquideerd voor de opname van het wettelijk pensioen door de aangeslotenen, momenteel dus op 65 jaar. Echter in het verleden werden veel contracten met een looptijd van 60 jaar opgesteld. Deze termijn, hoewel contractueel, mag niet langer (behalve in de overgangsmaatregelen), worden aangehouden, en als dus de aangeslotenen hun pensioen niet voor de leeftijd van 65 kunnen opnemen, dan zijn de bedrijven wettelijk verplicht de contracten te verlengen tot 65 jaar.
Zo een motief kan tekstueel / kort / uniform omschreven worden.
|
- 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.
|
.
|
|
.
|
.
|
.
|
