点击蓝字 关注我们

归纳总结是个好习惯,我们都值得拥有.

 每一个业务的开发需求,都是一次归纳的契机.

• 根据业务特定的需求分析,是否可以概括出一个通用需求?

• 特定业务需求是否完全包含在这个通用需求中呢?

• 是否可以根据这个通用需求概括出一个通用处理模型?

• 该模型是否可以解决这一类的业务需求?

• 怎么用特定的语言(ABAP)开发这个模型?

• 怎么给业务最大的自由度去使用这个配置使用这个模型?

    如果你是一个业务人员,带着这些问题去和你的开发沟通.(你毛病呀,半天就可以写完的程序,你想整一周?)

    如果你是一个开发人员,带着这些问题去和需求提出者沟通(你找事呀,按我的需求做就完事了,要不你来写功能说明书?)

    或者,你也会碰到志同道合的. 嗯,这个提议不错, 咱们一起来完善一下这个设计.  

尝试更多的去理解业务,去归纳业务,用开发的思想去重建功能设计.  

本文主要介绍门店要货需求怎么通过需求管理平台配置及处理.

SAP标准零售解决方案的分配表功能在实际应用中存在各种问题,无法满足业务对门店补货的实际需求. 分析客户需求,整合并归纳门店要货的所有可能场景,结合系统功能, 开发了需求处理平台. 

用来处理复杂的门店要货业务. 允许在框架范围内配置系统的处理方式. 

门店要货需求按来源划分,大致有以下几类

• 门店主动发起的要货需求

• 仓库主配给门店

• 通过后台逻辑计算的门店要货需求,(/经过人工确认)

需求处理平台允许自行配置需求类型

物流模式从实物操作方式大致分为几种:

• 直送：供应商直接送货到门店；（不到仓库）

• 直通：供应商合并门店的需求送货到仓，仓库自己按照各个门店分货；（仓库0库存）

• 越库：供应商按照门店打包好送到仓库，仓库不上架直接发货到门店；（仓库0库存）

• 配送：这部分仓库备有库存，门店要货直接从仓库发货给到门店；

需求处理平台允许配置不同的物流模式,这些模式涵盖了上述的实物物流模式.

不同的处理模式确定了不同的处理流程, 确定了下述处理框架中的各节点流向. 需求处理程序根据处理模式确定要处理的单据. 

(通过物流模式,商品管理模式,档期信息)确定不同需求处理模式. 其中物流模式维护在MARC表中. 商品管理模式通过商品类目获取.档期信息来自需求本身

通过需求处理模式,供应商类别,需求类型组,需求类型 确定不同节点单据的类型,组织机构等重要的单据信息

需求日期配置,通过需求类型,商品关联模式,物流模式,隔日要货标记 确定到货天数 备货天数,在途天数等信息, 最终计算出需求到货日期

门店需求传到ECC系统后, 读取配置后给每个需求添加相应的特征(物流模式,需求处理模式,到货日期等)

然后根据处理模式,

通过不同的程序处理需求产生相应的后续单据. 

(相关单据之间存在内在的关联关系,程序会读取这些关系,给出合适的处理).

需求处理平台尝试把门店要货需求处理的各个方面整合到在一个框架流程中. 通过配置实现不同的单据流向. 

从而解决门店要货需求的不同的业务处理要求.

项目实践中, 满足了客户对门店要货需求的处理要求, 并预留了一定的扩展性.

约定