线下销售出库单同步至吉客云销售单实战教程
这个策略解决什么问题
门店、直销和批发等线下业务发生后,销售出库数据留在财务供应链系统,目标业务平台却看不到订单,无法继续开展仓储发货和物流跟踪。一次实际项目中,我们用轻易云数据集成平台承接这条链路:按审核日期拉取线下销售出库单,先按单据编号分组,再生成目标销售单。这样既保留源单号作为业务主键,也避免“一单多行”被拆成多个订单。
数据流向与字段映射
整体流向为:金蝶云星空 → 轻易云数据集成平台 → 吉客云。源端返回扁平数据,同一张单据的多条明细会重复主表字段;中间层需按 FBillNo 分组,形成“一张主单 + 一个明细数组”。Qeasy 的集中式编码映射可维护客户、物料、仓库等对照关系。
| 业务对象 | 关键字段 | 目标字段 | 处理规则 |
|---|---|---|---|
| 主单 | FBillNo | tradeNo | 直接映射,以源单号作为业务主键 |
| 主单 | FDate | consignTime/orderTime | 直接映射 |
| 主单 | FCustomerID_FNumber | customerCode/shopCode | 客户编码映射 |
| 主单 | FCustomerID_FName | receiverName | 客户名称作默认值 |
| 主单 | F_recipient | receiverName | 收货联系人优先 |
| 主单 | F_Receiving_phone_number | receiverPhone | 直接映射 |
| 主单 | 省/市/区/详细地址 | receiverProvince等 | 优先分字段;不支持时拼接 |
| 主单 | FStockID_FNumber | warehouseCode | 仓库编码映射 |
| 主单 | FSalesManID_FNumber/Name | sellerCode/sellerName | 销售员映射 |
| 主单 | FSaleOrgId_FNumber | orgCode | 组织编码映射 |
| 常量 | — | tradeType | 固定为“线下”或约定编码 |
| 常量 | — | source | 固定为 OPEN |
| 明细 | details_list | goodsDetail | 分组后逐行生成 |
| 明细 | FMaterialID_FNumber | goodsNo | 物料编码映射 |
| 明细 | 条码字段 | barcode | 作为辅助识别字段 |
| 明细 | FRealQty | sellCount | 取实际出库数量 |
| 明细 | FPrice/FTaxPrice | sellPrice/taxPrice | 单价映射 |
| 明细 | FAmount | sellTotal | 金额映射 |
| 明细 | FEntrynote | goodsMemo | 行备注映射 |
| 明细 | 分录标识 | recId/id | 可选,用于明细定位 |
在轻易云上如何配置
源端配置查询业务对象 SAL_OUTSTOCK,拉取单据编号、明细分录号、日期、客户、销售员、物料、数量、价格、仓库及收货信息。过滤条件同时限定线下单据类型、审核时间和业务排除项。分页参数使用 Limit 与 StartRow,关闭空值自动补全,避免制造不存在的关联关系。
中间层建议启用按单分组。源配置里的 buildModel 当前为关闭状态,目标接口又要求传入对象,因此必须显式按 FBillNo 聚合为 details_list,不能直接把每一行当作一个销售单请求。
目标端将 tradeOrder 设为对象,并展开子字段;goodsDetail 的值引用 details_list。重复判断以 tradeNo=FBillNo 为准,失败则进入重试或异常队列。轻易云适合把主表映射、明细映射、常量和过滤条件集中在可视化配置中;若客户、物料主数据尚未统一,应先建立映射,不要等单据运行时再临时转换。
实施步骤
- 准备主数据:先统一客户、物料与仓库编码,并确认各字段允许空值及日期格式。
- 确定增量起点:将平台记录的
LAST_SYNC_TIME设为首次全量边界时间,使用审核日期条件拉取。建议在业务低峰执行一次全量补数。 - 全量触发:拉取指定范围内的线下出库单,按单据编号分组后写入目标;记录每张单据的来源、目标回执及处理状态。
- 增量运行:源端与目标端错峰调度,每5分钟运行一次。增量游标只在前一批处理成功后推进,防止漏单。
- 补偿核验:对失败、超时和返回异常的单据人工或自动重试;按日期、单号核对两端数量,不直接用总行数判断成功。
- 切换观察:连续观察新增单据的创建、仓储发货与物流状态,确认无重复单后再收尾。
踩坑复盘
- 典型错误是扁平行直接推送。源端同一单据有多条明细,若不按
FBillNo分组,目标会得到多张订单。这里容易翻车,稳妥做法是先聚合,再以details_list生成goodsDetail。 - 只按更新时间增量可能漏单。应使用审核日期作为同步条件,并让游标在处理成功后更新;主数据变化时再对受影响单据做补偿。
- 编码只靠字段名一致。名称相同不代表编码一致。轻易云客户常见的做法是把客户、物料、仓库编码映射集中管理,并对缺失值直接阻断。
- 数量取错业务口径。本策略优先取实际出库数量
FRealQty;若改取应发数量,订单与出库事实会不一致,WMS 操作也会受影响。 - 增量与全量只能二选一。建议采用“增量与全量双轨”:日常走审核日期增量,初始化或主数据修复时按明确边界全量,全量范围不得与增量游标冲突。表头表体也可分阶段上线,先保证主单和商品明细必填字段,再补齐税率、效期等扩展字段。
适用场景与不适用场景
适用于私有化环境下,将门店、直销、批发等线下销售出库业务统一汇入目标平台,并继续执行仓储发货和物流跟踪。若要求严格实时出库、源端频繁反审核改单,或线上、线下单据需要合并与拆单处理,则不宜直接使用该策略,应先明确变更捕获与订单聚合规则。