|
|
|
3. Nieuwe zaak
- 3.1. Vanuit het beheerspakket
- 3.1.1. Aanspreking
De makelaar beslist een nieuw contract aan te maken.
Als de verzekeraar de service/module gepubliceerd heeft (publicatiesysteem), dan wordt de service/module opgestart.
De service/module van de verzekeraar ontvangt bij de aanspreking parameters die moeten gebruikt worden om op de geschikte pagina van de module terecht te komen.
(Zie voor meer details punt « 1 Raadpleging contract / 1.3 Verbeteringen ».)
In het andere geval kan het contract binnen het beheerspakket aangemaakt worden.
Bij het aanspreken van de module van de verzekeraar voor de aanmaak van een nieuwe zaak, zal de identificatie van de verzekeringnemer binnen het beheerspakket worden meegegeven als parameter.
De verzekeraar kan die informatie opslaan en ze terug geven in het antwoordrecord.
Die informatie laat toe de verzekeringnemer éénduidig te identificeren bij de integratie van het antwoordrecord.
(11/06/2013 - Opmerking : wat je als makelaar/beheerspakket vraagt van je verzekeraar, doe dat dan ook zelf in omgekeerde zin; sla in je beheerspakket op welke identificatie je verzekeringnemer heeft bij welke verzekeraar.)
|
3. Nouvelle affaire
- 3.1. A partir du package
- 3.1.1. Invocation
Le courtier décide de créer un nouveau contrat.
Si la compagnie a publié ce service (système de publication des services), le module compagnie est démarré.
Lors de l’invocation, le module de la compagnie recevra des paramètres qui devront être exploités pour arriver sur la page du module qui traite le service demandé.
(Pour plus de détail, voir le point « 1 Consultation contrat / 1.3 Améliorations ».)
Sinon, le contrat pourra être créé dans le package.
Lors de l’invocation du module compagnie pour réaliser une nouvelle affaire, l’identifiant interne (du preneur) dans le package sera passé en paramètre.
La compagnie pourra stocker cette information et la restituer dans le bloc retour.
Cette information permettra d’identifier le preneur d’assurance de manière univoque lors de l’intégration du bloc retour.
|
.
|
- 3.1.2. Contextuele uitwisseling van gegevens
Om dubbele ingave te vermijden kunnen bepaalde gegevens overgenomen worden uit het beheerspakket van de makelaar.
Het is de verzekeraar die zo een uitwisseling van gegevens opstart.
De uit het beheerspakket overgenomen informatie maakt het mogelijk de schermen van de module van de verzekeraar op voorhand in te vullen.
In functie van de context worden de volgende gegevens uitgewisseld en ter beschikking van de module van de verzekeraar gesteld :
- De makelaar staat op een fiche van een verzekeringnemer
- De gegevens van de verzekeringnemer
Zie de MIG in Telebib.
- De makelaar staat op een fiche van een risico-object
- De gegevens van de verzekeringnemer
Zie de MIG in Telebib.
- Auto : de gegevens van het voertuig + van de gewone bestuurder + van de aanhangwagens
Zie de MIG in Telebib.
- Brand : de gegevens van het gebouw + van de hypothecaire schuldeiser
Zie de MIG in Telebib.
- Andere takken : Geen gegevens, tenzij ...
Zie de MIG in Telebib.
- De makelaar staat op een fiche van een ander type
- Geen enkel gegeven wordt onthouden, maar van zodra de module van de verzekeraar één van de gegevens hierboven opvraagt, start een manuele opzoeking op.
Opmerkingen :
-
Bij de contextuele uitwisseling is de identificatie binnen het beheerspakket van elk type tussenkomende partij (verzekeringnemer, gewone bestuurder, hypothecaire schuldeiser) beschikbaar.
We bevelen de verzekeraars aan deze identificaties op te slaan en deze terug mee te geven in het antwoordrecord.
Gezien dergelijke identificatie éénduidig is, vereenvoudigt ze de identificatie tijdens de integratie van het antwoordrecord.
- De uitgewisselde gegevens worden gepubliceerd in TELEBIB (de MIG : « Uitwisselingen via de context »).
|
- 3.1.2. Echange de données par le contexte
Pour éviter le double encodage, certaines données peuvent être récupérées du package du courtier.
C’est la compagnie qui initie cet échange de données.
Les informations récupérées du package permettront de pré garnir les écrans du module de la compagnie.
En fonction du contexte, les données suivantes seront exportées et mises à la disposition des modules compagnie :
- Le courtier se trouve sur la fiche preneur
- Les données du preneur
Voir les MIG du Telebib.
- Le courtier se trouve sur la fiche objet de risque
- Les données du preneur
Voir les MIG du Telebib.
- Auto : les données véhicule + conducteur habituel + remorques
Voir les MIG du Telebib.
- Incendie : Les données de l’immeuble + créancier hypothécaire
Voir les MIG du Telebib.
- Autre branche : Aucune donnée, sauf si ...
Voir les MIG du Telebib.
- Le courtier se trouve sur une fiche d’un autre type
- Aucune donnée n’est mémorisée mais si la compagnie sollicite une des données ci-dessus, la recherche manuelle est déclenchée.
Remarques :
-
Lors de l’échange contextuel, l’identifiant interne du package sera disponible pour tous les types d’intervenants (preneur, conducteur habituel, créancier hypothécaire).
Nous recommandons aux compagnies de mémoriser ces identifiants et de les restituer dans le bloc retour.
Cet identifiant étant univoque, il facilitera l’identification lors de l’intégration du bloc retour.
- Les données exportées seront publiées dans le TELEBIB (les MIG : « Echanges par le contexte »).
|
.
|
- 3.1.3. Aanmaak van de Nieuwe Zaak in de module van de verzekeraar
De module van de verzekeraar moet valideren dat de gegevens overgenomen uit het beheerspakket worden toegelaten in de module.
Voorbeeld : de makelaar kent de aanspreking/titel van zijn klant, maar de verzekeraar verwerkt slechts een deelverzameling van de mogelijke waarden (lijst X034 in TELEBIB).
Om manipulaties door de makelaar te vermlijden (deze zou in zijn beheerspakket alle waarden met teveel detail gaan corrigeren) kan de verzekeraar
- conversietabellen toepassen, ofwel
- deze vervangen door waarden gekend binnen de module, ofwel
- de makelaar signaleren dat de waarde niet toegelaten is binnen de module.
Het is dan aan de makelaar om een waarde te kiezen uit deze die de module van de verzekeraar voorstelt.
De verzekeraar kan ook het feit onthouden dat het uitgewisselde gegeven in het beheerspakket meer detail heeft en daarom beslissen de waarde niet terug te geven in het antwoordrecord.
Dergelijke procedure laat toe de integratie van het antwoordrecord te vereenvoudigen gezien het gegeven in het beheerspakket zal behouden worden (geen integratiefilter).
- Hij onthoudt dat de informatie rijker is in het beheerspakket.
- Hij geeft de standaard waarde, toegelaten door zijn module, niet terug mee in het antwoordrecord.
|
- 3.1.3. Réalisation de la Nouvelle Affaire dans le module de la compagnie
Le module de la compagnie doit valider si les données rapatriées du package sont admises par son module.
Exemple : le courtier connaît le titre de son client mais la compagnie ne traite qu’un sous ensemble des valeurs du titre (X034 dans TELEBIB).
Pour éviter des manipulations de la part du courtier (corriger toutes les valeurs qui sont plus détaillées dans son package), la compagnie peut
- appliquer des tables de conversion ou
- remplacer par les valeurs connues par son module ou
- signaler au courtier que cette valeur n’est pas admise par le module.
Au courtier de choisir une valeur parmi celles proposés par le module de la compagnie.
La compagnie peut également mémoriser le fait que la donnée importée du package est plus détaillée et ne pas restituer cette valeur dans le bloc retour.
Ce processus permettra d’alléger l’intégration du bloc retour puisque la donné du package sera conservée (pas de filtre d’intégration).
- Elle mémorise le fait que l’information était plus riche dans le package.
- Elle ne restitue pas la valeur standard admise par son module dans le bloc retour.
|
.
|
- 3.1.4. Integratie Antwoordrecord
Zie ook de commentaar en uitleg gegeven voor het bijvoegsel.
- 3.1.4.1. Te integreren sub-rubrieken
Zie bijvoegsel, uitgezonderd de test van het bestaan van het polisnummer.
- 3.1.4.2. Gegevens verzekeringnemer
- Identificatie
- Interne identificatie verzekeringnemer (éénduidige identificatie)
- Naam + voornaam + postcode + geboortedatum
- Naam + voornaam + postcode
- Naam
Als de verzekeringnemer met behulp van zijn interne identificatie éénduidig gevonden is, dan is er in principe geen manipulatie nodig bij de integratie (maar de makelaar kan nog altijd voor een andere verzekeringnemer kiezen).
Als de verzekeringnemer met behulp van de andere zoeksleutels gevonden is, dan moet de makelaar zijn keuze maken in de resultaatslijst (zelfs indien slechts één resultaat) (maar de makelaar kan nog altijd voor een andere verzekeringnemer kiezen).
Als de verzekeringnemer niet gevonden is, dan wordt hij in principe aangemaakt vertrekkende vanuit de gegevens van het antwoordrecord van de verzekeraar (maar de makelaar kan nog altijd voor een andere verzekeringnemer kiezen).
- 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 hebben de voorkeur (defaultkeuze).
- Opmerking
We bevelen aan ALTIJD de verzekeringnemer binnen het beheerspakket aan te maken, vooraleer een transactie via een module van een verzekeraar aan te vatten.
|
- 3.1.4. Intégration Bloc Retour
Voir aussi les commentaires et explications pour l'avenant.
- 3.1.4.1. Sous systèmes à intégrer
Voir avenant sauf test sur existence du n° de police
- 3.1.4.2. Données du preneur
- Identification
- Identifiant interne du preneur (identification univoque)
- Nom + prénom + code postal + date naissance
- Nom + prénom + code postal
- Nom
Si le preneur est trouvé de manière univoque à l’aide de l’identifiant interne du preneur, il n’y a en principe pas de manipulation lors de l’intégration du preneur (mais le courtier a la possibilité de choisir un autre preneur).
Si le preneur est trouvé avec les autres critères de recherche, le courtier doit choisir dans la liste résultant de la recherche (même si un seul preneur) (mais le courtier a la possibilité de choisir un autre preneur).
Si le preneur n’est pas trouvé, il est en principe créé à partir des données du bloc retour de la compagnie (mais le courtier a la possibilité de choisir un autre preneur).
- 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.
- Remarque
Nous recommandons de TOUJOURS créer le preneur dans le package avant de réaliser une transaction dans un module compagnie.
|
.
|
- 3.2. Vanuit het services/modules publicatiesysteem
- 3.2.1. Aanspreking
Niet van toepassing
- 3.2.2. Contextuele uitwisseling van gegevens
Het beheerspakket geeft een opzoekscherm per sub-rubriek opgevraagd door de module van de verzekeraar.
- 3.2.3. Aanmaak van de Nieuwe Zaak in de module van de verzekeraar
Zie 3.1.3 Aanmaak van de Nieuwe Zaak in de module van de verzekeraar.
- 3.2.4. Integratie Antwoordrecord
Zie 3.1.4 Integratie Antwoordrecord.
|
- 3.2. A partir du système de publication des services
- 3.2.1. Invocation
Pas d’application
- 3.2.2. Echange de données par le contexte
Le package propose un écran de recherche par sous système demandé par le module compagnie.
- 3.2.3. Réalisation de la Nouvelle Affaire dans le module de la compagnie
Voir 3.1.3 Réalisation de la Nouvelle Affaire dans le module de la compagnie.
- 3.2.4. Intégration Bloc Retour
Voir 3.1.4 Intégration Bloc Retour.
|
.
|
|
.
|
.
|
.
|
