租赁最怕“看起来都按天算”，实际现场却充满 overnight、超时、部分归还和价格不该重算的边界。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/sale_renting/models/product_pricing.pyenterprise/sale_renting/models/sale_order_line.pyenterprise/sale_renting/tests/test_rental_processing.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
企业版 sale_renting 真正困难的地方不是租出去，而是如何把时长、夜间计费、延迟归还、部分取还货和价格更新规则统一成一套可解释的租赁语义。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 sale_renting 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. pricing rule 先定义时长语义
product_pricing._compute_duration_vals()、_get_first_suitable_pricing() 与 unique_night_period 约束说明，系统先决定“这段时间算几个租赁单位”，然后才谈价格。
2. 订单状态会反过来限制日期编辑
tests/test_rental_schedule.py 覆盖了已提货后开始日期锁定、已归还后结束日期锁定，说明租赁不是任意改时间就重算，而要受物流状态约束。
3. late fee 是独立后处理，不是覆盖原价
test_add_late_fee 与 test_late_fee_allow_buffer 表明延迟费用要在原租赁逻辑之外追加，而且还能有 buffer，而不是把原订单重新定价。
三、最容易被误解的边界
- 把租赁当普通报价，忽视 duration unit 和 overnight 规则。
- 货已经部分提走还随意改起始时间，最后配送与计费脱节。
- 延迟归还直接重算主订单价格，而不是走 late fee 追加路径。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查产品适用的 pricing samples 与 suitable pricing。
- 再核对 pickup / return 状态是否锁定了日期字段。
- 最后检查 late fee 是否按 buffer 与差额追加，而非重写原租赁单价。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
租赁真正复杂的不是“租多长时间”，而是系统要同时尊重时间语义、物流状态和补价边界；这正是 sale_renting 的核心价值。
DISCUSSION
评论区