先说结论
很多人第一次看 Odoo 维修单，都会嫌它字段太多：
- 产品来源库位
- 修后去向库位
- 加件去向
- 拆下件去向
- 回收库位
- 再加一个
under_warranty
但这些不是表单噪音，而是在回答一个很现实的问题：
维修不是“数量从 A 到 B”，而是同一件物品周围会同时发生多种相反方向的库存动作。
为什么维修单不能只用两个库位
如果只有“来源”和“目标”两个库位，系统无法讲清：
- 新加的零件从哪里取、装到哪里
- 拆下来的旧件是报废、回收、待分析还是返还客户
- 修好的整机最终去哪
repair.order 正是把这些语义拆开，所以你会看到：
location_id：组件来源product_location_src_id：待修物来源product_location_dest_id：修后成品去向location_dest_id：新增零件的目标位置parts_location_id：拆下件默认去向recycle_location_id：回收件去向
这不是复杂，而是对维修现场的尊重。
可用性检查为什么也和普通出库不一样
在 action_validate() 里，Odoo 不只是简单看库存够不够。它会同时检查：
- 指定 lot
- 指定来源库位
- owner = 客户
- owner = False
然后判断待修品数量是否足够。
这说明维修单默认考虑到一个现实场景：待修品可能属于客户，也可能已经回到公司名下。
如果你忽略 owner 语义，就很容易出现“系统明明有货却说不能修”的错觉。
under_warranty 为什么不是展示字段
under_warranty 会直接影响 _update_sale_order_line_price()：
- 如果保修内，相关新增零件销售行价格会被写成 0
- 否则走正常价格计算
所以保修标记不是客服备注，它会改变收费逻辑。
也正因此，Repair 和普通库存调整不同：它天然带着服务履约与商业责任。
最容易被忽略的两个边界
1. 新增件和拆下件不是一进一出就完了
新增件的库存去向、拆下件的处理方式、回收件的归位，都可能影响后续库存可见性和成本解释。
2. 待修品的 owner 很关键
尤其在售后、寄修、代保管场景里，库存归属与实物所在不一定是同一层概念。
最常见的误区
1. 以为这些 location 可以随便抹平
抹平以后，系统很难解释旧件去了哪、新件怎么装上去。
2. 以为保修只影响报表备注
它直接影响价格。
3. 以为维修可用性只看仓库数量
lot、owner、来源库位都可能影响验证结果。
4. 以为 Repair 是轻量库存调整
其实它是“库存 + 服务 + 收费”三层叠加。
排错顺序
如果维修单出现“库存不够”“价格不对”“旧件去向混乱”，按这个顺序查：
- 待修品来源库位和 owner 是否正确
- lot / serial 是否绑对
- 新增件与拆下件的去向库位是否分清
under_warranty是否影响了销售行价格- 最后再看操作类型默认库位是否配置错
一句话记忆法
Odoo 维修单的多库位设计，不是在增加复杂度，而是在把维修现场真实发生的多方向动作说清楚。
DISCUSSION
评论区