核心结论：流程结构本身设计合理（业内 Order-to-Delivery 经典模型 + 控制门 + 仓库分流），主要问题集中在数据建模层——配件 / 标签 / 文档用 23 列宽表是反模式，应改子表； Master sheet 还保留 B/L/P 三套并列状态，是 82 个字段冲突的根因之一；责任归属层"做事人"vs"录入人"混淆，需要"字段 owner"制度收敛。
终结原因 字段区分。但语义差别巨大：
SCRAPPED（报废） / SWAPPED（返厂换货） / CANCELLED（订单取消，触发回流到 BRANDED_READY）。Cancel 不应该是终态。订舱 + 中方报关 + 国际运输 + 美国清关 + 关税处理 5 个动作合并成 3 个节点（IN_TRANSIT / BONDED / CUSTOMS_CLEARED）发起 RMA + 签收这 1 个 RMA 流程拆成 2 个节点（RETURN_INITIATED + RETURN_RECEIVED）ACCEPTED（客户已验收）+ PGI_POSTED（系统自动过账），或者明确标注 PGI 是"G6 后自动触发"。Robot · Battery · Remote · USA Power cable · CN cable w adapter · Power supply · Charging dock · foot pads · tools/spare kit · paperwork。
这本质是机器人主档 1 : N 配件的关系，硬拍成 10 列散字段：
RobotAccessory(robot_sn, accessory_type, sn, qty, status, batch_id, received_at, replaced_at)。
配件类型用枚举（Battery / Remote / Cable-USA / Cable-CN / 等）。每个配件可以独立追溯。
Label, body - FCC · Label, body Made in CN · Label, SN Body · Label, SN remote · Label, Battery SN · Label, Inspection Sheet · Label, Shipping box。
7 个合规标签字段，语义都是"这个 label 贴了没"，本质是 1 : N 关系。
RobotLabel(robot_sn, label_type, applied, applied_at, applied_by, evidence_url)。
可以记录每个标签的贴附时间、贴附人、留证照片。
Robotics Sales Agreement · Deposit Transfer Form · Deposit Transfer Contract (Car) · Superone Cocreation · Robotic Cocreation · Shipping Receipts。
6 列文档链接，本质是 1 : N 关系。未来增加文档类型就要改 schema。
RobotDocument(robot_sn, doc_type, url, uploaded_at, uploaded_by)。
doc_type 用枚举管理。可以查"这台机器人的所有文档"。
Status (Build) / Lifecycle Status / Physical Product Status 三套独立状态字段。
源文件 Conflicts sheet 显示82 个字段级冲突，其中大量是"同一台机器人的状态在 4 个上游源里写法不同"。
需求分析.md §5 已经设计了 state-as-node 单字段方案（21 状态值），但 Master sheet 本身没改。
stage（21 状态值）+ health（Normal/Hold/Issue）+ track（Retail/RLE/Rental/...）+ location 四个正交字段替代 B/L/P 三套并列。
需求分析.md §5.3 已给无损映射表。
signed → Signed / lease → Lease / yes → Yes 这种 title-case 修复。
这意味着录入时根本没用 Enum 字典约束，4 个上游源都是 free-text 输入，事后才统一。
created_at / updated_at / created_by / updated_by / version / is_deleted 这种基础审计字段。
字段级"by"字段散落（collected_by / requested_by / approved_by / validated_by / received_by / initiated_by），但没有统一的记录维护时间线。
Status (Build) / Lifecycle Status / Physical Product Status / Logistics Status / Payment / Contract Status / Delivery Status — 有的带 Status 后缀，有的不带Issue / Notes / Comments / Add'l Notes (Shipping) / Note (Pre-Del) / Compliance Notes / Customer Feedback — 命名规则混乱Date ready / Purchase Date / Arrival Date / Expected Delivery Date / Delivery Date — 有的首词大写有的不FF SN (key) / FF SN / Supplier SN — 重复列 + 命名不一致{entity}_{attribute} 全小写下划线（如 robot_status_build / shipping_note / purchase_date），重构时统一改名。
FF SN (key)、第 3 列 FF SN，存的是同一个值。这是 v3 引入的"主键 vs 显示"分离，但对实际数据没意义。
Customer）来自 4 个上游源（Inventory / Pre-Delivery / Lifecycle / Sales），每个源都可以写 — 所以会出现冲突：
12 RESERVED (SO 创建) + 13 PAYMENT_VALIDATED (G5 关键审批) + DA Delivery Approval + 17 ON_RENTAL (租赁) — 销售 + 财务 + 交付 4 个核心节点。
Fiona 一旦休假，整个销售/财务流程卡住。G5 还是硬阻塞，没人替她审批就交付不了。
David Michaelis · Chris Chen。但 OOW 报价是商业决策（涉及给客户报多少钱、能否谈价），应该是销售/商务的职责。
David 是 Service 团队，Chris Chen 推测是 IT Admin。技术人定价业务上不合理。
Hongliang Liu · Mike Domke 标注做 "PGI 过账"。但 PGI 是 SAP 自动事件，本质是系统动作。
实际上 Hongliang/Mike 是触发人（点 PGI 按钮），但收入确认是会计的事 — 责任边界模糊。
| P | 优化项 | 归属角度 | 影响 | 工作量 |
|---|---|---|---|---|
| P0 | BOM 配件 10 列拆子表 | 字段建模 | 扩展性 + 配件追溯能力 | 中（2-3d） |
| P0 | Label 7 列拆子表 | 字段建模 | 合规追溯 + 留证管理 | 中（2-3d） |
| P0 | 文档链接 6 列拆子表 | 字段建模 | 文档管理 + 类型扩展 | 小（1-2d） |
| P0 | 字段 owner 制度（消除字段冲突根因） | 责任归属 | 消除 82 个字段冲突 | 中（流程改造） |
| P0 | Cancel/Scrap/智元换货 拆开 | 流程结构 | 避免账实不符 | 小（1d） |
| P1 | B/L/P 三状态合并为 stage 单字段 | 字段建模 | 消除 50%+ 状态冲突 | 大（涉及 4 上游源改造） |
| P1 | 录入端枚举校验（替代事后清洗） | 字段建模 | 消除 188 次清洗负担 | 中（改 D365 / Excel） |
| P1 | Fiona 单点故障 — 加备份责任人 | 责任归属 | 业务连续性 | 小（组织变更） |
| P1 | 残值再售路径（REPAIRED → BRANDED_READY）画明 | 流程结构 | 残值管理可见 | 小（图改一下） |
| P2 | 补审计字段（created_at / by / version） | 字段建模 | 历史追溯能力 | 小（schema 加列） |
| P2 | 字段命名规范统一 | 字段建模 | 开发体验 | 中（重命名 + 兼容） |
| P2 | 节点粒度统一规则 | 流程结构 | 建模一致性 | 中 |
| P2 | Quote & Approve 责任人增加销售 | 责任归属 | 定价决策合规 | 小 |
| P3 | 区分"人为触发" vs "系统自动" | 责任归属 | 视觉清晰度 | 小 |
| P3 | 删除 FF SN (key) 重复列 | 字段建模 | 清洁度 | 极小 |