The Future of Compatibility Packs in SAP S/4HANA

[JanGilg]

If you’re reading this blog post then you’re probably in the process of working out your path to SAP S/4HANA. You’ve probably also learned that some of the features that you use today come from SAP ERP – and are therefore provided to you as a compatibility pack.

But what are compatibility packs? They were originally introduced as a way to unite multi-year development cycles at SAP with multi-year adoption strategies at our customers. Over time, we want to provide alternatives to the capabilities that are currently provided as part of these compatibility packs. In fact, many alternatives already exist or are already included on our development roadmap.

While SAP recently announced the maintenance extension for SAP Business Suite 7 until the end of 2027, the usage rights of the compatibility packs were not included in this extension and a couple of questions came up about why and how to deal with it.

 

Compatibility packs not extended beyond 2025: So, what’s next?

In short: We will offer, or have already offered, alternatives. In fact, out of 183 compatibility pack items only 15 are still in clarification for an alternative. We’re currently investing in order to accelerate the development schedule for those alternatives that are still outstanding so that they are available to customers in time for adoption before the usage rights expire. To help with this, SAP will provide timely communication to customers. We are in the process of completing the re-planning of the remaining alternatives and we hope that the complete overview will be available in Q3 2020. Intermediate updates will follow as the planning evolves. The complete overview can always be found in SAP Note 2269324.

We asked our teams to consider the effort to adopt the alternatives and hence build bridges where possible. In addition, we prioritized those with expected larger efforts like HCM or stock room management to start earlier to grant more time to adopt these. Target is for all alternatives to be available by 2023.

We think that customers will be able to plan their adoption scenarios based on this information. We see two scenarios:

1. An alternative capability exists for the relevant compatibility scope when you start the project. In this case we recommend that customers adopt the alternative as soon as they move to SAP S/4HANA.


2. An alternative is currently only planned for parts of the relevant compatibility scope. In this case it will be adopted as part of an upgrade after the alternative has been provided.

If you bring up a new system, you may as well sequence the deployment of capabilities so that you can only implement certain functionalities once the alternative exists.

 

Effort remains essentially the same

The good thing is that, in terms of effort, the overall effort to adopt SAP S/4HANA is generally not increased: It is simply split into two phases. Based on this, it’s possible to start now and harvest the innovations that were built over the past five years: In this way, customers can drive the value in their company as there is no need to wait for all the relevant alternatives to be completed first. This even has an advantage of its own as customers who move to SAP S/4HANA after 2025 will no longer be able to split the tasks into two phases. So, there’s no reason to wait to adopt SAP S/4HANA!

Of course, it’s also an option to delay the adoption of existing alternatives to a future upgrade to spread the effort and balance with other company strategies. However, in terms of change management, some changes may be simpler to adopt at the time of moving to SAP S/4HANA. This should be considered as part of the validation process for moving to SAP S/4HANA.

I hope this clarifies the logic and reasoning around compatibility packs at SAP S/4HANA: I believe that this process will make it simpler for our customers to move to SAP S/4HANA within the given timeline.

 

Further information:

SAP Support Portal

www.sap.com/s4hana

openSAP Course on SAP S/4HANA

[raph_g_pp]

Hello Jan

Thanks for this nice blog. Would you have an update for the 56 as I have not heard of any follow up and Q3 is behind us.

One of our key issue is the future of processes beased on LIS,

• namely Demand Planning and Forecasting and
• product allocation in SD (https://help.sap.com/doc/saphelp_46c/4.6C/en-US/6b/2785347860ea35e10000009b38f83b/frameset.htm) : we understand that aATP provide the PAL feature, but this will require additional licences, whereas product allocation is still available in S4 and covers our needs.

Thanks

[JanGilg]

Hello Raphael,

Many thanks for your comment and your question.

Since April 2020, we have continuously worked on the open items and we are updating the status in SAP Note 2269324 on a regular basis to keep our customers informed.

We now offer alternatives for 142 compatibility scope items (an alternative exists for 90 and there is a roadmap for an alternative for a further 52) compared to the 126 alternatives offered in April last year. Will continue to increase this number in the coming months.

 

Demand planning and forecasting is an SAP SCM application. Since you refer to LIS, I assume you rather mean Sales and Operations Planning (SOP) in SAP S/4HANA. SOP is addressed by the compatibility scope matrix ID 458 which you will find in the attachments to SAP Note 2269324. The alternative for SOP is IBP. PAL will still be part of SAP S/4HANA up to 2025 and beyond. However, it is only part of the basic ATP version in SAP S/4HANA. If you wish to use advanced ATP (which requires an additional license) then PAL cannot be used. For technical reasons PAL has to be switched off globally for the complete system in this case.

 

I hope this answers your questions.

 

Kind regards,

Jan

[raph_g_pp]

Thanks Jan for this very precise answer.

Do you have any official document confirming that PAL (basic ATP) will remain avaialble after 2025 ?

 

Thanks again for the quick answer

 

Raphael

[stefan_berndt]

Hello Raphael,

Product Allocation is part of the perpetual scope of SAP S/4HANA as described in the Feature Scope Description and, hence, available according to SAP maintenance commitments for SAP S/4HANA. SAP has currently no plans to revoke Product Allocation functionality provided as part of SAP S/4HANA Sales – Available-to-Promise.

Kind regards,

Stefan

[shirley_te]

It is not clear what "expiration of the usage rights" means to customers.  I understand about the support/maintenance will end.  But what is it to the customers as it relates to ,the expiration of usage rights because there are customers out there that even on versions of certain components of SAP are out of maintenance that they continue to use and accepting the risk that if something goes wrong, they do not get any support from SAP to fix the problem.  So for those customers who are willing to accept the risk of not having support or maintenance, what is the implication of the "end of usage rights given that SAP indicated "End of usage rights" does not mean those objects and artifacts covered by the compatibility pack will be deleted.

• Will that mean that in the S/4 HANA version there is a flag that suddenly gets turned on at the end of 2025 such that the users cannot execute any of the transactions covered by the compatibility pack?


• Will it mean they can still use it but SAP will be able to audit customers who are still using the transactions covered by the CP?  If yes, what would be the repercussion to the customer?  Will it be asking the customer to pay for license or fee for a product that is no longer supported?


• Will that mean that beyond 2025, the artifacts may have changed that those transactions using the artifacts prior to 2025 will stop working?  If yes, that means only those customer who are moving to S/4HANA version beyond 2025 will be affected but the ones below can continue to use minus the support from SAP.

I hope it can be clearly specified by SAP what does really "end of usage rights" mean to customers and not just saying that the CPs will no longer be supported or under maintenance because I am sure there will be customers who are willing to take the risk of not being supported for a certain period of time.

Thanks

S

[JanGilg]

Hello Shirley,

thanks for your comments and questions.

Please refer to the more recent blog post “Compatibility Scope: What Happens after 2025/2030, which is going into more details on the topics you are asking about. Especially for bullet point 1 and 3 of your question (answer 3. in the blog post).

The right to use the Compatibility Scope is independent from any maintenance obligation – see next section for details. However, compatibility scope functionality might break at any time after 2025, as this functionality won’t be adjusted anymore to changes delivered with subsequent SAP S/4HANA releases, support packages or notes, nor will it receive legal changes.

The Compatibility Scope usage rights expire automatically December 31, 2025 for all SAP S/4HANA versions, independent from their release date.

So irrespective of the SAP S/4HANA version, customers must not use Compatibility Scope functionality anymore after that point in time and SAP is convinced that customers will adhere to the contractual obligations in place.

(For selected functionalities in CS, PP–PI and LE-TRA, the usage rights and support is going to expire end on December 31, 2030. Details please see SAP note 2269324.)

Best,

Jan

[shirley_te]

Hi Jan,

Thank for your response and clarification.  I am clear now about artifacts and certainly about not being supported but it is still not clear what will happen to customers who are willing to take the risk of not being supported to continue using CP beyond 2025/2030 for a certain period of time after 2025 or 2030 for some. What is this contractual obligation and what if the customer does not adhere?  This will make it clear to us if we know of the implications apart from not being supported and that it may break and we are on our own.

 

Kind regards,

Shirley

[iguchi_hiro4]

Hi Jan,

I would also like a concrete answer as to what will happen to customers in terms of licensing if they use it after January 1, 2026.

Also, regarding profit center accounting, note 2993220 states that it can be used after the expiry date, so I would like you to explain specifically.
(Why can't SAP make each note consistent with the Compatibility Pack for important description changes?)

Regards,
Hiroshi

[JanGilg]

Hi Hiroshi,

Thanks for your comments and questions.
Regarding profit center accounting we have revised our statement in note 2993220 and changed it to better explain our strategy going forward.
We will adopt actual postings for classical Profit Center Accounting, using GLPCA and GLPCT, to SAP S/4HANA product standards and, thus, customers could use actual postings in EC-PCA after Dec 31, 2025. This will allow our customers to create their balance sheet, complete their fiscal year, and perform a final year end closing. However, this functionality is set to “deprecated” and will receive no further developments or updates. Customers need to transition to Profit Center Accounting on Universal Journal at the latest with the next fiscal year change after Dec 31st 2025.
Profit Center Planning based on table GLPCP stays in compatibility scope, though, and must not be used beyond they expiry date of the compatibility package usage rights, i.e. Dec 31st 2025.

Best,

Jan

[iguchi_hiro4]

HI jan,

Thanks for your reply。

In that case, I have the following questions:

I would like to ask a question if a customer is using only GLPCA and GLPCT for Planning and Accounting without using GLPCP in ECC6.0.
(This question would be if you were applying the approach in the following blog as of ECC6.0.
https://blogs.sap.com/2019/01/27/cost-center-and-glprofit-center-budget-uploads/)

1. Even if I convert to S/4HANA, I can still use it from 2026 as it will not be a Compatibility Pack, but does that mean I will need to migrate to the S/4HANA version of Profit Center Accounting after that? .

2. Do I need SAC or BPC when migrating to S/4HANA Profit Center Accounting? .
(In the case of the blog method mentioned earlier, I think these are unnecessary.)


Best regards,
Hiroshi