销售退货单审核同步实战:从钉钉审批到金蝶云星空的执行闭环
这个策略解决什么问题(场景与价值)
在某零售企业的实际项目里,销售退货流程最初是这样跑的:门店在钉钉提交退货审批,审批人走完流程后,需要有人在金蝶云星空里手动点"审核",才算真正生效。一个退货单跨两个系统、两次人工,出错率不低。我们用轻易云数据集成平台(Qeasy)承接这段链路,目标是把钉钉侧的审批结果自动回写到金蝶云星空执行审核,让单据状态在两边一致。
数据流向与字段映射(源 → 中间层 → 目标)
整体走向是:钉钉(审批完成事件)→ 轻易云中间层(聚拢、过滤、补字段)→ 金蝶云星空(执行审核)。
源端是从钉钉审批实例里取数,使用 topapi/processinstance/get 这类查询接口,拿到审批完成后的关键字段,核心包括:
- 单据编号:作为后续回写的唯一标识,必须与金蝶侧的编码严格一致。
- 办理人:实际审批人,用于审计追溯。
- 单据日期:审批完成时间,影响金蝶侧的业务日期。
- 退货组织、事业部:决定金蝶侧组织维度,务必在中间层校验非空。
目标端是金蝶云星空的审核执行接口(Audit),请求体里需要重点处理的字段对照如下:
| 目标端字段 | 含义 | 典型取值 / 来源 |
|---|---|---|
| FormId | 单据类型表单 ID | 固定值 SAL_RETURNSTOCK(销售退货单) |
| Numbers | 单据编码 | 取自源端"单据编号",需在中间层做编码映射 |
| InterationFlags | 交互标志 | 常用 STK_InvCheckResult,允许负库存 |
| IgnoreInterationFlag | 是否忽略交互 | true,避免交互式检查阻塞 |
| NetworkCtrl | 网络控制 | 默认 false |
| IsVerifyProcInst | 是否校验流程实例 | 按企业流程规范设置,本项目置为 true |
提示:FormId 不是单据编号,是金蝶单据元数据里的表单模型 ID,容易被误填,务必从元数据列表里确认。
在轻易云上如何配置
整个策略在轻易云里的配置思路是"源 + 目标 + 聚合 + 触发",下面是我们现场常用的配置要点。
源端组件(钉钉):选择钉钉连接器,API 选 topapi/processinstance/get,方法 POST,作用 QUERY。因为我们只关心审批完成事件,通常会在中间层用审批结果状态过滤,而不是把全部实例拉回来。
目标端组件(金蝶云星空):选择金蝶云星空连接器,API 选 Audit,方法 POST,作用 EXECUTE。请求体按上面那张表的字段填,特别注意 FormId 必须填 SAL_RETURNSTOCK,Numbers 用变量引用源端"单据编号"。
编码映射集中管理:轻易云的客户现场常见做法是把组织、事业部等编码映射放到独立的映射表里,而不是硬编码在策略里。这样,新增门店或组织变更时,只改映射表,不改策略。
表头表体分阶段:本策略只处理表头层面的审核动作,表体明细在另一条策略里同步。如果客户把表头表体混在一次请求里,容易出现"审核了但行项目没进去"的脏数据。
增量与全量双轨:投产初期,我们用全量跑一遍历史单据做对账;稳态后切换为按审批完成时间增量。轻易云的调度配置支持两者并存,核对无误差后再下线全量。
实施步骤
- 确认源头字段:在钉钉审批模板里确认"单据编号"字段值与金蝶侧编码完全一致,这是后续匹配的基础。
- 搭建中间层:在轻易云里配置聚合组件,只透传"已通过"状态的实例;补齐组织、事业部等金蝶侧必填维度。
- 配置目标调用:把请求体的 FormId 固定为
SAL_RETURNSTOCK,其他字段通过变量绑定;先把IsVerifyProcInst置为true,观察一段时间的失败日志。 - 调度频率:本项目调度为
*/3 * * * *,即每 3 分钟轮询一次。考虑到审批是离散事件,过密会增加接口压力,过疏又会让用户感觉"审批完要等"。3 分钟是一个折中点。 - 增量起点:用最近一次审批完成时间作为增量起点;若要重跑历史,切换为全量,但要谨慎,避免重复审核。
- 观测与告警:配置失败重试和告警,金蝶侧审核失败的常见原因是单据被锁定或上游维度缺失,这两类要分开统计。
踩坑复盘
- FormId 误填成单据编号:这是最典型的错误。FormId 是金蝶单据元数据里的表单模型 ID,不是业务单据号。我们见过客户直接把单据号当 FormId 提交,接口返回成功但实际没有任何动作。
- InterationFlags 漏配:如果不传
STK_InvCheckResult,退货场景下经常被负库存检查拦下。建议生产环境固定传该标志,并把IgnoreInterationFlag设为true,避免交互式阻塞。 - 调度过密导致重复审核:某些项目里,3 分钟一次轮询如果没用好增量起点,会重复拉取已审核的单据,产生脏调用。稳妥的做法是增量起点 + 状态字段双重判断。
- 组织维度缺失被静默丢弃:钉钉侧的"退货组织"在某些门店没填,金蝶侧必填,容易被默认跳过。我们要求在中间层做非空校验,缺失直接进告警,而不是放行。
- 历史与增量混跑:投产初期最容易翻车的点——全量回补和增量同时开,导致同一单据被多次审核。必须明确"先全量、后增量",核对一致再切换。
适用场景与不适用场景
适用:审批流在钉钉、执行流在金蝶云星空的销售退货业务;门店或组织数量稳定,编码映射可一次性维护。
不适用:金蝶侧需要人工二次确认的场景(本策略会跳过人工);退货单存在多级反审或驳回后再提交流程的复杂业务,本策略只覆盖"审核通过→执行"这一段。