Odoo 企业版 POS 餐厅预约为什么不是“到店就占桌”：calendar event、table 通知与 resource 释放边界讲透

在餐厅预约场景里，“桌子被占”并不是一张状态表的静态结果，而是当天 calendar.event 生命周期持续广播出来的结果。pos_restaurant_appointment 直接在事件 create / write / unlink 上发桌台通知，说明资源占用是事件流的一部分。

主要参考源码：

• enterprise/pos_restaurant_appointment/models/calendar_event.py

一、预约创建时，不是偷偷写状态，而是显式发 ADDED

create() 创建事件后马上 _send_table_notifications(new_events, "ADDED")。也就是说，桌台系统感知预约不是靠后续批处理，而是靠事件创建当下的消息。

二、修改预约时，为什么先 REMOVED 再 ADDED

write() 的顺序非常关键：先对旧事件发 REMOVED，再执行 super，最后对新状态发 ADDED。这意味着改时间、改桌子、改资源时，系统不会假设“前后差一点点没关系”，而是把原占用先撤销，再宣布新占用。

这是典型的状态同步边界处理，可以避免同一预约在前台被看成同时占着旧桌和新桌。

三、删除预约时，资源释放为什么是即时的

unlink() 在删除前就发送 REMOVED。对 POS 营业场景来说，这很重要：如果先删记录再算前台资源，消息链就可能断掉；先发移除通知，前台桌台状态能立即释放。

四、不是所有事件都会推到前台

_send_table_notifications() 还做了两层裁剪：

• 只处理当天事件；
• 只处理 booking_line 关联到当前餐桌资源的事件。

所以这不是“日历全部事件广播到 POS”，而是当天、当前桌台相关、当前 session 可用的公开投影。

五、结论

POS 餐厅预约不是“到店就占桌”，而是calendar.event 生命周期驱动的桌台占用流。创建、改期、取消都要通过 ADDED / REMOVED 通知把资源状态同步给前台，桌台释放也因此具有即时性和边界感。