这个模块补的不是“再收一单”，而是把 POS 现场补款、安全核销与客户应收口径绑在一起，避免前台收款和会计应收各算各的。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/pos_settle_due/models/pos_session.pyenterprise/pos_settle_due/models/res_partner.pyenterprise/pos_settle_due/tests/test_receivable_account_reconciliation.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
很多团队以为 POS 里的 settle due 只是把客户未结款项再收一次。但企业版 pos_settle_due 真正补的是一条受控结算链：前台先按 special products 表达“结清/预存/发票结清”意图，再把 partner 的 total due、未结清 move line 与 session 内收款对上，最后按客户维度完成应收核销。少看任何一段，都会把“补收欠款”做成“越收越乱”。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 pos_settle_due 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. special products 不是普通商品
pos_config.py 会为结清、预存、发票结清准备专门商品，pos_order_line._is_settle_or_deposit() 再把这些行识别成结算语义，而不是正常销售收入。这样前台动作才能被后端当成“清账意图”而不是“卖货行为”。
2. 客户 total due 不是静态数字
res_partner.get_total_due() / get_all_total_due() 会把 POS 欠款、发票欠款和前端加载口径统一起来；tests/test_total_due_frontend.py 还专门覆盖了即时更新、局部结清和搜索更多的场景，说明官方把“欠款显示是否同步”当成一等问题。
3. 真正关键的是 session 层核销
pos_session._reconcile_account_move_lines() 与测试里的 _create_settle_order()、_perform_test_customer_account_payment_is_reconciled() 表明，结清动作最后要落到按客户拆开的 move line reconciliation，而不是留下一堆看似收款、实则未核销的分录。
三、最容易被误解的边界
- 误以为 settle due 就是再开一张普通 POS 单；实际上 special line 会改变税基与后续对账逻辑。
- 把不同客户欠款放在同一条结清路径里；官方测试强调 same session 也要按 partner 分开核销。
- 只看前台数字变没变，不看 receivable move line 是否真正 reconcile；这会导致后续催款与账龄仍然异常。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查 pos_config 的结清/预存专用商品是否正确创建。
- 再查 partner total due 接口返回是否和后台 open invoices / unsettled POS orders 一致。
- 最后核对 session 关账后的 receivable lines 是否被正确 reconcile，尤其是有 credit note 和跨 session 场景。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
所以，POS settle due 的价值不在“门店也能催收”，而在它把前台补款翻译成一条可核销、可追踪、不会污染销售收入口径的会计链路。
DISCUSSION
评论区