积加ERP出库记录同步至金蝶云星空其他出库单：单策略实战教程

这个策略解决什么问题

某零售企业在多平台运营中，仓库作业以积加ERP为准，财务与库存账则沉淀在金蝶云星空。出库业务如果由人工二次录入，不仅工作量大，还会出现"两边库存对不齐、月底盘点异常"的老问题。这条策略要做的就是：把积加里的出库记录按业务类型分拣，自动生成金蝶的标准其他出库单、资产出库、VMI出库、费用物料出库、库存调整等单据，让两端账实同步。

数据流向与字段映射

整体链路是单向的：积加ERP（源）→ 轻易云数据集成平台（中间层，做清洗、映射、类型分拣）→ 金蝶云星空（目标，batchSave写入）。

源端通过 /purchase/inventory/storageInbound/page 这个 WebAPI 拉取出入库记录，关键入参是 type=Out 表示只取出库，code 用于按单号精准增量拉取，opType、warehouseIds 用于按业务类型和仓库做过滤。

目标端通过 batchSave 写入金蝶云星空，关键字段对照如下：

业务类型映射是这条策略的灵魂：积加的 opType 通过一张集中维护的字典表，翻译成 QTCKD01_SYS（标准其他出库）、QTCKD02_SYS（资产出库）、QTCKD03_SYS（VMI出库）、QTCKD04_SYS（费用物料出库）、QTCKD05_SYS（库存调整）。

在轻易云上如何配置

在轻易云数据集成平台（Qeasy）里，这条策略按"源建模 → 转换流 → 目标建模"三段配置。

源端：API 类型选 WebAPI，方法 POST，请求体里把 type 写死为 Out、pagesize 设为 50，并启用 autoFillResponse，让平台自动把返回结构展开成字段表。

中间层：用轻易云的字段映射与脚本节点完成三件事——按 opType 判定单据类型、把仓库 ID 写入 {{arrivalWarehouseId}} 占位、把表头表体拆开。客户现场普遍采用的应对模式是编码映射集中管理：所有 opType → FBillTypeID 的翻译写在一张独立字典表里，后续要新增类型只改这张表，不动主流程。

目标端：选 batchSave，把 buildModel 打开（让平台按返回自动建模型），idCheck 设为 true 防止重复提交。表头与表体在中间层拆成两次写：先写表头拿到 FID，再回填表体，确保行项能挂到正确的单据上。

实施步骤

我们建议分三阶段上线：

1. 增量起点：先把源端 API 的过滤条件收紧到"最近 24 小时 + 业务类型明确"的子集，避免一上来就被历史脏数据冲垮。源端 cron 设为 9 20-23,0-9 * * *，覆盖夜班到早班窗口。
2. 全量触发：增量稳定 3 天后，用一次性脚本补齐历史数据，跑完后立即停掉，避免与增量并发。
3. 调度频率稳定：目标端 cron 设为 50 4-9 * * *，与源端错峰 50 分钟，给金蝶留出写入余量。稳妥的做法是采用增量与全量双轨：日常按 code 单号增量，月末走一次全量对账。

踩坑复盘

1. 单据类型没分拣就一把梭：第一次上线时把所有出库都写成 QTCKD01_SYS，结果资产出库和库存调整都走了标准通道，金蝶账上科目全乱。后面改成字典映射后，业务类型在中间层就分好了。
2. 表头表体一起写导致行项丢失：金蝶的 batchSave 一次写全表时，表体数组如果为空容易被静默丢弃。稳妥做法是表头先建、空表体也提交，再二次补行。
3. {{arrivalWarehouseId}} 占位没替换干净：中间层变量解析失败时，金蝶会拿到空值直接报错。建议在轻易云里给所有占位字段加"解析失败则中断整批"的兜底。
4. 源端 code 单号去重逻辑漏配：同一张出库单在源端被改了两次，轻易云会重复拉两次。需要在中间层加一层"按 code 内存去重"。
5. 部门字段写成静态值：案例里 FDEPTID 暂时用静态兜底，是因为源端业务部门字段尚未贯通。后续要做成从积加部门主数据动态映射，否则换业务线就要改配置。

适用场景与不适用场景

适用：源端是积加ERP、目标端是金蝶云星空，需要把出库记录按业务类型分别落账到不同单据类型的零售或贸易企业；希望减少人工二次录入、做到两端库存日清。 不适用：积加侧业务类型尚未稳定、频繁新增；或金蝶侧要求按项目核算而不是按单据类型核算的场景，这种情况下应该改走项目辅助核算方案。