SAP MM VL32N和MIGO对内向交货单做收货,都会更新其‘总体货物移动状态‘

本文探讨了一位同行在SAP系统中遇到的关于内向交货单收货的问题,即使用MIGO和VL32N事务代码进行收货操作后,'总体货物移动状态'字段更新不一致的情况。作者通过实测发现,在标准的S4HANA 1909系统中,无论是MIGO还是VL32N,都能正确更新该字段为C。此外,还对比了两种收货方式在凭证流和采购订单历史信息上的差异。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

SAP MM VL32N和MIGO对内向交货单做收货,都会更新其'总体货物移动状态'

近日某个同行告诉我说他所在项目的系统里,对于Inbound Delivery执行收货,如果是使用MIGO来执行收货的话,则Inbound Delivery里的‘总体货物移动状态’(OvrlGdsMvtStat) 栏位还是保持为A,如果是使用VL32N对Inbound Delivery做收货,则Inbound Delivery里的OvrlGdsMvtStat 栏位才会被更新为C。

笔者觉得很是奇怪。项目实践中,对于采购订单,一些项目里使用VL31N为采购订单创建了收货后执行收货,使用MIGO和VL32N来收,都是OK的,交货单里的‘总体货物移动状态’字段的更新都是一样的。笔者从未遇到过该同行提到的现象。

笔者认为这个现象应该是系统因性能等缘故偶尔出现的数据库更新异常而导致的极小概率事件。为了验证自己的想法,抽时间在一个S4HANA(1909)的标准系统上做了测试。

1, 比如如下采购订单,我事先创建了3个inbound delivery。

使用VL32N和MIGO对内向交货单做GR,都会更新'总体货物移动状态'

2, 使用不同方式对其中的2个inbound delivery执行收货。

对于内向交货单180000192使用事务代码MIGO + inbound delivery号码执行101收货。

对于内向交货单180000193使用事务代码VL32N执行收货。

然后观察这2个Inbound Delivery里的’OvrlGdsMvtStat’ (总体货物移动状态)栏位,都被自动更新为C。

内向交货单180000193,

使用VL32N和MIGO对内向交货单做GR,都会更新'总体货物移动状态'

内向交货单180000192,

使用VL32N和MIGO对内向交货单做GR,都会更新'总体货物移动状态'

3, 对内向交货单的2种不同收货的方式,也会有些不同。

3.1, 一个典型的不同就是inbound delivery的凭证流里的信息略有不同。

使用VL32N 做收货后的Inbound Delivery会出现picking request的记录,如下图,

使用VL32N和MIGO对内向交货单做GR,都会更新'总体货物移动状态'

使用MIGO对Inbound Delivery执行收货后的凭证流,则不会出现picking request的记录,

使用VL32N和MIGO对内向交货单做GR,都会更新'总体货物移动状态'

3.2, 还有一个不同的对方在于,采购订单历史里的数据略有差异。

对于VL32N做收货的Inbound Delivery,在采购订单历史里的101收货记录里能在Reference栏位里才能看到Inbound Delivery的号码。如下图。

使用VL32N和MIGO对内向交货单做GR,都会更新'总体货物移动状态'

-完-

写于2021-12-2

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值