GIS与AGIS关系辨析：公司间交易引擎配置与Fusion迁移

1. 先把概念捋直：GIS 和 AGIS 到底是不是两套东西

去年帮一个集团做自研 ERP 平台的公司间交易模块评审，方案文档第一页就写着“本期需对接 GIS 与 AGIS 两套公司间交易能力，分别覆盖存量与增量场景”。评审进行到一半，被一位做财务系统十几年的架构师打断：“R12.2 里没有并列的 GIS 和 AGIS，你这话写进方案，后面所有工作量估算都是错的。”

这句话是整个项目的转折点。会后我们花了整整两天，把 GIS、AGIS、Fusion 公司间交易以及分配能力这条线从头理了一遍，才发现很多流传在文档里的说法，都是把版本演进关系误读成了产品并列关系。这篇就围绕这条线讲透四件事：GIS与AGIS的真实关系、公司间交易引擎的设计逻辑、可落地的配置与实现步骤、以及老能力怎么映射到Fusion云套件上。适合正在做 ERP 财务模块实施、迁移评估或者对账自动化的同行参考，无论你是刚开始接触公司间交易的新手，还是已经配过几轮规则但总在期末对账掉坑的老手，都能从里面拿到可以直接抄的配置思路和排查路径。

1.1 核心结论先摆出来：AGIS 是 GIS 的增强形态，不是平行产品

我先把最容易被误传的那句话写清楚：在 R12.2 这个版本上，并不存在“GIS 和 AGIS 两套并列的公司间交易功能”。准确的说法是，GIS（Global Intercompany System）是较早阶段引入的公司间交易能力集合，AGIS（Advanced Global Intercompany System）是在它基础上做过整体增强之后的形态。两者是同一产品线的前后版本关系，不是两个可以同时启用、互相备份的模块。

这个区别为什么重要？因为它直接决定了三件事的判断：

• 工作量估算。如果误以为是两套并行系统，就会安排两拨人分别做对接，实际只需要围绕一套能力做配置和扩展。
• 数据迁移范围。存量数据只有一套模型，不需要做两套映射。
• 职责与权限设计。菜单路径、并发程序、接口表都是同一套，多建一套职责反而会造成权限混乱。

打个生活化的比方：GIS 像是早期那台只能手动调档的电风扇，AGIS 是同一台机器换了变频电机、加了遥控和定时。你不会说“我家有两台风扇，一台叫风扇一台叫遥控风扇”，它就是一台风扇的两个阶段。

所以当你在方案里看到“并行支持 GIS 与 AGIS”这种表述，第一反应应该是追问：具体指哪个版本、哪个职责菜单、哪张接口表。答不上来的，基本就是把演进关系抄成了并列关系。

1.2 演进过程复盘：能力是怎么一步步长出来的

把时间线摊开看会更清楚。早期阶段的公司间交易能力，核心解决的是“同一套账里，两个业务单元之间发生往来，怎么把成对的分录记进去”。那个阶段的典型特征是以手工录入为主，操作路径集中在一个专门的公司间交易职责里，交易靠批次（Batch）组织，一个批次下挂多笔交易，录入完成后走提交、审批、过账的流程。

这个阶段的能力边界很明显：跨账簿的场景支持得比较勉强，账户推导规则偏弱，很多判断要靠人工在录入时选对交易类型；跟库存、应收应付这些业务模块的自动集成度也不高，很多企业实际上是靠财务人员在月末手工补录。

后来这一块做了整体增强，主要补了四块能力：一是引入了更完整的交易类型和账户推导规则体系，让“什么业务该走什么科目”从人工判断变成配置决定；二是把跨业务实体、跨账簿的公司间往来纳入统一处理；三是加强了与库存调拨、应收应付发票的集成，业务单据能自动生成对应的公司间交易；四是把公司间平衡规则独立出来，让总账过账时能自动补对手方分录。

这些增强叠加起来，就是 AGIS 的实质内容。它没有推翻原来的模型，而是在同一套模型上把配置能力、集成能力和规则表达能力都做厚了。R12.2 上你打开菜单看到的，就是增强后的形态，旧的那套入口基本已经被取代。

注意：不同小版本之间，菜单名称和并发程序名称可能还有细微差异。做方案时不要凭记忆写路径，一定要在实际环境里点一遍，把职责名、菜单名、并发程序短名都截图留档，这是后面写操作手册的原始素材。

1.3 三个必须分清的边界：交易、平衡、分配

概念混乱往往不是出在 GIS/AGIS 上，而是出在“公司间交易”“公司间平衡”“分配”这三个词被混着用。我在项目里见过把三者写成一个模块的，也见过把它们当成完全无关的三件事分别立项的，两种都麻烦。

我的划分方式是这样：

公司间交易是业务事实的账务表达。A 实体把一批货调给 B 实体，或者 A 实体为 B 实体提供了技术服务，这件事在账上必须体现为两条腿：A 这边是收入或者转出，B 这边是成本或者转入。交易模块负责的就是把这两条腿成对地生成出来。

公司间平衡是账务的兜底机制。当一张日记账分录的借贷方落在了不同的公司段上，总账在过账时会发现“这家公司的账不平”，平衡规则的作用就是自动补上对方的分录，让每家公司自己的账都是平的。它处理的是“分录层面的不平衡”，而不是“业务层面的往来”。

分配则是另一层的东西，处理的是共同成本或者共同收入怎么归到各个承担主体上。比如集团共享服务中心一年的人力成本，要按各业务单元的营收或者人头分摊下去。它属于总账层的能力，跟公司间交易有关联但不等价。

这三者的关系可以这样理解：交易是源头，产生往来；平衡是保险，保证单家账平；分配是归属，解决共同费用往哪儿放。实际项目里最容易出问题的地方，是把“分配”当成“平账工具”来用，结果分摊规则越配越复杂，最后没人说得清一笔费用到底该落在哪。

2. 设计逻辑拆解：公司间交易为什么要做成一个引擎

理解了概念关系，接下来要看的是设计层面。很多自研平台在做公司间交易时，第一反应是“写个功能页面让财务录分录”，做完上线三个月就开始出问题。原因不在于功能做得不好，而在于把一件本质上需要引擎化处理的事情，做成了一个录入工具。

2.1 手工做公司间交易的三笔烂账

先说我见过的三个典型场景，都是真实踩过的坑。

第一种是漏记对手方。A 实体把货调给 B 实体，业务部门在库存系统里做了调拨，财务在 A 这边记了转出，但 B 那边因为单据没流转过去，成本一直没入账。等到季度合并报表，内部往来对不平，只能反查三个月的调拨记录，一条条补。

第二种是金额对不上。A 记的收入是含税价，B 记的成本是不含税价，两边差额挂在“内部往来差异”科目里，越滚越大。根子在于两边用了不同的取数口径，而系统里没有强制的规则约束。

第三种是期末对账靠 Excel。两家实体各自导出往来明细，人工做匹配，匹配不上的挂“待查”。这个流程在业务量小的时候还能撑，一旦月度交易上千笔，光是匹配就要两个人做一周。

这三个问题的共同点是：它们都不是“录入界面不好用”造成的，而是缺少统一的交易模型、统一的规则约束和统一的对账标识。这就是为什么必须做成引擎。

2.2 设计假设一：单据驱动，而不是分录驱动

引擎化的第一个关键决策，是把业务单据作为唯一入口，而不是让人直接录分录。

这个选择背后的逻辑是：公司间交易的实质是两个主体之间的一次业务往来，它有业务凭证（调拨单、销售订单、服务确认单、工时单），也有账务结果（成对的分录）。如果入口是分录，那么业务凭证和账务结果之间就断了链，后续想追溯“这笔分录对应哪张调拨单”就只能靠备注字段，一旦备注没写清楚就彻底失联。

改成单据驱动之后，链路变成：业务单据 → 交易记录 → 成对分录 → 过账。每一环都带上前一环的标识，追溯变成一次关联查询。更重要的是，单据驱动意味着可以重跑——如果第一次生成的分录有问题，修正单据后重新生成，而不是手工去冲销再补录。

我在配置时习惯给每类业务单据都指定一个明确的批量来源（Batch Source），比如库存调拨走一个来源、服务确认走另一个来源、手工补录走第三个来源。这样后面查问题时，看一眼来源就知道该去哪个业务模块找原始单据。

2.3 设计假设二：规则与数据分离，会计政策改动不动代码

第二个关键决策是规则外置。什么叫规则外置？就是“哪种交易类型对应哪组科目”“哪两个公司段之间的往来用哪个过渡科目”“平衡分录挂到哪个账户”，这些全部做成配置项，而不是写死在程序里。

这个决策的价值在会计政策变化时体现得最明显。比如集团调整了内部交易的计价方式，从成本加成改成市场价，如果规则写死在代码里，就要改程序、走发版、做回归测试，周期以月计；如果规则是配置，改一个规则表、做一次数据验证，当天就能生效。

规则体系一般分三层：

• 第一层是交易类型，决定这笔往来的性质（货物调拨、服务提供、资产转移、费用分摊等）。
• 第二层是账户推导规则，根据交易类型、收发方实体、物料类别等维度，推导出应该记哪个科目。
• 第三层是平衡规则，决定当分录跨公司段时，对方分录挂在哪个过渡科目上。

三层各管一段，职责清晰。实践中出问题最多的，是把第二层和第三层混在一起配，导致同一个科目既承担业务核算又承担过渡职能，期末余额根本没法解释。

2.4 分配能力的定位：它解决的是归属，不是平账

很多人第一次接触分配功能，会误以为它是用来“把账做平”的。这个理解偏差会带来一连串错误配置。

分配的本质是把一笔已经记录在某个归集对象上的金额，按照一定的驱动因子，重新划分到多个承担对象上。典型场景包括：集团共享服务中心的成本分摊到各业务单元、总部研发费用按营收比例分摊、公共仓储费用按出库量分摊。

它有三个要素必须想清楚：

归集对象是钱先记在谁头上。通常是共享中心、总部或者某个虚拟的成本中心。

驱动因子是分摊依据。可以是固定的比例、可以是某个财务指标（营收、人数、资产额）、也可以是业务量（出库量、工单数、工时）。驱动因子的选择直接决定了分摊结果能不能被业务方接受，我见过用“办公室面积”分摊 IT 成本的方案，被业务部门集体反对，最后改成按终端数分摊才通过。

承担对象是钱最终落到谁头上。这里要注意承担对象必须是末级实体或者末级成本中心，否则分摊下去还是归集状态，等于没分。

还有一个容易被忽略的点：分配是可以多级的，也可以循环的。A 分摊给 B，B 再分摊给 C，这种多级分摊在配置时必须明确层级顺序和是否允许循环，否则会出现分摊死循环或者顺序错乱导致金额翻倍。

2.5 与库存、应收应付、总账的咬合关系

公司间交易引擎不是一个孤岛，它至少要和三个模块咬合。

跟库存的咬合点在调拨。库存做实体间调拨时，会产生物料移动，这个移动要能触发公司间交易的生成。这里的关键是调拨类型和交易类型的映射关系要配全，漏配一种调拨类型，就会出现“货动了但账没动”。

跟应收应付的咬合点在内部购销。A 卖货给 B，A 那边要开内部发票形成应收，B 那边要接发票形成应付。这条链路如果走自动开票，需要把公司间交易和自动开票的批量来源打通；如果走手工开票，至少要保证交易记录上有内部客户/供应商的标识，方便后续匹配。

跟总账的咬合点在过账。公司间交易最终要变成日记账分录导入总账，这里涉及接口表、导入程序、过账程序三段。实践中出问题最多的是接口表的数据校验，比如公司段组合无效、期间已关闭、币种不一致，这些错误在导入时才会暴露，如果不做预校验，一批几百笔交易可能全部失败。

3. 实现步骤：从零配一套能跑通的公司间交易

理论讲完，进入实操。这一节按配置顺序展开，每一步都说明为什么这么做，以及容易漏的地方。需要说明的是，具体字段名和路径可能因版本略有差异，但配置逻辑是相通的，遇到不一致时按逻辑去找对应项即可。

3.1 前置数据：实体、业务单元、账簿、账户四条线

配置公司间交易之前，有四类基础数据必须先到位，缺一项后面都会卡住。

法律实体是承担法律责任的主体，公司间交易的双方必须是两个不同的法律实体。这里常见的错误是把“部门”当成实体来配，结果做出来的往来在合并报表层面根本不需要抵销，白忙一场。

业务单元是业务操作的组织维度，一个法律实体下可以有多个业务单元。公司间交易在操作层面是按业务单元走的，在账务层面是按法律实体归集的，这个差别要在配置时想清楚，否则会出现“业务上分了家、账上还是一家”的情况。

账簿决定了分录记到哪套账。跨账簿的公司间交易是复杂度最高的场景，涉及到币种折算和期间对齐。如果集团是多账簿架构，建议先把同账簿内的交易跑通，再逐步扩展到跨账簿。

账户包括公司间应收、公司间应付、公司间收入、公司间成本这几类。账户的设计原则是“可追溯、可抵销”，也就是说合并报表时要能一眼看出哪些是内部往来，所以不建议和外部往来共用科目，必须单独设内部往来科目段。

下面这张表是我在项目里常用的前置数据检查清单：

3.2 交易类型与批量来源：把业务分类做在前面

交易类型是整个规则体系的入口。我通常建议按“业务实质加方向”两个维度来设计，不要按部门或者按项目来分。

按业务实质分，是因为不同实质的会计处理不同：货物调拨涉及存货转移，服务提供涉及收入成本确认，资产转移涉及固定资产清理，费用分摊涉及管理费用的再分配。这四类的科目走向完全不一样，必须分开。

按方向分，是因为同一类业务在不同方向上科目可能不同。A 卖给 B 和 B 卖给 A，虽然都是内部购销，但如果涉及不同的税务处理或者不同的计价方式，规则就是两套。

交易类型配好之后，再配批量来源。批量来源的作用是标识“这批交易是从哪个渠道进来的”。常见的来源包括库存调拨、内部发票、手工录入、定期生成、外部接口导入。来源设计得细一点没坏处，因为它是后面排查问题的第一个抓手——看到一批交易出问题，先看来源，就知道该去哪个模块查原始数据。

这里有个经验：手工录入来源一定要单独设一个，不要和自动来源混用。混用的后果是，出问题时你无法区分“系统自动生成错了”还是“有人手工录错了”，排查方向直接跑偏。

3.3 规则与账户推导：配置的重头戏

账户推导规则的配置，是整个实施里最耗时的部分，也是最需要和财务反复确认的部分。我的做法是先画一张矩阵表，把“交易类型 × 收发方实体组合”列出来，每一格填上应该用的科目，确认无误后再往系统里配。

推导维度一般包括：

• 交易类型（决定业务性质）
• 发出方法律实体（决定从哪个主体的角度记账）
• 接收方法律实体
• 物料类别或者服务类别（决定具体科目细分）
• 方向（发出还是接收）

维度不是越多越好。维度越多，规则条数呈指数增长，维护成本急剧上升。我的经验是核心维度控制在三到四个，剩下的用默认值兜底，并且一定要配一个“兜底规则”，否则遇到没覆盖的组合，系统直接报错，交易生成不了。

平衡规则的配置是另一块。平衡规则解决的是“当分录跨公司段时，对方挂哪儿”。配置时要注意两点：一是平衡规则的作用范围，是按实体对配还是按公司段配，前者精确但条数多，后者通用但不够精细；二是平衡分录的生成时机，是在交易过账时生成还是在总账过账时生成，这两个时机的选择会影响对账的复杂度。

提示：平衡规则配完之后，一定要拿几组边界场景做验证——同币种跨实体、跨币种同实体、跨币种跨实体、以及同一实体内部不同部门之间。第四种最容易出问题，因为很多人以为同一实体内部不需要平衡，实际上如果公司段不同，一样会触发平衡逻辑。

3.4 生成、审批、过账：三段链路的衔接

配置完成后的运行链路分三段，每一段都有明确的职责和检查点。

第一段是生成。业务单据触发或者手工创建交易记录，系统根据交易类型和推导规则算出成对的分录。这一段的关键检查点是分录是否成对、金额是否相等、方向是否正确。我习惯在这一段加一个自动校验：如果收发双方的金额差异超过阈值，直接拦截不允许提交，而不是让它流到后面。

第二段是审批。交易提交后进入审批流，审批人可以是财务主管、可以是实体负责人，取决于金额和性质。审批环节的价值不在于“多一道签字”，而在于给一个纠错窗口。实践中我发现，把审批节点设在过账之前而不是生成之前，能显著降低冲销率，因为审批人看到的是完整的分录，而不是草稿。

第三段是过账。审批通过的交易推送到总账接口，由日记账导入程序过账。这一段最容易出问题，常见错误包括期间已关闭、账户组合无效、币种折算率缺失、借贷不平。建议在过账前做一个预检程序，把接口表里的数据先跑一遍校验，把错误挑出来单独处理，而不是让整批失败。

三段链路之间要有状态字段贯通。交易记录上至少要有“已生成、已提交、已审批、已过账、过账失败”这几个状态，并且过账失败要记录错误信息。没有状态和错误信息的系统，出问题只能靠人肉排查，效率极低。

3.5 分配规则的落地配置

分配规则的配置分四步走：定义归集对象、定义驱动因子、定义承担对象、定义分摊层级。

归集对象的定义要精确到成本中心级别，因为分配是在成本中心之间进行的。这里常见的错误是归集对象设得太粗，比如把整个共享中心设成一个归集对象，结果分摊时无法区分不同服务线的成本，只能整体按一个比例摊，业务方不认。

驱动因子的取值来源要明确。如果是财务指标，要说明取哪个报表、哪个期间、是否含税；如果是业务量，要说明取哪个系统、统计口径是什么。口径不明确是分摊争议的主要来源，我见过因为“营收按含税还是不含税”这一点没写清楚，导致分摊结果差了几个百分点，最后整批重算。

分摊层级要画出来。哪些成本先分、哪些后分、分完之后是否参与下一轮分摊，这些必须在配置前用图或表明确。层级设计不当的典型症状是：某一级分摊完成后，接收方又被作为下一级的归集对象，导致同一笔成本被重复分摊。

4. 实战示例：一笔跨实体物料调拨的全流程

光讲配置还是偏抽象，这一节用一个完整例子把链路走一遍。为了不涉及具体企业信息，场景做简化处理。

4.1 场景设定

某集团有两个法律实体，甲实体负责生产，乙实体负责销售。甲把一批产成品调拨给乙，调拨价按成本加成百分之十确定。两个实体使用同一套账簿、同一币种。

这个场景看起来简单，但已经包含了公司间交易的核心要素：两个实体、一次货物转移、一个内部计价、一对会计分录。

4.2 单据生成与分录结果

库存系统做实体间调拨，调拨单上带发出方、接收方、物料、数量、调拨价。调拨单保存后触发公司间交易生成，系统根据交易类型“货物调拨”和收发方实体组合，推导出两条分录。

甲实体这边：

• 借：公司间应收——乙实体
• 贷：公司间收入（或者存货转出，取决于计价方式）

乙实体这边：

• 借：存货（或者公司间成本）
• 贷：公司间应付——甲实体

两条分录金额相等，方向相反，各自落在自己的公司段上。从单家账看，甲有应收、有收入，乙有存货、有应付，都是平的；从合并角度看，内部收入和内部应收应付在抵销时对冲掉，剩下的就是存货的实际成本。

这套分录生成后进入审批，审批通过推送到总账接口。这里有个细节值得说：如果甲实体和乙实体在同一个账簿内，两条分录可以在同一个日记账批次里过账；如果在不同账簿，就要分别生成两个批次的日记账，并且在期间上要对齐，否则合并时会出现在不同期间的往来，抵销不掉。

4.3 分配示例：总部共享成本的分摊

接着上面的场景，假设集团总部有一个共享服务中心，一年的人力成本记为归集对象。分摊规则是：百分之六十按各实体营收比例分摊，百分之四十按各实体人数比例分摊。

配置时，归集对象设共享服务中心的成本中心，驱动因子有两个，一个是营收（取自财务报表，按不含税口径，取月度累计数），一个是人数（取自人事系统，取月末在册数），两个因子各占百分之六十和百分之四十的权重，承担对象是甲、乙两个实体的对应成本中心。

跑分配的时候，系统先算出两个实体的权重，再乘以归集金额，得到各自应承担的份额。分摊结果生成一张分配日记账，借方是两个实体的管理费用，贷方是共享服务中心的成本中心，把归集金额清零。

这里有个实操细节：分摊结果出来后，一定要回写给业务方确认，不要直接过账。我遇到过因为人数取的是月初数还是月末数没对齐，导致某实体多摊了将近两成，业务方发现后要求全部冲回重算。后来我们加了一道“分摊结果预览”环节，先出报表给业务方看，确认无误再正式过账，返工率降了很多。

4.4 对账差异的排查路径

即便配置得再好，期末对账还是会有差异，关键是有没有一套固定的排查路径。

我的排查顺序是四步：

第一步查期间。先确认两边的交易是不是落在同一个会计期间。跨期是最常见的差异来源，尤其是月末最后几天的交易，一边过了账一边没过。

第二步查币种和汇率。如果是跨币种交易，确认两边用的汇率类型和汇率日期是否一致。折算差额如果没有单独设科目承接，就会体现为往来差异。

第三步查交易状态。确认两边是不是都到了“已过账”状态。有的是生成成功但过账失败，有的是过账成功但凭证被冲销，状态不查清楚后面的分析都是白做。

第四步查科目映射。如果前两步都没问题，那就是科目推导规则不一致，导致一边记的是公司间应收、另一边记的是普通应收，匹配的时候自然对不上。

这四步走下来，绝大多数差异都能定位。真正难查的是那种金额刚好相等、方向也对的差异，这种往往是两笔不同的交易被误匹配了，需要靠交易编号或者单据号做精确匹配，而不是靠金额和日期做模糊匹配。

5. Fusion 映射：老能力在新平台落在哪

如果只是维护现有系统，前面几节够用了。但现在很多集团在做平台切换或者新老并行，必须搞清楚老的这套能力在 Fusion 云套件里对应什么。这里最容易出的问题不是“找不到对应功能”，而是“按老思路去找新功能”，结果把架构理解反了。

5.1 概念映射：AGIS 在 Fusion 里叫公司间交易模块

先把最关键的一点说清楚：Fusion 里没有AGIS这个缩写，也没有GIS这个缩写。这部分能力被整体收进了公司间交易（Intercompany）相关功能里，作为一个完整的模块存在，而不是以缩写的形式分立。

映射关系可以这样理解：

这里要特别提醒一点：分配能力在 Fusion 里归属总账模块，而不是公司间交易模块。如果在公司间交易的配置页面里找分配，会一直找不到。这个归属差异反映的是设计理念的区别——老系统里分配和公司间交易放在一起，是因为两者经常配套使用；新平台把它们按功能域拆开，各自独立配置，通过凭证关联。

5.2 配置路径映射：从菜单到参数

配置层面的对应关系，我整理成一张对照表，实际迁移时按这张表逐项过一遍，能省不少时间：

迁移时最容易被忽略的是“默认值”。老系统里很多参数有隐式默认值，配置时没显式设置也能跑；新平台的默认值逻辑可能不同，导致同样的配置跑出来的结果不一致。我的做法是迁移时把每一个参数的当前值都显式写出来，包括那些看起来是默认的，然后在测试环境里逐个比对结果。

5.3 迁移时最容易丢的三样东西

第一样是例外规则。老系统跑了很多年，里面沉淀了大量“因为某个特殊场景加的一条规则”。这些规则往往没有文档，只存在于系统里。迁移时如果只迁移主干规则，例外场景上线后就会报错。建议迁移前做一次全量规则导出，逐条确认是否还需要。

第二样是历史对账口径。老系统的对账报表是按什么口径生成的、差异是怎么解释的，这些知识往往在具体经办人脑子里。迁移时如果只迁数据不迁口径，新系统上线后第一轮对账就会陷入“数字对不上但说不清哪里不对”的困境。

第三样是过渡科目余额的处置方案。切换时点上，公司间往来科目和平衡过渡科目都会有余额，这些余额在新系统里怎么承接、怎么在新老之间做抵销说明，必须有明确方案。我见过切换后过渡科目余额挂了一年多没人处理的，最后成了审计问题。

注意：迁移评估阶段不要只评估功能覆盖度，一定要评估“例外场景覆盖度”。功能清单对比看起来是百分百覆盖，实际跑起来出问题的往往是那些占比不到百分之五的例外。

6. 常见问题与排查技巧实录

最后一节放一些实操中反复遇到的问题，整理成速查表，再补几个不太会在文档里写、但确实能省时间的经验。

6.1 高频问题速查表

6.2 三个踩过的坑

第一个坑：以为同实体内部不用配平衡。项目初期我们认为只有跨实体才需要平衡规则，结果上线后发现同一实体下不同公司段之间的往来也会触发不平衡报错。原因是平衡判断的依据是公司段而不是法律实体。这一条的教训是：配置平衡规则时，判断维度要按“段”来想，不要按“主体”来想。

第二个坑：批量来源设计得太粗。最早我们只设了“自动”和“手工”两个来源，跑了一个月发现排查问题时完全没法定位。后来拆成库存调拨、内部发票、服务确认、手工补录、接口导入五个来源，同样的问题定位时间从半天缩短到十分钟。来源字段的价值不在业务处理，而在问题定位，设计时按“未来可能出问题的渠道”来拆，而不是按“现在有几个入口”来拆。

第三个坑：分配规则上线前没做结果预览。第一次跑分配直接过账，业务方看到结果后提出异议，要求全部冲回。冲回本身不难，难的是已经过了账的分录要逐笔冲销，还要跟总账的期间关账节奏对齐。后来我们改成“先出预览报表、业务方确认、再正式过账”三步走，虽然多了一个环节，但整体返工成本大幅下降。

6.3 几个能省时间的实操习惯

第一个习惯是给每笔交易打业务标识。不管是通过单据号、批次号还是自定义字段，一定要有一个能追溯到业务源头的标识。这个字段在排查问题时价值极高，因为绝大多数差异分析的起点都是“这笔分录是从哪来的”。

第二个习惯是配置变更留版本记录。账户推导规则和平衡规则是会被反复调整的，每次调整都要记录“改了什么、为什么改、影响哪些实体”。我见过因为规则被改过但没留记录，导致三个月后的差异分析完全无从下手的案例。

第三个习惯是对账报表先做小样本验证。新配的对账逻辑不要直接拿去跑全量数据，先用一个月的数据、两三个实体跑一遍，确认匹配率和差异分类都合理，再扩大到全量。全量跑一次发现问题再回头改，成本比小样本验证高一个量级。

第四个习惯是把分配和公司间交易分开管。虽然两者经常配套使用，但它们的配置变更节奏、影响范围、审批流程都不一样。混在一起管的结果是，改一个分摊比例要连带做公司间交易的回归测试，效率很低。

这套东西我在几个项目里反复用过，最深的体会是：公司间交易这个模块，难点从来不在功能本身，而在于它横跨业务、财务、系统三个视角，任何一个视角缺位，配出来的东西都会在某个环节卡住。真正决定项目成败的，是把“交易、平衡、分配”这三件事的边界划清楚，然后按单据驱动的链路一段一段配、一段一段验。至于 GIS 和 AGIS 的关系，记住一句话就够了——它们是同一套能力的两个阶段，不是两套可以并行选型的产品。