Odoo 企业版 POS 自助点餐为什么不是“下单后立刻进后厨”：付款闸门、取消边界与备餐屏补充字段讲透

餐饮门店最怕的不是订单少，而是“客人点了、后厨做了、最后又没付”。企业版自助点餐把进后厨这一步做成了可配置闸门。

核心链路

1. 在控制器 controllers/orders.py 中，process_order() 先走自助点餐原始流程，再调用 _send_to_preparation_display()。这说明“创建 POS 订单”和“把订单推给备餐屏”是两步。
2. _send_to_preparation_display() 明确写了条件：如果 POS 配置没有有效的自助支付方式，就所有单都进备餐；否则只有 state == "paid" 的订单才进入 pos.prep.order.process_order()。企业版是在这里卡住未支付订单。
3. 模型 models/pos_order.py 里 _send_order() 也会再次触发 process_order(self.id)；而 _load_pos_preparation_data_fields() 额外加载 table_stand_number，确保后厨屏看到的是带桌号/取餐位信息的订单，而不是一串无上下文的菜品。
4. can_be_cancelled() 会去查是否已经生成 prep order，并结合 _get_preparation_displays() 判断当前订单是否已经进入备餐体系。只要进了备餐屏，前台撤单就不再是纯前端操作，而会被拒绝。
5. models/pos_prep_display.py 又补了纸张状态同步：change_paper_status() 改 POS 配置，_paper_status_change() 把 PAPER_STATUS 广播给 preparation displays。它解决的是“出单设备没纸但后厨屏还在继续等单”的现场问题。

关键源码位置

• /home/ubuntu/odoo-temp/enterprise/pos_self_order_preparation_display/controllers/orders.py
• /home/ubuntu/odoo-temp/enterprise/pos_self_order_preparation_display/models/pos_order.py
• /home/ubuntu/odoo-temp/enterprise/pos_self_order_preparation_display/models/pos_prep_display.py

容易误解的地方

• 误区一：自助点餐一下单就一定进后厨。是否需要先付款，取决于 has_valid_self_payment_method()。
• 误区二：撤单总是前台说了算。进入 prep display 后，取消会被 remove_order() 拦下。
• 误区三：备餐屏只需要菜品明细。企业版还会把 table_stand_number、POS 配置和纸张状态一并纳入。

实战注意事项

• 上线前一定要和门店确认：自助订单是“先付后做”还是“先做后付”，因为源码已经把两种模式区分开了。
• 若门店投诉无法撤单，优先查该订单是否已生成 pos.prep.order，不要只看 POS 前端状态。
• 自助点餐 + 备餐屏调试时，最好同时开浏览器网络面板和后端日志，确认 process_order 与 PAPER_STATUS 两条通知都在工作。

结语

企业版这些代码共同说明一件事：真正可上线的业务流程，靠的不是“页面上看起来能点通”，而是权限、状态、时机、对账口径和跨模块回写都被收紧。理解这些边界，实施和二开时就不容易走进“功能演示能跑、真实业务一用就散”的坑。