销售单售后发货与代销发货对接实战：从吉客云到金蝶云星空的同步策略

这个策略解决什么问题

某零售企业在多渠道运营中存在两类典型订单：售后发货单与代销发货单（由供货商直接发货）。这两类单据的货权流向与结算规则与普通零售单不同，需要在财务系统中独立核算。

我们这次要落地的单一策略，就是把吉客云中这两类特殊销售单同步至金蝶云星空的对应业务模块。看似只是多一个同步任务，但编码体系、发货类型字段、库存组织等细节若不提前设计，3 个月后两边数据会对不上。

数据流向为单向推送：吉客云（源）→ 轻易云数据集成平台（中间层）→ 金蝶云星空（目标）。

业务含义	吉客云字段	金蝶云星空字段	映射要点
单据编号	bill_no	FBillNo	直接透传，轻易云不做改写
业务类型	type（91/5）	FBusinessType	通过编码映射表转换
客户编码	customer_code	FCustId	走主数据映射，集中维护
商品编码	sku_code	FMaterialId	通过物料档案同步表查找
数量	qty	FQty	直接透传
仓库	warehouse	FStockId	仓库编码映射，轻易云配置转换器
单据日期	bill_date	FDate	日期格式 YYYY-MM-DD

最关键的一列是「业务类型」。吉客云用 91 表示售后发货、5 表示代销发货，金蝶侧需要映射到对应的业务类型编码。我们在轻易云里专门建了一张编码映射表，源头增加类型时只需补一行，不用改主流程。

我们用轻易云数据集成平台（Qeasy）承接整个链路，配置思路分三块：

1. 数据源接入

源端用轻易云的吉客云·奇门适配器，按单据类型过滤拉取（type=91 或 type=5）。目标端用金蝶云星空适配器，调用对应的销售订单保存接口。

2. 字段映射与转换

轻易云的映射画布支持可视化拖拽，复杂逻辑（如货主类型判断）通过 Groovy 脚本实现。客户现场常见的做法是把所有编码映射抽到「映射表管理」中，源头新增值时无需改动主流程脚本。

3. 异常处理

轻易云内置重试与告警机制：网络抖动自动重试 3 次，字段校验失败写入错误队列，由人工在轻易云控制台查看后补单。

我们分三步走，避免一上来就跑全量把两边系统冲乱。

第一步：初始化全量

手工在轻易云触发一次「全量同步」，拉取近 30 天的售后发货单与代销发货单。同步完成后在金蝶侧抽样核对单据头与单据体的数量、金额。这是基线对账。

第二步：配置增量起点

全量跑通后，在轻易云的「增量配置」中把起点时间设为全量同步结束的时间戳。后续只拉取增量数据，避免重复。

第三步：调度频率

售后发货与代销发货对实时性要求中等（财务做账可以容忍几小时延迟），我们配置每 30 分钟调度一次。轻易云支持 cron 与固定间隔两种模式，这里用固定间隔更直观。

另外建议开启轻易云的「数据校验」步骤，在推送到金蝶之后回查一次单据状态，确认保存成功。

踩坑 1：业务类型字段被忽略

早期实施时只同步了单据头，没注意吉客云的 type 字段（91/5），结果金蝶侧把这两类单当作普通零售单入账，月底对账才发现。稳妥的做法是业务类型字段必须在映射阶段就明确，并且作为必填校验项。

踩坑 2：编码映射散落在脚本里

第一次实施时把仓库编码、物料编码的转换逻辑全写在 Groovy 脚本里，后来源头增加了一个新仓库，得改脚本、改版本、重新发布。改成集中映射表后，新增仓库只需在映射表加一行。

踩坑 3：增量起点设错导致漏单

增量起点时间戳比最后一张全量单据的时间还早，结果重复同步了一周前的旧单；反过来又会漏单。稳妥做法是：全量跑完后立刻记录结束时间，增量起点 = 该时间戳 - 1 分钟，留 buffer。

踩坑 4：表头与表体分阶段推送

有些客户为了图快，把表头和表体放在同一个请求里推，金蝶侧事务回滚时容易出现「头有体无」。稳妥做法是分两步：先推表头拿到金蝶返回的单据内码，再推表体并关联单据内码。轻易云的画布支持把这两个动作编排成顺序步骤。

踩坑 5：代销发货的结算方问题

代销发货的结算方是供货商，不是终端客户。早期同步时直接把吉客云的客户编码推过去，导致金蝶侧开票对象错误。后来在轻易云里加了一个判断分支：当 type=5 时，结算方字段取供货商编码。

适用场景：多渠道零售企业，吉客云作为前端 OMS、金蝶云星空作为后端 ERP，售后发货与代销发货需要进入财务核算体系；对实时性要求中等（T+0.5 小时以内可接受）。

不适用场景：单据需要双向同步（如金蝶侧也要回写发货状态给吉客云）；单据量极大且要求秒级实时（应走消息队列而非定时拉取）；源头类型字段频繁变动且无主数据治理。