吉客云组装拆卸单对接金蝶云星空:一条策略讲清供应链业务单据同步

这个策略解决什么问题

组装拆卸单是供应链里非常典型的业务单据:成品入库、原料出库、库存形态在一次单据里同时变化。在一次实际项目里,某零售企业的前端业务跑在吉客云,后端财务与库存核算落在金蝶云星空,两边编码、组织、事务类型都不一致。如果两端靠人工二次录入,3 个月后就会出现"前端有单、后端没账"或者"数量对得上、金额对不上"。我们用轻易云数据集成平台(Qeasy)承接,围绕「组装拆卸单」单独做一条同步策略,把吉客云里已完成的组装拆卸单按时间窗口拉过来,翻译成金蝶云星空能识别的单据形态再批量写入。

数据流向与字段映射

整体流向是:吉客云(QUERY) → 轻易云中间层 → 金蝶云星空(EXECUTE batchSave)。

源端调用 erp.combined.get 拉取组装拆卸单列表,入参以 modifyStartDate、modifyEndDate 为增量窗口,默认取近一天到当前时间前 30 分钟的数据,status=2 表示只取已完成单据,避免把草稿和审核中的中间态推到下游。

关键字段对照(节选,基于素材,未出现的字段不列):

这里有两个设计要点:第一,组织、单据类型、货主这种"环境级"字段不做动态映射,直接在中间层写常量,降低后期运维面;第二,assembleType 用 case when 函数翻译成金蝶的事务类型枚举,这是典型的「编码映射集中管理」做法。

在轻易云上如何配置

源端策略:接口选 erp.combined.get,POST 请求,请求体把 modifyStartDate、modifyEndDate、status 三个字段封装好。增量窗口用平台内置的 {{DAYS_AGO_1|datetime}} 和 _function from_unixtime({{CURRENT_TIME}}-1800,'%Y-%m-%d %H:%i:%s') 控制,这里 1800 秒的回看缓冲是用来覆盖上游写入延迟的,后面踩坑部分会再强调。

目标端策略:接口走金蝶云星空的 batchSave,仍是 POST。中间层做两件事:一是把表头字段(单据编号、组织、单据类型、事务类型、货主)按上面的映射写好;二是表体的物料、数量、批号等走分阶段处理——先用源端单号做幂等键,避免重复写入。

轻易云客户常见的应对模式在这里体现得比较完整:编码映射集中放在中间层脚本里,表头表体分两条线维护,增量按时间窗、全量靠手工触发。

实施步骤

第一阶段,增量起点对齐。先在源端用历史最大 modifyDate 倒推一次,把存量组装拆卸单全量补齐,这一步通常用全量触发完成,跑完之后切换到增量窗口。

第二阶段,接入增量调度。源端 crontab 设计为 4-59/10 6-22 * * *,即每天 6 点到 22 点之间,每 10 分钟的第 4 分钟跑一次;目标端错开 4 分钟,跑 8-59/10 6-22 * * *。两个错峰是为了让源端拉到的数据有足够时间落地到中间层。22 点之后停止,避免凌晨上游系统维护期数据脏写。

第三阶段,异常兜底。建议在轻易云上配一条「轻易云运维总管机器人」类的内部策略,盯住失败单据、人工处理或自动重投。整个流程跑 1-2 周后,观察两边单据号和库存台账是否一致。

踩坑复盘

第一条,回看窗口不能省。素材里 modifyEndDate 用的是「当前时间 - 30 分钟」,典型错误是直接写 {{CURRENT_TIME}}。上游单据在 status=2 时,后台可能还有 5-10 分钟的异步落库,边界值会被漏掉,第二天对账就少单。

第二条,状态过滤别只看完成态。只取 status=2 看起来干净,但如果上游审核流程有"已关闭=3"这种终态,这些单据同样要进金蝶,否则会出现前端关单、后端没账的情况。稳妥的做法是把 status 写成可配置的多值参数,上线后根据实际状态机调整。

第三条,组织、货主这类常量不要从源端带。它们在金蝶端是租户级配置,跟着源端字段走会出现"两边组织编码相同但语义不同"的尴尬。客户现场常见的翻车点是源头组织字段是空,中间层没设默认值,直接落到金蝶就报错。

第四条,幂等键要稳。用吉客云 assNo 直接做幂等键没问题,但要注意金蝶端回写 id 后,后续增量如果再拉到同一张单(状态没变),会因为 idCheck=true 命中冲突。稳妥做法是状态变化时才回写。

第五条,表体分阶段写入。整张组装拆卸单一次 batchSave 推下去,字段多、嵌套深,失败后排查成本高。建议表头先单独写,确认 FBillNo 落库后再分批推表体明细。

适用场景与不适用场景

适用:前端业务系统做组装拆卸业务、后端 ERP 做库存与核算收口,且两边编码、组织体系不完全一致的企业。不适用:实时性要求在秒级以内的车间联动、需要跨多组织协同的复杂装配业务,以及对历史单据做大批量回溯重算的场景。