卖服务最容易掉进的坑是：订单卖出去了，但交付班次不是没人可接，就是已经生成却没人维护。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/sale_planning/models/sale_order_line.pyenterprise/sale_planning/models/sale_order.pyenterprise/sale_planning/tests/test_sale_planning.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
sale_planning 处理的是服务销售和排班系统之间的契约：什么产品能计划、按什么 role 找人、已售工时如何拆成 slot、何时还能取消或回收未分配班次。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 sale_planning 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. 是否可排班由产品与角色共同决定
product.py 会计算 planning_enabled，planning_role.py 又强制角色工时单位一致；这说明能否计划不是订单确认瞬间拍脑袋，而是产品先声明可被规划、员工角色再决定谁能接。
2. 工时不是确认后机械平铺
sale_order_line._compute_planning_hours_to_plan()、_planning_slot_generation() 与 tests 里的 default role / previous slot 场景表明，系统会结合历史班次、分配比例与 role 去生成可执行班次。
3. unassign deadline 守的是交付纪律
planning_slot._compute_unassign_deadline() 与 sale_order._unplanned_shift_deletion() 说明，未分配班次可以回收，但不能无限拖；这既是资源治理，也是避免订单卖出后永远挂着未交付工时。
三、最容易被误解的边界
- 把服务销售当成普通 SO，不提前设计 product role 与 planning_enabled。
- 确认订单后手工随便建班，导致 sale line 和 planning hours 对不上。
- 忽略 unassign deadline，最后未分配班次长期滞留，交付统计失真。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查产品是否开启可排班且角色设置正确。
- 再核对 sale line 的 hours_to_plan / hours_planned。
- 最后检查未分配班次是否被 deadline 或取消动作正确清理。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
sale_planning 的关键，不是“确认订单自动生几条 slot”，而是让已售服务工时以可追踪、可回收、可分配的方式进入交付排班。
DISCUSSION
评论区