L’utilisation du relevé de portefeuille est évidente, le producteur qui s'informatise peut être aidé par les compagnies à constituer ses fichiers.
Exemples de demandes :
- en cas de transfert de portefeuille entre producteurs (vente, succession, ...);
entre compagnies à la suite de fusion, absorption et autres; - en cas de modification importante des tarifs, etc. ...
6.1. A partir du package
6.1.1. Par échange de message
Le courtier y trouve la fonctionnalité lui permettant de générer le message suivant le MIG M0401 (Demande de relevé de portefeuille).
12/10/2022 - Le GT Normalisation décide :
- constatant qu'aucun assureur a développé le nécessaire pour la réception et le traitement de ce message;
- ce message est abandonné - son MCI et son MIG seront archivés;
- le code objet/action 0401 reste utilisable pour l'invocation du service.
Tel abandon du message généré à partir du package-même réduit l'efficacité en sein du bureau de courtage.
6.1.2. Par invocation d’un service
Il se trouve sur une fiche « compagnie », plus précisément une fiche « compte producteur en sein d’une compagnie ».
- Si la compagnie a publié le service « Demande de relevé de portefeuille », le module de la compagnie est démarré.
- Le numéro du compte producteur est communiqué au module de la compagnie soit par l’échange contextuel, soit comme paramètre supplémentaire à l’invocation.
Le courtier se trouve sur une autre fiche
- Pas d’invocation possible.
6.2. A partir du système de publication des services
Tout se déroule dans le module de la compagnie.
6.3. Points d’attention
6.3.1. Eviter les doubles encodages
Permettre au courtier de brancher directement sur la page de la consultation.
Le module de la compagnie doit exploiter les paramètres qui sont passés à l’exécutable ou à l’URL au moment de l’invocation.
6.3.2. Eviter de ré encoder la référence de l’objet consulté
Lors de l’appel du service, il faut passer au module de la compagnie la référence de l’objet concerné (la référence du compte producteur).
Cet échange d’information peut se faire soit :
- À l’aide de l’échange contextuel
- En passant la référence de l’objet consulté en paramètre supplémentaire à l’exécutable ou à l’URL au moment de l’invocation
6.3.3. La demande peut porter sur :
- tout le portefeuille,
- une police précise (ne pouvant pas être appelée par le bloc retour à la demande),
- un groupe de polices (suivant Type de Police).
6.3.4. Règles d’extraction :
- Les compagnies envoient toutes les polices dont le courtier est gestionnaire sauf les annulées, résiliées, suspendues, expirées depuis plus de 2 ans.
- Les données des enregistrements doivent permettre de reconstituer la situation de la police au moment de la dernière date d’échéance principale ou de la dernière situation contractuelle en cours à la date d’extraction sauf les nouvelles polices à effet différé qui sont envoyées.
- Tous les montants sont actualisés à la date d'extraction du relevé.
- Les compagnies doivent mentionner s’il y a une version future du contrat.
- Pour des contrats de coassurance, la compagnie apéritrice doit envoyer les montants totaux.
- Les compagnies participantes peuvent envoyer le contrat, les objets de risques et les garanties.
- Dans les relevés de contrats, on ne reprend ni les projets, ni les affaires sans suite.
- Le relevé de contrat est uniquement constitué des données du contrat (CNTRCT).
- Les quittances (PRENOT) n’y sont pas inclues.
6.4. Réception et intégration de la réponse
Le principe est celui de l’intégration d’un « bloc retour », mais il y a des nuances spécifiques à cette réception de message sur base du MIG M0114.
6.4.1. Généralités
La compagnie envoie toutes les données d’un contrat.
Seules les données reprises dans le message mettront à jour la base de données du courtier.
L’assureur ne tient pas compte de l’éventualité où les données (codifiées) du courtier sont plus détaillées que celles de la compagnie.
Pour commencer l’intégration d’un contrat, les données suivantes doivent être retrouvées dans le packages :
- Le code OCA de la compagnie
- Le code producteur
Par sous rubrique, nous détaillons les règles d’intégration :
- Identification de la sous rubrique
- Données qui font partie de la sous rubrique
- Application d’un filtre d’intégration
6.4.2. Données administratives du contrat
Identification
- Le numéro de contrat
- Si le contrat n’est pas retrouvé dans le package, il y est intégré.
- C’est la situation « normale ».
- Si le contrat est retrouvé, il faut en garder trace, et ne pas trop vite « jeter » l’information. Il revient au package d’imaginer et de prévoir une fonctionnalité adéquate.
Données
- Voir les MIG (Message Implementation Guide) du Telebib.
Filtre
Les données de la compagnie étant plus précises, il n’y aura pas de filtre d’intégration.
Les données du message seront intégrées dans le package sans manipulations.
6.4.3. Données du preneur d’assurances
Identification
Le portefeuille appartenait déjà au courtier
- Identifiant interne du preneur (identification univoque)
- Nom + prénom + code postal + date naissance
- Nom + prénom + code postal
- Nom
Si le preneur est trouvé de manière univoque à l’aide de l’identifiant interne du preneur, il n’y a en principe pas de manipulation lors de l’intégration du preneur (mais le courtier a la possibilité de choisir un autre preneur).
Si le preneur est trouvé avec les autres critères de recherche, le courtier doit choisir dans la liste résultant de la recherche (même si un seul preneur) (mais le courtier a la possibilité de choisir un autre preneur).
Si le preneur n’est pas trouvé, il est en principe créé à partir des données du bloc retour de la compagnie (mais le courtier a la possibilité de choisir un autre preneur).
Remarque : Pour que l’intégration se passe de manière suffisamment « fluide » il faut que le package prévoit la possibilité de réponses par défaut à ce genre de questions.
Le portefeuille appartenait à un autre courtier
- Nom + prénom + code postal + date naissance
- Nom + prénom + code postal
- Nom
Si le preneur est trouvé avec les critères de recherche disponibles, le courtier doit choisir dans la liste résultant de la recherche (même si un seul preneur) (mais le courtier a la possibilité de choisir un autre preneur).
Si le preneur n’est pas trouvé, il est en principe créé à partir des données du bloc retour de la compagnie (mais le courtier a la possibilité de choisir un autre preneur).
Données
- Voir les MIG du Telebib.
Filtre
- Les données du courtier peuvent être plus complètes.
- Le filtre d’intégration présentera les différences.
- Les données du courtier sont prioritaires par défaut.
6.4.4. Objet de risque Auto – véhicule/remorque
Identification
- Numéro de PVA et numéro de suite PVA - fichier « Febiac » (identification univoque)
- Marque + châssis (identification univoque)
- Plaque + marque + année de construction
- Plaque + marque
Si l’objet de risque est trouvé à l’aide de l’identification univoque, les données du courtier seront en principe remplacées par celles du bloc retour (mais le courtier a encore toujours la possibilité de choisir un autre objet).
Si plusieurs objets de risque répondent aux critères de recherche, ils seront présentés au courtier et il aura la possibilité d’en sélectionner un parmi la liste ou de créer un nouvel objet de risque à partir des données du bloc retour.
Si aucun objet de risque ne répond aux critères, un nouvel objet de risque sera en principe créé à partir des données du bloc retour (mais le courtier pourrait encore opter pour un objet déjà appartenant au preneur, il faudrait donc lui présenter ces objets).
Données
- Voir les MIG du Telebib.
Filtre
- Les données de la compagnie sont plus complètes.
- Le filtre d’intégration présentera les différences.
- Données de la compagnie sont prioritaires par défaut.
6.4.5. Objet de risque Auto – Conducteur habituel
Identification
- Nom + prénom + code postal + date naissance
- Nom + prénom + code postal
- Nom
Si le preneur d’assurance = le conducteur habituel : il n’y a pas de données à intégrer.
Sinon : il faut faire comme pour la personne dans le rôle du preneur, mais ici dans le rôle du conducteur habituel. Ce principe est vrai pour tout « intervenant » ou « rôle ».
Données
- Voir les MIG du Telebib. (RODGEN, ROD001, ROD002)
Filtre
- Les données du courtier peuvent être plus complètes.
- Le filtre d’intégration présentera les différences.
- Les données du courtier sont prioritaires par défaut.
6.4.6. Objet de risque Incendie – Immeuble
Identification
- Numéro d’identification de la rue du fichier DEDALE
- Rue + n° de rue + n° de boîte + code postal + localité (identification univoque)
- Rue + n° de rue
Si l’objet de risque est trouvé à l’aide de l’identification univoque, les données du courtier seront en principe remplacées par celles du message, mais le courtier a encore la possibilité de choisir un autre objet.
Si plusieurs objets de risque répondent aux critères de recherche, ils seront présentés au courtier et il aura la possibilité d’en sélectionner un parmi la liste ou de créer un nouvel objet de risque à partir des données du message.
Si aucun objet de risque ne répond aux critères, un nouvel objet de risque sera en principe créé à partir des données du message, mais le courtier pourrait encore opter pour un objet déjà appartenant au preneur, ou même un tout autre objet, il faudrait donc lui présenter ces objets, ou lui permettre d’y accéder.
Données
- Voir les MIG du Telebib. (RODGEN, ROD01x)
Filtre
- Les données de la compagnie sont plus complètes.
- Le filtre d’intégration présentera les différences.
- Données de la compagnie sont prioritaires par défaut.
6.4.7. Objet de risque RCF – Famille (Vie Privée)
Identification
- Objet de risque RCF
Si l’objet de risque est trouvé, il n’y a pas de modification.(Particularité : 1 seule donnée -> on garde toujours le même objet de risque)
Sinon, l’objet de risque est créé à partir des données reprises dans le message.
Données
- Voir les MIG du Telebib. (RODGEN, ROD060)
Filtre
- Pas d’application.
6.4.8. Objet de risque Personne (individu)
Identification
- Nom + prénom + code postal + date naissance
- Nom + prénom + code postal
- Nom
Il faut faire comme pour la personne dans le rôle du preneur, mais ici dans le rôle de’objet de risque « personne – individu ». Ce principe est vrai pour tout « intervenant » ou « rôle ».
Données
- Voir les MIG du Telebib. (RODGEN, ROD030)
Filtre
- Les données du courtier peuvent être plus complètes.
- Le filtre d’intégration présentera les différences.
- Les données du courtier sont prioritaires par défaut.
6.4.9. Objet de risque Groupe de personnes
Identification
- Nom + code postal
- Nom
Si plusieurs objets de risque répondent aux critères de recherche, ils seront présentés au courtier et il aura la possibilité d’en sélectionner un parmi la liste ou de créer un nouvel objet de risque à partir des données du message.
Si aucun objet de risque ne répond aux critères, un nouvel objet de risque sera en principe créé à partir des données du message, mais le courtier pourrait encore opter pour un objet déjà appartenant au preneur, ou même un tout autre objet, il faudrait donc lui présenter ces objets, ou lui permettre d’y accéder.
Données
- Voir les MIG du Telebib. (RODGEN, ROD04x)
Filtre
- Les données de la compagnie sont plus complètes.
- Le filtre d’intégration présentera les différences.
- Données de la compagnie sont prioritaires par défaut.
6.4.10. Objet de risque Groupe/Personne (exécution d’une activité)
Identification
- Nom + code postal + numéro d’entreprise + numéro d’unité d’entreprise
- Nom + code postal + numéro d’entreprise
- Nom + code postal
- Nom
Si plusieurs objets de risque répondent aux critères de recherche, ils seront présentés au courtier et il aura la possibilité d’en sélectionner un parmi la liste ou de créer un nouvel objet de risque à partir des données du message.
Si aucun objet de risque ne répond aux critères, un nouvel objet de risque sera en principe créé à partir des données du message, mais le courtier pourrait encore opter pour un objet déjà appartenant au preneur, ou même un tout autre objet, il faudrait donc lui présenter ces objets, ou lui permettre d’y accéder.
Données
- Voir les MIG du Telebib. (RODGEN, ROD05x)
Filtre
- Les données de la compagnie sont plus complètes.
- Le filtre d’intégration présentera les différences.
- Données de la compagnie sont prioritaires par défaut.
6.4.11. Objet de risque Animal
Identification
- Nom + date d’achat + numéro matricule
- Nom + date d’achat
- Nom
Si plusieurs objets de risque répondent aux critères de recherche, ils seront présentés au courtier et il aura la possibilité d’en sélectionner un parmi la liste ou de créer un nouvel objet de risque à partir des données du message.
Si aucun objet de risque ne répond aux critères, un nouvel objet de risque sera en principe créé à partir des données du message, mais le courtier pourrait encore opter pour un objet déjà appartenant au preneur, ou même un tout autre objet, il faudrait donc lui présenter ces objets, ou lui permettre d’y accéder.
Données
- Voir les MIG du Telebib. (RODGEN, ROD090)
Filtre
- Les données de la compagnie sont plus complètes.
- Le filtre d’intégration présentera les différences.
- Données de la compagnie sont prioritaires par défaut.
6.4.12. Objet générique
- Y est question des objets de type non documenté ci-dessus.
Identification
- Néant
Aucun objet de risque ne répond aux critères, un nouvel objet de risque sera en principe créé à partir des données du message, mais le courtier pourrait encore opter pour un objet déjà appartenant au preneur, ou même un tout autre objet, il faudrait donc lui présenter ces objets, ou lui permettre d’y accéder.
Données
- Voir les MIG du Telebib. (RODGEN)
Filtre
- Les données de la compagnie sont plus complètes.
- Le filtre d’intégration présentera les différences.
- Données de la compagnie sont prioritaires par défaut.
6.4.13. Garanties
Identification
Nous considérons que le message contient toutes les garanties.
Les données de la compagnie remplacent les données du package.
Données
- Voir les MIG du Telebib.
Filtre
- Pas d’application.