Quantcast
Channel: SCN: Message List - Enterprise Resource Planning (SAP ERP)
Viewing all articles
Browse latest Browse all 6103

Re: Restricting access to XD01-XD03 with active Customer-Vendor-Integration

$
0
0

hi ingo

 

please look at the snote for solution at below,

 

1895612 - BP checks Authorisation Object S_TCODE with XD01, XD02...

 

content is:

 

 

Symptom

A business partner is synchronised with a customer or a vendor master data.
During maintenance of the business partner, the authorisation object S_TCODE is triggered checking XD01, XD02, XK01, XK02 transaction code.
SAP Note 1895335 is implemented

 

 

Other Terms

BP, S_TCODE, XD01, XD02, XK01, XK02, 00172, 00 172
BAdI, CUSTOMER_EXTENSION_AUTH_CHECK, AUTHORITY_CHECK_CUST_TRANSACT
VENDOR_EXTENSION_AUTH_CHECK, AUTHORITY_CHECK_VEND_TRANSACT

 

 

Reason and Prerequisites

Custom implementation help
SAP Note 1895335 or equivalent support package is implemented

 

 

Solution

  Note

 

CVI is designed to synchronize a Business Partner with a customer and/or a vendor master data.
As the customer or vendor is a master data on its own, the SAP standard make sure the user who does the maintenance is allowed for the direct customer/vendor transactions.
CVI functionality can also be triggered out of the synchronisation. This is an additional reason to check the S_TCODE authorisation object.
Nevertheless, this can be a considered as a lack of flexibility for setting up processes where the customer/vendors are exclusively maintained from Business partner master data and transactions.
The current note defines 2 new BAdIs

  • CUSTOMER_EXTENSION_AUTH_CHECK and method AUTHORITY_CHECK_CUST_TRANSACT.
  • VENDOR_EXTENSION_AUTH_CHECK and method AUTHORITY_CHECK_VEND_TRANSACT.

Customers that want to avoid the S_TCODE authority check are now able to skip the check by implementing this BAdI.
By default or when no implementation of BAdIs CUSTOMER_EXTENSION_AUTH_CHECK / VENDOR_EXTENSION_AUTH_CHECK, the CVI process check the authorisation object S_TCODE.

Custom implementation description for Customer Master data

 

In order to avoid checking the authorization object S_TCODE for transactions like XD01/XD02..., it is necessary to implement BAdI CUSTOMER_EXTENSION_AUTH_CHECK with method AUTHORITY_CHECK_CUST_TRANSACT.
The BAdI belongs to enhancement spot CUSTOMER_EXTENSION

 

Method AUTHORITY_CHECK_CUST_TRANSACT interface:
           Importing parameter: IV_TCODE
           Changing parameter: CV_NOCHECK
In order to avoid checking authorization object S_TCODE for transaction like XD01/XD02, the BAdI implementation has to return CV_NOCHECK = 'X'.

Custom implementation description for Vendor Master data

 

In order to avoid checking the authorization object S_TCODE for transactions like XK01/XK02..., it is necessary to implement BAdI VENDOR_EXTENSION_AUTH_CHECK with method AUTHORITY_CHECK_VEND_TRANSACT.
The BAdI belongs to enhancement spot VENDOR_EXTENSION

 

Method AUTHORITY_CHECK_VEND_TRANSACT interface:
           Importing parameter: IV_TCODE
           Changing parameter: CV_NOCHECK
In order to avoid checking authorization object S_TCODE for transaction like XK01/XK02, the BAdI implementation has to return CV_NOCHECK = 'X'.

Restriction:

 

The BAdI is only triggered from CVI.
Any external processes may still trigger the S_TCODE authorization object directly. For example Lean Customer Maintenance or Enterprise Services.


Viewing all articles
Browse latest Browse all 6103

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>