- 输入数据
- 订单明细（含退货与订单状态）、佣金规则表（人员类型、销售渠道、产品分类、阶梯区间、提成比率）、促销员主数据
- 核心方法
- 按促销员、月份、渠道、品类汇总净额，匹配人员类型对应的阶梯表，按全额法计算佣金
- 输出物
- 佣金明细清单（合格销售额、适用规则、比率、佣金金额）
促销员的佣金要按渠道分、按品类分、按阶梯算，还要扣掉退货、排除没收到款的订单。规则本身不难，难在每月几千条订单用表格拉一遍，一个环节漏了就算错，而算错的是直接发到人手里的钱。这个模型把规则固定成工作流，每月跑一遍几分钟出结果，每一笔都能追到是哪条规则、哪个阶梯算出来的。
适用场景
- 月度佣金核算：当月订单跑一遍，得到每人每渠道每品类的佣金明细与合计，直接作为发放依据。
- 政策调整试算：改一版规则表重跑，对比新旧政策下的佣金支出，再决定要不要调。
- 争议核查：员工对金额有异议时，按明细回溯到具体订单与适用规则，当场说清楚。
一笔退货是怎么改变佣金的
示例数据里有一个典型情况，能说明这个模型的价值在哪。
韩冰（P003），8 月，门店渠道、分类A
- 当月销售订单合计 125,000 元，按阶梯本该进 120,000 以上那一档，比率 4%，佣金 5,000 元
- 但当月有一笔 10,000 元的退货，冲减后合格销售额变成 115,000 元
- 落回第二档，比率 3%，佣金 3,450 元
两者相差 1,550 元。人工核算时，退货单往往和销售单分两张表，很容易只汇总销售、忘了冲减——而且这类错误偏向多发，不会有人主动来退。
同样容易出问题的还有三处：待收款的订单被当成已成交算了进去；金额正好等于阶梯下限时算错档位；某个渠道品类组合其实没有政策，却按邻近的规则给了佣金。这三种情况示例数据里都埋了，可以逐一核对。
输入数据要求
三张表：订单明细、佣金规则、促销员主数据。
| 表 | 字段 | 是否必需 | 说明 |
|---|---|---|---|
| 订单明细 | 订单号、订单日期 | 必需 | 日期取前七位作为统计月份 |
| 订单明细 | 促销员编码、销售渠道、产品分类 | 必需 | 汇总与匹配规则的维度 |
| 订单明细 | 销售金额 | 必需 | 退货填负数；待收款订单会被排除 |
| 订单明细 | 订单状态 | 必需 | 已收款、已退货、待收款 |
| 佣金规则 | 人员类型、销售渠道、产品分类 | 必需 | 三者共同决定用哪张阶梯表 |
| 佣金规则 | 阶梯下限、阶梯上限、提成比率 | 必需 | 下限含、上限不含 |
| 促销员 | 促销员编码、人员类型 | 必需 | 促销员与理货员比率不同 |
规则表要展开到具体的渠道与品类。不支持「全部渠道」这类通配写法——通配看着省事，但一旦出现多条规则同时命中，佣金会被算两遍。展开成明确的组合，宁可多几行。
计算方法
| 步骤 | 规则 |
|---|---|
| 有效订单 | 排除「待收款」；退货以负数参与汇总，当月冲减 |
| 汇总维度 | 促销员 + 月份 + 销售渠道 + 产品分类 |
| 规则匹配 | 按人员类型、渠道、品类找到对应阶梯表，再按合格销售额落档 |
| 阶梯算法 | 全额法：合格销售额 × 该档比率。不是超额累进 |
| 无规则组合 | 该组合不计佣金，也不报错 |
全额法意味着阶梯边界附近的金额差一点、佣金差很多。示例数据里两位促销员一个卖到 50,000 整、一个卖到 49,999.99，佣金相差 500 元。这是政策设计的固有特性，不是模型的问题，但值得在制定政策时想清楚。
工作流步骤
节点按 KNIME 英文名给出，iModel 中文界面的节点名以你所用的版本为准。示例数据已放在工作流内，导入后直接执行即可。
- 读取三张表CSV Reader
- 排除待收款Row Filter
- 取统计月份String Manipulation
- 按人、月、渠道、品类汇总净额GroupBy
- 关联人员类型Joiner
- 关联佣金规则Joiner
- 匹配阶梯区间Rule-based Row Filter
- 按比率计算佣金Math Formula
- 输出佣金明细CSV Writer
- 读取三张表CSV Reader
分别读取订单明细、佣金规则、促销员主数据；编码类字段设为文本，金额与比率保持数值。
- 排除待收款订单Rule-based Row Filter
规则：
NOT ($订单状态$ = "待收款") => TRUE。退货单保留，因为要靠它的负数冲减。 - 取统计月份String Manipulation
新增列「统计月份」：
substr($订单日期$, 0, 7) - 汇总合格销售额GroupBy
按「促销员编码、促销员姓名、统计月份、销售渠道、产品分类」分组，销售金额取 Sum。退货的负数在这一步自动冲减。
- 关联人员类型Joiner
与促销员主数据按「促销员编码」内连接，取出人员类型；右表重复的姓名与门店列在连接设置里排除。
- 关联佣金规则Joiner
与规则表按「人员类型、销售渠道、产品分类」内连接。没有对应规则的组合在这一步自然被去掉。
- 匹配阶梯区间Rule-based Row Filter
规则：
$阶梯下限$ <= $Sum(销售金额)$ AND $Sum(销售金额)$ < $阶梯上限$ => TRUE，下限含、上限不含。 - 计算佣金Math Formula
roundHalfUp($Sum(销售金额)$ * $提成比率$, 2) - 排序输出SorterCSV Writer
按促销员编码、渠道、品类排序后写出 result.csv。按人汇总可在此基础上再加一个分组节点。
参数
| 参数 | 默认值 | 作用 | 怎么调 |
|---|---|---|---|
| 佣金规则表 | commission_rules.csv | 全部阶梯与比率 | 政策调整时只改这张表，工作流不用动 |
| 排除状态 | 待收款 | 哪些订单不计入 | 按你们系统的状态值填写；预收款模式可能要改成别的口径 |
| 统计月份取法 | 订单日期前 7 位 | 按自然月核算 | 按财务月核算时改这一步的取值方式 |
用示例数据验证
运行后结果应与示例数据包里的 expected_result.csv 完全一致。
| 促销员 | 人员类型 | 渠道 / 品类 | 合格销售额 | 适用比率 | 佣金金额 |
|---|---|---|---|---|---|
| P001 林悦 | 促销员 | 抖音 / 分类A | 29,000.00 | 3% | 870.00 |
| P001 林悦 | 促销员 | 门店 / 分类A | 50,000.00 | 3% | 1,500.00 |
| P002 许诺 | 促销员 | 门店 / 分类A | 130,000.00 | 4% | 5,200.00 |
| P002 许诺 | 促销员 | 门店 / 分类B | 20,000.00 | 1.5% | 300.00 |
| P003 韩冰 | 促销员 | 门店 / 分类A | 115,000.00 | 3% | 3,450.00 |
| P004 马骁 | 理货员 | 门店 / 分类A | 60,000.00 | 1.5% | 900.00 |
| P005 罗佳 | 促销员 | 门店 / 分类A | 49,999.99 | 2% | 1,000.00 |
| P006 梁晨 | 理货员 | 门店 / 分类B | 55,000.00 | 0.8% | 440.00 |
按人汇总后：
| 促销员 | 人员类型 | 佣金合计 |
|---|---|---|
| P002 许诺 | 促销员 | 5,500.00 |
| P003 韩冰 | 促销员 | 3,450.00 |
| P001 林悦 | 促销员 | 2,370.00 |
| P005 罗佳 | 促销员 | 1,000.00 |
| P004 马骁 | 理货员 | 900.00 |
| P006 梁晨 | 理货员 | 440.00 |
三处边界与两处干扰都在数据里：50,000 整踩第二档下限、49,999.99 留在第一档、60,000 整进理货员第二档；韩冰的退货导致降档；某位促销员的抖音分类B 因没有对应规则不计佣金；一笔待收款订单不参与汇总。
适用边界
- 不含考勤、排班与津贴。加班补贴、高温补贴这类依赖考勤数据，需要先有考勤系统；本模型只做佣金这一段。
- 不含佣金账户与提现。余额、冻结、提现属于账户系统的职责，本模型输出的是应发金额。
- 跨月退货按订单日期归属。次月退上月的货，本模型计入次月冲减；若政策要求追溯调整上月，需在数据源先处理。
- 团队奖励与活动奖励未纳入。这类规则依赖团队结构和活动定义，建议单独建模后与本模型的结果合并。
常见问题
阶梯能改成超额累进吗？
可以，但结构要变：需要把每一档的销售额拆开分别计算再相加。做法是把规则表展开成「本档起始、本档比率、累计已算金额」的形式，用关联加多次计算实现。逻辑更复杂，建议在政策确定后单独做一版。
一个促销员同时服务多个门店怎么办？
在第 4 步的分组维度里加上门店编码即可，其余步骤不用改。如果政策是按门店分别计阶梯，这样处理正好；如果是合并计阶梯，就不要加。
订单数据在 CRM 里，能直接接吗？
把第 1 步换成数据库读取节点，查询出上表字段即可。退货单要一并取出并保证金额为负。
结果能直接发工资吗？
不能。这是佣金部分的应发金额，完整工资还包括底薪、津贴、社保与个税，需要与人力系统的数据合并后才能发放。
