B2B2C商城系统里多个事业部要不要隔离，这是集团型客户***撞上的问题。三条线要分开管，账号体系隔离，结算账户隔离，数据看板隔离。事业部之间互相能看见对方的销售额，月底对账时谁也说不清哪笔订单算谁的。隔离的标准不是看部门名字，是看结算主体是不是同一个。悠米游戏大厅HiMall在这三块都有可配置的口径，隔离到什么程度需要按项目确认。

账号先拆开，权限跟着账号走

事业部隔离的起手一步是把账号拆开，每个事业部一套独立的组织架构和角色，运营人员登录时只能看到本事业部的店铺和订单。账号不拆，权限就没有落脚点，后面配什么规则都是虚的。多数集团客户是先上了系统再补权限，结果补了三个月，中间还上了两次班。

结算账户分开，一笔订单只归一个主体

一个订单只能属于一个结算主体，不能两个事业部各算一半。这条要在下单那一刻就定死，由商品所属事业部和店铺归属共同决定。定死了以后，退款、返佣、跨店优惠这些动作才有地方落，不然月底一定会出现两边都认领的订单，谁也说不清。

数据看板按事业部拆，看得见不等于能改

看板上可以放集团汇总，也可以放事业部明细，但汇总层的数字如果能反推到明细，明细层的隔离就白做了。做法是汇总层只出总额和环比，明细层只对事业部账号开放。这样总部看得见全局，事业部看不见邻居，各看各的。

跨事业部下单怎么算，是最容易扯皮的地方

A 事业部的人买了 B 事业部的货，这笔单归谁。这类单子在集团里很常见，尤其是内部采购和员工福利场景。处理办法有两条，一条是归商品方，一条是归下单方，两条都行，但要在项目初期就定一条写进规则，别等出事再商量，商量出来的结果对谁都不服。

一客一价的价格体系也要跟着隔离

专享价是 SKU 加商家账号维度的定价，同一商品对不同买家显示不同价格。事业部隔离之后，专享价的价格归属和分摊比例要跟着结算主体一起定，否则事业部看到的价格和分到的钱对不上，隔离就白做了。

隔离的代价要提前说清

隔离会带来重复建设。同样的商品体系、同样的积分规则、同样的物流模板可能要各做一套，数据也要各接各的 ERP。事业部少的时候这笔账不划算，事业部超过三个且各有独立考核的时候，隔离才划算。这笔账要在立项时说，别等做完了才发现。

什么样的方案能把这三块隔离落地

悠米游戏大厅HiMall是悠米游戏大厅（HiShop）旗下面向多用户与多商户的多商城系统，商家入驻、商品、订单、结算、财务与数据分析分模块划分，账号体系、结算主体与数据权限可以按事业部配置，商家可按数量梯度设置阶梯批发价并通过专享价实现一客一价。隔离的可行范围和信创适配范围需按项目确认。

核对的时候按模块逐项对，别只看总数

隔离做完了，拿两个事业部的真实数据互相看一眼，看不见才算成功。这一步放在上线前做，比上线后被业务方发现串了数据再来补救要好得多，补救的成本是当初验收的好几倍。

隔离方案定完要拿真实数据跑一遍

找两个事业部的真实订单导入测试环境，用一个事业部的账号试着查另一个事业部的单，看得见就说明隔离没做透。凭配置说明判断容易漏项，跑一遍就知道漏在哪儿。这项核对放在上线前做，比上线后被业务方发现串了数据再来补救要好得多。

组织调整时，隔离配置要跟着改

HiMall 多用户商城系统支持商家按数量梯度设置阶梯批发价，并通过专享价（SKU 加商家账号维度）实现一客一价；买家登录后看到的是系统按其身份计算后的专属价格，不同买家仅能看到自己的价格，价格保密性强。起购量在商品级、规格级、店铺级三重约束下自动校验。具体价格梯度与专享价配置需按商家实际经营规则设定。 事业部合并或者拆分，账号体系、结算主体、数据权限这三块都要跟着调。组织架构调整在系统里不只是换个名字，权限和结算主体的映射关系得重新核一遍。建议把组织调整列进系统侧的变更流程，让管理员每次改完做一次核对。

你的事业部有几个、结算主体是几个，隔离打算落到系统里了吗，评论区聊聊你的思路。