This website is not affiliated with, sponsored by, or approved by SAP AG.
9 posts • Page 1 of 1
I have some eerie issue with C_STUE_WRK. Whilst the user has the following authorisations with this object:
when running CS11 we're always getting the error: not authorised blah blah, with the SU53 showing in missing objects
and in objects available: exactly the same!
I have been running a trace (ST01), it comes back with a returncode 4 on C_STUE_WRK, 03,2010. I checked the role - it's active generated and present in the user-buffer.
The trace doesn't hint at any murky user-exit or anything. Checking SMP notes revealed a couple of notes like 656868 describing the just the other way round of what I need, nothing else came up.
Anybody any ideas? Ever run into this? Oh, and this is ERP 5.0, NW640/SP1 (yes, it's ancient).
I've seen something similar in a WM auth object a while back. If I remember correctly it was a bug in the coding for the auth-check on the activity and the only way around it was *. That doesn't explain why there is a RC4 when the auths are buffered though.
Is this repeatable in a non-prod environment? if you have a role with only C_STUE_WRK 03/2010 (so not including the 1000 plant) does it still fail?
I'm quite the lucky chick - it's reproducible (word?) in every system in that particular landscape. And yes, it throws the same error when the object only has 2010 for CSWRK. I don't trust myself, so I double-checked on UST12 and USBRF2 again. Everything is, as it should be.
Next step: debugging MC29LIE1.
Allright. *throws arms into the air* I give up.
I added a debug-authorisation (just a role with object s_program, debug, all activities) to the userID in question and went on my merry way to debugging in the QA-system. There are only 3 parts in MC29LIE1 concerning said object. I passed the first, everything o.k. - at the second it was asking specifically for CSWRK = ' ' (two blanks!! two!). This is where the RC=4 comes from. This should be reset as soon as I come to the third auth-check. But it isn't!! The third bit is passed with everything o.k., but the returncode stays on!
So, this dumb thing is asking me to give authorisation to CSWKR = blankblank. That's downright BS. I went in search of notes again, but either I have lost all my skills at google-fu or there simply isn't any note. The interesting bit: if I replace 2010 and/or 1000 with '*' it passes, even though I should have a blankblank in there. But then, I'm no abapper, so maybe I missed something there ...
This cannot be - hundreds of thousands of people must have experienced said error!But there's nothing on SDN or SMP or someplace else ... how can that be?
How am I to authorise blankblank when there is a table behind the field that checks on valid entries?
I'm going to insert blankblank using SE16N to have a workaround and open a call with SAP for a proper solution.
I'm glad you found the root cause, definitely sounds like a fix for SAP to implement. What was the transaction? As you said, I would have expected more people to have picked this up. It's not like full auths are usually granted for stuff with BOM's (assume that's what it is?).
I've seen this problem before, and the only way around it - except table hacking and code change - is to assign *. Not an ideal, or for many people even possible solution.
It does happen in some of the "old" transactions. Thought most of it had been cleaned up by now...
I ran into this years ago with object C_DRAW_TCD. I could not create a role with 'space' as the document type because it was validated, but I was able to create a profile the old way in SU02 with the space value in DOKAR.
This was on a 3.x system so I have no idea if it is still possible - I have no access to SUxx transactions on my current gig.
Yes, it's in one of the 'old' transactions, CS11-13. No, it hasn't been cleaned up.
I have been testing this on a ERP 6.0 SR3 (quite new!), same shit, different day.
So, it's one of both: nobody else but me has the challenge to keep BOMs of one plant out of the sight (and the hands) of people of the other plant(s) (exception: CO, they have to look at the calculation data of combinations of plants)!!
How likely is that?
Or are people just not talking, simply hack tables or modify code to avoid the subject?
Opened call at SMP. Will come back with news (if there are any).
9 posts • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 8 guests