客群隔离业务政策、算法矩阵与常见问题 (Policy & FAQ)
适用岗位：商品主档主管、电商运营负责人、销售总监、内控合规审计师、系统架构师
1. 核心企业内控与业务合规政策
为了维护健康有序的 B2B 批发价格与渠道管理秩序，保障各专供渠道客户的商业隐私与专属性，企业制定并执行以下三项核心内控准则：
准则一：公开分类单一主导原则 (Category-Centric Principle)
- 禁止在商品主档上私自打标做访问权限判断。所有针对客户群体的商品可见性隔离，一律通过商品挂载的**电商公开分类（
product.public.category）**进行集中管控； - 商品主档团队负责确保高敏感度、专供装、专供包装商品准确挂载至对应的受限公开分类下。
准则二：层级子集不破原则 (Strict Subset Invariant)
- 子分类的客群范围必须严格是上级分类的子集，任何业务层级调整均不得违背该数学逻辑；
- 严禁通过直接修改底层数据库或绕过 ORM 约束的方式破坏子集关系，防止商城前台出现“不可见父节点下的游离孤岛商品”。
准则三：销售代客视角等同原则 (Sales On-Behalf Equivalence)
- 销售代表在日常商务咨询与大盘查阅时享有全库上帝视角；
- 但在启动“代客下单（On-Behalf）”模式后，系统必须强制销售人员进入目标客户的受限视角，杜绝销售代表在代客代下单过程中录入客户协议外未准入品类。
2. 访问控制仲裁决策矩阵 (Truth Table)
以下真值表详细定义了在各种用户身份、伙伴标签与分类配置交织场景下，系统底层的仲裁结果：
| 用户访问身份 | 客户所持标签 | 访问的分类类型 | 分类配置标签 | 是否允许浏览分类 | 挂载此分类的商品是否可见 |
|---|---|---|---|---|---|
| 匿名未登录访客 | (无) | 顶级分类 (通用) | (未配置) | ✅ 允许 | ✅ 可见 (公开展示) |
| 匿名未登录访客 | (无) | 顶级分类 (专供) | [西人超市] | ❌ 302 重定向 | ❌ 不可见 |
| 普通未打标客户 | (未分配标签) | 顶级分类 (通用) | (未配置) | ✅ 允许 | ✅ 可见 |
| 普通未打标客户 | (未分配标签) | 顶级分类 (专供) | [餐厅] | ❌ 302 重定向 | ❌ 不可见 |
| 餐饮连锁客户 | [餐厅] | 顶级分类 (通用) | (未配置) | ✅ 允许 | ✅ 可见 (并集通用) |
| 餐饮连锁客户 | [餐厅] | 顶级分类 (专供) | [餐厅] | ✅ 允许 | ✅ 可见 |
| 餐饮连锁客户 | [餐厅] | 顶级分类 (专供) | [西人超市] | ❌ 302 重定向 | ❌ 不可见 (彻底隔离) |
| 西人超市客户 | [西人超市] | 顶级分类 (专供) | [西人超市] | ✅ 允许 | ✅ 可见 |
| 双标签集团客户 | [餐厅, 西人超市] | 任意专供分类 | [餐厅] 或 [西人超市] | ✅ 允许 | ✅ 可见 (双向通行) |
| 销售员 (未代客) | (员工账号) | 全量分类 | 任意配置 | ✅ 允许 | ✅ 全量可见 (上帝视角) |
| 销售员 (代客模式) | 代客 [餐厅] 客户 | 顶级分类 (专供) | [西人超市] | ❌ 302 重定向 | ❌ 不可见 (跟随客户受限) |
3. 高频常见问题解答 (FAQ)
Q1：为什么客户反映上周还能看到的商品，今天在商城突然搜不到了？
排查步骤：
- 检查客户主档标签：进入【客户】主档，检查该客户的【标签 (Tags)】是否被业务人员误删或修改；
- 检查商品分类归属：打开该【商品模板】，核对【电商公开分类 (eCommerce Categories)】，是否被移出了客户拥有的分类，或者被挪到了其他专供分类；
- 检查分类标签配置：进入【电商品类】，检查对应分类的【适用客户标签】近期是否发生了调整；
- 检查单仓库存模块：若系统启用了
3will_website_sale_single_warehouse_stock单仓库存控制，确认该商品在客户指定发货仓库中是否存在有效可用库存。
Q2：若一个商品未挂载在任何公开分类下，前台会怎样展示？
- 业务机制：在 Odoo 原生机制中，未分配公开分类的商品会归入“All Products (全品类)”根目录下；
- 客群过滤行为：在启用本模块后，对于打标客户，系统在列表与搜索底层注入了分类范围过滤。为保障严格的渠道隔离，未挂载分类的商品不会被计入受限客群的专属列表；
- 最佳实践：强烈建议所有上架销售的商品至少挂载在一个公开分类下（如挂载在“通用食品与日化”或其子分类中），以确保索引与展示完全受控。
Q3：一个客户可以同时分配多个客群标签吗？
- 可以，完全支持。
- 例如：某综合性贸易采购商既经营川湘菜馆，又经营生鲜超市。在客户主档的【标签】中同时添加
[餐厅]和[西人超市]即可。登录商城后，该客户的侧边栏将同时展示餐饮专区和西人专区，享有双重采购权限。
Q4：在修改已有分类的父子结构时，系统如何处理子集约束？
- 当你尝试将分类 A 拖动或变更为分类 B 的子分类时，保存时系统将实时重新执行子集约束校验；
- 若分类 A 当前配置的标签存在超出分类 B 范围的情况，系统同样会触发验证错误，并明确指出哪个标签越界；
- 处理建议：先清空或精简分类 A 的标签，将其挂载到新父级分类下后，再按需细化配置。
Q5：本模块与单仓库存（single_warehouse_stock）模块如何协同工作？
- 双重协同，互不冲突：
- 分类客群过滤（本模块）：从“客户商业渠道与协议身份”维度决定商品是否有资格展示；
- 单仓库存控制：从“物理发货仓库库存与现货周转”维度决定商品是否允许加购或下单；
- 两者在底层采用管道钩子机制依次求交生效，共同构筑起严密的 B2B 电商业务防火墙。
Q6：销售人员在代客下单模式下，能够强行将客户看不见的商品加入购物车吗？
- 绝对不能，系统设计如此。
- 代客下单模块（On-Behalf）的设计初衷是让销售人员以客户的身份视角录单，防止销售员凭借内部特权向客户许诺其不可供的特约商品。若销售员尝试通过非法手段加入未授权商品，底层的商品前置校验钩子将拒绝加入并强制重定向。
- 正规解决方案：若确实需要向该客户销售此商品，应先由销售主管在客户主档中正式为其增补相应的客群标签，或由商品管理员将该商品并入客户已有的通用公开分类。