Skip to Content
avatar image
Former Member

Demoting an org-level - what to transport and when to do so

Dear gurus,

I am confronted with a question where it seems there is no answer except trying, so thought it best to see if anyone has done this before...

Background is SAP notes 323817 and 727536 regarding demoting customer org.level fields.

Someone promoted 28 fields to org.levels in a system here. PFCG_ORGFIELD_CREATE has a transport connection, so at the time the USORG and USVAR table entries were also transported through the landscape.

Now I have degraded to the fields to normal fields again using PFCG_ORGFIELD_DELETE, which converts the SU24 and PFCG data and the USORG and USVAR tables, but it does not ask for a transport request...

New roles which include the now "normal fields" can be imported successfully into QAS and PROD systems, and the old roles will clear themselves out and are being completely replaced anyway.

So my question is: should I transport the USORG and USVAR tables through the landscape as well? If yes, then before the roles are transported would seem correct to me, but there is no dialog I can find to add these to a transport request, so I suspect that maybe SAP's intension was simply to leave the data there as "dead wood" in QAS and PROD. The only way I can think of is to manually insert the tables as "table contents" into a workbench transport and send that through  - but that seems a bit suspect to me...

Has anyone done this before? Did you sync the tables in QAS and PROD or just leave them as inconsistent in the landscape?



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Sep 29, 2014 at 07:57 AM

    Hello Julius

    I used it some time ago (that was the 'Z' versions of the reports, such as ZPFCG_ORGFIELD_CREATE, in a 46C system). If my memory service me correctly there were no transport requests generated for the USORG or USVAR tables). So we executed the program in each 'tier' of our landscape. This has been executed several times in our company. In general we do the following:

    1. Run the ORGFIELD program in the DEV system
    2. Adjust and check the authorization roles, including profile generation
    3. put all affected roles in a transport request (or multiple, depending on the number of affected roles)
    4. Run the ORGFIELD program in the QAS system
    5. Import the roles (Transport requests created in step 3).
    6. Verify/Test if the roles are set correctly and if the profiles are generated correctly (one verification step could be using the AGR_1251 and AGR_1252 tables)
    7. Run the ORGFIELD program in the PRD system
    8. Import the roles (Transport requests created in step 3).
    9. Verify if roles are imported correctly, including correct profile generation.

    The USORG/USVAR tables are not transported, but 'cleaned up' in each tier of the landscape.

    I hope this information helps

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Update: I can confirm that it is quite safe to transport USORG and USVAR(T) as table entries and then also run SU25 steps in addition to PFCG_ORGFIELD_DELETE and transport that in step 3.

      The roles in target systems still have profiles assigned and UST12 does not care about orgfields, but the auths tabs are all red. This means that if you ever entered change mode, it will force the read old / merge new option, which is also correct.

      This is OK in my case as the 28 custom orgfields all had a * in them anyway, and the existing roles will soon be replaced by new sets of roles and deleted. We only need to bridge a small time gap where the users don't have the new roles and request something to be done to an old role.

      So transporting the definitions through was correct as exporting them in "old status" does not work anyway, and I need to get my new roles live ASAP (which is not a problem - first users are live already).

      If you however want to salvage the old roles after demoting orgfields and combining it with a release upgrade, then using this table entries solution to transporting is probably not an ideal approach.

      Upgrades are normally a nice opportunity to start over anyway...

      I will leave the thread open for a while still if there are other experiences with this or an official process shows up. But my own problem is solved.