原创 无峰 [ ABAP 技巧与实战 ](javascript:void\(0\);)
归纳总结是个好习惯,我们都值得拥有.
每一个业务的开发需求,都是一次归纳的契机.
• 根据业务特定的需求分析,是否可以概括出一个通用需求?
• 特定业务需求是否完全包含在这个通用需求中呢?
• 是否 可以根据这个通用需求 概括出一个 通用处理 模型?
• 该模型是否 可以解决 这一类的业务需求 ?
• 怎么用特定的语言(ABAP)开发这个模型?
• 怎么给业务最大的自由度去使用这个配置使用这个模型?
如果你是一个业务人员,带着这些问题去和你的开发沟通.(你毛病呀,半天就可以写完的程序,你想整一周?)
如果你是一个开发人员,带着这些问题去和需求提出者沟通(你找事呀,按我的需求做就完事了,要不你来写功能说明书?)
或者,你也会碰到志同道合的. 嗯,这个提议不错, 咱们一起来完善一下这个设计.
尝试更多的去理解业务,去归纳业务,用开发的思想去重建功能设计.
**正文**
**** 列表-SAP零售版本的一个功能.
• 站在业务角度,它是一个商品分配到门店的过程,
• 站在技术角度,它是商品扩展视图的一种方式.(理论上,也可以关闭系统的列表功能,使用其它方式去扩展商品的视图)
使用过SAP 零售版本的可能都在上线过程碰到过这个问题:标准列表程序执行的实在是太慢了. 如果企业有1万个门店, 1百万个商品.
需要耗时多久?根据一组企业列表的真实数据预估. 大概需要15天-170天之间.
这个预估模型过于简单.假设按照最快的速度计算,需要15天,考虑纠错,差不多需要20天左右.
货号(款) | 商品数(变式商品) | 门店数 | 列表执行时间(秒) | 单位货号门店耗时(秒) | 预计耗时(天)
---|---|---|---|---|---
10,146 | 101,460 | 212 | 31,692 | 0.014733941 | 170.5317
13,566 | 135,660 | 213 | 8,138 | 0.002816348 | 32.59662
11,583 | 115,830 | 214 | 36,154 | 0.014585507 | 168.8137
13,680 | 136,800 | 215 | 44,240 | 0.01504148 | 174.0912
9,217 | 92,170 | 216 | 2,649 | 0.001330573 | 15.40015
_(备注:上图列表执行过程已经考虑了多进程并发执行,并且应用了绝大部分的NOTE中提供的优化方案)_
那么怎么能改进列表的速度呢?
1. SAP提供了一系列的NOTES.用于改进列表速度.但是效果都不太明显.究其原因:SAP是一个严谨的系统,所以在商品主档中存在很多的检查,验证逻辑. 这些逻辑是无法优化掉的, 所以列表性能始终无法有效改进.(升级HANA数据库对列表的改进也不明显).
2. 从业务角度,商品数无法减少, 减少门店数就是一个有效的方法. 把区域公司定义成门店, 门店定义为区域公司的库位. 这样做,大量减少了门店数. 间接解决了列表的问题. 但随之而来的是业务问题:移动平均价是按地点计算的. 这个方案导致区域中所有门店的成本完全一致. 并且与标准retail解决方案相悖,需要开发一系列的增强解决各种相关问题.
3. 还有一个思路就是改写列表逻辑,分析标准列表的结果.根据列表的结果涉及的表及写入的内容,自定义程序直接写表.
方案3看起来有点疯狂, 但是存在一定的合理性和可行性. 使用结果导向过程,再通过业务测试验证结果. 实际应用中, 也确实解决了列表的性能问题.
并且通过了盲测: 一组数据使用标准列表, 一组数据使用方案3列表. 在实际业务执行过程, 系统对两组数据表现为无差异.
SAP提供的标准列表功能很多,核心方式都是一样的.
• 门店分组(参考门店,门店分类)
• 商品分组(商品类目,模块中分配商品)
• 关联门店分组和商品分组
• 根据关联最终构造商品和门店的关系.
自定义列表功能中也使用了一组配置表,去关联商品+地点.用于辅助业务构造把商品分配到地点的规则.
SAP开发框架系列 是我 对开篇前言中问题 的解答 , 这个系列提供的 是 一种 思维方式,有些涉及到的代码/工具,会在后续文章中陆续发布.
如果你 对这篇文章感兴趣,请帮忙转发分享, 并且勾选微信 <看一看>.文章右上角的按钮点击后,点击<在看>(或者文章末尾的右下角<在看>),即可.
(如果你真的喜欢这篇文章,请记得回来打个赏,作为支持我继续下去的动力,这是一个正反馈过程. 越多的人打赏,作者越有动力分享,读者就能享受更多的福利.
毕竟打赏的金额富不了我,穷不了你,却能支持这个公众号长久发文.)
扫码关注公众号,获取更多好用的SAP应用程序