ERP / ECC Archives » Musings of an IT Implementor

Release 2023 of SAP S/4HANA Last Target

The 2023 release of SAP S/4HANA is due in October 2023.
This release is likely the last release that existing SAP ERP customers can reasonably migrate to.

Here’s why

Any customer migrating to S/4HANA from SAP ERP will need to perform all the analysis and preparation work against this 2023 S/4HANA release (functional capabilities will be known).

The next S/4HANA release will be in late 2025 because after the 2023 release the product moves to a new 2 year release cycle (instead of annually).

This 2025 date is likely to be too late for any reasonably large customer to migrate to, as it would leave only 2 years until 2027 (end of maintenance for SAP ERP) and taking into consideration of the start of end-of-maintenance of Compatibility Scope items (see my other post about those here).

Running an SAP ERP to S/4HANA migration project quicker than 2 years is possible, but this depends heavily on existing environment complexity.

I would bet that for most, 2023 is *the* target S/4HANA release. The saint release as I’m calling it.

Reference link: https://news.sap.com/2022/09/new-sap-s4hana-release-maintenance-strategy/

SAP S/4HANA Compatibility Pack EOM

I don’t know about you but my LinkedIn feed is becoming uselessly full of “you must move to SAP S/4HANA” posts, with no real business case for doing so apart from the old “you will be left behind…” justification.
It is also becoming full of posts claiming that SAP S/4HANA Private Cloud Edition is the same as SAP S/4HANA On-Premise Edition.

Well, I’m ashamed to say, this is one of those “you will be left behind…” posts, but with an added “…in a boat with a hole and no bucket.”.
As a by-product it will also prove that SAP S/4HANA PCE is most definately not the same as SAP S/4HANA On-Premise Edition.

Some blogs on blogs.sap.com get many, many thousands of views, mainly because they answer the most common questions.
There are some questions however, that few ask and this one has brought me to this excellent blog post linked here: https://blogs.sap.com/2023/05/03/functional-differences-between-sap-s-4hana-cloud-private-edition-and-sap-s-4hana-on-premise.

When moving to SAP S/4HANA, some existing SAP ERP customers were/are allowed to carry over features/developments originally designed for SAP ERP.
These are called “Compatibility Packs” or “Compatibility Scope Items” and are detailed further in links in the blog post that I am linking (I recommend you read the linked blogs from that blog post).

In the blog post I reference it says:

“…functionalities that were originally created for SAP ERP that are currently available in SAP S/4HANA. But SAP has authorized customers to use these functionalities in SAP S/4HANA for a limited time…“

Oh really. Until what time is this “limited time” you may be thinking?

“…typically until the end of 2025, with a few exceptions that will be available until 2030.“.

Well, that is great for those customers that have already made the move to S/4HANA.
What about those that are not yet on S/4HANA? Does that 2025 date extend out to 2027? No, it does not!

The impact therefore, is if you are late migrating to the S/4HANA party, all the good food is already gone!

Those companies moving to S/4HANA before 2025 will get access to those Compatibility Packs to help smooth their transition from SAP ERP (if they need them).

Those who are moving to S/4HANA between 2025 and 2030, will see some of those Compatibility Packs become unsupported.

They can be used (SAP will not delete transaction codes etc) but they will be unsupported and unmaintained (think about security, legal, integrity issues and not just bugs).

Finally, regarding SAP S/4HANA On-Premise vs SAP S/4HANA Private Cloud Edition. These are similar but not the same.

The blog post goes to lengths to explain that “…the functional differences between SAP S/4HANA Cloud, private edition, and SAP S/4HANA On-Premise are only features that belong to the compatibility scope Matrix…“.
Voila!

Three editions of SAP S/4HANA, three products with differences:

Private Cloud Edition (for RISE with SAP).
On-Premise Edition (for those that know sense ;-p ).
Public Cloud Edition.

You may also be interested in:

Values for SAP Auth Objects F_REGU_BUK and F_REGU_KOA

Whilst configuring some new read-only SAP roles for FICO access, you may be struggling to find the descriptions for the actions for authorisation objects F_REGU_BUK and F_REGU_KOA and the values for FBTCH (Action for Automatic Procedure).
The descriptions do not appear in the usual auth object display screens.

Within the SAP GUI, if you go into transaction F110, then from the menu select “Environment -> Authorizations”, a popup will be displayed with the following legend:

Key	Action
02	Edit parameters
03	Display parameters
11	Execute proposal
12	Edit proposal
13	Display proposal
14	Delete proposal
15	Create payment medium proposal
21	Execute payment run
23	Display payment run
24	Delete payment run payment dat
25	Create payment media of paymen
26	Delete payment orders of payme
31	Print payment medium manually

For a read-only role, I would recommend only actions 03,13,23 and possibly 31 (in case the electronic BACS payment method breaks).

You may also be interested in:

R/3 to ECC – Benefits of not upgrading anything?

This is a question that will probably be asked by many IT persons over the coming months, as SAP draws to a close support for the SAP R/3 4.7 system.
(see the SAP production availability matrix https://service.sap.com/pam).
Whilst upgrading to ECC will mean a SAP supported system, what other options are out there?
Let’s look at just a few so that you may have some ideas that you maybe hadn’t considered.

– Stay where you are and pay for extended support.
This is an interesting option. Let’s face it, if you use SAP as a basic product e.g. for accounting or sales transactions, then exactly what else will you need from a product in the future? Why not save the upgrade costs and simply pay for extended support, and keep paying each time it expires.
Whilst the initial support costs may be known, the future costs are not and SAP could hike these. Also, there may be a fairly straight upgrade path to a newer product at the moment, but in the future you may have to follow that path, plus the additional paths and intricacies of upgrades to later versions in order to reach something more modern (UNICODE anyone!).
Things like OS support may bite you eventually, and those of you on HP-UX Itanium are already seeing what happens to non-x86 based operating systems when companies like Oracle decide to stop supporting you. Your future upgrade path could involve skill-sets no longer available/costly, or even more lengthy processes because you’re moving from older hardware.
On the positive side, the future could hold hope in the form of faster systems, smarter tools and cheaper processes that could make future upgrades/migrations faster and cheaper than doing it now. A big database in the future may not be so big in relational terms.

– Stay where you are and don’t pay for extended support.
You will loose all access to standard SAP support sites and tools, plus you will not benefit from any DB updates or DB vendor support.
This could be very problematic if your business needs to apply SAP legal patches for changes to HR related functions within the SAP modules.
I’m not entirely sure if you will still be able to request SCCR keys for modifying SAP objects or even be able to develop your own ABAP code in your own system. Maybe someone can let me know on that one.
Some of the words in Oracle Database support contracts state that you may have to back-pay for support if you decide to re-enable support at a later date. I’m not sure if SAP would be the same.
You would potentially suffer during external audits if additional security related legislation comes along (SOX for example) and you are not able to apply the updates/functionality to provide that security.

There are some common issues with both options above. These mainly centre around the IT resources that are supporting those systems. Nobody likes to stay still in IT. Not unless they are happy in the knowledge that retirement is looming and they just need to keep rolling in the meantime.
The constant need to keep abreast of the latest technical enhancements/changes is one of the most difficult aspects of the IT profession.
However, with the advent of off-shore IT resources, it should be possible to secure long-term support resources even if you can’t secure them on-shore. Having said that, I don’t yet know of any off-shore company that has a high retention level. Maybe this is coming…

In summary, there are some cost advantages in the short term for not upgrading an SAP system. But unfortunately those costs may hit you in the end in some form or another.

SAP FBL5N and Change Document Authorisation

After spending tedious amounts of time in SU24 and performing an authorisation trace I was unable to work out how users got “Change Document” access in FBL5N (Customer Line Item Display).

Access to change documents via transaction FBL5N, which is inherently a display only transaction, is controlled by giving transaction FB02 to the user.
You have to look in the source of program RFITEMAR:

Adding transaction FB02 (plus maintaining the subsequent authorisation activities) to a users role, as well as FBL5N, provides the “Change Document” button on the menu bar in FBL5N: