返利单ERP单号回写策略:用友NCC到纷享销客的闭环实现
这个策略解决什么问题
返利单审批在ERP(用友NCC)完成后,业务人员仍需在CRM(纷享销客)里跟进开票、对账与客户沟通。一旦ERP单号回不来,CRM侧就要人工补录,跨系统对账也会失真。我们在客户现场常见的需求是:把ERP侧已生效的返利单据号、审批状态回写到CRM对应单据上,让业务侧以ERP为最终口径。本策略不传输明细行,只做单号+状态字段的轻量回写。
数据流向与字段映射
整体流向是:用友NCC(源,中间轮询)→ 轻易云数据集成平台(中转、过滤、映射)→ 纷享销客(目标,调用数据更新接口)。
| 维度 | 源端(用友NCC侧) | 中间层 | 目标端(纷享销客侧) |
|---|---|---|---|
| 主键 | id(平台内置) | 内部ID | 单据object_id(CRM侧) |
| 业务号 | number(返利单单号) | 直接透传 | 返利单ERP单号(自定义字段) |
| 状态 | status=2(已完成) | 过滤仅取2 | 流程状态/审批结果 |
| 时间窗 | created_at_begin/end | LAST_SYNC_TIME / CURRENT_TIME | — |
策略关键在于:status=2 作为过滤条件只拉已完成的单据,number 直接作为回写字段值,源端以 id 做幂等键。
在轻易云上如何配置
源端是查询类接口,目标端是写入类接口,这是典型的"查→改"二段式。在轻易云数据集成平台(Qeasy)上配置时,把策略拆成源注册、目标注册、映射编排三块:
- 源注册:API 选
QueryStrategyData,方法 POST,作用 QUERY。请求体固定传strategy_id、status=2、created_at_begin={{LAST_SYNC_TIME}}、created_at_end={{CURRENT_TIME}}。number字段标记为业务号,id字段开启idCheck用于后续去重。 - 目标注册:API 选
/cgi/crm/v2/data/update,方法 POST,作用 EXECUTE。请求体由data(表头对象)、triggerWorkFlow=true、triggerApprovalFlow=false三部分组成。 - 映射编排:把源端
number写入目标端data内的 ERP单号字段;源端id与目标端data.object_id做关联。触发流程而不触发审批,是这类"轻量回写"的稳妥选择——避免CRM侧二次审批导致状态来回跳。
实施步骤
- 增量起点:把
LAST_SYNC_TIME初始化为ERP返利单正式上线日零点,首次跑批取全量,后续按15分钟节奏增量。 - 全量触发:对历史数据一次性回灌,通常用临时调度在夜间执行,跑完后
LAST_SYNC_TIME切到当前时间。 - 调度频率:按素材里的
crontab即*/15 6-23 * * *,业务时段每15分钟一次,夜间停跑以降低ERP压力。 - 异常处置:源端返回失败或目标端
data为空时,策略进入重试队列;连续3次失败转人工。
踩坑复盘
- 别忘了
status过滤:早期版本没加status=2,把"等待中"的单据也回写了,CRM侧流程被错误触发,业务投诉。稳妥的做法是源端查询时硬过滤状态。 - 时间窗别用响应时间:素材里
response_at_begin/end留空,只用created_at窗,避免回写过的单据被重复处理。 - 编码映射集中管理:某零售企业的ERP单号和CRM字段名不一致,我们把映射表放在轻易云里集中维护,后续扩区域只需新增规则,不再改流程。
- 触发流程还是审批:CRM侧只触发流程、不触发审批(
triggerApprovalFlow=false),否则已结案单据会被再次推审批。 - 幂等键必须开:开启
idCheck后,重复数据会被去重,避免对同一CRM单据多次写入。
适用场景与不适用场景
适用:ERP为返利/费用结算唯一口径,CRM仅做跟进与展示;需要把ERP单号作为后续对账锚点。 不适用:明细行较多的返利结算(本策略只回写表头字段);双向实时联动的场景,需要走事件驱动而不是定时轮询。
适用场景与不适用场景(英文同段,保留为总结)
适用:ERP is the single source of truth for rebate settlement, CRM is only for follow-up and display, and the ERP document number needs to serve as the reconciliation anchor. 不适用:Scenarios with many line items (this strategy only writes back header fields), or bidirectional real-time scenarios that require event-driven rather than scheduled polling.