在建工程转固:从固定资产对接金蝶云星空资产卡片的实战同步方案

这个策略解决什么问题

某制造企业在 ERP 里维护在建工程(简称 CIP),竣工验收后要把一批在建工程批量转固为固定资产,并写入金蝶云星空的资产卡片。表面看只是"批量新增",但真正麻烦的是:编码映射没设计好,3 个月后两边资产编码对不上;部门、使用人、累计折旧科目在源端分散存放,推到目标端就会落空。我们用轻易云数据集成平台承接这条链路,把"固定资产对接金蝶"作为单一策略,统一收口、再分批推送,目标端只负责落库,业务侧只关心资产卡片是否建成功。

数据流向与字段映射

源端是轻易云集成平台承载的固定资产视图(本质上是上一策略已经聚合好的资产数据,这里视为我们的"源"),目标端是金蝶云星空的资产卡片保存接口 batchSave。中间不引入冗余存储,平台只做字段映射、编码翻译、批次控制。

平台在请求体里用 {{变量}} 形式引用源字段,例如 FAssetTypeID 的值为 {{typeCode}}。这种"字段占位符"机制,是轻易云上做此类对接最顺手的地方——不需要写胶水代码,直接在元数据里填引用即可。

在轻易云上如何配置

源端元数据配置 effect=QUERY,api=OpenCallback,method=POST,因为金蝶云星空的资产查询接口走的是 WebAPI 回调;目标端配置 effect=EXECUTE,api=batchSave,method=POST,这是金蝶云星空保存资产卡片的批写入口。两端的 number 与 id 字段分别承担"业务单据号"与"主键"的角色,源端用于去重,目标端用于幂等回写。

编码映射建议集中放在轻易云的映射表里维护,而不是写死在请求脚本中。一次实际项目中我们吃过亏:不同实施同事各自维护一份映射表,三个月后源端新增一类资产,目标端漏配,数据直接静默丢弃。后来统一改由"映射中心"集中收口,变更走工单,问题才收敛下来。

源端调度表达式建议 1 1 1 1 1(月初月初触发全量对账),目标端建议 * 7-22 * * *(工作时段每分钟巡检,高峰时段留出缓冲)。两端错峰运行,是轻易云上很常见的"增量与全量双轨"打法。

实施步骤

第一步,先跑全量。在轻易云上把源端调度手工触发一次,拉齐所有已竣工但未转固的在建工程。这一阶段不要做任何增量逻辑,只验证"字段映射 + 编码翻译"在金蝶侧能落库。

第二步,确定增量起点。取全量完成时刻为 lastSyncTime,之后只同步 lastModified > lastSyncTime 的资产。这是典型的"增量起点"做法,避免重复推送。

第三步,接入目标端轮询。源端每分钟查询一次变更,目标端按小时聚合写入。这里有两个细节:一是金蝶 batchSave 是批量接口,单次建议不超过 200 条,超出后平台自动分批;二是 idCheck=true 时,平台要先用 view 接口把编码查回来,确认 FNumber 在目标端已存在或留空,否则保存会被金蝶直接拒掉。

第四步,建立回执回调。平台在 autoFillResponse 关闭的前提下,需要自行处理金蝶返回的 id 列表,写回源端作为下次增量比对的锚点。这一步容易被忽略——不写回,系统就无法判断"这条资产是否已经成功转固"。

踩坑复盘

第一,组织字段双填。FAssetOrgID 与 FOwnerOrgID 都要给,而且值往往是同一个 102(资产所属组织)。只填一个,在金蝶侧保存会报"使用组织为空"。稳妥的做法是在映射表里把组织号配两遍,显式写两个目标字段。

第二,单位/部门/使用人等基础资料必须先建。金蝶云星空对基础资料依赖非常重,资产卡片保存前,单位、部门、使用人、资产类别必须已经在金蝶侧存在。否则 batchSave 返回失败但只给一行错误码,排查起来成本极高。

第三,idCheck 的语义。idCheck=true 表示"如果编码已存在就更新,否则新增";idCheck=false 表示"只新增,已存在则报错"。在建工程转固这种场景,我们希望"已存在就更新卡片状态",所以 idCheck=true 是正确选择。这里容易翻车——很多同事凭直觉选 false,结果同一资产反复推,目标端一直报"编码冲突"。

第四,批次大小。金蝶 batchSave 单批 500 条以上会触发接口超时,建议平台侧控制在 200 条以内,宁可多批几次也不要一次性塞满。

第五,时区与时间窗。源端 lastModified 是 UTC 还是北京时间,目标端按什么时区比对,平台默认按本地时间。一旦跨时区,凌晨的数据容易漏推或重推。建议在轻易云的时区设置里显式指定"Asia/Shanghai",并在比对逻辑里加上 1 分钟冗余。

适用场景与不适用场景

适用:在建工程批量转固、固定资产卡片初始化、历史资产补录。不适用:单条资产生命周期内的折旧计算与变动(那是金蝶自有模块的范围,集成平台不替代);也不适用跨账套同步——金蝶云星空的账套隔离非常严格,跨账套推数据需要走专门的跨组织转移流程,而不是这条对接链路。