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

[Former Member]

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?

Cheers,

Julius

[m_coenjaerts]

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

[Former Member]

Hi Marc,

Thanks for stretching your memory all the way back to 46C for me...  😉

Yep, it looks like the process you followed is the one which SAP left us with. But I don't want to run programs which change SU24 and Roles and config in PROD... something tells me that is not a good idea.

My problem is that someone accidenturely promoted all fields they wanted a * in to org.levels so that the auths are all standard. These are were now mostly "Changed" status and SU24 broken. Seems like they went to ADM940 but were not listening all the time...

So, it being a Sunday yesterday, I eventually fixed it so that I could test before the users arrive on Monday morning:

• Run PFCG_ORGFIELD_DELETE for the fields which converts USRORG, USVAR, SU24 and affected PFCG roles and sets the auths tab to "red".
• Create a workbench Transport with R3TR/TABU/USORG/USVAR/USVART table contents and keys = * -> transport it through to QAS and PROD.
• Run SU25 step 2b to find fields which had been maintained which do not relate to this org.field fiasco.
• Run SU25 step 2c to find and convert the roles which are affected AND we still want to keep them (re are rebuilding all the roles anyway).
• Run SU25 step 3 and transport all SU24 data through the landscapes to sync the proposals.
• Transport at the end all roles which are affected and need to be kept through the landscapes.
• Other roles will correct themselves if we ever have to do maintenance on them before they are replaced completely anyway.

So this was my solution, but I would still be interested if someone has a better approach or whether there is an official way to correctly do this?

Cheers,

Julius

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

Cheers,

Julius