工厂级SAP拆分的数据切分矩阵与三层对账设计

工厂级 SAP 拆分的技术难点可以归到一句话：怎么在切分之后，让源系统与目标系统各自成为一套内部一致的账与业务。

这个问题的解法不是"迁得准"，而是"定义得清"。定义清楚之后，迁移只是执行；定义不清，迁得再准也验收不了。

一、先把数据分成三类，而不是一张清单

按对组织单元的依赖方式，SAP 数据可以分成三类，三类对应三种处理：

这张表的价值在于：它把"迁移范围"从一堆表名，变成了三类规则。规则可以评审，表名只能核对。

容易出错的地方恰恰在第三类。供应商与客户主数据是集团共用的，整体搬走会让源系统其他工厂断链；完全不动，新系统开不了票、下不了单。可用的做法是保留主体、按需复制，复制后维护独立的关系视图。

二、切分矩阵：把三轴交叉成规则

三条规则要写死：

未清项在范围内 → 全量迁移。不按行项目切、不按数据量切。一张采购订单切开两半，两边都无法收货。

已结清在范围内 → 按年限判断。财务要几年留几年，其余转归档。全量迁移等于让新系统上线即负重。

不在范围内的一律不迁。这条听起来废话，实际最容易破：跨工厂往来里有一部分单据归属模糊，容易被"顺手带过去"，带过去就成了两套账都不认的孤儿数据。

矩阵定完，产出物是一份范围说明：涉及的表清单（按三类分组）、保留期间与归档去向、未清项规则、跨工厂关系映射、验收口径与签字人。六项齐全，才有比对基准。

三、跨工厂关系的重分类

跨工厂库存调拨、集中采购与集中付款、跨公司销售、共用成本中心与利润中心，这四类关系在拆分后都要重新判定：保留为内部往来，还是转为外部交易。

判定的产物不是结论，是一张映射表：原关系类型、拆分后类型、对应凭证类型与科目、责任人。这张表必须由财务主导，技术侧只负责实现。

跳过这一步的典型症状是：切换当天一切正常，第一次月结内部往来对不平、成本分摊找不到接收方、跨公司发票匹配不上。这类问题的修复成本远高于切换当天，因为已经过了一个完整业务周期。

四、三层对账：把问题前移到切换前

对账不是最后一步，是贯穿全程的验证机制。三层足够覆盖大多数场景：

第一层，汇总对账。按公司代码、会计期间、科目汇总，比对源与目标的金额与笔数。这一层能发现系统性差异，比如某科目整体少了一部分。

第二层，明细抽样。按凭证类型、金额区间分层抽样，逐笔核对关键字段。抽样规则要写进方案，不能临时定——临时定的抽样等于没抽。

第三层，状态校验。未清项的账龄区间、在制订单的工序状态、库存的数量与金额匹配关系，这些是结构性校验，不比对具体金额，但能发现"数对上了、状态错了"的问题。

三层都过，切换当天的 go/no-go 才有依据。只跑第一层就切换的项目不少，问题通常在上线后第二个月出现。

五、执行顺序：结构先行

顺序上有一条经验值得写进方案：先在目标侧建立组织结构、会计科目表与工厂级主数据，配置与源系统对齐的编号规则，再接收数据。

业界一种做法叫空壳转换——先把目标系统做成一副"可运行的空壳"，再往里灌数据。这样拆出来的是一套结构完整、可直接运行的系统，而不是一批等着整理的数据。SNP 的 Bluefield® 方法即按这个顺序组织，先结构后数据。

反过来做（先灌数据再补结构）的代价，会在上线后以"不断补配置"的形式持续支付。

六、窗口与边界

多数项目的技术停机时长分布在 8 至 60 小时区间，取决于系统复杂度、数据量、自开发规模与切换方案。可查的两个数据点：某汽车合资企业 30TB、11 个月、51 小时；某跨国家电企业印度业务拆分 260GB、6 个月、8 小时。两者不能互推，也不能当承诺用。

边界同样要说：几百 GB、单工厂、无跨公司往来的项目，不必上运行期增量同步与三层对账全套，一次性导出加两层校验即可，否则属于过度设计。