Identifiant

Taille

Description

AID

5 à 16

octets

Identifiant d’une application Valeurs prédéfinies :

AMC commune :

‘A000000291 D250 0800 9301’h

AMC spécifique, AID enregistré dans le registre centralisé: ‘A000000291 D250 0800 93F0 DXYZ’h, avec ‘XYZ’h = valeur de

ServiceScopeID pour cette application

Numéro de série Calypso

8 octets

Numéro d’identification d’une application Calypso

ServiceScopeID

12 bits

Identifiant de périmètre de service de l’application, pour la France : ‘XYZ’h Enregistré dans le registre centralisé pour toutes les AMC

Pour l’AMC commune : ‘E00’h

IssuerReference

2 octets

Référence d’émetteur d’AMC (ou de données d’AMC) Enregistré dans le du registre centralisé pour tous les émetteurs, indépendamment des périmètres de service (ServiceScopeID)

GDIssuerReference

2 octets

Référence de l’émetteur de l’application

Valeur issue du registre des émetteurs (IssuerReference)

GDScopeID

3 octets

Identifiant international de périmètre de service de l’application Valeurs prédéfinies :

Pour la France :                      ‘250XYZ’h, avec ‘XYZ’h = valeur de ServiceScopeID pour cette application

Pour l’AMC commune :         ‘250E00’h

HolderIssuerReference

2 octets

Référence de l’émetteur de l’application (identique à GDIssuerReference)

PictInfoIssuerReference

2 octets

Référence de l’émetteur de la photographie

Valeur issue du registre des émetteurs (IssuerReference)

NameInfoIssuerReference

2 octets

Référence de l’émetteur du nom et prénom

Valeur issue du registre des émetteurs (IssuerReference)

PIDIssuerReference

2 octets

Référence de l’émetteur des identifiants prédéfinis  Valeur issue du registre des émetteurs (IssuerReference)

PIDScopeID

3 octets

Identifiant international de périmètre de service de l’application (identique à GDScopeID) 


Il est suggéré de choisir  la structure  qui a le plus de chances de répondre aux besoins du projet. Quand ces besoins sont  peu définis, le meilleur moyen d'y répondre est de prévoir le maximum, donc la structure la plus riche qui peut tenir dans l’espace disponible de la carte prévue.
Cela donne, par taille décroissante approximative :

  • Structure 83h (≈6k octets) : avec les fichiers pour la photographie et pour les données propriétaires.
  • Structure 82h (≈5k octets) : avec les fichiers pour la photographie, mais sans les fichiers pour les données propriétaires.
  • Structure D1h (≈2k octets) : avec les fichiers pour les données propriétaires, mais sans les fichiers pour la photographie.
  • Structure D0h (≈1k octets), en dernier recours : sans les fichiers pour la photographie ni pour les données propriétaires.

Rappels :

  • Les données propriétaires sont les identifiants personnalisés, ainsi que des contrats / compteurs / évènements.
  • Les fichiers permettant le stockage du nom, du prénom et de la date de naissance sont toujours présents dans ces structures.
  • Les tailles effectives dépendent de chaque produit.
  • L'utilisation d'une structure de données archaïque (C0h, C1h, 81h ou 82h) est déconseillée.

Global Data et Predefined IDs. C’est le minimum nécessaire pour que la norme soit utilisable. Ensuite, si on a une structure 81h ou C1h intégrant les données personnelles, il peut être intéressant de tout de suite inscrire ces données personnelles  si on les connaît (mais cela peut aussi relever d’une personnalisation ultérieure).


L'ADCET suggére une règle simple: (LID d’un fichier) = (LID du DF AMG) + (SFI)

Par exemple, si le DF de l'application  a un LID = 3100h :
- Global Data, qui a un SFI = 17h, aura le LID 3117h
- Predefined Identifier, qui a un SFI=03h, aura le LID 3103h
- etc.