新宝采购订单→金蝶云星空销售订单同步实战

这个策略解决什么问题（场景与价值）

在一次制造企业的供应链集成项目中，客户上游使用产业链协同平台下达采购订单，下游 ERP 是金蝶云星空。看似简单的「订单搬运」，但当采购方与销售方属于同一法人主体的不同组织时，必须把采购订单转为销售订单写入 ERP，才能进入后续的发货、开票、结算流程。我们用轻易云数据集成平台（Qeasy）承接这条链路，关键价值在于：把分散在两套系统里的组织、客户、编码规则集中映射，确保两边数字始终对得上。

数据流向与字段映射

整体流向是「源系统 → 轻易云中间层 → 目标系统」，源端用 queryTime 做增量游标，目标端按单据编号去重。

编码映射集中管理是轻易云客户常见做法：组织、客户、员工、单据类型四类基础资料，都放进同一张映射表里维护，源端变更只改一处。

在轻易云上如何配置

典型配置按「源接口 → 映射 → 目标接口」三段式完成。

源接口侧：选择 /order/orderList 的 QUERY 动作，方法 POST，把 queryTime 绑定到全局变量 LAST_SYNC_TIME，并启用 idCheck（poNo 作为幂等键）。注意素材里明确写了「只支持查询跨度 1 个月内的数据」，所以增量窗口一定要控制。

映射层：在轻易云可视化映射里，把 poNo 映到 FBillNo，orgName 经过查找表转 FSaleOrgId，FDate 走 prepareDate 表达式统一为 yyyy-MM-dd。客户与销售员的映射建议放进「编码映射集中管理」节点，而不是写在单条策略里。

目标接口侧：选择金蝶 batchSave 的 EXECUTE 动作，方法 POST，启用 idCheck，并打开金蝶的「保存即审核」开关（按客户实际业务决定）。表头字段齐了之后，再把采购订单行项目映到销售订单的明细实体上。

实施步骤

我们建议分三个阶段推进。

第一阶段：建映射、定增量起点 先在轻易云里完成组织、客户、员工、单据类型四类编码映射的初始化。增量起点 LAST_SYNC_TIME 默认设为「接入当日 00:00:00」，避免把历史数据全部重拉。

第二阶段：触发全量、补齐历史 对于切换前已有的在途采购订单，需要触发一次全量同步。我们采用「增量与全量双轨」的稳妥做法：全量任务单独调度，跑完后关闭，避免和增量任务抢同一条数据。

第三阶段：调频率、上监控 源端调度 */2 * * * *、目标端 */5 * * * *，两端错峰避免并发。轻易云上配置失败重试（建议 3 次，间隔 30 秒）、异常告警（飞书/钉钉/邮件任选），以及一张简单的「单据号 → 同步状态」对账看板。

踩坑复盘

1. queryTime 跨度超 1 个月直接报错。典型错误是把 LAST_SYNC_TIME 设到一个月之前，源端接口会拒绝返回。稳妥的做法是：在轻易云里加一个前置判断，若跨度 > 30 天，自动切片成多段循环拉取。
2. 采购单号和金蝶单据号混用。很多人图省事直接拿 poNo 当 FBillNo，一旦上游允许修改单号，金蝶就会重复建单。正确做法是 FBillNo 加源系统前缀（如 PO-xxx），写入失败也方便溯源。
3. 客户档案不存在导致整批失败。金蝶 batchSave 是「整批提交、任一失败全回滚」，上游新增的客户若没在金蝶建档，整批都会被回滚。我们建议在映射层加一道「客户档案预校验」，缺失就先落轻易云的待处理队列。
4. 表头表体分阶段上线。不少客户一上来就表头表体一起推，结果一张单据部分行项目有问题导致整单失败。分阶段的稳妥做法：先跑通表头，确认单据能正常创建，再补明细。
5. 时区与日期格式。源端返回的时间戳如果不带时区，轻易云默认按 UTC 处理，写入金蝶后会差 8 小时。映射层显式指定时区是最低成本的规避方式。

适用场景与不适用场景

适用：上下游属于同一法人主体、采购订单需要转为内部销售订单进入发货/开票流程；两端都允许批量写入。不适用：跨法人主体交易（应走真正的销售订单而非自转）、需要复杂审批流穿透的场景（建议走工作流集成而非数据同步）、单据字段差异巨大且无映射规律的情况（先治理主数据再谈同步）。