采购申请单从旺店通到金蝶云星辰:单一策略同步方案实战
这个策略解决什么问题(场景与价值)
某零售企业的电商业务跑在旺店通上,采购需求以「采购申请单」形式提出;但财务和供应链主数据沉淀在金蝶云星辰。申请单如果只在旺店通里转,采购员就要两边录单,数据对账每月都要扯皮。
我们用轻易云数据集成平台(Qeasy)承接「采购申请单同步[旺店通→金蝶]」这条单一策略:把旺店通的申请单增量拉到金蝶,作为后续下推采购订单的起点。一次实际项目中,光这一条策略就省掉了采购助理每天 1.5 小时的双录工作。
数据流向与字段映射
数据流向分三层:旺店通·企业版(源) → 轻易云中间层 → 金蝶云星辰 V2(目标)。中间层负责拉取、转换、落库,目标侧负责写接口。
主表字段映射对照表
| 源字段(旺店通) | 目标字段(金蝶) | 映射类型 | 转换规则 | 业务说明 |
|---|---|---|---|---|
| created | bill_date | TRANSFORM | {{created|date}} | 创建时间截取 yyyy-MM-dd,作为申请日期 |
| — | emp_id | CONSTANT | 固定常量 | 申请人,当前硬编码金蝶侧员工 ID |
| remark | remark | DIRECT | {{remark}} | 主表备注 |
| details_list | material_entity | ARRAY | 数组整体引用 | 明细行整体映射 |
明细行字段映射对照表
| 源字段 | 目标字段 | 映射类型 | 转换规则 | 业务说明 |
|---|---|---|---|---|
| details_list.spec_no / goods_no | material_entity.material_number | DIRECT | 直接取值 | SKU 编码,优先 spec_no |
| details_list.num | material_entity.qty | DIRECT | {{details_list.num}} | 申请数量 |
| details_list.remark | material_entity.comment | DIRECT | {{details_list.remark}} | 行备注 |
注意:
purchase_apply_no、warehouse_no、status等源字段在当前配置里没有映射到目标。如果业务要单据编号或仓库,要在目标端扩展 request 配置,这是后面踩坑章节会展开的点。
在轻易云上如何配置
在轻易云数据集成平台里,这条策略的典型配置分四块:
- 源端数据集:选「旺店通·企业版」的
purchase_apply_query,QUERY 类型、POST 请求,按start_time/end_time增量查询。 - 目标端写接口:金蝶云星辰 V2 的
/jdy/v2/scm/pur_request,EXECUTE 类型、POST。 - 字段映射层:主表四项映射(上表)+ 明细行数组映射
material_entity.value = "details_list"。日期用{{created\|date}}模板。 - 无脚本段:本策略不写
_function、_findCollection、CASE...END,全是字段级透传或常量,配置起来很轻。
实施步骤
我们给客户落地时,严格按三阶段走,避免「一次跑全量然后翻车」。
第一阶段:增量起点对齐
先和业务确认首次同步的起点时间,建议取「昨天晚上 23:59」作为 start_time,只把当天新增的申请单跑过来。轻易云的增量游标会自动保存进度,下次从上次结束时间继续。
第二阶段:全量触发(可选)
如果历史数据需要补传,谨慎起见先在测试环境跑一遍全量,确认 material_number 编码在金蝶侧都已存在——这一步直接关联到「物料同步[旺店通→金蝶]」策略是否先跑过。编码映射集中管理是轻易云客户常见的应对模式:把 SKU 编码对照放到一个独立的物料主数据策略里维护,本策略只引用,不在本策略里写死映射。
第三阶段:调度频率上线
生产调度配置为 */30 * * * *,每 30 分钟跑一次。轻易云的调度器支持失败重试和断点续传,网络抖动时不会丢单。增量与全量双轨也是常见做法:平时增量跑,每月初触发一次全量核对。
踩坑复盘
坑 1:物料编码没提前对齐
典型错误是「物料同步策略还没稳定,就急着跑采购申请单」。结果金蝶侧 material_number 不存在,接口返回物料不存在,整批失败。稳妥做法是先观察物料策略连续成功 24 小时,再启动本策略。
坑 2:申请人写死常量
当前 emp_id 是硬编码常量,所有申请单都记成同一个人。审计时业务方找过来「为什么都是张三提的?」这里容易翻车。如果业务要按 createtor_name 映射真实申请人,需要在轻易云里配 _findCollection 联查员工/部门方案,拿到对应的 emp_id,表头表体分阶段也是一种常见应对:先把表头映射稳定,再单独迭代申请人逻辑,不要一次改所有字段。
坑 3:日期格式被忽略
源端 created 是时间戳或 yyyy-MM-dd HH:mm:ss,金蝶侧只要 yyyy-MM-dd。不写 {{created\|date}} 模板,目标接口直接报日期格式错。
坑 4:明细行字段没在目标配置里展开
当前目标配置只声明了 material_entity 的数组映射关系,没有展开明细字段。实际项目里,我们建议在轻易云的「字段映射」里把 material_number、qty、comment 三项都显式声明出来,否则金蝶侧某些版本会按默认字段名取值,导致数量或备注丢失。
坑 5:采购申请单号没回写
旺店通的 purchase_apply_no 没映射到金蝶,后续对账只能靠 bill_date + emp_id 模糊匹配,效率很低。建议在目标端扩展一个自定义字段存原单号,或者用 remark 兜底带过去。
适用场景与不适用场景
适用:旺店通作为采购入口、金蝶云星辰作为 ERP 主数据的中小零售/电商企业,需要把电商侧的采购申请自动沉淀到 ERP,作为后续采购订单和收货的起点。
不适用:旺店通与金蝶不是同一家公司主体(没有物料主数据统一基础);申请人/部门组织架构差异巨大且无法联查;业务要求实时秒级同步(本策略建议 30 分钟一轮)。