K_REPO_CCA

[Blaster]

Hi,

Could someone please shed some light on the use of object K_REPO_CCA?

When running transaction code FAGLL03 I can see in a trace that in a few instances there is a check for K_REPO_CCA. This object should be obsolete so I do not know why this is still checked and what is special for the line items that invokes this check. It is very rarely that it is checked in the trace.

Can K_REPO_CCA be deactivated altogether and fully replaced by K_CCA or is it still needed for some legacy SAP code that has not been changed to the "new" RESPAREA?

[thx4allthefish]

Have you checked it in report RSUSR060OBJ? That's basically a where-used-list of authorisation objects in ... whatever (programs, classes ...).

I just ran it agains a NW640 ERP 5.0 ... used in

FK21RC02
FK21RE14
LFCINU44
LKBERF15

(all reports)

In a NW 7.0/ERP 6.0 still used in:

LKBERF15

You might nonetheless check for yourself, in case your have EHPs or something. Personally I wouldn't deactivate it completely, but consider adjusting SU24 for the affected transactions.

[Blaster]

Yes I have checked the where-used list.

My issue is why some documents/line items comes up with a check on K_REPO_CCA.

The vast majority of the checks in FAGLL03 are performed on K_PCA as expected.

A few are checked on cost centers though, and it looks like this is direct CO postings that have not been sourced from FI. This is actually also okay, but somehow the one leg posting is checked for K_CCA but the other leg is checked for K_REPO_CCA. I do not want to use K_REPO_CCA for this since I want to benefit from the hierarchy instead of maintaining all the specific cost centers.

It looks like I am fine by giving full access to KOSTL in K_REPO_CCA, for reporting at least, but I am not that comfortable about this approach since KOSTL is an organizational level here and is used in other objects as well and I cannot foresee the implications in other areas.

How do you guys go about restricting K_REPO_CCA/field KOSTL when it is an organizational level?

[GENCO]

Hi Blaster,

Did you manage to get answer to this query? This is similar to what I am facing and unable to get any sort of help / inputs from anywhere, I wonder if you got the breakthorugh and are ready to help me?

Rgds,
Genco

[jvroom29]

Not sure this will be helpful but there are several SAP security notes on Service Marketplace that talk about K_REPO_CCA. They are 15211 and 1490793. Note 15211 has some information regarding how to set the values in the "obsolete" objects to work with the new K_CCA object. According to the note:

As of Release 4.0A, you can choose between the new and the old authorization check for each area (cost centers, internal orders). The simultaneous use of the old and the new authorization check within one area is not possible. For the authorization check you do NOT want to use, all authorizations (*) for the corresponding authorization objects must be assigned to the users.
If you do not want to use the new logic, do not make any changes for the time being, since all authorization for the new objects is contained in the SAP_NEW_40A profile.

If this sounds like it might address your issue there is a lot more information in SAP Note 15211. Hope this helps!

[os]

The check will still appear in the trace and pester you in SU53 (because of the downward compatibility explained in the notes).

If you only want to use the new concept, then you must authority K_REPO_CCA and OPA with * for 27, 28 and 29.

The last check for K_CCA in the trace / SU53 will also be the root node of the hierarchy - which is expected because of the way the checks are built.

Note that for master data and planing activities it is different. The checks are alternate.