奖金方案与绩效激励操作说明

适用对象：商户管理员、店长、负责绩效核算和薪酬复核的人员

菜单入口：w/vision/performance/bonus/plans?ref=addtabs（奖金方案）

相关入口：w/vision/performance/bonus?ref=addtabs（奖金试算与结算）

一、这个功能解决什么问题

奖金方案用于把“岗位要求、绩效结果、销售提成、专项奖励和退款扣减规则”固定成可重复执行的结算规则。它不是一张只供查看的 JSON 配置，而是由方案主表、版本生效区间、奖金档位和可选奖金组件明细组成，管理员可以在页面上设置、编辑和复核。

建议把奖金方案作为门店经营制度的一部分维护：先明确岗位职责和考核口径，再设置方案，最后由考核结果驱动奖金试算和发放。

二、两个页面如何配合

数据只在当前商户范围内生效。岗位下拉来源于当前商户的岗位资料，不会把其他商户的岗位混入本商户方案。

三、新增奖金方案

1. 方案名称

建议使用“岗位 + 周期 + 版本”的命名方式，例如：

• 验光师月度奖金方案 V1
• 店长季度经营奖金方案 2026Q4
• 销售顾问新客转化方案

名称用于识别和复核，不能代替具体规则说明。

2.1 版本和生效区间

每个方案必须填写版本号和生效日期，可选填写失效日期。结算周期必须完整落在版本生效区间内；旧方案没有生效区间时按历史兼容规则视为一直有效。建议规则发生变化时新增版本，不要覆盖已经用于结算的历史口径。

2. 岗位

岗位可以选择一个具体岗位，也可以选择“全部岗位”。

建议：

• 岗位规则不同，分别建立方案；
• 只有规则完全相同的岗位才使用“全部岗位”；
• 先到“员工管理 → 岗位”维护岗位，再回来选择，确保岗位名称在全系统一致。

3. 基础奖金

基础奖金是通过绩效档位后，作为倍率计算基数的金额。填写 0 表示该方案不发基础绩效奖金，只计算其他规则。

4. 提成比例

提成比例按符合规则的净销售额计算。系统会读取结算周期内员工的销售额和退款额；如果勾选退款扣减，退款会从销售额中扣除后再计算提成。

5. 绩效分奖金阶梯

每一行是一档独立的最低分和奖金倍率。例如：

系统按“最终绩效分不低于最低分”的最高档位匹配。例如最终分为 95 分，匹配 90 分档；最终分为 100 分，匹配 100 分档。最低绩效分限制为 0—100，倍率不能小于 0。

档位不是 JSON 文本，不需要手工拼接或粘贴 JSON；点击“添加一档”即可增加明细行。

6. 高级奖金组件（可选）

如果只填写基础奖金、提成比例和评分档位，系统继续按旧版“基础绩效奖金 + 销售提成”兼容计算。需要配置更完整的激励结构时，在“高级奖金组件”中逐行设置：

组件还可以填写命中条件：最低/最高绩效分、最低/最高净销售额。空值表示不限制；不满足条件的组件不会进入叠加选择，并在只读预览和结算快照中显示未命中原因。

组件可以填写“叠加组”：

• 相加：同组组件全部计入；
• 互斥：同组只命中优先级最高的组件，优先级数字越小越优先；
• 取高：同组只计入金额最高的组件，金额相同再按优先级选择。

组件是可选的；一旦方案配置了组件，结算预览会显示每个组件的命中/未命中原因，并把最终组件明细写入结算快照。修改方案不会改写已经批准或已支付的历史结算。

6.1 适用业务范围

每个组件还可以设置“适用业务范围”，不需要填写 JSON。留空表示全部业务；页面可直接勾选普通配镜、防控方案、普通商品、0 元购、配镜套餐、导入套餐和邀请返现。命中方式可选“范围合计达标”或“每类业务都需成交”：前者统计选中范围的净销售额合计，后者要求每一个勾选的业务类型均有真实净销售，适合普通配镜+防控方案组合奖励。历史英文编码仍兼容读取。

业务范围会同时作用于该组件的净销售额条件和销售提成金额。例如总净销售额为 1000 元，其中防控方案 300 元，组件范围选择防控方案、比例填写 2，该组件提成为 6 元，而不是按全部 1000 元计算 20 元。组合模式未满足时，试算和结算快照会保存缺少成交的业务类型和中文未命中原因，便于复核。

6.2 商品明细范围与混合订单分摊

在“商品范围”中可多选当前商户商品；不选择表示全部商品。系统读取订单商品明细的支付金额，按同一订单各商品明细金额占比拆分订单净收款，再应用销售员工直接归属或多人协作比例。例如订单实收 1000 元，其中商品 A 明细 600 元、商品 B 明细 400 元，销售员工协作比例为 25%，商品 A 组件的净销售额为 150 元，而不是整单 250 元。退款会优先读取商品明细退款，缺少明细退款时按明细金额比例分摊订单退款。

商品范围可以和业务范围同时设置；“每类业务都需成交”在商品范围下表示每个选中的商品都必须有真实净销售。系统会在试算明细中保存商品范围、拆分后净销售额、缺失商品和未命中原因，便于奖金复核。历史组件商品范围为空，继续按全部商品兼容计算。

四、奖金试算与结算流程

• 在“绩效管理 → 考核方案”建立并确认考核周期、目标和评价流程。
• 完成员工考核，确认最终绩效分。未确认的考核不能生成奖金结算。
• 进入“奖金结算”，选择考核周期、员工和奖金方案，点击“只读预览”；预览不会写入结算单。
• 核对版本、生效区间、基础绩效奖金、销售额、退款额、净销售额、提成、其他组件奖励、命中原因和应发金额后，点击“生成结算单”。
• 进入复核流程：草稿 → 待复核 → 已批准；复核人员可以填写应发金额调整和复核说明，批准后结算单锁定，再标记“已支付”。
• 如需退回，必须填写退回原因；退回单可补充业务凭证后重新复核。已批准或已支付的结算单不能再次复核或直接重算。

标记“已支付”时，系统会在当前商户的财务支出流水中幂等登记一笔“员工绩效奖金”，关联结算单号、金额、操作人和业务来源；重复点击不会重复记账。这里代表商户已经人工确认实际发放，不等于银行自动代发，银行回执和当地薪税处理仍需按部署环境完成。

五、计算口径

基础绩效奖金：

基础奖金 × 匹配到的奖金倍率

提成：

净销售额 × 提成比例 ÷ 100

如果组件填写了业务范围，则改为：

该业务范围净销售额 × 提成比例 ÷ 100

组件奖励：

按组件类型计算 → 按叠加组规则筛选 → 汇总命中的组件

其中：

• 未启用退款扣减：净销售额 = 销售额；
• 启用退款扣减：净销售额 = max(0，销售额 - 退款额)；
• 应发金额 = 基础绩效奖金 + 销售提成 + 其他组件奖励；
• 系统保留计算明细，便于复核“当时使用了哪个方案、哪个档位、哪些组件和哪些销售数据”。
• 业务范围为空的组件沿用全部业务兼容口径；指定范围的组件只读取对应 vision_order.order_type，不会把其他业务金额混入。

六、常见问题

为什么选择不到岗位？

岗位下拉只展示当前商户启用的岗位。请先到员工管理的岗位页面新增或启用岗位，并确认当前登录商户正确。

为什么试算提示考核尚未完成？

员工必须存在当前周期的考核记录，并且考核结果已经确认。仅创建目标、未完成确认，不能进入奖金结算。

修改方案后，历史结算会不会自动变化？

已批准或已支付的结算不会被直接重算。新方案主要用于后续试算；对尚未批准的结算，应在复核前确认规则版本和计算明细。

绩效分刚好等于档位分数怎么处理？

按“达到即匹配”处理。例如最低分为 90，最终分为 90 时即可匹配 90 分档。

为什么提成和预期不一致？

优先检查五项：销售数据是否属于当前周期、销售是否归属该员工、是否启用了退款扣减、组件适用业务范围是否正确、提成比例是否按百分数填写。例如填写 3 表示 3%，不是 0.03%。

七、配置建议

• 先写清楚岗位职责、指标定义和数据来源，再配置奖金规则；
• 每个周期保留可识别的方案名称或版本，避免“同名方案”难以复核；
• 方案上线前先选一名员工试算，核对绩效档位、销售额、退款额和应发金额；
• 高级组件上线前先用绩效分/净销售额条件、同组互斥、同组取高和跨组相加各做一名员工试算，确认命中原因符合门店制度；
• 需要区分普通配镜、防控方案和商品提成时，在每个组件行勾选业务范围（普通配镜、防控方案、普通商品、0元购、配镜套餐、导入套餐、邀请返现）；不勾选表示全部业务。需要“每类都成交”的组合奖励时，选择对应命中方式；历史方案中的业务范围编码会兼容转换，试算明细会显示“范围净销售额”和未命中业务类型；不要通过复制多份模糊名称的组件来代替业务范围。
• 方案调整应由商户管理员操作，店长或财务在“待复核”阶段核对；
• 不要把工资、税费、社保等法定薪酬规则混入本页面。当前功能负责绩效奖金和销售提成结算，法定薪酬仍应遵循企业现有薪酬制度和财务流程。

页面右上角的“方案说明”和页面中的问号提示都指向本说明。新增字段或改变结算口径时，应同步更新本文件、文档中心索引和页面提示。

团队/个人奖金分配

在“奖金管理 → 团队/个人分配”中，可以按考核周期建立奖金池：

• 团队奖金池：面向门店或团队成员统一分配；
• 个人奖金池：记录个人专项奖励；
• 按权重：系统按员工权重比例计算金额，并对最后一项做分角调整；
• 固定金额：逐人填写金额，合计不能超过奖金池；
• 确认后保存员工明细、负责人依据和确认状态，后续财务支付仍在奖金结算流程完成。

分配池是奖金结果的分配记录，不会绕过绩效结果确认、财务复核或支付审批。