起因

前一阵子应营销部门的需要，检查了存在在测试系统里的自开发报表ZSDR012，把它进行了完善并上传到了生产系统，且授权给营销部门的用户去使用了。之前发生的事情详情请看前一篇文章《SAP-自开发的批量关闭销售订单》。

前一篇文章中介绍了ZSDR012里，前同事用更新透明表VBAP的字段ABGRU的方法来设置销售订单明细的拒绝原因。当时发现这种方法并不会同时去处理信贷的数据，需要用方法SD_ORDER_CREDIT_RECHECK去刷新信贷。但这个方法执行时，会去判断如销售订单锁定等必要的验证锁对象，于是更新透明表之前去补齐了一些验证。

本文主要是讲一下上线之后又发现了什么事儿及其处理过程。

首先，发现关闭的销售订单明细里的物料，在MD04里相对应的需求并没有去掉，所以要解决在关闭销售订单的同时，怎么去更新物料需。

其次，已经用现有程序关闭了的销售订单，相应物料的需求是错的，需要怎么处理。

经过

先搞“首先”，DEEPSEEK给我推荐了一个SAP自带的REPORT：SDRQCR21，只要按选择屏的格式传参数进去就可以。但可是，每一次处理都会弹出一个对话框在测试环境里还是可以接受的，反正不会用大量的数据去测试，但PRD里多久去处理一次就不受控了，需要把执行SDRQCR21的操作放在事务里才行。

然后再搞“其次”，有了处理“首先”的经验，我的思路是写一个FUNCTION，其功能借助在ZSDR012里记的日志，关联销售订单明细，存到内表里，我给内表取了个名叫gt_itab1，内表里存放销售订单号、销售订单行号、物料号、工厂、更新状态等，然后遍历内表，调用事务，执行SDRQCR21，很清晰的思路，技术上看起来也没有难点。开发过程也非常顺利。然而当我把它放到PRD里去执行的时候却出问题了。由于已经关闭了2万多条销售订单明细，程序里循环了2万多次，产生了2万多个事务，相应应该生成2万多个假脱机请求，程序执行没几分钟，其它打印程序报错了，大意是打印池已满了，看ST22，产生了若干的错误。先解决问题，关闭SAP GUI，重新登录，用事务码SP01，把当前用户今天产生的假脱机请求，先保障其它的打印功能可用。然后调整开发思路，去遍历内表gt_itab1，把其中凡是出现过的物料号、工厂号，一股脑的都塞进SDRQCR21的参数里，这样需要一个事务，执行一次SDRQCR21去更新所涉及的全部物料的需求即可。至于是否更新成功，那又得去遍历内表gt_itab，拿到每一个销售订单明细去检查透明表VBBE里有没有对应的记录。DEEPSEEK上说设置了拒绝原因的销售订单明细，在透明表VBBE里的记录是会被清除的，但这么说其实是不够准确的，如果这个销售订单明细存在着没过帐发货的外向交货单，是不会删除透明表VBBE里的相对应记录的，只会把几个数量字段做更新，销售订单明细不存在外向交货单的话，是会删除透明表VBBE里的相对应记录的。销售订单明细存在着已过帐发货的外向交货单的话，透明表VBBE里数据是怎么记的我没做测试，总之不能只判断在透明表VBBE里有没有记录，也要判断如果有记录但其OMENG字段为0的话，都要视为物料需求更新成功。做到这里，貌似我需要回去重写ZSDR012了。

结果

经过这十来天的和DEEPSEEK的人机交战，批量关闭销售订单的需求算告一段落了，可能完结了，但更可能还有后续。

这次开发涉及了好多知识点，包括怎么去刷新信贷、怎么去刷新物料需求，用事务的事候要注意优化，以免产生过多的假脱机请求导致堵满打印池等等等等。

但我得最重要的是，原来真是可以UPDATE透明表的，但后患真的是无穷的，上面处理的这一些，是不是在VA02里设置拒绝原因时需要做的全部事情，现在依然不清楚，如果有小伙伴们知道的，请不吝赐教，所以，能用BAPI解决的就别直接更新透明表。AI给的方案是需要去验证的，不能拿过来就用的。这里提到AI，并不是对它们的否定，只是希望它们越来越好，也是说明仍然需要普通人和AI之间的中间层，别焦虑。

好了，今天分享的内容就到这里了。用那句老掉牙的话收个尾吧，希望这篇文章对已经看到这儿的小伙伴们有所帮助。还是那句话，喜欢的小伙伴们请关注、点赞、评论。大家的鼓励是我持续创作的动力。感谢！