我之前那 5 套样例，字段有一半是我按经验补的。
在 [dirty-erp.html] 里我写的是「结构参照真实 ERP 导出」——现在抓了官方文档，这句话需要拆开说清：哪几列是真的，哪几列是我编的，哪几列官方接口根本没有。
| 系统 | 字段来源 | 核实结果 |
|---|
| 聚水潭 |
官方开放平台文档，直接抓到完整返回字段表 |
✓已逐字核对（21 个返回字段全部拿到） |
| 金蝶 云星空 |
官方开发者社区问答 + WebAPI 实例（FormId: STK_Inventory） |
✓核心字段已核对，未拿到完整数据字典 |
| 用友 U8 |
官方优普开放平台 API 中心 · 现存量查询 |
✓返回字段已核对，未拿到完整数据字典 |
| 旺店通 |
— |
✗没抓到，文档需登录。样例字段是推断 |
| Shopify |
— |
~列名是公开常识，但这次没逐字核对官方文档 |
最重要的一条：聚水潭的库存接口，根本没有「销量」和「成本价」两个字段。
我样例里写的「近30天销量 / 近6月销量 / 成本价 / 最后出库日」——这四列是我编的。真实的聚水潭库存接口不返回销量，也不返回成本。
这不是小事：它意味着客户的「一张导出表」实际不存在。销量在订单接口、成本在商品接口、最后出库日要查出库流水——必须跨三个接口拼。这条恰好是你最强的卖点，见 P5。
聚水潭的「库存」不是一列，是十三个口径。
接口：/open/inventory/query · 商品库存查询。下面每一个都是官方文档原文，不是我的推断。
来源：openweb.jushuitan.com/dev-doc?docType=3&docId=15 ↗
返回字段全表
| 字段名 | 官方中文名 | 说明 |
|---|
| sku_id | 商品编码 | SKU 级编码 |
| i_id | 款式编码 | 款式级编码——同一个款的多个颜色/SKU 共用它 |
| name | 商品名称 | — |
| qty | 主仓实际库存 | 仓库里的实物数量，可用于发货 |
| order_lock | 订单占有数 | 客户下单后锁定的数量 |
| pick_lock | 仓库待发数 | 订单审核通过、正在发货中的数量 |
| lock_qty | 库存锁定数 | 锁给特定店铺/链接用的（需传参才返回） |
| virtual_qty | 虚拟库存 | 可正可负，用来虚增/虚减同步到线上的库存 |
| purchase_qty | 采购在途数 | 采购单已生效但还没入库 |
| allocate_qty | 调拨在途数 | 仓间调拨路上 |
| in_qty | 进货仓库存 | 待检/待上架 |
| return_qty | 销退仓库存 | 客户退回、还没归位 |
| sale_refund_qty | 销退在途数 | 退货在路上（需开通才返回） |
| defective_qty | 次品库存 | 坏货，不能卖 |
| customize_qty_1/2/3 | 自定义仓 1/2/3 | 客户自定义的仓 |
| min_qty | 安全库存下限 | 系统内置字段，客户可以自己设 |
| max_qty | 安全库存上限 | 同上 |
| modified | 修改时间 | 增量同步用 |
| ts | 时间戳 | 防漏单 |
官方对「库存」的定义原文
qty
主仓实际库存 = 实物可发数量。分仓时 = 分仓库存 + 主仓库存
order_lock
订单占有数 = 已被订单锁定的量
pick_lock
仓库待发数 = 审核通过在发货中的量
可用数
= 主仓实际库存 − 订单占有数 + 虚拟库存 + 采购在途 + 进货仓 + 销退仓（后三项取决于业务设置）
公有可用数
= 主仓实际库存 − 订单占有数 − 库存锁定数 + 虚拟库存 − 虚拟仓可用数
这就是最值钱的一句话：客户说「我库存三千万」——你没法直接回答「钱压在哪」，因为三千万是哪个口径？
实物在仓（qty）、已卖出没发货（order_lock）、在发货路上（pick_lock）、退货没归位（return_qty）、次品（defective_qty）、采购在路上（purchase_qty）——这六个数的加总逻辑不同，答案差几十个点。
这一问，客户立刻知道你不是外行。而 AI 答不了，因为它不知道客户用的是哪个口径。
第二个发现：聚水潭天生就有两级编码。sku_id（商品编码，精确到颜色尺码）+ i_id（款式编码，一个款共用）。
这就是「一码多名」的官方解法——不用自己造合并逻辑，按 i_id 汇总就是「按款」，按 sku_id 就是「按色」。我在样例里编的 10001/10001B 那种问题，在规范使用聚水潭的客户那里不会出现；会出现，恰恰是因为客户没按 i_id 维护。
第三个发现：安全库存是系统内置的。接口里有 min_qty 和 max_qty 两个字段。
所以别对客户说「你没设安全库存」——更可能是他设了，但全店设了同一个数（比如统一填 45 天对应量）。这比你原来的说法更准，也更难反驳。
金蝶和用友也是同一个套路：库存有多个口径，且都没有销量。
金蝶 云星空 · 即时库存（STK_Inventory）
来源：金蝶云社区 · WebAPI 如何查即时库存 ↗
| 字段名 | 官方中文名 | 对应我样例里的哪列 |
|---|
| FMaterialId.FNumber | 物料编码 | ✓存货编码（真的） |
| FMaterialId.FName | 物料名称 | ✓存货名称（真的） |
| FModel | 规格型号 | ✓规格型号（真的） |
| FBaseUnitId.FName | 基本单位 | ✓计量单位（真的） |
| FBaseQty | 基本单位数量 | ~我写成「结存数量」——官方叫基本单位数量，强调「基本单位」是因为一个物料可以有多单位 |
| FStockId.FName | 仓库 | ✓我样例里没有仓库列（漏了） |
| FStockOrgId.FNAME | 库存组织 | ✗我完全没考虑「多组织」这个概念 |
| 库存金额（金额类字段） | ✗即时库存接口不返回金额，我编的「结存金额」要去存货核算模块才拿得到 |
金蝶的两个口径陷阱（官方问答里明说）：不同接口字段名不一样——
inventory_stock 接口：inv_im_qty（即时库存数量）、inv_qty（可用库存）
inventory 接口：qty（即时库存数量）、valid_qty（可用量）
抓错字段名，返回就是空白——这是官方 FAQ 里的原问题。真实客户的数据拿不出来，常常不是没数据，是指标取错。
用友 U8 · 现存量查询
来源：用友优普开放平台 · 现存量 currentstock/batch_get ↗
| 字段名 | 官方中文名 | 说明 |
|---|
| qty | 现存数量 | 只代表实物存量，不是「可用」 |
| stopqty | 其中冻结数量 | 被质量/订单冻结的量，不能卖 |
| inqty | 到货/在检数量 | 在路上、还没验收 |
| transinqty | 调拨在途数量 | 仓间调拨路上 |
| inqtysum | 预计入库数量 | 含在检 + 在途 |
和聚水潭一模一样：现存 ≠ 可用。可用 = qty − stopqty。而且没有销量、没有成本、没有最后出库日期——和我样例里的「参考成本 / 最后出库日期」完全对不上，那两列是我编的。
把 dirty-erp.html 的每一列，逐个打上真假标签。
✓官方文档验证 ~名字接近但不精确 ✗该接口没有，我编的
聚水潭样例（旧版 9 列 · 已修正）
| 我写的列名 | | 真实情况 |
|---|
| 商品编码 | ✓ | 官方 = sku_id |
| 商品名称 | ✓ | 官方 = name |
| 规格 | ✗ | 库存接口无此字段（在商品接口里） |
| 仓库 | ~ | 官方用 wms_co_id（分仓编号）当参数，不是返回的「仓库名」列 |
| 可用库存 | ~ | 官方没有「可用库存」这一个字段，它是公式算出来的（qty − order_lock + virtual_qty + …） |
| 成本价 | ✗ | 库存接口没有成本字段 |
| 近30天销量 | ✗ | 没有。销量在订单接口，要自己按天聚合 |
| 近6月销量 | ✗ | 没有。同上 |
| 最后出库日 | ✗ | 没有。只有 modified（字段修改时间），不等于出库时间 |
9 列里只有 2 列是真的——这页留作证据，实际页面已重做。现在
dirty-erp.html P2 已换成官方 21 个字段，xlsx 也重新生成了。保留这张表，是因为它能说明一件事：
编字段最容易编错的，恰恰是「卖得好不好」那一类——见 P5。
金蝶 / 用友样例
| 我写的列名 | | 真实情况 |
|---|
| 存货编码 | ✓ | 金蝶 FNumber / 用友 cInvCode |
| 存货名称 | ✓ | 金蝶 FName |
| 规格型号 | ✓ | 金蝶 FModel |
| 计量单位 | ✓ | 金蝶 FBaseUnitId.FName · 我编的「个/箱/打」单位混乱是真的会发生的 |
| 结存数量 | ~ | 金蝶官方叫「基本单位数量 FBaseQty」；用友叫「现存数量 qty」 |
| 结存金额 | ✗ | 即时库存/现存量接口都不返回金额，要去存货核算模块 |
| 存货分类 | ~ | 真实有，但不在这两个接口的返回里 |
| 现存量 | ✓ | 用友 qty |
| 参考成本 | ✗ | 现存量接口没有 |
| 最后出库日期 | ✗ | 没有——死货判断必须另查出库流水 |
清洁的结论：我编对的都是「这是什么货」类字段（编码、名称、规格、单位），编错的都是「它卖得怎么样、值多少钱」类字段（销量、成本、金额、最后出库日）。
这说明一件真事：ERP 里存的是「现在有什么」，不存「卖得好不好」。卖得好不好要自己从订单流水算。
「你的 ERP 导不出我需要的表」——这句话本身就值钱。
抓完官方文档，才发现客户最痛的地方不是算不出来，是根本拼不出来。
客户的以为错
「我有 ERP，点一下导出就有数据了。」
真实情况对
库存接口只有「现在有什么」。没有销量、没有成本、没有最后出库日。
要凑一张诊断底表，最少要拼三处数据
| 我要的列 | 从哪来 | 聚水潭 | 金蝶 | 用友 |
|---|
| 编码 / 名称 / 规格 | 库存接口 | ✓一家搞定 | ✓ | ✓ |
| 库存数量 | 库存接口 | ✓21 个口径要选 | ✓2 个口径 | ✓5 个口径 |
| 销量 | 订单/出库流水，按天聚合 | ✗另一个接口 | ✗另一模块 | ✗另一表 |
| 成本 / 单价 | 商品资料 / 存货核算 | ✗另一个接口 | ✗另一个模块 | ✗另一表 |
| 最后动销日 | 出库流水取最大值 | ✗要自己算 | ✗要自己算 | ✗要自己算 |
| 库存金额 | 数量 × 成本，自己乘 | ✗两个接口拼 | ✗另一模块 | ✗另一模块 |
六类数据，没有一家 ERP 能一张表给你。客户点「导出」，导出来的永远是其中一块。
而做诊断需要全部六块，还要对齐口径、对齐时间窗口、对齐单位。这就是数据整备的真实工作量，也是 AI 拿不到的东西——AI 连你有哪几个接口都不知道。
你可以直接说的三句话（都有官方文档撑腰）
1.「你说库存三千万，是哪个口径？」
聚水潭一个库存查询返回 13 个数量字段：实物、订单占有、待发、锁定、虚拟、采购在途、调拨在途、进货仓、销退仓、次品、自定义仓 ×3。金蝶 2 个、用友 5 个。选错口径，结论差几十个点。
2.「你的库存表里没有销量，对吧？」
官方库存接口明确不返回销量。要算「压了多久」，必须去订单/出库流水自己聚合。这一问，客户立刻知道你摸过系统。
3.「你的安全库存，是不是全店一个数？」
聚水潭有 min_qty / max_qty 两个官方安全库存字段。不是「没设」，是「设了个统一值」——这比说他偷懒更准，也更难反驳。
下一步该改什么：
① ✅ 已改 [dirty-erp.html] 的聚水潭样例已按官方字段重做成 20 行 × 21 列（接口返回的 21 个字段一个不删，另加 5 种「可用」口径对照页），xlsx 同步重生成。
② ✅ 已改 「一码多名」的讲法已换成 sku_id 与 i_id 的两级编码关系。
③ ⏳ 旺店通和 Shopify 还没核对——旺店通开放平台需企业认证，等你注册后补抓；Shopify 页面上标「未验证」。标未验证比装作验证过安全得多。