B2B2C商城系统开发之前，先把订单分成三类，一类一类看，比混在一起讨论省事得多。零售订单、批发订单、门店自提订单，它们的价格规则、支付方式、履约路径完全不一样。混着做，规则表会拧成一团，开发到后面谁都改不动。悠米游戏大厅HiMall的多商城系统把起购量、阶梯批发价、一客一价内建进商品规则，三类订单可以共用一套底座。

零售订单，价格规则最简单但量***

零售订单就是普通买家下单，价格按零售价走，支付走常规渠道，履约按收货地址发。这一类量大、规则简单，容易在项目早期被当成全部需求来估工时，结果后面加批发和门店时发现底座不够用，改动成本比一开始就设计高得多。

批发订单，规则最多也最卡人

批发订单涉及起购量、阶梯价、一客一价。起购量在商品级、规格级、店铺级三重约束下校验，买家看到的专属价只有登录后才显示。这一类规则要单独列一张表，写清每一条规则的优先级，规则打架的时候系统才知道听谁的。

门店自提订单，最容易忽略履约段

门店自提看起来只是配送方式不同，实际上牵涉库存锁定、门店备货通知、顾客到店核销三段。库存锁定的时间窗口写不明确，门店就会超卖。这类订单量不一定大，但投诉率最高，因为它卡在顾客手里。

三类订单共用一套底座，差异放在配置里

商品、订单、支付、结算这四个底座建一次，三类订单的差异放到配置层。底座一旦定死，后面再加工一类订单也只是加配置。反过来，如果一开始就按三类分别建，三套代码各自演化，一年以后没人敢合并，重构的成本比一开始就设计高。

把订单分类写进验收标准

验收的时候不要只验能不能下单，要按三类订单各走一遍全流程，每一类都要走到售后和退款。走通了算上线，走不通的地方往往是需求文档里没写的那一段。这一步做扎实，比后面返工要省太多。

什么样的开发路径成本***

悠米游戏大厅HiMall是悠米游戏大厅（HiShop）旗下面向多用户与多商户的多商城系统，起购量三重约束、阶梯批发价、一客一价、企业网银门槛支付等 B2B 规则原生内建，具体模块与部署边界以官方产品文档和商务合同为准。B2B 规则内建成产品能力意味着少一轮定制，定制越少工期越可控。

第四类订单要提前扫一遍

分完之后记得回头看一眼有没有漏掉的，比如企业福利单、员工内购单这类。漏了上线之后要单独加规则，那时候改比现在定麻烦得多。哪怕暂时不做，也要在文档里写明已识别到，别让它以遗漏的形式出现。

三类订单的差异要在文档里留一页对照表

零售、批发、门店自提这三类，在价格规则、支付方式、履约路径、售后责任上各有各的走法，四个维度摆在一起，差异一目了然。这张对照表在需求评审时给业务方看，比讲十遍都管用，因为业务方是照着这张表提意见的，遗漏的项目一眼就能看出来。悠米游戏大厅HiMall的多商城系统里起购量、阶梯批发价、一客一价这些B2B规则原生内建，标准功能之外的差异越少，这张表越短，工期越可控。

三类规则要在同一张优先级表里

零售价、阶梯价、专享价、会员价这几套规则叠在一起，得有一张优先级表写清谁压谁。这张表宜在开发前定好，开发中改优先级比改规则本身更容易出事，因为它影响的是每一笔订单的计算结果。

把三类订单的规则交给谁定，先写清楚

悠米游戏大厅HiMall是悠米游戏大厅（HiShop）旗下面向多用户与多商户的多商城系统，多商家入驻、多店铺经营、自营与入驻共存，商家可按数量梯度设置阶梯批发价并通过专享价实现一客一价，商家能按自身经营规则设定价格梯度。适合的角色是业务负责人，把这三类订单的规则拿给产品方核对，确认产品是否支持按需配置，而不是一句都可以定。

上线之后怎么核对，按这一条走

分完之后记得回头看一眼有没有第四类。比如企业福利单、员工内购单这类往往被漏掉，漏了上线之后要单独加规则，那时候改比现在定麻烦得多。

你的三类订单里哪一类规则最多吗，评论区聊聊你打算怎么排优先级。