Syntax Independent - BBP

> Syntax independent - Models & Processes > Broker Business Processes

SYNTAX INDEPENDENT COMPONENTS

Implementation Related Components

Broker Business Processes


De "Broker Business Processes" zijn ontworpen in 2002, eerstens in de context "AS/2" en de implementatie van die "AS/2" in een beheerspakket makelaardij dat in die periode opnieuw ontwikkeld werd. Het Telebib centrum functioneerde op dat ogenblik nog niet volledig autonoom. Deze tekst herneemt diezelfde "Broker Business Processes", en beschrijft ze nu generiek/sectoraal, en voegt tot op heden nog niet herkende en/of nog niet gedocumenteerde BBP toe (april 2010). (We gebruiken hier vanaf nu de afkorting "BBP".)	Les “Broker Business Processes” sont une notion conçue en 2002, premièrement dans le contexte “AS/2” et l’implémentation de cet « AS/2 » dans un package de gestion de bureau de courtage nouvellement développé dans cette même période. A cet instant le centre Telebib ne fonctionnait pas encore de manière totalement indépendante. Ce texte reprend ces mêmes « Broker Business Processes », les décrivant de manière sectorielle uniquement, et y ajoute les BBP non reconnus ou non documentés jusque ce jour (avril 2010). (Est utilisé à partir d’ici dans ce texte, l’acronyme « BBP ».)	These "Broker Business Processes" have first been imagined in 2002 in our "AS/2" vision and the implementation of that "AS/2" in a broker office management system conceived in that same period. At that moment the Telebib centre did not yet function completely independent of that one and specific development. This text re-phrases those same "Broker Business Processes", this time from a more global/sectoral point of view, and adds the BBP that were not yet documented (situation as of april 2010). (As from here on we will use the acronym "BBP".)
Op de volgende pagina lijsten we deze BBP op. Hieronder bepalen we eerst de context en plaatsen we deze BBP in dat grotere geheel.	A la page suivante nous présentons une liste des BBP. Mais ci-dessous nous définissons d'abord le contexte et ces BBP y sont positionnés dans ce grand ensemble.	On the next page you find a list of BBP. But first we define and explain the context and position these BBP within that bigger picture.
De BBP verkiezen het digitale; het gestructureerde en het automatische : Men moet de gestructureerde berichten zo veel als mogelijk gebruiken. Deze maken het de ontvanger mogelijk hun verwerking te automatiseren. e-Mails moeten vermeden worden. De ontvanger rmoet deze manueel verwerken. Voor de afzender: Straight Trough Processinq van de aanvragen tussen verzender en bestemmeling is mogelijk op basis van gestructureerde berichten; men moet de vrije berichten en de e-mails zoveel mogelijk vermijden. Het gestructureerde bericht moet alle informatie bevatten die nodig is opdat de bestemmeling de aanvraag kan afhandelen. De verzender van het bericht moet beseffen dat de bijgevoegde documenten de aanvraag slechts ondersteunen, en dat de aanvraag dus door de bestemmeling zal uitgevoerd worden op basis van de gegevens aanwezig in het gestructureerde bericht. De inhoud van het gestructureerde bericht is de basis van/voor de automatische verwerking en afhandeling door de bestemmeling. Voor de bestemmeling: De bestemmeling ontvangt de berichten en handelt ze af, bij voorkeur automatisch. De weigering van de ontvangst en het niet-afhandelen van het bericht omwille van ontbrekende automatismen moet absoluut/maximaal vermeden worden. () Een eerste alternatief kan de conversie in een "niet-gestructureerd" bericht zijn - een leesbaar tekst-document, en de routing daarvan naar de gepaste dienst, en dat alles nog steeds geautomatiseeerd. Een ultiem alternatief is de routing van dat document naar een meer algemeen back-office. Dat generieke back-office met dan feed-back naar de gebruikers genereren, maar ook naar de instanties die de interne systemen beheren en hun continue evolutie aansturen. () : Het bericht bevat in één of andere variabele een waarde/code die (al) gekend is binnen de Telebib2-community, maar (nog) niet gekend is binnen het IT-systeem van de bestemmeling - ga zo een bericht niet te snel weigeren...	Les BBP favorisent le digital; le structuré et l'automatisation: Il faut utiliser au maximum possible les messages structurés. Ils sont à la base du traitement automatisé par leur destinataire. Les e-mail sont à éviter. Ils obligent à un traitement manuel par leur destinataire. En ce qui concerne l'émetteur: Pour permettre le Straight Trough Processinq du traitement des demandes entre émetteur et destinataire, il faut utiliser les messages structurés, il faut éviter au maximum l’email ou texte libre. Le message structuré doit contenir toutes les données nécessaires au traitement de la demande par le destinataire. L’émetteur du message doit être informé que les documents annexés sont considérés comme les justificatifs de la demande et donc que la demande est exécutée par le destinataire sur base des données contenues dans le message structuré. Les données du message structuré sont à la base du traitement automatisé par leur destinataire. En ce qui concerne le destinataire: Le destinataire réceptionne et traite les messages, de préférence de manière automatisée. Le refus de la réception et le non-traitement du message en absence des automatismes nécessaires sont à éviter de manière absolue/maximale. () Une première alternative doit être la conversion du message en "déstructuré" - document textuel et lisible par l'humain -, et son routage vers le service de gestion adéquat, le tout encore toujours de manière automatisée. Une dernière alternative est le routage de tel document vers un back-office générique. Tel back-office générique doit en générer du feed-back vers les utilisateurs, mais aussi vers les instances gérant les systèmes de gestion et leur évolution continue. () : Le message contient dans l'une ou l'autre variable une valeur ou un code lequel est (déjà) connu au niveau du Telebib2, mais lequel n'est pas (encore) connu en sein du système informatique du destinataire - ne refusez pas trop vite ce genre de message/situation...	These BBP prefer the digital way; the structured and the automated: One must maximise the usage of the structured messages. They are the basis for the automated processing by the destinee. e-mails are to be avoided. They oblige a manual processing by the destinee. The point of view of the sender: Straight Trough Processinq of transactions in between sender and destinee needs structured messages, e-mail and free-text must be avoided. The structured message must contain all necessary information for the destinee to be able to handle what is asked for. The sender is aware of the joined documents merely justifying what is asked for and of the destinee executing as based upon the information present in the structured message. The structured message content is the basis for the automated handling by the destinee. The point of view of the destinee: The destinee receives and handles the messages, preferably automated. Denial of reception and non-treatment of some message in the absence of automated treatment is to be avoided by all means. () A first alternative is the conversion of such message into a "destructured" human-readable text-document, to be routed to the right handling administration/division/service - that routing still being automated. A last alternative is the routing of such document to some generic back-office. Such a generic back-office must give feedback to the users, and to those managing the systems and the continuous evolution of such systems. () : The message might contain in some data-element a value or a code that is already known of within Telebib2, but which is not (yet) known within the IT-system of the destinee - do not simply nor all too soon refuse such message/case...
Men definieert het begrip "domein" : In het algemeen zegt een domein welke de uit te wisselen informatie is volgens het type polis, volgens het risico object en volgens de waarborgen. Een BBP komt in principe voor binnen een specifiek domein. (Een nieuwe zaak "auto" of een bijvoegsel in een dossier "brand eenvoudige risico's" bijvoorbeeld.) Er zijn echter ook BBP die de notie "domein" overstijgen - denk aan het rekeninguittreksel producent bijvoorbeeld. Oorspronkelijk deed het domein enkel uitspraken over de hoofdzaak van het contract, en niet over alles wat bijkomstig aan het contract is (hoofdwaarborgen versus accessoire waarborgen). Sinsdien hebben de "Filters per domein" echter een meer restrictieve interpretatie van die notie domein met zich mee gebracht.	Est définie une notion de « domaine » : En général un domaine spécifie l'information a échanger et comment elle est structurée en fonction du type de police, de l'objet de risque et les garanties. Tout BBP ou échange relatif à une police, une quittance, un sinistre est à situer en sein d'un domaine d'activités assurances. (Une nouvelle affaire "auto", ou un avenant dans un dossier "incendie risque simple".) Mais il y a aussi des BBP surpassant cette notion de "domaine" - pensez par exemple à l'extrait de compte producteur. A l'origine le domaine s'exprimait sur le principal du contrat uniquement, et pas sur tout ce qui est considéré accessoire. Depuis, les "Filtres par domaine" ont amenés une interprétation plus restricitve de cette notion de domaine.	Our « domain » concept : In general a domain specifies the information to be exchanged and structured; for some type of policy, some risk-objec and the guarantees. Every BBP or exchange about some policy, a renewal, a claim, must be localised within some domain of insurance activities. (A new business in "motor", or an amendment to some "fire simple risks" contract.) There are also BBP that proceed above such "domain" - e.g. think of the periodic accounting statement. Originally such domain dictated things on the higher level of the contract only, and not on levels/things considered accessory. Since then, "Filters per domain" have introduced a more restrictive interpretation of that "domain" concept.
Men definieert het begrip "interfaces" : Men wil de makelaar toelaten "services" aan te spreken, op een uniforme manier, op basis van een uniforme publicatie van diezelfde aanspreekbare services door de verzekeraars. Die services worden veelal geleverd door "maatschappij-modules". De input van in het pakket gekende informatie, in de maatschappij-modules, wil men vermijden, via de context of de contextuele uitwisseling. Dat "pakket" is dan het beheerspakket makelaardij. Nadat in de maatschappij-modules (verzekerings-)technische acties werden uitgevoerd, wil men met behulp van "antwoordrecords" het pakket aanvullen.	Est définie une notion de « interfaces » : On veut permettre au courtier d’invoquer des « services », de manière uniforme, sur base d’une publication uniforme par les assureurs, de ces mêmes services invocables. Ces services sont généralement réalisés par des « modules compagnies ». On veut éviter l’encodage dans les modules compagnies d’informations connues par le package, via l’échange contextuel ou contexte. Ce « package » est bien le package de gestion de bureau de courtage. On veut alimenter le package, en retour d’actes techniques posés dans un module compagnie, à l’aide du « bloc retour ».	Our « interfaces » concept : We want to allow brokers to call « services », uniformely, based upon a uniform publication by the insurers, of these same call-able services. These services are offered as « company modules ». We want to avoid the encoding in such company modules of information already present in the broker's package, by means of contextual exchange or context. That « package » is the broker office management system (BMS). We want to feed the broker's package, once returned from (insurance-technical) actions taken on/in company modules, by means of "response-records" messages.
Men definieert een "transactionele stream" : De makelaar wenst vanuit zijn pakket een service aan te spreken. Het pakket kijkt via een interface na of de maatschappij deze service gepubliceerd heeft. Zo ja start deze de maatschappij-module op. Als de maatschapppij-module de contextuele uitwisseling implementeert, dan vraagt ze aan het pakket gekende gegevens uit de databank (dB) van de makelaar op. Het pakket exporteert deze gegevens. Als de vraag van de maatschappij niet voldoende precies is (vb meerdere risico-objecten), dan laat het pakket het de makelaar toe zijn selectie te verfijnen. (6 kan in theorie voor 5 komen.) De makelaar vult de overige informatie aan in de maatschappij-module. De informatie gaat naar de maatschappij. Een juridisch merkteken kan voorzien en gebruikt worden. Een antwoordrecord komt in de brievenbus van de makelaar terecht. Dat antwoordrecord wordt geïmporteerd in het pakket, en de gegevens van de makelaar worden bijgewerkt met deze die van de maatschappij komen. De reactie bij middel van het antwoordrecord is direct en volledig en laat zo de makelaar toe zijn dossier af te sluiten. Als de verzekeraar niet alle nodige informatie kan bezorgen, dan nog blijft de reactie direct maar is ze voorlopig wat betreft de inhoud - denk hierbij aan de contante premies die gekend zijn na uitvoering van programma's in batch. Op zo een voorlopig antwoordrecord volgt dan ook een uitgesteld en definitief atwoordrecord.	Est défini un « flux d’une transaction » : Le courtier veut réaliser un service à partir de son package. Le package vérifie à l’aide d’une interface si la compagnie a publié ce service. Si oui, le module de la compagnie est démarré. Si le module de la compagnie a implémenté l’échange contextuel, il demande au package des données connues par ce dernier et sortand de la banque de données (dB) du courtier. Le package exporte les données. Si la question de la compagnie n’est pas assez précise (ex plusieurs objets de risques), le package permet au courtier d’affiner sa sélection. (6 pourrait théoriquement devancer 5.) Le courtier complète les informations restantes dans le module compagnie. Ces informations sont envoyées à la compagnie. Une trace juridique peut être organisée et exploitée. Un bloc retour est déposé dans la boîte aux lettres du courtier. Ce bloc retour est importé dans le package et les données du courtier sont mises à jour à l’aide des données provenant de la compagnie. La réaction par bloc retour est immédiate et complète et permet ainsi au courtier de refermer son dossier. Si l'assureur n'est pas en mesure d'envoyer toutes les informations, la réaction par bloc retour reste immédiate, mais est provisoire au niveau de son contenu - pensez au primes au comptant qui sont disponibles après l'exécution de programmes batch. Tel bloc retour provisoire est logiquement suivi du bloc retour différé et définitif.	.

De voorstelling hieronder stelt diezelfde "transactionele stream" voor: Naast de andere acties die men in een beheerspakket kan ondernemen. Naast de idee dat een maatschappij-module kan opgestart worden, los van één of ander beheerspakket. Met de voorstelling van de contextuele vraag/antwoord communicatie tussen de maatschappij-module en het beheerspakket. Met de voorstelling van de verschillende copy/paste mogelijkheden via het AS/Web-clipboard. Dit voor zover dat deze en/of gene zijde dat AS/Web-clipboard geïmplementeerd hebben. Uiteindelijk is er een direct (lokaal) antwoord-record dat ofwel volledig en dan definitief is, ofwel onvolledig is en dan nog gevolgd zal worden door een uitgesteld volledig en defintief antwoord-record. En als laatste, naast de idee dat een transactie via een eenvoudig gestructureerd bericht kan afgehandeld worden, al of niet met als antwoord een ander gestructureerd bericht.	Le schéma ci-dessous représente ce même « flux d’une transaction » : En plus des autres actions pouvant être entreprises dans un package de gestion. Outre l'idée qu'un module de compagnie peut être démarré, séparé d'un package de gestion. Avec la représentation de la communication contextuelle question/réponse entre le module de l'assureur et le progiciel de gestion. Avec la représentation des différentes options copier/coller via le presse-papiers-AS/Web. Ceci dans la mesure où tel et/ou ce côté a implémenté ce presse-papiers-AS/Web. En fin de compte, il y a une réponse directe (locale) laquelle est soit complête et donc définitive, soit incomplête et alors ce "bloc-retour" sera ensuite suivi d'un "bloc-retour" différé et complet et définitif. Et en dernier, outre l'idée qu'une transactio peut être effectuée par simple message structuré, oui ou non y compris une réponse par un autre message structuré.	.

29.01.2020De afzender en de bestemmeling degelijk identificeren. 21/08/2019: Het is niet "de makelaar", maar wel "de beheerder binnen het makelaarskantoor" die één of andere beheersdaad stelt. Die "transactionele stream" identificeert daarom niet alleen het kantoor, maar ook die beheerder binnen dat kantoor. Die beheerder kan in een kleinere organisatie een individu zijn, en kan in een grotere organisatie een dienst zijn. Als algemene regel stellen we dat voor elk bericht tussen organisatie A en B niet alleen die organisatie, maar ook het individu of de dienst binnen die organisatie expliciet in de adressering herkenbaar is. In een (Telebib2-Edifact) enveloppe XGH-XGT vermelden we dan het "sender domain address" en het "sender user address" - op die manier is de afzender tot op het niveau van het individu of de dienst gekend. Die enveloppe bevat ook het "recipient domain address" en voor zover mogelijk/gekend het "recipient user address". Als een "transactionele stream" bestaat uit het aanroepen en gebruiken van een verzekeraar-specifieke front-end module door een makelaar-individu (te herkennen via zijn [domain-address - user-address]) en finaal een antwoordrecord van die module aan dat makelaar-individu, dan komt dat antwoordrecord minstens van de (verzekeraar) "sender domain address" en is dat gericht aan de (makelaar) "recipient domain address" inbegrepen het (individu of dienst) "recipient user address". Als een "transactionele stream" bestaat uit het verzenden van (bijvoorbeeld) een MPB (productiebericht) door een makelaar-individu/dienst (te herkennen via zijn [domain-address - user-address]) en één of ander antwoord-bericht van die verzekeraar aan die makelaar-individu/dienst, dan komt dat antwoord-bericht minstens van de (verzekeraar) "sender domain address" en is dat gericht aan de (makelaar) "recipient domain address" inbegrepen het (individu/dienst) "recipient user address". Dit is geldig voor elke uitwisseling van berichten, of dat nu productie of schade of boekhouding is. De "transactionele stream" kan nog juister geïdentificeerd worden als het "antwoordende/reagerende" bericht verwijst naar de GUID van het "vragende" bericht. Daarom voorzien we nu de techniek RFF+084 / RFF+085 (GUID bericht / gerefereerd bericht) meer te veralgemenen.	Bien identifier, et l'originaire et le destinataire d'un envoi. 21/08/2019: Ce n'est pas le "courtier" mais bien "le gestionnaire chez le courtier" qui effectue l'acte de gestion. C'est pourquoi le "flux d'une transaction" identifie et le courtier, et le gestionnaire chez ce courtier. Ce gestionnaire peut être dans une petite organisation un individu, et dans une organisation plus importante un service. Nous partons du principe que, pour tout message entre les organisations A et B, telle organisation aussi bien que l'individu ou le service en sein de telle organisation soit explicité dans l'adressage. Dans une enveloppe (Telebib2-Edifact) XGH-XGT est mentionné le "sender domain address" et le "sender user address" - ainsi son émetteur est connu jusqu'au niveau de l'individu ou du service. Cette enveloppe mentionne aussi le "recipient domain address" et pour autant que possible/connu le "recipient user address". Dans le cas où le "flux d'une transaction" est composé de l'appèl d'un module front-end propre à l'assureur par un courtier-gestionnaire (identifiable par son [domain-address - user-address]) et finalement un bloc-retour de tel module envers ce courtier-gestionnaire, alors tel bloc-retour émane au moins du (assureur) "sender domain address" et adresse le (courtier) "recipient domain address" y compris le (individu ou service) "recipient user address". Dans le cas où le "flux d'une transaction" est composé de l'envoi de (par exemple) un MPB (message production) par un courtier-gestionnaire/service (identifiable par son [domain-address - user-address]) et l'un ou l'autre message-réponse de tel assureur envers ce courtier-gestionnaire/service, alors tel message-réponse émane au moins du (assureur) "sender domain address" et adresse le (courtier) "recipient domain address" y compris le (individu/service) "recipient user address". Ceci est valable pour tout échange de messages, que ce soit en gestion production ou sinistres ou comptabilité... Le "flux d'une transaction" peut être géré/maintenu de manière encore plus fine quand le message "réponse/réaction" réfère le GUID du message "demandant". C'est pourquoi nous désirons généraliser la technique RFF+084 / RFF+085 (GUID message / GUID message référé).	.
Hetzelfde, met andere woorden... De doelstelling: Het systeem dat een bericht ontvangt moet dit kunnen toewijzen aan degene die het aanvroeg. In de uitwisseling tussen de verzekeraar en de tussenpersoon gebeurt die identificatie met het ID (domain-address) en sub-ID (user-address) op het uitwisselingsplatform. De volledige identificatie zit in de (Telebib2-Edifact) enveloppe XGH-XGT van het bericht. ( https://www.telebib2.org/SegmentLayOut.asp?STag=XGH ) De verzender (sender) : de (Telebib2-Edifact) enveloppe XGH-XGT bevat het Composite Data Element C900 sender identification met daarin de elementen : "sender domain address" (X921) en "sender user address" (X922). De bestemmeling (recipient) : de (Telebib2-Edifact) enveloppe XGH-XGT bevat het Composite Data Element C905 recipient identification met daarin de elementen : "recipient domain address" (X923) en "recipient user address" (X924). De verschillende situaties : 1. de gebruiker (aanvrager) realiseert een transactie in de applicatie van de verzekeraar (1.1). Op de beëindiging van die transactie volgt een bevestiging van die transactie per gestructureerd bericht aan die aanvrager (1.2). 1.1 de front-end module van de verzekeraar bewaart het "sender domain address" (X921) en het "sender user address" (X922) van de aanvrager (dus de volledige identificatie van de aanvrager). 1.2 bij de voltooing van de transactie, in het uitgegeven bericht, geeft de applicatie van de verzekeraar die identificatie terug mee in het "recipient domain address" (X923) en in het "recipient user address" (X924) van degene aan wie dat bericht gericht is. 2. de gebruiker (aanvrager) stuurt een vraag via een (Telebib2-Edifact) bericht (2.1). Op de beëindiging van die transactie volgt eventueel een antwoord per gestructureerd bericht aan die aanvrager (2.2). 2.1 het bericht vanwege de aanvrager bevat het "sender domain address" (X921) en het "sender user address" (X922) van de aanvrager (dus de volledige identificatie van de aanvrager). 2.2 bij de voltooing van de transactie, in het uitgegeven bericht, geeft de applicatie van de verzekeraar die identificatie terug mee in het "recipient domain address" (X923) en in het "recipient user address" (X924) van degene aan wie dat antwoord-bericht gericht is.	En d'autres mots... L'objectif : Lors de la réception d'un message dans le système destinataire, permettre l'assignation de celui-ci au demandeur. Dans les échanges entre intermédiaire et assureur - cette identification se fait grâce au ID (domain address) et sub-ID (user address) de la plate-forme d'échange. Cette identification complète se fait dans l'enveloppe (Telebib2-Edifact) XGH-XGT du message. ( https://www.telebib2.org/SegmentLayOut.asp?STag=XGH ) Pour identifier le demandeur (sender) : l'enveloppe du message (Telebib2-Edifact) XGH-XGT prévoit le Composite Data Element C900 sender identification dans lequel, les éléments : le "sender domain address" (X921) et le "sender user address" (X922). Pour identifier le destinataire (recipient) : l'enveloppe du message (Telebib2-Edifact) XGH-XGT prévoit le Composite Data Element C905 recipient identification dans lequel, les éléments : le "recipient domain address" (X923) et le "recipeint user address" (X924). Situations : 1. l'utilisateur (demandeur) réalise une transaction dans l'application de l'assureur (1.1). A la finalisation de cette transaction, la confirmation de la transaction est transmise par un message structuré au demandeur (1.2). 1.1 Le module front-end de l'assureur récupère (garde) le "sender domain address" (X921) et le "sender user address" (X922) du demandeur (identification complète du demandeur). 1.2 A la finalisation de cette transaction, lors de l'émission du message, l'application de l'assureur retransmet l'identification du demandeur via le "recipient domain address" (X923) et le "recipient user address" (X924) à qui doit être assigné la message. 2. l'utilisateur (demandeur) transmets une demande via un message (Telebib2-Edifact) (2.1). A la finalisation de cette transaction, la réponse éventuelle attendue à la demande est transmise par un message (Telebib2-Edifact) au demandeur (2.2). 2.1 Le message transmis par le demandeur contient le "sender domain address" (X921) et le "sender user address" (X922) du demandeur (identification complète du demandeur). 2.2 A la finalisation de cette transaction, lors de l'émission du message, l'application répondante retransmet l'identification du demandeur via le "recipient domain address" (X923) et le "recipient user address" (X924).
Men definieert enkele "business principes" : De makelaar streeft naar een zeer volledige beschrijving van de "verzekeringnemer" en hij beschouwt de gegevens in zijn databank als de juiste. De makelaar wil beschikken over een versie van alle contracten van zijn verzekeringnemer, ongeacht de maatschappij. De makelaar kent het patrimonium van zijn klant. De makelaar wil zijn dossier in één handeling kunnen afsluiten. Tegelijkertijd, De officiële versie van de administratieve gegevens van het contract en van de waarborgen is deze van de maatschappij. (vb: aanvangsdatum, waarborgen, formules, producten, ...) De maatschappij gebruikt niet altijd alle details van een waardenlijst zoals vastgelegd in TELEBIB. Voorbeeld : codering titel(X036) De makelaar kan in zijn pakket de juistere informatie hebben. Tussen de gegevens zoals in het pakket, en deze van de maatschappij, kunnen er dus verschillen zijn. Deze afwijkingen kunnen zichtbaar zijn op het ogenblik van de uitwisseling van gegevens via de context, en tijdens de integratie van antwoordrecords.	Sont définis quelques « principes business » : Le courtier veut une fiche « preneur » très développée et il considère qu’elle est plus précise dans sa DB à lui. Le courtier veut disposer d’une version de tous les contrats de son preneur quelle que soit la compagnie. Le courtier connaît le patrimoine de son client. Le courtier veut clôturer son dossier en une opération. En même temps, La version officielle des données administratives du contrat et des garanties est celle de la compagnie. (ex: date d’effet, garanties, formules, produits, …) La compagnie n’utilise pas tous les détails d’une liste de valeurs définie dans TELEBIB. Exemple : code titre (X036) Le courtier peut avoir des informations plus précises dans son package. Entre la situation du package et celle de la compagnie, il peut donc y avoir des divergences. Ces divergences peuvent se présenter lors de l’échange de données via le contexte et lors de l’intégration du bloc retour.	.
Men definieert het begrip "(integratie-)filter" : Contextuele uitwisseling : dB makelaar - makelaarspakket -> (Filter) -> maatschappijmodule - dB maatschappij Als een gegeven uit het pakket meer precies is dan wat de maatschappij toelaat, dan moet dit verschil door de maatschappijmodule onderschept worden. De maatschappij kan een filter ("import-" of "integratie-filter") in zijn module stoppen en toepassen, ofwel kan ze haar schermen opvullen met die gegevens en ze dan verwerpen bij de validatie van die scherm-gegevens. Het pakket vragen een filter ("export-filter") voor contextuele uitwisseling te beheren is erg zwaar qua onderhoud, gezien de maatschappijen dan aan de pakketten moeten melden welke waarden zijn al dan niet toelaten via hun modules, inbegrepen alle wijzigingen daaraan.	Est définie une notion de « filtre d’intégration » : Echange contextuel : dB courtier – package du courtier -> (Filtres) -> module compagnie – dB compagnie Si une donnée provenant du package est plus précise que celle admise par la compagnie, cette divergence est à gérer par le module de la compagnie. La compagnie a le choix d’appliquer un filtre (« filtre d’importation » ou « d’intégration ») dans son module ou bien elle pré garnit les écrans avec cette donnée et celle-ci sera rejetée lors de la validation des données. Demander aux packages de gérer un filtre (« filtre d’exportation ») pour l’échange contextuel est une opération très lourde à maintenir parce que les compagnies doivent signaler aux packages toute modification au niveau des valeurs admises par leur module.	.
Integratie antwoordrecord : db maatschappij - maatschappijmodule -> (Filter) -> makelaarspakket - dB makelaar Om dit verschil in gegevens op te vangen stelt men het gebruik van "integratie-filters" voor. Een "integratie-filter" steld twee gegevens voor die beide in principe juist zijn, maar toch verschillend. Voorbeeld : in het pakket is de codering van de titel gelijk aan "Eerwaarde Pater" en de maatschappijmodule kent enkel de waarde "De heer". Men kan voor zo een filter minder of meer complex gedrag bedenken : Tijdens de integratie van een antwoordrecord toont het filter de makelaar enkel de verschillen. Men stelt defaultkeuzes voorop die dan voorrang hebben (gegevens van de makelaar of van de maatschappij). De activatie van de filter kan ingesteld worden per maatschappij en per domein. Als de makelaar een defaultkeuze in voorrang wijzigde, dan zal het filter dit onthouden en de volgende keer deze nieuwe defaultkeuze voorstellen.	Intégration bloc retour : dB compagnie – module compagnie -> (Filtres) -> package du courtier – dB courtier Pour résoudre cette discordance d’informations, il est proposé d’utiliser des « filtres d’intégration ». Un « filtre d’intégration » présente deux informations en principe correctes mais divergentes. Exemple : le code titre du package contient la valeur « Révérend Père » et le module de la compagnie ne traite que la valeur « Monsieur ». On peut s’imaginer des comportements moins ou plus avancés d’un tel filtre: Lors de l’intégration d’un bloc retour, sont présentées au courtier uniquement les différences. Sont définies des valeurs par défaut qui seront prioritaires (données du courtier ou de la compagnie). L’activation du filtre sera paramétrable par compagnie, par domaine. Le courtier ayant modifié une valeur prioritaire par défaut, lors de la prochaine intégration, le « filtre d’intégration » proposera ce choix du courtier.	.
Let op : Deze "integratie-filter" is iets anders dan de "filter per domein" van de polistypes / risico-objecten / waarborgen / omstandigheden / document-types ...	Attention : Ce "filtre d'intégration" est autre chose que le "filtre par domaine" des types de polices / objets de risque / garanties / circonstances / types de documents ...	.
Men maakt onderscheid tussen verschillende (deel-)verzamelingen van gegevens die worden uitgewisseld : Contextuele uitwisseling : export van gegevens (vanuit het standpunt van het systeem van de makelaar) Verzekeringnemer Risico-object Risico-object + bepaalde types betrokkenen (denk aan het voertuig + de gewone bestuurder, of aan het gebouw + de hypothecaire schuldeiser, ...) ... Antwoordrecord : import van gegevens (vanuit het standpunt van het systeem van de makelaar) Contract Verzekeringnemer Risico-object Waarborgen Kwijting	Est faite distinction entre divers (sous-)ensembles de données échangées : Echange contextuel : données exportées (du point de vue du système du courtier) Preneur Objet de risque Objet de risque + certains types d’intervenants (imaginez le véhicule + le conducteur habituel, ou l’immeuble + le créancier hypothécaire, ...) ... Bloc retour : données importées (du point de vue du système du courtier) Contrat Preneur Objet de risque Garanties Quittance	.
Men bedenkt een vereenvoudigd gegevensmodel :	Est imaginé un modèle de données simplifié :	.

Dat model is herwerkt (in 2010) :	Ce modèle est maintenant (2010) ré élaboré :	.


Voor elk type (deel-)verzameling identificeert men de business partner die in principe meester van de gegevens is : Verzekeringnemer ( : meester = makelaar) Risico-object ( : meester = makelaar) Risico-object + elke betrokkene, in en vanuit dat risico-object (inbegrepen de verzekeringnemer, maar dan niet inbegrepen, bijvoorbeeld de verzekeraar van de polis) De betrokkene, in en vanuit dat risico-object, indien van het type ?...? ( : meester = sector) en dan ook nog, de gegevens, minder "algemeen" maar vooral meer "specifiek" ?...? ( : meester = makelaar) Contract ( : meester = verzekeraar) Waarborg en zijn details ( : meester = verzekeraar) Kwijting ( : meester = verzekeraar) Voor de schadedossiers is het minder evident hierover uitspraken te doen, het principe zou kunnen zijn : Als basis, uitgesloten het gedelegeerde schadebeheer : Van het contract, van het risico-object, de betrokkenen ( : meester = makelaar) Schade - Gebeurtenis (versie makelaar) enzoverder.... Verzekeraar Schadedossier (zijn administratieve gegevens) Betrokkenen schadedossier Schadedossier - Gebeurtenis (versie maatschappij) Schadedossier - Evaluatie Schadeloosstelling Gemeenschappelijk Schadedossier - Schade Schadedossier - Schade - Schade-object Bijkomend moet men hier het onderscheid maken tussen het schadedossier onder het beheer van de verzekeraar, en het schadedossier onder het beheer van de makelaar in delegatie.	Pour chacun des (sous-)ensembles est identifié le partenaire business qui en principe a la mainmise sur les données : Preneur ( : mainmise = courtier) Objet de risque ( : mainmise = courtier) Objet de risque + tout intervenant, dans et à partir de tel objet de risque (ceci incluse le preneur déjà mentionné, mais n‘inclue donc pas, par exemple l’assureur de la police) L’intervenant, dans et à partir de tel objet de risque, si de type ?... ? ( : mainmise = secteur) et en plus, les données moins « générales », mais bien plus « spécifiques » ? ... ? ( : mainmise = courtier) Contrat ( : mainmise = assureur) Garantie et son détail ( : mainmise = assureur) Quittance ( : mainmise = assureur) Pour les dossiers sinistres il est moins évident de s’exprimer là-dessus, le principe pourrait être : De base, hors délégation : Du contrat, de l’objet de risque, les intervenants ( : mainmise = courtier) Sinistre - Evénement (version courtier) etcétéra.... Assureur Dossier sinistre (ses données administratives) Intervenants sinistre Sinistre - Evénement (version cie) Sinistre - Evaluation Indemnité Commun Sinistre - Dommage Sinistre – Dommage - Objet endommagé Il faut ici, en plus, faire une distinction entre le sinistre géré sous autorité de l’assureur, et celui géré sous autorité du courtier délégataire.	.
Wat betreft de « Broker Business Processes » («BBP») beschrijft men de transacties : Raadpleging van een contract (in detail) (aanmaak van een) Bijvoegsel (in detail) (aanmaak van een) Nieuwe zaak (in detail) (De eerste versie van de BBP beschreef enkel de volledig uitgewerkte versies van die drie transacties.) (Idealiter zijn deze drie transacties beschikbaar binnen elk type domein.) (Deze transacties kunnen uitgevoerd worden bij middel van de betreffende service/module, aangeboden door de verzekeraar. Indien dergelijke service niet beschikbaar is, dan kan de transactie ofwel niet gebeuren (bijvoorbeeld: de consultatie van een contract), ofwel moet de transactie dan via een andere weg gebeuren (bijvoorbeeld: de aanmaak van een bijvoegsel in domein xyz). Dat een service/module niet in het aanbod van een verzekeraar zit betekent niet noodzakelijk dat deze verzekeraar dan ook geen antwoordrecord kan leveren.)	Au niveau des « Broker Business Processes » («BBP») sont identifiées les opérations : Consultation d’un contrat (en détail) (création d’un) Avenant (en détail) (création d’une) Nouvelle affaire (en détail) (La première version des BBP ne mentionnait de manière élaborée, que ces trois opérations.) (Idéalement, ces trois opérations sont là pour tout type de domaine.) (Ces opérations peuvent être réalisées en exploitant le service en question, mis à disposition par l’assureur. Tel service n’étant pas mis à disposition implique que l’opération ne peut pas être réalisée du tout (exemple : consultation d’un contrat), ou que l’opération doit être réalisée autrement (exemple : création d’un avenant en domaine xyz). Un service n’étant pas mis à disposition n’implique pas que tel assureur soit incapable de délivrer le bloc retour adéquat.)	.
(aanmaak van een) Tarifering (Input van de WGN dd. 13/10/2016) Met object-actie code 0102 kan men een tarificatie-module aanroepen/opstarten (zonder enig al bestaand tariferingsdossier te specificeren) - bij één verzekeraar. Met object-actie code 0170 kan men een multi-tarificatie-sessie aanroepen/opstarten (men kan hierbij nooit een bestaand tariferingsdossier te specificeren) - bij een opeenvolgende reeks verzekeraars. Het bericht M0109 is het resulterende antwoord-record/bericht na die 0102 aanroep/verwerking. Of nog de reeks individuele/aparte M0109 berichten na de 0170 aanroep/verwerking. Elke M0109 bevat zijn eigen RFF+004 "tariferingsnummer". Met object-actie code 0102 kan men een tarificatie-module aanroepen/opstarten voor de consultatie van een bestaand tariferingsdossier op basis van dat RFF+004 "tariferingsnummer". Met object-actie code 0103 kan men een module-nieuwe-zaak aanroepen/opstarten op basis van een bestaand tariferingsdossier op basis van dat RFF+004 "tariferingsnummer". Het bericht M0103 is het resulterende antwoord-record/bericht na die 0103 aanroep/verwerking. Hierin moet die RFF+004 "tariferingsnummer" nog steeds voor komen, naast het RFF+001 "polisnummer", opdat het tariferingsdossier en de polis kunnen gelinkt worden. Noteer dat de MPB (ProductieBerichten) M0124 bruikbaar blijft voor de gevallen buiten dit proces dat eerder voor de "private lines" dan voor de "commercial lines en/of grote risico's" bedacht is. In de M0109 blijven de ROD en ICD dus verplicht te voorzien, wat niet het geval is in de M0124.	(création d'une) Tarification (Input du GTN dd. 13/10/2016) Avec le code objet-action 0102 le module tarifaire peut être appelé/exécuté (sans spécification d'un dossier tarifaire quelconque) - chez un assureur. Avec le code objet-action 0170 une session-multi-tarifications peut être appelé/exécuté (ici il est tout à fait impossible de spécifier un dossier tarifaire pré-existant) - chez une suite d'assureurs distincts. Le message M0109 est le bloc-retour/message résultant après cet appel/exécution du 0102. Ou la série de messages M0109 après l'appel/exécution du 0170. Chaque M0109 contient son propre RFF+004 "numéro de tarification". Avec le code objet-action 0102 le module tarifaire peut être appelé/exécuté pour la consultation d'un dossier tarifaire pré-existant sur base du RFF+004 "numéro de tarification". Avec le code objet-action 0103 le module-nouvelle-affaire peut être appelé/exécuté sur base d'un dossier tarifaire pré-existant en spécifiant le RFF+004 "numéro de tarification". Le message M0103 est le bloc-retour/message résultant après cet appel/exécution du 0103. Ici ce RFF+004 "numéro de tarification" doit encore toujours être présent, en plus du RFF+001 "numéro du contrat", pour que le dossier tarifaire et le dossier nouvelle affaire puissent être liées. Notez que le MPB (Messages Production) M0124 reste utilisable pour les cas restants en dehors du processus décrit/pensé plus "private lines" que "commercial lines et/ou grands risques". Donc, dans les M0109 les ROD et ICD restent obligatoires, ce qui n'est pas le cas dans ce M0124.	.
Notez comment le jargon propre é la syntaxe d'impémentation (Telebib2-Edifact) s'introduit dans ces textes. Textes lesquels décrivent les choses, en principe indépendamment de l'éventuel syntaxe d'implémentation...	Merk op hoe het jargon eigen aan de implementatie-syntax (Telebib2-Edifact) binnensluipt in deze teksten. Teksten die in principe de dingen beschrijven, los van de eventuele implementerende syntax...	.
Raadpleging schade(in detail) (Voor de schadedossiers heeft men in eerste instantie slechts gedacht aan de contextuele uitwisseling van het polisnummer en niets meer. Zonder expliciet te zijn dacht men enkel aan de service/module "consultatie schadedossier". De MIG van release 01.01.2006 voegen daar het schadedossiernummer aan toe.)	Consultation d’un sinistre (en détail) (Pour les sinistres n’était, dans un premier stade, pensé qu’à l’échange contextuel du numéro de police, et rien de plus. Sans que c’était explicite, n’était pensé qu’à l’opération « consultation d’un dossier sinistre ». Les MIG du release 01.01.2006 y ajoutent le numéro du dossier sinistre.)	.
Raadpleging kwijting (in detail) (Aangaande de kwijtingen heeft men tot op heden slechts gewerkt op basis van de contextuele uitwisseling van het polisnummer en niets meer. Zonder echt expliciet te zijn, denkt men enkel in functie van de module "consultatie van een kwijting".)	Consultation d’une quittance (en détail) (Pour les quittances n’est, jusque ce jour, pensé qu’à l’échange contextuel du numéro de police, et rien de plus. Sans que c’était explicite, n’était pensé qu’à l’opération « consultation d’une quittance ».)	.
(aanvraag) Portefeuilleoverzicht (in detail) (Men mag de transacties die de BBP beschrijven niet vereenzelvigen met de servicemodules aangeboden door de verzekeraars. Anders moeten we er een betere naam voor bedenken. Men moet ook denken aan de transacties die via heen en weer gaande gestructureerde berichten tot stand komen.) Release 01.01.2006 beschrijft zo de combinatie vraag/antwoord bestaande uit MIG M0401 (Aanvraag portefeuilleoverzicht) en M0114 (Portefeuilleoverzicht).	(demande de) Relevé de portefeuille (en détail) (Il ne faut pas trop identifier les opérations des BBP avec les seuls services offerts par les assureurs. Sinon il faut trouver un meilleur libellé que « BBP ». On doit aussi imaginer les opérations exécutées par un aller-retour de messages structurés.) Depuis le release 01.01.2006 est ainsi défini l’ensemble question/réponse des MIG M0401 (Demande de relevé de portefeuille) et M0114 (Relevé de portefeuille).	.
(aanvraag) Antwoordrecord op aanvraag (in detail) Release 01.01.2006 beschrijft de combinatie vraag/antwoord van de MIG M0405 (Aanvraag antwoordrecord) en de M0101 (Antwoordrecord op aanvraag).	(demande d’un) Bloc retour à la demande (en détail) Depuis le release 01.01.2006 est défini l’ensemble question/réponse des MIG M0405 (Demande d’un bloc retour) et M0101 (Bloc retour à la demande).	.
Figuur 6 - BBP via uitwisseling van berichten / Figure 6 - BBP par échange de messages
(aanvraag) Administratie wijziging (inningswijze) (in detail) Release 01.01.2009 beschrijft de vraag MIG M0105 (Aanvraag administratieve wijziging (inningswijze)), maar het antwoord daarop staat er niet echt expliciet uitgewerkt bij. (deze zouden eveneens in beide richtingen bruikbaar zijn?)	(demande d’une) Modification administrative (mode d’encaissement) (en détail) Depuis le release 01.01.2009 est définie la question MIG M0105 (Demande d’une modification administrative (mode d’encaissement)), mais la réponse n’y est pas définie de manière explicite. (iraient quand-même dans les deux sens ?)	.
(aanvraag) Wijziging klantgegevens (in detail) De oude « Community MIGs » bevatten een « Diversen – Vraag, Bijwerking van klantgegevens ». In release 01.01.2009 staat het verzoek MIG M0410 (Aanvraag wijziging klantgegevens), maar het antwoord is daar niet expliciet beschreven.	(demande de) Modification des renseignements client (en détail) Les anciens « Community MIGs » contiennent un « Divers – Demande, Modification des renseignements client ». Dans le release 01.01.2009 est définie la question MIG M0410 (Demande de modification des renseignements client), mais la réponse n’y est pas définie de manière explicite.	.
(ontvangst van een update na) Winstdeelname (in detail) Vanaf release 01.01.2024 wordt MIG M0115 (Winstdeelname – Contractgegevens) definitief vervangen door MIG M0121 (Contract update (leven of andere) - Opgave per 31.12 of per hoofdvervaldag of in het geval van een veralgemeende wijziging of na een contractueel event (incl. perequatie, winstdeelname) - Contractgegevens). Release 01.01.2009 bevat bericht MIG M0115 (Winstdeelname – Contractgegevens). De makelaar kan dit gebruiken om het contract te updaten.	(réception d’une mise à jour suite à une) Participation bénéficiaire (en détail) A partir du release 01.01.2024, le MIG M0115 (Participation bénéficiaire – Données contrat) est définitivement remplacé par le MIG M0121 (Mise à jour contrat (vie ou autre) - Relevé au 31.12 ou en date anniversaire ou lors d'une modification globale ou suite à événement contractuel (incl. péréquation, participation bénéficiaire) - Données contrat). Dans le release 01.01.2009 est défini le message MIG M0115 (Participation bénéficiaire – Données contrat). Le courtier peut l’utiliser comme mise à jour du contrat.	.
(ontvangst van een update na) Perequatie (in detail) Vanaf release 01.01.2024 wordt MIG M0116 (Perequatie – Contractgegevens) definitief vervangen door MIG M0121 (Contract update (leven of andere) - Opgave per 31.12 of per hoofdvervaldag of in het geval van een veralgemeende wijziging of na een contractueel event (incl. perequatie, winstdeelname) - Contractgegevens). Release 01.01.2009 bevat bericht MIG M0116 (Perequatie – Contractgegevens). De makelaar kan dit gebruiken om het contract te updaten.	(réception d’une mise à jour suite à une) Péréquation (en détail) A partir du release 01.01.2024, le MIG M0116 (Péréquation – Données contrat) est définitivement remplacé par le MIG M0121 (Mise à jour contrat (vie ou autre) - Relevé au 31.12 ou en date anniversaire ou lors d'une modification globale ou suite à événement contractuel (incl. péréquation, participation bénéficiaire) - Données contrat). Dans le release 01.01.2009 est défini le message MIG M0116 (Péréquation – Données contrat). Le courtier peut l’utiliser comme mise à jour du contrat.	.
(ontvangst) Overzicht per 31.12 of op de (jaar-)vervaldag (in detail) Release 01.01.2010 bevat bericht MIG M0121 (Overzicht per 31.12 of op de vervaldag - Contractgegevens). De makelaar kan dezegebruiken om het contract te updaten.	(réception d’une mise à jour) Relevé au 31.12 ou en date anniversaire (en détail) Dans le release 01.01.2010 est défini le message MIG M0121 (Relevé au 31.12 ou en date anniversaire – Données contrat). Le courtier peut l’utiliser comme mise à jour du contrat.	.
(ontvangst van een update na een) Vrije storting (in detail) In release 01.01.2010 staat het bericht MIG M0122 (Vrije storting – contractgegevens) beschreven. De makelaar kan dit gebruiken om het contract bij te werken.	(réception d’une mise à jour après) Versement libre (en détail) Dans le release 01.01.2010 est défini le message MIG M0122 (Versement libre – Données contrat). Le courtier peut l’utiliser comme mise à jour du contrat.	.
(verzending) Productiebericht (MPB), oorsprong makelaar (in detail) In release 01.01.2011 zit het bericht MIG M0123 (Productiebericht (MPB), oorsprong makelaar). De makelaar kan dit gebruiken voor een reeks degelijk omschreven acties, maar ook voor andere zaken.	(envoi d’un) Message Production (MPB), origine producteur (en détail) Dans le release 01.01.2011 est défini le message MIG M0123 (Message Production (MPB), origine producteur). Le courtier peut l’utiliser pour une série d’actions biens définies, mais aussi pour d’autres choses.	.
(ontvangst) Productiebericht (MPB), oorsprong verzekeraar (in detail) In release 01.01.2011 zit het bericht MIG M0124 (Productiebericht (MPB), oorsprong verzekeraar). De makelaar kan dit ontvangen voor een reeks degelijk omschreven acties, maar ook voor andere zaken.	(réception d’un) Message Production (MPB), origine assureur (en détail) Dans le release 01.01.2011 est défini le message MIG M0124 (Message Production (MPB), origine assureur). Le courtier peut le recevoir pour une série d’actions biens définies, mais aussi pour d’autres choses.	.
(verzending) Bericht van wijziging van tussenpersoon (beheersmandaat, via MPB), oorsprong makelaar, en de reactie van de verzekeraar naar de oude en naar de nieuwe makelaar (in detail) In mei 2013 beslist de WGN (Werkgroep Normalisatie) de M0108 te gebruiken om de van het beheer ontheven makelaar in te lichten over die ontheffing, geakteerd in het voordeel van een andere makelaar. Die andere makelaar zal in principe het nieuwe bijvoegsel aan het contract ontvangen.	(envoi d’un) Avis de changement d'intermédiaire (mandat de gestion, via MPB), origine producteur, et la réaction de l'assureur envers l'ancien et envers le nouveau courtier (en détail) En mai 2013, le GTN (Groupe de Travail de Normalisation) décide sur l'utilisation du M0108 pour mettre au courant le courtier dépossédé de la gestion actée en faveur d'un autre courtier. Cet autre courtier recevra en principe le nouveau avenant au contrat.	.
Sales development - up-selling en cross-selling Met een bericht M9120 kan men updates van klanten-gegevens binnen één of ander programme (sales, fidelity...) (CRM - Customer Relations Management) communiceren. Een up-sell identificeert zich op basis van het bestaande polis- of contract-nummer. Een cross-sell identificeert zich op basis van de naam en het adres van de klant, of op basis van het ondernemeingsnummer.. Een bericht M9120 is bedoeld voor een verwerking in batch en/of zo veel als mogelijk automatisch. De meer punctuele dingen worden gecommuniceerd via productie-berichten M0124 (up-sell) en M0126 (cross-sell). De makelaar kan puntueel reageren via productie-berichten M0123 (up-sell) en M0125 (cross-sell). Uiteindelijk resulteert dit (hopelijk) in een bijvoegsel (M0104MOD) of in een nieuwe zaak (M0103).	Actions commerciales - up-selling et cross-selling Un message M9120 peut servir à la mise à jour des données des clients en sein des programmes de fidélité ou similaires (CRM - Customer Relations Management). Un up-sell est identifié sur base du n° de police du contrat existant. Un cross-sell est identifié sur base des noms et adresse du client, ou du numéro d'entreprise. Ce 9120 est destiné au traitement en batch et/ou plus ou moins automatique. Les informations plus ponctuelles sont communiquées par les M0124 (en up-sell) et M0126 (en cross-sell). Le courtier sait réagir ponctuellement avec les M0123 (en up-sell) et M0125 (en cross-sell). Finalement le tout résultera (espérons le) en un avenant (M0104MOD) ou en une nouvelle affaire (M0103).	.
(ontvangst) Kwijting (in detail) De oude « Community MIGs » maken al onderscheid tussen de « kwijtingen van type 1 » (object/actie code 0305) en de « kwijtingen van type 2 » (object/actie code 0304). De « MIGs based upon sector recommendations » vermelden enkel nog de « kwijtingen van type 2 ». Release 01.01.2008 bevat de MIG M0304 (Vervaldagbericht (termijn) of zending Contante (PRENOT)).	(réception d’une) Quittance (en détail) Les anciens « Community MIGs » font déjà la distinction entre les « quittances de type 1 » (code objet/action 0305) et les « quittances de type 2 » (code objet/action 0304). Les « MIGs based upon sector recommendations » ne mentionnent déjà plus que les « quittances de type 2 ». Le release 01.01.2008 contient le MIG M0304 (Avis d’échéance (terme) ou envoi d’un Comptant (PRENOT)).	.
(ontvangst) Borderel (termijn of contante) (en détail) (De oude « Community MIGs » stellen dat voor de « Gemengde Commissie Productiviteit » de « CURRAC » (object/actie code 0702) de berichten met boekhoudkundige waarde zijn. Maar stellen ook dat het de « PRENOT » (object/actie code 0304) zijn die deze boekhoudkundige waarde krijgen, bovenop hun eerste finaliteit zijnde de « kwijting ». Die « Community MIGs » beschrijven ook een « Syntheserecord (kwijtingen en rekeninguittreksels) » (object/actie code 0603 en 0604), maar documenteren nergens het « Rekeninguittreksel » (object/actie code 0701). De « MIGs based upon sector recommendations » vermelden wel degelijk het « Termijnborderel » (object/actie code 0702) en het « Rekeninguittreksel » (object/actie code 0701), en vermelden geen nood aan een « Syntheserecord ». Release 01.01.2008 bevat de MIG M0304 (Vervaldagberichten (termijn) of zending Contante (PRENOT)) en het complement M0603 (De totalen van een verzameling berichten PRENOT – Vervaldagberichten (termijn)).	(réception d’un) Bordereau (terme ou comptant) (en détail) Les anciens « Community MIGs » dictent que les « CURRAC » (code objet/action 0702) sont pour la « Commission Mixte de Productivité » les messages à valeur comptable. Mais y est stipulé aussi que seront (? décision unilatérale?) utilisés les « PRENOT » (code objet/action 0304) à tel deuxième fin, en plus de leur première finalité de « quittance ». Ces « Community MIGs » décrivent aussi un « Enregistrement de synthèse (quittances et extraits de compte) » (code objet/action 0603 et 0604), mais ne documentent nulle part le « Extrait de compte » (code objet/action 0701). Les « MIGs based upon sector recommendations » mentionnent bien le « Bordereau terme » (code objet/action 0702) et le « Extrait de compte » (code objet/action 0701), et n’expriment aucun besoin d'un « Enregistrement de synthèse ». Le release 01.01.2008 contient le MIG M0304 (Avis d’échéance (terme) ou envoi d’un Comptant (PRENOT)) et son complément M0603 (Les totaux d’un ensemble de messages PRENOT – Avis d’échéance (terme)).	.
(ontvangst) Rekeninguittreksel (in detail) De « MIGs based upon sector recommendations » vermelden het « Rekeninguittreksel » (object/actie code 0701). Release 01.01.2008 bevat de MIG M0701 (Rekeninguittreksel).	(réception de) L’extrait de compte (en détail) Les « MIGs based upon sector recommendations » mentionnent le « Extrait de compte » (code objet/action 0701). Le release 01.01.2008 contient le MIG M0701 (L’extrait de compte).	.
(verzending) BRB (Retour Borderel / « Bordereau de Retour » in het frans) (in detail) De « MIGs based upon sector recommendations » vermelden de « BRB » (object/actie code 0302). Release 01.01.2008 bevat de MIG M0302 (BRB - Retour Borderel). De vraag is de BRB, en het antwoord is eerstens de beweging in het volgende rekeninguittreksel.	(envoi d’un) BRB (Bordereau de Retour / « Retour Borderel » en néerlandais) (en détail) Les « MIGs based upon sector recommendations » mentionnent le « BRB » (code objet/action 0302). Le release 01.01.2008 contient le MIG M0302 (BRB (Bordereau de Retour)). La question est le BRB, et la réponse est premièrement le mouvement dans le prochain extrait de compte.	.
(verzending) ATK (Aanvraag Teruggave van een Kwijting) (in detail) De « MIGs based upon sector recommendations » vermelden de « ATK » (object/actie code 0303). Release 01.01.2008 bevat de MIG M0303 (ATK - Aanvraag Teruggave Kwijting). De vraag is de ATK, en het antwoord is eerstens de ontvangst van de kwijting (a), en tweedens de ontvangst van het borderel (contant, van heruitgifte) (b) dat dan nog zal bevestigd worden door de beweging in het volgende rekeninguittreksel. In de praktijk vormen (a) en (b) één geheel in de vorm van (a).	(envoi d’une) DRQ (Demande en Retour d’une Quittance) (en détail) Les « MIGs based upon sector recommendations » mentionnent la « DRQ » (code objet/action 0303). Le release 01.01.2008 contient le MIG M0303 (DRQ (Demande en Retour d’une Quittance)). La question est la DRQ, et la réponse est premièrement la réception de la Quittance (a), et deuxièmement la réception du Bordereau (comptant, de ré émission) (b) lequel sera confirmé par le mouvement dans le prochain extrait de compte. En pratique, (a) et (b) font un seul sous forme de (a).	.
(ontvangst) Annulatie van een kwijting in inning maatschappij (in detail) (en dus van het credit van de commissie in afwachting bij de makelaar) Release 01.01.2008 bevat de MIG M0307 (Annulatie van een kwijting in inning maatschappij).	(réception d’une) Annulation d’une quittance en encaissement compagnie (en détail) (et donc du crédit commission en attente chez le courtier) Le release 01.01.2008 contient le MIG M0307 (Annulation d’une quittance en encaissement compagnie).	.
(aanvraag) Lijst onbetaalde kwijtingen (in detail) Sinds release 01.01.2008 bestaat de combinatie vraag/antwoord van de MIG M0403 (Vraag, lijst (onbetaalde) kwijtingen) en de M0306 (Kwijting(-lijst), bericht van betalingsachterstand).	(demande d’une) Liste des (quittances) impayées (en détail) Depuis le release 01.01.2008 est défini l’ensemble question/réponse des MIG M0403 (Demande liste (quittances) impayées) et M0306 (Liste (quittances) impayées).	.
Organisatie en samenhang van de "boekhoudkundige" uitwisselingen, verduidelijkt met een voorbeeld 01/07 : voor de vervaldag stuurt de verzekeraar de verzekeringnemer een voor 15/07 te betalen vervaldagbericht in inning verzekeraar, en informeert hierover de makelaar via een bericht M0304, tesamen met andere M0304, en dat geheel getotaliseerd in een bericht M0603 15/07 : de vervaldag 31/07 : 15 dagen na de vervaldag stuurt de verzekeraar de verzekeringnemer een herinnering van dat vervaldagbericht, en informeert hierover de makelaar via een bericht M0306 met ATT+B051 = 1 "eerste herinnering" 15/08 : 15 dagen na de herinnering stuurt de verzekeraar de verzekeringnemer een ingebrekestelling, en informeert hierover de makelaar via een bericht M0306 met ATT+B051 = 7 "verzending van de ingebrekestelling" 01/09 : bij niet-betaling, zending bericht M0104SUS "schorsing contract / schorsing waarborgen wegens niet-betaling" (02/09 : bij betaling, zending bericht M0104REM "wederinvoegestelling") 15/09 : 15 dagen later, en zonder betaling, stuurt de verzekeraar de verzekeringnemer een dreigbrief-advocaat, en informeert hierover de makelaar via een bericht M0306 met ATT+B051 = L "advocaat" 30/09 : 15 dagen later, en zonder betaling, stuurt de verzekeraar de verzekeringnemer een ingebrekestelling met opzeg, en informeert hierover de makelaar via een bericht M0306 met ATT+B051 = F "opzegbrief" 15/10 : aan de makelaar, bericht M0104RES "opzeg" met ATT+A705 "reden opzeg" = D "niet-betaling premie" 15/10 : aan de makelaar, bericht M0307 "annulatie kwijting inning maatschappij" Dit voorbeeld vertrekt van een premie op vervaldag en in inning maatschappij. Voor een premie in inning makelaar komt hier nog een eerste etappe bij; de terugzending van de kwijting naar de maatschappij voor inning door de maatschappij, en dit binnen de tussen de verzekeraar en de makelaar overeengekomen terugzendtermijn (bericht M0302 "retour-borderel"). Dit voorbeeld is slechts illustratief; elke verzekeraar kan zijn "incasso-geschillen-beheer" opzetten naar eigen goeddunken.	Orchestration des messages dites "comptables", expliquée moyennant un exemple 01/07 : avant l'échéance, la compagnie envoie au preneur un avis d'échéance à payer pour le 15/07 en encaissement compagnie, et en informe le courtier par message M0304, lui regroupé avec d'autres M0304 et cet ensemble totalisé dans un message M0603 15/07 : échéance 31/07 : 15 jours après l"échéance, la compagnie envoie un rappel de l'échéance au preneur, et en informe le courtier par M0306 avec ATT+B051 = 1 "premier rappel" 15/08 : 15 jours après le rappel, la compagnie envoie la lettre de mise en demeure au preneur, et en informe le courtier par M0306 avec ATT+B051 = 7 "envoi de la mise en demeure" 01/09 : si non paiement, envoi du message M0104SUS "suspension contrat / suspension garanties pour non paiement" (02/09 : si paiement, envoi du message M0104REM "remise en vigueur") 15/09 : 15 jours après, si non paiement, la compagnie envoie la lettre comminatoire avocat au preneur, et en informe le courtier par M0306 avec ATT+B051 = L "avocat" 30/09 : 15 jours après, si non paiement, la compagnie envoie la lettre de mise en demeure de résiliation au preneur, et en informe le courtier par M0306 avec ATT+B051 = F "lettre de résiliation" 15/10 : envoi au courtier du message M0104RES "résiliation" avec ATT+A705 "motif de résiliation" = D "non paiement prime" 15/10 : envoi au courtier du message M0307 "annulation de quittance en encaissement compagnie" Cet exemple démarre d'une prime à échéance et en encaissement compagnie. Dans le cas d'une prime en encaissement courtier s'y ajoute comme première étappe le renvoi de la quittance à la compagnie pour encaissement par la compagnie en dedans le délai de retour des quittances convenu entre l'assureur et le courtier (message M0302 "bordereau de retour"). Cet exemple n'est qu'illustratif; tout assureur à la liberté d'organiser son "contentieux" comme lui le désire.	.
Het schadebeheer en het aanspreken van services aangeboden door een verzekeraar (in detail) De « Projectgroep Uitwisselingen Schade » hield in release 01.01.2009 een gescheiden schadebeheer in gedachten, enerzijds binnen de administratie van de makelaar, en anderzijds binnen de administratie van de verzekeraar. Vandaar de term "uitwisselingen schade" en niet "schadebeheer". Er is dus sprake van uitwisselingen zoals beschreven in Figuur 6 - BBP via uitgewisselde berichten.	La gestion des sinistres et la notion de l’invocation d’un service mis à disposition par une compagnie (en détail) Le « Groupe de Projet Echanges Sinistres » a, pour le release 01.01.2009, pensé en direction d’une gestion séparée, en sein de l’administration du courtier d’un coté, et en sein de l’administration de l’assureur de l’autre coté. De là l’expression « échanges sinistres » et non « gestion sinistres ». Il y a donc question d’échanges comme décrits dans le « Figure 6 – BBP par échange de messages ».	.
(verzending) Administratieve opening van een schadedossier (in detail) Release 01.01.2009 beschrijft de combinatie vraag/antwoord van de MIG M0202 (Administratieve opening) en M0205 (Ontvangstmelding). Dat geheel van vraag en antwoord is te gebruiken wanneer de klant de aangifte komt doen bij de makelaar. De administratieve opening gebeurt liefst onmiddellijk, zelfs indien daardoor slechts met minimale inhoud. De ontvangstmelding komt liefst onmiddellijk, zelfs indien daardoor nog maar met minimale inhoud. De administratieve opening kan opnieuw verzonden worden van zodra ze vollediger is, maar dan niet zonder de schadereferte ontvangen bij de (onmiddellijke) ontvangstmelding, en dus niet voor de ontvangst van die eerste ontvangstmelding. (LET OP: de MIG M0202 voorziet die referte nog niet - toe te voegen!) De ontvangsmelding kan opnieuw verzonden worden van zodra ze vollediger is, de integratie-filter moet dan zijn rol spelen.	(envoi d’une) Ouverture administrative d’un dossier sinistre (en détail) Le release 01.01.2009 définit l’ensemble question/réponse des MIG M0202 (Ouverture administrative) et M0205 (Accusé de réception). Cet ensemble question/réponse est à utiliser quand le client vient déclarer le sinistre chez l’intermédiaire. L’ouverture administrative est de préférence immédiate, quitte à être minimaliste en contenu. L’accusé de réception est de préférence immédiat, quitte à être minimaliste en contenu. L’ouverture administrative peut être ré-envoyé dés que plus complet, mais pas en absence de la référence sinistre reçue avec l’accusé de réception (immédiat), et donc pas avant réception de ce premier accusé de réception. (ATTN : le MIG M0202 ne prévoit cette référence – à ajouter !) L’accusé de réception peut être ré-envoyé dés que plus complet, le filtre d’intégration doit alors jouer son rôle.	.
(ontvangst) Ontvangstmelding van een (aanvaarde) aangifte en van de opening van het schadedossier (in detail) Release 01.01.2009 beschrijft een tweede geval voor de M0205 (Ontvangstmelding). Het bericht is ook te gebruiken wanneer de klant de aangifte van zijn schade komt doen bij de verzekeraar of bij zijn aangestelde (denk hier aan Carglass of zo ...). De ontvangstmelding komt liefst onmiddellijk, zelfs indien daardoor nog maar met minimale inhoud. De ontvangsmelding kan opnieuw verzonden worden van zodra ze vollediger is, de integratie-filter moet dan zijn rol spelen.	(réception d’un) Accusé de réception d’une déclaration (acceptée) et de l’ouverture du dossier sinistre (en détail) Le release 01.01.2009 définit un deuxième cas de figure pour le M0205 (Accusé de réception). Ce message est aussi à utiliser quand le client vient déclarer le sinistre chez l’assureur ou son préposé (pensez à un Carglass ou autre ...). L’accusé de réception est de préférence immédiat, quitte à être minimaliste en contenu. L’accusé de réception peut être ré-envoyé dés que plus complet, le filtre d’intégration doit alors jouer son rôle.	.
(verzending) Aanduiding expert door de makelaar (in detail) Release 01.01.2009 beschrijft de combinatie vraag/antwoord van MIG M0210 (Aanduiding expert) en M0211 (Expertiseverslag (oorsprong verzekeraar)). Die combinatie van vraag en antwoord is te gebruiken wanneer de makelaar de expert aanstelt. Het is duidelijk dat er hier een zekere tijdspanne ligt tussen de gestelde vraag en het gegeven antwoord. Toch zien we dit, in de zin van de BBP, als een geheel van vraag/antwoord. Il faut aussi remarquer que le P.V. d’expertise part de l’expert à l’assureur, et que c’est l’assureur qui envoie (les informations de) ce P.V. au courtier. .	(envoi d’une) Désignation expert effectuée par le courtier (en détail) Le release 01.01.2009 définit l’ensemble question/réponse des MIG M0210 (Désignation expert) et M0211 (P.V. d’expertise (origine compagnie)). Cet ensemble question/réponse est à utiliser quand le courtier désigne l’expert. Il est clair qu’ici, il y aura un délai certain entre la « question posée » et la « réponse donnée ». Néanmoins, en tant que BBP, c’est bien un ensemble question/réponse. Il faut aussi remarquer que le P.V. d’expertise part de l’expert à l’assureur, et que c’est l’assureur qui envoie (les informations de) ce P.V. au courtier.	.
(ontvangst) Aanduiding expert door de verzekeraar (in detail) In release 01.01.2009 voorziet men een tweede geval voor de MIG M0210 (Aanduiding expert). In dergelijk geval wijzigt de combinatie vraag/antwoord in de opeenvolgende berichten A/B, de A is dan de aanstelling, en de B is dan het verslag (MIG M0211).	(réception d’une) Désignation expert effectuée par l’assureur (en détail) Le release 01.01.2009 définit un deuxième cas de figure pour le MIG M0210 (Désignation expert). Dans ce cas, l’ensemble question/réponse devient l’ensemble avis_A/avis_B, le A étant la désignation, et le B étant le P.V. (MIG M0211).	.
(verzending) Bericht van regeling door de makelaar (in detail) In release 01.01.2009 voorziet men het geval waar de makelaar (met delegatie) de schaderegeling uitvoert en daar dan de verzekeraar van op de hoogte brengt. Idealiter is er één enkel regelingsbericht dat de totaliteit van de schade omvat, maar in de praktijk kan dat ideaal niet gehaald worden. De release voorziet de verzending van meerdere "Berichten van schaderegeling". In de MIG M0204 (Bericht van regeling) gaat het bovenste deel van het bericht over het schadedossier in zijn geheel, en het is enkel het deel "uitkering vergoeding" (de segment-tag "PAT+...") dat gaat over (gedeeltelijke) regeling op zich.	(envoi d’un) Avis de règlement effectué par le courtier (en détail) Le release 01.01.2009 prévoit le cas où le courtier (délégataire) effectue le règlement du sinistre, et en informe l’assureur. Idéalement, il y a un seul « Avis de règlement » couvrant la totalité du sinistre, mais en pratique cet idéal ne peut pas être atteint. Le release a voulu prévoir l’envoi de multiples « Avis de règlement ». Dans le MIG M0204 (Avis de règlement), il faut considérer que toute la partie supérieure du message traite du « dossier sinistre » dans sa totalité, et que seulement la partie « Indemnité » (le segment-tag « PAT+... » traite du règlement (partiel) en soi.	.
(ontvangst) Bericht van regeling door de verzekeraar (in detail) In release 01.01.2009 voorziet men het geval waar de verzekeraar de schaderegeling uitvoert en daar dan de makelaar van op de hoogte brengt. Idealiter is er één enkel regelingsbericht dat de totaliteit van de schade omvat, maar in de praktijk kan dat ideaal niet gehaald worden. De release voorziet de verzending van meerdere "Berichten van schaderegeling". In de MIG M0204 (Bericht van regeling) gaat het bovenste deel van het bericht over het schadedossier in zijn geheel, en het is enkel het deel "uitkering vergoeding" (de segment-tag "PAT+...") dat gaat over (gedeeltelijke) regeling op zich. Voor de integratie van een "Bericht van regeling" vergelijkt men dus dat bovenste deel van het bericht met het al aanwezige dossier en vult men dit eventueel aan. En het deel "uitkering vergoeding" zal men in principe toevoegen aan het dossier, bijkomend aan de andere "vergoedingen" die er eventueel al aanwezig zijn.	(réception d’un) Avis de règlement effectué par l’assureur (en détail) Le release 01.01.2009 prévoit le cas où l’assureur effectue le règlement du sinistre, et en informe le courtier. Idéalement, il y a un seul « Avis de règlement » couvrant la totalité du sinistre, mais en pratique cet idéal ne peut pas être atteint. Le release a voulu prévoir l’envoi de multiples « Avis de règlement ». Dans le MIG M0204 (Avis de règlement), il faut considérer que toute la partie supérieure du message traite du « dossier sinistre » dans sa totalité, et que seulement la partie « Indemnité » (le segment-tag « PAT+... ») traite du règlement (partiel) en soi. Lors de l’intégration d’un Avis de règlement, cette partie supérieure du message va donc être comparée avec le dossier déjà présent et va éventuellement la compléter. Et la partie « Indemnité » va en principe être ajouté au dossier, en plus des autres « Indemnité » éventuellement déjà présentes.	.
(verzending) Afsluiting dossier door de makelaar (in detail) In release 01.01.2009 voorziet men het geval waar de makelaar (met delegatie) de afsluiting van het dossier uitvoert en daar dan de verzekeraar van op de hoogte brengt. (MIG M0206)	(envoi d’une) Clôture du dossier effectuée par le courtier (en détail) Le release 01.01.2009 prévoit le cas où le courtier (délégataire) effectue la clôture du dossier sinistre, et en informe l’assureur. (MIG M0206)	.
(ontvangst) Afsluiting dossier door de verzekeraar (in detail) In release 01.01.2009 voorziet men het geval waar de verzekeraar de afsluiting van het dossier uitvoert en daar dan de makelaar van op de hoogte brengt. (MIG M0206)	(réception d’une) Clôture du dossier effectuée par l’assureur (en détail) Le release 01.01.2009 prévoit le cas où l’assureur effectue la clôture du dossier sinistre, et en informe le courtier. (MIG M0206)	.
(verzending) Schadebericht (MSB), oorsprong producent (in detail) In release 01.01.2009 beschrijft men bericht MIG M0203 (MSB oorsprong producent). De makelaar kan dit bericht verzenden voor een aantal duidelijk beschreven acties, maar ook voor andere zaken.	(envoi d’un) Message Sinistres (MSB), origine producteur (en détail) Dans le release 01.01.2009 est défini le message MIG M0203 (MSB origine producteur). Le courtier peut l’utiliser pour une série d’actions biens définies, mais aussi pour d’autres choses.	.
(ontvangst) Schadebericht (MSB), oorsprong verzekeraar (in detail) In release 01.01.2009 beschrijft men bericht MIG M0207 (MSB oorsprong verzekeraar (bestemming producent)). De makelaar kan dit bericht ontvangen voor een aantal duidelijk beschreven acties, maar ook nog voor andere zaken.	(réception d’un) Message Sinistres (MSB), origine assureur (en détail) Dans le release 01.01.2009 est défini le message MIG M0207 (MSB origine compagnie (destination producteur)). Le courtier peut le recevoir pour une série d’actions biens définies, mais aussi pour d’autres choses.	.
(aanvraag van) Opvolging beheersdaden (in detail) In release 01.01.2009 beschrijft men de combinatie vraag/antwoord MIG M0203 (MSB oorsprong producent) met de CMSA-code 27 en MIG M0214 (Schadegeval, opvolging beheersdaden). De release sluit niet uit dat die aanvraag meermaals voor komt. Bij de integratie van het antwoord moet de integratie-filter zijn rol spelen.	(demande d’un) Suivi des actes de gestion (en détail) Dans le release 01.01.2009 est défini l’ensemble question/réponse des MIG M0203 (MSB origine producteur) contenant le CMSA-code 27 et MIG M0214 (Sinistre, suivi des actes de gestion). Le release n’exclue pas que telle demande soit effectuée multiples fois. Lors de l’intégration de la réponse, le filtre d’intégration devra jouer son rôle.	.
(aanvraag van) Volledig dossieroverzicht schade (in detail) In release 01.01.2009 beschrijft men de combinatie vraag/antwoord MIG M0203 (MSB oorsprong producent) met de CMSA-code 28 (de vraag), en de MIG M0205 (bevestiging ontvangst), M0204 (regelingsbericht) en M0206 (afsluiting) (het antwoord). Deze business transactie zien we als eerder uitzonderlijk. De (her-)integratie van de berichten in een schadedossier dat wel al bestaat (wat niet het doel is van deze transactie) mag geen probleem zijn, tenzij dat het regelingsbericht al aanwezige regelingen zou kunnen verdubbelen. De integratie-filter zou dit kunnen opvangen.	(demande d’une) Vue complète du dossier sinistre (en détail) Dans le release 01.01.2009 est défini l’ensemble question/réponse des MIG M0203 (MSB origine producteur) contenant le CMSA-code 28 (la question), et les MIG M0205 (accusé de réception), M0204 (avis de règlement) et M0206 (clôture) (en réponse). Cette opération business est considérée de caractère exceptionnel. La réintégration des messages dans un dossier quand-même déjà existant (ce qui n’est pas le bût de l’opération) ne posera pas de problème, sauf que l’avis de règlement risque de doubler les « indemnités ». Le filtre d’intégration pourrait prévoir l’éventualité.	.
Om deze processen op te starten kan de makelaar vertrekken van : uit zijn beheerspakket uit het services publicatie-systeem uit/met een link naar de module van de verzekeraar	Pour entamer ces « Processes », le courtier peut travailler à partir de : de son package du système de publication des services d’un pointeur vers le module de l’assureur	.
Aanbevelingen Maak eerst de verzekeringnemer aan in het beheerspakket, vooraleer de aanmaak van een transactie in een maatschappijmodule op te starten. Adreswijzigingen worden uitgevoerd in het beheerspakket en worden vervolgens van daaruit aan de verzekeraars medegedeeld. De verzekeraars sturen onmiddellijk een antwoordrecord, ook voor de zaken die "in onderzoek" geplaatst worden.	Recommandations Nous recommandons de créer le preneur dans le package avant de réaliser une transaction dans un module compagnie. Les changements d’adresses sont effectués dans le package et ensuite communiqués aux compagnies. Les compagnies envoient un bloc retour immédiat également pour les affaires mises à l’examen.	.
Wat dit betekent op het vlak van ontwikkeling en implementatie Het wijzigen van waardenlijsten niet zomaar toelaten De tabel van de waarborgen eveneens afsluiten Aanspreken van services Plaats nemen op de juiste pagina/venster Consultatie/bijvoegsel : het polis- of schadenummer doorgeven Nieuwe zaak : de "referte verzekeringnemer" doorgeven Contextuele uitwisseling de MIG (Message Implementation Guide) publiceren, ook voor deze contextuele uitwisselingen Consultatie/bijvoegsel : het polis- of schadenummer doorgeven Nieuwe zaak : de "referte verzekeringnemer" doorgeven Antwoordrecord (AR) de MIG (nieuwe versies) publiceren de verplichte inhoud aanduiden definities toevoegen de MIG aanvullen (voor de andere takken/domeinen) administratieve contract-gegevens en de Waarborgen. de officiële versie van de verzekeraar is de meest juiste de gegevens van het AR worden overgenomen in een nieuwe contract-versie geen integratie-filter gegevens van de verzekeringnemer de gegevens van de makelaar zijn de meest juiste de verschillen weergeven de gegevens van de makelaar hebben default voorkeur gegevens van het risico-object de gegevens van de maatschappij zijn de meest juiste de verschillen weergeven de gegevens van de maatschappij hebben default voorkeur Integratie en gebruik van het bestand "merken/modellen" Integratie en gebruik van het bestand "adressen"	Conséquences pour les développements et l’implémentation Fermer les tables de codes Fermer la table des garanties Invocation Positionner sur la bonne page Consultation/avenant : passer n° police ou sinistre Nouvelle affaire : passer « référence preneur » Echange Contextuel : Publier les MIG (Message implementation Guide), aussi pour les Echanges contextuels Consultation/avenant : passer n° police ou sinistre Nouvelle affaire : passer « référence preneur » Bloc retour (BR) Publier nouvelle version des MIG Indiquer zones obligatoires Ajout définitions Enrichir MIG (autres branches) Données administratives du contrat et Garanties La version officielle de la compagnie est la plus correcte Les données du BR sont créées dans la nouvelle version contrat Pas de filtre d’intégration Données du preneur Les données du courtier sont les plus complètes Présentation des différences Données courtier prioritaires par défaut Données objet de risque Les données de la compagnie sont les plus complètes Présentation des différences Données compagnie prioritaires par défaut Intégration du fichier marques modèles Intégration du fichier « DEDALE »	.
.	.	.