Hiding condition type VPRS -
OSS note 105621
We are wanting to implement an OSS note 105621 that
will check authorizations and keep condition type VPRS from being displayed.
I have done most of the note, but am a bit confused by part of it.
It tells you to modify userexits: USEREXIT_FIELD_MODIFICATION,
USEREXIT_FIELD_MODIFIC_LEER,
USEREXIT_FIELD_MODIFIC_KZWI, USEREXIT_FIELD_MODIFIC_KOPF
and USEREXIT_PRICING_CHECK.
It also tells you to create two new includes: ZZAUTH01
and ZZAUTH02, but it doesn't tell you what changes to actually make in
any of these. I am assuming that the authority checks have to be added
somewhere, but what goes where?
The coding for includes ZZAUTH* are (create them in SE38
like INCLUDE, and althought note say that dev.class must be VF, I have
them with own dev.class ie: Z**, and it works)
include ZZAUTH01
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Object REPS ZZAUTH01
*& Object header PROG ZZAUTH01
*&---------------------------------------------------------------------*
*& This object has been generated from an advance
correction *
*& attached to a R/3 note. *
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Title: Authority check for displaying fields *
*&---------------------------------------------------------------------*
***INCLUDE ZZAUTH01.
* Beim ersten Aufruf ist KOMV initial; OLD_KOMK löschen,
* damit auf jeden Fall Berechtigungsprüfung durchgeführt
wird.
* Sicherheitshalber zunächst Berechtigung verweigern.
* if komv is initial.
IF SCREEN-NAME = 'FCODE'.
CLEAR OLD_KOMK.
AUTH_SUBRC = 4.
ENDIF.
* Berechtigungsprüfung auf Kalkulationsschema und
Stufen-Nr.
* Beim Wechsel der KOMV-Zeile einmalig eine Berechtigungsprüfung
* durchführen
IF KOMK-KALSM NE OLD_KOMK-KALSM OR KOMV-STUNR NE OLD_KOMV-STUNR.
AUTHORITY-CHECK OBJECT 'Z_KONH_KLS'
ID 'ZKALSM' FIELD KOMK-KALSM
ID 'ZSTUNR' FIELD KOMV-STUNR
ID 'ACTVT' DUMMY.
AUTH_SUBRC = SY-SUBRC.
OLD_KOMK = KOMK.
OLD_KOMV = KOMV.
ENDIF.
IF AUTH_SUBRC NE 0 AND ( SCREEN-NAME = 'RV61A-SELKZ'
OR SCREEN-NAME = 'KOMV-KAWRT'
OR SCREEN-NAME = 'RV61A-AWEIN'
OR SCREEN-NAME = 'KOMV-KBETR'
OR SCREEN-NAME = 'RV61A-KOEIN'
OR SCREEN-NAME = 'KOMV-KPEIN'
OR SCREEN-NAME = 'KOMV-KMEIN'
OR SCREEN-NAME = 'KOMV-KWERT' ).
SCREEN-ACTIVE = 0.
ENDIF.
MODIFY SCREEN.
* Ende Berechtigungsprüfung
for include ZZAUTH02
***INCLUDE ZZAUTH02 .
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Object REPS ZZAUTH02
*& Object header PROG ZZAUTH02
*&---------------------------------------------------------------------*
*& This object has been generated from an advance
correction *
*& attached to a R/3 note. *
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Title: Authority check for creating new conditions
*
*&---------------------------------------------------------------------*
***INCLUDE ZZAUTH02.
AUTHORITY-CHECK OBJECT 'Z_KONH_KLS'
ID 'ZKALSM' FIELD KOMK-KALSM
ID 'ZSTUNR' FIELD KOMV-STUNR
ID 'ACTVT' DUMMY.
IF SY-SUBRC NE 0.
MESSAGE E609(VH).
ENDIF.
* Ende Berechtigungsprüfung
...
*&---------------------------------------------------------------------*
In my system (46B) I remember that the subroutines USEREXIT
is not changed for this purpose. With SU21 (z_konh_kls I think that
you don't have problems), like with SU02.
In su02, remember that in XU180-PROFILE of first dynpro,
you must populate with value 'ZCOND_STD' and click on create work area
for profiles. Double click on zcond_std. In object populate with 'Z_KONH_KLS',
double click and you see the parameters like in tcode PFCG (profiles and
auth.)
For action you can populate '*'
For procedure you can populate with the procedure (see
tcode V/08 ) that you use in your SD documents, or the procedure/s in where
you want that the restriction will work, if you have many procedures.
For level, you must write the ranges of levels in this
procedures (into V/08 ) that you want that the user can see (remember that
alpha routine conversion dont works, ie: for level ' 1' [in dynpro] you
must write '001', if not, you will have problems). The levels out of this
ranges, the user with this profile when go to conditions in SD document
will not see the value of these items.
Finally, in SU01, add this profile to profiles created
with PFCG in 'profiles'.
After check if it works.
Back to:
SAP SD (Sales and
Distribution) Configuration Hints and Tips
Return to :-
SAP ABAP/4 Programming,
Basis Administration, Configuration Hints and Tips
(c) www.gotothings.com All material on this site is Copyright.
Every effort is made to ensure the content integrity.
Information used on this site is at your own risk.
All product names are trademarks of their respective
companies. The site www.gotothings.com is in no way affiliated with
SAP AG.
Any unauthorised copying or mirroring is prohibited.
|