迭代循环丨 SUMX 函数（修订）

白茶在之前的一期，曾经分享过RANKX排名的问题，但是白茶当时犯了一个很严重的错误，这里和小伙伴们说一声抱歉。本期呢，既是纠正这个错误，也是学习另一个函数——迭代循环函数之SUMX。

这是白茶之前在做RANKX函数排名时的示例文件。可能有的小伙伴已经反应过来不对劲的地方了，就是总计！总计的数额显示的非常不合理，那么问题出在哪里呢？

小伙伴们仔细看，问题就出在这里。首先是单价和购买数量分处于两个不同的表格，但是当时白茶忽略了这个问题，脑袋中只有排名问题来着，现在来纠正这个错误。

首先就是这里的单价，是一个维度表，而数量是事实表，在这里我们要呈现的结果是根据两个表共同的列——[商品名称]来为数量匹配相对应的单价，一遍又一遍的循环匹配相乘，并且求和。这不就是迭代循环么？

果断请出SUMX函数！

这里和小伙伴们分享一下SUM与SUMX函数的区别。

SUM函数是一个单纯的聚合函数，它不知道啥玩意叫行，在他的眼里面只有列。按照切片器大哥的要求之后，进行汇总聚合。如果要是类似于[销售金额]这类已有的列名，可以用SUM进行聚合汇总。

SUMX函数是一个挑剔的函数，眼里面只有“行”，完全不考虑家庭感受的这种。当你告诉它要干啥的时候，首先的是告诉它，你要在“哪个表”中，告诉它对哪一行进行迭代。适用于[单价]*[数量]这种。

白茶也是挺无奈的。这里面，单价和数量并不是在同一个表中，我们还需要另一个函数配合——RELATED函数。

RELATED函数是啥作用呢？从其他表返回“相关值”，白茶在上面提到过，两个表唯一有直接联系的就是产品的ID，需要迭代筛选销售数量匹配单价，那这里用RELATED最恰当不过了。

编写如下代码：

销售金额 =
SUMX ( '销售明细', '销售明细'[销售数量] * RELATED ( '产品表'[销售价] ) )

这段代码是啥意思？在'销售明细表'中，对购买数量进行迭代循环，之后返回'产品表'中匹配相关的单价，进行乘法运算。结果如下：

传送门丨：PowerBI中的排名问题丨RANKX函数（修订）

小伙伴们❤GET了么？

白茶会不定期的分享一些函数卡片

（文件在知识星球[PowerBI丨需求圈]）

这里是白茶，一个PowerBI的初学者。

下面这个知识星球是针对有实际需求的小伙伴，有需要的请加入下面的知识星球。

请在PC端查看，有部分图片无法在移动端显示。
PowerBI丨白茶