库存表怎么核对？保留预留记录，从四条事件查到在库15件

先固定问题：算实物在库，不算可售承诺

本例定义很窄：同一SKU、同一仓库、同一个统计窗口内已经发生的实物变化。所有数量均为非负件数，由事件类型决定加减。预留表示保留给某项需求，本例并没有因此发生搬出或发货。

实际系统可能同时展示在库、可用、预留和在途，字段规则应以你的系统定义为准。本文的15件不自动等于可销售数量，也不把盘点当成会计审计。先把口径写出来，才有资格比较两份看似冲突的答案。

原材料：一份期初和四条事件

以下为自编教学数据，不是真实仓库，也不是模型运行结果。期初10件是窗口开始时的余额，不是又一次收货。E1到E4在本例窗口内按所列顺序发生，SKU和仓库不变；如果真实材料含时区、跨仓或不同包装单位，应先补齐这些定义。

quantity列均为正数，只有类型带方向。不能先把shipment变成－5，又在求和时再减一次。预留也不能悄悄丢行，应保留记录并把实物影响解释为0。

Opening balance: SKU-A, 10 units
event_id,sku,type,quantity
E1,SKU-A,receipt,8
E2,SKU-A,shipment,5
E3,SKU-A,reservation,3
E4,SKU-A,physical_return,2

先分开原始数量、分类变化与期初

练习包包含opening.csv、events.csv、classified.csv、wrong-reservation.csv和参考账本，均为编辑设计教学材料。events.csv是四条原始事件，classified.csv是需要逐行审核的编辑分类结果，不是第二份来源，也不是工具已经验证过的AI回复。

E2的原始quantity保留正数5，physical_delta只取负一次；E3的quantity仍是3，physical_delta为0。这个零来自已声明的事件定义，不能拿来填补缺失资料。

event_id,sku,type,quantity,physical_delta
E1,SKU-A,receipt,8,8
E2,SKU-A,shipment,5,-5
E3,SKU-A,reservation,3,0
E4,SKU-A,physical_return,2,2

先让AI列出分类，再要求合计

提示词应要求保留编号、说明每个事件是否改变实物在库，并给出逐行余额。只要一个最终数字，会掩盖开头余额重复相加或预留被误当发货等错误。

下面的参考结果是编辑按明示规则推导，没有执行第三方模型。你实际使用AI时，应保存原始回复，先与上表逐行比较，再决定是否采纳它的摘要。

你在核对虚构库存记录，不修改系统。目标仅为实物在库件数。期初是10，不是一笔收货；所有quantity为非负数。receipt和physical_return增加在库，shipment减少在库，reservation在本例不产生实物变化。保留E1至E4，输出事件分类、带符号变化、逐行余额、期末在库以及未知项。不要补造盘点调整。
Opening balance: SKU-A, 10 units
event_id,sku,type,quantity
E1,SKU-A,receipt,8
E2,SKU-A,shipment,5
E3,SKU-A,reservation,3
E4,SKU-A,physical_return,2

实际分组导出，再回到逐行余额

打开数据汇总。工具负责对数值列求和，不理解收货、发货或预留，也不自动加期初余额；必须先完成分类审核。

1. 1
   只导入classified.csv，确认当前工作数据四行。opening.csv单独保存，不把期初追加成第五条事件。
2. 2
   在“分组汇总（当前工作数据）”里，分组列选sku、求和列选physical_delta，再点“简单分组汇总”。
3. 3
   下载CSV重新打开，应为分组SKU-A、数量4、合计5；英文列名是Group、Count、Total。5是净变化，不是期末余额。
4. 4
   把另存的期初10与净变化5相加得期末15，再按E1至E4核对18、13、13、15的滚动余额。E3及原始数量3都要能回查。

12件可能是换了口径，不能直接覆盖15件

故意写错的编辑稿是“10＋8－5－3＋2＝12件实物在库”。算式本身算得对，但把预留当作实物离库，违背了本例目标。正确的实物余额为15。若要另算某系统定义的可用数量，应新建有名称和规则的指标，不能沿用“实物在库”标题。

在表格中可以另列physical_delta为8、－5、0、2。若A到E列依次是event_id、sku、type、quantity、physical_delta，样本公式为10＋SUMIFS(E2:E5,B2:B5,"SKU-A")，得到15。Microsoft的SUMIFS说明支持按条件求和；事件分类是否正确仍由业务定义与原始材料负责。

记录数没少，为什么仍可能错成12

另开一轮导入wrong-reservation.csv，它只把E3的physical_delta从0改成－3。同样汇总会返回数量4、合计2，加期初10后是12，所有事件编号仍在。这是刻意设计的错误分类，不是模型错误率实测。

按已声明的实物事件规则对照E3，拒绝该结果；有依据地恢复physical_delta为0，同时保留quantity3，再重跑核对过的classified.csv。不要删掉预留行，也不要拿盘点16强行充当账面参考答案。

盘点16件时，把差1件留下来查

若同一时点的另一次盘点记录为16，盘点与账面15相差＋1。当前四条事件无法解释这1件，合理输出应是“差异待查”，而不是让AI自动生成“遗漏退货1件”。后者会把猜测变成一条虚构事实。

检查截止时间、漏记事件、SKU、仓库与单位；有依据后再按正式流程调整。还可参考表关联增行后的对账方法与多币种分别核算。它们共同强调保留计量对象，但不替代本例的库存定义。