概念模型与实体关系

为了准确支撑业务逻辑，本系统不采用简单的“CRM（客户管理）”模型，而是采用 “以品牌为锚点的三方协作模型”。本主要阐述核心实体的关联关系及数据边界。

1. 实体关系图

下图展示了系统核心对象之间的逻辑关联。

这是本系统区别于普通 CRM 的核心设计。系统不记录 “BD 拥有达人”，而是记录 “BD 在某个品牌下拥有达人”。

实体对象：Cooperation (合作关系)
唯一性约束：
- 数据库级别必须保证 (brand_id, creator_id) 的唯一性。
- 业务含义：在同一个品牌下，达人只能被一个 BD 认领。
多品牌并行：
- 达人 Tony 可以同时存在两条 Cooperation 记录：
  1. 品牌 A (Anker) + 达人 Tony + BD 张三
  2. 品牌 B (Shein) + 达人 Tony + BD 李四
- 结论：达人的状态（已合作/公海）是相对于品牌而言的，而不是全局的。

为了适应 TikTok 复杂的电商生态，我们将“营销维度”和“交易维度”解耦。

维度	实体	职责	关联逻辑
营销维度	品牌 (Brand)	承载达人关系、排他性规则、跨商家合作。	达人归属于品牌。
交易维度	店铺 (Store)	承载商品库存、订单交易、资金结算。	视频产生的GMV来自店铺。

场景举例：BD 在推广品牌 “X”，寄送样品时，系统会列出该商家下所有绑定了品牌 “X” 商品的店铺（Store 1, Store 2），供 BD 选择从哪里发货。

该模型解决了“货主”与“渠道”的数据共享与隔离问题。

系统不再使用单一的倒计时，而是基于 Cooperation 表中的 protection_stage 字段动态计算 release_deadline。

计算公式： release_deadline = last_action_time + GetProtectionDays(team_id, protection_stage)

CONTACT (建联/维护)：
- 场景：Status=MANAGED 且无活跃寄样单。
- 对应规则：
  - “已建联合作未寄样”
  - “达人历史已有发布视频未再次寄样/未履约新视频”
- 默认天数：15天。
SAMPLING (寄样中)：
- 场景：存在状态为 SHIPPED 或 DELIVERED 但尚未关联视频的寄样单。
- 对应规则：
  - “已寄样未履约”
  - “达人历史已有样品未履约”
- 默认天数：35天。
FULFILLED (刚履约)：
- 场景：最近一次动作是 Video_Linked。
- 对应规则：
  - “履约后未重新寄样或二次履约视频”
- 默认天数：35天。

为了满足“不同商家设置不同保护期”的需求，需要引入配置表。

实体：TeamConfig
字段：
- days_contact_stage: 建联期天数 (默认15)
- days_sampling_stage: 寄样期天数 (默认35)
- days_fulfilled_stage: 履约后保护天数 (默认35)

需拆分为两部分存储以满足隔离需求：

Creator_Public (公共档案)
- 来源：TikTok API
- 字段：tiktok_id, handle, follower_count, category
- 可见性：全平台共享，单例模式。
Creator_Private (私有档案)
- 来源：BD 手工录入
- 字段：email, whatsapp, notes, real_name
- 可见性：严格按 (Merchant + Creator) 维度隔离。即便是跨商家合作，乙方填写的 Email，甲方也不可见，反之亦然。

用于计算提成的核心表。

为了开发便利，统一实体的生命周期枚举：

Cooperation Status (合作状态)

系统不再维护复杂的中间状态，而是基于**“归属权 (Ownership)”** 二元状态进行管理。

状态值	业务含义	权限逻辑
1: MANAGED	我的达人	独占读写。该 BD 拥有对该达人（在该品牌下）的独家开发权，能查看私密信息、创建寄样单。
0: POOL	潜在达人 (公海)	公共只读。无归属 BD。任何 BD 均可查看基础画像，并可发起“认领”动作将其转为 MANAGED。

Sample Order Status (寄样状态)