薪资 （如果您的门店已启用）
跟踪团队的提成、保底和周期总额；在会计师 录入税表后，还按条目计算 PAYG 代扣与 Super 退休金。它不是 STP/ATO 申报或银行付款系统。
薪资涵盖什么
| 它做 | 它不做 |
|---|---|
| 按服务计算提成 | 向 ATO 做 STP 申报 |
| 保底（最低工资）检测 | Award 解释 |
| 按您录入的税表计算 PAYG 代扣 + Super 退休金 | 银行付款 / 银行文件生成 |
| 周期创建/重算/关闭/审批/标记已发 | 预置任何税表、税率或门槛 |
| 按员工分解（含每日明细） | 替您向 ATO 核验税表 |
PAYG 代扣与 Super 退休金（V1）
Admin → 薪资 → PAYG 与 Super（仅租户/超级管理员）
系统不预置任何数据。由业主或会计师录入带版本的配置；每个版本都有生效日期和变更原因，版本不能编辑或删除——只能追加新版本。
- PAYG 代扣税表：按 ATO 公布的系数形式录入区间行——周期类型（周/双周/月）、税务居民身份、免税额度与 Medicare levy 豁免标记、
[起, 止)收入区间以及系数a、b（代扣 = a × 收入 − b）。每个版本还要声明收入输入规则（忽略分 / 追加分数）、舍入规则、固定代扣是否先于税，以及未提供 TFN 员工的固定税率（留空即拒绝计算）。 - Super 退休金：比率、每季度最高缴费基数、哪些薪资成分计入 OTE（提成、保底补足、营业额分红）以及舍入规则。
- 员工税务属性在雇佣关系上维护（Admin → 雇佣管理 → 编辑）：税务居民身份、是否申请免税额度、Medicare levy 豁免、是否已提供 TFN。系统从不存储 TFN 本身。
周期计算时，每条条目记录 gross、PAYG 代扣、税后实发、SG 金额以及所用的精确配置版本。SG 上限会计入该员工同一日历季度内所有其他已计算周期，即使两个周期的结束日相同。缺任何一项——属性未申报、周期结束日没有生效版本、没有匹配区间——条目会显示红色税务错误而不是 0，且在修正并重算前周期不能审批。open 条目的实发被手动覆盖后，之前的 PAYG/Super 结果会清空，必须重算。已审批条目永久保留其版本；之后的配置版本不会改写它们。
设计上 fail-closed：系统宁可拒绝也不猜税务规则。请让会计师核对您录入的税表；MMOS 不会替您向 ATO 核验。
提成如何运作
提成按每个已完成服务基于门店策略计算：
| 策略 | 规则 |
|---|---|
employee | 员工级提成率（来自雇佣关系）优先 |
service | 服务级提成率优先 |
higher | 哪个产出更高金额就用哪个 |
策略在 Admin → 门店管理 → 编辑门店 → 佣金策略中设置。
服务完成、调整或作废时，提成通过 Celery 任务自动重新计算。
薪资配置
Admin → 薪资 → 配置
按员工的薪资规则。五种计算类型：
| 类型 | 作用 | 示例 |
|---|---|---|
| commission | 标准按服务提成 | 服务收入的 50% |
| tiered_guarantee | 基于营收阶梯的最低工资 | 营收 < $2000 → 保底 $800/周 |
| days_guarantee | 基于出勤天数的最低工资 | 工作 5 天 → 最低 $1000 |
| revenue_bonus | 营收超过阈值时的奖金 | 营收 > $5000 → 超出部分 5% 奖金 |
| deduction | 每周期固定扣减 | 工服租赁：-$20/周期 |
规则有优先级——计算时按顺序求值。
薪资周期
Admin → 薪资 → 周期
周期是计算薪资的日期范围。在 Admin 中手动创建的周期始终按周。按日、双 周和按月的周期只由自动周期任务生成，它遵循各薪资配置的周期设置。
创建周期
- 周期 → 创建（或系统通过 Celery 任务自动创建，如已启用）。
- 选择门店和一个周一作为周起始日；七天后的结束日期自动推导。非周一的起始日会被拒绝。
- 周期以
open状态开始。若门店属于 Twin，同一步会为每个 Twin 成员创建同一周的周期。
计算
- 打开周期 → 全部重新计算（条目随周期创建而生成，重算只是刷新它们；也可以等待服务完成后自动重算）。
- 引擎为每位员工汇总：
- 已完成服务的总提成
- 出勤天数（来自打卡）
- 产生的营收（来自付款）
- 保底阈值和奖金
- 结果：每位员工一条 PayrollEntry 显示分解明细。
审查条目
每条显示：
| 行 | 来源 |
|---|---|
| 提成总额 | 按服务提成之和 |
| 保底金额 | 如保底 > 提成，差额补齐 |
| 营收奖金 | 如达到阈值 |
| 扣减 | 每周期固定扣减 |
| 实发 | 最终金额 |
| 每日明细 | 哪家店、多少服务、多少钱——按天 |
| 分店明细 | 各并入门店的提成与出勤天数（多店员工，见下文） |
审批
- 店长审查所有条目——每条都必须显示已计算的 PAYG/Super（没有红色税务错误）。
- 关闭周期 → 状态变为
closed（从这里起停止重算）。 - 批准周期 → 状态变为
approved。 - 周期一关闭即停止重算——API 在行锁下拒绝重算，数据库本身也会拒绝修改不再处于 open 状态周期的条目（只有标记已发的确认列可以改动）。
标记已发
将钱转给员工后：
- 标记已发 → 状态变为
paid。 - 这是记录步骤——系统不转账。
周期生命周期
open → closed → approved → paid
- Open：服务在产生，提成在累积；条目可以重算。
- Closed：本周记录已完整；不再可能重算。
- Approved：店长签字。
- Paid：外部转账完成；最终。
已关闭周期的调整与结转
周期一旦关闭、审批或已发，其条目即冻结。迟到的奖金、扣减或更正以调整记录在条目上（只追加；错误的调整用原因反转，从不删除）。
如果这笔钱应随下一次发薪支付，请在调整表单勾选结转到下一个 open 周期：
- 调整记录在已关闭周期的条目上，但金额在该员工同一门店的下一个 open 周期实现，该周期条目会立即重算（gross、实发、PAYG 代扣与 Super，使用已配置版本）。已关闭周期的数字不变。
- 条目显示 已结转到
起–止，方便查看金额落在哪里。 - 该门店还没有之后的 open 周期时，结转会被拒绝——请先创建下一周期。
- 结转调整在目标周期仍 open 时可以反转；目标关闭后，请改在目标周期上记录新的调整。
银行转账和 STP 申报仍不在系统内 。
保底逻辑
两种类型：
- 阶梯保底（经理）：如果周期总营收低于某阶梯阈值，无论提成多少，员工获得保底最低金额。
- 天数保底（技师）：如果员工工作了 N 天或以上，至少获得 $X——提成在保底之上累加。
最终薪资始终为：max(提成, 保底) + 奖金 − 扣减。
多店员工：主店、Twin 与借调
员工在多家门店工作时——同一商场的两家 Twin 店，或借调到区域内另一家店——工资在其主店算一次，其他门店的工作以分店明细并入。
- 主店 = 标记为主任职的雇佣关系（Admin → 雇佣管理）。只有一条 active 雇佣的员工不需要额外设置；有多条雇佣的员工必须恰好有一条标记为主任职；借调产生的雇佣关系永远不能设为主任职。没有主店时，主店会拒绝计算并指出该员工。
- 什么会并入：当某门店向主店授予
payroll.consolidate共享能力时，它的提成、营业额和打卡天数并入员工的主店条目。Twin 会自动双向授予；借调到非 Twin 门店时，从该店向主店添加一条薪资策略，选 Collaborate 预设（或勾选并入员工主店薪酬计算）。 - 一个人，一份保底：天数保底和阶梯保底使用合并后的天数/营收。保底保的是人，不是每家店。
- 分红营收范围：每条
revenue_bonus规则都有营业额范围——仅本店（两位店长各管一店）或全部并入门店（一位店长管 Twin 两店）。 - 代扣按主店配置。PAYG 对合并后的 gross 只代扣一次；Super 季度上限不变。
- 不会双计：工作被并入他店的员工不会在来源店生成条目；周期摘要把他们计为已并入他店。
Twin 周期一起流转。 在一家 Twin 门店创建某周，会为每个 Twin 成员创建同一周；关闭、审批、标记已发作用于整组，任一成员周期状态不同即被拒绝。借调（非 Twin）门店保持自己的周期生命周期。
看另一边。 在员工被并入他店的门店上，周期页显示只读的已并入其他门店计算表。能看到什么取决于主店授予本店的薪资共享：未授予 → 只看本店贡献（提成、天数）；查看汇总摘要 → 加实发；查看逐条明细 → 完整分店明细。Excel 导出含 Store Breakdown 列，员工门户向每位员工展示分店明细。
提示
- 审批前检查 — 审查每日明细。技师"周二没收入"可能是在班但未被分配（排班问题，非薪资问题）。
- 提成争议 — 始终检查：门店用什么策略？雇佣提成率是多少？服务提成率是多少？引擎根据策略解析。
- 这不是您的税务薪 资 — 将系统输出作为实际薪资供应商的输入。周期总额是您的"应付提成"数字；其余由会计师处理。