S4D440-Custom Code Adaption for SAP S/4HANA-笔记

SAP ERP基本是十年左右一代产品，最早的R2到上世纪90年代的R3，再到2004年的ERP，2015年的S4 HANA，前后经历了4代产品，这也是S"4"的来历，2025年 SAP对第三代ERP不再提供技术支持，掐指一算界时S4也将处于生命周期的尾期了，如此算来目前的S4正处于青年时期，日渐强壮，做为一名传统SAP的开发人员，如不能及时完成从ERP到S4开发的过渡，势必步履维艰。
So，学起吧，ABAPer们，这是我看S4D440时的笔记，主要介绍从ERP升级到S4HANA后，自开发代码的调整，全文介绍了如何深入去了解系统升级过程及升级后如何对自开发的代码进行相应的调整。是一本不错的guide book，在Learninghub中可以找到，需要一起学习的同学们也可以私信我索取。

Unit 1 Explaining the Basics of SAP S4HANA

分清两个概念先，否则后面的内容肯定晕菜，SAP HANA和S/4 HANA。这是两个完全不同的概念：
SAP HANA，是SAP的HANA数据库；
S/4 HANA，则是使用SAP HANA数据库的最新一代ERP软件；
如果还不理解就把它当成ECC的升级版。传统的ERP也可以使用HANA数据库。或者这么说：说到SAP HANA就要想到这是一个数据库，说到S/4 HANA就要想到这是一个使用SAP HANA数据库的最新一代ERP。

Unit 2 The need for Custom Code Adaption to SAP S4HANA

2.1 了解SAP HANA 自开发代码的影响

首先从了解SAP HANA的特性开始，SAP HANA和其它数据库之间有很大的差异，当使用HANA数据库时，有三个特性对我们定义数据库表和编写ABAP程序有重要的影响：

1. 列存储。SAP HANA数据库中创建表时列存储做为默认存储方式。
2. 压缩。SAP HANA使用了多种不同的压缩方法来尽可能的减少内存的消耗以及需要加载到CPU cache的数据量。
3. 并行处理。并行处理可以大幅度降低处理时间，甚至同一列的数据也可以并行拆分并并行处理，这也造成了，之前我们常用的隐式排序的取数方式在HANA中取出的结果有可能是杂乱无章的。

SAP软件的相应变化
为了支持SAP HANA数据库，SAP软件必须也做一些调整，这些更改出现在使用SAP HANA作为数据库的SAP产品中。调整主要包括：

1. De-pooling and De-clustering，去pool表和cluster表，因为这两类表不适用列存储和压缩这两个特性。所以绝大多数的pool表和cluster表在S/4 HANA中都以透明表出现。
2. Deactivation of Secondary indexes ，其它数据库中存在的二级索引在SAP HANA数据库中不再需要，主要是为了避免不必要的内存消耗。

Custom Code的影响
结合特性，很容易理解使用SAP HANA数据库会对自开发code有以下几类影响：

1. Native SQL需要调整，Native SQL就是针对数据库直接操作的SQL，不同的数据库使用的SQL不尽相同，所以可能需要调整。
2. DB hint需要调整，同上。
3. 需要删除对Pool表和Cluster表的直接访问，因为很多Pool表和Cluster表已经被移除。下面两图可以清晰的理解Pool表和Cluster表，（HANA并不是不支持Cluster或Pool表，即使升到HANA，系统中还是有一些不能转化的Pool表和Cluster表。）
4. 依赖二级索引的代码需要调整，同上，二级索引被删除了，代码肯定需要被调整。结合下面两个图，更好的理解二级索引：
5. 隐式排序相关的代码需要调整，Select from table根据字段顺序会有一个默认的索引，如果使用了这个索引的结果，比如read table …binary search结果就会受到影响，需要调整。如果使用了显式的order by进行排序，是不受影响的。

2.2 了解Code Adaption需求

这章了解一下Simplification简化，为什么要做简化，以及这些简单对已有的custom code意味着什么。

简单理解，简化就是SAP ERP到SAP S4HANA后的一些变化，S4HANA为了适应 SAP HANA数据库对自己软件做了很多简化，做了一次大的整理，移除了很多原来为了优化处理效率建的一些对象，说好听点突破了很多传统ERP使用过程中的限制。
升级后，原有的custom code有一部分执行效率会明显提高，一部分代码就必须要做调整。这就是对Custom code的影响。

Simplification
上图可以直观的看出，升到S4HANA后，Custom code中引用或是访问的对象已经被废弃了，这些就被称为被简化的库对象，不涉及这些对象的程序可以不受影响直接完成升级

所有的简化项都被整理成了note，上面列举了最常见也是最重要的Top10 Simplification，其中一些相对独立，一些总结了整个应用领域的大规模重新设计。

Discontinued Functionality
在S4HANA中，会把原ERP中的一些功能完全废弃掉。例如MB11进行库存转移这个功能就被废弃而整合到了MIGO（MB11还在，不推荐使用，SAP的开发人员在这些程序的开头加入了"A"类型的MESSAGE，在使用这些已经被废弃的TCODE时会弹出A类型消息，所以用到这些TCODE的custom code也需要被调整），或是S4HANA只使用新总账，Classical GL不再支持。还有一些在ERP中存在很久的对象被移除，比如 GLT0_AEDAT。

S4 HANA中有一个黑名单监视工具，使用这个工具，就可以在不修改ABAP程序的情况下动态的禁止库对象的使用。对象的类型可以是：TCODE，函数，报表，类方法，Form。当程序执行这些对象时会触发SYSTEM_ABAP_ACCESS_DENIED异常。

调整字段长度
字段长度被调整是因为有些确实太短了，还有一些是为了与行业方案保持一致，最典型的就是物料号由18位扩到了40位。扩展字段意味着系统中的代码必须保证所有相关的代码都能处理新的字符长度。确保不会被截断而导致出现数据问题。所有相关的对象，比如Domain, Data element, Structure, Table type, Table, Extenal and Internal Interface等等都要做相应调整。

如上图的例子，如果物料号用的不是参考对象，而是指定了长度18，就会导致物料号被截断。

数据模型Redesign
Data Model Redesign出于以下原因：为了最大限度的发挥SAP HANA DB；去掉多余的索引表、聚合表和历史表；合并一些Data Model。

例如：
财务的聚合表和索引表（表BSIS,BSAS,BSIK,GLT0）
FI CO的Universal Journal（表ACDOCA）
记录销售凭证的无状态表（表VBUK,VBUP）

SAP S4HANA Simplification一个很重要的部分就是Data model的Redesign，在过去的SAP ERP中，为了提高运行效率创建了很多聚合表，索引表，以及历史表，到了HANA数据库这些表将不再需要，删除这些表很大的简化了数据模型，从而降低了数据库的内存消耗。主要变化在财务、库存管理、物料账和分销等业务模块。
所以相应的Custom code就需要做调整。

Data Model的Redesin并不只是表的删除，在一些领域会更深，比如Sales Documents的状态，原来在ERP中，Sales Documents的状态并没在在Document表中，而是保存在了 VBUK和VBUP表，到了S4HANA，Sales Documents的状态就直接存在了Documents表中，也就是销售订单的状态在VBAK和VBAP中，Delivery的状态在LIKP和LIPS表中，Billing的状态保存在VBRK表中（billing 没有item级别的状态，所以不涉及VBRP），所以结果就是使用到VBUK和VBUP的costom程序都需要做相应的调整 。

冗余的数据库表

总的来说，有上面这几类冗余表，对应了不同的影响和处理方式。依次来看：

* 类别1：表被删除了，并且没有替代表

这类表直接被删除了，这种情况下，就算是类型的参考也会被报Syntax Error。

• 类别2：表被删除了，改为同名的View存在
  
  这种类型是很常见的一类，表被删除了，为了减少影响就用CDS创建了一个同名的View，如最常见的BSIS表，新创建的View BSIS和原透明表BSIS有相同的字段，读取操作可了返回相同的结果。所以这类表涉及的程序并不需要做调整（甚至使用BSIS的native SQL也一样可用），但是，如果有对这些表的写操作时就需要做调整了，因为View是不支持写操作的。还有一种情况就是有读取这类表的数据库视图也需要调整，因为数据库视图并不支持View-on-View。最后要说的是，如果原系统中对BSIS表做了字段增强，那么在S4HANA也要对相应的CDS View做View Extension，并且要做相应的访问权限处理。

• 类别3：表存在，但被指定了Proxy Object（从1709版本开始，改名为Replacement Object,替代对象
  ）
  
  另一类常见的表变化就是上图这种所谓的代理对象Proxy Object，在S4HANA中，表MSEG不再用了，虽然透明表MSEG还在，但它是一张空表。表MSEG被关联到了一个CDS View NSDM_E_MSEG。由于表还存在，所以使用MSEG的程序不会Syntax Error。
  
  上图可以看出代码中取MSEG的Open SQL在转到Native SQL实际取的是CDS View NSDM_V_MSEG，所以只要不是写MSEG而只是读MSEG的代码都不需要调整。（注意NSDM_E_MSEG和NSDM_V_MSEG是不同的，前者CDS View的名字，是用来定义Proxy Object的，后者是相应SQL View的名字，它才是数据库中实际的物理的CDS View）
  
  
  再看CDS View的定义，上图可以清楚的看到CDS View Name，SQLView Name和实际存储表三者关系。
  
  这张图是SE11查看DDL SQL View ‘NSDM_V_MSEG’，它的字段就是MSEG的字段，也是MATDOC的字段。
  同样，视图是不可以写操作的，所以这里也不能对MSEG进行写操作，上图可以看出实际的MSEG数据其实是在表MATDOC中，做一个实验：
  假设一共有10条物料凭证数据，那么，
  SE11查看MSEG表，可以看到10条，计数10；
  SE11查看MATDOC表，也可以看到10条，计数10；
  DBACOCKPIT使用SQL select count( * ) FROM MSGE，结果0条；
  DBACOCKPIT使用SQL select count( * ) FROM MATDOC，结果10条；
  所以通过以上操作可以证明：HANA数据库中MSEG表并没有保存任何数据，它的Proxy Object是CDS View ‘NSDM_E_MSEG’，我们通过SE11或是SE16N查看MSEG时，它真正指向的是MATDOC表。

• 类别4：表存在，并且没有Proxy Object
  
  最后一类是也是最难的一类，系统中还存在这些redundant表，但并没有替代对象，比如VBUK和VBUP(销售凭证的状态表)，或是条件表KONV，这一类表可以继续做为data type参考使用，但不论是直接访问还是通过视图访问，任何的read或是write操作都是需要调整的。

以上就是升级到S4HANA后的四类冗余表，针对不同的表有不同的处理方式，接下来就是如何找到这些表，通过什么样的工具可以快速定位需要调整的对象。

2.3 Simplification List

先了解几个概念的关系：
Simplification List–> Simplification items–>Simplification piece lists–>Piece list Items

每当SAP对软件进行不兼容的更改时，都会把这些更改做为简化项Simplification Item记录在描述业务影响的相应SAP note中。这些simplification items就组合成了一个Simplification List。一个Piece List就是受这个simplification影响到的库对象的列表，就是Piece list items，比如哪些对象修改的，删除或是废弃的，新增的。Piece Lists也是被整理成了SAP Note，一个Simplification item可能包含了多个Piece list。

有几种方式可以查看Simplification Item:

• SAP官网http://help.sap.com/s4hana下载Simplification List PDF文件，优点是可以方便离线查看，一个文件包含的完整的信息，缺点是只能简单的文本搜索（如果你想反查影响某一个库对象的所有simplification item是搞不定的），并且不包含具体的Piece List。注意它是release dependent，官网上这里挂的永远是S4HANA最新版本的Simplification，有可能你还在升1809时，这里已经到了1909。
  
  打开是这个样子
  
  
  每一项Simplification Item都包含上面几块信息，如果要看具体Piece List，需要点进其中的note中进行查看

• Simplification Item Catalog,这个也可以在上面的官网地址中找到（红框上面一个就是）它打开以后是这样的这是一个在线数据库，里面包含了上一种方式中没有Piece List，相关的item也可以直接跳转到对应的note去，优点是不需要下载，并且永远是最新的，缺点是不可以按库对象去检索，另外需要有SAP的S-user才可以查阅。

• Simplification Database 这是一个7.51版本以上的一个TCODE（ SYCM），长这个样子：这个方式也包含Piece List，也有Link到note，还有Link到库对象，使用前需要先到SAP Support Portal下载数据库的ZIP文件，然后用这个程序导入，菜单Simplification Database–>Import from ZIP file。导入后就可以使用这个程序检索查看Simplification Database中的内容；它的优点是可以根据库对象搜索，还可以按Application Component检索，它可以集成在ABAP Code Check里，缺点是需要手工更新数据库。这种方式推荐开发人员使用（但通常开发人员没有权限下载上传这个数据库，需要BASIS同事协助），使用此工具，开发人员可以很方便分析简化后的SAP库对象。点击选择屏幕的Overview按钮（或是Ctrl+F8），可以查看整个Simplification List items，如上图所示，点击不同的字段可跳转不同的功能。

Unit3 系统转换过程

3.1 Conversion过程

这是从ERP到S4HANA的三条不同的路径：
1. System Conversion
2. New Implementation
3. Landscape transformation
简单讲，第1种就是我们说的升级，把原来的ERP升级到S4HANA；第2种是新实施，准备一个崭新的空白的S4HANA，不管是on-premise还是Cloud，然后根据需要进行各模块实施；第3种是整个landscape的角度考虑，把多个系统整个到一个新的S4HANA中，也是一种新实施。这里我们只讨论第1种。

Conversion的好处是什么呢？为什么选择这种方案而不选全新实施呢？主要就是上图中的黑体字 Keep your investment in custom code，说白了就是之前花了那么多钱做了那么多的自开发不能都扔了重新做啊。
这个图就是从SAP ERP到S4HANA升级的roadmap，感兴趣的同学可以看那本ADM328或是SUM guide或是Conversion Guide，都有很详细的说明，这里不展开详述。

这里只针对涉及自开发的部分，分别在准备阶段和实现阶段，在准备阶段要对Custom code使用代码检查工具做S4 HANA Check，这次的检查不只是识别出受S4 HANA Simplification影响的代码，还要识别有可能影响功能的部分，比如最开始说的隐式排序，这类问题可能会严重影响到功能结果。
在准备阶段，除了S4 HANA Check，SAP推荐用户在前几个月甚至更长时间前开启程序调用分析，使用UPL或是SCMON分析客户使用到的业务功能或程序，简单说就是这一年内你要用不着的功能还有程序也没必要管它们了，缩小需要处理的custom code的范围。
其实，在准备阶段就可以把不依赖S4HANA的adoption，比如那些隐式的SORT问题和HARD CODE字段长度问题处理掉。依赖S4HANA的比如需要换表那种就需要等系统转换到S4HANA之后再做调整。Modification(对标准对象的修改)的调整需要使用SPDD和SPAU进行调整。最后的一个步骤是数据库关键Query的性能优化。

Unit4 Custom code分析工具

4.1 Identify Unused Custom code

SAP Netweaver AS ABAP7.4 SP14就可以使用SCMON来监控ABAP Code的执行，低一点的版本（7.00或更低时）可以用ST-PI组件中的/SDF/SCMON，注意SCMON要在生产系统打开，原因无需多说。注意，如果系统中既可以执行SCMON又可以执行/SDF/SCMON，切记不要两者同时运行。
原来在Solution Manager里还有一个工具叫UPL(Usage Procedure Logging)，但它只能收集ABAP对象的使用情况，SCMON还可以看出这些对象属于哪个Business Process，结果可以看到哪些哪些业务流程调用了哪些对象，调用了多少次。
有几点需要注意：首先SCMON一定要在生产系统执行，监视的时间越长，数据越可信。监视期间，系统每天凌晨2:30的时候会起一个后台JOB来聚合的数据。聚合的数据可以通过CDS View 'SUSG_I_*'来进行查看。
生产系统收集的数据怎么传到其它系统呢？两种方式可选 ，一个是创建快照‘snapshot’，另一种是下载到文件，然后上传目标系统，或者是RFC连接。
这些聚合的Usage数据可以帮助我们确定哪些代码是没有在使用的，从而最小化adoption的effort。

4.2 静态代码检查

3个工具可以做代码的静态检查（就是只分析代码，不考虑它的执行情况）：

1. Extended check(TCODE: SLIN)
2. Code Inspector(TCODE: SCI)
3. ABAP Test Cockpit(TCODE: ATC)
   
   这3个应该是我们开发人员很熟悉的工具，平常的开发完成后都会使用这些工具来检查开发的代码。SLIN太弱现在几乎已经不用了，ATC是Netweaver AS ABAP 7.40后才有的工具，之前是都是SCI，它俩可以理解是一回事，ATC是SC升级版的SCI，相对来说它多了几个功能，比如Schedule Regular Runs，分发结果到对应的负责人，加入examption，远程执行（7.51以后）等，另外它还集成在了ADT中。他们都是对指定的对象集执行指定的check variant。
   一个Check Variant通常包括了一个或多个single check, Variant就是要把需要选择某些single check的集合，逐个去执行检查Object Set中对象，结果分为Error，Warning, Information三类，Single Check通常分为4类：性能类、安全类、语法类、通用类。
   上图是ATC的运行界面，schedule定时执行也非常简单。

4.3 Remote ATC

首先前提是做一套check system，有两个（三个）选择：

• On-premise – empty SAP S/4HANA system：就是空的S4HANA OP系统，参考blog1，参考blog2，参考blog3
• On-premise – SAP S/4HANA fully activated appliance:准备一套full activated applicance的S4HANA OP系统，参考NOTE2041140
• Cloud – SAP Cloud ABAP Platform，使用云ABAP环境，参考blog

最后说一下Remote ATC，这个操作是升级过程中非常重要和关键的一个步骤。

在远端系统中，也就是被检查的系统中装一个Remote Stubs远程存根。ATC Check variant只在中央系统中进行维护，在ATC执行过程中，中央检查系统使用RFC连接通过所谓的远程存根远程访问架构中的其它系统，远程存根作为ATC中央检查系统和被检查系统之间的接口，并从需要检查的自定义代码中返回一个模型。
SAP NW AS 7.51以后的版本都可以使用Remote ATC， 用一台装有SAP NetWeaver AS ABAP 7.51 or 7.52 (SAP_BASIS only) 以上的系统做的中央检查系统（one ATC central check system: pure SAP Basis System (SAP_BASIS >=7.51) ），远程为架构中的其它系统做远程ATC检查，可以想像这样做的优点很多。
需要注意的是：
如果要为自定义命名空间（如 Z*,Y*）的对象做远程ATC，就需要在 中央检查系统 中注册被检查系统中的命名空间。
SE38或SA38执行程序 SATC_AC_INIT_NAMESPACE_REG，这个程序显示系统中的所有命名空间，这些命名空间具有角色生成器(Role Producer)，这意味着可以对命名空间中的对象进行开发，但不属于SAP。
注意，这里没有显示标准的Y和Z名称空间。这些命名空间中的对象总是可以由ATC进行质量检查，并且不需要向ATC注册。（权限： SAP_SATC_ADMIN）
这时需要挂载一个TR，所以一般先在DEV环境做这个检查，然后传输到QAS 和PRD

如果这里是空的，可以先看一下这个note
https://launchpad.support.sap.com/#/notes/0002439348

下面以实际操作说明一下详细过程：

1. Setup System Role
   TCODE: ATC保存
2. Define RFC destinations for checked systems
   TCODE:SM59
   
3. Maintain Object Providers
   ATC框架使用到远程检查系统的RFC连接从定制代码中提取模型进行分析。Object Provider定义这些RFC连接，因此必须对它们进行配置以供使用。
   每一个Object provider必须被assign给一个System Group，所以在这之前需要先建System Group，一个System Group包括多个SAP系统（相同Release），所以最好多定义几个System Group（比如为每一个子公司定义一个），ATC豁免（ATC exemptions）适用的单位是System Group.
4. Configure Run Series
   
   Handling of pragmas/pseudo comments
   这里有两个checkbox可以注意一下
   Analyze Generated Code：分析包括自动生成的代码
   Consider Baseline: 在上次执行后可以将其结果设为baseline，这样下次的执行就是在上一次检查的基础上进行的，比如第一次检查检测到了10个error，如果将其设为Baseline，代码不做改动第二次检测将会是0。Baseline的目的是为了让用户可以更好的关注在新增加或是变更的代码，这个功能是在SAP NetWeaver AS for ABAP 7.51之后的才能用的，
5. Schedule Run Series
   
   也可以后台执行，会在中央系统起几个JOB
   
6. View Results
   两种方式查看ATC结果：SE80或ATC
   SE80:
   
   ATC:
   
   注意：不是所有的check都可以Remote执行，只有勾选了远程标记的check才可以。

4.4 执行S/4 HANA Readiness Check

Check for S4HANA Simplification
7.51版本 SCI和ATC提供了专门做S4 HANA Readiness的check，这6项检查是基于Simplification Database的，所以执行的前期就是SYCM导入Simplification Database（前面提到了如何导入），这6项检查有5项是支持Remote的，可以用这5项为其它旧的SAP ERP系统做Remote check。最后一项Search for S/4 HANA syntax error是不可以远程的，因为它是检查升级后的语法错误。

S/4 HANA readiness check主要有以下几项：

• Search for S/4 HANA syntax errors
  这个检查主要是针对特定的对象集做语法检查操作，检查到的结果与Simplification items中的Notes做匹配，它使用启发式方法搜索可能与语法错误相关的SAP Notes。这也是为什么note的findings可能是不完整的或有一些过量的原因。此检查是用于检查SAP S/4系统中的自定义代码的，例如在导入TR时custom code遇到激活错误，这项检查就可以非常有效的识别哪此错误是跟Simplification相关的并且提供相应的note号供查阅处理。
• Search for Usage of Simplification Objects
  这个检查可以在ABAP库对象中检索被简化对象的用途，被简化对象就是在Simplification数据库中提到的对象，举例说，比如那些为了不引起语法错误而保留在系统中但是原来所用在的功能已经废弃了的对象。
• Field Length Extensions
  这个检查搜索那些因为字段长度变化而有可能出现问题的语句，比如物料hardcode定义物料号18位长度。
• Search for Database Operations
  这个检查将搜索ABAP源代码中不允许的数据库语句。比如引用了那些被废弃的对象的代码。还有上面提到那些能read不能write的对象。
• Search Base tables of ABAP Dictionary Views
  这个检查搜索被简化的数据库表，在simplification 数据库中提及的并且在用户的ABAP Dictionary View中用到的数据库表。这个检查将分析所有的传统ABAP Dictionary view types,像Projection view,maintenance view还有help view.
• Search for Dictionary Enhancements
  这个检查搜索那些被增强过的结构和表，以及simplification database中提及的database view。

Check parameters

每一个check前如果有这个方框加箭头的图标的话，就代表这个check可以设定不同的执行参数，每一项根据实际需求做针对性的设置，这些check也可以被release dependent，比如上图中的设定就是只针对1511版本做检查。如果不指定的话就会对所有版本做检查，实事上并没有必要。
注意：通常情况SAP提供的variant ‘S4HANA_READINESS_nnnn’，可以覆盖所有的一般性检查 ，nnnn代表release的版本。

Check Category in Simplification Database

Simplification Database中的记录需要使用不同的code adaption方法处理。所以不是全部的Simplification item都需要做上面那些check。

• 一些因为功能不再继续用了而需要废弃的库对象，就必须在迁移期间把所有用到的地方都做调整。
• 一些因为字段长度变化而需要调整的数据字典对象（比如domain,data element, structure等）如果不是hardcode的方式在用，也不用调整。
• 还有一些数据库表和视图列在这里是不再需要了，使用它们做为 data type没问题，但必须要检查一下表的访问是否正常，如果有replacement object（proxy object）就没有问题，如果没有就需要更新用到它的read或是write的代码了。

为了支持各种类型的代码处理，Simplification Database中有一列‘Check category’可以方便我们快速分辨每一个simplification item的类型，Readiness check也是根据这个字段来决定运行哪个check：

• 1：被字段长度调整引起的项目，执行hard-code field length check
• 2：有replacement object的数据库表或视图，执行check for write access and dictionary extension
• 4：没有replacement object的数据库表或视图，执行check for read and write，Dictionary extension or views containing this table
• ’ '：空的代表相关的库对象已经被废弃、或者黑名单、或者删除了，任何使用这个对象的都得处理
• 5 6 7：（最新的版本的readiness check中有这3个，暂时不关注先）

Unit5 Example for Custom Code Adaption

以下是常见的code adaption例子，其实在看到代码时就已经知道要去怎么去调整了，所以关键还是在于发现这些需要调整的代码，熟练的应用工具。

5.1 Adapting Code with SAP S/4HANA Related Syntax Errors

语法问题主要有这3类：

• 访问已经删除的库对象
  解决办法：修改使用这些库对象的代码，如果一定要，就在相关的simplification note中搜索替代的对象。通常这个时候需要把整段代码给重写的。
  
• 对已经被替换的数据库表的写操作
  解决办法：修改写操作部分的代码，如果一定要，还是找相关Note中的替代对象。如下图的例子，在SAP ERP中，BSIK表是一张透明表，但在S4HANA中，BSIK则是一个视图（SQL View for a CDS View），这时就要找相应的simplification note做相应调整。
  
• 字段长度扩展后的类型冲突
  解决办法：改掉那些hard-code长度的声明，使用标准的domain和data element，像下面这个例子，只要把上面的matnr也参考mara-matnr就没有问题。
  

5.2 Adapting Code Affected by Field Length Extensions

这种情况不会触发语法错误，但很明显会导致数据错误

分解结构中的数据时错位
BAPI interface中声明类型冲突

5.3 Adapting Code that Uses Simplified Objects

同样3类：

• Syntax Error
• Runtime Error
  
• Missing or Limited Functionality
  

如果对象被删除了还好说，直接报语法错误容易发现，大多数情况下SAP不会把对象删除，会保留在系统里，只要运行进才发现错误。

5.4 Adapting Code that Contains Not Allowed Database Operations

还是以这个MSEG为例，read不需要调整，如果有write操作时，需要用全局CLASS CL_NSDM_STOCK 去修改，一般这种情况SAP都会提供一些全局的类来实现替代对象的write操作。虽然read操作可以正常运行，但从效率方面考虑，维持原对象并不是一个最好的选择，值得去研究一下相关的note对代码做必要的调整。
这种情况下维持read操作就也是错误的，因为这个表已经被新表所替代了，但SAP并没有为KONV设置proxy object，从KONV读数肯定已经读不到正确的数据了。这类情况，SAP也是提供了一些全局类来访问需要处理的数据，而不是简单的更换一下表（如果能简单的更换表，SAP就直接设置proxy object了），这种情况就多看一下simplification note，做相应的调整。像例子中这个情况就要用CLASS CL_PRC_RESULT_FACTORY 来处理条件记录。

5.5 Adapting ABAP Dictionary Views with Obsolete Base Tables

如果被简化的数据库表是视图的基础表，影响取决于simplification的性质，表的删除肯定会引起view的激活error，同样如果表被view替代的这种情况也一样会被错，因为view-on-view不行。
这里需要注意的是：==对于有proxy object的表，直接访问时系统会自动指向替代表，但如果是做为视图的基础表时，系统是不会自动指向替代表的。==像上面图中的例子，本来视图取的是是ANLA和ANEA表，但ANEA被简化了，ANEA表有一个替代对象FAA_ANEA，直接访问ANEA时系统会自动指向新的CDS VIEW FAA_ANEA，问题是ANEA并没有完全过时，代理对象取数时不止取ANEA表，还取了另外两张表。 S4D440D_VIEW_3 这个VIEW取数时会直接读ANEA表，也不会指向替代的CDS VIEW，这样另外表张表的数据就会丢了。
这是其中一种解决方案，不能再使用视图 S4D440D_VIEW_3 ，而是使用ANLA和FAA_ANEA的JOIN,这样可以避免数据的不完整。（当然这里用ANEA也可以，因为是直接访问，系统会自动指向替代的那个CDS view）
这是另一种解决方案，创建一个新的CDS VIEW，其中包含ANLA和FAA_ANEA的join。注意：CDS VIEW和传统的VIEW是不同的，它可以使用view做为base objects。
其实还有一种方案，就是做一个新的CDS view做为数据库视图S4D440_D_VIEW_3的proxy object，这时读 S4D440_D_VIEW_3时就会自动指到新的CDS view。

5.6 Adapting ABAP Dictionary Enhancements

如果在SAP ERP中给表创建了APPEND，表在S4HANA又被简化了，那么在迁移之后就需要特别注意这些APPEND的字段是否可以访问。有两种情况 ，如果表被删除了，那么这时的APPEND就不能迁移过来，另一种是如果表被指定了proxy object，那么在代理对象没有使用完全相同的字段进行扩展之前，激活都是不可能成功的。不管是这两种情况中的哪一种，新的字段在新的库对象中都将丢失，并且需要在那里再添加。对于某些表，数据迁移工具将支持将附加字段从旧数据结构迁移到新数据结构。但为此，有必要在数据迁移之前进行分析和代码迁移。第一种情况就是原表和proxy object字段数不同

例如，数据库表KONV在SAP S/4HANA中已经过时，而定价条件数据存在数据库表PRCD_ELEMENTS中，假设客户已经向数据库表KONV创建了一个APPEND结构，那么很可能升级后就也必须将相同的字段附加到数据库表PRCD_ELEMENTS中，而且要在将数据从KONV迁移到PRCD_ELEMENTS表之前，准备好这个有附加结构的PRCD_ELEMENTS表。但是数据库表PRCD_ELEMENTS并不是惟一需要APPEND字段的地方，还有两个数据库表也包含相关数据，它们都与SAP Fiori APP维护定价条件数据的DRAFT概念有关。另外，SAP提供了兼容性视图V_KONV和V_KONV_DRAFT，它们以旧表KONV的格式返回新表中的数据，所以为了确保额外字段的可用性，当通过这些兼容性视图读取数据时，也需要扩展它们。
总之，==APPENED一定要全！==别漏对象，方法就是盯住相关的note。

最后是CDSView的扩展，是在使用DDL语句extension view的definition部分中定义的。每一个带有CDS View extension的DDL源代码都定义了两个对象：真实的CDS view extension和一个Append View，对应了标准DDL定义的两个对象:CDS view和SQL view。
上面是CDS View V_KONV扩展的例子

补充内容

在升级前precheck前看下这两个note 2194618,2197392，主要是检查MM-IM模块的一些必要检查，必须哪些标准表做了字段增强，在升到S4 HANA后这些表变成了CDS view，那些增强字段就需要以 CDS View extension创建。
其实应该把Simplification 文档认真熟读之后再做升级，起码把涉及的模块的内容都读一遍，Note也大概看一遍，相信我，磨刀不误砍柴工！熟读Simplification List文档花费的时间在后期都能节省出来。