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.