3. 版本管理入门
监管报送的版本管理，本质上是给“同一份报送任务在不同时间点的不同形态”建立可识别、可追溯、可回退的管理机制。没有版本管理，补报与历史追溯就失去了基准：你无法说清“补的是哪一版”“追溯到的数据是不是当时提交的那一份”。因此，版本号、生命周期、状态与数据快照四者必须作为一个整体来理解。
一、核心原理：版本号是身份，状态是位置，快照是证据
版本号解决“这是哪一版”的识别问题；生命周期描述版本从产生到归档的完整过程；状态标记版本当前处于哪个可控节点；数据快照则锁定该版本在某一时刻所依赖的源数据与计算结果。四者关系可以概括为：版本号是身份标识，状态是流程位置，快照是数据证据，生命周期是时间轴。
监管报送中常见的版本号规则采用“主版本.次版本.修订号”三段式，例如 V2.1.3。主版本通常在报送口径、报表结构或监管规则发生重大变化时递增；次版本用于同一口径下的数据范围调整或补报批次；修订号用于同一批次内的错误修正。也有机构采用“报送期+批次+序号”的复合规则，如 2024Q1-B02-R01，其优势是直接携带时间与批次信息，便于人工识别。
关键原则：版本号一旦提交给监管或进入归档，就不可复用、不可覆盖。任何修改都必须产生新版本，即使只改了一个数字。
二、版本生命周期与四种状态
一个报送版本通常经历四个状态：草稿、审核、提交、归档。它们不是简单的标签，而是权限、可操作性和数据锁定程度的分界。
| 状态 | 可操作性 | 数据快照 | 典型责任人 |
|---|---|---|---|
| 草稿 | 可编辑、可删除、可重新生成 | 可随编辑刷新，允许临时快照 | 报送经办 |
| 审核 | 只读为主，退回后可回到草稿 | 冻结快照，审核基于该快照 | 复核人/业务负责人 |
| 提交 | 不可编辑，只能通过补报产生新版本 | 正式快照，与报送文件绑定 | 报送主管 |
| 归档 | 完全只读，长期留存 | 归档快照，含校验值与日志 | 档案/合规 |
状态迁移必须满足前置条件。例如，草稿进入审核前应完成必填项校验和总分核对；审核退回时必须记录退回原因和退回人；提交后若发现错误，不能直接改状态，而应创建补报版本，并在新版本中引用原版本号作为追溯依据。
版本状态迁移示例：
DRAFT(草稿) --提交审核--> REVIEW(审核)
REVIEW --审核通过--> SUBMITTED(提交)
REVIEW --审核退回--> DRAFT(草稿)
SUBMITTED --归档任务--> ARCHIVED(归档)
SUBMITTED --发现差错--> 新建补报版本(DRAFT)
三、版本与数据快照的关系
数据快照是版本管理的“证据层”。同一个版本号下，如果源数据发生变化而快照未锁定，就会出现“版本号没变、数据却变了”的严重问题，历史追溯将彻底失效。因此，快照应在状态进入审核时冻结，并在提交时生成正式快照标识。
快照至少应包含：源系统数据抽取时间、抽取批次号、关键指标计算结果、校验规则版本、操作人与时间戳。对于补报场景，新版本应同时保留“原版本快照”和“补报版本快照”，以便对比差异。实践中，快照可以存储在版本表中，也可以以文件形式与报送文件一并归档，但必须保证可通过版本号唯一检索。
实用做法：为每个版本生成一个快照指纹，例如对关键数据表做哈希。提交时记录指纹，归档后定期抽验。若指纹不一致，说明快照被篡改或存储损坏，可立即触发排查。
四、案例场景：一次季度报送的版本演进
某银行2024年一季度EAST报送，初始版本 2024Q1-V1.0.0 处于草稿；完成校验后进入审核，快照冻结；审核发现部分贷款五级分类口径有误，退回草稿，修改后生成 2024Q1-V1.1.0；审核通过并提交，状态为已提交，正式快照绑定。两周后监管通知补报，需调整部分字段，此时不能修改V1.1.0，而是创建 2024Q1-V1.2.0 作为补报版本，引用原版本号，提交后原版本仍保持已提交状态，新版本进入归档。整个过程中，每个版本都有独立快照，历史追溯时可清晰回答“当时提交了什么、后来补了什么”。
五、常见误区与复盘
- 误区一：提交后直接改数据。这会导致版本号与数据不一致，历史追溯时无法证明当时提交内容。正确做法是新建补报版本。
- 误区二：快照只在提交时生成。审核阶段若没有冻结快照，审核人看到的数据可能已变化，审核结论失去意义。
- 误区三：版本号随意命名。如“最终版”“最终版2”无法机器解析，也无法与报送批次对应。应统一规则并写入系统校验。
- 误区四：归档后删除中间版本。中间版本是追溯链的一部分，删除后无法还原版本演进过程，补报依据也会缺失。
复盘要点：版本管理的失败往往不是技术问题，而是流程纪律问题。必须明确“谁在什么状态下可以做什么”，并用系统强制约束，而不是依赖人工自觉。
掌握版本号规则、生命周期、状态与快照的关系后，后续的补报操作和历史追溯才有稳定的基准。版本管理做得好，补报就是一次有序的新版本创建；做得不好，补报就会变成对历史数据的破坏性修改。