这个策略解决什么问题
某零售企业在钉钉上用一张「公司产品赠送及内购申请表」做内部福利与样品领用审批，审批通过后再到聚水潭里落地为销售订单。问题是：审批单与销售单在两边各跑一套号，员工要把单号手动复制回钉钉，3 个月后两边数字就对不上了，财务对账每月都要追着业务问。
这条策略要做的事很收敛：把聚水潭的销售订单推回钉钉那张申请单上，并回写聚水潭生成的单号。一次项目里我们用轻易云数据集成平台承接这条链路，单策略即可闭环，无需自建中间表。
数据流向与字段映射
整体流向是「聚水潭 → 中间层 → 钉钉申请表」，并在钉钉侧做一次回写。
关键字段对照（源：聚水潭销售订单 / 目标：钉钉申请单）：
| 业务含义 | 聚水潭销售订单（源） | 钉钉申请单（目标） | 处理方式 |
|---|---|---|---|
| 申请单号 | 外部单号 / io_id | 申请单主键 | 直接映射，作为关联键 |
| 销售单号 | so_id（生成后） | 自定义字段「销售单号」 | 回写 |
| 申请人 | 客户/下单人 | 申请人 | 映射 |
| 商品明细 | 表体：sku、qty、price | 表体：明细行 | 表体逐行映射 |
| 金额合计 | 订单总金额 | 申请金额 | 映射 |
| 审批状态 | 订单状态 | 审批结果 | 状态值映射 |
实际项目里，编码映射集中管理是反复强调的一点。聚水潭的 SKU 在钉钉侧是「物品名称」，我们把映射表放在轻易云的「编码映射」组件里统一维护，源端新增一个 SKU 不会出现「孤儿行」。
在轻易云上如何配置
- 接入源与目标：源端选聚水潭销售订单（开放接口），目标端选钉钉自定义审批流，关联到那张申请表。
- 数据源配置：聚水潭侧按「单据状态 = 已审核」过滤，避免把草稿单也推过去。
- 字段映射：表头字段逐个绑定；表体走「明细行映射」节点，按 sku + qty 维度对齐。
- 回写动作：在流程末端加一个「写回节点」，把聚水潭生成的 so_id 写回钉钉那张申请单的「销售单号」自定义字段。
- 异常分支：找不到映射、字段超长、钉钉侧单据被撤回，分别走不同的告警通道。
实施步骤（分阶段调度）
我们通常按三段式推进：
- 阶段一：增量起点。先一次性把近 7 天已审核、且在钉钉侧能找到对应申请单的历史销售订单补齐，确认两边对得上再开调度。
- 阶段二：全量触发。在轻易云里跑一次「全量回填」，把当前所有未回写销售单号的申请单补齐。这一步是兜底，建议放在业务低峰执行。
- 阶段三：调度频率。常态调度建议每 5 分钟轮询一次，以「单据最后修改时间」为增量条件；订单量大时可压到 1–2 分钟，但要把并发控制在钉钉侧限流阈值内。
回写动作独立成一个子流程，调度策略是「源端有结果才触发」，避免空跑写脏数据。
踩坑复盘
- 回写单号被当成普通字段，没设唯一性。第一次上线时，钉钉侧同一条申请单被回写了两次。稳妥做法是：回写前先按「so_id 是否为空」做判断，已写过就跳过。
- 表头先到、表体后到。聚水潭接口在某些情况下明细行会比表头晚一帧到，结果钉钉侧出现了「有金额无线」。我们后来在轻易云的「数据组装」节点里加了一个「整单就绪」的合并条件。
- 钉钉侧撤回申请单。员工撤回后，聚水潭那边单据已经在走审核，链路没断，导致两边状态不一致。处理方式是：源端把「单据状态 = 已审核」改成「单据状态 ∈ {已审核、未审核且未撤回}」，并在异常分支里把异常明细转人工。
- SKU 编码映射散落在脚本里。早期我们图省事直接写 JS，后来 SKU 一多就失控。轻易云的客户里常见的应对模式就是：编码映射集中管理，全量加载到内存，增量用定时任务刷新。
- 限流被忽略。钉钉自定义表单写接口是有 QPS 上限的，5 分钟一轮没问题，但如果出现大批量补单，必须加分页与退避。
