顾客看板最怕“信息太少”与“信息太多”同时出现：太少就没法取餐，太多又把后厨内部状态直接暴露出去了。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/pos_order_tracking_display/models/pos_prep_display.pyenterprise/pos_order_tracking_display/models/pos_prep_state.pyenterprise/pos_order_tracking_display/models/ir_http.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
很多人把顾客取餐屏理解成 preparation display 的只读副本。但 pos_order_tracking_display 实际上重建了一条“可对外展示”的订单状态流：从 prep display 抓订单、按 stage 变化广播，再把可公开的信息投到 customer display，而不是把后厨原始状态直接暴露给顾客。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 pos_order_tracking_display 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. customer display 有独立取数口径
pos_prep_display._get_pos_orders() 与 open_customer_display() 说明对外屏不是直接复用后台列表，而是单独打开一个顾客展示入口，先挑出该展示该看的订单。
2. 状态推进靠消息而不是轮询猜测
_send_orders_to_customer_display() 与 _send_load_orders_message(sound=False, notification=None, orderId=None) 表明，订单变化会被主动广播，顾客屏关注的是“该提醒什么、该响不该响”，不是不停刷新整张后台视图。
3. stage 变化是经过翻译的
pos_prep_state.change_state_stage() 接收 stages 与 prep_display_id，说明真正被展示的是准备链路中的状态切换结果，而不是厨房内部每一个细碎动作。
三、最容易被误解的边界
- 把 customer display 当成后厨显示器的公开版，结果把内部阶段、备注或未准备订单全部暴露。
- 只更新 preparation display，不触发 customer display 通知，顾客端就会停留在旧状态。
- 忽略 frontend translation modules，导致外屏文案与主 POS 不一致。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查 prep display 是否能正确拿到待展示订单。
- 再查 change_state_stage 后是否触发 send_load_orders_message。
- 最后验证 open_customer_display 的公开页面是否只包含面向顾客的信息。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
顾客取餐屏真正值钱的地方，是它把后厨状态翻译成“顾客能看懂、也只该看到这些”的一套公开状态流。
DISCUSSION
评论区