P_ORGIN and P_ORGXX?

Guru's
What are P_ORGIN and P_ORGXX?
Thanks,
Harish

Hi ,
These 2 are the authorisation objects ,
P_ORGIN consisting of fields
AUTHC     Authorization level
INFTY     Infotype
PERSA     Personnel Area
PERSG     Employee Group
PERSK     Employee Subgroup
SUBTY     Subtype
VDSK1     Organizational Key
and
P_ORGXX consisting of fields
AUTHC     Authorization level
INFTY     Infotype
SACHA     Payroll Administrator
SACHP     Administrator for HR Master Data
SACHZ     Administrator for Time Recording
SBMOD     Administrator Group
SUBTY     Subtype
Once these are provided to the user , he/ she can access the data accordingly .
Let us take for example there is a role maintained for a user
THis is how it looks for a user in SU01
      Standard   Cross-application Authorization Objects
      Standard   Transaction Code Check at Transaction Start
      Standard   Transaction Code Check at Transaction Start
              Transaction Code               PA51, ZPTR0011
              Changed    Human Resources
              Changed    HR: Master Data
              Changed    HR: Master Data
                Authorization level            R
                Infotype                           2006, 2007
                Personnel Area                 HYD, BGL
                Employee Group               *
                Employee Subgroup           *
                Subtype                            *
                Organizational Key             *
     Inactiv     Standard   HR: Clusters
     Inactiv     Standard   HR: Master Data - Personnel Number Check
Now this employee is capable of looking into data from 2 personal areas HYD and BGL only .
Also if this being maintained can be used in the custom reports(Z-report) as well for restricting the data according to locations .
Hope this helps .
Regards
SureshP

Similar Messages

Relation into P_ORGIN and INFOTYPE 105 SUBTYPE 0001

Hello, at the moment I have a problem, I add the user's name in the infotipo 105 and subtype 0001 but this cause that the user can see his data in the infotipo 0001, when at level of P_ORGIN one has specified that alone he can see personal to his position by means of the organizational key.
Does this infotipo have some precedence on the P_ORGIN?

when at level of P_ORGIN one has specified that alone he can see personal to his position by means of the organizational key.
At VSK1 level
P_ORGIN
INFTY - Info type
SUBTY
AUTHC- Authorization Level
PERSA u2013 Personnel area
PERSG u2013 Employee group
PERSK- Employee sub group
VDSK1- Org Key

HR Ojbects: P_ORGIN and PLOG

Should the infotypes on P_ORGIN be the same as those in PLOG?
Thanks,
Liz

It depends what you are trying to control.
Both do different jobs - speak to your HR team it identify the control points and map the respective requirements into your build. You could need different infotypes for PLOG, P_ORGIN, P_PERNR etc.

Plz tell me how to create authority check objects and how to usein prg

dear sir,
plz tell me how to create authority check objects and how to usein prg

http://help.sap.com/saphelp_46c/helpdata/en/5c/deaa74d3d411d3970a0000e82de14a/content.htm
http://help.sap.com/saphelp_nw70/helpdata/en/52/6716a6439b11d1896f0000e8322d00/content.ht
Create custom authorization Customer specific object
If you have requirements that cannot be met using the P_ORGIN and P_ORGXX authorization objects (for example, because you want to build your authorization checks on additional fields of the Organizational Assignment infotype (0001) that are customer-specific), you can include an authorization object in the authorization checks yourself.
Create the authorization object using transaction SU21. Make sure you keep to the customer name range (Z/Y). To be able to use the new authorization object you have created in the master data authorization check, the object must contain the INFTY, SUBTY, and AUTHC fields. You can use any of the fields of the Organizational Assignment infotype (0001) for the other fields. You can also use customer-specific additional fields provided they are CHAR or NUMC type fields.
After you have created the object, you must start the RPUACG00 report. This report overwrites the MPPAUTZZ standard include with the code that is needed to evaluate the authorization object you created. Note: Technically speaking, this involves a modification. However, SAP fully supports this procedure. And you should not have more maintenance work as a result of this modification.
          Note: that if you use customer-specific authorization objects, you must maintain these objects in transaction SU24 (Maintain Assignment of Authorization Objects to Transactions) in the same way as you maintain the authorization objects P_ORGIN, P_ORGXX, and P_PERNR
AUTHORITY CHECK OBJECT Object_name
            ID fieldname1 FIELD fieldvalue1
            ID fieldname2 FIELD fieldvalue2
            ID fieldname3 FIELD fieldvalue3.
             If sy-subrc eq 0.   "Authorization exists
             Endif.
http://articles.techrepublic.com.com/5100-6329_11-5110893.html
Edited by: JackandJay on Jan 16, 2008 10:21 AM

Authorization check in HR

Hi experts,
I'm new one in Authorization Management, and i have the following question.
please help me out, thanks.
Display Role: DR
Object ORGIN:
AUTHC = M,R
PERSA = 0001
Object ORGXX:
SBMOD = Z001
Maintenance Role: MR
Object ORGIN:
AUTHC = *
PERSA = 0002
Object ORGXX:
SBMOD = Z002
These two roles assign to user test01.
My simple question is:
Does user test01 has permission to maintain the employee whose PERSA = 0002 and SBMOD =Z001?
Many thanks.
Herman.

Hi Herman,
The answer to your question would be "no" because while the user has write access for PERSA 0002 from the maintain role, he does not have write access for SBMOD Z001 as this value is only in the display role.
If he/she does have write access to this combination then check following settings:
1) Authorization main switches (transaction OOAC): Make sure that the check for P_ORGXX has been activated, otherwise only P_ORGIN will be checked. Switch ORGXX is off by default.
2) Time logic: If Time Logic for the Infotype you are changing is disabled (V_T582A, default disabled I think) then the user will have write access if the PERNR you are testing with has an IT0001 record for which he has authorization.
3) Run SU56 for the user and check which P_ORGIN and P_ORGXX authorizations he/she has. There may be more than just these 2 roles.
Good luck,
Brent

Usage of SAP* user in OOSB

Hi Gurus,
I'll be implementing Structural Authorization for my current project.
I received requirement to restrict ESS and MSS display access specific to Qualification/Qualification Group (by object ID).
General Authorization cannot specify the restriction by Object ID, thus I'm considering to restrict it using authorization profiles.
Restriction for MSS view has successfully tested since MSS users will be assigned with MSS Authorization Profile in OOSB. The issue that I'm facing at the moment is how to apply the same restriction to ESS without assigning ESS IDs in OOSB - approximately 40K ESS users; will it impact the system performance anyway?
If I were to use similar authorization profile defined in OOSP as per MSS, the only way to make it effective for all ESS users without assigning PD profile to each ESS ID in OOSB is by using SAP* - this is based on my understanding referring to notes that I found as attached below. I plan to customize authorization profile specific for ESS users and assign it to SAP* - still in test stage.
Here are the statement that I'm referring to from the notes mentioned above:
" What happens if the table doesnu2019t contain entries for a specific user? In that case, the authorization check uses the
entry of the SAP* user. So, the profile stored for this user is applicable if an entry has been left out."
Please correct me if I'm wrong and appreciate your advice on this matter. Million thanks

Hi,
In this scenerio you can activate Context based structural authorizations where the Auth profiles are not assigned to User Ids directly but assigned via Custom roles using authorization objects P_ORGINCON (HR: Master data with Context) and P_ORGXXCON (HR: Master data- Extended Check with Context).
Authorization objects P_ORGINCON and P_ORGXXCON consists of the same fields as to P_ORGIN and P_ORGXX respectively and has been expanded to include the PROFL field. The PROFL field is used to determine which structural profile the user is authorized to access (as per table T77UA - User Authorizations = Assignment of Profile to User).
Additionally,I f you have requirements that cannot be mapped using the P_ORGINCON and P_ORGXXCON authorization objects (for example, because you want to build your authorization checks on additional fields of the Organizational Assignment infotype 0001 that are customer-specific) and if you want to implement the context solution, you can include an authorization object- P_NNNNNCON (HR Master Data: Customer-Specific Authorization Object with Context) in the authorization checks yourself.
Please note following switches have to be activated for Context based Structural authorization in table T77S0 (tcode- OOAC)
AUTSW INCON (HR Master Data (Context))- Authorization Main Switch that controls whether the P_ORGINCON authorization object should be used in the authorization check.
AUTSW XXCON (HR Master Data: Extended Check (Context))- Authorization Main Switch that controls whether the P_ORGXXCON authorization object should be used in the authorization check.
AUTSW NNCON (Customer Authorization Object (Context))- Authorization Main Switch that controls whether the P_NNNNNCON customer-specific authorization object should be used in the authorization check.
Hope this is helpful!
Thanks
Sandipan

ESS-Display Qualification

Hi All,
I am using transaction PZ31_EWT which is taking me to the screen "Change Qualification Profile for (individual's Name).
Can anybody let me know the transaction to "Display the Qualification Profile" for ESS?
Rohini

Hi,
In this scenerio you can activate Context based structural authorizations where the Auth profiles are not assigned to User Ids directly but assigned via Custom roles using authorization objects P_ORGINCON (HR: Master data with Context) and P_ORGXXCON (HR: Master data- Extended Check with Context).
Authorization objects P_ORGINCON and P_ORGXXCON consists of the same fields as to P_ORGIN and P_ORGXX respectively and has been expanded to include the PROFL field. The PROFL field is used to determine which structural profile the user is authorized to access (as per table T77UA - User Authorizations = Assignment of Profile to User).
Additionally,I f you have requirements that cannot be mapped using the P_ORGINCON and P_ORGXXCON authorization objects (for example, because you want to build your authorization checks on additional fields of the Organizational Assignment infotype 0001 that are customer-specific) and if you want to implement the context solution, you can include an authorization object- P_NNNNNCON (HR Master Data: Customer-Specific Authorization Object with Context) in the authorization checks yourself.
Please note following switches have to be activated for Context based Structural authorization in table T77S0 (tcode- OOAC)
AUTSW INCON (HR Master Data (Context))- Authorization Main Switch that controls whether the P_ORGINCON authorization object should be used in the authorization check.
AUTSW XXCON (HR Master Data: Extended Check (Context))- Authorization Main Switch that controls whether the P_ORGXXCON authorization object should be used in the authorization check.
AUTSW NNCON (Customer Authorization Object (Context))- Authorization Main Switch that controls whether the P_NNNNNCON customer-specific authorization object should be used in the authorization check.
Hope this is helpful!
Thanks
Sandipan

Difference between M (Read entry helps) and R (Read) in P_ORGIN

Hello Gurus,
I have question regarding the authorization level in P_ORGIN. The enduser has access to the Read 'R' access but When
he tries to assign (PERNR xxx) to an order he does not see the user.
SU53 says that authorization level 'M' (Read with entry help) is missing. Currently it is setted as R,
please let me know if the end user can be able to see with R only as it is also read access.
Regard's

Hi Salman,
Look at the following note from SAP make sure to have correct combination for both P_orgin and P_pernr.
this readily available. Once you have the proper assignment of infotypes and subtypes you will be good to go.
use ST01 to trace the authorization failure, Su53 only displays the last step in your authorization failures.
Note:
Definition
Here you can define the authorization level for the HR and FI Travel Management application components. You must determine whether the field is used together with:
objects for HR infotypes
HR: Master data
HR: Master data - extended check
HR: Master data - personnel number check
HR: Applicants,
the data stored in HR clusters
HR: Cluster,
or with the relevant object in Statements
HR: Statements.
or in FI Travel Management
FI: Travel Planning
FI: Travel Accounts
Possible values if the field is used together with one of the four first objects (the values E, D and S may only be specified together with R):
M (read with entry helps)
R (read),
S (write locked record; unlock if the last person to change the record is not the current user),
E (write locked record),
D (change lock indicator),
W (write data records)
(all operations).
Note:
Users with write authorization should always also have the relevant read authorization. In other words, the user should also have the correct authorizations for authorization level R together with each of the authorization levels E, D, and W.
The values E and D or S can be used to implement the double verification principle.
Possible values for HR: Cluster are:
R (read),
U (write to the database; this includes exporting the data to a buffer but not reading the data)
S (export data to a buffer; the database is not updated. You can use this value to simulate a payroll accounting run. Payroll results are determined but not stored on the database).
Possible values for HR: Statements are:
E (single record entry)
S (fast entry)
A (display when printing statements)
D (print statement)
L (delete statement)
Possible values for FI Travel Management are:
R (read),
W (maintain data)
A (release)
B (reserve in Amadeus reservation system)
C (reserve released trips in Amadeus reservation system)
Q (create trip template)
(all operations).
You can only enter the values 'W', 'A', 'B' and

Authorization issue on hire action through HCM Process and Forms

Hi All,
We are executing hiring action through HCM form process. The process is using the HR_PL_ADMINISTRATOR role on ECC which is super admin access to execute the action and HR administrator role on the portal. If we restrict the role with personal area, we do not see the hire process on the portal.
Could you please let me know if anyone has faced this issue?
Thanks,
Gowri

Thanks for responding back. I have seen the link before.
We have HR_PL_ADMINISTRATOR_000 role. The role has P_ASRCONT P_ORGIN and P_PERNR object. Object P_ORGIN needs to be set as
Authorization level            Read
Infotype                           *
Personnel Area                *
Employee Group              *
Employee Subgroup         *
Subtype                           *
Organizational Key            *
in order to show the Hire Process in execute hiring link on the Portal. If we put a restriction on personal area, we do not see the Hire process on the execute hiring on the portal.
Kindly advice.
Thanks,
Gowri

Restrict user on custom report by using P_orgin

Hi
I have a requirement of restricting the view of a custom HR report based on Personnel Area(PERSA). I am using the standard authorization object "P_ORGIN" and call the following in my code, still I am not being able to restrict the view of the report based on PERSA.
The test user id created has the role rest
    CALL METHOD zyclmdmim_authority_chk=>zyxapm_authority_check
      EXPORTING
        infty = '0001'
        authc = 'R'
        persa = '0684'
      EXCEPTIONS
        noauthorization = 1
        OTHERS          = 2.
method zyxapm_authority_check.
authority-check object 'P_ORGIN'
id 'INFTY' field infty
id 'AUTHC' field authc
id 'PERSA' field persa.
if sy-subrc <> 0.
    raise noauthorization.
endif.
endmethod.
Regards
Swarnali
Edited by: swarnali_IBM on Jan 28, 2012 9:10 AM

Hi Swarnali
You can use codee below
CALL METHOD zyclmdmim_authority_chk=>zyxapm_authority_check
      EXPORTING
        infty = '0001'
        authc = 'R'
        persa = '0684'
      EXCEPTIONS
        noauthorization = 1
        OTHERS          = 2.
method zyxapm_authority_check.
authority-check object 'P_ORGIN'
id 'INFTY' field infty
id 'AUTHC' field authc
id 'PERSA' field persa.
if sy-subrc NE 0.
    raise noauthorization.
endif.
endmethod.

Inconsistencies in P_ORGIN for Transaction code PU00

Hello Gurus,
I am getiing a inconsistancy error in the auth object P_ORGIN when I try to add a tcode PU00 and while going into the authorization tab.
I understand that this need's to be corrected in SU24 for the tcode PU00 and deleting the proposed values and saving the settings then modifying the role and then changing back to the previous authorization values. I checked that the tcode PU00 has these values currently.
P_ORGIN     AUTHC     M
P_ORGIN     AUTHC     R
P_ORGIN     AUTHC     W
P_ORGIN     INFTY
P_ORGIN     PERSA     $PERSA
P_ORGIN     PERSG
P_ORGIN     PERSK
P_ORGIN     SUBTY
P_ORGIN     VDSK1     $VDSK1
Please let me know if I need to delete all these values then save the settings and then modify the role. I see that it prompts a workbench request for this changes.
Regard's,
Salman

Hi Salman
Yes, you would need to delete the objcet P_ORGIN and add it back with the same values as listed. It will promt you to create a workbench request. Once changes are done you can go to the role in transaction PFCG and authorization tab go to "Expert mode for Profile Generation" and check on "Read old status and merge with new data" to import the changes in the role.
Once the changes are done in the role, generate the role.
Thanks.
Anjan

Object P_ORGIN inconsistent

Hi all,
I have created a new Role and inserted the Tcode OOOE in the menu tab and when click on change authorization data in Authorization tab it pops up with an error message
Authorization default values of transaction OOOE for object P_ORGIN inconsistent.
Message no. 5 @ 015
Diagnosis
The authorization fields included in authorization default values are incomplete or incorrect
System Response
The action is terminated to avoid inconsistent authorization data
Procedure
In transaction SU24, modify the authorization default values in object definition from transaction SU21, and repeat the action.
I have checked the values of P_ORGIN using SU21 & SU24 and they have default values. How to make the P_ORGIN object consistent?
Thanks in Advance
Ravi

Result of a test in 4.6C and 4.7 system (with up-to-date support package):
The PFCG loads the merged authorization proposals for S_TCODE, PLOG, P_ORGIN and P_TCODE according to the SU24 data for the parameter transaction OOOE and the 'master' transaction PPOM. -> It seems that you have a special problem in your system.
I assume that you have the same problem if you add transactopn PPOM inte a role, because the systems loads these authorization proposals.
The PFCG shows the message if there is an inconsistency between authorization proposals in table USOBT_C and the definition of an authorization object in table TOBJ
My suggestion: Use SU24 to delete the authorization proposals for transaction PPOM, save it and add them again.
P_ORGIN
AUTHC      *
INFTY      0000 0001 0002 0003
PERSA      <empty>
PERSG      <empty>
PERSK      <empty>
SUBTY      *
VDSK1      <empty>
Please check note <a href="https://service.sap.com/sap/support/notes/745655">745655</a>, too, which might be applicable.
Kind regards
Frank Buchholz

CATS Timesheet creator and approver

All,
We have two main roles we are dealing with in CATS. We have a Time Sheet creator and than a Time Sheet Approver. Right now it is setup mainly through the P_ORGIN auth. obj. I won't allow the approvers to approve their own time sheets but itlll allow them to approve everyone elses. so Infotype 0328 is setup with ' ' subtype and activity D, and P_PERNR activty M,R with infotypes 0000-0002 0007 0315 0315 2001-2003 2010 with subtype ' ' and it will allow the approvers to approve anyones timesheets but their own like we would like.. In the Time Sheet creators it is setup with infotype 0001 and ' ' subtype. with activity M in P_ORGIN and activty R for infotype 0007 & 0316 with subtype ' '. which allows the users to create timesheets for only themselves
The issue is when those two roles are put together to the approver can't create a timesheet. We need the approver to be able to create timesheet for themselves only and approve timesheets for everyone but them selves. I understand the logic of how it is setup (well atleast I think I do) and I know by adding a * to the approver subtype it will allow them to create timesheets for themselves. Is there anyway around this or another way of assigning authorizations to get this to work properly.
Thanks,
-Daniel

Hello,
I have exaclty the same issue.
have you found something please ?
Do you use Pd profile or P_ORGINCON authorisation ?
Regards
Edited by: Cédric LEFRANCOIS on Dec 1, 2009 12:53 PM

Restricting P_ORGIN checks to the current state of an employee

Hello everyone,
as part of our authorization concept, we are using the field PERSG in authorization object P_ORGIN (and P_ORGINCON) to determine whether a user has access to the infotypes of a given employee.
In the current example, the user may access employees with a personnel group (PERSG) '1' - '9', but not 'M', because our PERSG 'M' stands for 'manager', so his P_ORGIN and P_ORGINCON are restricted to PERSG BETWEEN '1' AND '9'. Basically, this works nicely.
However, there are cases in which an employee is promoted to manager level. His former PERSG in infotype 0001 is '1', but beginning from a certain date, his PERSG changes to 'M'. The autorization system now lets the user still see the former periods of time of this employee during which his PERSG was still '1', even though now he is 'M'. I understand that this is correct system behavior as SAP designed it. However, in our case it is undesired by the management. Once an employee has been promoted to PERSG 'M', none of his infotype periods should be visible to any user who does not have the 'M' authorization level.
Is there a way to achieve this?

Hello Eva,
thank you very much, that appears to be the right track already. Trouble is, HRPAD00AUTH_TIME is very poorly documented. It has two methods "CONSIDER_SY_DATUM_EXIT" and "BEGDA_ENDDA_COMPARE_EXIT" which have documentations of their own.
The documentation of CONSIDER_SY_DATUM_EXIT says that this method is only applicable if T528A-VALDT is set to 'X'. However, the whole table T528A does not even exist in our system?! (7.40)
Documentation of BEGDA_ENDDA_COMPARE_EXIT leaves me pretty clueless how to interpret the IMPORTING parameters. I would have expected to be able to set the new time for which the system shall check the authorization. However, the only available export parameters allow me to set whether authorization is given or not, overriding the standard coding. So it seems that with this method I am not changing the time period for the check, but overriding the whole authorization process altogether?!
My other hope was note 570161, but the BADI HRPAD00CHECK_TIME which is referred to there does not seem to exist in our release anymore, so I assume it is obsolete.
Do you happen to know anything more about the BADI that would make its usage for my purpose more transparent?

HR Authorization Issue (How can it be achieved)

Hi Gurus,
Our SAP HR PA data authorization is by Org Key using P_ORIGIN security object. As a result, HR Users who have the access for the Org Key can view records of employees belonging to that particular Org Key.
The problem comes when an employee is transferred from old Org Key to new Org Key. As a result, HR user can still view those records in PA infotypes for the prior periods when IT0001 org key was the old one.
Requirements: Our HR Head wants to completely block these kind of employees whose org key has been changed to the new one. Since HR Users dont have the authorization for the new Org Key; they should not be able to view PA IT0001 records for period which still have the value for old org key.
Any way to implement this kind of check ? Or any way to control security access by Pernr (so that we could block some pernrs from being viewed by HR user).
Please provide your insight..
Note: We have not activated P_ORGXX in our system.

Hello Amit,
Try to use organizational key (VDSK1) to restrict access to HR personnel information. When we change the value in the VDSK1 field from users not able to view PA data only for those employees for which they have responsibility. Use P_ORGIN and organization key (VDSK1) to do this.
Cheers and Regards.
Jaime

P_ORGIN and P_ORGXX?

Similar Messages

Maybe you are looking for