我同意上述Werner的分析，（通常）有一个简单的原因-缺少[ 提交工作| http://help.sap.com/abapdocu_70/en /ABAPCOMMIT.htm ]（这是我到目前为止遇到的唯一原因）。 解释非常简单：如果您签入了合作伙伴配置文件立即发送并创建一个IDoc，则IDoc层将尝试在更新过程中发送IDoc。 如果没有COMMIT WORK，则永远不会触发用于发送IDoc的更新功能，并且IDoc的状态最终为03。

下次运行BD75（或程序[RBDMOIND | http://help.sap.com/saphelp_nw70/helpdata/en/0b/2a66af507d11d18ee90000e8366fc2/frameset.htm ]）），以便将IDoc状态从03转换为成功传输的IDoc的12，SAP将 检查出站RFC队列，但未找到任何内容（由于更新功能中缺少发送尝试），因此将IDoc状态从03更改为12（尽管SAP从未尝试发送过该事实，但是在此阶段，这是 不再知道）。

因此，在您发送SAP的系统中，一切看起来都很好，并且绝对没有迹象表明有任何问题。 这让我第一次遇到麻烦，因为我一直在与接收方争吵，他们必须已收到IDoc，并且一切在 我的发送方。 我错过的是，在不检查生成IDoc的代码的情况下，我不应该做出这样的粗体语句（在我的情况下，这是我之前从未见过的自定义代码）...????

将合作伙伴资料更改为收集IDocs 后，发送将不再在更新过程中触发，而是必须通过报告[RSEOUT00 | http://help.sap.com/saphelp_nw70/helpdata/ zh/0b/2a6613507d11d18ee90000e8366fc2/frameset.htm ]。 同样，WE19具有完全不同的COMMIT处理方式，这就是为什么我不喜欢在那里进行任何 real 测试的原因之一。

无论如何，现在我变得更聪明了，并且按照Werner的建议，我的清单包括分析生成IDoc的代码。 我可以想到的一个经典示例是通过更改指针成功发送部分而非全部IDoc，在这种情况下，COMMIT WORK通常很少执行（例如每20个IDoc）。 有时，其余IDoc的COMMIT WORK丢失了（例如，如果创建了23个IDoc，则在前20个IDoc之后执行COMMIT，但对其余3个IDOC不执行）。

对于那些感兴趣的人，请签出函数[EDI_OUTPUT_NEW | http://help.sap.com/SAPhelp_nw70/helpdata/zh-cn/dc/6b7ec743d711d1893e0000e8323c4f/frameset.htm ]（太好了，我们可以实际阅读SAP代码来了解发生了什么事情） -您会看到通过更新任务触发了发送过程（如果在合作伙伴资料中选中了立即发送）。 请注意，这意味着[数据库通过本机SQL或隐式提交| http ：//help.sap.com/abapdocu_70/zh-CN/ABENDB_COMMIT.htm ]不足以触发发送过程。

欢呼声，哈拉德

ps：而且，如果您没有任何自定义代码，则检查[OSS | https://service.sap.com/notes ]中可能引起此错误的任何错误。 例如，请参见[OSS注释1501225-偶尔不会发送生成的IDOC | https ：//service.sap.com/sap/support/notes/1501225 ]用于非常具体的组件BW-BCT-ISR-PIP（尽管遗憾的是，该注释并未说明是否确实存在/em>出站RFC队列中的条目）。