2015-12-14 1 views
0

Je travaille sur un processus entrant BizTalk à des fichiers 837-p entrants provenant de différents partenaires commerciaux. Après le traitement du fichier entrant, je transfère également le fichier 999 généré automatiquement par BizTalk aux partenaires commerciaux en tant qu'accusé. Pour un partenaire commercial spécial, BizTalk entrante le fichier 837 et générant un fichier 999, tous les enregistrements de ce fichier sont "Acceptés" dans son segment AK9.BizTalk a généré le mauvais fichier 999?

Mais le processus de poursuite de ces enregistrements à partir du fichier indique que certains enregistrements ont effectivement échoué.

J'ai sauvé l'un des messages échoué en XML et validé avec le schéma 837-p fourni avec BizTalk, il fait échec à la validation avec l'erreur suivante:

error BEC2004: The element 'PRV_BillingProviderSpecialtyInformation' in namespace ' http://schemas.microsoft.com/BizTalk/EDI/X12/2006 ' has incomplete content. List of possible elements expected: 'PRV03_ProviderTaxonomyCode'.

La question est, si le dossier fait Echec de la validation du schéma, pourquoi le fichier 999 a-t-il été généré avec tous les enregistrements comme "Accepter"?

Quelques autres informations:

  1. La validation EDI est activée dans l'accord que partenaire commercial. J'ai vérifié deux fois que tous les paramètres d'accord correspondent au fichier entrant .

  2. Cette validation est en fait une validation HIPPA de niveau 2. Mais par document BizTalk, il devrait supporter la validation de niveau 2.

  3. La version BizTalk est BizTalk 2013 avec la mise à jour CU3.

+0

Où exactement a-t-il échoué en aval? Que faisait exactement l'application à ce stade? –

Répondre

1

Enfin comprendre. L'élément manquant se plaint BizTalk est en réalité détient un seul caractère d'espace. Il passe donc la validation entrante, mais le caractère espace est tronqué plus tard dans une orchestration. Ensuite, l'erreur est soulevée.