A005-预算下达与监控的故事

今天，终于把《预算下达与监控BADI需求说明书》完成，趁热打铁缝一针，做个总结。

开场白

下达和监控，是用户最近新增的需求，7张下达表(其中一张是检查表，供报表单位检查是否达到集团下达的经营指标要求)，6张监控表。

这里要总结的重点是：6张监控表和这张检查表相关的逻辑计算设计的演化过程。

序幕

下达表，把集团的预算要求，下达到关注的100多家单位(包括部分关注的单体公司)，这是预算一下版；报表单位根据这个要求，做出一上版的预算；

一下版和一上版的数据进行对比，算出得分，通过得分，集团可大概得知预算上报情况。

正片

乍一看，不算复杂，有个两周搞定。

于是，一位同事开发下达表，我开始着手表中计算逻辑的梳理与逻辑实现的设计。

一、报表逻辑说明不完善，让用户做了补充。

二、整体分析，计算主要分三大块:

预算数据是否达到集团下达的经营指标要求;

预算数据是否达到集团下达的管理要求(可量化部分);

正确性检查(例如资产=负债+所有者权益)

三、进一步具体工作

3.1计算所需科目编码的对照

把计算中用到的科目编码梳理出来(用户只提供报表格式及计算的文字逻辑描述，没有对应的科目编码，但是计算需要)，让用户确认，中间消耗了不少时间。

总结: 如果意识到这是个消耗时间的活，应该尽早明确提出整个过程安排及时间消耗，否则，时间意识上的不统一，用户不觉得需要多少时间，导致误会。

3.2梳理存储计算结果所需的主数据

报表上展现的通过计算才能获得的数据，需要存储（有些计算需要在此结果上，继续计算，所谓联动计算），这块工作不是一蹴而就，需要随着逻辑往下推理而发现；

随着需求逐步细化，总共增加了三次主数据，这块梳理工作也比较耗时间，需要写在工作安排上，起码告知用户会消耗大概多少时间，让用户有个心理准备，否则，用户也会认为这不需要耗太多时间。

总结: 这个梳理需要梳理出数据存储方案，存储方案包括：是否与同一年度的下一版本数据存储冲突，是否与下一年度数据存储冲突，方案是否具有扩展性。

完善的方案，需要基于至少三次的前后推演，方能基本确定，需要时间，严重的情况，可能会推倒重来，所以，时间上别估计不足。

3.3 逻辑怎么实现，BADI还是EXCEL，这是个问题

共计400多家报表单位，用户坚持通过EXCEL进行该计算过程；

根据我们的分析，数据需要进行多层次计算，

i.       先算出三大块是否符合要求（每个计算取数方式及算法都不相同），给用户展现一种报表；

ii.       然后再根据每块的结果，出个总表；

iii.       最后再根据每块的总表、评分规则，出个总的评分表。

考虑到EXCEL实现的复杂性和时间不可控性，计算效率问题，我们选择了BADI来处理。为此，用户各方面确认我们选择的合理性，最终同意我们的选择。

3.4 BADI需求说明书的书写

原计划下达表一周时间，按时完成。

监控表一周时间，按时完成，写了90多页的BADI需求说明书；用户看了后，觉得写得很详细，予以认可。

可是当我第三周走进办公室，听同事聊一个测试问题的时候，忽然意识到如果数据来自三大报表，合并单位需要从相应的合并报表取数；经过与用户确认，确实如此！

之前聊需求的时候，没有信息说明这个需求，当时考虑重点是计算逻辑（不完善的地方，让用户做了补充）和存储的实现，取数方面的逻辑考虑的少，疏漏了。

没啥说的，发现了更细节的逻辑，补吧。

由于合并报表和单体报表取数维值搭配不同，所以，经过梳理、比较，重新整理需求说明书，加上安排的其他任务，一周又过去了，用户抱怨怎么还没有完成！于是，进行了解释，由于之前双方确实没有谈过取数问题，而且取数问题也是我在其他需求梳理完成后，再次思考时发现的，所以，用户也同意继续修改，但是仍认为不需要太久时间，其实修改比新作短不了多少时间，不想解释了，完成为重。

3.5 与ABAP的沟通

用户安排了公司做运维的ABAP来进行BADI的开发，ABAP之前1-2个月刚接触BPC开发，开发过几个季度预算的BADI，算是比较快上手。

但是，之前的开发只涉及对逻辑脚本传过来的数据的处理，没有涉及对父级节点取数的技术，经过跟ABAP确认，确实不知道这一技术的用法，于是协调资深同事寻找之前项目上该方面资料，于第二周的周一交给ABAP,ABAP没看懂，一方面版本不同（2014年的项目资料），另外一方面，ABAP接触BPC不久，找到的资料有些复杂，于是用户向SAP提交MESSAGE，获得比较直接的答复：1个函数名，两个ABAP经过几天的时间，根据SAP提供函数，实现了任何维值搭配取值的方法，值得点赞！

鉴于这种方法，就不再需要逻辑脚本提供数据，通过函数直接获取自己需要的数据，效率更高，于是，再次进入文档修改，我倒是还可以接受，用户着急了，

怎么又要修改文档，啥时候是个头？！为此写了个说明给用户。

赶工了1天，完成了一部分，赶紧交给ABAP开发；

用户有急需，安排了年度预算报表修改，于是停下手头工作，投入报表修改工作，经过一周，完成报表修改工作，赶紧开始继续需求文档修改，因为ABAP开发进度，快赶上我的文档修改进度。

但是，用户又有急需，1.5天内完成另外的报表修改；

我选择了今天一整天完成BADI，并最终在晚上7点多完成了文档的修改，95页，这可是经过梳理多次之后的成果。

总结：新需求的技术实现，会遇到各种问题，技术的解决，需要时间；

          同时，解决方案也随着技术的进步而不断改进，简单说，又得改，

          所以，还是注意时间安排及跟用户的说明。

3.6特殊业务的处理

手工时代，下达表中有“0”要求和“无要求”的做法，BPC不允许混填，要么这一列是数字，要么是文字，具体总结可见公众号的A002号文章，关于该需求的解决方案之一。

关键问题是，经过这个总结，忽然意识到：这两点，虽然用户没有相关逻辑，但是我们得把它考虑进入逻辑，明天还得跟用户确认下关于这个的方案，然后，确认结果也得写入BADI计算过程中。

明天，继续修改BADI说明书；

逻辑，又完善了一步，人类就是这么进步的吗？

总结：新的、较为长的逻辑，需要经过多次迭代，才能逐步完善，无论自己，还是用户，都需要一个良好的心态。

 结尾

主干问题解决之后，接下来是很多细节的问题，需要不断完善。

（正文结束）

附1：关于本公众号

微信公众号ID：SAP-BPC

微信公众号名称：BPC123

欢迎您的关注和阅读，希望这篇文章能为您带来帮助。

欢迎转载与分享，也请注明出处。

如果您有需要了解的关于BPC的其他内容，也可以给我留言或发邮件（chaijw@126.com）

识别下面的二维码，或者直接搜BPC123，或者SAP-BPC，可以关注本公众号。