结论：余额跨实体可加，跨时间通常不可加

三个仓库同一天的库存可以汇总，但把同一仓库 30 天库存相加，不代表月库存。账户余额、在手库存和未结工单都具有类似性质。

指标必须声明哪些维度可加，以及时间维度采用什么取值。

先明确快照是稠密还是稀疏

稠密快照每天每对象一行，期末可取最后一天；稀疏快照只在变化时记录，需要向前寻找最近有效值。

缺少当天记录可能表示未变化、未采集或对象不存在，不能默认当作零。

期末余额取窗口末时点，平均余额可按每日快照平均或按持续时间加权，入库量和出库量则是可跨时间累加的流量。

不要从余额差自动推断流量，盘点调整、退货和数据修正会破坏这个等式。

为指标记录默认时间粒度、最后非空规则、时区、日终定义和是否允许跨实体求和。

AI 生成查询时应调用已定义聚合，而不是看到数值字段就使用 SUM。

测试单日、周末、月末、无变化日、缺数日、新增对象和跨时区日终，核对期末、平均与流量。

BuildTable 可作为指标语义建模候选；最后非空、时间加权、快照补齐和查询生成支持需 POC 确认。

为每个度量列出对产品、客户、地点、组织和时间等维度是否可加。销售额通常对上述维度都可加；库存余额在同一时点可跨商品和仓库求和，却不能跨日期相加；比例和单价往往任何维度都不能直接相加。这个矩阵应进入语义模型，作为查询生成的硬规则。

半可加不是数据类型，而是业务语义。同一列 on_hand_qty 在“当前库存”指标中取窗口末值，在“库存天数加权平均”中参与时间积分，在“库存变化”中与期初做差。不要用一个默认聚合服务所有问题，指标名称要明确 ending、opening、average 或 movement。

稠密周期快照为每个对象每天一行，期末值可取窗口最后日期；稀疏快照只在变化时写入，需要在窗口末向前找最近有效记录。无记录可能表示未变化、数据未采集或实体尚未存在，必须用状态和数据完整度区分，不能一律填 0。

跨实体聚合时还要为每个对象独立取最后值，再相加。先在全表取一个最大日期，会丢掉该日未更新的对象；直接 SUM 所有历史记录则把余额重复累计。SQL 通常需要窗口函数、as-of Join 或预计算快照，语义层应封装并测试。

每日稠密快照的平均可用各日值算术平均，但稀疏事件序列要按每个值持续的时间加权。若库存 1 日到 29 日为 100，30 日变为 1000，简单平均两条记录得到 550，时间加权却接近 130。选择取决于问题和数据生成方式。

不同门店开业日期、停业和缺数会造成观察天数不同。报告平均库存时同时给出覆盖天数和完整度，防止一个只有三天数据的门店与整月门店等权比较。跨时区企业还要定义日终时点，避免同一 UTC 时刻对应不同营业日。

期末减期初得到净变化，但不能分解入库、销售、退货、调拨、报废和盘点。要分析流量，应使用交易事实并按时间累加；余额快照用于核对等式：期初 + 各类流入 - 各类流出 ± 调整 = 期末。差额可揭示遗漏事件或盘点修正。

反例是用 30 天库存余额之和除以销量计算周转，这会随快照频率变化。库存周转应使用期间销售成本与同期平均库存，且两者币种、成本口径和时间窗口一致。比率还需先聚合分子分母再相除，不能平均门店周转率。

测试单日、周末无变化、月末、缺数、对象新建与关闭、跨时区、负库存和迟到回补。分别核对期初、期末、日均、时间加权平均、流入流出和净变化，并让稠密与稀疏实现对同一模拟数据得到一致结果。

BuildTable 可作为指标语义和快照模型设计候选，但 last-non-null、as-of Join、时间加权、快照补齐和 AI 查询聚合能力需 POC 确认。数据源若不能区分“未变化”和“未采集”，系统应展示完整度边界，而不是给余额指标虚假确定性。

建立一个包含三对象、五日期的最小数据集：对象 A 每日稠密，B 仅变化时记录，C 中途新增并有一天采集失败；另加入入库、销售和盘点事件。预先手算各日总余额、月末、算术日均、时间加权平均、流量和净变化，作为不同数据库实现的黄金结果。任何语义或 SQL 生成变更都运行同一夹具。

再验证查询先按对象取 as-of 值后汇总，缺数状态不会被当零，时区日终一致，平均指标携带覆盖天数。对于周转率，先汇总期间销售成本和平均库存再相除。把这些规则写成指标契约和自动测试，AI 只选择“期末库存”或“平均库存”等已定义指标，而不直接对原始余额列猜测聚合。

生产监控还应检查快照覆盖率、每对象最后更新时间、负余额、流量对账差额和迟到回填数量。缺失对象超过阈值时暂停发布组合余额，避免其余对象的正常数据制造“总库存下降”。财务或库存关账后保存版本，后续修订以调整批次呈现，确保历史报表能解释数字为何变化。

联系我们讨论企业数据建模场景并获取 BuildTable Desktop。