Odoo 企业版 POS 结清客户欠款为什么不是“前台补收一笔钱”而已：special products、总欠款口径与分客户对账链路讲透
很多团队以为 POS 里的 settle due 只是把客户未结款项再收一次。但企业版 pos_settle_due 真正补的是一条受控结算链：前台先按
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
Odoo POS 跨收银台共享挂单为什么不是“大家都能看到同一张草稿”：trusted config、currency 校验与 open orders 同步边界讲透
很多人把 Odoo POS 的共享挂单理解成“把草稿单广播给别的收银台”，但 point_of_sale 实际把 trusted config 关系、币种一致性、动态拉单 domain、删除回收和前端 open orders 同步做成了一条完整链路。
Odoo POS 关班分录为什么不是“一单一凭证”：_accumulate_amounts、sale key/tax key 与 receivable 聚合逻辑讲透
很多人以为 POS 关班就是把每笔订单逐条做会计分录，但 point_of_sale 实际先在 session 级别跑 _accumulate_amounts，把销售、税、应收、库存和发票对冲按不同 key 聚合，再统一落账。
Odoo POS 商品配置为什么不是“弹个规格框就完”：variants、自定义属性与 extra price 入单链路讲透
很多人把 POS 商品配置弹窗理解成一个前端交互壳，但 point_of_sale 实际把 attribute 选择、自定义值、extra price 展示、variant 归位和订单行持久化串成了一条完整链路。
Odoo POS 订单号为什么不是“前台随便递增一下”：device identifier、_get_next_order_refs 与追溯链路讲透
很多人把 POS 订单号理解成一个展示给收银员看的流水号，但 point_of_sale 实际把 device identifier、后台 sequence、tracking number 与多设备追溯需求串成了一条编号链。
Odoo POS 挂单为什么有的会拦关店、有的却能留到明天：draft order、preset time 与 close session 边界讲透
很多人以为 POS 关店只看有没有未支付单，但 point_of_sale 实际把今天的 draft 单、未来预订单、取消权限和关班弹窗提示拆成了两套边界。
Odoo 企业版 POS：预约模式为什么只加载未来一天的 booking
pos_appointment 不是把 Appointment 全量塞进 POS。它只把门店眼前需要处理的 booking 窗口装进 session，同时补上电话、等待名单和操作视图，避免前台被历史或远期预约淹没。