【手工单】销售出库单同步实战:从吉客云到金蝶云星空的客户联查与分阶段调度

这个策略解决什么问题

在某零售企业的供应链中,线下手工单和线上电商单走的是两套识别逻辑:线上单靠店铺编码映射客户,手工单只能靠客户名称去金蝶主数据里查客户编码。一旦联查环节没设计好,就会出现"单据推到金蝶后客户栏位空着、库存没扣减、财务核算对不上"的尴尬。我们用轻易云数据集成平台(Qeasy)承接这条链路,目标是把吉客云·奇门手工出库单按发货时间增量拉到金蝶云星空,客户通过名称联查,退换货自动识别。

数据流向与字段映射

数据流向:吉客云·奇门(手工单 trade 发货数据) → 轻易云中间层 → 金蝶云星空 SAL_OUTSTOCK。

关键字段对照(表头):

源字段(吉客云)	目标字段(金蝶)	映射类型	转换要点
tradeNo	FBillNo	DIRECT	交易号作为业务主键
consignTime	FDate	TRANSFORM	`{{consignTime\|date}}` 截取日期
customerName	FCustomerID	COLLECTION	`_findCollection` 按 FName 联查金蝶客户 FNumber
tradeType	F_WFHW_Combo_qtr	TRANSFORM	`CASE WHEN '7' THEN '002' ELSE '001'`,区分退换货
logisticName / mainPostid	F_EXPRESS_COMPANY / F_Express_tracking_number	DIRECT	快递公司与单号
sellerMemo	FNote	DIRECT	卖家备注
goodsDetail.sourceTradeNo	F_Platform_order_number	DIRECT	平台单号(首行)
—	FBillTypeID / FSaleOrgId	CONSTANT	`XSCKD01_SYS` / `100`

明细行:源端 goodsDetail[] 数组循环映射到目标 FEntity[],典型对应 goodsNo/barcode/outerId → FMaterialId.FNumber、actualSendCount → FRealQty、sellPrice → FPrice、sellTotal → FAmount。

在轻易云上如何配置

源端(吉客云·奇门)

接口:jackyun.tradenotsensitiveinfos.list.get(WebAPI/QUERY),主键 tradeNo,开启 idCheck。
增量窗口:startConsignTime = {{HOURE_AGO_1|datetime}},endConsignTime = {{CURRENT_TIME|datetime}},以发货时间滚动。
过滤:tradeTypeList = 1,2,3,4,5,6,7,9,10,11,13,91,92,93,100,isDelete = 0。
必传字段:customerName(手工单识别客户的唯一线索,务必勾出)。

目标端(金蝶云星空)

接口:batchSave(EXECUTE,FormId SAL_OUTSTOCK),idCheck = true,主键 id。
客户:FCustomerID 用 _findCollection find FNumber from 1c941bfd-177f-37ad-98f5-89f93b4085b6 where FName={{customerName}},依赖「金蝶-客户→吉客云-客户」同步方案先把客户主数据落到集线器。
出库类型:tradeType='7' 映射 002 退换货,其他 001 正常出库,表达式:_function CASE '{{tradeType}}' WHEN '7' THEN '002' ELSE '001' END。
物料:明细 FMaterialId 通过「店铺+SKU/货品编码」对照金蝶物料 FNumber,配合物料同步策略维护。

调度:源端 1-59/7 7-22 * * *,目标端 3-59/7 7-22 * * *,错开 2 分钟避免读写撞车。

实施步骤

前置依赖:确认「金蝶-客户→吉客云-客户」与「金蝶-物料→吉客云-货品」两个基础资料同步方案已稳定运行,否则 _findCollection 会查不到。
全量触发:首次上线用全量回灌,把历史手工单补齐;通过手工指定 startConsignTime 起止点拉一遍,目标端先在测试账套验证。
增量起点:全量完成后,把源端切换到 HOURE_AGO_1 / CURRENT_TIME 滚动窗口,以 consignTime 增量拉取。
调度上线:源端每 7 分钟一轮、7–22 点执行,目标端错开 2 分钟执行,实现"表头先落、表体续传"的双轨。
监控闭环:在轻易云上挂失败重试与告警,针对 FCustomerID 联查空值、FMaterialId 未映射、tradeType 异常单独建告警通道。

踩坑复盘

客户名称不一致是最大雷区:吉客云手工单的客户名带空格、别名,金蝶主数据里是规范名,联查直接返回空。这里稳妥的做法是把"客户主数据同步"作为强前置,差异表集中维护。
物料编码没建立对照就推表体:明细行 FMaterialId 取不到值,整张单在金蝶保存失败。物料同步和出库同步解耦,表头先成功再回填表体是轻易云客户常用的应对模式。
退换货 tradeType 漏判:不写 CASE 表达式时,所有手工单都被当成正常出库,导致库存和财务口径错位。
增量窗口设置过窄:只取 CURRENT_TIME 一瞬间,会漏掉跨分钟提交的单;用 HOURE_AGO_1 留一小时重叠更稳。
源端与目标端同分钟并发:两边都 */7 同时拉,网络抖动时易重复写。用 1-59/7 与 3-59/7 错开 2 分钟,踩过坑的都懂。

适用场景与不适用场景

适用:线下/手工录入发货、需按客户名称联查客户主数据、发货时间作为增量依据、退换货需独立标识的销售出库同步。 不适用:电商平台标准化订单(应走【线上】策略)、客户与店铺绑定清晰无需联查、无物料主数据支撑的初始上线阶段。