本主题介绍 BizTalk Server 中 EDI 确认的已知问题。
997 确认中的 AK102 可能是负值
X12 997 确认中的 AK102 数据元素（组控制编号）可以是负值。 包含负 AK102 数据元素的确认消息将通过 BizTalk Server 的验证，即便负值的组控制编号并无实际意义。
CONTRL 回执可能会在消息的一部分被拒绝时报告“已接受”状态。
CONTRL 收据（EDIFACT 技术确认）仅当传入的 EDIFACT 消息重复或信封中存在错误（例如字符集出现问题）时，才会报告状态为“已拒绝”。 EDIFACT 不会在 CONTRL 技术确认中报告“已接受但存在错误的交换”状态，而 X12 会在 TA1 确认的 TA104 字段中报告此状态。 如果接受 EDIFACT 消息的一部分，CONTRL 技术确认将报告“已接受”。 在某些情况下，部分消息将被拒绝，但 CONTRL 确认仍然会报告状态为“已接受”。 在这种情况下，UCI5 元素可能会报告错误。
当组标头或结束段出错时，X12 确认将显示接受的保留交换（出错时挂起交换）
如果 X12 消息的入站批处理选项设置为“保留交换 —— 出错时挂起交换”，并且组标头或尾部中的字段无效，则状态将在 TA1 和 997 确认中报告为“已接受”。 EDI 状态报告和事务集详细信息也将指示“已接受”状态。 尽管交换会暂停，事件查看器中仍会出现错误，指示交换已暂停。
TA1 确认将显示“已接受”状态，因为它旨在验证 ISA 标头和 IEA 预告片的正确性，但不验证 GS 标头和 GE 预告片的正确性。 但是，997 确认也会显示“已接受”状态。
如果交换中的组具有相同的名称，状态报告将显示两倍的确认数
如果 BizTalk Server 处理多个具有相同名称的组的 EDI 事务交换，EDI 事务交换和相关 ACK 状态报告会列出两倍于预期的功能确认。 例如，如果交换中的两个组具有相同的名称，则状态报告将列出四个确认，而不是两个。