此文系笔者原创，首发于AZSAP第一课堂 https://mp.weixin.qq.com/s/9yuDJohp1iNRR-hHTyT9WQ
上半年，笔者刚刚加入某运维项目，就接到了该项目客户中国总部SAP运维部门负责人的工作分配，说是让我帮忙优化一只进销存报表，很可能是需要重新设计重新开发。
该项目是一个民营企业项目，几年前就已经上线了，目前处于运维阶段。民营企业的SAP项目有一个特点，你懂的，就是各种增强开发很多很多，以至于SAP系统主要被当作一个数据库来使用！很多标准的功能没有被使用，一些标准的function module也被封装了外壳然后在一些自定义的功能里被使用。像我这种没有参与前期实施的过程在项目运维几年后中途加入的外部顾问，进入这个项目立马就被安排这种对于历史遗留问题的优化任务，真有点掉入大坑两眼一抹黑的感觉。
怎么办？我来这里就是要帮助客户解决问题，为客户创造价值的，不是来喝茶聊天的。所以，虽然很难搞，也要迎难而上。
既然要优化报表，就得要了解现行报表的过去与现状。
笔者首先与客户的内部顾问了解了一下这个报表的一些情况。经过与内部顾问的沟通，得知该报表有2个硬伤，第一个硬伤是性能超级慢，基本不堪使用。我测试过了，发现查询日期范围，即使是昨天到今天2天，报表依旧会跑死，报ABAP Runtime Error。这确实不堪使用，让业务部门多难受啊！第二个硬伤是期末库存金额与财务科目余额表里的库存金额对不上。
然后就是要找到导致报表两大硬伤的原因。
据悉，性能慢是因为报表功能过于复杂以及超大的数据量。从报表第一版程序到现在，报表程序被改了无数次，增加了很多逻辑，功能越来越复杂。既要能按批次来查询进销存，还要能按照存储地点来查询；既要查询库存数量，还要计算金额，面积；而其面积的计算，又涉及到物料主数据和批次主数据里的分类视图数据；加上客户系统里的工厂代码超过40个，日积月累，货物移动方面的数据量巨大。笔者找了开发同事帮忙分析代码，发现其性能瓶颈之一在查询批次进销存数据的时候，耗时太多。
为了找到起初期末库存余额与科目余额表不一致的根本原因，我也找开同事帮忙一起分析代码。经查，该报表是采取倒推方式计算期初库存，其大致逻辑是首先拿到系统当前实时库存，然后计算当前日期与期末日期以及期初日期之间的货物移动数据，然后计算出期初期末库存数量与金额。同时我们发现，现行报表程序计算库存余额的时候，仅仅考虑到了货物移动带来的库存价值的变化，却未能考虑到非货物移动比如修改物料成本价，比如发票校验导致的库存价值的变化，这是导致库存余额跟科目表余额差异的原因。
找到了现行报表不堪使用的根本原因之后，笔者开始了报表优化的设计。
首先，我把报表功能进行裁剪，把查询粒度加大，不再支持按批次按存储地点级别的进销存查询，只在工厂级别出进销存报表。这样避免在大数据量以及逻辑复杂的情况下因查询粒度过细再次出现性能问题。当然这些建议需要得到业务团队的认可。客户业务团队因这个报表而受苦久矣，所以对于我提出的这个优化建议，对方欣然同意。
其次，我决定采用顺推方式得到期末余额，先根据MBEWH/MSEG/MKPF/BSIM表里抓取到期初余额，然后抓取查询日期范围内货物移动以及其它事务代码导致的库存变化数据，计算出期末余额。如果采用倒推方式，可能会出现性能问题，比如业务如果想查询2015-01-01 到2015-01-31 这个期间的进销存，倒推的方式需要得到当前（现在是2018年7月）库存，然后计算当前日期到2015-01-31 这段时间段范围内（三年多的时间范围）货物移动金额以及非货物移动库存金额差异，然后计算出期末余额，再计算期初余额，无疑这么做在数据量大的系统里还是会出现性能慢的问题。而采用顺推方式，则先计算出2015-01-01的期初余额，这个可以从一些表里直接抓取数据，然后查询一个很小时间段范围内的货物移动数据以及非货物移动库存金额差异数据就可以得到期初库存，然后查询到2015-01-01 到2015-01-31 这一个月时间段里的库存变化数据，得到2015-01-31这天的库存余额。这样报表程序需要查询的数据量明显减少，当然性能上要好一些。
最后，在计算期初期末余额的时候，要去BSIM表里抓取到非货物移动导致的库存价值变化的数据。笔者总结了，需要去BSIM表里抓取凭证类型为ML/PR/RE等的财务凭证里的金额，按借方和贷方汇总，计入指定查询日期范围内非货物移动的库存差异金额栏位，这个栏位参与计算期末余额。同时笔者上网查询资料得知，一些项目的进销存报表里，常常因为没有考虑到这BSIM表里这三种类型的财务凭证里的金额，导致进销存报表余额与科目余额表数据不一致，看来这是SAP项目实践中常见问题之一。
在这几个大的思路的指引下，开发出来的新的进销存报表，性能快到让业务人员喜出望外，与财务科目余额表的数据一致也让财务业务人员不再为进销存报表而痛心疾首了。
