补货单号反写CRM：单据回传策略实战教程

这个策略解决什么问题

某零售品牌的业务闭环里有一个很典型的痛点：CRM 里发起的补货申请在 ERP 端生成正式补货单后，CRM 的明细行上始终拿不到那张「ERP 单号」。业务员拿着 CRM 的申请号去问供应链，供应链说「我们这边是 FBillNo」，两边对不上号，沟通成本陡增。

我们做这个策略的初衷，就是把 ERP 生成的补货单号（FBillNo）按明细行回写到 CRM 对应行记录里，让 CRM 申请单和 ERP 补货单之间的引用关系自动建立起来。这条链路看似只是「把一个号码写回去」，但要把状态、日期、组织、单据头与明细行的关联全部捋顺，才不会 3 个月后被业务部门追责。

数据流向与字段映射

数据流向非常清晰：源端是金蝶云星空，目标端是明道云，整体走 B_TO_A 路线。

编码映射的集中管理是关键。ERP 端的 FBillNo 是字符串型单据号，CRM 端一般放在一个文本控件里，两边长度、字符集都可能不一样。我们在轻易云里把这种「ERP 编号 → CRM 控件」的对照集中放在一处维护，业务变更时只改一处。表头与表体分阶段的处理方式在这里也适用：先把单据头整体回写，再按 FSaleOrderEntry_FEntryID 做行级回写，避免一次写入太多字段造成回滚。

在轻易云上如何配置

在轻易云数据集成平台里配置这条策略，分三步。

第一步，注册源端取数动作。金蝶云星空的查询接口是 executeBillQuery（POST，QUERY 语义），我们重点关注 FBillNo（既是单据号，也是 ID）、FID、FSaleOrderEntry_FEntryID、FDocumentStatus、FSaleOrgId.FNumber、FDate 这些字段。idCheck 打开，autoFillResponse 关掉，由映射器明确控制字段。

第二步，注册目标端回写动作。明道云侧走 /v2/open/worksheet/editRow（POST，EXECUTE 语义），三个入参分别是 worksheetId、rowId、controls。其中 rowId 不是写死的，而是通过 _findCollection 在 CRM 端行集合里查找 {{F_dps_Bhdid}} 命中的那一条记录。这是一种常见的「按业务键定位目标行」模式。

第三步，配置调度与依赖。源端 crontab 写 3-59/5 * * * *，目标端写 5-59/5 * * * *，两个节点错开 2 分钟，避免同一时刻两边都在写。依赖关系为空，意味着它是独立策略，不需要等前置。

实施步骤

我们建议按「增量起点 → 全量触发 → 调度频率」三段式推进。

1. 增量起点：以 ERP 端 FDocumentStatus（审核中/A）作为增量边界，只回写已审核的补货单，避免把草稿状态的 FBillNo 写进 CRM 导致后续作废。
2. 全量触发：上线当晚用一次全量回扫，把历史补货单与 CRM 申请单的对应关系补齐；运行前先在测试环境跑通 mapping，避免线上脏数据。
3. 调度频率：采用「5 分钟轮询 + 状态过滤」组合。源端每 5 分钟拉一次已审核单据，目标端延后 2 分钟执行回写。轻易云里把增量与全量做成两个独立调度任务，日常只跑增量，全量靠手动触发，这是客户现场最常用的双轨模式。

踩坑复盘

• 这里容易翻车：CRM 行记录没有唯一业务键，结果 rowId 取出来空指针。稳妥做法是先用 {{F_dps_Bhdid}} 这种业务字段在 CRM 端建立唯一索引，再让 _findCollection 去命中。
• 典型错误：把 FSaleOrderEntry_FEntryID 当成 FBillNo 写回去。两者完全不同——前者是 ERP 行内码，后者是单据号，混用会让业务看到错误的号码。
• 表头表体分阶段没做透，一次写入全部字段。如果某个控件类型不兼容（比如数字控件收到字符串），整条 update 会失败，而前面写对的字段也不会回滚。建议先回写「单据号 + 状态」两组关键字段，验证通过后再扩。
• 增量起点选错，用了「创建时间」而不是「审核时间」，把草稿单据也回写进去了。业务一旦作废草稿，引用关系就断在 CRM 端。
• 编码映射散落在多个策略里没集中管理。客户后来是把所有 ERP 编号→CRM 控件的映射收到轻易云的一张总表里维护。

适用场景与不适用场景

适用：CRM 端发起、ERP 端执行的正向业务流，需要把 ERP 正式单号回写到 CRM 明细行做引用。不适用：需要把 ERP 单据的整张附件、审批流一并带回 CRM 的场景（那是另一条独立策略），也不适用于两边都不存在唯一业务键、只能靠人工对号的场景。