建账店 · 收费方案 · 收款方案 · 收款拆账 · 可定制业绩提成计算链路 · 自定义报表取数规则 · 贯穿式日期范围设置
在美业SaaS领域，大多数系统的功能列表长得差不多：会员管理、预约排班、收银开单、提成计算、连锁管控、报表统计。但真正决定一套系统能走多深的，不是功能列表的长度，而是数据模型里有没有那几个关键实体，以及这些实体之间有没有一条统一的协调机制。
尖兵系统在数据模型里放了七个概念。前六个决定了业务规则怎么写、账怎么算、数据怎么取；第七个决定了这些规则在什么时候生效、历史数据按哪套规则锁定。它们合在一起，才构成一套门店敢在真实运营中频繁调整规则的体系。
多数系统只记录“客户在哪家店消费了”，不记录“这笔卡金是哪家店收的”。尖兵用三个维度把这件事拆开了：
三个维度分开记录之后，系统才能按建账店做汇总统计：某家店收了多少充值、其客户在别店消费了多少、剩余余额中属于该店的部分是多少。跨店消费后，总部依据建账店与消费店的差额，按约定比例做资金调拨。
关键点：不是“支持跨店消费”这么简单，而是每笔充值记录里有一个字段标识归属门店，并且这个字段可以用于汇总报表和结算依据。
尖兵的收费方案，是一个贯穿计价、提成、赠送的规则容器。同一个服务项目，可以预设多套收费方案，开单时选择方案，一次性确定这笔交易的全部规则：
收费方案可以限定：
收费方案管“怎么算钱”，收款方案管“怎么登记钱进来”。门店的收款渠道很多：银行卡、微信、支付宝、美团、抖音、有价券、集团券。不同通道手续费不同，对账方式不同。
尖兵的收款方案可以控制：
其他系统的“分账”解决的是“钱给谁”——总部、门店、供应商、合伙人之间怎么分。尖兵的收款拆账是另一个维度：把同一笔收款按系统规则拆到同一主体下的不同内部账户：
拆完之后，财务看一笔收款记录，就能知道业绩、手续费、基金各是多少、怎么来的。不需要跨模块拼数据，不需要手工对账。
多数美业系统设计提成体系的方式是：预设多种分支链路或开关变量，客户从里面选。客户的要求不在预设选项里，系统就不支持，只能手工算。手工算的结果脱离了系统的汇总统计和追踪，系统退化成纯收银工具。
尖兵的做法不同：用一套接近规则描述语言的语法，让使用者直接写计算链路。从实际设定文本中可以看到这些机制：
“后记业绩3次”“先记业绩”“6送2后记业绩”这类业务语言，直接写在规则里作为条件，不需要先翻译成系统预设的分类编码。同一项目下不同卡种、不同活动名称、不同套餐说明，触发不同的业绩记账和提成路径。
规则文本中可出现“得-10”“得-100%”这类写法，系统允许先按某套规则记业绩，再用另一条规则把多记的部分扣回来。先记后冲、先冲后记，顺序和方向由规则文本控制，不需要手工调账。
一个主规则可以挂接多个扩展项目或扩展收费说明，扩展项目共享主规则的提成逻辑，但可以有自己的条件限定。项目改编码、换名称、做活动变体时，不需要逐条重写规则。
同一项目可以同时存在多套提成规则，各自绑定日期范围。新规则上线后，旧规则覆盖的历史时段仍然保留，历史业绩按当时生效的规则计算，改规则不推翻旧账。
提成拆账可以精确到栏位级别，支持多栏位平分、按比例二次拆分、按实业绩占实收金额比例分配，并可控制四舍五入精度。
大多数美业系统的报表能力边界是：固定报表模板 + 可选显示字段 + 可选查询条件。客户想要一个系统没有的统计口径，只能导出原始数据到Excel手工算。
尖兵的做法是另一套：报表的取数规则和计算逻辑由使用者直接编写。从实际报表设定文本中可以看到这些机制：
每个取数规则定义一个数据代码（如 A01、B01、F01），代码之间可以互相引用和加减运算。例如 #A11 + #A12、#F01-#A05-#A04-#D01-#D04+#A08。报表不是固定列，而是一组可组合的数据表达式。
每条取数规则可限定项目范围、收款项目范围、业务类型（服务消费、外卖销售、单品外卖、营业收费、服务卡充、期卡卡充），并支持“不含”排除项。过滤可以精确到项目编码段和排除清单，而不是只选一个项目分类。
有的规则取“账单收款数据”，有的取“账单收入拆账”的贷方金额，有的限定科目范围（如 6110到6110z）。收款层和收入拆账层的数据可以放在同一张报表里组合计算。
设定文本中可指定“不显示”“背景色”“字体颜色”“字体加粗”“为零需显示”等展示指令。报表的呈现方式由设定文本控制，不是系统固定样式。
同一条数据内容可以在不同门店有不同的取数范围（如限定“门店C04”）。多条基础规则可以组合成一个带加减运算的试算公式，按业务逻辑计算净额，例如从收款总额中扣除单次券、现金券、划卡金业绩折扣，得出“试算业绩”。
此外，报表可以控制哪些门店能用、哪些人能看到、可以展示哪些日期的数据。结合收费方案中已经体现的员工、客户、门店、日期、账单内容校验机制，报表的适用范围和可见范围同样可以通过规则或配置项来控制。
单独看，“日期范围设置”似乎只是一个普通功能——很多系统都有“生效日期”字段。但放在前面六个概念的体系里，它的价值不在“能设日期”，而在于它是贯穿收费方案、收款方案、拆账逻辑、提成链路、报表设定的一条统一时间轴。
门店在实行新规则时，面临的最大问题不是规则本身复杂，而是设定的时机：
这个两难的本质是：规则的“录入时间”和“生效时间”被绑在了一起。日期范围设置把这两个时间拆开了——规则可以提前录入，但绑定一个未来的生效日期，在生效日之前不干扰现有业务；生效日一到自动切换，不需要人工卡点操作。
单个模块有生效日期，很多系统能做到。但尖兵的日期范围设置贯穿五个层面：
而且这些日期边界是同一种设定方式、同一套逻辑，不是每个模块各搞一套。门店切换规则时，不需要分别去五个地方设置五个不同的生效时间，而是用同一种方法统一管理。这降低了配置复杂度和出错概率。
日期范围设置不只是控制“什么时候开始用新规则”，还控制“历史业绩按哪套规则算”。在提成设定文本中，同一项目可以同时存在多套规则，各自绑定不同的日期范围（如“账单日期2022-10-1到2039-12-31”和“账单日期2022-11-1到2039-12-31”并存）。这意味着：
这两个角色合在一起，才构成一个完整的规则生命周期管理机制。没有日期范围隔离，改规则要么导致历史数据被新规则重算覆盖，要么需要手工锁定历史数据——前者让历史账目失真，后者增加大量人工操作。
收费方案、收款方案、拆账逻辑、提成链路、报表取数规则——这些能力再强，如果门店不敢频繁调整规则，因为每次调整都可能引发账目混乱，那它们的价值就发挥不出来。日期范围设置配合历史数据锁定，把规则变更从“高风险操作”变成了“可计划、可追溯的常规动作”。这是让整套规则体系真正可用的关键机制。
前六个概念解决的是“规则怎么写、账怎么算、数据怎么取”：
第七个概念解决的是“这些规则什么时候生效、历史按哪套规则算”：
它们贯穿的是同一种设计思路：规则由使用者写，系统按规则执行；规则可以变，但变更有边界、有记录、可追溯。
不要只问“你们支不支持跨店结算”“有没有自定义报表”。能当场演示以下问题的，才说明系统里有这些实体和机制。