Odoo 企业版 POS 结清客户欠款为什么不是“前台补收一笔钱”而已：special products、总欠款口径与分客户对账链路讲透
很多团队以为 POS 里的 settle due 只是把客户未结款项再收一次。但企业版 pos_settle_due 真正补的是一条受控结算链：前台先按
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
Odoo POS 小票二维码为什么能补开发票却又不随便放开：ticket code、access token 与 portal 边界讲透
很多人以为 Odoo POS 小票上的二维码只是一个“补开电子发票入口”，但源码里其实设计了两层访问边界：一层是基于 order access_token 的直达入口，另一层是通过 pos_reference、date_order、ticket_code 三元组找回订单。本文结合 controllers/main.py 与 receipt 源码讲清：为什么这套机制既方便顾客补票，又不会把 POS 订单公开成随便可猜的网页。
Odoo POS 在线支付为什么不是“支付成功就完了”：交易桥接、draft 单保护与入账边界讲透
很多人以为 POS 在线支付只是给订单挂一个 payment link，但 Odoo 真正在做的是“交易对象先落支付模块，再桥接回 POS 支付行，并且在 draft 订单阶段严格防止前端乱写付款”。本文结合 pos_online_payment 源码，讲清 payment.transaction、account.payment、pos.payment 三层对象为什么分开，以及为何 draft 单的在线支付行不能直接从 UI 进来。
Odoo POS 自助点餐为什么不是“扫个码就能下单”：入口鉴权、桌台 token 与 kiosk/mobile 边界讲透
很多人把 POS Self Order 看成一个公开 H5 菜单，但 Odoo 源码真正做的是“配置入口校验 + 运行模式分流 + 桌台上下文绑定 + 默认用户降权执行”。本文结合 pos_self_order 控制器与模型，讲清 access_token、table_identifier、kiosk/mobile 两套入口、默认用户执行上下文，以及为什么自助点餐不是一个彻底匿名的开放接口。
Odoo 餐饮 POS 为什么不是“同桌就一单到底”：table 归并、course fire 与后厨出菜边界讲透
餐饮场景里，很多人以为 POS 桌台单就是一张不断追加的订单，但 Odoo 真正在管理的是“桌台上下文”和“出菜节奏”两条链。本文结合 pos_restaurant 源码，讲清 open order 为什么会按 table 合并、course 为什么要单独建模、fired/fired_date 为什么重要，以及遇到一桌多单、后厨节奏错乱时该怎么排错。
Odoo POS 收银员登录为什么不只是“扫工号进系统”：employee 可见域、角色分层与哈希 PIN 边界讲透
很多人以为 POS 员工登录只是前端做个扫码或输 PIN，但 Odoo 真正在处理的是“谁能看见哪些员工、谁在前台拥有什么权限、敏感凭证能不能明文下发”。本文结合 pos_hr 源码，讲清 employee 域、manager/minimal/cashier 三层角色、barcode/PIN 哈希下发，以及为什么删员工会被活跃会话拦住。
Odoo POS 为什么小票一打印就不让改付款：nb_print、已付款状态与防篡改边界讲透
现场经常有人抱怨：明明只是换个付款方式，为什么 Odoo 在小票打印后就不让改？这不是前端任性，而是 POS 在“已付款 + 已出凭证/票据语义”之后主动收紧可编辑边界。本文从 pos.order.write、nb_print 与支付变更日志讲清 Odoo 为什么要在 printed order 上锁付款，以及正确的补救方式是什么。