Odoo 企业版 POS 结清客户欠款为什么不是“前台补收一笔钱”而已：special products、总欠款口径与分客户对账链路讲透
很多团队以为 POS 里的 settle due 只是把客户未结款项再收一次。但企业版 pos_settle_due 真正补的是一条受控结算链：前台先按
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
Odoo POS 预约单为什么不是“选个时间就行”：preset、time slot 与容量控制边界讲透
很多人把 Odoo POS 的 preset 当成前台快捷按钮，但源码里的 pos.preset 其实能同时携带价目表、税制、身份要求、退货模式以及按时间管理订单的容量规则。本文结合 point_of_sale 源码讲清：time slot 如何计算、为什么满额判断不是建一张“时段表”、以及遇到同一时段超卖或不可取消时应如何排查。
Odoo POS 小费为什么不是“加一行服务费”：tip 产品、找零行与已打赏状态边界讲透
很多人把 POS 小费理解成订单尾部加一行金额，但 Odoo 真正在处理的是“这笔金额挂到哪个产品、订单是否已进入 tipped 状态、找零行和真实支付行怎么拆、会计与收银统计要不要把它当独立语义”。本文结合 point_of_sale 源码，把 tip_product、is_tipped 与 payment move 边界讲透。
Odoo 企业版 POS 餐桌配置为什么不是“删一张桌子就结束”：restaurant table、appointment resource 与 linked cleanup 链路讲透
pos_restaurant_appointment 把餐桌和 appointment.resource 双向绑住；桌台创建、停用、删除都会影响前台预约资源加载，不是纯 UI 配置动作。
Odoo 企业版 POS 自助收银台为什么不是“终端成功回调一下就行”：IoT 支付回执、websocket 通道与 kiosk 订单绑定讲透
pos_self_order_iot 在 kiosk 模式下把终端回执、POS 配置 access token 和 websocket 通道绑在一起，确保付款成功/取消都能落回正确自助订单。
Odoo 企业版 POS：并桌、拆单和补推备餐时，准备屏与顾客号牌为什么还能维持同一笔订单连续性
pos_restaurant_preparation_display 通过 prep_order、line uuid 和 notify_pdis 维持内部备餐对象；而顾客侧仍靠 tracking/order 投影读进度，所以 merge/unmerge 后看起来是“一单还在走”，其实背后对象已经重绑。
Odoo 企业版 POS：赊账补款时，旧应收、当前付款和关班分录如何重新对齐
pos_settle_due 的重点从来不是做一笔“补收订单”，而是把 partner 总欠款、发票未结清金额、当班 pay_later 分录与 session closing 的核销重新归到同一口径。