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 textuelle comment 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...

...