工作小记——佣金配置设计

好久没来写东西了，正好最近碰到个说大不大说小的需求，和大家分享下，如果有什么更好的方案也请告诉我

 

需求：

现在佣金为固定的。将来要针对不同的平台，不同的场景，不同的理财师角色，配置不同的佣金系数、发放形式

 

整体设计：

根据需求，最终决定将佣金配置分为三部分：基础佣金、活动佣金、转让佣金。同一份佣金计算及发放代码，循环三次。

转让佣金是全局控制，和基础佣金及活动佣金与标或项目有关不同，必须独立。

且不建议把基础佣金与活动佣金合并在一起。基础佣金调整频度很小，活动佣金会根据活动时间，活动情况调整，甚至同一天内不同标的佣金都不同，调整频繁。

如果合在一起，从记录的角度还是账务的角度，信息都不够清晰，会很混乱。拆分后，资金情况很清楚，这部分是基础佣金，这部分是活动佣金。

 

配置的修改的实现：

需求方希望，佣金配置的修改不影响已关联的标。

方案一：

在标信息的表中添加多个字段，记录当时的配置，记录每个角色对应的佣金。

方案二：

标相关表添加两个字段，存放配置id与配置版本号。在配置表中，id与“版本号”为联合主键，修改某规则后，新增版本号

方案三：

标相关表仅添加“配置id”字段。配置表不涉及版本号。当有标与该配置绑定时，该配置不可修改。可以直接添加

方案一明显是最不合适的。因为数据库中冗余数据太多，且不具有扩展性。增加角色的话，方案二，三只需改动配置表的表结果，而方案一缺需要改动标的表结构，不可取

最终选择方案三，因为从逻辑上说，使用版本号修改某个配置和新增配置没有本质区别，那就选用简单的方式。

不断新增，会不会导致发标时候，配置的下拉列表很长？不会，因为有配置停用的功能。停用后不在下拉列表中展示。

 

 转让配置的实现：

转让佣金配置，除了涉及各角色不同的佣金系数。还和转让产品的还款方式（一次性还本付息、等额本息）、可转让天数（30天可转、60天可转、90天可转）以及活动时间有关。

难点倒并不是在佣金的计算，而是在配置规则的添加。要保证不冲突，一个转让产品在计算佣金系数时，只有一条规则匹配成功。

方案一：

一个活动配置（比如30,60天可转的等额本息项目）在数据库中按多条存储，每行一个角色。优点：直接sql语句判断是否有规则冲突。缺点：配置编辑时可能还需要删数据，不方便（因为只有未使用，才容许编辑，所以可以直接删）

方案二：

一个活动配置在数据库中按一条存放。优点：编辑的时候可以避免删数据，而是直接updata。缺点：无法用sql语句直接判断，需查询出活动期间所有的现存规则，在应用程序中进行排查。

方案一、二都不是太理想，将两者合并一下，升级为

最终方案：

一个活动配置在数据库中按一条存放。可转天数以及还款方式分别以bitmap形式（假设30天可转为1,60天可转为2,90天可转为4，则全选的话，数据库中存7，和chmod是一个概念）存放在数据库字段中。添加新规则时，sql语句可写成：select count(1) from ... where 时间重叠 and 可转天数&new可转天数>0 and 发放形式&new发放形式>0。如果查询结果>0，说明有冲突，则不能添加。

最终方案又可以避免删除操作，也可以直接使用sql语句判断，而且位运算更快。为了处理方便，建议下拉列表中的选项不包括“全选”，可以添加“全选”按钮帮助全部选择，但是无需传给后台。另因为存在并发查询，插入，应用分布式锁来控制并发