背景：

之前上一个项目上有同事碰到一个问题，外围接口数据进入SAP，可能会对同一工单同一工序进行连续多次报工，并且工序控制码配置的是会自动货物移动的，所以正常来说，调用完BAPI完之后除了报工数量会更新之外，还会自动收货产生一条物料凭证，当时的问题是，按照正常方式在接口中连续调用BAPI之后，发现报工的数量正常更新了，但是MIGO物料凭证并没有正常产生，比如报工了5次，每次数量是1000，最终报工数量正常，但是收货只有1000，其他的4000进了COGI，查看报错消息会发现是账号锁定问题，当时项目上同事采用了wait up to xxx seconds的方式进行解决，但这个方式是解决异步提交延迟问题最不建议的一种方式，在大批量数据处理中很浪费时间，所以最近抽空调查了一下这个问题的解决方向。

调查过程：

通过一些标准note的解释可以了解到，报工中涉及货物移动的处理是有单独的更新进程去触发的，而且是异步更新，所以即使在调用完BAPI_PRODORDCONF_CREATE_TT之后使用BAPI_TRANSACTION_COMMIT并附加WAIT参数去提交，也可能会出现因为货物移动没有处理完成而导致锁没有释放，从而产生COGI记录。

针对note中提到的将OPK4中的“自动售货”、“反冲”、“实际成本”都设置为“立即联机”，在系统中经过测试也确实并不能解决这个问题。

针对这种异步提交导致锁定，从而产生COGI的问题，官方note给出的解决方案如下，执行程序CORUPROC进行处理，如果要基于订单和工厂去处理，可以实施note:1008686。

场景还原：

初始状态：

模拟针对同一个订单同一道工序连续报工5次，每次报工1000个：

执行结果：

可以看到，虽然报工都成功了，AFRU表也成功更新了报工数量，但是货物移动只成功过账了1000，其余4000都由于锁定问题进了COGI，这种情况可以手工COGI重新执行进行处理，也可以调用程序CORUPROC进行处理：

虽然可以在报工完成后调用CORUPROC去处理COGI的问题，但是异步更新仍然有可能会导致BAPI_PRODORDCONF_CREATE_TT直接报错：

所以除了wait的方式是否有其他方式解决该问题？有。

解决方案：

通过多次的debug及尝试，发现如下两处地方的参数可以控制货物移动以同步提交的方式完成：

增强点1：

增强点2：

测试验证：

以上，问题解决，不会再出现锁定问题导致的COGI。

补充：

绝大部分BAPI异步提交的问题根本原因都是因为内部有COMMIT WORK语句（没有附加 AND WAIT），部分BAPI会有类似NO_COMMIT或者COMMIT_AND_WAIT等类似的参数来控制是否内部提交，或者内部以同步更新方式提交，所以很多时候需要同步提交处理BAPI的时候，不妨查看源码，看是否可以通过这些参数来避免内部以异步方式提交，因为如果在BAPI内部COMMIT WORK之后，外部再次使用BAPI_TRANSACTION_COMMIT(WAIT = 'X')或者COMMIT WORK AND WAIT是没有用的，所以我们只需要通过一些手段（比如增强，或者通过BAPI的控制参数）来避免BAPI内部进行异步提交即可解决这个问题，WAIT的方式并不推荐使用。

残留疑问：

虽然按照上述方式可以解决该问题，但我仍然没能说服自己为什么BAPI之后的COMMIT WORK AND WAIT为什么不起效果，因为更新进程被COMMIT WORK AND WAIT触发将会是以同步方式进行的，主流程中的锁会被带到V1更新进程中，当V1更新进程执行完毕会自动释放锁，虽然报工的BAPI会触发V2更新，但我单步跟踪过，V2的更新进程中并没有上锁的操作，按道理在BAPI之后同步提交应该不会有锁的存在，所以我仍然没能清晰准确的找到note中提到的单独的更新进程是在哪里触发的，可能调试过程中还是漏看了一些过程，等有空再仔细追踪一下。

Synchronous and Asynchronous Updating | SAP Help Portal

以上。