How to find standard routines to update SAP-tables which will survive a conversion to S/4HANA?

[BaerbelWinkler]

In our ERP NW 7.50 system (SP13, EHP8) we unfortunately have many (actually way too many!) instances where SAP-tables get updated directly in custom code. Many of these codings were created years ago and not just to update custom fields in append structures or used in "one-time" correction reports. I'm well aware that this never should have happened but wishful thinking won't make these udpates go away. I'm therefore looking for options of how best to identify replacements for the updates via standard routines.

As this is one of many preliminary activities in the run-up to a conversion to S/4HANA, whatever we change the code to now should stand as good a chance as possible to still be available and functioning with S/4HANA. I have a hunch that this limits our options considerably as thus far convenient solutions like Call transaction/Batch Input will not make the cut. In addition, we already know that for example some BAPIs don't work properly wihtin our processes so several of them will not be an option either.

Here are a few questions I have but I'm sure there'll be more:

• Is my take correct that Call transaction / Batch input is not an option at all or does this depend on the module and already known simplifications?
• How can we find SAP-approved alternatives to the hard updates, meaning where can we look/search for them?
• How dependent on the module impacted is this?
• Can solutions like utilising "RFBIBL00" for FI-input and similar programs still be used or should they be avoided?
• How can updates to Z-fields in append-structures be improved if there's no suitable SAP-provided mechanism?

Right now, I'm not (yet) looking for solutions for individual tables but more for some general tips & tricks of what and where to look for alternatives.

Thanks much and Cheers

Bärbel

[juan_suros]

you have certainly described a big problem. You ask for general advice:

• Plan to move custom code from SSCR key locations into user exits, badis, and enhancements
• Use "where used" function on the tables you are manually updating to find function modules in the SAP library. Look for "BAPI" in the function module names, but there may be others that are useful to make updates.
• Try to identify scenarios where you could do your business in your modified system by using the standard transactions only. If you can get close to using SAP standard it will be easier to use BADIs, enhancements, and BDC commands to CALL TRANSACTION to get the rest of what you need working.

• Badi LE_SHP_TAB_CUST_OVER activates user data tabs in delivery notes, for instance. You could add and maintain custom fields using something like this.

Good luck.

[Sandra_Rossi]

I don't see how upgrading to S/4HANA is different from previous upgrades. You'll have to test everything, especially parts with custom code. But probably most of custom code will remain functional, so I don't think it's worth rewriting everything. Maybe it's time to automate your tests (if not already done, with focus on custom code) before upgrading, and repeat the tests after upgrading.

[BaerbelWinkler]

sandra.rossi

Hi Sandra,

my understanding is that going to S/4HANA is not an upgrade but a complete system conversion so not really comparable to earlier upgrades. Reason for this are all the simplifications applied where for example tables currently used no longer exist so if you currently do an update on one of these tables, this will no longer technically work under S/4HANA. We would like to get rid of these updates now while still on NW750 but ideally in such a way that we won't have to change it again once we convert to S/4HANA.

[Sandra_Rossi]

Some tables were changed a lot (BSEG, ACDOCA...) but most of them were not, and the ABAP code remained mostly unchanged. Honestly, I didn't perform any conversion, but it's my impression when looking at S/4HANA. I'm looking forward to answers of experienced people.

[matt]

It is definitely a migration, not an upgrade. This is causing SAP some headaches, as some customers are thinking that if they have to do a migration anyway, then they can explore other offerings,

[jack_graus2]

Hello

I did a ECC to S/4HANA conversion. Most customer developments have been redesigned for S/4HANA. This to optimize it for the up-to-date business requirements and also to optimize for S/4HANA. However, most of the customer developments in ECC will still work in S/4HANA. Most of the ECC logic is stil available in S/4HANA.

On using batch input: Also this will continue to work with no or little modification as most ECC screens are also available in S/4HAHA. However in general I avoid batch input as the correct (screen) processing is very dependent on configuration and as of so very error prone. S/4HANA offers other possibilities for updating data like ODATA and / or BOPT.

On using Z fields in append structure: We did use this in ECC and do use this in S/4HANA. Mainly for standard SAP tables. Most business document or master data transactions have an enhancement available for filling in these fields with own logic. When doing so in most of the cases the updating of these fields, the change logging, ... is handled by standard SAP without any additional programming. Only field logic and screen processing is to be programmed.

Regards Jack