> Syntax independent - M & P > BBP > Listed > 16

SYNTAX INDEPENDENT COMPONENTS

Implementation Related Components


Back to overview Previous BBP - 16 - Bericht kwijting / Message Quittance / Discharge note message Next
16. (ontvangst van een) Kwijting
De definitie van « kwijting » :
Bewijs van betaling, geschreven, ondertekend door de ontvanger van de gelden, overhandigd aan de betaler.

De BBP « Bijvoegsel » en « Nieuwe zaak » beschrijven het principe van de integratie van het « antwoordrecord ». Er wordt gesteld dat er voor de gegevens van de (contante) kwijting geen proces van automatische integratie van de premies van die kwijting voorzien is, maar dat deze getoond worden en dat de makelaar deze moet valideren vooraleer zijn databank bij te werken.
16. (réception d’une) Quittance
La définition de « quittance » :
Preuve de paiement, écrite, signée par le receveur des fonds, au payeur.

Au niveau des BBP « Avenant » et « Nouvelle affaire » est mentionné le principe de l’intégration du « bloc retour ». Y est mentionné pour l’intégration des données de la quittance (au comptant), qu’il n’y a pas de processus d’intégration automatique des primes de telle quittance, mais que celles-ci sont affichées et que le courtier doit les valider avant mise à jour.
.
  • 16.0. De verzekeraar geeft die PRENOT (M0304) uit:
    • voor elk bericht van contante, te betalen of terug te betalen, inning verzekeraar of inning makelaar
      (en dan samen met het polis-bericht, en zo is dat een "antwoord-record") ;
    • voor elk bericht van termijn, inning verzekeraar of inning makelaar
      (samen met de andere termijnen van de maand) ;
    • voor elk bericht van afrekening
      in de praktijk een "contante" (het is geen "termijn"):
      - zonder dat dit een geheel vormt met het polis-bericht (welke niet veranderde) (en dan als een M0308)
      - samen met het polis-bericht (als deze wijzigde)
    - naar alle betrokken makelaars, dus ook de ex-gemandateerde makelaar (mocht die nog recht op commissie hebben).
  • 16.0. L'assureur émet ce PRENOT (M0304):
    • pour chaque avis de comptant, payable ou remboursable, encaissement assureur ou courtier
      (et alors en ensemble avec le message sur le contrat, et ainsi formant un « bloc retour »);
    • pour chaque avis terme, encaissement assureur ou courtier
      (en ensemble avec les termes du mois);
    • pour chaque avis de décompte
      en pratique un « comptant » (ce n’est pas un « terme »):
      - sans que c’est un ensemble avec le message contrat (lequel n’a pas changé) (et alors comme un M0308)
      - ensemble avec le message contrat (lequel a changé)
    - envers tout courtier impliqué, y compris le courtier ex-mandaté (ayant encore droit à des commissions).
.
  • 16.0.b. Die PRENOT bevat één en/of andere periode (PER+...):
    • een contante, resulterende van een nieuwe zaak:
        een PER+003 "verzekerde periode" ;
    • een contante, resulterende van een bijvoegsel:
        een PER+001 "prorata -"
        en een PER+002 "prorata +" ;
    • een termijn:
        een PER+003 "verzekerde periode" ;
    • een contante in voorschot, resulterende van een nieuwe zaak op afrekening:
        een PER+005 "voorschot op afrekening" ;
    • een contante in voorschot, resulterende van een bijvoegsel op afrekening:
        een PER+001 "prorata -"
        en een PER+002 "prorata +" ;
    • een termijn in voorschot:
        een PER+005 "voorschot op afrekening" ;
    • een contante, resulterende van een afrekening:
        een PER+003 "verzekerde periode"
        en één of meerdere PER+006 "voorschot verrekend" waarbij die PER+006 het totaal van, of de individuele verrekende voorschotten voorstellen.
    - De sommatie (PER+002 "prorata +" minus PER+001 "prorata -") is negatief: de kwijting is van het type ATT+B001 3 "teruggavekwijting".
    - De sommatie (PER+002 "prorata +" minus PER+001 "prorata -") is positief: de kwijting is van het type ATT+B001 2 "contant".
    En zo ook voor een afrekening:
    - De sommatie (PER+003 "verzekerde periode" minus PER+006 "voorschot verrekend") is negatief: de kwijting is van het type ATT+B001 8 "afrekening terug te betalen".
    - De sommatie (PER+003 "verzekerde periode" minus PER+006 "voorschot verrekend") is positief: de kwijting is van het type ATT+B001 7 "afrekening te betalen".
  • 16.0.b. Tel PRENOT renseigne sur l'une et/ou l'autre période (PER+...):
    • un comptant résultant d'une nouvelle affaire:
        une PER+003 "période assurée" ;
    • un comptant résultant d'un avenant:
        une PER+001 "prorata -"
        et une PER+002 "prorata +" ;
    • un terme:
        une PER+003 "période assurée" ;
    • un comptant en avance résultant d'une nouvelle affaire sur décompte:
        une PER+005 "avance sur décompte" ;
    • un comptant en avance résultant d'un avenant sur une affaire sur décompte:
        une PER+001 "prorata -"
        et une PER+002 "prorata +" ;
    • un terme en avance:
        une PER+005 "avance sur décompte" ;
    • un comptant résultant d'un décompte:
        une PER+003 "période assurée"
        et une ou plusieures PER+006 "avance escomptée" représentant la totalisation des, ou les avances individuellement escomptées.
    - La totalisation (PER+002 "prorata +" moins PER+001 "prorata -") est négative: la quittance est de type ATT+B001 3 "remboursement".
    - La totalisation (PER+002 "prorata +" moins PER+001 "prorata -") est positive: la quittance est de type ATT+B001 2 "comptant".
    Et de même pour un décompte:
    - La totalisation (PER+003 "période assurée" moins PER+006 "avance escomptée") est négative: la quittance est de type ATT+B001 8 "décompte à rembourser".
    - La totalisation (PER+003 "période assurée" moins PER+006 "avance escomptée") est positive: la quittance est de type ATT+B001 7 "décompte à payer".
.
  • 16.1. De definitie van « antwoordrecord » :
    Een antwoordrecord bestaat in deze uit een uitwisselingseenheid CNTRCT en een uitwisselingseenheid PRENOT.
    De twee uitwisselingseenheden moeten samen in een groep geplaatst worden, die dan begrensd is ddor de segmenten XGH en XGT.
    In het XGH segment moet gegevenselement X925 (Group type) de waarde "001" -Antwoordrecord- bevatten.
    Qua premies bevat het onderdeel CNTRCT de jaarpremies eisbaar op de hoofdvervaldag, en bevat het onderdeel PRENOT de contante premies.
    Minstens 1 risico-object met minstens 1 waarborg is verplicht aanwezig.
  • 16.1. La définition du « bloc retour » :
    Un bloc retour consiste en une unité d'échange CNTRCT et une unité d'échange PRENOT.
    Les deux unités d'échange doivent être mises ensemble dans un groupe délimité par les segments XGH et XGT.
    Dans le segment XGH, l'élément de donnée X925 Group type doit contenir la valeur "001" -Bloc retour-.
    Au niveau des primes la partie CNTRCT contient les primes annuelles dues à l'échéance principale, la partie PRENOT contient les primes au comptant.
    La présence d'au moins 1 objet de risque avec au moins 1 garantie est obligatoire.
     
.
  • 16.2. Kwijting in inning door de verzekeraar.
    De PRENOT van het antwoordrecord geeft de inhoud van de kwijting weer.

    De kwijting zelf blijft in het bezit van de verzekeraar totdat deze de betaling ontvangt, en wordt pas op dat ogenblik aan de verzekeringnemer overhandigd.
    De verzekeraar nodigt de verzekeringnemer uit het verschuldigde bedrag te betalen, en stuurt hem daarvoor een "bericht van contante" (of een "termijn-vervaldagbericht" in dat andere geval).
    Om het zijn klant gemakkelijk te maken integreert de verzekeraar in dat "bericht van contante" een overschrijvingsformulier dat al ingevuld is met het te betalen bedrag, de gegevens van de bestemmeling van de betaling, en de referte van de betaling.

    Het principe is dus :
    • de verzekeraar identificeert het te betalen bedrag,
    • de verzekeraar bericht zijn verzekeringnemer en vraagt hem te betalen, (het (vervaldag-)bericht)de verzekeringnemer betaalt het verschuldigde bedrag (het overschrijvingsformulier)
    • de verzekeraar geeft de verzekeringnemer een bewijs van betaling (de kwijting).

    De GCP (Gemengde Commissie Productiviteit) heeft een drieluik (model A) ontworpen dat de drie elementen (kwijting, bericht en overschrijvingsformulier) groepeert op één enkel gedrukt en geperforeerd blad papier.
    • Binnen de verzekeraar maakt een dienst "productie" dat document aan, en geeft dat dan door aan een dienst "inningen".
    • Die dienst "inningen" scheurt dat document in twee, bewaart het deel "kwijting", en stuurt het deel "bericht plus overschrijvingsformulier" naar de verzekeringnemer.
    • De verzekeringnemer scheurt het ontvangen document in twee, en gaat met het deel "overschrijvingsformulier" naar zijn bank om de betaling te doen, en bewaart het deel "bericht" in afwachting van de ontvangst van de "kwijting".
    • Binnen de verzekeraar ontvangt de dienst "inningen" de betaling op zijn bankrekening en bevestigt dit aan de verzekeringnemer door hem de "kwijting" op te sturen.

    In de praktijk, omwille van de kosten, zijn de verzekeraars al vroeg clausules op de berichten gaan vermelden in de stijl van "...Dit bericht vergezeld van het overschrijvingsbewijs vormt het betalingsbewijs, onder voorbehoud van vroegere vervallen en nog onbetaalde premies of intresten. ...".
    Zo vermijden verzekeraars de kwijting te moeten verzenden, apart van de verzending van het (vervaldag-)bericht. Het is bijna alsof het (vervaldag-)bericht tegelijkertijd de kwijting is...

    Al in 1985 heeft men dit gedrag sectoraal erkend en heeft de GCP een model B van zijn "drieluik" ontworpen.

    De « Witte Map » (versie 2.2, juni 1999) bepaalt in de « Aanbeveling 09 » ook nog de modellen C en D van dat « drieluik »; dat zijn aanpassingen aan technische kenmerken van de printers die toen in gebruik waren.
    Er wordt daar ook nog gesteld dat het "drieluik" of "vervaldagbericht - betalingsaanvraag" geen boekhoudkundig document is, maar dat de boekingen gebeuren op basis van het "borderel" zoals beschreven in de « Aanbeveling 05 ».

    Zoomit :
    in 2009 startte het systeem « e-invoicing ».
    Het vervaldagbericht wordt geleverd aan een technisch platform en via die weg rechtstreeks aan de klant aangeboden in zijn "homebanking" systeem.
    De klant kan gemakkelijk voor een "opt-in" kiezen en zo kiezen voortaan gebruik van dit "facturatie" systeem te maken.
    De betaling zelf gebeurt dan via de gewone handelingen zoals gebruikelijk binnen de "homebanking" toepassing in kwestie.
  • 16.2. Quittance, en encaissement par l’assureur.
    Le PRENOT du bloc retour reflète le contenu de la quittance.

    La quittance en soi reste en mains de l’assureur jusqu’à la réception du paiement par cet assureur, et n’est qu’à ce moment donnée en mains du preneur d’assurance.
    L’assureur invite le preneur à payer le montant dû en l’envoyant un « avis de comptant » (ou « avis d’échéance terme » dans tel autre cas).
    Afin de rendre la vie facile à son client, l’assureur intègre dans cet « avis de comptant » un bulletin de virement, pré rempli avec le montant payable, les données du destinataire du paiement, et la référence du paiement.

    Le principe est donc que :
    • l’assureur identifie le montant à payer,
    • l’assureur avise et invite son preneur d’assurance à payer, (l’avis)
    • le preneur paie le montant dû, (le bulletin)
    • l’assureur donne une preuve de paiement au preneur d’assurance (la quittance).

    La CMP (Commission Mixte de Productivité) avait imaginé un document « triptyque » (modèle A) regroupant les trois éléments (quittance, avis et bulletin) sur une seule feuille de papier imprimée et perforée.
    • Chez l’assureur, un service « production » produit ce document, et le transmet à un service « encaissement ».
    • Ce service « encaissement » déchire ce document en deux, garde la partie « quittance » chez elle, et envoie la partie « avis plus bulletin » au preneur d’assurance.
    • Ce preneur d’assurance déchire ce document reçu en deux, et va avec la partie « bulletin » à sa banque pour effectuer le paiement, et garde la partie « avis » en attente de la réception de la quittance.
    • Le service « encaissement » de l’assureur réceptionne le montant sur son compte en banque, et le confirme au preneur en lui envoyant la « quittance ».

    En pratique, pour des raisons de coûts, les assureurs ont commencés assez vite à utiliser sur les avis des termes de style « ... Cet avis, accompagné du document justifiant le transfert de fonds constitue la preuve du paiement sans préjudice des primes ou intérêts antérieurs qui resteraient dus. ... ».
    Ainsi ils évitent de devoir encore envoyer la quittance, séparément de l’envoi de l’avis. C’est presque comme si l’avis devienne en même temps quittance...

    Déjà en 1985, ce comportement a été reconnu au niveau sectoriel, et la CMP avait défini un modèle B de son « triptyque ».

    Le « Recueil Blanc » (version 2.2, juin 1999) définit dans la « Recommandation 09 » en plus les modèles C et D de ce « triptyque », s’adaptant aux caractéristiques techniques des imprimantes utilisées.
    Y est stipulé en plus que ce document « triptyque » ou « avis d’échéance – demande de paiement » n’est pas un document comptable, mais que les comptabilisations se font sur base du « bordereau », comme décrites dans une « Recommandation 05 ».

    Zoomit :
    en 2009 est démarré ce système de « e-invoicing ».
    L’avis d’échéance est déposé sur une plateforme technologique et par cette voie, présenté directement au client, dans son système « home-banking ».
    Le client peut facilement effectuer un « opt-in » et ainsi choisir de dorénavant opter pour ce système de « facturation ».
    Le paiement même s’effectue par les manipulations habituelles de l’application de « home-banking » en question.
.
  • 16.3. Kwijting in inning door de makelaar.
    De PRENOT van het antwoordrecord geeft de inhoud van de kwijting weer.

    De kwijting zelf wordt aan de makelaar gegeven, die dan binnen een zekere periode (de terugzendingstermijn voor kwijtingen) zal trachten te innen.
    De kwijting die de makelaar binnen de hem toegekende terugzendingstermijn terugstuurt naar de verzekeraar valt dan terug onder het regime van inning door de verzekeraar.
    De kwijting die niet binnen de toegekende terugzendingstermijn naar de verzekeraar terug gezonden is, is geacht door de makelaar geïnd te zijn.
    De kwijting blijft in het bezit van de makelaar totdat deze de betaling ontvangt, en wordt pas op dat ogenblik aan de verzekeringnemer overhandigd.
    De makelaar nodigt de verzekeringnemer uit het verschuldigde bedrag te betalen, en stuurt hem daarvoor een "bericht van contante" (of een "termijn-vervaldagbericht" in dat andere geval).
    Om het zijn makelaar en zijn klant gemakkelijk te maken, geeft de verzekeraar aan zijn makelaar, samen met de kwijting, een "bericht van contante" met daarbij een overschrijvingsformulier dat al ingevuld is met het te betalen bedrag, de gegevens van de bestemmeling van de betaling, en de referte van de betaling.

    Het principe is dus :
    • de verzekeraar identificeert het te betalen bedrag,de verzekeraar bericht zijn makelaar en vraagt hem te innen, (de kwijting) de makelaar bericht zijn verzekeringnemer en vraagt hem te betalen, (het (vervaldag-)bericht)de verzekeringnemer betaalt het verschuldigde bedrag (het overschrijvingsformulier)
    • de makelaar geeft de verzekeringnemer een bewijs van betaling (de kwijting).

    De GCP (Gemengde Commissie Productiviteit) heeft een drieluik (model A) ontworpen dat de drie elementen (kwijting, bericht en overschrijvingsformulier) groepeert op één enkel gedrukt en geperforeerd blad papier.
    • Binnen de verzekeraar maakt een dienst "productie" dat document aan, en geeft dat dan door aan de makelaar.Die makelaar scheurt dat document in twee, bewaart het deel "kwijting", en stuurt het deel "bericht plus overschrijvingsformulier" naar de verzekeringnemer.De verzekeringnemer scheurt het ontvangen document in twee, en gaat met het deel "overschrijvingsformulier" naar zijn bank om de betaling te doen, en bewaart het deel "bericht" in afwachting van de ontvangst van de "kwijting".
    • De makelaar ontvangt de betaling op zijn bankrekening en bevestigt dit aan de verzekeringnemer door hem de "kwijting" op te sturen.

    In de praktijk, omwille van de kosten, zijn de makelaars de verzekeraars gevolgd en zijn ook zij al vroeg clausules op de berichten gaan vermelden in de stijl van "...Dit bericht vergezeld van het overschrijvingsbewijs vormt het betalingsbewijs, onder voorbehoud van vroegere vervallen en nog onbetaalde premies of intresten. ...".
    Zo vermijden ook de makelaars de kwijting te moeten verzenden, apart van de verzending van het (vervaldag-)bericht. Het is bijna alsof het (vervaldag-)bericht tegelijkertijd de kwijting is...

    Al in 1985 heeft men dit gedrag sectoraal erkend en heeft de GCP een model B van zijn "drieluik" ontworpen.

    De « Witte Map » (versie 2.2, juni 1999) bepaalt in de « Aanbeveling 09 » ook nog de modellen C en D van dat « drieluik »; dat zijn aanpassingen aan technische kenmerken van de printers die toen in gebruik waren.
    Er wordt daar ook nog gesteld dat het "drieluik" of "vervaldagbericht - betalingsaanvraag" geen boekhoudkundig document is, maar dat de boekingen gebeuren op basis van het "borderel" zoals beschreven in de « Aanbeveling 05 ».

    In diezelfde periode 1985 – 1999 waren er nog enkele evoluties.
    • 16.3.1. « Vervaldagbericht – Betalingsaanvraag », versie makelaar.
      De uitgifte van een document met de hoofding van de makelaar maakt deze makelaar zichtbaarder.
      De beheerspakketten laten de makelaar toe zijn eigen betalingsrefertes te bezigen (op de overschrijvingsformulieren).
      De beheerspakketten lieten de makelaar toe gespreide betaling aan de klant aan te bieden, zonder dat dit de inning vanuit het standpunt van de verzekeraar beïnvloedde.
    • 16.3.2. « Vervaldagbericht – Betalingsaanvraag », gegroepeerde.
      De beheerspakketten laten de makelaar toe de verschillende vervallen kwijtingen binnen eenzelfde periode en voor eenzelfde verzekeringnemer, te groeperen op één enkel document dat ze zelf aanmaken en uitgeven.
      Dit heeft, samen met de mogelijkheid van gespreide betaling, geleid tot een vorm van budgettisering waar de makelaar het totaal van de jaarlijkse betalingen groepeert, aan de verzekeringnemer periodieke schijven opvraagt, en hem jaarlijks éénmaal de betaling van een saldo vraagt.
       
    Zoomit :
    in 2009 startte het systeem « e-invoicing ».
    Het vervaldagbericht wordt geleverd aan een technisch platform en via die weg rechtstreeks aan de klant aangeboden in zijn "homebanking" systeem.
    De klant kan gemakkelijk voor een "opt-in" kiezen en zo kiezen voortaan gebruik van dit "facturatie" systeem te maken.
    De betaling zelf gebeurt dan via de gewone handelingen zoals gebruikelijk binnen de "homebanking" toepassing in kwestie.
  • 16.3. Quittance, en encaissement par l’intermédiaire.
    Le PRENOT du bloc retour reflète le contenu de la quittance.

    La quittance en soi est donnée à l’intermédiaire, qui dans une certaine limite de temps (le délai de retour des quittances) va s’occuper de l’encaissement.
    La quittance retournée à l’assureur avant le délai de retour accordé à l’intermédiaire, retombe sous le régime d’encaissement par l’assureur.
    La quittance non retournée à l’assureur avant le délai de retour accordé à l’intermédiaire, est supposée être encaissée par cet intermédiaire.
    La quittance reste en mains de l’intermédiaire jusqu’à la réception du paiement par cet intermédiaire, et n’est qu’à ce moment donnée en mains du preneur d’assurance.
    L’intermédiaire invite le preneur à payer le montant dû en l’envoyant un « avis de comptant » (ou « avis d’échéance terme » dans tel autre cas).
    Afin de rendre la vie facile à son intermédiaire et à son client, l’assureur lui donne, en plus de la quittance, le « avis de comptant », et y intègre un bulletin de virement, pré rempli avec le montant payable, les données du destinataire du paiement (l’intermédiaire), et la référence du paiement.

    Le principe est donc que :
    • l’assureur identifie le montant à payer,
    • l’assureur avise et invite son intermédiaire à encaisser, (la quittance)
    • l’intermédiaire avise et invite son preneur d’assurance à payer, (l’avis)
    • le preneur paie le montant dû, (le bulletin)
    • l’intermédiaire donne une preuve de paiement au preneur d’assurance (la quittance).

    La CMP (Commission Mixte de Productivité) avait imaginé un document « triptyque » (modèle A) regroupant les trois éléments (quittance, avis et bulletin) sur une seule feuille de papier imprimée et perforée.
    • Chez l’assureur, un service « production » produit ce document, et le transmet à l’intermédiaire.
    • L’intermédiaire déchire ce document en deux, garde la partie « quittance » chez lui, et envoie la partie « avis plus bulletin » au preneur d’assurance.
    • Ce preneur d’assurance déchire ce document reçu en deux, et va avec la partie « bulletin » à sa banque pour effectuer le paiement, et garde la partie « avis » en attente de la réception de la quittance.
    • L’intermédiaire réceptionne le montant sur son compte en banque, et le confirme au preneur en lui envoyant la « quittance ».

    En pratique, pour les mêmes raisons de coûts, les intermédiaires ont suivi les assureurs et ont aussi commencés à utiliser des termes de style « ... Cet avis, accompagné du document justifiant le transfert de fonds constitue la preuve du paiement sans préjudice des primes ou intérêts antérieurs qui resteraient dus. ... ».
    Ainsi eux aussi évitent de devoir encore envoyer la quittance, séparément de l’envoi de l’avis. C’est presque comme si l’avis devienne en même temps quittance...

    Déjà en 1985, ce comportement a été reconnu au niveau sectoriel, et la CMP avait défini un modèle B de son « triptyque ».

    Le « Recueil Blanc » (version 2.2, juin 1999) définit dans la « Recommandation 09 » en plus les modèles C et D de ce « triptyque », s’adaptant aux caractéristiques techniques des imprimantes utilisées.
    Y est stipulé en plus que ce document « triptyque » ou « avis d’échéance – demande de paiement » n’est pas un document comptable, mais que les comptabilisations se font sur base du « bordereau », comme décrites dans une « Recommandation 05 ».

    Dans cette même période 1985 – 1999 se sont manifestées quelques évolutions en parallèle.
    • 16.3.1. « Avis d’échéance – Demande de paiement », version de l’intermédiaire.
      L’émission d’un document à entête de l’intermédiaire rends plus visible cet intermédiaire.
      Les systèmes de gestion utilisés ont permis aux intermédiaires d’utiliser leurs propres références de paiement (sur la partie bulletin).
      Les systèmes de gestion utilisés ont permis aux intermédiaires d’instaurer une notion de vente à tempérament sur le plan intermédiaire – preneur d’assurance, sans que ceci impactait l’encaissement comme vu par l’assureur.
    • 16.3.2. « Avis d’échéance – Demande de paiement » regroupés.
      Les systèmes de gestion ont permis les intermédiaires de regrouper les différentes échéances dans une même période pour un même preneur d’assurance, sur un même et seul document émis par leurs propres soins.
      Ceci, combiné avec la notion de vente à tempérament déjà citée, a même permis le développement d’une notion de budgétisation, l’intermédiaire y regroupant l’ensemble des dépenses annuelles du preneur d’assurance, et invitant ce preneur aux acquittements périodiques, et invitant ce preneur à l’acquittement du solde annuel.
       
    Zoomit :
    en 2009 est démarré ce système de « e-invoicing ».
    L’avis d’échéance est déposé sur une plateforme technologique et par cette voie, présenté directement au client, dans son système « home-banking ».
    Le client peut facilement effectuer un « opt-in » et ainsi choisir de dorénavant opter pour ce système de « facturation ».
    Le paiement même s’effectue par les manipulations habituelles de l’application de « home-banking » en question.
.
  • 16.4. Een contante kwijting versus een termijn kwijting.
    Buiten de boekhoudkundige implicaties volgen beide dezelfde principes.
  • 16.4. Une quittance au comptant vis-à-vis d’une quittance terme.
    Hormis les aspects comptables, les deux respectent les mêmes principes.
.
  • 16.5. Doel van de informatie geleverd via het « Vervaldagbericht – Betalingsaanvraag ».
    • 16.5.1. De makelaar toelaten zijn eigen versie te ontwerpen en te printen.
      Het detail van de verschafte informatie, met name dat van de verschillende risico-objecten, en dat van de verschillende mogelijke waarborgen, en dat alles onder eenzelfde contract, moet toelaten aan de wettelijke verplichtingen te voldoen.
      In principe weerspiegelen die details qua risico-objecten en waarborgen deze van het contract.
      Indien de verzekeraar in zijn eigen "papieren" versie van het vervaldagbericht verkozen heeft de zaken te condenseren door bepaalde objecten en/of waarborgen te groeperen, dan mag hij datzelfde niet aan zijn makelaar opleggen door hem slechts diezelfde groeperingen te bieden via zijn "geïnformatiseerde" versie.
      Dit doel is geldig in de sfeer van de inning door de makelaar.
       
    • 16.5.2. Zicht hebben op de financiële stroom vanuit verschllende standpunten.
      Als de details qua risico-objecten en waarborgen dezelfde zijn voor de contracten en voor de "vervaldagberichten - betalingsaanvragen", dan kan de makelaar de zaken bekijken volgens de financiële assen die hij zelf bepaalt.
      Dergelijke zichten zijn sleutelelementen ten behoeve van allerhande beslissingen die de makelaar in hoofde van zijn beroep moet kunnen nemen.
      Dit doel is ruimer dan enkel de zaken in inning makelaar en men moet er de zaken in inning verzekeraar in betrekken.
  • 16.5. Finalité des informations fournies par le biais du « Avis d’échéance – Demande de paiement ».
    • 16.5.1. Permettre l’impression d’une version propre à l’intermédiaire, par l’intermédiaire, suivant les intentions de l’intermédiaire.
      Les détails des renseignements, spécialement au niveau des multiples objets de risques, et au niveau des multiples garanties possibles sous un même contrat, doivent permettre de répondre aux obligations légales.
      En principe, ces détails en objets de risque et en garanties reflètent les détails du contrat.
      Si l’assureur, dans sa propre version « papier » de l’avis a préféré condenser les choses en regroupant certains objets et/ou garanties, il ne peut pas obliger l’intermédiaire à faire de même, ne lui offrant que ces mêmes détails globalisés dans sa version « informatisée ».
      Cette finalité est là pour les affaires en encaissement par l’intermédiaire.
       
    • 16.5.2. Avoir une vue sur les flux financiers suivant multiples axes.
      Le détail au niveau des objets de risque et au niveau des garanties étant le même pour les contrats et pour les « Avis d’échéance – Demande de paiement », permettra l’intermédiaire de développer les vues suivant les axes que lui désire.
      Ces vues sont les éléments-clés à la base de diverses décisions que lui doit prendre dans le chef de sa profession.
      Cette finalité dépasse les seules affaires en encaissement par l’intermédiaire, il faut y intégrer les affaires en encaissement par l’assureur.
.
  • 16.6. Ontvangst en integratie van een kwijting.
    De PRENOT van het antwoordrecord geeft de inhoud van de (contante) kwijting weer.
    De PRENOT aangemaakt door het termijnvervaldagenbeheer geeft de inhoud van de (termijn-)kwijting weer.

    Onder het punt « Bijvoegsel » – « Integratie antwoordrecord » – « Administratieve contractgegevens » - « Identificatie » staat uitgelegd wanneer en hoe een nieuwe versie van een contract wordt aangemaakt.
    Onder dergelijke contractversie wordt deze (contante) of gene (termijn-) kwijting aangemaakt.
     
    • Identificatie
      Het nummer van de kwijting, en van het contract, en van de verzekeraar.
      Als de kwijting niet gevonden wordt in het beheerspakket, en het contract wel, dan wordt de kwijting aangemaakt (Het normale geval).
      (De minder normale gevallen.)
      • Als de kwijting niet wordt gevonden in het beheerspakket, en het contract ook niet, dan heeft makelaar de mogelijkheid een contract op te zoeken in zijn databank.
        Wordt het contract nog steeds niet gevonden, dan nog moet de makelaar de mogelijkheid krijgen de kwijting te integreren.
        Die situatie is uitzonderlijk en moet toelaten een PRENOT te integreren, zelfs in het geval waar er een probleem is met de nummering van de contracten.
      • Als de kwijting wordt gevonden in het beheerspakket, dan heeft de makelaar de mogelijkheid deze al of niet bij te werken.
      Deze situaties doen zich in principe niet voor wanneer de makelaar zijn polissen bijwerkt met behulp van de kwijtingen komende van de verzekeraars.
       
    • Gegevens
      Zie de MIG M0304 in Telebib.
      We gaan er van uit dat de PRENOT alle waarborgen bevat. De gegevens van de verzekeraar vervangen deze van het beheerspakket op het niveau van die kwijting.

      Zie ook de MIG M0603 « Samenvatting, controletotalen PRENOTbestand(en) ».
      Er staat in de commentaren :
      • Dit bericht moet in dezelfde XGH-XGT (groepering van berichten) zitten als het PRENOT bericht waarvan sprake.
      • Een apart bericht per: inningswijze, munteenheid, en code uitwissellingskaart.
      Opmerking :
      Maar het segment XGH zou dan in de X925 "Group type" een waarde moeten bezigen die expliciet maakt dat de enveloppe specifiek is.
      Een (niet-ideale) kandidaat zou de waarde 003 « Borderel » kunnen zijn, maar de definitie daarvan zegt « ...Niet gebruiken in nieuwe ontwikkelingen (aldus genoteerd op 08.11.2001). ... ».
      Beter nog zou een (nieuwe) waarde 007 « Termijnborderel » zijn.
       
    • Filter
      Niet van toepassing.
  • 16.6. Réception et intégration d’une quittance.
    Le PRENOT du bloc retour, reflète le contenu de la quittance (au comptant).
    Les PRENOT générés par la gestion des échéances terme, reflètent le contenu des quittances (terme).

    Sous le point « Avenant » – « Intégration bloc retour » – « Données administratives du contrat » - « Identification » est expliqué quand et comment se crée une nouvelle version d’un contrat.
    C’est en dessous de telle version du contrat que se crée l’une (quittance au comptant) ou l’autre quittance (au terme).
     
    • Identification
      Le numéro de la quittance et le numéro du contrat et le numéro de l’assureur.
      Si la quittance n’est pas trouvé dans le package, et si le contrat est retrouvé dans le package, la quittance sera créée. (Le cas normal.)
      (Les cas moins normaux.)
      • Si la quittance n’est pas trouvé dans le package, et si le contrat n’est pas trouvé dans le package, le courtier aura la possibilité de rechercher un contrat dans son package.
        Si le contrat n’est toujours pas retrouvé, il faut encore permettre au courtier de décider d’intégrer la quittance.
        Cette situation doit être exceptionnelle et doit permettre d’intégrer un PRENOT, même s’il y a un problème de numérotation des contrats.
      • Si la quittance est retrouvé dans le package, le courtier aura le choix entre la mise à jour ou non de telle quittance.
      Ces situations ne se présenteront en principe pas si le courtier met à jour ses polices à l’aide des quittances provenant des compagnies.
       
    • Données
      Voir le MIG M0304 du Telebib.
      Nous considérons que le PRENOT contient toutes les garanties.
      Les données de la compagnie remplacent les données du package, au niveau de telle quittance.

      Voir aussi le MIG M0603 « Récapitulation, totaux de contrôle fichier(s) PRENOTs ».
      Y est stipulé :
      • Ce message doit faire partie du même XGH-XGT (groupe de messages) que le message PRENOT dont question.
      • Un message distinct par : mode d'encaissement, unité monétaire, et code carte échange.
      Remarque :
      Mais le segment XGH devrait alors utiliser une valeur en X925 « Group type » pour expliciter que l’enveloppe est bien spécifique.
      Un candidat (non-idéal) serait la valeur 003 « Bordereau », mais est stipulé dans la définition « ...Ne pas utiliser dans des nouveaux développements (cette note date du 08.11.2001). ... ».
      Un meilleur candidat serait une (nouvelle) valeur 007 « Ensemble d’avis terme ».
       
    • Filtre
      Pas d’application.
.
. . .

 

-->