cancel
Showing results for 
Search instead for 
Did you mean: 

Excluding of organisation in REQUESTER attribute of PPOSA_BBP

JacobDK
Explorer
0 Kudos

We are running SRM server 5.0 EBP 4.0.

I have a question concerning the REQUESTER attribute of PPOSA_BBP.

For example if we have an organization structure like this:

ORG3 belongs to ORG2 and ORG2 belongs to ORG1 that is: ORG1 -> ORG2 -> ORG3

In ORG1 we have 10 employees, ORG2 15 employees and ORG3 25 employees. We would like all employees of ORG1 to be able to do purchasing for each other. There for we maintain the attribute REQUESTER of ORG1 on organization level: value O ID_ON_ORG1.

But now the employees of ORG1 also gain access to do purchasing for all the employees of ORG2 and ORG3. To prevent this we maintain another value to the attribute REQUESTER of ORG1 on organization level: value O ID_ON_ORG2 and mark it as EXCLUDED.

But the result is the same

If we fill in single users the excluding works just fine.

How is this designed to work? And how should we obtain our goal?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

You can implement the BADI BBP_F4_READ_ON_ENTRY for your problem.

Regards

Kathirvel

JacobDK
Explorer
0 Kudos

Hi

Thank you for your response.

But is it standard behavior that you canu2019t exclude organizations the way I describe?

Former Member
0 Kudos

I would have assumed the same way that you have. If you exclude the Org unit, it shouldn't be shown. Maybe it's worth opening an OSS message for that, be prepared for a 'works as designed' answer though... Maybe I'll have some time tomorrow to see how it works and if it only checks the position for exclusion.

For what it's worth: restricing the PO list is done using the BBP_WF_LIST badi if I'm not mistaken. In our company we created an additional attribute in the organisational model and checked against that to determine which orders a user could see.

Regards,

Robin

JacobDK
Explorer
0 Kudos

OSS answer is as you expected "works as designed"

OSS SOLUTION:

To work around this problem, I advise that you maintain the requester attribute using a mixture of orgs and users.

Hmmm, we might then copy your idea and create an additional attribute in the organisational model.

Thank you all for your time!

Answers (0)