SAP 交货单与 HU 指派关系数据不一致问题的解决方案
SAP 交货单与 HU 指派关系数据不一致问题的解决方案
我所在的项目是一个超大型的 Global SAP 项目,客户是一家跨国企业巨头,其 SAP 系统早已实施十几年了。除了 SAP 系统,客户还有其它各种外部系统,比如 WMS 系统等。
我的合作伙伴是一家印度的知名咨询公司,该公司有近乎 100 号印度人在这个项目上。客户这些年每年都有一些优化项目在做,我和这些印度同事们根据客户总部的安排,有需要实施的 SAP 优化项目就参与其中,没有优化项目需要实施就做运维。
近期客户总部以及乙方合作伙伴没有给我安排实施项目,所以我加入了有近乎 50 人的运维团队,主要解决客户业务团队提出的各种问题,为客户的业务部门保驾护航。该运维团队基本都是印度人,我和另外 2 个中国的 SAP 同行在运维团队里主要负责客户中国区工厂的运维支持。
近日接到了项目上用户提出的一个比较棘手的问题,让我纠结了几天。通过在项目上跟印度同事一起寻找解决方案,让我对于印度同行们有更多的了解。他们在项目上工作的专业技能和态度,他们的文档能力,都给笔者留下了比较深刻的印象。
如今问题已经解决,闲来无事写下这篇文字,做一个记录。
Part I:问题描述
客户美国公司的某个用户提出他需要删除一个外向交货单,无法删除,所以报了一个 TICKET 给到我们运维团队。我刚好手头没其它事,就主动接了这个 TICKET。
该外向交货单是一个公司间 STO 流程里的交货单,交货单因故需要删除。不过经过业务人员的一顿操作猛于虎,弄成的结果就是:该交货单相关的 Handling Unit 都已经被 un-assigned(解除分配)了,且这些 HU 都已经没有库存了,就是一些空的 HU 了,该批次号的库存在发货工厂里也没有了。
VL03N 显示该交货单,其 Pack 界面里,已经没有任何 HU 信息了,
![](https://static001.geekbang.org/infoq/0f/0fb54d4bedb0cc71d0e3c4221bbbcb94.png)
![](https://static001.geekbang.org/infoq/60/601f8a398e46a5aea3f5366fb6bc39ce.png)
但是因为操作不当等种种原因,导致该交货单的 document flow 里还是能看到这些 HU 号码信息。如下图示:
![](https://static001.geekbang.org/infoq/9b/9b54bfe5a0ca3201dc171a0d4e43bea7.png)
要想删除交货单,一定要将交货单里的 picked quantity 清零,且需要将已经相关的批次号删除掉。
但是因为交货单之前做拣配时候关联的 HU 解绑出问题了,凭证流表(VBFA)里还残留有数据。这使得业务人员无法将清空 picked quantity 以及批次号,系统会提醒说:Delivery still contains handling units.如下图示:
![](https://static001.geekbang.org/infoq/1e/1e893dfa06dabf1c3f02d2291a875fbe.png)
也就是说现在外向交互单,业务人员已经无法正常取消其拣配,无法将凭证流里的 HU 信息正常删除掉,所以就没有办法将该交货单正常删除了。
尼玛,一不小心接了一个烫手山芋!
Part II: 我的解决方案
接到这个 ticket,我第一反应就是这是一个由于业务人员操作不当或者数据库更新异常导致的疑难杂症,常规手段已经无法解决了。
所以我想到的解决方法是只能在 Debug 模式下将 VBFA 里该交货单相关的 HU 数据行删除掉,然后去修改交货单里的 picked quantity 以及清理批次号信息,然后就可以正常删除该交货单了。
Debug 改 SAP 表数据以解决很多疑难杂症,是很多 SAP 同行在万不得已的时候都会想到和用到的终极解决方案。这个方案是纯粹技术手段,并且是上不了台面的手段。当然这个解决方案对于解决类似由于业务人员操作失误或者数据库更新异常等导致的疑难杂症,是非常简单且快捷有效的!
这种手段这在很多民营企业的 SAP 项目里屡试不爽。不过以笔者参与的诸多大型跨国企业的 GLOBAL SAP 项目经历来看,Debug 改 SAP 表数据绝不是轻易可以做的事情。大型跨国企业里的 SAP 系统,对于权限控制极为严格。很多权限是不会开放给 IT 部门的,Debug 改 SAP 表数据的权限更是不可能轻易开放给运维团队的。
所以当我将自己想到的解决方案跟运维团队的相关负责人沟通,他们表示这种解决方案不是不可以,但是不推荐;只能在别无他法的时候才能考虑,并且需要客户的业务部门同意,客户总部 IT 老大以及运维部门老大审批,然后申请专门的 Firefighter 账号,才能去执行 Debug 改表。
看得出,项目上对于这种技术手段的控制是非常严格的,虽然没有一刀切的绝对禁止,但是设计了非常严谨而复杂的管控流程。我对此表示理解,毕竟客户是跨国大公司,做什么都要讲究合规,都有规范的流程。
Part III:印度人的解决方案
运维团队负责人在项目上干了很多年,很明显对于类似的疑难杂症有相关处理经验。他要求我所在的 DOMAIN 内其他几个印度同事也帮忙看看这个问题,以找出更为可行的解决方案。这让笔者挺欣慰的,技术上有疑难杂症可以在团队内部得到帮助和建议,这不就是 team work 么?
不通过 DEBUG 改表的方式能解决这个问题?我倒是想看看这些印度人到底有啥好办法。两天后,印度同事给出了方案,不过步骤很多,都是业务人员就能有权限执行的操作:
1)先通过 701 盘盈方式造出该物料批次的少量库存。毕竟该物料批次的库存已经没有了。
2)系统上的外向交互单的包装(Packing)是通过 SHPCON 这种 message type 的 IDoc 方式进行的。所以通过 WE19 复制其它 IDoc 的方式产生一个新的 SHPCON 类型的 IDoc,然后 reprocess 这个 IDoc, SAP 系统就能自动更新交货单的 Packing 信息,将凭证流里的 HU 信息自动更新(老的垃圾 HU 数据被清除,新的 HU 增加进去)。
3)正常手段对该交货单执行 unpack,删除 HU。
4)正常手段删除交货单。
5)最后执行 702 盘亏方式将第一步里造出的少量库存清除掉。
看完印度同事的解决方案,我表示很震惊,不能不对他们暗自佩服,居然还可以这么玩!不过他也表示,先让业务人员按照这个执行,如果不可行最后还得要 debug 删除表数据来解决。解决方案发给用户没多久,用户就反馈说按这个方案解决了问题,交货单已顺利删除!
至此,挂在我名下的这个 TICKET 可以关闭了,我也可以松口气儿。
-完-
写于 2023-1-13.
版权声明: 本文为 InfoQ 作者【SAP虾客】的原创文章。
原文链接:【http://xie.infoq.cn/article/f0c4aa726e9bbf86b46f58455】。文章转载请联系作者。
评论