华三第一部分.docVIP

第一部分：需求说明 一、背景 ?商务在进行业绩和利益计算时,面对如下挑战: 。计算基数来源分散,手工比例大，规则不够清晰。 。计算结果与政策依据关联性不直观，核算过程透明度低。 。例外事项、异常情况调整记录未保存，版本差异无法体现记录 。发布过程依靠邮件,缺乏统一的发布、存储及查询平台。 。缺乏有力的数据分析工具。 ?因此迫切的需要有一个统一的平台来进行业绩与利益的核算。 二、项目范围 ?打通公司发货数据（ERP、DMS）、渠道进销存数据（CBS）、商务基础数据（CDIP），统一核算基础数据来源。 ?在系统中保存各类业绩利益核算政策、调整备忘录和例外调整的依据，供稽核部门追溯。 ?根据各类业绩和利益核算政策及调整备忘录等，提供灵活的核算逻辑配置功能。 ?提供统一的业绩利益发布、存储及查寻平台,满足商务、渠道、销售管理、财务等部门的不同需求. 三、业绩核算总流程 ?每季度进行一次业绩核对工作，主要通过进销存的平衡来进行。 ?首先确认库存，然后确认salesin，最后通过进销存平衡报告确认salesout。在进销存都确认后，我司商务会输入手工调整项，最后输出最终业绩。 四、总代出货业绩奖励 五、总代促销奖励计算 六、总代保价计算 七、总代进货业绩奖励 八、差价补贴 九、二代返点计算 十、二代促销计算 第二部分：系统设计 一、总体功能 ?业绩核算功能 。包括CBS数据、手工数据、库存、salesin、Salesout ?利益核算功能 。我司对合作伙伴的利益核算政策是比较灵活的，因此在系统中不能将所有核算规则均固化下来，需要有灵活配置的功能。 。我们对我司的利益核算政策进行了分析，可以将其抽象为数据模型和规则模型。每一种利益计算用的基础数据(一般是业绩)可以看作数据模型的实例，而计算用到的规则(一般是政策)可以看作是规则模型的实例，规则作用于基础数据最后生成利益数据。 二、数据模型 三、规则模型 四、功能模块 五、权限控制 控制与设计约束 1、一种利益对应一个规则包，政策与以及描述与规则包关联。 2、规则包发布后，进入提交审核状态，此时规则包不能修改，直到审核人驳回或批准。 3、利益发布时采用本季度最新版本的规则包和基础数据重新运算写入正式表并覆盖本季度原利益数据。 4、利益审核完毕后，该季度利益即不能发布新的版本，直到该利益被失效。 5、开发人员可以执行规则也可以查看执行结果，但结果数据不会被写入正式表，仅作为测试参考。 控制方法 利益核算系统的权限控制分为两部分,业绩核算权限控制与利益核算权限控制. 业绩核算权限控制:基于CDIP原权限控制机制,可按程序模块和操作部门进行权限控制. 利益核算权限控制:采用基于规则包的权限控制机制,以规则包和针对规则包的操作进行二维权限控制. 对于规则包的操作有以下几种 创建,开发,查询,发布,审核,执行. 针对利益计算的结果操作有以下几种 发布利益，审核利益，失效利益 六、数据控制 业绩数据控制 1、业绩数据按计算期（一般是季度）和版本进行控制。任何业绩记录都必须包含版本号和计算期两个字段。 2、业绩记录的版本生成由业绩核算模块控制。 3、业绩数据若生成新的版本，则当期用到此业绩数据的利益结果将失效。 利益基础数据控制 1、业绩数据按计算期（一般是季度）进行控制。每个计算期仅保留一份数据，每次导入新的利益基础数据，将会覆盖该计算期的利益基础数据。 2、若利益基础数据重新导入，则当期用到此基础数据的利益结果的基础数据将失效。 规则数据控制 规则数据按版本和计算期进行控制，版本号由 “大版本.小版本”形式组成。 1、规则开发人员可对规则进行编辑和修改。也可打版本标记，打过版本标记的规则将被记入数据库。规则开发人员每次打版本标记则 小版本自动+1。 2、规则包审核通过后，大版本自动+1，小版本自动归0 3、规则包的计算期有规则开发人员设定，默认值为该规则包上一个版本的计算期。 第三部分：规则应用 一、权限控制 权限划分 二、功能描述 （一）权限管理模块 用户管理 管理用户基本信息，包含登陆名，用户姓名，所属部门，密码设置，拥有角色等信息。 角色管理 管