Cost Centre Auth: K_REPO_CCA & RESPAREA

[Former Member]

Hi,

1. Have read it at more than one place that K_REPO_CCA is obsolete. Can anyone please help me in understanding what exactly that means? Does that mean we simply deactivate this object in the tcodes calling it or may be just give all fileds * in all the roles?

2. Also I wonder what can be the scnearios where RESPAREA isn't changed to an Org. level? Shouldn't this actually be made an org level by default as always there are cases when many roles or users within the same plant just differ at this field level only. Have seen cases where it has been kept as non-org filed and maintained in the derived roles but it will simnply be washed off with 1 push from the masters. In othe scenarios where again this is kept as non-org filed only but K_CCA disabled in all roles but maintained in 100s of enabler roles and thus assigned to diff users which could have been avoided had it been made as org level in the first place. So I wonder why shouldn't RESPAREA be an org level field by default or why shouldn't all change it to an org level?

Explored all accessible sources of info but didn't get a breakthrough so far so finally throwing it open to the experienced fellows at SDN.

Rgds,

Gill

[Former Member]

Hi

1. SAP Note 1490793 talks about K_REPO_CCA and it being obsolete. If not required I would maintain SU24 appropriately to ensure that it is not pulled into roles.

2. I have yet to work on an implementation where it has been required to keep RESPAREA as a field value rather than promoting to an org level. After a design phase I usually switch it to an org level, though that is as a result of the design rather than doing it for the sake of it. Lots of people either don't know about or are scared of creating org levels which would explain why this isn't done more frequently. RESPAREA also needs special treatment which is explained in SAP Note 698401

[Former Member]

Unfortunately it is not that clear cut...

For reporting you need to give full access to the old objects for the reporting activities only.

For master data you need to remove the activities as only the new objects ( K_CSKS* ) are sufficient.

Authoritive is SAP Note 370082 as far as I know. It is certainly reflected in the coding. It also makes sense to check transaction AUTH_SWITCH_OBJECTS for globally deactivated objects in this case, as some consultants recommended this solution to remain downward compatible way back when...

Cheers,

Julius

[Former Member]

I'll take your word for it. The last CO stuff I did was wrestling with K_ORDER and one of the F_FAGL* objects!

[Former Member]

Within the RESPOAREA you have three levels (the trace will also bug you).

The best simplification is central master data maintenance and then only use the standard hierarchy and not use the old objects any more.

The migration path is more complex as you need to switch the roles as you go along considering the activity dependencies and hopefully no "role surfing" from "value roles".

If the role design is considerate of this sort of upgrade changes, then it is easy and can be done in 1 day. Typically it is not...

Cheers,

Julius

Edited by: Julius Bussche on Jul 7, 2011 12:14 AM

[Former Member]

Alex, thanks for the note.

About RESPAREA, How feasible is it to make it as an org level now when I already have a global temp. in hand where it's not an org level and we have some countires already live using it and few more planned next year.

Thank, Gill

[Former Member]

Hi,

It's perfectly feasible I've done it in systems with 20,000+ roles previously. In a dev environment run PFCG_ORGFIELD_CREATE in TEST mode and it will tell you what changes are made and what roles need attention etc. The only bit you need to be careful of is the migration to prod. You will get transport problems if you try to transport roles into environments which do not have the org level configured.

If you do not have the luxury of some downtime, you could try look at something similar to the following approach

1. Make sure there is a backup of all roles & profiles

2. Run program in dev. Configure KBEROBJ. Mass regen (SUPC) and perform any manual updates, sample testing etc.

3. Create your transports

4. Run program in QA. Configure KBEROBJ. Mass regen (you could skip this step if you have no-one working in QA), import transports from Dev

5. Repeat above for Production. Do it at a quiet time, do the regen and then import transports. If you have complete downtime then OK to skip regen.