这个策略解决什么问题
在一次实际零售供应链集成项目里，客户把金蝶云星空作为采购中台，把旺店通作为门店履约侧的采购入口。两边都要有采购订单，但编码体系、税率口径、字段命名都不同。最直接的问题就是：金蝶审核过的采购订单，怎么按增量、稳定地推到旺店通，保证两边单据编号、供应商、仓库、明细行一一对应。
这个策略就是为这件事设计的------单向把金蝶云星空的采购订单同步到旺店通·旗舰奇门，承担跨系统单据镜像的职责。我们用轻易云数据集成平台（Qeasy）来做承接。
数据流向与字段映射
整体流向是 金蝶云星空 → 轻易云 → 旺店通·旗舰奇门 。金蝶侧通过 executeBillQuery（QUERY 类型）扁平化拉取采购订单主表加明细，平台再按 FBillNo 把多行明细聚合成 POOrderEntry 数组，最后整单推到旺店通的 wdt.purchase.purchaseorder.createorder。
关键字段对照（主表）：
| 源字段（金蝶） | 目标字段（旺店通） | 类型 | 说明 |
|---|---|---|---|
| FBillNo | purchase_no | DIRECT | 单据编号，必填 |
| FSupplierId_FNumber | provider_no | DIRECT | 供应商编码 |
| F_TPRO_Base2_FNumber | receive_warehouse_nos / expect_warehouse_no | DIRECT | 收货仓、预计入库仓 |
| FPurchaserId_FNumber | prop1 | DIRECT | 采购员编码写入自定义属性 |
| - | purchaser_name | CONSTANT | 固定常量，必填 |
| - | is_check | CONSTANT | 固定 true，创建即审核 |
| - | pay_type / postfee_pay_type | CONSTANT | 固定 1，现付 |
| FDeliveryDate | expect_time | TRANSFORM | 日期格式化 |
关键字段对照（明细行 purchase_details）：
| 源字段 | 目标字段 | 类型 | 说明 |
|---|---|---|---|
| FMaterialId_FNumber | spec_no | DIRECT | 物料/SKU 编码 |
| FQty | num | DIRECT | 采购数量 |
| FPrice | price | DIRECT | 税前单价 |
| FEntryTaxRate | tax | TRANSFORM | 百分比转 0~1 小数，13% → 0.13 |
| FEntryDiscountRate | discount | TRANSFORM | 折扣率转小数 |
| FEntryNote / F_TPRO_LargeText | remark | DIRECT | 行备注 |
在轻易云上如何配置
在 Qeasy 的策略画布里，源端选 executeBillQuery，目标端选 wdt.purchase.purchaseorder.createorder。源端 buildModel: false 必须保留，由平台在数据流里按 FBillNo 做分组，把同单的多个分录行聚成 POOrderEntry 数组，再赋给目标端明细字段 purchase_details。
映射面板里，主表字段大多用 {``{FBillNo}} 这类模板直接取值，常量字段（purchaser_name、is_check、pay_type）在策略层直接固定；明细行通过循环把 POOrderEntry 数组展开。两条转换函数一定要加：一是 FEntryTaxRate/100 把税率从百分比变成 0~1，二是日期字段的 datetime 格式化。
编码映射集中管理是轻易云客户的常见做法：供应商、物料、仓库的编码差异统一在「编码映射」或主数据策略里维护，而不是散落在每条单据策略里。表头表体分阶段也常见------表头先稳跑一周，再放开表体循环，避免一上来就把全量明细打过去。
实施步骤
第一步：主数据前置。 同步跑起来之前，供应商、物料、仓库三套主数据必须先在两边对齐，否则 provider_no、spec_no、receive_warehouse_nos 都会推不过去。
第二步：全量触发。 第一次上线，用全量方式把历史已审核采购订单补齐，确认单据编号、供应商、税率、仓库都对得上。
第三步：增量起点。 切换到增量模式，过滤条件用金蝶的 FApproveDate >= LAST_SYNC_TIME and FDocumentStatus = 'C' and FPurchaseOrgId.FNumber = '100'------按审核日期拉取、只同步已审核单据、限定采购组织。
第四步：调度频率。 源端 */30 7-20 * * *，目标端 */31 7-20 * * *，错峰 1 分钟避开两端在同一秒触发。
第五步：联查准备。 下游的采购入库单同步要用 _findCollection 或 _mongoQuery 从方案集线器反查 FID、FPOOrderEntry_FEntryId，本策略的 FBillNo + 明细 goods_no 是关联键，提前确认联查字段已落库。
踩坑复盘
-
扁平化数据没分组就推。 金蝶返回是扁平结构，主表字段每行重复。如果不按
FBillNo分组，直接把每行当一条单据推到旺店通，会出现 N 张只有一行明细的重复采购单。稳妥做法是在数据流层做分组。 -
税率口径不一致。 金蝶
FEntryTaxRate是百分比，旺店通tax是 0~1。忘了除以 100，旺店通会按 13 倍税率算税，单据金额直接错位。 -
主数据没对齐就先跑业务单。 供应商、物料、仓库编码有一边缺数据，推过去就是空指针或编码不存在报错。
-
交货日期从明细行取，多行时取值规则模糊。
FDeliveryDate是明细行字段，多行时取首行还是按业务规则聚合，要在策略里写清楚，否则同一张单不同时间跑会出不同结果。 -
两端调度撞同一秒。 源端和目标端 crontab 完全一致时，平台容易在边界秒出现重复触发，错峰 1 分钟能显著降低这种风险。
适用场景与不适用场景
适用于：金蝶作为采购中台、旺店通作为门店/履约侧采购入口、单向同步已审核采购订单、跨系统编码已统一或可映射的场景。
不适用于：双向同步、反写金蝶、源端含未审核或暂存单据、税率口径与目标端完全不同的场景------这些都需要单独的策略设计。