先说结论
Odoo 的维修单（Repair Order）和拆解单（Unbuild Order）不是一对同义词。
它们看起来都像“处理坏件”，但回答的问题完全不同：
- 维修单：这件东西还作为“原产品”存在，只是要修、换件、回收部分零件后再交回去
- 拆解单：这件东西作为成品身份要被反向拆开，退回组件层
所以你要先问的不是“哪个按钮都能做”，而是：
这次业务的目标，是恢复原物，还是撤销原物。
维修单为什么更像服务 / 返修流程
repair.order 里有很明显的结构：
- 被维修产品本体
- 新增零件 move
- 拆下零件去向
- 回收零件去向
- 是否保修内
- 与销售单 / 退货单的绑定
这说明 Repair 的核心不是“拆 BOM”，而是围绕一个待修物展开换件、返还、收费、责任归属。
它甚至专门区分多个库位：
- 产品来源库位
- 修好后成品去向
- 新加零件去向
- 拆下零件去向
- 回收零件去向
这是一条服务型、过程型链路。
拆解单为什么更像逆向制造
mrp.unbuild 关注的是：
- 以哪张 MO 或哪份成品记录为依据
- 要把成品拆回哪些组件
- 追溯链如何反向连接
- 相关 consume / produce moves 如何生成
它的本质是：把一个“已成为成品”的东西重新分解回组件结构。因此重点是 BOM、move、lot、追溯，而不是维修责任和收费语义。
为什么很多团队会用错
因为现场口头都会说“这个坏了，拆一拆 / 修一修”。但系统对象必须分清：
适合 Repair 的情况
- 更换某个零件后，产品本体还叫原来的那件
- 要记录保修、收费、客户返回、返修责任
- 要区分拆下件是报废、回收还是保留
适合 Unbuild 的情况
- 成品身份本身不再保留
- 目标是回收组件库存
- 要按 BOM / lot 追溯逆向展开
用错对象会带来什么问题
如果本该维修却走拆解：
- 你会丢失换件、收费、保修这些语义
- 现场难解释“修完后交回的是谁”
如果本该拆解却走维修：
- 你会得到很多服务流程字段
- 却得不到真正的逆向 BOM 组件回流逻辑
最常见的误区
1. 以为 Repair 就是“轻量版 Unbuild”
不是。两者目标不同。
2. 以为 Unbuild 更底层，所以都能覆盖
也不对。它不天然覆盖维修收费、保修和返还语义。
3. 以为维修后的旧件去哪里不重要
Repair 恰恰非常强调 removed parts 和 recycle location。
4. 以为两者差别只在界面
差别在库存 move、追溯和业务责任模型。
排错顺序
当业务说“这单到底该用维修还是拆解”，按这个顺序问：
- 产品修完后还保留原身份吗
- 目标是换件返还还是拆回组件
- 是否涉及保修 / 收费 / 客户退回
- 是否需要明确 removed parts 与 recycle 去向
- 是否必须沿 BOM 和 lot 做逆向追溯
一句话记忆法
Repair 是修好并交回原物，Unbuild 是撤销成品并退回组件。
DISCUSSION
评论区