很多餐饮项目把“桌台配置”当成后厨平面图问题，但 pos_restaurant_appointment 把它提升成了资源治理问题。每张桌子背后都对应 appointment.resource，因此 create、write、unlink 都会改变预约子系统能不能继续识别这张桌。
主要参考源码：
enterprise/pos_restaurant_appointment/models/pos_restaurant.pyenterprise/pos_restaurant_appointment/models/appointment_resource.py
一、建桌台时其实同时在建预约资源
create() 并不是只插一条 restaurant.table。若桌台还没有 appointment_resource_id，系统会自动创建资源，把桌号、座位数和关联的 appointment type 一起挂进去。
这一步让 POS 桌台正式成为预约系统中的可预订资源。
二、停用和删除不是同一件事
write() 里如果写了 active=False，对应资源会被同步停用；重新激活时又会刷新资源名和容量。unlink() 则更重，直接删除 appointment_resource_id。再加上 @api.ondelete 的 _delete_linked_resources()，模块显式保证桌台被删时不会遗留孤儿资源。
三、前台为什么会受影响
appointment_resource._load_pos_data_domain() 只会把当前 POS 已加载桌台关联的资源送到前台。如果资源没被正确停用、删除或更新，POS 仍可能加载到错误桌台；反过来，如果 cleanup 做对了，前台资源集合会自动收缩。
四、真正的跨模块链路
- 餐饮楼层/桌台配置；
- appointment.resource；
- POS 预约模式的数据加载。
所以“删桌子”不是 UI 收拾干净这么简单，而是要把资源层和前台加载层一起带走。
五、结论
企业版 POS 餐桌配置的重点不是画桌子，而是桌台对象如何持续代表一个可预约资源。建桌时要自动建资源，停用时要同步资源状态，删除时要连同 linked resource 一起清掉，前台预约加载才不会失真。
DISCUSSION
评论区