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: 

Authorzation only to Insert / not to change in P_PERNR

Former Member
0 Kudos

Hi,

I have to give the Authoirzation for Employees (ESS/ECC6) to Insert new

Temporary Address (IT0006 /subtype 2).

I am using the object P_PERNR. When i give "W" authorization

it allows both Insert & Change.

How to give only for Insert and block Edit of the Address.

Regards,

Boobalan

1 ACCEPTED SOLUTION

manohar_kappala2
Contributor
0 Kudos

Hi,

There is no way doing that but however you can go for Double Verification Principle (using S,E,D) values to do that.

This might help in this regard,

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

1 REPLY 1

manohar_kappala2
Contributor
0 Kudos

Hi,

There is no way doing that but however you can go for Double Verification Principle (using S,E,D) values to do that.

This might help in this regard,

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