SAP数据迁移--第一章将数据迁移到SAP的业务基础知识

tiantianspace

已于 2024-02-21 14:34:33 修改

阅读量1k

点赞数 24

文章标签：大数据 java 数据库

于 2024-02-21 14:31:24 首次发布

本文链接：https://blog.csdn.net/tiantianspace/article/details/136052672

版权

第一章将数据迁移到SAP的业务基础知识

为了使数据迁移项目能够成功实施，不仅必须去确保数据迁移本身的技术正确性，还必须能够保证迁移后数据的质量。

关于提到的一些名词的简单解释：
源系统（legacy system）：遗留系统，也就是迁移数据的来源系统，后文中我都写成了源系统
目标系统（SAP) ：未来要使用的S4系统，数据迁移到的目标系统。
历史数据(legacy data) : 遗留数据，是在源系统中存在的全部历史数据，可能需要迁移，也可能不需要。
休眠数据（dormant data）：在源系统及目标系统的运营业务中不会使用的数据。
冗余的数据（Redundant legacy data）：同一个数据重复出现，属于休眠数据的一种>。
自定义配置（customizing）：IMG中根据公司蓝图进行的配置。（本人觉得书中提到的customizing是指IMG中进行的配置，而不是自开发程序，因为书中自开发通常使用的是custom program）

1.1 数据迁移作为独立子项目

在大部分的项目中，迁移并没有得到足够得重视.项目经理大部分时间也没意识到，迁移会占用项目资源及预算。当数据迁移的技术只掌握在一部分人范围内的时候，人员配置平静就会产生。因为，经常使用自开发数据传输程序，所以开发人员的缺乏是造成瓶颈的主要原因，因此要减少自开发，这样数据迁移就不仅仅是开发人员的责任，那些没有复杂开发能力的人员也可以引入到迁移项目，减少人员瓶颈。
另一个重要的方面是数据迁移的数据质量。例如未清项，不论是余额还是行项目，在源系统及目标系统都需要保持一致。因为数据迁移作为后续业务流程的基础，还需要迁移看上去不相关但可能是控制数据信息，以确保下游的流程能正常处理。
所以，仅仅确保迁移数据在数量上的完整是不够的，还需要调查迁移后的数据是否可以确保目标系统能够处理后续的运营交易，以及是否具有决策过程所需的信息。在未清项的这个例子中，意味着除了验证金额是否正确之外，还必须确保付款截至日期的计算正确，因为他可能直接影响企业的流动资金计划。缺少或者不正确的信息，可能会导致决策失误。
综上，我们建议数据迁移是一个迭代的过程。这意味着你可以在第一次从源系统抽取数据后就开始测试，并在目标系统中进行开发允许数据迁移（第三正会介绍细节）。基于初始迁移结果，可以在接下来的步骤中检查是否所有的数据都是后续流程运转必须的。这包含全面的系统测试和潜在的自定义配置。如果信息确实了，必须确认从哪获得这些信息，并重复迁移过程直到达成想要的结果。需要注意的是不能孤立的进行数据迁移和业务流程测试，这两个任务是密不可分的。
鉴于数据迁移在项目实施过程中的重要性，建议负责数据迁移的团队尽早处理源系统中的流程，并研究如何在目标系统中映射这些流程，特别如果在目标系统中进行业务系统流程重构。因为没有人比用户更了解源系统，所以他们应该从一开始就参与到项目中，以预防该领域的人员配置瓶颈。通过这种方法，用户部门的工作人员将熟悉目标系统，并能够更好地确定必须提供哪些数据以确保系统顺利迁移。

1.2 初步考虑

在项目开始时，可以根据源系统确定初步考虑因素，而无需详细了解目标系统。包括定义迁移的数据集，识别可能不需要迁移的历史数据，减少迁移数据量可以采取的步骤，数据提取的准备工作，以及有关记账数据的一些特殊注意事项。

1.2.1 确定迁移的数据集

迁移的数据可以分为主数据和交易数据。

主数据
主数据包含了长时间保持不变，且为了相同的目的而需要的信息。当然只有迁移实际使用的主数据才有意义。那些休眠数据（详见1.2.2），即在运营过程中没有使用的数据，应该在源系统中标记为休眠，并且不进行迁移。

交易数据
交易数据的生命周期短，并且可以分配给特殊的主数据。交易数据有时也被称作过账凭证（posting document）。在迁移时，需要澄清源系统的历史数据需要迁移到目标系统的明细程度。具体而言，需要确定迁移的凭证是按照行项目还是余额。如果决定迁移行项目，需要确定迁移的会计年度，哪些已清项也需要迁移行项目；如果决定迁移余额，那么源系统在过渡阶段，需要保证可以查询历史的明细信息。
过去的经验表明，大部分项目采用了行项目和余额相结合的迁移方式，大部分的管理者决定迁移客户和供应商的所有行项目，为了业务流程在目标系统的继续运行。需要注意的是，行项目并不是资产负债表和利润表的不可或缺的组成部分，所以业务需求决定了需要迁移哪些数据

1.2.2 确定休眠数据

要把数据迁移看作一个机会，一个可以检查历史数据并删除冗余数据的机会。投资在这件事情上的时间是值得的，因为它将确保在新系统中数据的一致及有序。另外这个过程也可以显著减少迁移的数据量，从而减少数据传输时间。
所以问题就是如何识别休眠数据，以下是一些识别方法举例：

主数据举例
如果可以分析出哪些主数据很长的会计期间（eg. 2年）内没有激活使用，可以作为这些数据未来是否还使用分析的起点。如果不使用，可以标记这些数据与迁移无关。
还经常会遇到相同的主数据在源系统中存在多个。尽管这个主数据有不同的编号，但是其他的信息相同或基本相同。在这种情况下，进行休眠数据分析有助于识别正在迁移的项目中是否存在这种情况。如果存在，也要标记这些数据，在未来的迁移步骤中进行排除。
当交易数据基于这些冗余的主数据创建的时候，情况就会变得复杂，就必须源系统或辅助系统（如Microsoft Excel）中已经识别出的过账，之后才能删除冗余的数据，否则会导致迁移错误，因为这些交易数据在目标系统中没有相应的主数据。
无论之前提到的问题是否解决，都需要调查目前的主数据是否按照现在的方式继续在目标系统中使用，或者是按照新的方式创建。常见的例子就是科目表（Chart of accout），会随着时间的推移而增加很多独立的科目，在这种情况下，需要思考这些科目是否真的全部都需要，或者合并科目将其减少到易于管理的数量会更方便管理。如果采用后者，则过账凭证就需要进行变更。

交易数据举例
在迁移的过程中可能会发现源系统中包含目标系统无法识别的交易数据。这类情况包含0值过账。为了从开始避免后续迁移步骤的错误，需要在源系统的数据集中进行搜索，并消除这类交易数据。
而且必须考虑这些分配了同一主数据，但是相加余额为0的交易数据。是否有什么理由导致必须为单独地行项目，还是因为忘记了清账。对源系统的分析将会帮助你回答这些问题(个人认为分析只能帮助找到这些数据，而是清账还是保留需要业务来确认)如果保留余额更有利，则在源系统或辅助系统中进行操作，这样可以减少迁移的数据量。（一般都是建议在迁移前尽可能地进行清账）

1.2.3 减少迁移数据量的方法

源系统中历史数据复制到目标系统的详细程度对数据量有重大的影响。即使决定按照行项目迁移，也有以下几种措施可以帮助在迁移之前减少数据量：
如果一个流程可以关闭，则状态应设置为完成，根据不同的应用，行项目可以不进行迁移。如果经济状况及公司政策允许，可以考虑在迁移前支付未付的供应商发票，以利用现金折扣。这不仅会减少迁移数据量（假设已支付的行项目与迁移无关），而且还有助于减少公司费用。
还有一种可能的方案是调整付款模式，以将贷项凭证保持在最低限度。

1.2.4 抽取源系统数据的准备措施

因为业务人员对于目标系统并不了解，所以如果在项目开始的早期阶段，因此在项目早期阶段提供用于测试的历史数据传输的初始数据抽取几乎没有意义。尽管如此，在项目开始阶段，需要确认源系统是否包含了主数据及交易数据需要的所有信息，并导出到一个活多个文件中。这里需要问自己的一个重要的问题是，源系统是否有标准程序支持数据抽取，还是需要进行自开发。如果需要自开发，需要确认项目内部是否有相关顾问，还是需要提前安排。

1.2.5 附录：财务考虑因素

如果需要迁移交易数据，则需要在数据迁移开始前解决会计问题。后续将在第四章专门介绍交易数据迁移，这里主要介绍如何在SAP中迁移交易数据,如未清的贷项行项目（open credit items）。
很显然，发票及贷项通知单会记账到相应供应商的借方及贷方，但相应的抵消过账（offsetting postings）呢？在这种情况下，一个选项就是在目标系统种配置一个用于迁移的总账科目，这个科目用于迁移未清项和数据迁移中接收所有抵销分录（offsetting entries）。因为这个科目比较特殊，一般采用9开头的科目。以下举例说明了这个选项。
供应商1有两张金额分别为100和200的未结发票（I:open invoices)，以及一张金额为50美元的贷项凭证（C:credit memo)。
供应商2有一张金额为150的未付发票。
从会计角度来看，供应商账目如表所示
option 1 迁移科目如图所示：
在这里插入图片描述如图所示，迁移科目的余额是供应商科目余额的总和。这意味着迁移科目（9*）适合用来对比源系统和目标系统的初始数据的余额。如果两个系统种的余额（balance）相同，可以简单地检查供应商的随机抽样，以确认其准确性。
在大部分情况下，迁移科目不是资产负债表科目，这意味着它会归类到未分配科目。如果实在财政年度开始的时候迁移数据，并且仅使用一个迁移科目来处理供应商数据(the vendor data)，未清销售行项目(open sales items)，以及其他资产负债表中科目(the remaining balance sheet accounts)的数据，如果迁移正确的话，这个科目的余额就会是0。在这种情况下，可以将迁移科目视为反映所有要转移的科目的所有过帐（posting）的科目。迁移科目可以与期初资产负债表科目进行比较，该科目反映了期初资产资产负债表的所有期初余额，并且余额为零。与只包含期初余额（每个科目一个余额）的期初资产负债表科目不同，迁移科目还可以解释这些余额的原因，因为它列出了相应的行项目。
前面提到的其他资产负债表科目（transferring the remaining balance sheet accounts）是什么意思。这些财务报表中，列示的所有科目，不反映统驭科目。比如一个总账类的统驭科目，是通过明细账（subledger accounting）记录交易数据的，比如应收和应付。你不能直接过账到统驭科目，而是在明细帐中创建了过账后，统驭科目就会自动接收所有值。所以在客户/供应商等未清项的迁移过程中，这些过账只发生在明细账，总账和明细账是自动集成的，所以统驭科目完全排除在数据迁移过程之外。
而当资产的价值需要迁移时，情况就不同了。在迁移历史数据的传输期间，不能确保总账和资产明细帐的集成。所以，在迁移之后，需要收到过账资产的统驭科目。但是因为不可以直接过账到统驭科目，相应的功能在资产模块自定义设置（customing）中。
迁移利润表科目也需要澄清。如果是在年初进行迁移，决策很明确。因为在上一个会计年度结束时，所有的利润表科目余额都已经结转到留存收益科目，这些科目余额都为0，这意味它们不包含当前年度的任何交易数据，所以可以在数据迁移中排除；但如果是在年中进行迁移，则利润表科目中可能已经发生交易，所以必须进行迁移。在后一种方案中，那些损益科目余额还没有结转到留存收益（资产负债表科目），这意味着资产负债科目不平，当前利润表的收益和损失还要增加。所以迁移科目在资产负债表科目迁移完成之后会有余额，这个余额等于利润或损失的金额。举例如下：
固定资产（FA:fixed assets）余额：1000
流动资产(CA:current assiets) 余额 500
期初股东权益（*** opening balance of stockholders’ equity–SE***) 金额：500
利润表中的利润（PROF：profit）：500–尚未结转到留存收益
应付账款（PAYB：payables）：500
如下图
在这里插入图片描述
前面提过资产负债表对应的迁移科目，是包含统驭科目明细的，但是为了演示简便，这里简化了FA,CA,SE和PAYB的科目，不展示行项目。在迁移资产负债表科目（包括子分类账）之后，
迁移科目如表1.5所示。
在这里插入图片描述
在上面的例子中，在资产负债表科目迁移完成后，还需要迁移收入，在收入迁移到目标系统后，迁移科目看上去如下图1.6
总结如下，一个成功的数据迁移完成后，迁移科目的余额应为0，无论迁移是在年初还是年中执行。
区别在于年初的迁移科目中不包含利润表科目，仅包含明细帐的交易数据和其他资产负债表科目；年中还要包含利润表部分。也就是所迁移科目需要包含所有的交易，作为过账镜像，过账到总账科目或明细账中。
或者，也可以使用多个迁移科目。比如客户、供应商、资产、其他资产负债表科目、损益表科目，这些都可以使用不同的迁移科目，这些迁移科目迁移成功后，合计值金额应为0。对于需要使用多少迁移科目没有一般性的建议。但绝对不建议为了后续容易定位错误建立大量的迁移科目。如果你使用同一个迁移科目，但是用不同的凭证类型（根据实际情况）也可以获得相同的结果。
另外迁移时还需要注意过账码（posting key）
您必须以类似的方式转移客户、供应商未清项和G/L账户过账：
在这里插入图片描述

1.3 项目视角下的数据迁移过程

以下是关于数据迁移的主要任务

1.3.1 基础的自定义配置

首先系统要完成基础的自定义配置，保证所有的业务流程可以执行，才能进行数据迁移。比如如果没有配置付款条件，则迁移未清项目就没有意义，付款运行是一个后续流程，如果没有确切的到期日，则系统无法提供正确的结果。

1.3.2 SAP中的系统演示

相关部门用户了解并熟悉目标系统的流程，然后才能提供需要从源系统中抽取的数据清单。传授这些知识的一种方法是进行系统演示，使内容更容易理解，在这些演示中，需要确保适当的关键用户参与其中，是他们能够提出相关的问题。理想情况下，用户在演示后，可以大概确认哪些数据必须迁移到目标系统中，才能保证后续的业务流程顺利执行。

1.3.3 业务重建（Business Reengineering）

当源系统与目标系统使用不同的逻辑的时候，会出现更难的情况，因为源系统无法直接迁移到目标系统。在这种情况下，必须再迁移之前对数据进行处理，这个过程及其复杂，不应低估。因为目标系统必须的一些信息，可能在源系统中以不同的形式存在，相反，一些源系统的信息，可能目标系统也不需要。
1.3.2中描述的知识在这个框架中尤为重要，因为对于参与的用户部门来说，它是重新构建组织架构和重新设计流程的基础。因为重构的组织和数据结构要符合SAP的要求。因为这个重构过程可能具有复杂的维度，可能需要和业务部门再次讨论在目标系统中可以继承源系统的数据结构程度。

1.3.4 模拟数据迁移

当业务用户都了解了目标系统的逻辑之后，你可以将精力主要放在与数据迁移本身相关的活动中：

识别计划迁移的业务
在目标系统中运行这些业务，并使用来自源系统的测试数据，并注意哪些字段是必须的。这些必须字段中可能在源系统中没有对应的数据字段。

原文的两点是：

Identifying the enterprise resource planning transactions that you want to use to migrate the legacy data to SAP。
Running these identified transactions manually in SAP with test data from the legacy system, and note which fields are required. There may be required entry fields that have no corresponding data fields in the legacy system.
不太理解第一点提到的the enterprise resource planning transactions,因为如果是resource的计划，和后面提到的有点衔接不上，所以我理解成了需要迁移的业务。

确定了sap业务（the SAP transactions）和需要维护的字段后，可以开始映射阶段。

1.3.5 映射（字段匹配）

只有少数情况下源系统与目标系统的字段名称一致。如果命名规则不同，需要线下记录对应关系，也称作映射（mapping）。
在简单的情况下，两个系统的字段名称一致，或者名称不一致，但是内容相同：
Field name (legacy system) = Field name (SAP)
但如果源系统的设计与目标系统完全不同，则需要提前进行转换，才能适用SAP的原则：
Field name(s) (legacy system) -->Transformation --> Field name(s) (SAP)
举例：
假设源系统的借贷用"I","C"标识，SAP采用的过账码，则需要进行转化才能将交易数据迁移到SAP系统，如下图
在这里插入图片描述如果目标系统的必输字段在源系统中不存在，则需要对源系统的数据结构进行更改，线下补充相应信息；或者在目标系统的配置中，将这个字段改为可选字段。
在这一阶段结束时，数据迁移所需的每个SAP字段都必须通过直接分配或通过转换从源系统中分配一个相应的字段。

1.3.6 源系统的数据抽取

当从源系统抽取数据时，需要确保这些数据是在一个或多个文本文件中提供（可编辑的文档格式）。这很重要，有助于手动改对数据进行后处理（参见1.3.7）。还可以使用SAP DATA Services抽取数据。（详见第八章）

1.3.7 抽取数据的手工后处理

在大多数情况下，由于系统环境的变化或业务重构，必须对数据记录进行调整或转换，以便在SAP系统中进行处理。
因此手工后处理的目标是创建一个文件，目标系统可以在不进行任何转换和调整的情况下进行处理。进行后处理的文件来自匹配阶段产出的结果，消除不再使用的数据也是这一阶段执行（见1.2.2）。
使用表格（excel）有助于实现这一目标，如果前提是避免自开发，则必须确保这个流程正确处理。因为这边书的目标之一是不适用自开发的情况下完成数据迁移，所以第十章，描述了几种可以提前格式化数据集的方法，以避免在随后的迁移阶段进行开发。

1.3.8 选择数据迁移技术

在选择迁移技术时，必须权衡数据安全需求与将数据迁移速度。速度是以牺牲数据安全为代价的；同时实现这两个目标几乎是不可能的。
在您了解了数据迁移的各个方法后，我们将在第11章中评估各种技术，并描述哪些程序最适合某些情况。

1.3.9 上传数据到目标系统

这个阶段主要是技术流程，与选择的迁移技术相关。第4-7章会介绍SAP需要的准备步骤。
上传的步骤主要基于1.3.7阶段完成的数据库，如果上传的程序被中止了，需要对原始数据进行深入分析和调整，之后重复上传操作。在这个过程中要注意数据的备份，临时的更改要特别注意，删除和调整都可以记录不同版本，做好备注，避免影响最终迁移到目标系统的数据。
上传数据要考虑不同数据间的依赖关系，要根据相关顺序进行上传，比如：

主数据要在交易数据之前
总账要在明细账之前。（eg.统御科目在供应商之前）
采购订单要在收货过账之前
物料主数据要在物料清单（BOMs：bills of material）之前

1.3.10 SAP中测试业务流程

在数据迁移到SAP系统后，需要确保数据完整行，如果涉及交易数据，可以比较上传文件中的数据总数和目标系统中的结果。如果没有差异，可以随机抽取数据进行评估，已确保目标系统的字段，都按照映射规则全部更新到了目标系统；如果存在差异，需要进行针对性分析，确认问题产生是导入的数据库问题，还是迁移程序的错误，并进行更正。
然而检查数据量的完整并不足够，还必须确认迁移后的数据信息能够支撑后续所有的业务流程，因为迁移的数据作为测试业务流程的基础，不可以单独的考虑，而需要与后续测试相结合。如果这个数据基础缺少后续流程的必要的信息，则需要增加迁移的字段，从重新创建相应的匹配关系。也就是重复1.3.5–1.3.7步骤，直到后续流程能执行出预期的结果，如下图：
在这里插入图片描述