Authorization for single cost center

[Former Member]

Hi,

I got the request to authorize single cost ceter to users. We have got many cost centers and even with the concept of responcibility areas it is not possible for us to reduce the huge number of roles.

Does anyone have an idea solving this problen? Has anybody tried to use customer exits and customer coding?

Thanks a lot!

Zidu

[andrea_brusarestelletti]

Hello,

you could use derived roles to manage quickly many different roles whose only difference is the Cost center in the proper authorization object, beside running a standard SAP report which promotes a specific field to "Organizational level", so that you can manage it by the "Organizational levels tab" in role maintenance.

I don't know if there are user exit that you can use to perform the check you requires.

Best regards,

Andrea

[Former Member]

Hello Andrea,

Thank you very much for your answer.

We could maintance cost center via "organizational level " but in this case the huge number of roles will still remain. Please keep in mind that single cost center shall only be given to exact defined users. Granting any cost center to any user must be possible.

Cheers, Zidu

[Former Member]

>

> Does anyone have an idea solving this problen? Has anybody tried to use customer exits and customer coding?
> Zidu

Hi Zidu,

I have used this at a previous client but in R/3 I really would not recommend it. The amount of structural change to many transactions will take many months of development time to achieve.

In this sort of situation I would consider looking at the value or enabler role concept where you have your cost centre access separate from your functional roles. You could automate the assignment using some custom logic and one of the user management BAPI's.

[Former Member]

To add a bit to Andrea's and Alex's comments, you can also have a template role which you download and then use Excel to replicate it for each cost center and include the number in the roles name. Then upload again.

Some things to consider:

- If not all cost center names have the same length, then use leading zeros for the role name generation.

- For central or important functions who may have a * for the cost centers or a wildcard / range, build this into their functional role anyway. Appart from the maintenance, you are also limited to max. 312 profiles per user and will reach this quickly.

- When you make a change, always load all roles again and protect the version management of the Excel tool.

You can alternately also consider moving the lot over to a BW system, and load the analysis authorizations from an even easier template and possibly more timely data source.

Cheers,

Julius

[Former Member]

Variables via analysis auths are definitely the way to go for the reporting.

From an accounting perspective CO auths are never going to be as important as FI auths yet many companies organise their business along CO lines. Personally I think it's a bit of a cop out from SAP that they have not delivered a really robust auth model in this area, unlike the rest of the core modules.

[Former Member]

Some reasons which I see for this are:

- Controlling is a 2nd class citizen to the modules it is controlling. They got their concepts in first and now fitting controlling concepts to it is a hassle.

- Customers differ widely in their confidentiallity views of cost centers and the quality of the master data and cost center conventions was not always thought of in advance.

- Historically, many companies have had a central G/L department where the controllers would send their journal entries for accruals, adjustments, etc to. So both the CO and the FI side were set up without considering each other. Then the controllers were trained on FB50 and the assumptions fell apart.

etc.

For sure it belongs in BW. Recommendations from SAP to use the planning option there are regularly made, so if you choose the ECC backend system for it and find some transaction is not CO conform with what you want to achieve, then I don't see much chance of an enthusiastic "cop in" from SAP.

Just guess-work and personal observations

Cheers,

Julius

[Former Member]

Unfortunately this goes beyond naming conventions and adequate stewardship of costs, the actual implementation of the concept is reminiscent of a large block of Emmental ;-). The Professional Services implementations of SAP jump through a whole load of hoops to protect this data, much of which wouldn't be required if the concept was sufficient to rest

Offering an add-on in an additional system solves the problem for a minority of customers who decide they use a workaround, not much good for those who don't want the extra complexity or expense.

Unfortunately CO lacks consistency and standardisation that is present in most other mainstream modules (we can excuse PS ). Even recently, taking the New G/L as an example, it was released with a lack of basic working security. The subsequent scramble to get the security working (on the CO side) did not do anyone any favours, especially the poor souls at OSS who were flooded with notes.

[Former Member]

>

> ... (we can excuse PS  ). 

Gosh: you are being generous! I am not about to excuse anything, not PS, not CS, PM, QM, not WM ... take CS for example: what kind of concept is it to have to authorise the transaction code repeatedly in every object and then again in S_TCD?

And don't get me started on the Enjoy-transactions.

At least, in CO (CO-PA) there are 'visible efforts' to improve the security!

[Former Member]

> And don't get me started on the Enjoy-transactions.

I reckon your gravestone will read "killed by MIGO"

[Former Member]

> > And don't get me started on the Enjoy-transactions.

Are you having SHD0 problems with them?

Cheers,

Julius