Introduction EDIFACT

1. Principes de base

1.1. Basé sur UN/EDIFACT

La norme TELEBIB2 s’appuie dans sa version originale sur le standard international UN/EDIFACT. Toutefois, certaines composantes ont été adaptées pour mieux répondre aux besoins du secteur belge de l’assurance.

En ce qui concerne les répertoires, seuls certains segments UN/EDIFACT ont été conservés, tandis que de nouveaux segments ont été créés pour remplacer ceux qui ne répondaient pas suffisamment aux besoins belges ou pour couvrir des concepts absents d’UN/EDIFACT.

Les écarts par rapport à UN/EDIFACT ne sont cependant pas de nature à exclure le traitement du TELEBIB2 dans un environnement EDIFACT pur. Les entreprises qui utilisent déjà UN/EDIFACT, ne devront donc adapter leur environnement existant que dans une mesure réduite. D'autre part, on peut affirmer que les entreprises qui implémenteront le TELEBIB2 se constitueront une base suffisamment large pour passer éventuellement à l'utilisation d'UN/EDIFACT afin d'échanger par voie électronique des informations structurées avec des partenaires d'autres secteurs.

1.2. Un format unique pour tous les types d'assurance

Les éléments et les rubriques décrits dans le TELEBIB2 peuvent être utilisés à différentes fins spécifiques. L'ensemble "contrat", par exemple, peut être utilisé pour l'échange d'informations relatives à la fois à des polices de branches différentes et à des polices concernant différentes branches, de même qu'à toutes les actions se rapportant à une police donnée. Dans le même esprit, la rubrique générique "objet de risque", par exemple, peut être utilisée pour l'échange d'informations concernant aussi bien un véhicule qu'un bâtiment.

1.3. Adaptable aux besoins des utilisateurs

La norme TELEBIB2 documente les messages en répertoriant tous les champs susceptibles d’être échangés. Au-delà des champs obligatoires qu’elle définit, la partie émettrice reste libre de choisir les informations qu’elle juge utiles d’inclure. De son côté, la partie réceptrice détermine quelles informations, parmi celles présentes dans les messages, elle souhaite conserver et exploiter dans son système.

2. La syntaxe UN/EDIFACT

2.1. Tags et codes Telebib2

Dans le standard UN/EDIFACT; chaque champs utilisé est déterminé par une code de trois chiffres, également appelé "tag", qui indique le type d'information contenue dans le champs.

La liste complète des tags existants dans la norme TELEBIB2 peut être consultée dans les annuaires.  

Voici quelques exemples de tags pour les champs les plus courants : 

• MOA : Montant
• ATT : Attribut
• DTM : Date
• BIN : Champs binaire / boolean
• RFF : Référence
• IFD : Formule
• ...

2.1. Code Lists & Qualifiers

La standard UN/EDIFACT est très codifié. Toutes les informations sont indiquées via des associations de codes (appelés aussi des tags) et des chiffres (appelés des qualifiers).

Lorsque les valeurs permises pour une donnée échangés sont limitées, celles-ci sont documentées dans une liste de valeurs souvent appelée « code list ».

Exemple : Code list 4160 – Type de famille

• 1 – Famille avec enfants
• 2 – Famille monoparentale
• 3 – Famille sans enfants
• 4 – Famille d’une seule personne

Le qualifier est un type de code list particulier qui donne la liste des valeurs à utiliser pour qualifier un objet. Ils sont reconnaissables par leur nomenclature : un « X » suivi d’un code de 3 chiffres.

Exemple : Segment « Date d’effet »

• « DTM » est le tag qui définit tous les segments du type Date/temps.
• La liste des qualifiers autorisés pour le type de segment définit est repris dans la liste X016 « Date/Time qualifier »
• dans la liste, on voit que la qualifier « 008 » représente la date d’effet d’un contrat.
• Le segment de la date d’effet du contrat sera donc indiqué dans le message comme suit : DTM+008

2.1.1. L'utilisation de X901 "Code list identifier" et de X902 "Code list responsible agency, coded"

Lors de l'utilisation de listes de valeurs, il faut, dans certains cas, indiquer quelle liste de valeurs est utilisée et par qui la liste de valeurs utilisée est gérée. A cette fin, il faut utiliser les éléments de données X901 "Code list identifier" et X902 "Code list responsible agency, coded".

2.1.2. Utilisation d'une liste de valeurs spécifique d'une compagnie

Dans certains cas, les partenaires peuvent décider d'utiliser une liste de valeurs spécifique compagnie au lieu d'une liste de valeurs standard TELEBIB. X901 et X902 doivent alors être utilisées comme suite :

• IFD+572:xxx:0079'
• IFD+C090' ( voir le répertoire des Segments pour la description du IFD )
• IFD+X062:X901:X902:X063' ( voir le répertoire des Composite Data Elements pour la description du C090 )

( ...et la conclusion est que... )

• IFD indique que la donnée est une formule
• 572 est la valeur qui identifie la formule dans la liste spécifique de la compagnie
• xxx contient l'identification de la liste spécifique dans l'annexe du TELEBIB2
• 0079 indique que la liste appartient à la compagnie 0079

2.3. Représentation des valeurs des éléments de données numériques

2.3.1. Signe décimal

Contrairement à la norme EDIFACT actuelle, le signe décimal doit continuer à ne pas être utilisé dans l'échange.

Le nombre de positions décimales doit être spécifié dans un autre élément de données et doit être compté pour le calcul de la longueur de champ maximale de l'élément de données numérique.

Dans un élément de données numérique n..9 (2 décimales), '12,50' doit être transmis comme '1250'.

Bonne pratique :

• Ne pas reprendre les zéros non significatifs dans la partie entière.
• Compléter si nécessaire la partie décimale avec des zéros devant et derrière.

Ex. : Dans un élément de données numérique n..9 (3 décimales), '-0,05' doit être transmis comme '-0050' et '0' doit être transmis '0000'.

2.3.2. Séparateur de milliers

Les séparateurs de milliers ne doivent pas être utilisés dans l’échange.

• Autorisé : 2500000
• Interdits : 2,500,000 ou 2.500.000 ou 2 500 000.

2.3.3. Signe

Si une valeur doit être signalée comme négative, elle doit être immédiatement précédée du signe « moins » (par exemple '-12' dans un élément de données défini comme n..5 (et pas '-..12')).

Contrairement à la norme EDIFACT, le signe « moins » doit être compté comme un caractère de la valeur pour le calcul de la longueur de champ maximale d’un élément de données (par exemple n..4 accepte des valeurs allant de -999 à 9999).

3. Structure du message TELEBIB2

3.1. Structure globale

Le message TELEBIB2 est composé de plusieurs niveaux :

Plusieurs unités d'échange peuvent figurer dans un groupe. Plusieurs rubriques peuvent figurer dans une unité d'échange. Une rubrique est constituée de segments. Un segment se trouve dans une rubrique ou directement dans l’unité déchange Un segment est composé d'éléments de données simples et/ou composites. Les segments doivent figurer dans l'ordre indiqué ci-dessous dans un groupe d'unités d'échange.

• Les éléments de données sont liés au segment, soit directement, soit par l’intermédiaire d’un élément de données composite. Par exemple, les champs d’une adresse (rue, numéro, code postal, ville, etc.) sont regroupés dans l’élément de données composite « Adresse ».

3.2. Les types d’objets dans les messages EDIFACT

3.2.1. (Groupe d’) Unité d’échange

L’unité d’échange et le groupe d’unité d’échange représentent le plus haut niveau de groupement dans le fichier échangé. Il donne une indication sur la nature de l’objet échangé à un niveau très agrégé. 

La norme TELEBIB2 contient 13 types d’unités d’échange :

Les informations véhiculées après le code XEH dans le message dépendent du type d’unité d’échange.

Il n’y a qu’un groupe d’unité d’échange défini dans la norme TELEBIB2 reprenant les informations concernant l’émetteur et le destinataire du message : 

• X926 - Numéro de version *            * champs obligatoire
  
  • C900 – Identification de l’émetteur
    • X921 : Emetteur : Adresse du domaine *
    • X922 : Emetteur : Adresse utilisateur
    • X927 : Code type d’émetteur
  • C905 – Identification du destinataire
    • X923 : Emetteur : Adresse du domaine *
    • X924 : Emetteur : Adresse utilisateur
    • X928 : Code type d’émetteur
  • X925 – Type du groupe d’échange

3.2.2. Groupe de segments (rubrique)

Une rubrique ou groupe de segments regroupe des segments formant un ensemble souvent repris de manière identique dans plusieurs messages où elle apparaît.

La norme TELEBIB2 distingue 25 types de rubriques différentes.

Exemple : Rubrique « Assureur »

• Les intervenants sont souvent repris avec des informations semblables dans les messages. 
• Elles sont reprises dans la rubrique avec le tag « PTY » et les qualifiants autorisés sont repris dans la liste X043 Party Qualifier. 
• L’assureur est repris dans cette liste avec le qualifiant 006
• La rubrique PTY+006 qualifiant l’assureur sera toujours composée des segments suivants : 
  
  • PTY+006 : Assureur
  • RFF+075 : Numéro d’entreprise
  • RFF+076 : Numéro d’unité d’établissement
  • RFF+107 : LEI (Legal Entiry Identifier)
  • ATT+A020 : Type d’assureur en co-assurance

Une rubrique contient :

• En-tête de rubrique : XRH (obligatoire)
• Segment avec données rubrique (obligatoire)
• Segment(s) avec données utilisateurs (selon besoin)
• Rubrique(s) (selon besoin)
• Fin de rubrique : XRT (obligatoire)

3.2.3. Segments

Chaque segment est identifié par un "segment tag", tels que DTM et MOA. Dans un segment, une donnée est identifiée au moyen d'un "qualifier". Ainsi, un qualifier indiquera, par exemple, qu'une date est une date de naissance ou une date de début, ou encore qu'un montant est une prime ou une valeur assurée. Outre le qualifier et la valeur explicite d'une donnée proprement dite, le segment pourra contenir d'autres informations sur une donnée. 

Pour un montant, on pourra par exemple indiquer la monnaie et pour une date, le format dans lequel elle est exprimée. Tous les fragments d'information concernant une donnée sont placés dans des éléments de donnée et ont une place fixe dans un segment. Dans certains cas, et cela uniquement pour des raisons techniques, des éléments de données sont regroupés dans des éléments de données composites. Les éléments de données qui ne sont pas disposés dans des éléments de données composites sont appelés des éléments de données simples.

Une description complète des segments et des éléments de données composites et simples est reprise dans les répertoires respectifs. Pour indiquer qu'il s'agit ici de notions techniques, des dénominations anglaises ont été données aux segments et aux éléments de données composites et simples.

Le segment définit d’un point de vue fonctionnel précis la nature de l’information échangée. 

Il est défini par un code segment composé par

• un tag de 3 lettres indiquant le type de donnés échangés ainsi 
• un qualifiant de 3 chiffres qui définit exactement la donnée échangée

Exemple : Date d’effet – DTM+008

Un segment contient :

• Code du segment   (obligatoire)
• Séparateur d'éléments de données  (obligatoire)
• Eléments de données simples ou composites  (selon les besoins)
• Indicateur fin de segment  (obligatoire)

3.2.4 Eléments de données

L’élément de données est l’objet qui contient la valeur de l’information véhiculée dans le segment.

Un élément de données constitutif ne contient qu'une seule valeur d'élément de données.

Un élément de données composite contient plus d'un élément de données constitutif. Cet élément est utilisé pour des objets contenant plusieurs informations, comme par exemple une adresse.

Le code d’un élément de données constitutif commencera par « X ». Le code d’un élément de données composite commencera par « C ». 

Exemple :  Composition de l’élément de données composite C001 – Adresse

• X002 – Rue
• X003 – Numéro de maison
• X004 – Numéro de boîte
• X005 – Indicateur du type de la boîte
• X088 – Extension de l’adresse
• X089 – Identifiant du format de l’adresse
• X099 – Agence/standard utilisé pour le format de l’adresse (Dedale, bpost, Google…)

Il n'y aura pas de séparateur d'éléments après le dernier élément de données, qu’il soit constitutif ou pas.

3.3. Composition d’un message

Le message Telebib2 est composé par tous les éléments cités ci-dessus.

4. Documentation EDIFACT de TELEBIB2

La documentation du standard UN/EDIFACT de la norme TELEBIB2 comporte deux principales sections : 

• Les annuaires des objets
• Les Message Implementation Guides (MIG)

4.1. Les annuaires

Les répertoires fournissent une description détaillée pour chaque objet de la norme TELEBIB2. Ils sont structurés par type d’objet : 

• Les unités d’échange
• Les groupes de segments
• Les segments
• Les éléments de données composite
• Les éléments de données constitutifs
• Les qualifiants et code lists

Le TELEBIB et les répertoires mentionnés ci-dessus sont disponibles également sous la forme d'une structure de base de données relationnelle ACCESS MySQL.

4.2. Les Messages Implementation Guides (MIG)

Le Message Implementation Guide (MIG) donne une vue structurelle de la composition d’un message TELEBIB2.

Il reprend, message par message, de façon fonctionnelle l’ensemble des objets (unité d’échange, rubrique, segment…) l’ensemble du contenu.

La documentation des MIGs est divisée en 4 grandes sections : 

• Contrats : Information des messages contrats ainsi que les objets qui vont être inclus dans ces messages (objets de risque, garanties, franchises)
• Sinistres : Information des messages liés à l’activité de sinistre
• Echanges financiers : Information des messages liés aux quittances, avis d’échéances et extraits de comptes
• Echange contextuel : Tous les messages utilisés dans le cadre de l’échange contextuel (incl. Broker Entry Point et Broker Bridge) 

A l’inverse des répertoires qui fournissent l’information sous forme de listes, le MIG offre à l’utilisateur une représentation plus visuelle et structurée de l’information.