前言:
归纳总结是个好习惯,我们都值得拥有.
每一个业务的开发需求,都是一次归纳的契机.
根据业务特定的需求分析,是否可以概括出一个通用需求?
特定业务需求是否完全包含在这个通用需求中呢?
是否可以根据这个通用需求概括出一个通用处理模型?
该模型是否可以解决这一类的业务需求?
怎么用特定的语言(ABAP)开发这个模型?
怎么给业务最大的自由度去使用这个配置使用这个模型?
如果你是一个业务人员,带着这些问题去和你的开发沟通.(你毛病呀,半天就可以写完的程序,你想整一周?)
如果你是一个开发人员,带着这些问题去和需求提出者沟通(你找事呀,按我的需求做就完事了,要不你来写功能说明书?)
或者,你也会碰到志同道合的. 嗯,这个提议不错, 咱们一起来完善一下这个设计.
尝试更多的去理解业务,去归纳业务,用开发的思想去重建功能设计.
正文
可配置增强
项目实施过程中往往都需要对标准逻辑实施一些增强功能.这些增强用于实现一些特定的功能:
跳过系统报错
实现用户自定义检查
设置字段默认值
触发系统功能执行
保存数据到自定义表
等等....
早期实现增强功能时,往往严格按照业务提交的功能说明书实现,后来逐渐调整为通过配置实现,再后来,优化配置方案,实现这一类的功能.
下面通过一个示例,呈现这个逻辑进化的过程
比如,业务提出需求:ZP01的采购订单需要检查商品状态MARA-MSTAE=40 时报错.
V1.0版本: 代码中写明 IF 订单类型=ZP01 . 读取商品状态, IF MARA-MSTAE = 40 . 报错.
V2.0 版本: 创建一个配置表,主键是订单类型. FLAG字段标记该订单类型要执行商品主档检查. 增强逻辑中读取配置表,如果存在FLAG标记, 则读取商品状态, IF MARA-MSTAE = 40. 报错
V2.1 版本: 在V2版本的基础上,配置表中添加一个消息类型. 用于控制是报错还是警告.
V2.2 版本: 在V2.1版本的基础上,配置表添加一个字段,存放 40 . 判断MARA-MSTAE= 该字段值. 报错或者警告.
V3.0 版本: 在V2.2版本的基础上, 配置表添加一个字段, 用于存放字段名MSTAE. 用于识别要检查的商品主数据字段. 动态读取商品的该字段内容后,与配置的值比较. 如果相同. 报错或者警告
V3.1版本: 在V3.0版本的基础上,配置表添加一个字段,用于存放要检查的表. 识别是商品表后,动态读取商品的特定字段,与配置值比较,如果相同,报错或者警告.
V3.2版本: 在V3.1版本的基础上, 再添加一些主键字段:比如采购组织,采购组等. 用于识别不同特性的单据.
经过上述逻辑的演变后,实现的功能也发生了一些变化
V1.0 实现了业务需求功能
V2.0 允许业务控制特定单据类型是否执行商品状态检查
V2.1 允许业务控制消息报错还是警告
V2.2 允许业务控制要检查的商品状态
V3.0 允许业务控制检查商品的特定属性与属性的值
V3.1 允许业务控制检查特定对象:商品或供应商的属性与数据的值
V3.2 允许业务控制特定单据的不同业务范围的检查规则.
最终这个增强的逻辑可能会变得很复杂, 但是它实现了这一类共性问题: 对采购订单执行特定对象的属性检查. 解决了这一类的需求.
对项目中的增强需求都按照上述过程处理,并且使用SIMGH 管理所有的配置项. 这样逐渐形成了一套类似SPRO的配置体系.
积累可配置增强是一个很有价值的事情. 通过这样的积累,逐渐形成一套配置体系,用于实现一些SAP标准配置没有考虑的功能. 其中一些有价值的增强配置点会陆续放到一个特定系列中去展开讨论.
SAP开发框架系列是我对开篇前言中问题的解答,这个系列提供的是一种思维方式,有些涉及到的代码/工具,会在后续文章中陆续发布.
如果你对这篇文章感兴趣,请帮忙转发分享, 并且勾选微信 <看一看>.文章右上角的按钮点击后,点击<在看>(或者文章末尾的右下角<在看>),即可. (如果你真的喜欢这篇文章,请记得回来打个赏,作为支持我继续下去的动力,这是一个正反馈过程. 越多的人打赏,作者越有动力分享,读者就能享受更多的福利. 毕竟打赏的金额富不了我,穷不了你,却能支持这个公众号长久发文.)
扫码关注公众号,获取更多好用的SAP应用程序
