如果把所有预约都直接灌进门店 POS，前台很快就会陷入两个问题：今天要处理的预约找不到，几周后的远期预约却一大堆；而且一旦容量变化，等待名单也很难现场解释。
这篇文章主要参考了以下企业版源码入口：
enterprise/pos_appointment/models/pos_session.pyenterprise/pos_appointment/models/calendar_event.pyenterprise/pos_appointment/models/appointment_type.py
一、这篇功能真正解决什么问题
pos_appointment 解决的是门店前台只处理“眼前要接待的预约”。它不是把通用 Appointment 应用照搬到 POS，而是围绕 POS 场景重新定义加载范围、展示字段和操作入口。
二、核心链路怎么走
1. session 明确把 calendar.event 纳入 POS 数据模型
pos.session._load_pos_data_models() 在上游基础上追加 calendar.event，说明预约不是一个外部弹窗，而是 POS 本地数据的一部分。
2. 但加载窗口被严格压在“现在到明天”之间
calendar.event._load_pos_data_domain() 会构建一个时间窗口：只取 start/stop 落在 now 到 day_after 范围内、且匹配当前 appointment_type_id 的事件。这能大幅减少前台噪音，确保收银员看到的基本都是当天近期业务。
3. waiting list 和电话信息会在门店场景下被补齐
_compute_waiting_list_capacity() 会根据资源容量或已预留容量计算等待名单容量；appointment_type._prepare_calendar_event_values() 则会把客户电话补进事件字段。对门店来说，这两件事都很务实：一是方便临时插单，二是方便直接联系顾客。
三、新手最容易踩的坑
- 以为 POS 预约越全越好。门店前台真正需要的是短窗内可处理数据，而不是全历史。
- 以为 waiting list 只是一个独立数字。源码明确让它跟资源容量、预订量联动。
- 以为预约操作必须跳回后台。实际上模块已经给了 kanban、gantt、list、calendar 等门店可触达入口。
四、实战落地时最该盯的点
- 先确认门店预约类型是否配置准确，因为 POS 只会加载该
appointment_type_id对应的数据。 - 如果门店说“明天后天预约看不到”，先别急着当 bug，看看是不是产品设计上就只让 POS 聚焦未来一天。
- 等待名单和资源容量要一起讲给门店，否则一线人员会把“还能排队”和“还能接待”混成一回事。
五、结论
POS 预约模式的关键，不是把预约功能搬进收银台，而是把它压缩成短时间窗口、门店可执行、容量感知的一套前台工作流。对门店来说，这比“看得到全部预约”更有价值。
DISCUSSION
评论区