我不确定这里的SAP设计是什么（无法​​在此找到任何SAP Notes，并且FM文档也无法解释它），但我认为BMIT_PO_RESET_RELEASE是COMMIT附带的一个很好的理由。

很有可能必须先完成此特定操作，然后才能启动其他任何操作。 对于许多取消类型的任务来说都是如此。 我敢打赌，有一些代码正在数据库中检查当前PO状态是什么，如果已发布，则会应用一些业务逻辑。 因此，除非该PO真正是"未发布"的，否则其他BAPI都将无法对其进行任何处理。

这只是我的猜测，但我相信您必须在程序中解决此问题。

如果您说"如果有一个 "在BAPI_PO_RESET_RELEASE内'提交工作'"，因为如果您需要执行以下操作，则无法回滚数据库更新...如果要更改此行为，则需要修改标准...我看不到任何其他解决方案 。 或者，您应该实施自定义恢复系统，以识别哪些更新失败，手动分析和更正错误等。

通常，就像您说的那样，"后台任务"中的bapi将是 以相同的方式，它们都应该成功或失败，但是以上三个bapi不能，特别地，假设第一个bapi的成功和任何后一个bapi的失败，它不会回滚第一个bapi的更新，更多的是向 点，bapi'bapi_po_reset_release'里面有一个'commit work'，所以，我可以将它们捆绑成一个单独的luw吗？

对于调试，您可以使用最简单的数据，谢谢。

通常，就像您说的那样，"后台任务"的api处于相同的状态，并且所有 它们应该成功还是失败，但是上面的三个bapi不能，特别是，假设第一个bapi的成功和任何后一个bapi的失败，它不会回滚第一个bapi的更新，更重要的是，有一个"提交工作" '在bapi'bapi_po_reset_release'内，因此，我可以将它们捆绑成一条lu吗？

关于调试，可以使用最简单的数据，谢谢。

...........

如果您分析BAPI BAPI_PO_RESET_RELEASE的代码，则可以去除需要放入代码部分的逻辑。

BAPI中使用的主要FM是ME_REL_RESE。 尽管我没有研究过，但看起来它返回了EKKO上需要重新设置而需要更改的字段，而且看起来也没有提交到数据库。

建议您尝试一下ME_REL_RESET。