起因

我们公司的销售订单，发货之后没人处理，就是没有完全发货的订单没有人去录入拒绝原因，最近营销部门的同事告诉我，说测试环境里有一个自开发程序可以批量的关闭销售订单，问我能不能把它传到正式环境里来，营销好酌情关闭历史订单，来释放客户的信贷风险额度。那天也不怎么的，反复和营销同事核实当时是否测试过之后，我还是说我需要测试一下再决定把它传不传到生产环境。

经过

程序不算长，七百多行的样子。在选择屏里除了查询条件之外还做了一些选项。根据用户选择的不同，处理流程还不一样，我承认这种方式已经超出我的设计思路了，不过看了后续代码呢，流程走向没有覆盖全部的组合的可能性，这里指定是需要完善的了。老实说，这问题是我写本文的时候刚发现的，那必然不是本文里我最想说的。

它的功能是根据选择屏的条件，筛选出来符合条件的、拒绝原因是空的、交货状态不是C的，销售订单明细，放到ALV中展示。关键功能是把用户在ALV中选中的那部份销售订单明细的拒绝原因设置成选择屏上选中的拒绝原因。

它用的方法是参照内表，去直接写的透明表，然后去记录了个日志。我把整段代码发给了DEEPSEEK，DEEPSEEK给出了一些优化建议。印象最深的是DEEPSEEK教了我一种办法，在程序里只写更新销售订单明细表VBAP的语句，把写日志的功能放到一个FUNNCTION里，在更新语句后调用这个方法并加上IN UPDATE TASK关键字，最后去执行去COMMIT WORK AND WAIT，保障数据的一致性等等好多技巧和方法。

把DEEPSEEK给出的修改建议中的我认为有必要修改的那一部份处理完之后，便开始对这程序进行测试，这时候发现了比较严重的问题。这种直接UPDATE VBAP透明表去设置拒绝原因的方法，并不会去影响信贷风险额度。人为用VA02去修改销售订单明细的拒绝原因的话，信贷风险额度是会随之变化的。显然大顾们说的是对的，直接更新透明表是极度危险的。后来DEEPSEEK是对应的修改销售订单的BAPI的，且同时说明了也同样不会去触发更新信贷风险额度，结合DEEPSEEK对直接操作透明表这事儿没有强烈反对，我决定不去改用BAPI处理销售订单明细，其实就是懒。老实讲，我对DEEPSEEK说的这一点是存疑的，其实是懒战胜了好奇，于是我决定在UPDATE VBAP之后，看看怎么样去更新一下信用额度。

经过了和DEEPSEEK，和豆包一番拉扯之后，找到了如下代码去更新销售订单所占用的信贷额度。

故事到这里还没完。加上这部份代码之后呢，会有这么一种冲突，当我打开一张销售订单的同时，用我写的程序去设置拒绝原因的时候，前半部份UPDATE VBAP的操作是允许执行的，但表1里的代码会报错说订单被占用，导致信贷额度更新失败。

于是我又回到了DEEPSEEK里，去找判断销售订单是否被占用的方法。DEEPSEEK告诉我一个叫ENQUEUE_READ的方法可以实现我的需求。起初给我的是图1里的这种用法，但没有实现我要的效果后，我又去请教DEEPSEEK，接下来又给了我第二种用法，依然没实现我要的效果。

现在回过头来看，图1里的代码没实现即定效果的原因是ls_vbeln处理的不对，没有加集团号。图2里的代码没实现即定效果的原因是在该传表名的参数gname里，传入了对象名。这些都是开发完回看的时候整理出来的。

正确的赋值是群里的大顾教我的，名字我就不提了，希望大顾也能看到我的文章。大顾不教我用SM12去查锁对象。

结果

首先感谢大顾，一句话解决了我和豆包、和DEEPSEEK撕扯了一天的问题。

其次呢，把整个开发过程中遇到的问题给记录下来，和小伙伴个做个分享，也给自己做个备查。

再次呢，我不是来告豆包、和DEEPSEEK的状的，它们是很好的工具，现在可以帮我解决大部份问题，但不是所有问题，还是需要有人去把方案代入、测试、修改等一系列的事儿，所以小伙伴们不必焦虑，用好工具就好了，人定胜天，何况一些好工具呢。

 这次就允许我水一篇吧，文笔不通顺，没有可以直接用的代码，仅仅就是想安慰一下自己和同样因为AI所焦虑的同行。就写到这儿吧，感谢小伙伴的耐心阅读。

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