Odoo 企业版 POS 租赁为什么不是“前台扫序列号收钱”而已：lot 回写与已交付数量对账讲透

租赁商品一旦带 lot/serial，POS 收银和后台租赁履约就不能各记各的；否则前台扫过的设备，后台看起来却像没交付。

核心链路

1. models/pos_order.py 的 _process_order() 在父类处理完 POS 订单后，会遍历订单行：只要该行关联 sale_order_line_id、商品 rent_ok，且 tracking 不是 none，就把 POS 上录入的 pack_lot_ids.lot_name 搜成 stock.lot，回写到销售行 pickedup_lot_ids。
2. 这一步非常关键，因为 POS 前端记录的是“我扫了哪些序列号”，而销售租赁线后续履约、归还、损坏追踪需要的是标准 stock.lot 记录。
3. models/sale_order_line.py 中 _prepare_qty_delivered() 又进一步修补 delivered qty。注释已经直说：这里复制了 sale_stock_renting 和 pos_sale 的逻辑，就是为了防止 POS 侧写进去的数量被租赁库存逻辑覆盖掉。
4. 当租赁拣货逻辑开启时，它会先统计 outgoing moves 的 done 数量；若该销售行关联的 POS picking 全部完成，且产品不是 service，还会把 POS 行数量折算后叠加进去。
5. 换句话说，这个模块做的不是“让 POS 支持租赁”这么宽泛，而是把 lot 回写和 delivered qty 口径对齐，避免收银、库存、租赁三条线各说各话。

关键源码位置

• /home/ubuntu/odoo-temp/enterprise/pos_sale_stock_renting/models/pos_order.py
• /home/ubuntu/odoo-temp/enterprise/pos_sale_stock_renting/models/sale_order_line.py

容易误解的地方

• 误区一：POS 扫到序列号就够了。后台租赁线还需要 pickedup_lot_ids 才能继续追踪。
• 误区二：delivered qty 只看 stock picking。这里还要叠加 POS 行数量，避免口径被覆盖。
• 误区三：所有租赁商品都一样处理。源码只在 rent_ok 且 tracking 生效时才做 lot 回写。

实战注意事项

• 门店租赁设备一旦需要序列号追踪，就要强制培训店员在 POS 正确扫 lot，别让字段空着过单。
• 若后台发现 delivered qty 异常，先查 skip_pos_rental_pickings_check 和 POS 相关 picking 是否都 done。
• 序列号搜不到时，不要只怪 POS；也要检查 stock.lot 是否提前建档、命名是否与扫码值一致。

结语

企业版这些代码共同说明一件事：真正可上线的业务流程，靠的不是“页面上看起来能点通”，而是权限、状态、时机、对账口径和跨模块回写都被收紧。理解这些边界，实施和二开时就不容易走进“功能演示能跑、真实业务一用就散”的坑。