聚水潭销售订单→钉钉赠送及内购申请：单策略回传单号实战教程

这个策略解决什么问题

某零售企业在钉钉上用一张「公司产品赠送及内购申请表」做内部福利与样品领用审批，审批通过后再到聚水潭里落地为销售订单。问题是：审批单与销售单在两边各跑一套号，员工要把单号手动复制回钉钉，3 个月后两边数字就对不上了，财务对账每月都要追着业务问。

这条策略要做的事很收敛：把聚水潭的销售订单推回钉钉那张申请单上，并回写聚水潭生成的单号。一次项目里我们用轻易云数据集成平台承接这条链路，单策略即可闭环，无需自建中间表。

数据流向与字段映射

整体流向是「聚水潭 → 中间层 → 钉钉申请表」，并在钉钉侧做一次回写。

关键字段对照（源：聚水潭销售订单 / 目标：钉钉申请单）：

实际项目里，编码映射集中管理是反复强调的一点。聚水潭的 SKU 在钉钉侧是「物品名称」，我们把映射表放在轻易云的「编码映射」组件里统一维护，源端新增一个 SKU 不会出现「孤儿行」。

在轻易云上如何配置

1. 接入源与目标：源端选聚水潭销售订单（开放接口），目标端选钉钉自定义审批流，关联到那张申请表。
2. 数据源配置：聚水潭侧按「单据状态 = 已审核」过滤，避免把草稿单也推过去。
3. 字段映射：表头字段逐个绑定；表体走「明细行映射」节点，按 sku + qty 维度对齐。
4. 回写动作：在流程末端加一个「写回节点」，把聚水潭生成的 so_id 写回钉钉那张申请单的「销售单号」自定义字段。
5. 异常分支：找不到映射、字段超长、钉钉侧单据被撤回，分别走不同的告警通道。

实施步骤（分阶段调度）

我们通常按三段式推进：

• 阶段一：增量起点。先一次性把近 7 天已审核、且在钉钉侧能找到对应申请单的历史销售订单补齐，确认两边对得上再开调度。
• 阶段二：全量触发。在轻易云里跑一次「全量回填」，把当前所有未回写销售单号的申请单补齐。这一步是兜底，建议放在业务低峰执行。
• 阶段三：调度频率。常态调度建议 每 5 分钟轮询一次，以「单据最后修改时间」为增量条件；订单量大时可压到 1–2 分钟，但要把并发控制在钉钉侧限流阈值内。

回写动作独立成一个子流程，调度策略是「源端有结果才触发」，避免空跑写脏数据。

踩坑复盘

1. 回写单号被当成普通字段，没设唯一性。第一次上线时，钉钉侧同一条申请单被回写了两次。稳妥做法是：回写前先按「so_id 是否为空」做判断，已写过就跳过。
2. 表头先到、表体后到。聚水潭接口在某些情况下明细行会比表头晚一帧到，结果钉钉侧出现了「有金额无线」。我们后来在轻易云的「数据组装」节点里加了一个「整单就绪」的合并条件。
3. 钉钉侧撤回申请单。员工撤回后，聚水潭那边单据已经在走审核，链路没断，导致两边状态不一致。处理方式是：源端把「单据状态 = 已审核」改成「单据状态 ∈ {已审核、未审核且未撤回}」，并在异常分支里把异常明细转人工。
4. SKU 编码映射散落在脚本里。早期我们图省事直接写 JS，后来 SKU 一多就失控。轻易云的客户里常见的应对模式就是：编码映射集中管理，全量加载到内存，增量用定时任务刷新。
5. 限流被忽略。钉钉自定义表单写接口是有 QPS 上限的，5 分钟一轮没问题，但如果出现大批量补单，必须加分页与退避。

适用场景与不适用场景

适用：内部福利、样品领用、员工内购等审批驱动的业务，订单由申请单转化而来，需要回写业务号做对账。不适用：纯外部销售订单同步（不需要走钉钉审批）、跨组织代销（审批流不在钉钉）、以及单据体量超大需流式处理的场景（应另走批量通道）。