库存历史同时出现加一和减一，先确认是不是同一个移动事件

仓储历史里出现一条数量增加和一条数量减少，未必是两笔互不相关的业务。ShipBob 的 Inventory History 文档把 increment 与 decrement 放进同一个事件对象中，说明阅读这类数据时，除了数量的正负，还需要保留它们所属的事件及位置。

在2026-07版本的响应示例里，一个 ReceivingStow 事件的 increment 写着 quantity_change 为1，decrement 则为负1，两者对应不同的 location_id。原文将增加端解释为目标货架的事件，将减少端解释为对其对象中所指设施数量的减少。把示例拆成两个没有关联的“库存变化”，会掩盖它们原本属于同一记录。

这里不能反过来认定，所有事件都必须一增一减。文档紧接着说明，某些事件类别只导致增加时，decrement 可以为 null，例如部分盘点调整事件。因此，“存在两个字段”与“每次都有两个非空对象”并不相同；看到空值也不能在没有进一步依据时替它补出一笔减少。

可以设想一份只为说明而编写的表：同一库存项从位置甲减少一件、向位置乙增加一件，并用同一事件标识相连。如果把两个方向都当成新到货，会重复理解这一移动；但若要讨论某个设施的净变化，还必须确认两端是否属于同一设施及相同统计范围。这个例子没有对应实际仓库，也没有构造一套库存记账算法。

来源还保留 primary_reference 来解释事件关联什么对象。ReceivingStow 的 type 为 WroAndBox 时，value 组合入库单和箱子标识；OrderPicked 的 type 为 OrderId 时，value 对应订单标识。相同的 value 字段，需要结合 type 才能阅读，不能因为都长得像编号就互换。

对第三方仓储交接而言，一份有用的摘录可以让接手者同时看到库存项、事件类别、时间、增加或减少的方向，以及相应位置。这样能够先回答“这段记录在描述哪次变化”。它仍不是当前库存总表，不能把截取的几条历史当作完整现存量，也不能据此判定货损或要求调整账目。

本文于2026年10月12日读取官方2026-07文档，没有调用商家接口或更改库存。文章只采用事件结构和引用对象的说明；示例数据不代表真实订单，也不把所有增减概括为同一种原因。