Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

ORG values for parameters not set in configuration

Former Member
0 Kudos

Hi All,

We are creating parent / child roles for FICO & MM for a project. The business requirement / configuration is such that the org values are available only for Company code and Purchasing organization. What is the appropriate way to set this up in the child roles? For e.g. should we put in * for plant , purchasing group etc or leave it BLANK

Please provide your comments

Thanks in advance

Vijaya

6 REPLIES 6

Former Member
0 Kudos

Hi

FI relies on company codes (mainly) and MM relies on plant, Porg etc (again - mainly) but, without all the other objects being filled in your roles won't work.

It depends on your client's needs I suppose but it does sound a little open to me but each set up has their own design requirements, you'll have to put * in the rest of the very many org levels (and cost centres, release strategies, etc - too many to mention at org/object) if you aren't given the information either due to lack of knowledge by the functional guys (not likely, hopefully) or a top down 'do what I say approach'.

I'd get the spec in an email from somebody responsible for the implementation from the business and save it for the auditors...

Cheers

David

0 Kudos

I'd get the spec in an email from somebody responsible for the implementation...

I faintly suspect that Vijaya is never going to follow-up on this (like 6 out of 7 other questions...) or we will next see the full spec posted for us to solve...

To prefent this, I would suggest that Vijaya organizes a meeting with the business folks and makes it an online tele-conference for us to dial into as well...

Cheers,

Julius

Former Member
0 Kudos

Hi Vijaya,

I agree with David, ignoring the values will mean your roles won't work. If you put in * values then you need to be 100% sure that there are no control requirements over that data (data visibility, segregation of business units etc).

If there are no control requirements and you want to use * then think through the implications of people using any org level that they choose.

A "halfway" approach would be to get a copy of the enterprise structure for your implementation and use that to provide the detail to list key org elements e.g. all the plants assigned to a specific company code.

0 Kudos

@ Alex

Good call on getting the company - plant - sales org - purch - org etc data and at least populating the org levels with those values (say from T00* ) which would go a fair bit towards showing you had at least tried to create roles with the business model in mind - thank you.

Cheers

David

0 Kudos

The only problem i see with functionally dependent retrictions (i.e. for example defining restrictions on company code and leaving the plant values as * since the plants are dependent on the company code up the hierarchy) is that mid way through say after implementation if the organization decides to go in restrictions at the lower level in the hierarchy rather than up the order, i have seen this happen with one of my clients and it needed a lot of re work.

Regards,

Prashant

Former Member
0 Kudos

confused....

you said values are available for company code and purchase org, then put those values and in rest or org level put *

hope i got you right

regards,

surpreet