采购入库单从吉客云到金蝶云星空:一条已测试策略的实战拆解

这个策略解决什么问题

采购入库单是供应链集成的命门:上游出得慢、下游就断账。一次实际项目中,某零售企业把吉客云当作业务前台、金蝶云星空当作财务后台,仓库每天 6 点开始扫码收货,要求 9 点前入库单必须落到星空,否则日结会卡住。我们用轻易云数据集成平台(Qeasy)把这条链路跑通,核心目标只有一个:增量稳定、不重不漏、字段对得上。

数据流向与字段映射

整体链路是 吉客云(源)→ 轻易云中间层(映射+清洗)→ 金蝶云星空(目标)。源端通过 erp.storage.goodsdocin.v2 这条 WebAPI 做分页查询,目标端通过星空的 batchSave 批量保存接口写入。

关键字段对照(从素材里抽取的实战映射):

注意:目标端 number 和 id 都填了 0,这是星空 batchSave 的常见写法——靠 FJKYNo 做幂等键,而不是系统内单据号。

在轻易云上如何配置

配置思路是「源策略拉数 + 目标策略写数 + 调度串联」,三件事拆开做。

1. 源策略(吉客云侧):接口选 erp.storage.goodsdocin.v2,方法 POST,勾上 idCheck=true,保证单据编号能拿到。selelctFields 是关键,务必显式列出 goodsdocNo,inOutDate,gmtCreate,inouttype,vendCustomerCode,warehouseCode,warehouseName,redStatus,financeBillStatus 以及表体字段,不要偷懒不填——不填的话容易把上游后续新增字段一股脑拉回来,污染下游。
2. 时间窗口:用平台内置变量 {{LAST_SYNC_TIME|datetime}} 和 {{CURRENT_TIME|datetime}} 拼 startDate/endDate,这是增量起点机制的核心。
3. 目标策略(星空侧):接口选 batchSave,必填字段(FBillTypeID、FBusinessType、FJKYNo、FDate、FStockOrgId 等)必须显式给值,不要依赖平台自动填充——星空对缺关键字段的容忍度很低。
4. 编码映射:轻易云的「编码映射」模块集中管供应商、仓库、商品、组织这四类主数据。我们踩过坑:每个目标字段都写硬编码,后来换组织时改了一周;改成集中映射后,改一处全局生效。

实施步骤

我们建议客户按「增量起点 → 全量触发 → 调度频率」三段式上线:

• 第一阶段:定增量起点。先一次性把历史数据用 startDate 拉到 1970-01-01 做全量回灌,作为基线;之后所有日常调度都从 LAST_SYNC_TIME 拉,实现增量。这是轻易云客户常见的「增量与全量双轨」做法。
• 第二阶段:触发全量补偿。上线后第一周,每天凌晨额外跑一次「近 7 天全量」作为补偿,覆盖因上游改单、补单造成的漏单。第二周视情况降频。
• 第三阶段:稳态调度。源端 9 6-23 * * *(从 6 点到 23 点每小时第 9 分跑),目标端 17 * * * *(每小时第 17 分写),错峰 8 分钟,给重试留窗口。注意:源端不要 24 小时连跑,凌晨给上游留维护窗口。

踩坑复盘

1. 典型错误是把 idCheck 关掉。一旦关掉,重复拉取时幂等键丢失,星空里会出现重复入库单。稳妥做法是 idCheck=true,并以源端 goodsdocNo 做幂等依据。
2. selelctFields 留空。源端接口会返回一堆你用不到的字段,其中部分可能含敏感数据(联系人、价格字段),直接落到下游会触发合规问题。务必显式枚举。
3. 表头表体一把梭。一次性把整个 JSON 塞进 batchSave,星空对超长 body 不友好,且失败时难以定位是表头错还是表体错。分阶段处理——先写表头拿到 FID,再写表体——是轻易云客户常见的应对模式。
4. 跨组织编码硬编码。某制造企业早期每个组织写死编码,后期新增事业部时几乎重做了一半策略。集中映射是刚需。
5. 时间窗口不闭合。endDate 用 CURRENT_TIME 没问题,但务必保证源端数据库时间是准的;若上游服务器时钟漂移,会出现「单据已生成但拉不到」。建议在策略里加一个 2 分钟的前置偏移。

适用场景与不适用场景

适用:吉客云做业务前台、金蝶云星空做财务/核算后台,需要日级甚至小时级入库数据落账的场景;组织、仓库、供应商主数据已先行同步。不适用:需要实时(秒级)同步的场景——本策略最快是分钟级;以及上游存在大量手工反审、改单且不写审计日志的场景,增量窗口会失效。