cancel
Showing results for 
Search instead for 
Did you mean: 

S/4HANA system conversion SPDD phase and creation of appends

JaySchwendemann
Active Contributor
0 Kudos

Dear all,

we are in a project to convert our ERP 6.0 EHP 8 to an S4H (2021) system. We currently try to convert our first sandbox without having gone through all SIs in order to gain first knowledge with the conversion process and the like

That being said, we experience the following situation when hitting the SPDD phase (being in a shadow system, obviously)

  • We have tables, where we directly inserted custom (Z) fields
  • SAP suggests / proposes to move that fields into an append as an action in SPDD
  • If we chose so, the system would ask about a Package (it already exists, e.g. Z_MM), but then asks for a lokal transport request

My questions are

  1. Is it ok to create such appends when already in SPDD phase or would we be (much) better off if we dealt with that before the conversion in the ERP system already?
  2. If it is ok to deal with that in SPDD or in case we missed something and an SPDD entry like that will pop up in the next sandbox or in the development system: Is it explainable why the system wanted an local transport request when we tried to create the append in (say) package "Z_MM". That package was there before, obviously. Granted, I did not look at the package myself and it might easily have to do with the kind of system copy we've done to create the unconverted sandbox in the first place and this would not hit us in development system, but I wanted to touch base for this anyways, to gather some insights
  3. If a local transport request is to be expected, how to make sure that the then moved custom fields in the new custom append also being transported into the next system (when time comes and we are on development system). Is there a best practice for such operations?

Kind regards and many thanks

Jens

Accepted Solutions (1)

Accepted Solutions (1)

amontella96
Active Contributor

Hi jens.schwendemann

first of all, if it makes you feel better, those decision do not pertain only the upgrade to s4h but these are normal to make in every upgrade

then let's handle the topic correctly by bullet points as you did :

1) It is ok to create such appends when already in SPDD phase BUT it would we be better if you deal with the migration of those custom fields to appends before the conversion so a) you separate the append change risk from the upgrade itself b)shadow instance step is less time consuming

2) a)if you miss to the migration of those custom fields to appends you'll probably lose the data contained in the sandbox table columns related BUT the popup will prompt again in development (and other) systems upgrade b)regarding the local transport it matters only if you were planning to transport those changes from sandbox to your normal landscape, if you plan to reapply those changes in Development (as per point 1) then don't be bother about sandox packages

3) the transport is local bcz of missing system copy post activities, in development it should not be local and if this happens you have to change the settings of the package about original system = your development

And thats it , WOW that was a long one... hope you like it and hit the button answered! cheers!A

JaySchwendemann
Active Contributor

Hi amontella96 ,

thanks for reaching out and for the lengthy answer 🙂 I try to put in our (new) findings here too

About 1)

The funny thing was, that requesting an append not only was true for tables, where we directly added custom fields to the table but also was the case for customer includes to standard tables. So even when being in an include SPDD wants you to extract the data to an append.

About 2 and 3)

Indeed with some further digging we found the reason for the transport to be a local transport in the way we did the system copy. The Package (here "Z_MM") had a Transport Layer "ZDEV" where it should have "ZSBX" because there is no transport route to "ZDEV" in a Sandbox system obviously. We then had two choices: Change the transport layer for [all? | the needed?] packages to "ZSBX" or maintain a route for "ZDEV" also. We opted for the latter. We did this in Shadow System as we already hit SPDD and this was a sandbox anyway. For next Sandbox we will switch the transportation layer of the packes to the new one as part of the post-system-copy-process before we start S4H conversion

Answers (0)