门店帮客户预约最怕两件事：前台约上了，后台资源却没留住；或者客户联系方式没带过去，后续通知全断。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/pos_appointment/models/calendar_event.pyenterprise/pos_appointment/models/appointment_type.pyenterprise/pos_appointment/tests/test_pos_appointment_flow.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
企业版 pos_appointment 并不是简单把 appointment 放进 POS 菜单里。它把预约资源、waiting list 容量、客户电话与后台 booking 视图打通，让门店预约既能快速创建，也不会绕开原有 appointment 的资源校验。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 pos_appointment 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. POS 不是绕过 appointment 引擎
calendar_event._appointment_resource_domain()、_load_pos_data_domain() 说明 POS 端看到的预约数据仍受资源域限制，前台不是随便写一条 event，而是在 appointment 的可预约边界内操作。
2. waiting list 是容量治理，不是装饰字段
_compute_waiting_list_capacity() 与 attended/cancelled 状态方法表明，门店创建预约后，是否还能补位、如何释放容量，都跟事件状态同步，而不是只在 UI 上显示“候补”两个字。
3. 电话透传决定后续运营是否接得住
测试 test_prepare_calendar_event_values_phone_number 专门验证 phone number 进入 event values，说明官方知道门店代预约后，联系信息必须无损带到后台，否则提醒、改期、到店确认都会失真。
三、最容易被误解的边界
- 以为 POS 建预约等于直接建 calendar.event；其实它仍受 appointment type、resource domain 和候补容量限制。
- 忽略电话透传，导致预约成功但后续通知链断掉。
- 只看 POS 下单是否成功，不看 attended/cancelled 后 waiting list 是否及时释放。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查 appointment type 的资源配置是否允许该门店场景。
- 再查 calendar_event 的 waiting_list_capacity 与状态切换。
- 最后核对 POS 创建的 event values 是否带上 phone、partner 等关键字段。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
理解了这一点，就会知道 pos_appointment 不是给收银员加一个日历按钮，而是把门店预约纳入同一套资源调度与客户联系链。
DISCUSSION
评论区