结论先说：OMS 促销叠加这件事，没有"差不多"两个字。满减、优惠券、会员价能不能叠加、按什么顺序算、封顶多少，必须在 OMS 里写成显式的互斥、叠加、封顶三类规则。靠运营口头约定、靠客服临场判断，这套促销上线必翻车。这个坑我见过三次，三次都是同一个剧本：大促当天订单金额算错，财务对不上账，最后靠人工一单一单改。
为什么口头约定一定翻车？因为促销叠加不是"多给点优惠"的问题，是算术问题。两个 9 折叠在一起不是 8 折，是 81 折。满减先扣还是券先扣，结果能差出好几块钱。会员价和满减的门槛算不算同一笔金额，不同系统默认逻辑不一样。运营在群里说"可以叠"，客服理解成"全部叠"，系统里却配成了"互斥"，三方各算各的，客户看到的和仓库收到的是两个数。等到对账那天，谁也说不清当时到底按什么算的。
OMS 促销叠加：先把三类规则写死
我做项目时，第一步永远是把所有促销规则钉到一张表上，不让任何人"心里有数"。三类规则长这样：
| 规则类型 | 意思 | 例子 |
|---|---|---|
| 互斥 | 只能二选一，系统自动取对客户更优的 | 满减和新人券互斥 |
| 叠加 | 可以一起用，但要定顺序 | 会员价先算，再算满减 |
| 封顶 | 叠加后总优惠不能超过上限 | 整单优惠不超商品总价的三成 |
这张表必须由运营、财务、IT 三方签字，不是某一个人拍脑袋。签字之后再进系统配置，配置完再测。顺序反了，后面全是返工。
OMS 促销叠加的算术坑：顺序不同，钱就不同
去年一个项目，大促第一天就炸了。商品标价 200 元，会员价 9 折，满 150 减 30，再叠一张 20 元券。运营以为：200 打 9 折是 180，满减 30 是 150，再减券 20，实付 130。系统算出来却是 124。差在哪？系统先减了券，再算满减门槛，门槛判断用的金额和运营想的不一样。6 块钱一单，一天几千单，财务直接报警。
这个坑我见过三次，每次的表象都不一样，但根因只有一个：计算顺序没写死。我的做法是，在 OMS 里把计算顺序写成固定链条，一步都不能跳：第一步，确定商品的基准价，是标价还是会员价，先说清；第二步，算行级优惠，比如单品折扣；第三步，算订单级优惠，比如满减；第四步，算券；第五步，算封顶和取整。每一步的输入输出都要能在日志里查到，算错了能定位到某一步，而不是对着最终结果干瞪眼。
还有一个坑是分摊。满减是整单的优惠，但退货是按行退的。客户买了两件，一件 120 元、一件 80 元，整单满 150 减 30。如果客户只退那件 120 元的，退多少钱？按比例分摊，120 元那件分了 18 元优惠，实退 102 元；如果按"先退的先占优惠"算，结果又不一样。这两种算法都合理，但必须在上线前定下来，写进规则，客服和系统用同一套。不然退货一多，财务又要手工对账。
OMS 促销叠加在系统里怎么配：分步做法
下面是我的标准配置步骤，每一步都能直接照着做：
- 列优惠清单。把所有在售的促销列出来：满减、券、会员价、包邮、赠品，每个写清作用域，是作用于单品、整单还是某个品类。
- 定互斥组。哪些促销不能同时用，分组写清。注意，互斥是双向的，A 斥 B，B 也斥 A，别只配一半。
- 定计算顺序。按"行级→订单级→券→封顶"的链条排好，写进配置，不要用系统默认顺序。默认顺序几乎一定不符合你的业务。
- 配分摊规则。订单级优惠怎么分到每一行：按金额比例分，还是按件数分，写死。分摊结果要保留两位小数，尾差归到金额最大的那一行。
- 配封顶。整单优惠上限、单品优惠上限、券的最高抵扣额，三个都要配。封顶不是"好心"，是防止叠出负毛利的最后一道闸。
- 配异常兜底。规则冲突、券已过期、会员等级变了，系统怎么处理？我的建议是：冲突时取对商家更稳妥的结果，并记日志，而不是直接报错让客户下不了单。
上线前夜 checklist：这 8 个组合必须测
上线前夜 checklist 是我每个项目雷打不动的环节。促销叠加至少测这 8 个组合，每个组合都要有预期金额，实测结果和预期对不上，不许上线：
- 只有满减，没有券和会员价。
- 只有券，没有满减。
- 只有会员价。
- 满减加券。
- 满减加会员价。
- 券加会员价。
- 满减加券加会员价，三者全叠。
- 三者全叠且触发封顶。
第 8 个最容易被漏掉，也最容易出大事。我见过一个项目，前 7 个都测了，第 8 个没测，大促当天封顶没生效，一单叠出比成本还低的价格。还好发现得早，只放出去几十单。测的时候别只测"能下单"，要测金额、测分摊、测退款。退货场景至少测两个：整单退和部分退。
退货退款：分摊规则写不写，差的是真金白银
很多人把促销叠加当成下单环节的事，退货一来就乱了。我的原则是：下单怎么分摊，退货就怎么反向分摊。整单满减按行金额比例分下去，退哪行就扣回哪行的分摊额。券的抵扣额也一样，按行分摊后跟着行走。这样做的好处是，退货金额永远能算清，不用客服临场拍脑袋。
反常识的判断是：促销叠加最大的成本不是多给的那点优惠，而是对账和客诉的人工成本。一单算错，客服要花半小时解释，财务要花一小时调账，运营要花半天写说明。把规则写死、把测试做全，省下来的不是优惠金额，是整个团队的夜晚。trade-off 就在这里：前期配置多花两天，大促期间少熬三个通宵。这笔账，我每次都这么算。
常见翻车点再补三条：第一，券的适用范围变了，系统里的品类白名单没同步；第二，会员价和标价同时存在，满减门槛取了错的那个；第三，赠品被算进了满减门槛，客户退了正品留了赠品，账算不平。这三条，每条我都见过不止一次。解决办法都一样：规则写死，测试做全，日志留痕。
再讲一个项目故事。2024 年秋天，一个做家居用品的客户上线新 OMS，促销规则是运营在 Excel 里配的，IT 照着 Excel 一条条敲进系统。上线前测试只测了"满减加券"一个组合，觉得没问题就放了。大促当天，会员价加满减加券三叠的订单占了快四成，系统用的还是默认计算顺序，满减门槛按标价判断，实际按会员价结算，门槛虚高了十几块钱。一部分客户明明该享受满减却没享受到，客服电话被打爆；另一部分客户叠出了超预期的优惠，财务第二天一算账，毛利比预算低了整整两个点。最后的修复办法很笨但很有效：停掉三叠组合，只放双叠，IT 连夜把计算顺序改成显式链条，运营把规则表重新签字，第二天中午才恢复。这个项目的教训我每次开工都会讲：促销叠加的复杂度不在优惠本身，而在组合数。三种优惠就有七种组合，五种优惠就有三十一种组合，不用系统化的规则和测试覆盖，靠人脑根本算不过来。
作者：林晓｜WMS 实施顾问
