有好几个月，对"我们到底有什么"这个问题的诚实回答，是一组来自各处的数字：格式不一致，时间对不上。我们知道各个渠道上报了什么，但我们没有一本台账。
这篇记录的就是改变发生的那一刻。台账 #1 是 WEOUR OS 中第一条把真实实盘结果变成可记录库存的条目，而且它可以被事后审计。
在台账出现之前，我们有什么
那时两个真实仓库已经建模完成，它们的在用库位也已经被替换为经验证的物理库位——也就是上一篇提到的 1,306 个库位。平台和渠道在上报它们能看到的内容。但这些都不等于"WEOUR 知道"。
观测库存是证据：它是某个来源在某个时间点、从它自己的角度告诉我们的内容。中央台账不同：它是 WEOUR 决定自己持有什么的地方，而它只有能够追溯到物理事实，才配得上这个地位。
第一次实盘真正改变了什么
实盘不是同步。它是有人站在某个库位前，确认那里到底有什么。当这个结果被写入台账时，三件事第一次成为可能：
- 一个数字之所以存在，是因为有人在某个范围、某个时间、某个库位把它数了出来；
- 系统此前显示的数字与实盘结果之间的差异，变成了一笔可记录的变动，而不是一个谜；
- 之后的观测可以与一个"决定"进行比较，而不是只能与其他观测互相比较。
- 范围内的真实仓库
- 2
- 在用库位
- 1,306
- 第一条记录
- 来自实盘的期初余额
- 台账变动
OPENING_BALANCE +55- 自动库存写入
- 无
- 审批要求
- 按变动类别显式审批
OPENING_BALANCE +55 是一笔记账变动，不是需求信号。它记录的是：在被统计的这个范围内，实盘结果与台账首次就一个数字达成一致。我们公开它，是因为几个月之后，一个中央库存系统正是必须能够解释这类变动——而且因为编造一个看起来更漂亮的数字，会让整件事失去意义。
让它得以成立的规则
这次实盘之所以能被录入，是因为系统里已经存在四条规则：
NOT_INITIALIZED ≠ 0。从未被统计过的范围不是空的，而是未知的；在有人去数之前，它一直保持未知。NOT_REPORTED ≠ ZERO。一个上报失败的渠道并没有告诉我们任何事，而失败的上报永远不会变成缺货。Observed Inventory ≠ Central Inventory。渠道继续上报它们看到的内容；台账记录的是 WEOUR 在核对之后决定下来的事实。Candidate ≠ Approved。被提出的变动只是提议，只有经过显式审批才会成为库存，绝不会由自动化填补空白来完成。
这不意味着什么
它不意味着库存问题"解决了"。两个仓库被数清楚了，就是两个仓库被数清楚了。台账的质量取决于下一次实盘，而下一个范围，正是那个还没有被初始化的范围。
它也不意味着这些数字是最终结论。实盘是关于某个瞬间的陈述。系统必须把这个瞬间一起保留下来，这样之后出现的差异，才是两个已知状态之间的差异，而不是一场关于谁对谁错的争论。
为什么这是第一篇台账记录
我们公开台账系列，是因为它是整套 Commerce OS 里最不显眼、却最承重的部分。如果系统无法把"它知道的""它观测到的""它决定的"这三件事分开说清楚，那么它上面所有的数字都只是装饰。
台账 #1 就是这三件事第一次不再是同一件事的那一条记录。