5010 278 EDI中的意外段 - 无法通过架构更改修复NM1段 [英] Unexpected Segment in 5010 278 EDI -- Cannot fix NM1 segment via schema change

查看:107
本文介绍了5010 278 EDI中的意外段 - 无法通过架构更改修复NM1段的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,

我在解析5010 278文件时遇到意外的段错误,如下所示: 

I am getting an unexpected segment error during parsing of my 5010 278 file, as follows: 

组件"未知"的输出消息。在接收管道中"WellMed.TruCare.Pipelines.Receive5010EDI,WellMed.TruCare.5010.Pipelines,Version = 1.0.0.0,Culture = neutral,PublicKeyToken = 82ab535ea96e65d6"由于以下
错误而暂停:     

An output message of the component "Unknown " in receive pipeline "WellMed.TruCare.Pipelines.Receive5010EDI, WellMed.TruCare.5010.Pipelines, Version=1.0.0.0, Culture=neutral, PublicKeyToken=82ab535ea96e65d6" is suspended due to the following error:     

Error encountered during parsing. The X12 transaction set with id '0001' contained in functional group with id '719088611', in interchange with id '000000044', with sender id 'ID1234567890   ', receiver id 'ID0987654321   ' is being suspended with following errors:
Error: 1 (Segment level error)
                SegmentID: NM1
                Position in TS: 23
                2: Unexpected segment.
The sequence number of the suspended message is 1.

这是我正在加载的EDI文件的图像:

Here is an image of the EDI file I am loading:

这是一个错误解析的NM1段XML的图像:

Here is an image of the incorrectly parsed NM1 segment XML:

NM1段实际上并不意外,因为它是应该是2010FA NM1段 - 当请求提供商与服务提供商不同时使用。但是,由于NM101字段为'1P',因此在解析期间,BizTalk似乎认为
属于UMO NM1段。

The NM1 segment isn't actually unexpected, as it is supposed to be the 2010FA NM1 segment -- which is used when the Requesting Provider is different from the Servicing Provider. However, since the NM101 field is '1P', during parsing, BizTalk seems to think it belongs to the UMO NM1 segment.

如果查看5010 278实施指南(或在模式本身),您将看到2010P段下没有列出'1P',而是在2010A UMO NM1段下。因此,解析器正在绊倒是有道理的。事实上,当我尝试
来弄清楚为什么'1P'不起作用时,我尝试了一个有效枚举的2010FA NM101值,'SJ',并且EDI文件解析得非常好。

If you look at the 5010 278 Implementation Guide (or at the schema itself), you will see that '1P' is not enumerated under the 2010FA segment, but under the 2010A UMO NM1 segment. So, it makes sense that the parser is tripping up. In fact, when I was trying to figure out why '1P' wasn't working, I tried one of the valid enumerated 2010FA NM101 values, 'SJ', and the EDI file parsed perfectly fine.

但是,当我尝试将"1P"添加到枚举值列表中时,解析仍然失败。我甚至删除了所有枚举约束,但我仍然得到相同的意外段错误。

However, when I attempted to add '1P' to the list of enumerated values, parsing continued to fail. I even went so far as to remove all enumeration constraints, but I still get the same unexpected segment error.

有没有人知道如何修改架构(或做其他事情,除了关闭验证)所以这些类型的消息在解析过程中不会失败?我有点紧张,这种类型的错误占我的门诊
授权的绝大部分。

Does anyone know how I can modify the schema (or do something else, other than turning off validation) so these types of messages do not fail during parsing? I am in a bit of a crunch, and this type of error accounts for a large majority of my outpatient authorizations.

非常感谢!

Josh

使用:BizTalk Server 2010  

Using: BizTalk Server 2010 

推荐答案

您的X12输入文件似乎很完美。

Your X12 input file is seems pefect.

尝试根据模式验证实例。

Try to validate the instance against the schema.

/ Dhiraj


这篇关于5010 278 EDI中的意外段 - 无法通过架构更改修复NM1段的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆