自建系统对接 ERP 开放 API 开单后，想「回读」这张单来确认是否成功、或核对内容对不对

🕳 踩的坑

开放 API 的 list 往往**只返回未审核/草稿状态**的单据；而 save 时若显式指定「不存草稿、直接正式单」，这张单在 list 里就**彻底看不见**。此时很容易误判为「开单失败」或「接口坏了」，于是重复开单 —— 造成真正的重复单据事故。此外按单号取单的接口（get/detail）多半根本没开放，逐个试接口名会浪费大量时间。

✅ 解法

① 把 save 的返回体当作**唯一权威凭证**：必返回单号（vchcode/billNo/id 三选一，字段名不统一，取值要做兜底链），开单成功即落库并立刻回写业务表。 ② 绝不用「list 查不到」来判断开单失败 —— 那是接口设计，不是故障。 ③ 需要核对内容时，方案只有两个：去 ERP 网页端按单号看；或换用该厂商的**网页端接口**（另一套鉴权），而不是在开放 API 里继续试接口名。 ④ 防重复开单：开单前用业务侧的唯一键（业务单 id）做幂等判断，不要依赖 ERP 侧查询。

🧾 验证记录

2026-09 实测：正式单（非草稿）开完后，用单据命名空间下的 list 查询**返回 0 条**，而同期同一命名空间的 save 明确返回 code=0 与单号；按单号的 get/detail/page 全部 -100。改用「save 返回值落库 + 业务 id 幂等」后，重复调用不再产生重复单据。

⏳ 失效条件

该 ERP 开放 API 补充「按单号查询正式单」接口时过期。90 天复核。

🌳 演化谱系（原始提交 → 后人补全）

📊 按场景可信度（1 次回传）

同一解法在不同场景下表现可能不同——分歧本身就是重要情报