on 03-22-2007 1:57 PM
I am trying to change the check maintain indicator for a couple of transactions
to alow me to manage access based on security objects that are not currently defined as check maintain. Specifically, I have updated the check indicator
(using SU24) to check maintain for object c_stue_ber on transactions MD11 and MD12 (planned order create/change). The transactions still do not check this object as expected. Does anything else need to be done to enable checking an
object that is not set up as check maintain originally?
Any help is appreciated.
Thanks,
Doug Scott
We have the same requirement to restrict displaying BOM components in MD11, CO03, etc...
Sounds like object C_STUE_BER does not work to prevent displaying BOM Component lists in these transactions....
Is there any other solutions?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
C_stue_ber only controls programs that read the BOM tables i.e. MAST, STPO, etc. MD03 and CS03 read the RESB table for component information. The only way we
control MD03 and CS03 is by restricting the transaction to a given SAP plant using M_PLAF_ORG.. You could look at user exits for MM03 and CS03 and control with code if needed. Also be aware that displaying cost estimates on MM03 costing 2 tab also displays bom information, so we also restrict M-MATE_STA for views B and G to prevent this access.
SAP has here an very high security leak.
Many companys have to restrict the access to their boms.
This works in CS..-Transactions (e.g. CS02) with object c_stue_ber, but not in the component-view in production orders (e.g. CO02) what corresponds normally to the boms.
The answer from SAP which i received: System works as designed.
I had a very long interchange of letters (in german) with SAP. They recommended, to modify the system.
Maybe you've got better solutions?
You have the same problem in the calculation (e.g. CK13N), where you can open the calculation-structure on the left side totally - which also corresponds to the boms. The object c_stue_ber is already included in this transaction but it is not checked.
br Robert
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Doug,
Thank you for the quick reply. I am just wondering then why they list authorization objects in a transaction code, if it can not be checked. So, we will have to find another way for preventing people from changing the component list.
Thanks again and good luck.
Regards,
Kerstin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Kerstin,
I also wrote a message to SAP and got the following response. Looks like there are no security checks for this object in these transactions.
Regards,
Doug
Response from SAP
03.04.2007 - 12:48:38 CET SAP Reply
Dear Doug,
An authority check on C_STUE_BER is not possible for the transactions
CO02, CO03, MD11, MD12, CO26, CO27, CO28, COOIS, COHV, CO05, CO05N,
CO04N, COMAC or CO46.
In CO01 we check if the user has the authority to resolve the BOM
(C_STUE_BER). After resolving the BOM we don't check any longer with
C_STUE_BER since we don't work with the BOM but with a component list
in the order (which is actually a copy or the BOM).
For this component list there is no authority check.
The component list is visible in CO02, CO03, CO26, CO27, CO28, COOIS,
COHV, CO05N, CO04N, COMAC, CO46.
For production orders we use authority C_AFKO_AWA. With this
authority you can limit the access to CO02, CO03 and the change of
production orders by other transactions.
But please note that there are still transactions
that will display the orders and its components without authority
checks. For example infosystem transactions (COOIS, COHV, CO26, CO27,
...) and other processing transactions (COGI, ...). For those
transactions you would have to limit access.
For the creation of planned orders MD11, the authority check C_STUE_BER
is not used. Here you can use M_MTDI_ORG to check on a MRP controller.
So you should enter the same MRP controller in the material master
of the troublesome products and only this MRP controller will be able
to create a planned order for this material.
I am sorry not to be able to offer you any better solution for this
problem.
Kind Regards
Eoin Donnelly
SAP Support Consultant (SCM)
SAP GSC Ireland
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Doug,
I wish I have an answer, but I do have the same problem, just for another transaction (CO01 and CO02). Do you know the answer already? I actually searched OSS, but could not find a message, so I send a message myself. Maybe it is an error.
Thank you.
Regards,
Kerstin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
85 | |
10 | |
10 | |
9 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.