05-31-2019 1:16 PM
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:
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
06-01-2019 12:06 AM
you have certainly described a big problem. You ask for general advice:
Good luck.
06-01-2019 7:51 AM
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.
06-01-2019 9:08 AM
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.
06-01-2019 9:28 AM
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.
06-01-2019 1:40 PM
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,
06-03-2019 7:18 AM
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