Odoo 企业版库存分析为什么不是“把 picking 列出来再 group by”：stock.report 的 delay、cycle time 与 backorder 指标边界讲透

库存分析最常见的误解，是把它看成 picking 列表加几个筛选器。企业版的 stock.report 明显不是这么做的。

主要参考：

• enterprise/stock_enterprise/report/stock_report.py

一、stock.report 是 SQL 视图，不是普通业务模型

_auto = False 说明它本来就不准备承载业务写入，而是专门用于分析。Odoo 手工拼出 _select / _from / _group_by，最后在 init() 里 CREATE OR REPLACE VIEW。

这意味着：分析口径由视图定义，而不是由前端报表临时拼出来。

二、delay 与 cycle_time 为什么要在 picking 层先算，再挂到 move 上

内部子查询先以 stock_picking 为单位算：

• delay = avg(date_done - scheduled_date)
• cycle_time = avg(date_done - create_date)
• is_backorder = backorder_id IS NOT NULL

然后再 join 回 stock_move。这样做的意义是：执行时效属于 transfer 级别事实，但分析又需要最终落到产品、类别、操作类型等维度上。

三、最容易踩坑的地方

• 它只统计 t.is_storable = true 的产品
• 以 move 为明细粒度，不等于 picking 只有一行
• is_late 本质来自 delay > 0
• backorder 是从 picking 的父子关系判定，不是看用户有没有手工补单备注

四、结论

库存分析的真正价值，在于企业版把“执行事实”和“分析维度”拆开了：时效来自 picking，统计落在 move/product/category 上。明白这层结构，报表口径才不会越看越乱。