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: 

Block Delete Authorization in P_PERNR

Former Member
0 Kudos

Hi,

I have to give the user Read/Write (Insert/Change) Authorization for Infotype 0021. But they should not be allowed to Delete.

Please let me know.

Thank you.

Regards,

Boobalan.

1 ACCEPTED SOLUTION

manohar_kappala2
Contributor
0 Kudos

Hi,

The Authorization Level field doesnt work that way.

Once you give the W (write) value then it includes all writes to create, change n delete record.

But I am still doubtful as to in which scenario you need to have such a control for P_PERNR object for IT 0021 - "Family/Related Person" as a end user will have to have right to change his family member details.

But you can use the Double verification concept (by using values E,D,S) and create a scenario in which this result can be obtained partially.

Here a user will be able to create locked records only and not update the DB and doesnt have access to manipulate including delete from the DB.

But he can create locked records which after verification can be applied to DB.

Plese refer to this:

The double verification principle requires that at least two persons are involved in changing HR infotype data. This principle can be used for all infotypes except 0000 (Events), 0001 (Organizational Assignment), 0002 (Personal Data), 0003 (Payroll Status) and 0031 (Reference Personnel Number).

The double verification principle is implemented by setting a lock indicator. If an infotype record is locked, this record is (physically) available on the database but is not taken into account in HR evaluations. (For example, if a "recurring payment/deduction" record is locked, it is not selected in HR payroll and is therefore not handled like an existing record). The lock indicator limits the validity period of records. Only records without a lock indicator are "valid" records. When the double verification principle is applied, one user stores locked data and another deactivates the lock indicator (unlocks the record). There are two ways in which two users can write a "valid" record to the database.

Asymmetric variant

User A is authorized to edit locked records (he/she is assigned authorization level 'E' (edit) and 'R' (read locked or unlocked) records. User A is authorized to:

create or copy locked records. Records created (or copied) by user A are locked. Locked or unlocked records can both be used as models.

change locked records,

delete locked records,

read locked or unlocked records.

User B is authorized to:

set (lock) or remove (unlock) the lock indicator (authorization level D),

read infotype records (authorization level R).

B checks the data created or changed by A and declares this data valid by unlocking it. Once the data has been unlocked, user A can no longer change it. To do so, user B must first lock the data so that user A can change it. User B must then check and unlock it, etc.

Please note the following: User A can copy existing (and unlocked) records. This copy is initially locked. If user B unlocks this copy, the unlocked model would be deleted either completely or partially if the time constraint is 1 or 2.

Example: You want to apply the double verification principle when entering a recurring payment (wage type nnnn [time constraint 2] in infotype 0014). User A (authorization level E) creates a record with subtype nnnn and enters a certain amount. The system sets a lock indicator for the record. This record is not taken into account in evaluations (payroll) while it is locked. Only when it is unlocked by user B does the entry of user A become active. An incorrect amount can be changed in two different ways:

1. B locks the record, A changes it, B checks and unlocks it, or

2. A copies the existing record and corrects the amount (in the copy); B checks the copy and unlocks it. Since the time constraint is '2', the existing unlocked record (with the incorrect amount) is deleted. The copy with the corrected amount then becomes valid.

Symmetric variant

User A and B have identical authorizations. Both have a read authorization and an authorization which allows them to edit locked records and unlock these (authorization level S). User A and B are both authorized to:

create (or copy) records. These records are locked (both locked or unlocked records can be used as a model),

change records (records which have been changed are locked even if they were previously unlocked),

lock records,

unlock records if the last person to change the record is not identical with the current user.

Here, user A and B check each other's work. When A creates or changes a record, it is locked. B checks the record and unlocks it (A can also perform B's work and vice versa). It takes two users (with identical authorizations) to create or change a valid (unlocked) record. Users with authorization level S cannot delete records.

Example: You want to apply the double verification principle (symmetric variant) when entering a recurring payment/deduction. User A enters the data. The record is locked. User B unlocks it. If data needs to be changed after the record has been unlocked, both A or B can do this. The data is changed and the record locked. The other user can now unlock this record. Alternatively, A or B could create a 'locked' copy. In this case, the model remains an unlocked record. If the copy is unlocked, the copy overwrites the model (time constraint 2).

The following applies to the symmetric variant of the double verification principle.

The person who last changed an infotype record must not have changed it explicitly: Even if the validity period of a particular record changes when user A creates or deletes a different record (due to time constraint 1 or 2), A is nonetheless entered as the person who changed the record. For example, both A and B have an 'S' authorization. A changes an existing infotype record (time constraint 2) with a validity period from 01/01/96 - 12/31/99. Then B creates the same type of record for 07/01/96 - 12/31/99. The result is two locked records with validity periods from 01/01/96 - 06/30/96 (1) and 07/01/96 - 12/31/99 (2); in both cases, B is entered as the last person who changed the record. However, B did not explicitly change the first record; he/she merely delimited it by creating the second record. As a result, A can unlock the first record.

Hope this helps

Manohar Kappala

1 REPLY 1

manohar_kappala2
Contributor
0 Kudos

Hi,

The Authorization Level field doesnt work that way.

Once you give the W (write) value then it includes all writes to create, change n delete record.

But I am still doubtful as to in which scenario you need to have such a control for P_PERNR object for IT 0021 - "Family/Related Person" as a end user will have to have right to change his family member details.

But you can use the Double verification concept (by using values E,D,S) and create a scenario in which this result can be obtained partially.

Here a user will be able to create locked records only and not update the DB and doesnt have access to manipulate including delete from the DB.

But he can create locked records which after verification can be applied to DB.

Plese refer to this:

The double verification principle requires that at least two persons are involved in changing HR infotype data. This principle can be used for all infotypes except 0000 (Events), 0001 (Organizational Assignment), 0002 (Personal Data), 0003 (Payroll Status) and 0031 (Reference Personnel Number).

The double verification principle is implemented by setting a lock indicator. If an infotype record is locked, this record is (physically) available on the database but is not taken into account in HR evaluations. (For example, if a "recurring payment/deduction" record is locked, it is not selected in HR payroll and is therefore not handled like an existing record). The lock indicator limits the validity period of records. Only records without a lock indicator are "valid" records. When the double verification principle is applied, one user stores locked data and another deactivates the lock indicator (unlocks the record). There are two ways in which two users can write a "valid" record to the database.

Asymmetric variant

User A is authorized to edit locked records (he/she is assigned authorization level 'E' (edit) and 'R' (read locked or unlocked) records. User A is authorized to:

create or copy locked records. Records created (or copied) by user A are locked. Locked or unlocked records can both be used as models.

change locked records,

delete locked records,

read locked or unlocked records.

User B is authorized to:

set (lock) or remove (unlock) the lock indicator (authorization level D),

read infotype records (authorization level R).

B checks the data created or changed by A and declares this data valid by unlocking it. Once the data has been unlocked, user A can no longer change it. To do so, user B must first lock the data so that user A can change it. User B must then check and unlock it, etc.

Please note the following: User A can copy existing (and unlocked) records. This copy is initially locked. If user B unlocks this copy, the unlocked model would be deleted either completely or partially if the time constraint is 1 or 2.

Example: You want to apply the double verification principle when entering a recurring payment (wage type nnnn [time constraint 2] in infotype 0014). User A (authorization level E) creates a record with subtype nnnn and enters a certain amount. The system sets a lock indicator for the record. This record is not taken into account in evaluations (payroll) while it is locked. Only when it is unlocked by user B does the entry of user A become active. An incorrect amount can be changed in two different ways:

1. B locks the record, A changes it, B checks and unlocks it, or

2. A copies the existing record and corrects the amount (in the copy); B checks the copy and unlocks it. Since the time constraint is '2', the existing unlocked record (with the incorrect amount) is deleted. The copy with the corrected amount then becomes valid.

Symmetric variant

User A and B have identical authorizations. Both have a read authorization and an authorization which allows them to edit locked records and unlock these (authorization level S). User A and B are both authorized to:

create (or copy) records. These records are locked (both locked or unlocked records can be used as a model),

change records (records which have been changed are locked even if they were previously unlocked),

lock records,

unlock records if the last person to change the record is not identical with the current user.

Here, user A and B check each other's work. When A creates or changes a record, it is locked. B checks the record and unlocks it (A can also perform B's work and vice versa). It takes two users (with identical authorizations) to create or change a valid (unlocked) record. Users with authorization level S cannot delete records.

Example: You want to apply the double verification principle (symmetric variant) when entering a recurring payment/deduction. User A enters the data. The record is locked. User B unlocks it. If data needs to be changed after the record has been unlocked, both A or B can do this. The data is changed and the record locked. The other user can now unlock this record. Alternatively, A or B could create a 'locked' copy. In this case, the model remains an unlocked record. If the copy is unlocked, the copy overwrites the model (time constraint 2).

The following applies to the symmetric variant of the double verification principle.

The person who last changed an infotype record must not have changed it explicitly: Even if the validity period of a particular record changes when user A creates or deletes a different record (due to time constraint 1 or 2), A is nonetheless entered as the person who changed the record. For example, both A and B have an 'S' authorization. A changes an existing infotype record (time constraint 2) with a validity period from 01/01/96 - 12/31/99. Then B creates the same type of record for 07/01/96 - 12/31/99. The result is two locked records with validity periods from 01/01/96 - 06/30/96 (1) and 07/01/96 - 12/31/99 (2); in both cases, B is entered as the last person who changed the record. However, B did not explicitly change the first record; he/she merely delimited it by creating the second record. As a result, A can unlock the first record.

Hope this helps

Manohar Kappala