L'élémentaire sur notre
domaine des assurances
Encore une fois, sans un minimum de connaissances sur le secteur des assurances
lui-même, et sur son fonctionnement et sa réglementation sur notre
marché belge, vous ne devriez pas vouloir vous lancer. Insert est le « centre de compétences » d'Assuralia qui dispense les
formations nécessaires. Vous pouvez vous rabattre là-dessus si
nécessaire.
L'élémentaire sur notre
syntaxe Edifact
Rentrez les "Syntax dependent components", et lisez les deux textes sur la page "introduction".
Ces textes ne sont pas fort longues, et il est indispensable de les avoir lus.
Eléments importants du
site-web
Les plus assidus trouvent ici une introduction sommaire; une explication textuellecomment les différentes parties du site-web sont
connectées (y compris la présentation).
Un bon trajet
d'apprentissage A. Comprenez ce que sont les données élémentaires
(atomaires), oui ou non données codifiées. Et comprenez comment nous
assemblons ces données, formant ainsi des messages lesquels nous voulons
échanger (MCI - Message Content Inventories). B. Saisissez ce que sont les BBP (Broker Business Processes) et comment les
messages échangés viennent à l'appui de ces processus ou même
carrément permettent de les réaliser. C. Comprenez ce qu'est cette syntaxe Edifact. D. Saisissez ce que sont ces Edifact-qualifiants et comment ils donnent une
signification concrète aux segments et aux groupes de segments. E. Comprenez comment à partir des MCI nous passons aux MIG (Message
Implementation Guide). F.
Saisissez ce que fait la validation et ce qu'elle ne fait pas, et comment cela peut vous
aider lors de votre quality-control. G. Comprenez comment ce grand ensemble évolue avec le temps et
comment/pourquoi nous pratiquons des releases annuels et/ou des versions successives des
messages-définitions.
H. Un élément
délicat/sensible
La Convention Sectorielle 1 (SLA 1/3) "La maintenance du Telebib2" définit
sous son point 3.2.2 les "Demandes de modifications, remplacements,
dépréciations, radiations de données et/ou de valeurs".
C'est ce concept de "dépréciation" qui est
difficile.
Dans nombre d'écrans/listes sur notre site-web nous pratiquons ici le terme (anglais)
"obsolete"
("désuet" ou "obsolète" en français).
Avant d'avoir réussi à rédiger le texte de ce SLA 1/3 on en a longtemps
et intensément discuté, et la définition à laquelle on est
finalement arrivée est ce qu'elle est, et est le seul fil conducteur que nous avons
à notre disposition.
Y est acté que ce sont des demandes qui nuisent à la compatibilité
descendante.
Notre interprétation est:
- Lors d'une visualisation/consultation d'un dossier la donnée/valeur permet la
recherche du libellé qui va avec et donc la visualisation de tel libellé.
- Lors d'une visualisation d'une liste de choix possibles ("listbox" ou
"combobox" en anglais) les donnée/valeurs reprises
(présentées à l'utilisateur) sont celles qui ne sont pas (encore)
obsolètes.
- Lors d'un échange (message), le obsolète ne peut plus être
présent du tout.
(Implique que tout obsolète doit être recherché et
modifié dans le portefeuille... )
- Dès le 1/12/2017 (dans le contexte législatif des "rapports
adéquats") devrait être implémenté:
En réception, le destinataire (courtier ou autre) reçoit un
warning dans le cas de la présence de données/valeurs obsolètes. Ceci
moyennant une fonctionnalité du package de gestion ou du
système/réceptacle des messages.
Une vidéo au sujet de l'outil de validation
Ceci est une première - nous voulons utiliser d'autres médias didactiques.
Dans ce premier essai nous parlons de l'outil validant le contenu d'un message.
C'est fait en deux étappes, comme c'est le cas lors de la validation d'un contenu
XML.
Là aussi, on va d'abord valider la syntaxe pure et puis, quand c'est bon, on va y
valider le contenu vis à vis du schéma référencé dans le
message même.
Nous avons isolées les deux étappes dans des outils distincts...
> Seminars