Skip to Content
Personal Insights

Interesting stuff you find when running S/4HANA Readiness Checks

Even though our move to S/4HANA is still quite some time away, I decided to run readiness checks with the latest simplification database for release 1909 on our large Z-code base. This was inspired by my own curiousity of what surprises we have “sleeping” in our system and the neat summary slide from e.g. Olga Dolinskaja‘s presentation at this year’s TechEd in Barcelona (session CAA364) which among other things suggests to make new code S/4HANA ready:

Luckily enough, we already have a remote ATC-system which is on NW 7.52 and therefore ready for the S/4HANA readiness checks so to speak. After having OSS note 2812556 – Check variant for SAP S/4HANA 1909 custom code checks applied in the central ATC system, I set up a run series to look at all of our Z-code and used the standard S4HANA_READINESS_CHECK_1909 for it. Due to the numbers of objects to check in two development systems, the runs took a while to complete, but with less than 1 1/2 and 2 1/2 hours runtime respectively it wasn’t too bad either. Not too surprisingly, the resulting lists of findings were quite large and instead of poking around in SAP in them, I grabbed the whole lot and downloaded it into Excel in order to more easily “play” with the results.

Looking at the findings

With some tweaking of the Excel-files and creating some pivot-tables based on the individual entries, I was able to generate a useful listing by Simplification OSS-Note showing all the programs affected by it.

Next – and somewhat tedious – step was to create one page per note – if it hadn’t already been created by colleagues – in an internal Confluence space on which to provide a link to the OSS-Note and some information from it, especially comments on what needs to be looked for in Z-code in need of adaptation. I also added the list of affected programs to each page (yes, not a fun task but one which will prove helpful in the future when looking for concrete examples in our own code).

What the heck?!?

Looking through the long list of OSS Notes I wasn’t surprised to see items for “2215424 Material Number Field Length Extension” or mentions of “2220005 S/4HANA: Data Model Changes in Pricing and Condition Technique” as these are related to processes we obviously had in use. But, there were also some rather weird titles included in the list which looked completely out of place for our company.

Why should we have programs impacted by “2689873 SAP S/4HANA: SAP Patient Management (IS-H) Restriction Note“? This really piqued my curiosity especially because the note contained this interesting piece of information: “Also please note, that as of SAP S/4HANA 1809 all development objects belonging to the above mentioned healthcare products have been deleted from the software stack.”. So I went through the not even short list of 80 to 100 programs to find out what was going on. Here is a collection of the things I found:

Some programs were calling function modules which at least had “ISH” in their names, giving away where they belong to:

            ss_bapiret2 = lt_mess[].

        call function 'ISH_POPUP_TO_CONFIRM_SIMPLE'
            I_TITLE    = text-ach
            I_TEXTLINE = v_textline
            I_QUESTION = v_text80_2
            I_DEFAULT  = 'N'
            E_ANSWER   = v_answer.

But, most of the impacted IS-H objects used in the programs have rather nondescript names and I’m really not surprised that developers have made use of them over the years. Often, the only “tell-tale” sign that an object belongs to “IS-H” is in the description field. Here are some examples:

Function Module:

      datin  = p_wadat
      format = 'DD.MM.YYYY'
      datex  = var_date_out.

Memory ID:

                                   MEMORY ID FIL

Messages (not sure about you, but I also tend to reuse standard messages instead of creating yet another version for something generic as “Customer & was changed” for which I then have to provide translations and possibly long explanations):

    MESSAGE i179(n8). "There is no data for your selection

    MESSAGE s064(nf) WITH sy-subrc 'LT01' "Error & while calling transaction &
    INTO lt_listact_alv-message.

    MESSAGE e115(n2) WITH wa_kna1-kunnr "Customer & was changed
                          space INTO wa_data_alv-msgtxt.


But, the icing of the cake must be the innocuously named data element “CHAR02”:

    constants C_CREATE type CHAR02 value '01' ##NO_TEXT.

      c_bt   TYPE char02            VALUE 'BT', 

Given, that there are several other comparably named data elements just with different names depending on length, it’s really no wonder that this one gets used rather a lot! Looking for an alternative for CHAR02 I quickly found CHAR_02 which can be used instead – and judging from its package name ABA_TOOLS this one will hopefully stick around for long(er) and not get axed!

What I don’t quite understand is why SAP doesn’t just provide a complete set of data elements and corresponding domains in one of the basic packages (perhaps ABA_TOOLS?) named i.e. CHAR_001, CHAR_002 …. CHAR_128 (or whatever), plus the same with e.g. “_CS” at the end to show that it’s for case-sensitive content. This would avoid “accidental” usage like happened here for CHAR02.

Next steps

What I’m going to do with these and other yet to be identified “interesting” findings is to put them in a list in our development guidelines, let our developer teams know about them and ask them to at least no longer use the impacted objects for any new developments. Whenever possible and feasible they should also be eliminated from existing code should it need to be changed for whatever reason. I’m also going to define a custom check variant including only checks which can actually be acted upon easily before the conversion to S/4HANA happens – and are not as ubiquitous as for example the MATNR-length issue for which – if need be – automated code-updates should be available by the time we actually make the switch.

What I also plan to do is to include this check into a regular routine – perhaps a daily check-run for currently open transport requests and the objects these contain. The check variant will include the relevant check but restricted to the exact OSS-Note(s) to avoid too many unwanted/false hits. Ideally, I’ll also find a way to send the findings to the developer currently working on the object in order to alert him/her about these not S/4HANA compatible constructs in the code. Perhaps, I’ll also include them in the regular check used during transport release but the findings might get overlooked often because they are only priority 3 (and I’m not yet sure it would be worth changing that to priority 2 or 1 in order to prevent transport release). But, I’m fairly certain that we should at least prevent creating more programs with these types of preventable issues.

Your experience and asking for verification

Have any of you encountered similar cases with finding out-of-place simplification notes and interesting impacted objects? If you did, how did you deal with them? If you already have a S/4HANA 1809 (or even 1909) system at your disposal, would you mind checking if the above mentioned objects really no longer exist and let us know in the comments?


You must be Logged on to comment or reply to a post.
  • Hi Bärbel,

    I have seen the same at customers. After running the S/4HANA readiness checks the results have been quite "interesting" i.e. functionality from IS-Health and IS-Media was reused. The bottom line for me and an important message to customers:  when converting to SAP S/4HANA even if you do not use industry-specific solutions like IS-H or IS-M in your business processes there might be some technical "debt" hidden in your custom code that you must consider and that will cause some efforts before you do the conversion.

    Best regards


  • What I don’t quite understand is why SAP doesn’t just provide a complete set of data elements and corresponding domains in one of the basic packages

    I would consider such basic data elements as a bad practice. Data elements should carry semantic meaning.

    I suggest to create own data elements for each use case, even if many of them share the same technical data type. That is a bit more work in the beginning, but you gain:

    • individual description or even documentation in the data element, making its semantics clearer
    • the ability to change the data type of this data element in wherever it is used. A data element "char02" can never be changed to something else.


    • Hi Andreas,

      not really sure if it's bad practice to use such basic data elements for typing internally used fields as is done in the examples I saw in our Z-code which don't really need much if any semantic meaning. If such a field needs another type within a program, the definition could just be switched to another available basic data element.

      My main point was SAP's "somewhat" haphazard naming of these data-elements (and corresponding) domains, that they are all over the place package-wise and with many "gaps" in between:

      (just a few of the 408 data-elements starting with "CHAR*").

  • We have a similar result in our ATC findings. Over 300 occurrences of IS-H usage. I also can confirm that all of the above objects do not exist in our 1809 test system (we are going 1909).

    • Thanks for checking in your system and providing feedback, Jeff! Makes for an even stronger case inhouse to prevent making this issue worse and to add appropriate checks to our check variant used during transport release sooner rather than later.

  • I'm currently trying to fix a development created in an ERP system (which is a standalone application), so that it can run on a BW system. I encounter exactly the same kind of issues - function modules and data elements that do not exist in BW are being used.

    I've encountered similar where I've created a whole suite of applications... and then the client asks for just one of them for one particular instance. It's very hard to disentangle! You either get all, or nothing.

    It's a bit of a paradox - on the one hand, don't recreate what already exists, but on the other hand, program without dependencies!



    • When I just started with ABAP, the mantra was "re-use", so we scoured SE11 for standard types that would match what we needed. I've even seen "do not create Z elements in dictionary" in some guidelines. Why? No one could explain other than "it takes up space". As if we were still dealing with the machines having memory in kilobytes. 🙂

      Of course, reusing is not bad but must be applied judiciously.

  • Hi Bärbel,

    I also can confirm that I see a lot results like that. Additional to the data-elements I want to make you aware, that also the reuse of exception-classes should be in your focus. This is something I also run in when upgrading from different S/4-releases. HAd the last shift from 1709 to 1809 and also run into the problem, that some of the data-elements and exception-classes did not exist anymore.


    • Thanks for your feedback, Florian! If issues with the exception classes exist, I hope/guess that they'll be caught by the readiness checks - or is that hope in vain?



  • Hi Bärbel,

    thanks for the blog post and making us more aware about that!

    It just shows again, that the package concept features which are offered by the ABAP stack are rarely used and this causes a lot of problems. I agree with Andreas Huppert that one should create own domains if possible. The same applies for me for error messages. If it's a custom application you should create your own messages. If it's an enhancement of SAP coding, only use the message class of the package the SAP coding belongs to.

    I know this feature is not often used, but the package concepts even offers the possibility of definining objects which can be seen and used from other packages and there are checks for that. So in a new custom code project I recommend to define a clear package concept and use this features!

  • Hi Bärbel,

    you are not alone. The following result is from a run I made yesterday (3.5 h runtime by the way). Most of the marked findings are dataelements or function calls which are not available anymore in S/4 (IS-M, IS-BEV,...)

  • Thank you for sharing! Our system is not even there yet but it's been one of my "upgrade selling points" that we need to upgrade our ECC so that we can start the whole HANA readiness rather sooner than later.

    It would also allow us to improve discipline when creating new code. Just like we enabled Unicode checks on all programs even before the system conversion, it makes total sense to make any new code HANA-compliant.


  • Hi Bärbel,

    yes, I can add something (I had put it on Mastodon but not shared here yet) :


    Did you know? When going from #SAP #S4HANA 1709 to 1809 you will lose some dictionary types, e.g.:



    SAP-Components that (seem to) have been simplified (=> deleted) with #S4HANA 1809:

    IS-M: SAP Media (confirmed via #SimplificationList)
    IS-H: SAP Healthcare (haven’t seen a clue on this one)

    2 more* data-elements affected:

    (*of course, there are many more, but those mentioned caused me some problems! ? )



    Very smart if you find out via checks up front, that’s how it should be – we found out when doing the upgrade ?  (no big deal, we do an upgrade every year and there often is some kind of surprise)



  • Hi Barbel,

    Nice to read this blog. As the upgrade from 1709 to 1909. We came across below ATC check. in S/4 HANA message class N4 is not available "Alternate message ID, message content needs to be created" and some issue with IS-M data element. Can you suggest what should we do?  Do we need to create custom messages and data element accordingly?