围绕「H2B 封闭采购商商城、BTOC 联合开店（壳店协议）、BTOB 联合开店（经销开店）以及以销定采期货模式」的新蓝图，对照当前已落地的三端平台与四层底座，逐点拆解产品逻辑变化与开发改动量：哪些可复用、哪些要新建、改动多大、底层从哪开始改。
新蓝图不是推倒重来的技术重构，而是一次产品准入、渠道分发、前端权限和履约策略的定性升级：底层仍是「单后端 + 三销售前台 + 共享底座」，但 H2B 必须成为封闭采购商商城，普通访客不能查看；H2B 采购商注册、H2B 商品上架、BTOB / BTOC 非 H2B 源头商品上架都必须进入管理员审核，且 H2B 申请表新增「是否愿意联合开店」字段，仅供后台审核展示。BTOB 前台维持现有开放浏览逻辑：游客可查看商品，注册后才可下单，不新增后台买家审核门禁；自助申请 BTOB / BTOC 商家时，后台保持同一商家主体，但渠道资格分开审核。联合开店已退化为协议层 + 线下日本化改造 + 以销定采期货模式（仅协议同意和状态记录，不驱动产品复制，无镜像、无 linked listing / forked product），取消前置仓备货；日方先在自有渠道预售，达到起订量后向中方批采，定金进入平台接入的第三方持牌支付机构托管账户，平台、买方、卖方三方可见且任何一方不能单方动用；货物正规报关报检后发到平台日本交付中心，验货合格后尾款进入托管账户、仓库放行、平台按账期结算给中方，验货不合格则退回退款，并同步生成国家标准版外贸合同和报关文件。最新口径下，现有代码已具备三端 storefront、B2B+B2C 渠道底座、分账/佣金引擎、网红与推荐人复用底座；新增工作主要是三端前端登录态/权限隔离、H2B 可见性门禁、H2B 联合开店意愿展示字段、渠道资格守卫、供应商外贸验厂资料、联合开店协议与预售状态、定金/尾款/交付中心验货记录、店铺归属展示、商品/店铺二维码和网红店铺。
图 1 ｜ 新蓝图三层全景：H2B 是商品源头，BTOB / BTOC 是下游渠道；底座大部分复用（中方资金代收为新增）
| 维度 | 现有实现（当前已落地） | 新蓝图（目标形态） | 改动性质 |
|---|---|---|---|
| 平台叙事 | B2C / B2B / H2B 三端已存在，当前可并行运营 | H2B 为封闭采购商商城，BTOB / BTOC 按路径从 H2B 合作关系受限派生 | 叙事调整 |
| 商品来源 | 各渠道商家可直接上架，现有审核强度不完全一致 | H2B 商品必须审核；BTOB / BTOC 非 H2B 源头商品必须审核 | 新增门禁 |
| 供应商外贸资料 | 现有商品/店铺资料不足以覆盖外贸验厂考察 | H2B 供应商栏目需展示工厂视频、资质证书、检测报告、产能设备、质检体系、出口经验、客户案例和售后能力；供应商后台维护上传，平台审核完整性与有效期 | 新增资料栏 |
| 企业身份 | 企业实体、商家能力、渠道能力已有底座 | 后台企业 / 商家主体共用；H2B / BTOB / BTOC 登录态、访问权限和渠道资格相互独立；H2B 采购商审核通过后才可查看，申请时记录是否愿意联合开店（仅后台审核展示）；BTOB 买家开放浏览、注册后下单 | 权限调整 |
| 自助商家资格 | 一个 seller/profile 可挂多个 allowed sales channel，底座可复用 | 商家主体统一，BTOB / BTOC 渠道资格分开申请、分开审核、分开开通；未获渠道资格不能发布该渠道商品 | 新增守卫 |
| 商品销售版本 | 商品可通过 sales channel 绑定影响前台展示，历史 linked listing / forked product 链路仍存在 | 联合开店为协议层，不驱动产品复制；日方使用改造后的产品素材在自有渠道预售，达起订量后批采；新链路移除 linked listing / forked product | 新增规则 |
| 路径渠道 | 已支持 B2B / B2C 渠道绑定与商品上架 | 联合开店仅作协议同意标记（joint_agreement_btoc / joint_agreement_btob）；BTOC 联合开店仅平台指定壳店；BTOB 联合开店仅 H2B 注册采购商可申请；直接采购不派生 | 新增守卫 |
| 店铺与二维码 | 商品展示、推广码、部分链接能力已有 | BTOB / H2B 店铺只显示对应商家产品；商品和店铺都可生成分享二维码 | 补齐能力 |
| 认证流转 | 客户（买家）与商家（卖家）两套实体，可入驻转换 | 明确「三端前端独立、H2B 审核可见、后台资格关联」流转 | 流程明确化 |
| 卖货模式 | 三种：自营 / 联营代发 / 联营自营 | 三种交易路径：H2B 直接采购 / BTOC 联合开店（壳店协议）/ BTOB 联合开店（经销开店） | 可映射 |
| 联合开店 | 已实现邀请接受 → joint store → linked listing / forked product → B2B/B2C 渠道展示 | 改为协议层 + 线下日本化改造 + 以销定采：仅记录 joint_agreement、预售/起订量、定金监管、交付中心验货和尾款状态；新链路不兼容旧 linked listing / forked product，测试数据可清理 | 替换旧链路 |
| BTOB 分拨 | 已有商品展示与渠道绑定底座；本期做：BTOB 官方入口注册下单、海报二维码（扫码导流到平台商品页或自有平台）+ 产品导出（图片/字段，供日企自传电商平台）；API 同步/代下单为后期概念 | 小 B 可直接进入 BTOB 前端商城注册成为用户并下单 BTOB 商品，也可通过大 B 商品/店铺二维码进入；复杂客户后期系统对接 | 新增工具层 |
| 网红推广 | 后端底座已实现（归因 + 分佣 + 结算） | BTOC 带货飞轮（产品定义一致） | 沿用补全 |
| 推荐人招商 | 后端 referrer 模块与 workflow 底座已建，前端与业务接入待产品化 | B 端招商飞轮（与网红共用财务底座，但计佣基数为平台佣金） | 补齐接入 |
| 分账 / 支付 | 佣金引擎 + 跨境支付连接 + 防倒贴护栏 | 沿用，新增定金监管、尾款状态、交付中心验货记录、核规整改费、售后准备金、6% 售后保障费等收费项（比例后台动态可配） | 核心复用 |
当前系统的主链路（联合开店历史实现）：供应商接受联合开店邀请 → 创建 joint_store 关系 → 合作方 seller profile 固定为 distributor → 渠道预设固定为 domestic（B2C+B2B）→ 通过 linked listing / forked product 发布到指定 sales channels → 三个 storefront 统一从 /store/linked-listings/products 读取可展示商品。
backend/src/workflows/joint-store/steps/ensure-buyer-seller-account.ts，`BUYER_SELLER_BUSINESS_TYPE = "distributor"`，并使用 `resolveSellerChannelCodesForPreset("domestic")`。backend/src/types/channel-refactor/seller-channel.ts，`DOMESTIC_SELLER_CHANNEL_CODES = ["b2c", "b2b"]`。backend/src/workflows/joint-store/workflows/respond-joint-store-invite.ts，`respond → createJointStoreStep → completeAcceptedJointStoreInviteStep`。backend/src/api/vendor/joint-store/linked-listings/route.ts 调用 create-joint-store-linked-listing-workflow，通过 `sales_channel_ids` 创建渠道绑定。新口径下联合开店退化为协议层，linked listing / forked product 不再驱动产品复制，仅保留协议同意标记字段（joint_agreement）。backend/src/api/store/linked-listings/products/route.ts 读取商品；新口径下它不能再代表 linked listing，应重命名或改职责为「按 sales channel / 店铺归属读取自主发布商品」的数据源。结论：联合开店已退化为纯协议层（仅协议同意标记，不复制产品，无镜像、无 linked listing / forked product）。日企按线下谈妥后的单一售价发布：BTOC 联合开店仅平台指定壳店可签协议、报价栏即网红选品库；BTOB 联合开店仅 H2B 注册采购商可申请成为经销商；直接采购只形成 H2B 采购订单。
绿底（沿用）是好消息——日方支付与分账链路基本复用（中方资金代收为新增）；红底（新增）是主战场——BTOB 分拨工具、门禁、专区、推荐人、中方代收；黄底（调整）是产品口径需要重新对外表述的部分。后续产品层 / 开发层会分别展开。
本部分面向产品经理 / 业务方，用业务语言讲清新蓝图与现状的产品差异、角色关系、身份流转，以及需要产品拍板的口径。不含任何技术实现细节。
对外可以强调「H2B 商品先经过封闭采购商准入与管理员审核，再按合作路径进入 BTOB 或 BTOC」。这个口径能同时表达源头可溯、渠道受控和平台招商质量。
这是最容易把产品方带晕的地方：同一个企业，在不同渠道，买家 / 卖家身份会翻转。必须先用一张表理清。
| 参与角色 | H2B（封闭采购商商城） | BTOB（企业分拨） | BTOC（零售） |
|---|---|---|---|
| 🏭 中国供方（例：智核科技） | 🟢 卖家 | BTOB 联合开店：日企（经销商）自主发布 | BTOC 联合开店：仅平台指定壳店自主发布 |
| 🏪 日方采购方（例：樱花堂） | 🔵 审核后买家 | 🟢 BTOB 经销商 | 🟢 BTOC 壳店经营方 |
| 🔑 推荐人 | 拉新商户入驻 | 拉新大客户 | — |
| 🌟 网红 | — | — | 必须拥有网红店铺，选品带货赚佣金 |
| 👤 C 端消费者 | — | — | 浏览下单 |
樱花堂在 H2B 是审核通过后的采购商。若申请成为 BTOB 联合开店经销商，它在 BTOB 以日企店铺身份发布按线下谈妥单一售价维护的产品；日企若被平台指定为 BTOC 壳店，则其发布的产品只进入 BTOC 零售链路、报价栏即网红选品库。同一家后台企业主体可以拥有多渠道业务资格，但三端登录态、访问权限和渠道资格互相独立；BTOB 买家端不新增审核门禁。
历史上业务方按「中国供方参与度」分模式（直接采购 / 联合开店），系统按「谁定价、谁发货、谁承担库存」分模式——这两个分类轴不正交，沟通时极易拧巴。新口径下联合开店已退化为纯协议层（无产品复制、无镜像），建议产品对外统一用「交易路径」三选一来描述（见 P4），避免模式命名打架。
① 现在三端是不是共用同一个用户？② 新蓝图是不是要三端独立用户？③ 一个 B2C 前端用户注册完企业，怎么「变成」B2B 商家，流转怎么做？能不能复用现有底座？
答案是：后台企业 / 商家主体可共用，BTOC、BTOB、H2B 的登录态、访问权限和渠道资格互相独立。H2B 采购商必须管理员审核通过后才可以查看 H2B 商品；BTOB / BTOC 按各自前端注册与经营规则运行，不与 H2B 登录态互通。
| 层次 | 现有实现 | 新蓝图要求 | 是否独立 |
|---|---|---|---|
| 前端登录态 | 三端已有各自 storefront | BTOC / BTOB / H2B 登录态、访问权限和渠道资格相互独立；后台企业 / 商家主体可关联共用 | 按资格隔离 |
| 企业实体 | 后端企业/商家模型可复用 | 后台可识别同一企业的多渠道资格，但前端用户不互通 | 底座复用 |
| H2B 可见资格 | 现有 H2B storefront 已存在 | 采购商注册后必须管理员审核，通过后才可查看商品 | 新增门禁 |
| 渠道角色 | 卖家 / 买家角色已有 | BTOC 联合开店（壳店协议）、BTOB 联合开店（经销开店）、H2B 直接采购三条路径写入权限规则 | 规则调整 |
图 2 ｜ 身份流转：后台企业资格可关联，三端前端登录态、访问权限和渠道资格独立
分两步，都能复用现有底座：
田中先在 BTOC 注册成普通消费者（客户身份），买了一台 AI 翻译耳机觉得很赚。他觉得自己也能卖，于是：① 提交自己公司「田中商事」的营业执照 → 平台审核通过，田中商事成为企业实体，田中本人获得商家身份；② 田中商事作为 H2B 注册采购商经企业申请、平台确认后成为 BTOB 联合开店经销商，可按线下谈妥后的单一售价发布产品到 BTOB；③ 若被平台指定为 BTOC 壳店，则其发布的产品只面向 BTOC，报价栏即网红选品库；④ 田中在 Vendor Panel 中维护商品（联合开店仅作协议同意标记，不再使用 linked listing / forked product），系统根据其签署的协议类型限制目标渠道。整个过程不是三端账号互通，而是由后台把同一企业的 H2B 采购资格、BTOB 经销能力、BTOC 壳店能力按规则关联。
需要承认三端前端登录态、访问权限和渠道资格独立，但不需要推翻后端企业/商家底座。开发重点是新增 H2B 可见性审核、三端登录态/权限边界、渠道资格关联表和路径渠道守卫；BTOB 买家端维持开放浏览、注册后下单。
日方采购方在 H2B 审核通过后看中商品，根据自身能力和意愿三选一。三条路径的成本承担、定价权、预售/起订量、结算方式、可发布渠道完全不同；联合开店已调整为协议层 + 线下日本化改造 + 以销定采期货模式；仅平台内部指定的 BTOC 套壳壳店存在坑位费，按订单实付金额百分比计入结算快照。
| 对比项 | ① H2B 直接采购 | ② BTOC 联合开店（壳店协议） | ③ BTOB 联合开店（经销开店） |
|---|---|---|---|
| 价格口径 | 中国供方维护单一售价，可按线下谈妥订单改价 | 线下谈妥日本化改造后的单一售价 | 线下谈妥日本化改造后的单一售价 |
| 谁发货 | 中国直发日本采购商 | 中方生产后发往日本交付中心，验货后放货 | 中方生产后发往日本交付中心，验货后放货 |
| 履约模式 | 中国供方按确认后的单一售价履约 | 自有渠道预售，达起订量后批量采购 | 面向下游 B 端预售/集单，达量后批采 |
| 核规整改责任 | HTOB 产品合规中方出/线下 | 核规日企负责事项、中企出费用（可从后续平台服务费扣） | 核规日企负责且承担费用 |
| 结算方式 | 定金和尾款进入平台接入的第三方持牌支付机构托管账户；验货合格后放货并按账期结算给中方 | 定金和尾款进入第三方持牌托管账户；验货合格后放货并按账期结算 | 定金和尾款进入第三方持牌托管账户；验货合格后放货并按账期结算 |
| 适合谁 | 小渠道商试水 | 平台指定的 BTOC 壳店，报价栏即网红选品库 | H2B 注册采购商转型经销商 |
| 经营风险 | 最低 | 日企自营自担 | 日企自营自担 |
| 可发布渠道 | 仅 H2B 采购订单 | 仅 BTOC，仅平台指定壳店可签协议 | 仅 BTOB，仅 H2B 注册采购商可申请 |
① H2B 直接采购：智核科技维护单一售价 ¥500，小渠道商买 100 台试水；若涉及合规整改成本，双方线下谈妥后由中国侧商务或平台运营后台确认订单价。
② BTOC 联合开店（壳店协议）：被平台指定为壳店的日企发布美容仪到 BTOC，按线下谈妥后的单一售价 ¥1200 直卖日本消费者，承担 PSE 认证等核规事项（中方出费用，可从后续平台服务费扣）；报价栏即网红选品库，平台收佣金+网红费+推荐人费+售后准备金+6% 售后保障费（无售后保障产品由平台兜底）。
③ BTOB 联合开店（经销开店）：H2B 注册采购商经企业申请、平台确认成为经销商，按线下谈妥后的单一售价 ¥1300 卖给下游小 B；下游小 B 可直接进 BTOB 官方入口注册下单，也可扫码进入；日企承担日本化核规费用，平台收佣金+推荐人费+售后准备金。
决策层反复强调「H2B / BTOB / BTOC 前端用户互相独立」，这里需要按最新口径拆开：前端登录态、访问权限、渠道资格互相独立；后台企业资料可关联复用；H2B 强制管理员审核后可见；BTOB 买家开放浏览、注册后下单。
图 3 ｜ 三层认证：三端前端登录态与权限独立，后台企业资格关联，H2B 与商品上架必须审核
目标：拉新企业商户入驻（中国供方 / 日方采购方 / 大客户）。
收益：平台从实收佣金中让利给推荐人，与商户永久绑定，特定期限享分成。
层级：B2B（商户层），按企业维度归因。
✅ 后端底座已实现，前端接入待产品化
目标：推广商品销售（选品库挑货 → 个人货架 → 推广码带货）。
收益：商品销售推广佣金，按推广码 / 末次点击归因。
层级：B2C（消费者层），按商品 / 订单维度归因。
✅ 后端已实现 🚧 前端在建
推荐人拉的是「企业」（B2B，长期绑定），网红推的是「商品」（B2C，按单归因）。两者复用同一套分账底座，但独立运营、互不干扰——产品上不要把它们混成一个「推广系统」。
这三个是现有平台完全没有、团队也从未接触过的全新能力。本节用大白话讲清「是什么、为什么、里面什么逻辑」，配流程图和例子。
AI 门禁＝商品上架前的「安检关卡」；核规整改（本期线下化）＝不达标商品由管理员审核把关，整改未完成不予通过（线上仅放介绍页，实际整改线下对接服务商、线下收费）；企业私用专区＝大客户的「私密采购 VIP 室」。三者串起来：门禁卡住不合规商品 → 引导去整改专区花钱修好 → 修好的商品才能进各渠道（含大客户私用专区）。
中国供方把 AI 商品上传到 H2B 时，平台在上架前自动跑一道「安检」，检查这件商品是否「能在日本正常用 + 符合日本法规」。不达标就拦住，不能上架。
中国 AI 产品直接丢到日本，常出问题：① 到日本连不上网 / 服务器被墙 ② AI 大模型在日本不可用（变砖头）③ 全中文界面日本用户看不懂 ④ 违反日本出口 / 电波 / 认证法规 ⑤ 没有日文说明书和合规标签。门禁就是提前把这些「坑」挡住，保平台声誉与合规。
① 海外联网：在日本能正常联网 ② AI 模型可用：依赖的 AI 大模型在日本可调用 ③ 界面多语言：至少有日文 / 英文界面 ④ 出口合规：符合中日出口管制 ⑤ 本地化资料：日文说明书、认证凭证、包装标签齐全。
自动通过（五项达标）→ 上架；人工复核（部分需人判断）→ 平台管理员审核；拦截 + 引导整改（明显缺项）→ 引导完成核规整改（线下，线上仅介绍页），整改未完成不予通过。
智核科技上传「AI 美容仪」，门禁自检发现缺日文说明书 + 缺 PSE 认证凭证（第五维不达标）→ 自动拦截 → 提示「请完成核规整改后再提交，整改未完成审核不通过（线上仅介绍页，实际整改线下对接服务商）」→ 商品暂存、不上架，由管理员审核跟进。
本期核规整改走线下：线上只放一个介绍页（扫码可看核规整改说明），不建线上整改服务商城、不下服务订单、不自动回填凭证。流程为：商品提交 → 后台审核 → 管理员联系商家跟进整改 → 整改未完成则审核不通过。实际整改由商家线下对接服务商、线下收费（对公转账/微信），缴费承担由审核员人工判断登记。
门禁仍是商品上架前的安检关卡：不达标商品被自动拦截，必须整改完成、由管理员审核通过后才能上架——拦截的「卡点」作用不变，只是整改动作放到线下、不依赖线上商城。
整改费用由审核员按商品目标渠道人工判断、登记责任归属（系统本期不做自动分流）：
缴费方式：对公转账 / 微信（线下），由审核员人工判断并登记付款方与承担方。
智核的美容仪要做整改（日文说明书 + PSE），线下服务费 ¥38000。HTOB 直接采购 → 中方出 / 线下处理；BTOC 联合开店 → 日企负责核规事项、中企出费用（线下结算，可从后续平台服务费扣）；BTOB 联合开店 → 日企负责并承担费用。同一件商品、同一笔费用，目标渠道不同，付款人就不同，由审核员人工判定登记。
说明：服务商城子域 / 整改服务市场 / 服务项目目录 / 服务订单 / 整改凭证回填门禁等均属后期概念，本期不做。
BTOB 里给大客户（连锁店、集团、大型批发商）开的「私密采购专属入口」。大客户用独立密码进入，看到的是只给自己定制的商品目录和价格，别人看不到。
大客户采购有特殊需求：① 要定制商品组合和私密入口 ② 不想让竞争对手看到自己的采购目录 ③ 需要线下谈妥的合作条件和后台确认的单一售价。普通 BTOB 满足不了，所以要单独开「VIP 室」。
① 独立密码入口（每个大客户一个专属入口，区别于普通 BTOB 登录）② 专属商品目录（只展示给该大客户）③ 后台确认的单一售价（不做数量分层自动定价）④ 来源优先（专区商品主要来自 H2B；大客户上传 H2B 之外的独立产品须过平台审核才可见）。
日本「樱花药妆连锁」是大客户，平台给它开专属密码入口。它登录后看到的是后台确认后的 AI 美容仪单一售价和履约说明；普通 BTOB 买家看到普通商品页。价格差异不由系统按数量自动计算，而是双方线下谈妥后由后台维护。
三概念串联：门禁安检 → 不达标完成线下整改（缴费由审核员人工判定）→ 修好回门禁 → 达标进各渠道（含私用专区）
本部分面向开发 / 架构师，按领域建模语言（不暴露具体代码路径与内部代号）讲清改动地图、改动大小、底层起点与依赖顺序、分阶段路线。
| 能力领域 | 现有状态 | 新蓝图要求 | 性质 | 大小 | 建议方案（可降级） |
|---|---|---|---|---|---|
| 分账 / 佣金引擎 | ✅ 完整 | 沿用 + 新增核规整改费/售后准备金/6% 售后保障费/中方代收 | 复用 | 小 | 直接做 |
| 跨境支付连接 | ✅ 完整 | 沿用（日方 Stripe 自动打款） | 复用 | 小 | 日方直接复用 Stripe |
| 资金代收与打款（中方） | 部分 | 中方款项平台代收 + 后台绑卡 + 财务月结手动拨款 | 新增 | 中 | 月结手动即确定方案（见 D11） |
| 联合开店协议层（joint_agreement） | ✅ 代发+自营历史实现 | 退化为协议层：仅协议同意标记，不复制产品；停用 linked listing/forked product/镜像代发；BTOC 套壳壳店保留坑位费百分比条款 | 改动 | 中 | 保留协议字段，停用产品复制链路；费用走核规整改费/坑位费快照/售后准备金/6% 保障费 |
| 企业 / 商家 / 客户实体 | ✅ 完整 | 后端底座复用；前端登录态、访问权限、渠道资格按 H2B / BTOB / BTOC 独立；BTOB 买家不新增后台审核 | 改动 | 中 | 新增三端权限边界，不拆后端企业模型 |
| H2B 采购商可见性门禁 | 🚧 需补齐 | 普通访客不可查看；H2B 采购商注册后管理员审核，通过后才可浏览商品 | 新增 | 中 | 先用审核状态字段 + 前端路由守卫 + API 权限校验 |
| 路径渠道守卫 | 🚧 需补齐 | BTOC 联合开店仅壳店、BTOB 联合开店仅经销商；直接采购不派生到下游商城 | 新增 | 中 | 在发布 workflow / API 层校验 joint_agreement 类型与 sales_channel_ids |
| BTOC 联合开店壳店协议 | ❌ 无 | 仅平台指定壳店可签 joint_agreement_btoc，日企自主发布、报价栏即网红选品库 | 新增 | 小 | 先做 allowlist 配置；后台人工维护壳店名单即可 |
| BTOB / H2B 店铺归属展示 | 部分 | 店铺只显示对应商家的产品，联合开店商品同样按店铺归属展示 | 改动 | 中 | 商品查询增加 store/vendor ownership filter |
| 商品 / 店铺分享二维码 | 部分链接能力 | 商品和店铺都可以生成分享二维码，二维码不能绕过审核与渠道权限 | 补齐 | 小 | 复用现有链接/推广码能力，补店铺二维码与权限落点 |
| 网红店铺 | 🚧 后端已有推广底座 | 网红必须拥有店铺，推广商品进入自己的网红店铺成交 | 补齐 | 中 | 前端工作台补店铺、货架、商品/店铺二维码 |
| 商家入驻审核流程 | ✅ 完整 | 沿用作为「升级」基础 | 复用 | 小 | 直接做 |
| BTOB 联合开店经销能力 + BTOC 壳店协议 | 部分具备 | H2B 审核采购商可申请 BTOB 联合开店经销能力；BTOC 联合开店仅平台指定壳店可签协议 | 调整 | 中 | 复用 seller profile + 渠道底座，补 joint_agreement 协议标记和后台标识 |
| BTOB 经销商二次发布工具（二维码导流 + 产品导出） | ❌ 无 | 经销商商品/价格管理 + 二维码扫码导流（跳转到自有平台下单，走自有系统逻辑）+ 产品导出（图片/字段，供日企自传电商平台） | 新增 | 中 | 不做 API 同步 / 手动录入回写 / 成交回写 BTOB 网店 / 代下单（后期概念） |
| AI 国际化门禁 | ❌ 无 | 发布前置校验五维度 | 新增 | 大 | 可降级：管理员人工逐件审核五维度 |
| 核规整改：本期线下化（线上仅介绍页 + 审核拦截） | ❌ 无 | 线上仅放介绍页；商品审核由管理员把关，整改未完成不予通过；缴费责任按目标渠道（HTOB 中方出/线下；BTOC 中企出费用；BTOB 日企承担）由审核员人工判断登记 | 新增 | 小 | 服务商城为后期概念，本期不做 |
| 企业私用专区（密码鉴权） | ❌ 无 | 专属入口 + 定制可见性 | 新增 | 中 | 可降级：现有专属渠道 + 价格清单 + 手动开户替代 |
| 推荐人招商系统 | ✅ 后端 referrer 模块与 workflow 底座已建 | 补前端入口、业务接入、报表和运营配置 | 补齐接入 | 中 | 可降级：初期线下登记推荐关系 + 财务手动算佣金 |
| 网红推广 | ✅ 后端 / 🚧 前端 | 补全前端工作台 + admin | 改动 | 中 | 后端已实现，补前端即可 |
| 三销售前台 / 渠道隔离 | ✅ 完整 | 沿用，强化资格过滤 | 改动 | 小 | 直接做 |
本平台尚未上线，正是「先用最小开发把业务跑通、验证需求」的好时机。原则：
改动必须自下而上：先建数据模型，再建资格与审核流，最后才是门禁、专区、前台。乱序会导致反复返工。
图 4 ｜ 改动依赖链（自下而上）：L0 复用 → L1 BTOB 经销商工具与 BTOC 壳店协议 → L2 门禁/整改 → L3 专区/售后保障/推荐人 → L4 前台。箭头＝下层支撑上层；同层多块为并列项
最新口径下，后台企业/商家主体可共用，三端前端登录态、访问权限和渠道资格独立；H2B 采购商审核通过后才可查看商品。联合开店已退化为纯协议层（joint_agreement），所以第一步不是重写联合开店，而是补齐H2B 可见性门禁、joint_agreement 类型到 sales_channel_ids 的路径渠道守卫、BTOB 经销商二维码导流 + 产品导出工具、BTOC 壳店协议白名单。
| 建模要素 | 说明 | 关联现有 |
|---|---|---|
| 后台资格关联规则 | H2B 日方采购商审核通过后，可申请 BTOB 联合开店经销能力（经企业申请、平台确认），但 BTOB 前端用户与 H2B 前端用户独立 | 复用 seller profile，新增 joint_agreement_btob 协议标记 |
| 渠道协议标记 | BTOC 联合开店仅平台指定壳店可签 joint_agreement_btoc；BTOB 联合开店仅 H2B 注册采购商可申请 joint_agreement_btob；渠道底座按协议类型限制 sales_channel_ids | 现有渠道底座复用，新增 joint_agreement 守卫 |
| BTOC 上架审核开关 | 联合开店店 + 普通店统一配置上架审核开关；日企可正常在 BTOC 开店 | 沿用现有审核状态机，统一开关 |
| BTOB 经销商二次发布工具（二维码导流 + 产品导出） | 经销商商品/价格管理 + 二维码扫码导流（跳转自有平台下单，走自有系统逻辑）+ 产品导出（图片/字段，供日企自传电商平台） | 新增工具层；不建回写接口、不做 API/代下单（后期概念） |
| 资格与角色绑定 | 同一企业在 H2B 是采购方，在 BTOB 是联合开店经销商，在 BTOC 是壳店经营方（若被指定） | 关联现有角色权限 |
| 续期 / 变更 | 资格有效期到期提醒、资质变更触发复审（有效期后台动态可配） | 新增提醒机制 |
本平台尚未上线，不存在老数据与老企业，因此无需任何迁移兼容策略——所有企业直接走新资格模型，从 H2B 审核可见开始，再按路径开通 BTOB 联合开店经销能力或 BTOC 壳店协议。这反而简化了设计，不用维护新老两套逻辑。
田中（客户实体，复用）→ 提交田中商事资料 → 审核通过生成 企业实体（复用）+ 田中获商家身份（复用入驻流程）→ 田中商事申请 BTOB 联合开店经销资格（新增 joint_agreement_btob 协议标记 + 审核流）→ 通过 → 田中商事在 BTOB 拥有「卖家」角色，按线下谈妥后的单一售价发布产品（联合开店仅协议层，不复制产品）。全程复用 6 项，新增 1 个协议标记模型。
蓝图的「三种交易路径」在新口径下都退化为协议层标记 + 渠道发布：联合开店不再驱动产品复制，linked listing / forked product / 镜像代发全部停用，仅保留 joint_agreement 协议同意标记。
| 蓝图交易路径 | 现有工程对应 | 改动 | 要点 |
|---|---|---|---|
| ① H2B 直接采购跨境 | 普通跨境交易（购物车 + 跨境结算） | 复用 | 仅加门禁 + 佣金项 + HTOB 合规中方出/线下 |
| ② BTOC 联合开店（壳店协议） | 协议层 joint_agreement_btoc（新增标记，停用镜像） | 改动 | 仅壳店可签；按线下谈妥后的单一售价发布；报价栏即网红选品库；6% 售后保障费兜底 |
| ③ BTOB 联合开店（经销开店） | 协议层 joint_agreement_btob（新增标记，停用 linked listing） | 改动 | H2B 注册采购商→经销商；按线下谈妥后的单一售价发布；提供 BTOB 官方入口注册下单、二维码导流和产品导出（不做成交回写） |
联合开店退化为纯协议层后，不再需要镜像同步、改价失效再重发、关系级模式锁定等复杂机制：日企在各渠道按线下谈妥后的单一售价发布，平台只守门审核 + 按渠道收平台佣金；推荐人从平台佣金让利；BTOC 网红费由商家/商品毛利承担并由平台代结算；售后准备金按配置切分（BTOC 另收 6% 售后保障费）。历史 linked listing / forked product 代码保留但不再驱动新链路。
在商品发布工作流挂扩展点（hook），五维度前置校验：
① 海外可联网 ② AI 大模型可用 ③ 操作界面多语言 ④ 出口合规 ⑤ 本地化资料齐全
三档处理：自动判定拦截 / 人工复核 / 引导整改。建议与整改专区共用同一套规则，避免两套标准。
本期不建服务商城子域。线上只放一个核规整改介绍页（扫码可看说明）；商品提交后由管理员审核跟进，整改未完成则审核不通过。实际整改由商家线下对接服务商、线下收费（对公转账/微信）。业务逻辑与例子见 P7 · 概念二。
缴费责任（谁付整改费，已决策，线下判定）：按商品目标渠道由审核员人工判定——HTOB 直接采购中方出/线下；目标 BTOC 联合开店则核规日企负责事项、中企出费用（线下结算，可从后续平台服务费扣）；目标 BTOB 联合开店则日企负责并承担费用（线下结算）。商品模型仍预留「目标渠道」字段供审核员参考。服务商城 / 服务订单 / 凭证回填门禁为后期概念，本期不做。
① 专属入口：每个大客户独立密码入口（区别于普通 BTOB 登录）。
② 定制可见性：商品 / 价格按大客户维度过滤，不同客户看到不同目录和后台确认的单一售价。
③ 来源优先：专区商品主要来自 H2B；大客户上传 H2B 之外的独立产品，须过平台审核才可见。
❌ 全新 复用现有「销售渠道 + 价格清单」做可见性过滤，新增「密码入口 + 客户维度可见性」。价格仍是后台确认的单一售价，不做数量分层自动定价。
| 引擎 | 后端 | 前端 | 与蓝图衔接 |
|---|---|---|---|
| 🌟 网红推广 | ✅ 已实现（归因+分佣+结算+打款底座） | 🚧 在建（网红工作台、供应商选品 opt-in、admin） | 直接作为 BTOC 带货飞轮，补全前端即可 |
| 🔑 推荐人招商 | ✅ 后端已实现（referrer 模块 + workflow 底座） | 🚧 待接入（前端入口、业务配置、报表） | 补齐产品化接入，计佣基数为平台佣金 |
网红后端底座（9 张数据表 + 归因引擎 + 状态机 + 分佣公式 + 结算 + 打款）已经落地，可作为推荐人系统的参照蓝本——推荐人复用同一套分账底座，只是归因维度从「商品」换成「企业」。
图 5 ｜ 分阶段路线（按依赖排序，工作量大小见 D1 热力图）。Phase 0 是硬前置，不可跳过。
这是金额敏感的核心规则，日方与中方走完全不同的资金通路，务必先对齐。
资金流向：日方 Stripe 默认自动、异常可手动管理；H2B 中方跨境款进入第三方持牌托管账户，验货合格后按账期结算到中方账户
① 中方代收：中方相关订单款项不直接付给中方，而是进平台收款账户；② 中方绑卡：后台支持中方录入 / 留存银行卡（注意合规，不要明文存储）；③ 月结拨款：财务后台需「按月汇总中方应收 → 生成拨款单 → 手动确认拨付」能力；④ 日方沿用 Stripe 自动化，无需新建。
8 月上线时间紧，原则：核心交易链路程序保证，其余「审核 / 资格 / 合规 / 招商 / 专区」全部人工兜底先跑起来，几乎零新增模块。
8 月上线只需保证「一笔跨境交易能跑通 + 钱能收能分」。关键区分：企业 / 产品的「申请、提交、资料留存」走线上程序（有入口、能提交、留记录），只有「审核、判定、合规检查」走人工。处置图例：✅ 程序＝复用现有；🟡 线上申请+人工审核＝提交线上、审核人工；🚫 人工/线下＝全程人工。其余智能功能先人工顶上，跑通后补程序。
| 功能 | 8 月处置 | 人工怎么做 | 上线后补 |
|---|---|---|---|
| AI 国际化门禁（产品合规） | 🟡 提交线上/审核人工 | 供方线上提交商品 → 管理员人工审五维度合规（检查清单打勾） | 量上来补自动判定 |
| 核规整改（线下） | 🚫 不开发线上商城 | 本期纯线下：线上仅介绍页 + 管理员审核拦截；线下对接整改服务商，微信 / 对公转账收费 | 量上来建服务商城 |
| 缴费承担判定 | 🚫 不开发自动分流 | 审核员人工判断谁付款（看商品目标渠道）并登记 | — |
| 三端前端用户独立 | 🟡 必做 | H2B / BTOB / BTOC 登录态与权限互相独立；H2B 必须审核通过后可见 | 后续可做统一企业关系视图 |
| H2B 商品上架审核 | 🟡 提交线上/审核人工 | 供方线上提交商品 → 管理员人工审核 → 只对审核通过 H2B 采购商展示 | 量上来补自动门禁 |
| BTOB / BTOC 非 H2B 商品审核 | 🟡 审核人工 | 不是 H2B 源头派生的商品，上传后必须管理员审核 | 后续补规则引擎 |
| BTOC 联合开店（壳店协议） | 🟡 白名单人工 | 仅平台指定壳店开通，日企自主发布、报价栏即网红选品库 | 试点结束后再产品化 |
| BTOB 联合开店（经销开店） | ✅ 底座复用 + 守卫新增 | H2B 注册采购商→经销商，自主发布到 BTOB；售后准备金 + 6% 保障费率后台可配 | 补渠道守卫与报表 |
| 店铺 / 商品二维码 | 🟡 补齐 | BTOB、H2B、网红店铺和商品都可生成二维码，进入对应店铺或商品页 | 补二维码管理与统计 |
| 企业私用专区 | 🟡 申请线上/配置人工 | 大客户线上申请 → 管理员人工配专属渠道 + 价格清单 | 量上来建密码专区 |
| 推荐人招商 | 🟡 注册线上/佣金人工 | 商户线上扫码注册（复用）+ 绑定推荐人 → 财务用表格算佣金 | 规模上来建佣金系统 |
| 售后保障兜底（6%） | 🚫 不开发（线下兜底） | 平台找日本服务保障公司线下兜底，向无售后保障卖家收 6% 保障费（后台动态可配） | 量上来建自动化兜底 |
| H2B 中方托管结算 | 🟡 状态记录 | 第三方持牌托管账户 + 验货合格后按账期结算；平台后台记录托管、验货、放行、结算状态 | 可补结算单管理 |
| 商品上架（H2B） | ✅ 程序 | 复用现有 + 人工审核入口 | — |
| H2B 直接采购跨境 / BTOB 联合开店 | ✅ 程序 | 复用现有交易链路 | — |
| 日方 Stripe 支付 | ✅ 程序 | 复用跨境支付连接 | — |
| 网红推广 | 🚧 简化 | 后端已有，前端先上简化版 / 人工配推广码 | 补全前端工作台 |
| BTOC 联合开店（壳店协议） | 🚫 不开发（协议层） | 仅协议同意标记（joint_agreement_btoc），按线下谈妥后的单一售价发布，报价栏即选品库；走人工维护壳店白名单 | 补全协议流与后台人工管理能力 |
纯人工兜底只适合上线初期小规模验证。一旦商品 / 商户 / 订单规模上来，人工会崩（审核积压、算错账、漏拨款）。建议"上线后补自动化"按业务量触发：哪个环节先撑不住，就先补哪个的程序——而不是按固定时间表。
用一支 AI 美容仪，把上面所有新逻辑串起来跑一遍，看看每个环节复用 / 新增了什么。
图 6 ｜ 全链路：招商 → 门禁 → 整改 → 过审 → 路径选择 → 协议层开店 → 网红带货 → 分账
① 推荐人招商（后端底座已实现，前端接入待产品化）｜② H2B 上架（复用）｜③ 国际化门禁（新建）｜④ 核规整改（线下·介绍页 + 审核拦截）（新建）｜⑤ 路径选择（H2B 直接采购复用/BTOC 联合开店协议层/BTOB 联合开店协议层）｜⑥ 联合开店协议层 + 路径渠道守卫（新增）｜⑦ BTOB 经销商二维码导流 + 产品导出工具（新建）｜⑧ 网红带货（后端已实现）｜⑨ 分账结算（日方复用/中方代收）
身份双轴（渠道 × 角色）+ 三种交易路径 + 中日双资金通路，原本在很多接缝处会产生「谁来做、钱从哪走、责任归谁」的错位与闭环断裂。最新口径下，联合开店退化为协议层（日企自营，不再用镜像复制驱动分账），绝大多数错位随之消解；BTOC 套壳壳店保留按订单百分比计算的坑位费，并归入动态可配参数 + 订单快照。下面逐条标注落点。
网红选品库的佣金设置权：原「借壳托管」模式下佣金设置权反转到中国供方、资金通路错配。新口径下联合开店=日企自营：BTOC 壳店按线下谈妥后的单一售价发布，报价栏即网红选品库；网红费用由商家/商品毛利承担，平台只做代结算，不再有「中方付日方网红」的错配，也避免平台佣金被网红费吃穿。资金通路统一：联合开店订单=日企自营订单，货款归日企（日方 Stripe 默认自动、异常可手动管理），平台收平台佣金+推荐人费+售后准备金（BTOC 另收 6% 售后保障费），网红费从商家毛利中扣除并由平台代结算；中方仅在中国供货的 H2B 跨境采购环节通过第三方持牌托管账户结算。
原错位：借壳模式下佣金设置权反转到中国方、资金通路错配。新口径：BTOC 壳店由日企自主发布、报价栏即网红选品库。
已决策 网红费用由商家/商品毛利承担，平台只做代结算，不从平台佣金中扣；网红费率后台动态可配，并必须有毛利护栏。
原断裂：网红（日方）佣金由中国方承担，中日双通路对不上。新口径：联合开店退化为协议层，取消镜像/复制驱动的旧内部分账；BTOC 套壳壳店坑位费作为协议费用按订单快照单独计算。
已取消 联合开店订单=日企自营订单，货款归日企（Stripe 自动），平台收平台佣金；推荐人从平台佣金让利；售后准备金按配置切分（BTOC 另收 6% 售后保障费）；网红费由商家毛利承担并由平台代结算；中方仅在中国供货的 H2B 跨境采购环节结算。
新口径下联合开店为日企自营：店铺法律主体=运营主体=日企，消费者看到的日企店即实际经营者，不再有「出壳/借壳」分离。
已决策 售后/税务/消费者权益责任归日企；日本《特定商取引法》标示与日企主体一致。HTOB 产品合规中方出/线下。
原链路：中国方付日方坑位费，跨中日双通路中转。新口径：联合开店退化为协议层，但平台内部指定的 BTOC 套壳壳店保留坑位费。
已决策 坑位费仅适用于 BTOC 套壳壳店，按订单实付金额百分比计算，比例后台可改；下单时与 joint_agreement、承担方、收款方一起写入订单费用快照。BTOB 经销开店默认无坑位费，除非未来单独配置。
原漂移：借壳 BTOC 中国方控价、加价 BTOB 日方控价。新口径：联合开店为日企自营。
已决策 BTOC 壳店、BTOB 经销商与 H2B 直接采购均展示单一售价；日本化改造、合规整改和底价线下谈妥后，由中国侧商务或平台运营在后台维护售价或确认订单价。
推荐人永久绑「企业」，企业有多份渠道资格。
已决策 推荐人佣金按企业维度计：推荐中国供方/H2B 采购商/BTOB 联合开店企业入驻后，其平台成交额按比例计佣金（比例后台动态可配）。
整改费按交易路径确定付款方：HTOB 直接采购中方出/线下；BTOC 联合开店核规日企负责事项、中企出费用（可从后续平台服务费扣）；BTOB 联合开店日企负责且承担费用。BTOC 壳店协议商品只能上架 BTOC，BTOB 经销商品只能上架 BTOB。
已定规则 联合开店为协议层、不复制产品；日企在各渠道自主发布独立商品、独立审核、独立结算。
资格审核通过 ≠ 角色就绪。H2B 采购资格→BTOB 联合开店经销能力（经企业申请、平台确认），BTOC 壳店协议→仅平台指定壳店。
已定规则 资格通过后，由后台按审核结果关联开通对应渠道能力，并保留运营可控和审计记录。
原断裂：借壳订单退款跨境退货成本高。新口径：BTOC 联合开店为日企自营订单，售后由日企负责；平台层兜底。
已决策 3 平台成交佣金都要切售后准备金份额；6% 售后保障费（可调）对无售后保障产品由平台找日本服务保障公司兜底、向卖家收。准备金/保障费率后台动态可配。
买家定金/尾款 → 第三方持牌托管账户 → 验货合格后按账期结算给中方。托管期间资金法律归属、放行条件和退款条件需明确。
业务说明 托管资金法律定性、对账凭证、利息归属、单方不可动用、验货不合格退回退款，作为合规运营流程文档化，与金额参数无关、不阻塞开发。
联合开店退化为协议层后，「日本分销商↔中国供方」「借壳」「镜像代发」三类关系已取消；保留以下关系并钉死基数，避免数据模型与分账混乱。
| 关系 | 已决策基数 | 影响 |
|---|---|---|
| 推荐人 ↔ 企业 | 1 企业只能 1 推荐人（唯一，企业维度） | 防佣金争抢、归属清晰 |
| 网红 ↔ 商品 | 1 商品多网红 / 1 网红多商品（多对多，推广码归因） | 推广码归因、佣金分摊 |
| 大客户 ↔ 私用专区 | 1 专区 1 客户（专区隔离、价格保密） | 专区隔离、价格保密 |
| 企业 ↔ 渠道资格 | 1 企业最多 3 份（H2B / B2B / B2C，已定） | — |
| 日企 ↔ joint_agreement 协议 | 1 日企可签 0..1 份 BTOC 壳店协议 + 0..1 份 BTOB 经销协议 | 协议标记、渠道守卫 |
| 规则 | 已决策落点 / 动态可配 | 为什么重要 |
|---|---|---|
| 推荐人佣金有效期 | 动态可配（默认 12 月后永久，后台可调） | 平台长期成本 |
| 网红归因窗口 | 动态可配（默认末次点击 cookie 30 天，后台可调） | 归因准确性、争议 |
| 整改服务定价 | 线下协商定价（本期不做线上服务商城，无平台指导价/服务商报价机制） | 线下收费、人工登记 |
| 资格有效期 | BTOB 联合开店经销资格随 H2B 采购资格有效期同步；BTOC 壳店协议单独续期；有效期后台动态可配 | 续期运营、过期处置（宽限期+提醒，不立即冻结） |
| 商品发布规则 | 联合开店退化为协议层，停用 linked listing / forked product；日企按渠道资格发布，价格为线下谈妥后的单一售价，分别审核与结算 | 上架流程、门禁范围 |
| BTOB 下游触达 | 已明确：P0 做商品/店铺海报二维码、采购意向、产品导出和自有平台导流；不做平台内代下单或成交回写 | 经销触达、线索归因 |
| BTOB 二次发布 API / 成交回写 | 明确为后期企业定制概念，本期不做（本期二次发布＝二维码导流到自有平台 + 产品导出，无回写闭环）；后期 API 同步、订单状态回写的范围随客户实施细化 | 开发排期、客户实施成本 |
| 订单渠道边界 | H2B / BTOB / BTOC 前端、商品池、购物车和结算天然隔离；一个商品销售版本只属于一个目标销售渠道，不存在跨渠道混单，也不规划跨渠道购物车 | 结算、发货、退款冲正 |
| 货币与汇率 | 中日交易结算货币？汇率何时锁定？（金额敏感，随跨境支付选型落地） | 金额敏感、汇损 |
| 税务与关税 | 日本消费税由日企交（联合开店=日企自营）；跨境关税随 HTOB 合规中方出/线下处理 | 合规、成本 |
| 售后准备金 / 6% 保障费 | 动态可配（3 平台成交佣金都切售后准备金份额；6% 售后保障费向无售后保障卖家收、平台兜底，比例后台可调） | 资金切分、兜底成本 |
| 下架级联 | 联合开店为协议层、无镜像；日企自主发布的商品下架只影响其自身店铺，已下单按成交时口径履约 | 数据一致、订单履约 |
| 价格变更 | 双方线下谈妥后由中国侧商务或平台运营后台维护售价/确认订单价；已生成订单按成交时价格 | 价格一致、争议 |
这 10 个缺口根因是同一个：身份双轴（渠道 × 角色）只定义了「谁」，没定义「钱和责归谁」。建议动工前补一张「交易路径 × 角色 × 资金通路 × 责任主体」四维矩阵，把每种组合下的「定价权、佣金承担方、打款通路、售后责任、税务主体」一次性钉死。这张表不定，上面每个点都是雷——而且实现时爆出来的现象（佣金算错、钱对不上账、售后扯皮）很难倒查回这几个根因。
最新拍板后，原待确认点已全部落定。联合开店退化为协议层（日企自营，不做镜像复制链路）消解了大部分错位；BTOC 套壳壳店坑位费按订单百分比保留；金额类参数统一为后台动态可配并在下单时快照（默认值见下，先跑通不阻塞开发）；流程类为已决策落点。
| 关系 | ✅ 已决策落点 | 说明 |
|---|---|---|
| 推荐人 ↔ 企业 | 一对一（唯一，企业维度） | 归属唯一，防佣金争抢 |
| 网红 ↔ 商品 | 多对多 | 符合传播特性，按推广码归因互不冲突 |
| 大客户 ↔ 私用专区 | 一对一 | 私密定制本质，价格保密与专属体验 |
| 日企 ↔ joint_agreement 协议 | 0..1 BTOC 壳店 + 0..1 BTOB 经销 | 协议层标记，驱动渠道守卫 |
| 已取消：联合开店（日方↔中方）、借壳（中方↔壳）、镜像代发（1 货↔分销商）——联合开店退化为协议层，无产品复制。 | ||
| 规则 | ✅ 已决策落点 | 说明 |
|---|---|---|
| 推荐人佣金有效期 | 动态可配（默认限时 12 月后永久） | 让推荐人持续拉新，同时控成本 |
| 网红归因窗口 | 动态可配（默认 30 天末次点击） | 行业惯例 |
| 整改服务定价 | 线下协商（本期不做线上服务商城） | 线下对接、人工登记 |
| 资格有效期 | 动态可配（默认 1 年 + 提前 30 天提醒，宽限期不冻结） | 契合企业资质年审节奏 |
| 商品发布规则 | 联合开店协议层，按线下谈妥后的单一售价发布 | 停用 linked listing / forked product；日本化改造和最终价格在线下确认 |
| 核规整改费承担 | 按目标渠道分流（HTOB 中方出/线下；BTOC 中企出费用可从服务费扣；BTOB 日企承担） | 责任与渠道对齐 |
| 售后准备金 | 动态可配（3 平台成交佣金都切份额） | 覆盖售后成本 |
| 6% 售后保障费 | 动态可配（默认 6%，向无售后保障卖家收、平台兜底） | 平台找日本服务保障公司兜底 |
| 订单渠道边界 | 不做跨渠道混单，不需要按渠道拆单 | 前端与商品销售版本按渠道隔离，订单天然单渠道 |
| 货币与汇率 | 日元结算 + 下单锁汇（金额敏感，随跨境支付选型落地） | 日本消费者用日元最自然 |
| 税务与关税 | 消费税日企担（联合开店=日企自营）、HTOB 关税中方出/线下 | 符合日企自营法律结构 |
| 下架 / 价格变更 | 后台维护单一售价，无下游级联，已生成订单按成交时口径 | 协议层无镜像，无级联问题 |
| 缺口 | ✅ 已决策落点 | 说明 |
|---|---|---|
| ① 网红佣金设置权 | 网红费用由商家/商品毛利承担，平台代结算 | 消解原「中方付日方网红」错配，也避免平台佣金被网红费吃穿 |
| ② 借壳佣金资金通路 | 旧链路取消（不再用镜像/复制/linked listing 驱动内部分账） | 订单=日企自营，货款归日企；套壳坑位费作为协议费用单独计算 |
| ③ 法律 vs 运营主体 | 日企自营，法律主体=运营主体 | 售后/税务/消费者权益归日企 |
| ④ 坑位费资金中转 | 保留为协议费用（仅 BTOC 套壳壳店，按订单百分比） | 后台可改比例，下单时写入订单快照；BTOB 默认无坑位费 |
| ⑤ 价格口径 | 单一售价 | 线下谈妥最终价格后由后台维护，不做数量分层自动定价 |
| ⑥ 推荐人绑定粒度 | 绑企业维度，按平台成交额计佣 | 绑定简单、边界清晰 |
| ⑦ 商品销售版本 | 联合开店协议层，日企按渠道自主发布独立商品 | 无产品复制，单渠道责任清晰 |
| ⑧ 商家渠道资格 | 商家主体统一，BTOB / BTOC 资格分开审核 | 复用 seller/profile 底座，控制渠道越权 |
| ⑨ 资格 → 角色映射 | 审核通过后关联开通对应渠道能力（带审计） | 减少手动操作、防漏 |
| ⑩ C 端跨境退款 | 售后准备金 + 6% 售后保障费覆盖 | 3 平台佣金切准备金；无保障产品平台兜底 |
| ⑩ 代收资金所有权 | 业务说明（非金额参数）：独立托管、归属中方、平台代管 | 合规防挪用，作为运营流程文档化 |
最新口径统一遵循：① 联合开店=日企自营协议层（取消 linked listing/forked product/镜像复制驱动的旧内部分账）；② BTOC 套壳壳店保留坑位费（按订单实付金额百分比，后台可改，订单快照固化）；③ 金额参数全部后台动态可配（佣金率/坑位费率/服务费/准备金/6%/有效期/结算周期，先跑通不阻塞开发）；④ 责任边界按渠道划清（HTOB 中方、BTOC 中企出费用日企负责事项、BTOB 日企承担）；⑤ 平台兜底售后（3 平台佣金切准备金，6% 保障费覆盖无保障产品）。此口径下可大幅降低运营纠纷、对账复杂度与合规风险，最有利于快速上线。
2026-07-06 老板拍板后，原待确认清单已全部落定。金额类参数统一为后台动态可配（先跑通不阻塞开发，临上线前由业务微调）；流程类为已决策落点。下表按原清单序号映射新落点。
| # | 类型 | 事项 | 已决策落点 | 属性 |
|---|---|---|---|---|
| 1 | 已决策 | 渠道资格与商品发布守卫 | H2B 采购商审核可见；BTOB 联合开店仅 H2B 注册采购商可申请；BTOC 联合开店仅平台指定壳店；联合开店协议层日企自主发布 | 流程 |
| 2 | 动态可配 | H2B 直接采购跨境佣金承担方 + 比例 | 平台收取，默认比例后台动态可配（先跑通） | 金额 |
| 3 | 已决策 | 套壳开店坑位费计算规则 | 仅 BTOC 平台指定套壳壳店收坑位费；按订单实付金额百分比计算，后台可改并写入订单快照；BTOB 默认无坑位费 | 金额 |
| 4 | 已决策 | 三种交易路径能否中途切换 | 联合开店为协议层、不复制产品；新签协议按新路径发布，已有订单按成交时口径结算 | 流程 |
| 5 | 已决策 | 中方「月结手动拨款」对账与凭证机制 | 作为运营流程文档化（周期/凭证/绑卡留存），不阻塞开发 | 流程 |
| 6 | 已决策 | 门禁与整改五维度规则合并 | 合并为一套合规校验，随门禁模块上线持续细化 | 流程 |
| 7 | 已决策 | 核规整改具体判定标准清单 | 按目标渠道分流责任（HTOB 中方出/线下；BTOC 中企出费用日企负责；BTOB 日企承担），清单随门禁模块上线细化 | 流程 |
| 8 | 已取消 | 托管模式「改价直同步」新建分支 vs 扩展镜像 | 联合开店退化为协议层，无需镜像同步/改价直同步；日企自主发布、自主改价、无下游级联 | 流程 |
| 9 | 动态可配 | 佣金 / 核规整改费 / 售后准备金 / 6% 保障费结算周期与比例 | 全部后台动态可配（默认月结 + 最低起付额；准备金份额、6% 保障费率、推荐人/网红费率均可调） | 金额 |
| 10 | 已决策 | 资格过期对在用资格的处置 | 宽限期 + 续期提醒，不立即冻结；有效期后台动态可配 | 流程 |
费率、承担方、准备金份额、6% 保障费率、结算周期、有效期等均为动态可配置参数，先跑通不阻塞开发，临上线前由业务拍板微调即可。原"金额不定则分账无法落地"的阻塞已解除。
日方支付与分账链路基本复用（中方资金代收为新增）；真正的工作量集中在资格模型（L1，硬前置）、门禁+整改、售后保障兜底、推荐人招商、中方代收打款五块新增逻辑。建议排期：直接启动 Phase 0 资格模型与 joint_agreement 协议层，金额参数并行后台可配化，其余按依赖链推进。