采购入库单同步实战:从营销云到财务ERP的端到端方案

这个策略解决什么问题

采购入库单是供应链的「最后一公里」:商品到了仓库,单据得进财务ERP,否则账实对不上、应付没法挂、成本算不清。某零售企业的营销云负责下单与审核,星辰负责核算与记账,两个系统必须打通。我们用轻易云数据集成平台(Qeasy)承接这条链路,做到审核即同步、单据可追溯。

整条链路是单向的:营销云(源) → 轻易云(中间层,负责清洗、映射、补默认值) → 星辰(目标,执行入库单写入)。

源端从营销云的 purInWarehsOrder 查询已审核入库单,按更新时间窗口增量拉取。中间层完成编码转换(供应商编码、商品编码)、单据头与分录拆分、默认值补全(如业务类型)。目标端调用星辰的 pur_inbound 接口写入。

关键字段对照:

业务含义	营销云源字段	星辰目标字段	处理要点
单据日期	auditTime	bill_date	取审核日期,格式化为日期型
单据编码	number	bill_no	由星辰自动生成或回填
业务类型	—	transtype	固定值"2"(采购入库)
供应商编码	supplierNumber	supplier_id	走编码映射表,源编码 → 星辰内码
商品分录	items[]	material_entity[]	表体按行展开,逐行映射
备注	remark	remark	拼接"来源-原单号",便于溯源

在轻易云集成平台里,这条策略拆成「源读取」「中间转换」「目标写入」三段。

源读取配置 WebAPI,方法 POST,请求体里 status=1 锁定已审核单据,beginTime 用 {{LAST_SYNC_TIME|datetime}} 占位,平台自动注入上次同步时间戳,实现增量窗口。

中间转换是核心。轻易云的字段映射面板支持「常量赋值」「变量引用」「条件分支」三种模式,我们通常把编码映射做成一张集中维护的对照表(供应商、商品、仓库各一张),后续只改表不改动流程——这是轻易云客户最常用的应对模式之一,新接入一家经销商只需维护映射行,不必重配策略。

目标写入同样走 WebAPI,POST 到星辰的 pur_inbound。bill_no 留空让星辰自动生成,remark 用模板拼接:{{remark}}-来自营销云-{{yxyNumber}},财务日后翻账能直接看到来源单号。

我们建议分三阶段上线。

第一阶段,全量初始化。在轻易云里手动触发一次,时间窗口开大(例如近一年),把历史已审核入库单一次性回灌。跑完后在星辰侧抽样核对单据数、金额、供应商,确认无误再进入增量。

第二阶段,增量起跑。打开调度,源端 crontab 设为 */3 8-21 * * *(白天营业时段每3分钟拉一次),目标端 */4 7-23 * * *(覆盖源端前后各1小时,留出写入缓冲)。beginTime 用 LAST_SYNC_TIME 占位,平台自动维护游标。

第三阶段,稳定运行。观察一周,核对两边单据数差异、失败重试情况、接口耗时。轻易云的运行监控面板可以直接看到每次调用的请求体与返回体,排查问题不用登两边系统。

坑一:beginTime 传时间戳字符串,目标系统不识别。 营销云要的是 0000-00-00 00:00:00 格式,星辰要的是日期型。统一在轻易云的字段映射里加格式化器,不要在两边各写一遍转换逻辑。

坑二:供应商编码漏映射,单据写入直接失败。 典型错误是只配了商品编码,忽略了供应商。星辰的 supplier_id 是内码,不是源系统编码。稳妥的做法是把所有依赖的基础资料(供应商、商品、仓库、币别)先单独建「查询」策略跑一遍,落库到星辰后再启业务单据同步。

坑三:表头与表体一并推送,分录被覆盖。 营销云一次返回头+多行分录,直接整包推给星辰,经常出现「只保留了最后一行」的情况。一定要在中间层显式 for 循环展开 items[],逐行拼 material_entity,表头只取一次。这是表头表体分阶段的典型应用。

坑四:重跑导致重复单据。 增量窗口和全量回灌混在一起跑,星辰里出现重复入库。务必给全量初始化单独建一条策略,与增量策略互斥,跑完禁用。

坑五:营业时段外没有单据,但调度仍空转。 把 crontab 限定在业务时段,既能节省配额,也方便在非营业时段做维护。

适用:营销云下单、星辰做账的两系统架构;入库单需要审核后即时入账;希望集中维护编码映射。不适用:需要实时秒级同步(轻易云是近实时,分钟级);源头系统本身不做审核流,所有单据都是草稿态;目标ERP是本地化部署且无法出公网。