很多门店上线后厨屏后，第一反应都是“阶段名字再改一下”“多加一个处理中”。但在营业中的门店，这类修改往往比想象中危险，因为阶段不是装饰文案，而是订单状态机的一部分。
这篇文章主要参考了以下企业版源码入口：
enterprise/pos_enterprise/models/pos_prep_display.py
一、这篇功能真正解决什么问题
pos.prep.display 里的 stage_ids 解决的是门店如何定义自己的出餐流程。但官方没有把它做成一个随手可改的标签集合，而是把它和开放订单过滤、完成判定、平均时长统计绑在一起。正因为这样，营业中修改阶段才会被严格限制。
二、核心链路怎么走
1. 至少要有一个阶段，且最后一个阶段天然代表完成
_check_stage_ids() 先保证 display 至少存在一个 stage；而 _get_open_orderlines_in_display() 与 _compute_order_count() 又都默认最后一个阶段意味着“done”。这说明阶段顺序本身就是业务语义，不能随便插拔。
2. 营业中的 session 会锁住阶段配置
同一个约束方法会去找关联 pos.config 的 session，只要发现有 opened 的 session，就直接抛 ValidationError，阻止修改阶段。原因很朴素：订单正在流转时改阶段，相当于半路改状态机，会让未完成单、已完成单和统计值全都失真。
3. 指标计算依赖阶段定义
order_count 来自“未到最后阶段的订单数”；average_time 则要取同一 display 范围内订单从创建到完成的总耗时。官方甚至连 preset_time 与 closing_control 这种边界都考虑进开放订单过滤里，说明阶段并非 UI 元素，而是指标分母分子的基础。
三、新手最容易踩的坑
- 以为阶段只是看板标题，营业中也能改。实际上它是完成判定条件。
- 以为平均出餐时间是简单取订单表平均值。源码是按 display 可见范围、阶段状态和最后变更时间来算的。
- 以为关闭 session 前后差异不大。事实上很多配置编辑动作就是故意等 session 结束后才放开。
四、实战落地时最该盯的点
- 上线前先把阶段设计谈清楚，别把“边营业边试”当成常态流程。
- 如果门店想新增阶段，优先安排在 session 关闭窗口做，并同步评估历史报表解读方式。
- 排查“计数不准”时，不要只看订单表，要回到 display 自己的 stage 范围和开放订单过滤逻辑。
五、结论
准备屏阶段不能乱改，不是因为 Odoo 保守，而是因为它把执行流程、完成判定和运营指标绑在了同一套 stage 结构上。理解这一点，门店就会知道为什么“多改一个阶段”其实是在改业务语义。
DISCUSSION
评论区