餐厅不是零售店：同桌加菜、拆单、分 course、内部备注、已付款但仍未出餐，都会让“显示订单”变成一条长期状态链。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/pos_restaurant_preparation_display/models/pos_prep_order.pyenterprise/pos_restaurant_preparation_display/models/pos_prep_display.pyenterprise/pos_restaurant_preparation_display/tests/test_frontend.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
餐饮场景里的 preparation display 远不只是把 POS 订单贴到电视上。企业版 pos_restaurant_preparation_display 要处理合单、拆单、course、桌台、内部备注和支付后仍需保留的出餐状态，所以它维护的是一套可持续更新的 prep order 模型。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 pos_restaurant_preparation_display 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. prep order 是独立业务对象
pos_prep_order.create()、process_order()、_compute_order_name() 说明后厨屏不是直接渲染 pos.order，而是维护自己的 prep order / prep line 状态。这样才能承接多次修改与厨房回推。
2. 合单拆单是核心，不是附加功能
merge_orders() 与 unmerge_orders() 直接告诉你，餐厅里一张桌的出餐对象会不断重组。若只按第一次下单渲染，后面任何加菜或拆台都会让看板失真。
3. 支付完成不等于后厨流程结束
测试 test_payment_does_not_cancel_display_orders 覆盖了付款后仍保留显示；再加上 notify_pdis() 和 _send_notification_to_preparation_displays()，说明厨房状态要独立于收银状态持续推进。
三、最容易被误解的边界
- 把已付款当成可以从后厨屏移除的信号；餐饮场景往往恰恰相反。
- 忽略 course / table 信息，导致前厅与后厨对同一订单的组织方式不同。
- 只支持首单显示，不支持 merge/unmerge，最终厨房屏内容越来越不可信。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先看 prep_order 是否创建并维护了正确的 line UUID。
- 再查 merge/unmerge 后通知是否推到所有 preparation displays。
- 最后核对内部备注、桌台与 course 字段是否进入 additional info。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
餐饮后厨屏的本质不是“把单据投屏”，而是让厨房拥有一份能跟着现场变化持续演化的订单状态视图。
DISCUSSION
评论区