cancel
Showing results for 
Search instead for 
Did you mean: 

Error in creating Dispute case

Former Member
0 Kudos

Hello Experts,

i got this error in su53

Evaluation of Last Failed Authorization Check of User KHPSAROM

Description Authorization values

User Name KHPSAROM Authorization Object CPE_SETTIN

System FCP Client 400

Date 15.10.2010 Time 13:34:30

Instnce fghsrv014 Profile Parameter auth/new buffering 4

Authorization check failed

Object Class AAAB Cross-application Authorization Objects

Authorization Obj. CPE_SETTIN Commodity Pricing Engine: General Settings

Authorization Field ACTVT Activity

03

User's Authorization Data KHPSAROM

Object Class AAAB Cross-application Authorization Objects

Authorization Object CPE_SETTIN Commodity Pricing Engine: General Settings

Authorizat. T-FD96017500 Commodity Pricing Engine: General Settings

Profl. T-FD960175 Profile for role Z:ROLE_AR_ARACC

Role Z:ROLE_AR_ARACC

Authorization Field ACTVT Activity

03

User cannot create dispute case

try to solve it

Thanks and regards

Dhaval Thaker

Accepted Solutions (0)

Answers (1)

Answers (1)

sunny_pahuja2
Active Contributor
0 Kudos

Hi,

> Authorization check failed

> Object Class AAAB Cross-application Authorization Objects

> Authorization Obj. CPE_SETTIN Commodity Pricing Engine: General Settings

> Authorization Field ACTVT Activity

> 03

> User's Authorization Data KHPSAROM

> Object Class AAAB Cross-application Authorization Objects

> Authorization Object CPE_SETTIN Commodity Pricing Engine: General Settings

> Authorizat. T-FD96017500 Commodity Pricing Engine: General Settings

> Profl. T-FD960175 Profile for role Z:ROLE_AR_ARACC

> Role Z:ROLE_AR_ARACC

> Authorization Field ACTVT Activity

> 03

>

User has missing authorization which is shown in SU53 data. Assign the missing authorization then it will work.

Thanks

Sunny

Former Member
0 Kudos

I believe what Dhaval is getting at is that the authorization object and value that is being reported is the same authorization object and value that it is returning in the SU53 as being assigned which is causing the confusion.

We see this in our systems from time to time, usually after transporting the role into a system.

Some things to check:

1. Have the user reset their user buffer (from the SU53 screen menu path Authorization Values > Reset User Buffer)

2. Make sure the role is properly generated

3. Make sure the role is not end dated in the user account (I don't think it would show in the SU53 if it was but hey! you never know)

And this is way out from left field but I actually had this happen to me a week or two ago - double check the role and make sure that authorization is actually there. I had one pop where it showed an authorization that was an old version of the role but not in the current version.

Cheers

Melissa

Former Member
0 Kudos

To disspell any doubts, SU53 shows the last failed auth check which the user invoked in a program, immediately before executing Su53. It is not necessarily the correct one to assign!

> And this is way out from left field but I actually had this happen to me a week or two ago - double check the role and make sure that authorization is actually there. I had one pop where it showed an authorization that was an old version of the role but not in the current version.

>

I assume by this that you are referring to profile name collisions. This has two common causes:

The SID ID's of PROD, QAS and DEV etc systems all have the same identical characters in the 1st and the 3rd place. Only these two are used in the generation of the profile name. Search for "AGR_NUM_2" for more infos and options.

Another (IMO more likely possibility) is that which SAP Note 1373111 describes in the reason codes of the FOR USER construct. The check might infact have been performed against a different user ID...

Please run the same with an ST01 trace on and check the reason code (if your kernel release is high enough).

Personally I am rather sceptical about this new mechanism in the wild. The old mechanism via FM AUTHORITY_CHECK at least gave us a where-usd-list and when jumping from the trace to the source it was clear what the developer had intended to do, even if they have already left the building...

Cheers,

Julius