尽管我们要迁移到S/4HANA还有相当长的时间，但我还是决定在我们庞大的Z代码库上使用最新的简化版数据库1909来运行就绪检查。这是因为我对系统中"睡眠"的惊喜感到好奇，以及Olga Dolinskaja在今年巴塞罗那TechEd（CAA364会议）上的演示文稿中整洁的摘要幻灯片，其中建议准备好新代码s/4HANA：

幸运的是，我们已经有了一个远程ATC系统西北7.52，因此准备好进行S/4HANA准备就绪检查。在中央ATC系统中应用了OSS note 2812556–Check variant for SAP S/4HANA 1909自定义代码检查之后，我设置了一个运行序列来查看所有的Z代码，并使用了标准的S4HANA\u READINESS\u Check\u 1909。由于要在两个开发系统中签入的对象太多，运行需要一段时间才能完成，但运行时间分别不到1 1/2和2 1/2小时，也不算太糟。不足为奇的是，调查结果的列表非常大，我没有在SAP中到处乱翻，而是把所有的结果都下载到Excel中，以便更容易地"玩"出结果来。

通过对Excel文件进行一些调整，并根据每个条目创建一些透视表，通过简化OSS便笺，我能够生成一个有用的列表，其中显示了所有受其影响的程序。

下一步——有点乏味——是在一个内部合流空间中为每个便笺创建一个页面——如果它不是由同事创建的话——提供指向OSS便笺的链接和其中的一些信息，大数据实战，淘客返利，特别是评论什么需要在Z代码中寻找需要适应。我还将受影响程序的列表添加到每个页面（是，这不是一个有趣的任务，但在将来我们在自己的代码中寻找具体的例子时，它将被证明是有帮助的）。

在OSS注释的长列表中，我并不惊讶地看到"2215424 Material Number Field Length Extension"或"2220005 S/4HANA:Data Model Changes in Pricing and Condition Technique"的条目与我们使用的过程有关。但是，联网，列表中也有一些奇怪的标题，对我们公司来说似乎完全不合适。

为什么我们的项目会受到"2689873 SAP S/4HANA:SAP患者管理（IS-H）限制说明"的影响？这确实激起了我的好奇心，特别是因为便笺中包含了一条有趣的信息："另请注意，自SAP S/4HANA 1809起，属于上述医疗保健产品的所有开发对象都已从软件堆栈中删除。"。所以我浏览了80到100个节目的短名单，看看到底发生了什么。以下是我发现的一些东西的集合：

一些程序调用的功能模块名称中至少有"ISH"，泄露了它们所属的位置：

但是，程序中使用的大多数受影响的is-H对象都有相当不起眼的名称，开发人员这么多年来一直在使用它们，大数据现状，我并不感到惊讶。通常，对象属于"IS-H"的唯一"指示"符号是在描述字段中。以下是一些示例：

功能模块：

内存ID：

消息（不确定您的情况，但我也倾向于重用标准消息，而不是为"Customer&was changed"这样的通用消息创建另一个版本，然后我必须提供翻译和可能的长解释）：

但是，锦上添花的一定是无伤大雅的数据元素"CHAR02"：

鉴于还有其他几个相似的命名数据元素，只是根据长度的不同而有不同的名称，所以这一个被大量使用也就不足为奇了！为了寻找CHAR02的替代品，我很快就找到了CHAR\u02，它可以被替代使用——从它的包名ABA\utools来看，这一个很有希望能保留很长时间（er），而不会被砍掉！

我不太明白的是，为什么SAP不只是在一个基本包（也许是ABA\U工具？）中提供一套完整的数据元素和相应的域命名为CHAR\u 001，CHAR\u 002…。CHAR_128（或其他），加上相同的字符，例如结尾的"_CS"，表示它是用于区分大小写的内容。这将避免像这里发生的CHAR02的"意外"使用。

对于这些和其他尚未确定的"有趣"发现，我要做的是将它们放在我们的开发指南的列表中，让我们的开发团队知道它们，并要求他们至少不再将受影响的对象用于任何新的开发。在可能和可行的情况下，如果出于任何原因需要更改现有代码，也应该将它们从现有代码中删除。我还将定义一个自定义检查变量，只包括在转换为S/4HANA之前实际上可以很容易地执行的检查，并且不像MATNR长度问题那样普遍，如果需要的话，物联网设备，在我们实际进行切换时，自动代码更新应该是可用的要做的计划是将此检查包含到常规例程中—可能是对当前打开的传输请求及其包含的对象的每日检查运行。检查变体将包括相关检查，但仅限于确切的OSS注释，以避免过多不需要的/错误的点击。理想情况下，我还将找到一种方法，将结果发送给当前正在处理该对象的开发人员，以便提醒他/她代码中的这些与S/4HANA不兼容的构造。也许，我还将在传输释放期间使用的常规检查中包括它们，但是发现可能经常被忽略，因为它们只是优先级3（我还不确定是否值得将其更改为优先级2或1以防止传输释放）。但是，我很肯定，我们至少应该防止创建更多具有这些类型的可预防问题的程序。