介绍

实现的效果如下：

业务管理者可以根据年份，月份来查看的某个员工所产生的实际提成费用。提成费用由以下几部分构成：

个人直接创造的价值按一定比例提成
个人完成预定的个人目标按照达到的比例阶梯提成
个人所在团队完成团队目标按照达到的比例阶梯为团队成员提成
个人所在的中心门店完成门店总目标按照达到的比例阶梯为门店成员提成

这里面的额难点在于：

计算个人的提成收益，要考虑比个人粒度更粗的不同级别
不同级别达到的阶梯不同，对于个人获得的提成比例也就不同
对于 汇总行 的计算，很多DAX玩家应该不难会发现在很多业务中PowerBI对汇总行的计算默认逻辑与业务逻辑是不匹配的，本案例正说明如此
对于目标是按月来设置的，但在体现上由1月1日表示1月，必须使用用日粒度的数据来表示月粒度的数据

业务中的人员结构

在实际业务中

中心门店与团队与个人是逐级一对多的关系。

数据结构

本案例继续沿用DAX数据建模无侵入式设计风格，建模如下：

在后续的计算中，要通过员工来考察粗粒度业务实体团队以及更粗粒度业务实体门店，并同时兼顾对完成任务与目标的计算，进而最终在提成区间表中锁定各业务人员的额提成计算逻辑进行计算。

在细粒度筛选上下文计算粗粒度对象

考虑把成员这个相对于团队和门店更细粒度对象作为筛选上下文时如何获取团队或门店的筛选上下文，并在更宽的筛选上下文中计算多个成员的聚合。如下：

在报表环境中，负责人作为最细粒度的业务对象，如何获得比它更粗粒度的业务对象组或店，并计算相应的下面的所有的人的订单销售额。

比之更粗粒度的店所对应的销售额如下：

结合上面两个公式，可以看出：

VALUES：保持了筛选
ALL：忽略了筛选

做到这里，可以给自己一个奖赏了，因为这里很精准地用了保持筛选和忽略筛选，巧妙跳开了当前细粒度行（筛选上下文）的影响，而同时保持了粗粒度行（筛选上下文）的影响。这种设计完全巧妙了利用了CALCULATE的特性。

群里有个伙伴问，到底CALCULATE干嘛的，都可以拖拽出来的啊，什么时候要自定义计算，那本例给出一个很好的诠释。

提成参数表

学会使用 DAX参数表套路是一个小的里程碑，之前案例已经很多使用，本案例也会使用参数表，让模型保持动态可配置化。由于提成比例是按阶梯来的，参数表设计如下：

这里将直接提成（不分阶梯）以及个人、组、团队（分阶梯）的提成都设置了，里面用到了微弱的数字技巧，为了在实际计算时，将DAX动态筛选卡在确定的区间，并取出该区间对应的提成比例。如下：

该DAX表达式的业务逻辑很清晰，取出卡在某区间并且提成比例是个人类型的当前提成比例是多少再乘以完成额度即可。这里的巧妙在于：必须保证不管如何运算，一定有且仅有一个区间是可以能卡出来的。也就是说必须保证 存在性 和 唯一性。恰好，早就考虑到这些细节，因此处理的非常的当。然后将度量值拖拽进入，计算正确。

提成合计的计算

按照类似的思路，分别计算好直接的、个人的、团队的、店面的提成并求和即可，如下：

在模型的计算上，基本就完成了。

总计行的大陷阱你掉进来过了吗

不要高兴太早，当你开始使用时一切都是对的，直到你关注总计，似乎也是对的，直到你家财务意识到所有人的单人提成合计并不等于这里的总计值，问题出在哪里？如果不用财务提醒而能在写完DAX就自发发现这个陷阱的，那可以算是懂业务并且又可以DAX用来解决实际问题了。由于使用了自定义的CALCULATE，在行粒度的级别计算和汇总级别的计算是在完全不同的上下文进行的，结果当然不会是理所应当的正确，而是可能会出现难以察觉的问题。例如：