BAPI_GOODSMVT_CREATE 具有多个材料编号和相同的 PP 订单?
据我所知,当您同时使用 BAPI_GOODSMVT_CREATE (通过循环或巧合)时,使用相同的材料编号会给您带来有关锁定对象的错误(材料 XXXX 被 USER YYYY 锁定)。
但是,据我所知,同时使用 BAPI_GOODSMVT_CREATE,但不同的物料编号与相同的生产订单不会出错。
问题
最近,当我尝试并行处理生产订单的 GI 时,在执行 BAPI_GOODSMVT_CREATE 时,发现有关 M3/897 的错误(物料 XXXX 的工厂数据被用户 XXXX 锁定),这将不同的物料编号放入同一生产订单中。
问题
所以,我问的是 BAPI_GOODSMVT_CREATE 的约束。
到目前为止我知道的是 -
A. 当您为不同的生产订单输入相同的物料编号时,您不能同时为生产订单(Mvt 261)签发 GI。
B.(我对此不太确定)当您为同一生产订单输入不同的物料编号时,您不能同时为生产订单(Mvt 261)签发 GI。
两者都对,还是只有A对?如果有经验丰富的 ABAPer 或 MM 顾问提供帮助,我们将不胜感激!
As I know of, When you're using BAPI_GOODSMVT_CREATE at the same time(by loop or just coincidence), Using same material number puts you an error about locked object (Material XXXX is locked by USER YYYY).
But, as i know of, using BAPI_GOODSMVT_CREATE at the same time, but different material number WITH same production order makes no error.
Issue
Recently I found an error about M3/897 (Plant Data of Material XXXX is locked by user XXXX) when I'm doing BAPI_GOODSMVT_CREATE when I'm trying GI for Production order, by parallel processing, which are putting different Material number to same production order.
Question
So, I'm asking about constraint of BAPI_GOODSMVT_CREATE.
So far I know is -
A. You can't issue GI for Production Order(Mvt 261) at the same time, when you're putting same material number for different production order.
B. (I'm not sure about this) You can't issue GI for Production Order(Mvt 261) at the same time, when you're putting different material number for same production order.
Is both is right, or just A is right? Any help from experienced ABAPer or MM consultant would be appreciated!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
要在循环中发布 GI,您需要在每次运行后进行提交,并显式解锁对象,否则您将获得 PP 锁。
尝试如下:
每次 BAPI 调用后始终使用带有 WAIT 参数的 BAPI_TRANSACTION_COMMIT 或带有相同参数的 COMMIT WORK。
此外,GR 和隐式 GI 运动也可能存在棘手问题,请参阅注释 369518
To post GI in a loop you need to make commit after each run, and unlock the object explicitly, otherwise you will get the PP lock.
Try like this:
Always use BAPI_TRANSACTION_COMMIT with WAIT parameter or COMMIT WORK with the same after each BAPI call.
Also there can be tricky issues with the GR and implicit GI movements, see the note 369518 about this.
您可以使用此 FM“ENQUE_READ2”在运行时检查现有锁是否存在。
数据:RAW_ENQ,如 LOCKSEDX_ENQ_TAB,
SUBRC 型 SY-SUBRC,
NUMBER类型I。
但是如果你必须防止GOODS mvt失败。一般来说,您必须实现一些重新处理逻辑来存储错误。
步骤是:捕获错误 -->存储 bapi 信息或标头文档编号 -->稍后重试
You can check the presence of existing lock at runtime using this FM - "ENQUE_READ2".
data: RAW_ENQ like LOCKSEDX_ENQ_TAB,
SUBRC type SY-SUBRC,
NUMBER type I.
But if you have to prevent a failure of GOODS mvt. in general you have instead to implement some reprocessing logic to store errors.
The steps would be : Catch errors --> store bapi information or header doc number --> retry later