当企业集团统一建设的财务系统暂未覆盖全集团，在一套集团统建系统和多套企业异构系统并存的情况下，如果集团总部需要集中全集团财务数据用于合并报表、财务分析时，本文是一种解决方案。
本方案的核心要点是：把企业异构系统中的原始数据同步至集团总部统建数据平台，由三方协同(本方案的关键)，充分利用数据平台强大的数据管理和处理能力，实现异构数据的集团标准化，然后与集团统建系统中原本标准的数据整合在一起，形成全集团完整的财务数据，进而用于合并报表、全集团财务数据分析等场景。
关于数据平台，当前可以完成数据管理和处理的软件系统很多，包括各类数据中台(现在中台的“中”越来越模糊了)、数据治理平台、数据资源管理平台，以及此前多年的ETL工具、数据仓库、……，为简单起见，本文统称为数据平台。
本方案的关键内容如下：
1. 基于集团统建财务系统(核算、合并报表等系统)的情况，集团总部协同统建系统财务顾问，制定集团统一财务数据标准(以下简称“集团标准”)，包括记账凭证、各类明细账和余额表、相关档案数据(主数据)等标准。并且标准要被应用场景验证通过后才能正式发布，例如希望集中异构ERP系统的财务数据实现全集团的合并报表，那么满足该标准的数据要能够被合并报表系统正常使用，能够完成合并才行。
2. 在集团数据平台的数据库中创建集团标准的数据库表，即目标数据库表，异构系统数据被处理后存储至目标表中被合并报表等系统使用。并且建立数据同步机制，从集团统建主数据管理系统、财务系统等系统中把集团标准涉及的档案数据同步至数据平台的数据库中，用于企业财务系统的异构数据与集团标准建立映射关系。
3. 企业系统的财务顾问和技术人员，按照集团标准，把所需的数据从企业财务系统的数据库中原样同步至集团数据平台的数据库中，并存储于贴源层。需关注记账凭证等财务数据同步的特点，即数据量大，在合并报表等需求下，数据同步时效性不高。可按会计期间同步，例如每月关账后同步数据，并且为减少数据同步对生产系统的影响，一是可以考虑在夜间等非繁忙时段执行同步，二是可以考虑备库的方式，以适当的数据范围把数据先从生产库同步至备库中，后续再从备库中把数据同步至集团数据平台的数据库中，这样也避免了其他应用系统直接访问生产数据库可能造成的各种问题。
对无法修改或删除已过账凭证的财务系统，只需要考虑增量同步;对能够删除和修改已过账凭证的财务系统，则需要建立更复杂的同步机制，保证企业端的变化可以准确同步到集团端。数据库之间的数据同步有较多的技术方案可选择，包括数据库管理系统(DBMS)本身提供一些功能也可以考虑。
关于数据平台的贴源层稍作展开，企业端异构财务系统的原始数据先被存储于数据平台的贴源层，原始数据的数据库表名、字段名、数据值完全保持原样，相当于直接把数据原样复制到了集团数据平台的数据库中。这种方式优点有很多，第一个是在数据平台中不对原始数据做任何直接的修改，是通过多层逐级加工成为所需的结果数据，上层被加工的结果不正确，只需要调整映射关系或者逻辑处理代码后重新计算即可，对原始数据是无损的，数据在集团数据平台上，集团总部可完全自主可控。如果不是这种方式，例如企业端按逻辑把数据处理为半成品后传给集团数据平台，一旦某些数据结果不正确，可能还需要企业端调整处理逻辑后再传给集团数据平台，不如企业端不做任何处理，完全由数据平台处理更有自主性。
第二个优点是，因为被同步到集团数据平台上的企业数据是最小颗粒度的原始数据，就可以为各种应用场景服务，如果企业端预先按集团某种需求加工后传给集团数据平台，后续在集团其他应用场景下，还需要企业按新的业务需求增加处理逻辑或者彻底重新提供数据。
4. 如上提及过的，企业原始数据到达集团数据平台后将分多层完成数据的清洗、翻译和逻辑处理，而逻辑处理如我此前一篇文章《异构系统间的逻辑处理是集团财务凭证集中的关键之一》所述，是重点，同时也是最复杂的部分。
(1)清洗。略。
(2)翻译。需要建立和维护一系列映射表，把企业财务数据的相关档案翻译为集团标准，其中，需要做异构系统处理的都是没有使用集团统建系统的企业，以客商主数据为例，这些企业使用的一些客商主数据在集团主数据系统中已有(集团内使用统建财务系统的子企业也与这部分客商有业务)，但也有一部分客商主数据只有这些企业使用，企业需要把这部分集团没有的客商主数据创建到集团数据平台上或者集团主数据管理系统中(主数据管理系统会同步给数据平台)，这是对全量客商主数据做处理的情况，工作量很大。
在合并报表的需求下，如果暂无对财务数据全量客商做集团标准化的需求时也可以轻量化处理，即为满足内部交易抵消的处理要求，只需要对财务记账凭证数据中客商档案属于集团子企业的做处理，可大大减少客商主数据的处理工作量。具体的，例如集团在并表口径下有所属企业1000家，那么只需要对这1000家子企业做映射翻译处理(即内部客商范围)，对外部客商的数据可不处理。
(3)逻辑处理。举例说明异构系统的差异和处理的复杂度，假设企业使用的是SAP ERP系统(ECC、S4)，而集团标准是以国产财务系统制定的，以差旅费科目为例，在国产财务软件中会在销售费用科目6601下设置差旅费子科目660103，也会在管理费用科目6602下设置差旅费子科目660205，国产财务软件通过会计科目即可识别是销售费用还是管理费用。但SAP ERP系统中会计科目编码是平级的，科目编码长度都一样，并且只会设置一个差旅费科目6603080000，那么SAP怎么区分是销售费用还是管理费用呢?SAP有“功能范围”，用“会计科目+功能范围”实现费用性质的区分，例如可以定义功能范围：0100制造费用、0200销售费用、0300管理费用、0400研发费用、……，那么在SAP的记账凭证中，“会计科目6603080000+功能范围0300”代表管理费用下的差旅费。
以上就是一种两类财务软件的典型差异，包括我在《异构系统间的逻辑处理是集团财务凭证集中的关键之一》一文中提到的SAP通过“反记账标志”实现国产财务软件的红冲，SAP通过几十个记账码代表借贷方等差异，以及因为SAP记账凭证的币种在抬头区，而用友NCC等国产ERP系统记账凭证的币种在分录区，使得同一个业务对两类系统在凭证数量上就不一样，等等，所有这些差异都需要做逻辑处理才能对齐到集团标准。而因为系统差异和各家企业业务的差异，很多内容还需要有更为复杂的一系列逻辑处理。
这些逻辑处理，需要三方协同才能完成，这也是本文所述方案最关键的部分。第一方是集团统建系统的财务顾问，第二方是企业系统的财务顾问，这两方顾问需要共同梳理企业异构系统向集团标准的转换逻辑，两方都是资深的ERP财务顾问，集团方对集团的系统和标准熟悉，企业方对企业的系统和业务熟悉，双方基于通用的财务语言沟通，制定出企业系统向集团标准对齐的各种处理逻辑。然后，把一系列逻辑告诉第三方，即数据平台的数据技术人员，由数据技术人员充分利用数据平台强大的数据管理和处理能力，通过映射、逻辑转换等处理方式，编写代码，分多层逐步处理，最终得到符合集团标准的结果。
这种三方组合之所以是本方案的关键，主要是术业有专攻，全面掌握三方技能往往是很难实现的。例如同时精通两种ERP系统是很困难的(用友和SAP、金蝶和SAP、浪潮和SAP、金蝶和用友、……)，况且还要了解用户企业的业务情况，而让一位资深的ERP财务顾问再同时精通一种数据平台，或者精通数据技术也是很难的，人的精力毕竟有限，必须专才能成为专家，而跨领域的专家更少;而数据技术人员，同时熟悉ERP或者相关业务的也很少，即便在一个项目上了解了一种异构ERP的情况，但对其他子企业的另外一种ERP就又是陌生的。
就如同三足鼎，缺少其中任何一足，鼎都无法立起来。完成这类异构数据的处理，就需要三方的协作，缺一不可。
更具体的人员配置和分工，可详见本公众号《企业集团财务数据集中项目的人员配置方案探讨》一文。
5. 异常处理。上述工作的完成只是数据集中和应用的开始……，运转起来后，一则上述数据同步和映射翻译是日常工作，同时，必然会出现大量异常情况。例如数据同步异常，本来上个月有20万个记账凭证及相关数据，但同步后因为网络或其他原因导致数据平台只收到19万个，或者一部分主数据没有正常同步，数据平台做映射翻译时也会报错;再例如，上个月企业有了一种新的业务，有了新的核算方式，但新的逻辑没有及时在集团数据平台上体现，那么相关逻辑处理就会出错。这类问题很难完全避免，每个月都会出现，出现后就需要三方人员排查和处理，这种常态化的工作量是必须要考虑的，通常需要一组专门的运维人员。
此外，如果企业集团内有多家子企业使用多套异构系统，每套异构系统都需要以上的一系列工作，例如虽然都是使用SAP ERP的两家企业，一家如果是ECC，另外一家如果是S4，加上两家企业的业务差异，基本就需要为两家企业开发各自专用的一套逻辑，往往很难直接复用。即便是使用同一软件厂商同一版本系统的两家企业，因为企业的业务不同，使得为第一家企业做的处理逻辑很可能也不能直接被第二家使用(例如：第二家企业有自己另外的个性化辅助核算属性，有自己特有的业务形式，等)。
文末，再着重提一下，这类异构数据的集中和使用，非常非常复杂，所以需要三方协同。
