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:
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.
