FB03 Document Relationship Browser Authorisation Issue

[Former Member]

We have recently upgraded our ECC 6.0 system to EHP4. After EHP4

installation we are facing a peculiar issue.

We have 2 user ids, with same authorisation, the below screen works for

one id and doesn't work for the other id.

Replication Steps:

-

---

Tcode > FB03

Doc No : 2503375271

Com Code : US50

Fiscal Yr : 2010

From the top menu > Environment > Document Env > Relationship Browser

In the next screen, you could see the sub tree Accounting document >

CustIndivBillingDoc>...>

Although both the above ids has the same authorisation, it behaves

differenly only for the above tcodes.

But however, if you create a new user id with the same authorisation,

it works.

Can you please help us to resolve this error, asap

[Former Member]

9 times out of 10 it is a PID.

Other possibilities are that the other users have additional "roles" required to complete this step successfully.

This is one of the buggers with users having many roles assigned, or using composite roles even (which subsequently grow larger and larger in their single assignment).

Cheers,

Julius

[Former Member]

Julius,

We have compared both the roles /profiles/parameters they are exactly the same.

Can u pl help us with the steps to resolve this issue?

Regards

[Former Member]

A reference user (check USREFUS) to add the authority or an exit / validation rule with a table of "excluded users" for whom this is not allowed? The latter would be consistent with what you have described above.

Cheers,

Julius

Edited by: Julius Bussche on Aug 30, 2009 10:40 PM

[Former Member]

Hi Julius,

I faced a similar issue but we havent upgraded. There were 2 users having same set of authorizations. But one was able to see the Tcode in his menu and other could not.

But when we copied his authorizations to dummy id, everything was fine. We were able to see the Tcode in Menu. We simply deleted the old id and replaced with the new one.

Not sure if it was the best possible option but it solved the issue.

Regards,

Rajesh

Edited by: Rajesh Nanda on Aug 31, 2009 5:13 PM

[Former Member]

Checking table USERS_SSM would be a good start, but this case here seems a different topic to me.

Cheers,

Julius