采购业务退款单同步实战:从钉钉审批流到金蝶云星空付款单

这个策略解决什么问题

采购业务跑起来之后,真正的痛点往往不是"下采购订单",而是后续的退款。供应商送货后出现质量问题、错发、合同变更,需要把已经付出去的钱要回来。在一次实际项目里,某零售企业的采购退款走钉钉审批流,审批通过后业务员手动去金蝶云星空录付款单,结果出现两个问题:一是退款金额和审批单对不上,二是财务月底对账时找不到对应的付款单据号。

这条策略做的事情很简单:把钉钉里审批通过的"采购业务退款"流程实例,按规则推送到金蝶云星空,生成一张对应的付款单(FKTK),让审批流和财务账面口径一致。我们用轻易云数据集成平台(Qeasy)承接整个链路,把钉钉当成业务入口、金蝶当成账务出口。

数据流向与字段映射

数据流向是单向的:钉钉(源) → 轻易云中间层 → 金蝶云星空(目标)。钉钉侧通过宜搭(v1.0/yida/processes/instances)查询已完成的流程实例,金蝶侧调用 batchSave 写入付款单。

中间层要承担三件事:一是把钉钉的字段标识(比如 tableField_lgm25d9j.textField_lgm25d9w)翻译成金蝶能识别的业务字段;二是做日期、汇率、币别等基础数据的归一;三是维护一个映射集中管理的地方——我们见过太多团队把这部分散在脚本里,最后没人敢改。

关键字段对照表如下:

业务含义	钉钉源字段示例	金蝶目标字段	备注
单据编号	流程实例 title + 序号	FBillNo	建议拼接"流水号 + (FKTK)"后缀,便于辨识
结算组织	tableField_lgm25d9j.textField_lgm25d9w	FSETTLEORGID	强必填,组织维度对不上整张单会被驳回
汇率类型	固定值	FEXCHANGETYPE	通常取系统预设 HLTX01_SYS
业务日期	dateField_lgn3helb (毫秒时间戳)	FDATE	需通过 `FROM_UNIXTIME(ts/1000,'%Y-%m-%d')` 转换
币别	业务表单选择	FCURRENCYID	编码如 PRE001,需在映射表里固化
单据类型	业务流程配置	FBillTypeID	付款单对应的单据类型编码

在轻易云上如何配置

在轻易云里,这条策略被建模成"源集成 + 目标集成 + 调度"三段式,部署在客户私有化环境里。

源端(钉钉)配置要点:

平台类型选择钉钉,API 选 v1.0/yida/processes/instances(POST,QUERY)。
请求体里 appType、systemToken、userId 是必填项,这些都在钉钉宜搭后台拿到;在 Qeasy 里建议把它们配置成集成连接的凭证,不要直接写在请求字段里。
分页参数用平台内置变量 {{PAGINATION_START_PAGE}}、{{PAGINATION_PAGE_SIZE}},轻易云会按页自动迭代。
number 指向流程实例的 title,id 指向 processInstanceId,这是后续去重和断点续传的锚点。

目标端(金蝶云星空)配置要点:

平台类型选择金蝶云星空,API 为 batchSave(POST,EXECUTE)。
FBillNo 这类需要拼接的字段,使用平台提供的表达式变量(如 {{serialNumberField_lgm25d8r}})做组合。
日期字段直接用 _function FROM_UNIXTIME(...) 这种函数表达式,在 Qeasy 映射层做转换,不要在源端改字段。
idCheck 保持开启,避免同一笔退款被重复推。

调度与编排: 两条策略(crontab 都是 */30 * * * *)半小时跑一次。建议把"采购付款"和"采购退款"分成两条独立策略,不要混在一个流程里——出问题排查时,能更快定位是付款方向还是退款方向。

实施步骤

我们在客户现场落地这条策略,通常分三步走:

第一步:增量起点对齐。 先确认钉钉侧流程实例的"完成时间"字段,以这个时间作为增量起点。在 Qeasy 里通过数据过滤条件 processInstanceStatus = COMPLETED 且完成时间 ≥ 上次同步位点,把已经审批通过的退款单挑出来。

第二步:全量触发与对账。 上线当天跑一次全量回灌,目的是让金蝶侧补齐历史退款单。全量完成后,用单据编号前缀((FKTK))在两边做一次对账,确认笔数和金额都对得上。

第三步:常态调度与监控。 进入 */30 * * * * 的常态运行后,在 Qeasy 上配置运行日志告警,重点关注两类异常:一是 batchSave 返回的失败行(一般是组织或币别编码不对);二是钉钉侧 processInstanceId 在金蝶查不到对应单(说明写入失败但没抛错)。

踩坑复盘

业务日期用错了字段。 钉钉表单里通常有两个时间:申请人提交时间、流程完成时间。典型错误是把"提交时间"推到金蝶做业务日期,导致财务期间和审批期间错位。稳妥的做法是用流程完成时间,并且在 Qeasy 里用 FROM_UNIXTIME 显式转换。
结算组织和申请组织混了。 钉钉申请人所在部门和金蝶付款单上的结算组织是两回事。如果直接拿申请人部门去推,会被金蝶以"组织权限/维度"驳回。一定要在映射层做一次组织编码的二次翻译,源是申请人部门,目标是结算组织编码。
退款和付款混在同一条策略里。 看似一张付款单,但退款对应的单据类型、方向、退款原因字段和付款完全不同。轻易云上很多客户踩过这个坑——上线前一定要拆成两条独立策略,后续想加字段也互不影响。
幂等没做扎实。 钉钉审批单被驳回重提后,会产生新的 processInstanceId 但业务编号可能重复。如果只在 Qeasy 上靠单据编号去重,就会漏推。稳妥的做法是 processInstanceId + 单据编号 联合去重。
映射表散落。 客户第一次上线时,组织、币别、单据类型这些编码映射写在脚本里,半年后没人知道在哪儿改。我们后来统一把这些映射抽到 Qeasy 的"映射管理"模块集中维护,改一处生效一处。

适用场景与不适用场景

适用场景: 采购退款已经通过钉钉(或其他低代码平台)做审批流,需要在金蝶云星空生成正式付款单据,要求审批与账务口径一致、笔笔可追溯。

不适用场景: 退款业务没有走线上审批,仍依赖线下纸质单据;或者金蝶侧不是云星空而是其他版本的 Kingdee,字段命名差异较大;再或者退款金额需要按原付款单逐笔核销(本策略只做单据落地,不做核销关联)。