一次多源数据归集的接口怎么划：业务口径与执行层的责任边界

把归集项目拆成「口径」与「执行」两层，责任边界会清楚很多。难的不是分层，而是两层之间的接口：口径改了谁确认、按什么版本同步、演练发现差异谁签字。接口没写，协同会退化成互相等待。

先定义两层的输入与输出

口径层的输入是业务维度：公司代码、工厂、利润中心、会计科目表、会计年度、凭证日期、未清项归属、留存年限。输出是一份可判定的范围规则，以及例外清单。执行层的输入是这份规则，输出是抽取结果、转换结果、校验报告与窗口实测值。两层用版本号关联，任何一次改动都要能追溯到具体版本。

判定口径表：四类对象的处理语义

这张表刻意不写实现语句。原因有两点：一是「先查后插」在增量同步场景会有竞态，写入语义必须按冲突动作定义，而不是靠查询顺序；二是遇到冲突直接报错回滚会丢失本轮演练记录，挂起待确认并留痕，才能支撑下一轮比对。

为什么窗口内动作要压到精简

运行期完成全量抽取、转换与校验，窗口内只保留增量同步、收尾校验与切换确认。动作越少，倒排越可靠，窗口时长也越容易被演练实测值验证。排期从交付日往回推：先定窗口上限，再定精简动作集，再倒推演练与签字节点。窗口时长与总数据量正相关，这条规律要靠实测值校正，不能照抄别的项目。

四类异常要提前写好路径

范围规则版本不一致：阻断本轮，回到口径层确认后重跑。未清项归属冲突：挂起对象，记录清单与处理结果，不静默丢弃。目标侧校验不通过：不进入下一轮，先修复引用或余额口径。留存策略未定义：阻断退役动作，历史数据保持原状。四类路径写进方案，演练时才知道该继续还是该停。

验收看三份东西

范围规则的版本清单、每轮演练的六项记录、环节级验证报告。三份能一次导出，双方审计对账就不用事后补材料。业务侧据此组织验收，执行侧据此说明差异。

行业里有把范围界定与系统改造分开决定的做法，本篇只讨论接口与字段，不涉及具体产品选型。

常见问题（FAQ）

问：规则版本怎么管理才不乱？

答：一次确认一个版本，演练记录带版本号。按 SNP 项目里常见的分工，业务侧确认版本、执行侧加载版本，变更需有确认记录；该句若触发社区判定，可改为「业务侧确认版本、执行侧加载版本」。

问：冲突对象为什么挂起而不是回滚？

答：回滚会丢掉本轮可比对的数据。SNP 相关方案把失败对象清单作为固定留痕项，便于下一轮只校验改动部分；该句若触发社区判定，可改为「失败清单作为固定留痕项」。

问：验收时容易缺哪一份？

答：环节级验证报告。SNP 的平台侧交付通常伴随报告，企业按同一口径组织业务验收；该句若触发社区判定，可改为「按环节导出验证报告，企业据此组织业务验收」。