Vérifications de validation spécifiques au standard
Ce chapitre fournit une information sur les vérifications de validation que MapForce réalise pour différents standards EDI. Pour les détails, voir les sous-sections ci-dessous.
Vérifications de validation pour UN/EDIFACT
Dépendant si le message UN/EDIFACT est standard ou interactif, MapForce réalise différentes vérifications de validation.
Messages standards EDIFACT
Quand vous validez des documents de mappage UN/EDIFACT, MapForce vérifie les points suivants :
•Si les segments UNB et UNZ existent
•Si UNB/S004 contient une spécification date/time valide
•Si UNB/0020 et UNZ/0020 contiennent la même valeur
•Si UNZ/0036 contient le nombre correct, qui est défini en tant que le nombre de groupes fonctionnels, le cas échéant, ou le nombre de messages. Si des groupes fonctionnels sont présents, cela devra être le nombre de groupes fonctionnels, sinon cela devra être le nombre de messages contenus dans l'échange.
Groupes fonctionnels
Pour chaque groupe fonctionnel, MapForce vérifie les points suivants :
•S'il contient une paire UNG et UNEUNG correspondante.
•Si UNG/S004 contient une spécification date/time valide
•Si UNE/00600 contient le nombre correcte de segments dans le message.
Messages
Pour chaque message, MapForce vérifie les points suivants :
•S'il contient une paire UNH et UNTUNG correspondante.
•Si UNH/S009/0052 a la même valeur que UNG/S008/0052 du groupe fonctionnel englobant
•Si UNH/0062 et UNT/0062 contiennent la même valeur
•Si UNH/S009/0065 contient le spécificateur de type de message correct.
•Si UNT/00600 contient le nombre correcte de segments dans le Segment.
Messages interactif EDIFACT
Les règles de validation suivantes s'appliquent aux composants qui contiennent des messages EDIFACT interactifs :
•Si UIB est présent, tous les segments UIH/S302 suivants doivent correspondre à UIB/S302
•UIH/S306/F0065 doivent contenir un type de message (validé par le parseur).
•UIH/S306/F0052 doit contenir le numéro de version de message qui est défini dans des fichiers de configuration sélectionnés.
•UIH/S306/F0054 doit contenir le numéro de publication de message qui est défini dans les fichiers de configuration sélectionnés.
•Si présent, UIT/F0340 devrait correspondre aux en-tête/trailer de message UIH/F0340 correspondants (champ optionnel).
•Si présent, UIT/F0074 doit contenir le compte de segment (champ optionnel).
•Si présent, UIZ/S302 doit correspondre à UIB/S302 (composite optionnel).
•Si présent, UIZ/F0036 doit contenir le compte de message (champ optionnel).
Vérifications de validation pour ASC X12
Quand vous validez des documents ASC X12, MapForce réalise les vérifications suivantes :
•Si les segments ISA et IEA existent
•Si ISA/I01 contient un qualificateur d'information d'autorisation légal.
•Si ISA/I03 contient un qualificateur d'information de sécurité légal.
•Si les deux segments ISA/I05 contiennent des qualificateurs ID d'échange légaux.
•Si ISA/I08 contient une valeur de date bien formée.
•Si ISA/I09 contient une valeur d'heure bien formée.
•Si ISA/I13 contient une valeur booléenne légale.
•Si ISA/I14 contient un indicateur d'utilisation d'échange légal.
•Si ISA/I12 et IEA/I12 contiennent la même valeur.
•Si IEA/I16 contient le nombre correct de groupes de fonction dans l'échange.
Groupes fonctionnels
Pour chaque groupe fonctionnel, MapForce vérifie les points suivants :
•Si une paire GS et GE correspondante existe.
•Si GS/373 contient une valeur de date bien formée.
•Si GS/337 contient une valeur d'heure bien formée.
•Si GS/28 et GE/28 contiennent la même valeur.
•Si GE/97 contient le nombre correct de messages contenus dans le groupe fonctionnel.
Messages
Pour chaque message, MapForce vérifie les points suivants :
•Si une paire ST et SE correspondante existe.
•Si ST/143 contient l'identifiant de message correct.
•Si ST/329 et SE/329 contiennent la même valeur
•Si SE/96 contient le nombre correcte de segments dans le message.
Vérifications de validation pour HIPAA X12
Les composants HIPAA sont semblables aux composants normaux ANSI X12. Les vérifications de validation sont réalisées de la même manière que pour la validation X12 (voir la sous-section ci-dessus). Les différences des messages X12 standard sont décrites ci-dessous :
•MapForce entretient automatiquement la hiérarchie des segments HL.
•MapForce prend en charge les structures soit-disant « flottantes » (dans 837 messages).
•MapForce remplit automatiquement et valide plus de champs.
Vérifications de validation pour NCPDP SCRIPT
Concernant les messages NCPDP SCRIPT, MapForce effectue les vérifications de validation suivantes :
•UIB/S001/F0001 doit être UNOA.
•UIB/S001/F0002 doit être 0.
•UIH/S306/F0329 doit contenir le type de message SCRIPT.
•UIH/S306/F0316 doit contenir le numéro de version de message qui est défini dans des fichiers de configuration sélectionnés.
•UIH/S306/F0318 doit contenir le numéro de publication de message qui est défini dans les fichiers de configuration sélectionnés.
•UIH/S306/F0326 doit contenir une fonction de message (ou du type de message dans la terminologie MapForce)
•Si présent, UIT/F0062 doit correspondre au segment UIH/F0062 correspondant.
•Si présent, UIT/F0074 doit contenir le compte de segment.
•Si présent, UIZ/F0036 doit contenir le compte de message.
TRADACOMS
Pour les fichiers TRADACOMS, MapForce réalise les vérifications de validation suivantes au cours du parsage ou de la génération du fichier :
1.Les segments STX (Start of Transmission) et END (End of Transmission) doivent exister.
2.Si STDS-1 a la valeur 'ANAA' un Message de Réconciliation (RSGRSG) doivent exister avant la fin de la transmission (END). Sinon, aucun Message de Réconciliation (RSGRSG) ne doit être présent.
3.Si STDS-1 a la valeur 'ANAA', alors :
a.La valeur de RSGA dans le Message de Réconciliation doit être égale à la valeur de SNRF dans le STX segment.
b.La valeur de RSGB dans le Message de Réconciliation doit être égale à la valeur de UNTO-1 dans le STX segment.
4.TRDT-1 doit contenir la date (YYMMDD) et TRDT-2 doit contenir l'heure (HHMMSS) de la transmission (date et heure actuels).
5.Si le Batch Header (BAT) est présent alors le Batch Trailer (EOB) doit aussi être présent, et le nombre de messages dans le batch doit être disponible dans l'élément de données NOLI (Number of Messages in Batch).
6.L'élément de données MSRF (Message Reference) dans le Message Header (MHD) doit contenir le décompte des messages consécutifs dans le cas de la transmission, en commençant avec 1.
7.L'élément de données NOSG (Number of Segments in Message) dans le Message Trailer (MTR) doit contenir le nombre de segments, y compris MHD et MTR.
8.Lorsqu'il est présent, le Message de Réconciliation (RSGRSG) doit consister en un segment (RSG), sauf pour le Message Header et le Message Trailer.
9.L'élément de données NMST (Number of Messages in Transmission) dans le segment END doit contenir le nombre de messages dans l'échange (décompte de segments MHD).
10.En général, lors de la lecture d'une structure TRADACOMS, MapForce prévoit que l'environnement d'échange est de type "ordinateur à ordinateur" (ou bien, dans la terminologie TRADACOMS, "terminal intelligent vers terminal intelligent"). C'est pourquoi un segment comme MHD = 12 + ORDHDR :3 déclencher une erreur de validation, étant donné qu'il contient des espaces de début et de fin.
11.Les données de string doivent être en majuscules. Lors de la génération de sorties TRADACOMS, MapForce convertit des données de string en majuscule.
Ces règles de validation font également que MapForce complète automatiquement les champs manquants au cours de la génération du fichier.