BizTalk的另一次捕获22，产生999
我问了另一个几乎相同的问题，A catch 22 in generating 999 file
基本上，我是插入HIPPA 837文件，并需要生成999响应文件。
今天，我在一个缺少ST02元素的文件中进行了绑定。使用接受状态创建的TA1，因为它只关心ISA级别，这部分很好。
BizTalk对文件进行了限制，发现了问题，并实际生成了999条消息，但它未能作为物理文件发送出去，原因是：
Unable to read the stream produced by the pipeline.
Details: Error: 1 (Field level error)
SegmentID: AK2
Position in TS: 3
Data Element ID: AK202
Position in Segment: 2
Data Value:
1: Mandatory data element missing 下面是catch 22:应该创建999来报告这个传入的837文件的错误，999的AK202是ST02中定义的传入文件的事务号的必需字段引用。传入文件的错误是它丢失了这个ST02。
现在，对于这个场景，它以BizTalk messageBox中的accept messageBox和pending结束。
在我们的贸易伙伴视图中，他们发送一个文件，并且只得到一个具有接受状态的TA1响应。
我的问题是: 1.报告这种错误(ST02缺失)的正确文件是TA1还是999？
- 是否存在绕过此错误并创建999的问题？
回答 1
Stack Overflow用户
发布于 2017-01-04 17:38:46
在x12.org：http://rfi.x12.org/Request/Details/55?stateViewModel=WPC.RFI.Models.ViewModels.RequestViewModel上有一个RFI。
TLDR版本:您应该拒绝整个功能组，并在AK202中使用来自功能组的控制标识符。
以下是相关案文：
描述 当错误与语法或min/max相关时，在997中报告ST02 (事务集控制编号)错误时，应该使用哪些段/数据元素？如果您试图用997的ST02中的AK202中的入站数据创建一个997返回给提交者，那么您将创建一个无效的997事务。在这一级别上报告错误的997标准可能存在差距。如果我们误解了交易的使用并且可以报告，请告诉我们怎么做。 响应 位于事务组997和事务集999中的数据元素AK102和AK202用于在被确认的功能组或事务集中传递控制编号的值。如果在997或999中包含数据元素值的副本将导致997或999中的语法违规，那么如果要在找到数据元素的级别报告违规行为，则必须在下一个更高级别报告。 Recommendation 官方对正式RFI的回应是来自ASC现任X12主席的一封信。这个网站经常显示RFI的摘要。单击此处查看此RFI的信件PDF。 当在对事务集进行语法分析后报告错误时，所分析的数据必须能够在确认中报告。虽然数据元素AK404支持报告不违反997语法的语法分析失败的数据元素的值，但同样的方法不适用于AK202。有两种公认的确认事务集的方法: 1)确认功能组中的所有事务集；2)只确认那些包含错误的事务集。如果错误中的事务集控制号不能在AK202中报告，则不建议接受有错误的函数组。对于请求中的示例，适当的操作是拒绝包含ST02值的整个函数组，该值在AK202中回显时会创建语法上无效的997。此外，同样的逻辑也适用于功能组控制号；适当的操作是拒绝包含语法无效数据的整个交换。
https://stackoverflow.com/questions/41366907
复制相似问题
腾讯云开发者
