De uitdaging om maatwerk naar S/4 HANA mee te nemen

Vandaag een blog waarin wij u uitdagen uw kostbare maatwerk in SAP ECC niet af te schrijven, maar mee te nemen naar S/4 HANA.
We gaan er daarbij vanuit dat u maximaal gebruik wilt en kunt maken van de voordelen die de nieuwe technieken u bieden.

Er zijn meerdere paden, al dan niet met side-by-side development op SAP Cloud Platform of andere oplossingen als low-code. Deze blog beperkt zich tot migratie van ABAP-maatwerk naar een S/4 HANA On-Premise als ‘to be’ situatie

S/4 HANA Custom Code Conversion Technical Challenges

Al in 2015 kwam de eerste release van SAP S/4 HANA uit en kwam een einde van de ondersteuning in zicht voor de SAP Business Suite per 2025. Onder druk van de SAP-gebruikers is deze deadline opgeschoven naar 2030. Daarna stopt de Extended Maintenance.

Deze nieuwe deadline biedt SAP-gebruikers als voordeel meer tijd en daarmee meer mogelijkheden om bestaande applicaties te migreren naar het nieuwe platform. Dit heeft als nadeel dat nieuwe innovaties die SAP uitsluitend voor S/4 ontwikkelt voor de klant dus ook worden uitgesteld.

S/4 HANA is niet zomaar een update van ERP 6.0 naar een in-memory database. Het is een totaal nieuw product met een aantal fundamentele wijzigingen:

• SAP GUI transactions zijn vervangen door Fiori toepassingen.
• SAP Functionaliteit is geïmplementeerd in het Simplified Datamodel om hun overwoekerde datamodel te vereenvoudigen.
• Niet (meer) relevante functionaliteit is of herzien of heeft geen plaats meer in S/4
• Specifieke aanpassingen, zoals bijvoorbeeld verlenging van de artikelcode (MATNR)
• De HANA-database brengt de power voor online processing, maar verwacht andere programmeertechnieken, zoals bijvoorbeeld Code Push Down.

Duidelijk is dat S/4 HANA veel mogelijkheden en kansen biedt, maar dat daar wel iets voor moet worden gedaan.

1. Fiori Launchpad als vervanging van SAP GUI

In de S/4 On-Premise omgeving werken de meeste transacties nog wel in meer of mindere mate, maar zijn overbodig[1] en niet bedoeld voor eindgebruikers. Als er maatwerk op transactieniveau is geïmplementeerd, moet u de functionaliteit mogelijk toevoegen aan de vervangende Fiori-applicatie.

2. Simplified Datamodel

Traditionele modules zijn opnieuw ontworpen om een beter gebruik te maken van de nieuwe HANA-database en om het complexe datamodel te vereenvoudigen. Dit is gegroeid in de jaren dat SAP nieuwe functies aan de ERP heeft toegevoegd.

Een voorbeeld is de SD-module, het volledige datamodel is sterk vereenvoudigd[2] op basis van 2 scenario's:

• Overtollige tabellen die als hoofddoel hadden de leessnelheid tot specifieke gegevens te verhogen, zijn verwijderd omdat HANA DB ze verouderd maakt.
• Tabellen waarvan de gegevens kunnen worden opgeslagen in een andere bestaande tabel zijn verwijderd en hun velden zijn toegevoegd aan de respectievelijke tabellen. In sommige gevallen worden nieuwe documenttypes gegenereerd.

[1] See for instance the MM module obsolete transactions: https://help.sap.com/doc/0080a18cdc1045638d31c87b839011e7/1909.000/en-US/SIMPL_OP1909.pdf#page=425

[2] SD module model simplification: https://blogs.sap.com/2016/07/03/sap-s4-hana-simplifications-in-sales-distribution-data-models/ (see also note 2267306)

Een specifiek voorbeeld is de VBUK-tabel met de status van de verkooporder in ECC. Deze tabel bestaat nog steeds in S/4 HANA, maar wordt niet meer ingevuld met gegevens wanneer een verkooporder wordt aangemaakt of gewijzigd. Het is nog niet verwijderd omdat enkele standaard functiemodules nog steeds de structuur gebruiken.

In het nieuwe model veroorzaakt ABAP mogelijk geen fout omdat de tabel nog steeds bestaat, maar retourneert deze niet de verwachte gegevens, als uw ABAP-maatwerk gegevens selecteert uit de VBUK-tabel. Om uw maatwerkcode aan te passen, biedt SAP specifieke instructies onder de naam “cookbooks” voor elke Simplification en alle implicaties. Voor de VBUK-tabel is het kookboek te vinden als bijlage in de note 2198647.

Naast het aanpassen van uw eigen code, als u een append-structuur in de VBUK heeft gemaakt, moet u de velden toevoegen aan de overeenkomstige tabel voor het relevante documenttype: VBAK, LIKP, of VBRK. Pas tenslotte de code aan waar de append-structuur wordt gebruikt.

3. Verouderde functionaliteit

Gedurende vele jaren en releases heeft SAP meerdere oplossingen geleverd voor dezelfde functionele gebieden. Met het nieuwe S/4 product zijn echter veel van deze duplicaten verwijderd of gemarkeerd als verouderd, maar het is mogelijk dat uw ABAP maatwerk er nog steeds gebruik van maakt.

Zo is de Credit Control module voor Sales and Distribution niet meer beschikbaar en moet u in plaats daarvan SAP Credit Management gebruiken. Een ander voorbeeld zijn de industry specifieke objecten die aanwezig waren in SAP ERP en niet beschikbaar zullen zijn in S/4 HANA.

Zelfs als de API's van deze verouderde modules niet worden gebruikt door uw ABAP code, is het mogelijk dat ontwikkelaars die de best-practices van weleer probeerden te volgen, gegevenselementen of structuren hergebruikten om het maken van nieuwe custom objecten waar mogelijk te vermijden. In ieder geval moet alle code waarin de verwijderde of verouderde objecten zijn gebruikt, worden aangepast volgens SAP-aanbevelingen.

4.HANA DB

Zoals de naam aangeeft, is S/4 HANA ontworpen om uitsluitend op de in-memory HANA-database te worden uitgevoerd. Om ervoor te zorgen dat uw ABAP maatwerk goed blijft werken en deze te optimaliseren voor de nieuwe HANA DB, moeten enkele verplichte aanpassingen worden doorgevoerd.

** Hoewel SAP ERP 6.0 niet is ontworpen om alle kracht van HANA DB te gebruiken, zal het systeem beter presteren wanneer de code is ontwikkeld met de nieuwe DB in gedachten. Daarom beginnen de meeste klanten met het vervangen van hun SAP ERP SQL database door de HANA-database.

Het doel van deze blog is niet om technische aanpassingen te bieden die u zullen helpen om de prestaties van selecties voor HANA DB te corrigeren en te optimaliseren, maar alleen om erop te wijzen dat er verplichte wijzigingen zijn in uw ABAP-code voor uw overgang naar S/4 HANA.

Bezoek de volgende blogs voor meer informatie over dit onderwerp:

• ABAP custom code adaptation for SAP HANA – The efficient way

• ABAP custom code adaptation for SAP HANA DB migration

Om de HANA-specifieke problemen in uw code te identificeren, heeft SAP een aantal Code Inspector varianten voorzien, genaamd FUNCTIONAL_DB en FUNCTIONAL_DB_ADDITION, die kunnen helpen om al uw custom code te scannen en de punten te identificeren waarin deze moet worden gecorrigeerd. Naast de prestatieaanbevelingen, zijn de twee belangrijkste problemen die onmiddellijk moeten worden aangepast, de specifieke databasecode en de verwachte impliciete sortering op primaire sleutel.

5. Veranderingen in veldlengte en gelijkaardige functionele aanpassingen

Waarschijnlijk de meest bekende technische wijziging in S/4 HANA is de verlengde lengte van het materiaalnummer van 18 tot 40 tekens. Een andere soortgelijke wijziging is de verlengde lengte voor alle valutavelden tot 23 met 2 decimalen.

Als de ontwikkelaar in deze gevallen custom types in de code of in de Data Dictionary heeft gebruikt, kan de toewijzing onjuist zijn. Het onderstaande voorbeeld is erg simplistisch, maar het illustreert het probleem van het gebruik van custom gegevenstypen voor een materiaalnummer.

Conclusie

De migratie naar S/4 HANA brengt meerdere technische uitdagingen met zich mee die de aanpassing van uw ABAP-maatwerk vereisen. Sommige van de benodigde wijzigingen kunnen al worden geïmplementeerd in uw huidige SAP ERP-omgeving, zelfs voordat u uw migratie naar S/4 overweegt.

Bij Oliver IT kunnen we u helpen met de analyse, voorbereiding en uitvoering van uw SAP-systeem upgrade. Neem contact met ons op om uw roadmap te bespreken en het beste advies van onze technische experts te krijgen.