Header Ads

  • Recent Posts

    Position numbers are not getting listed in POSITION_DATA component in PeopleSoft-HCM8.9

    Why does Position numbers does not get listed in POSITION_DATA component in PeopleSoft HCM 8.9?
    First up, the issue is not only for PeopleSoft HCM8.9 but will also happen in other versions of HCM. This is not a defect in delivered PeopleSoft and is because of the way HRMS is setup in the organization.
    The position numbers could exist in POSITION_DATA record however the position number does not get listed in Position data pages or prompts, why is it so?

    In PeopleSoft - HCM, a valid and active position number does not get listed in Position data search page. When querying the position record, the position number seems to be valid. So there is some underlying security reason which prevents the position number from getting listed. Having said that, just a while before we could have edited the same position and chnaged the data however, after saving the component and hitting the search page the position does not get listed.

    In the navigation, Organizational Development -> Position management -> Maintain positions, no position data is found even though there is data in the system

    Even in the navigation Setup HRMS -> Foundation Tables -> Organization -> Position the position number does not get listed.

    This could happen Business Unit (BU) is value is changed for a position number and when security access type is set based upon Business Unit. This prevents the Position numbers getting listed for the user based upon the security levels set for the user's BU. This holds good for departments too.

    POSITION_DATA component has POSITION_SRCH as search record. POSITION_SRCH record is a view with the following SQL:
                    SELECT SETID
                    FROM PS_SET_CNTRL_REC SC
                    AND SC.RECNAME = 'DEPT_TBL')
    AND (A.EFFDT>=%CurrentDateIn
                              FROM PS_POSITION_DATA D
                              WHERE A.POSITION_NBR = D.POSITION_NBR
                              AND D.EFFDT<=%CurrentDateIn ) )

    Taking a look at the data in PS_DEPT_SEC_SRCH record and PS_SET_CNTRL_REC record will give more inputs on why the particular position_nbr is not getting listed in POSITION_DATA component.

    Position data security search view considers security by DeptID. The primary reason Position Search views are based on Department is because employees are hired into positions in Departments and one department may be present in multiple locations. Row level security by permission list (security access type BU) is implemented in the system and hence the position number does not get listed in POSITION_DATA component's search page.

    Notes from Oracle Support on this issue:
    ICE report 1468246000 was logged addressing this issue. This is not considered an issue for HRMS 8.9 and 9.0 releases and is now considered as an enhancement for HRMS 9.1 release

    Component Search record (POSITION_SRCH), it joins security data from record PS_DEPT_SEC_SRCH, thus requires row-level security setup using department.

    A possible workaround would be to explore the possibility of enabling security access type 023 - Departments by SetID.

    In case that your SetID relates to a BU (one to one relationship) it could work. You would need to select Security Set DEPT and Security Access Type 023 - Dept by Set ID.
    Position Data is part of the DEPT Security Set, which in turn allows three security access types - department tree, SetID, and non-tree. Dept by SetID is suggested if it makes sense to make a correlation between Business Unit and SetID. Depending on how your business requirements are, you may need to pay attention to the TableSet Controls found in PeopleTools > Utilities > Administration. The objective would be to have Departments use the SetID that corresponds with the Business Unit, even if some of the other tables share the same SetID across business units.

    Please also refer to Home > PeopleBooks > PeopleSoft Enterprise Human Resources 9.0 PeopleBook: Manage Positions > Setting Up Positions - Managing Position Data Security

    ICE Report 1597211000 was also logged addressing this issue but this was closed as WAD. The following is the recommendation based on that ICE Report:

    The row level security for search views in PeopleSoft 'HCM' must be given by Security by Department Tree"; though security by Location / Business Unit can be enabled by doing certain set up. The primary reason Position Search views are based on Department is because employees are hired into positions in Departments and one department may be present in multiple locations.

    There are two ways which can ensure Security based on Location and Business Units.

    Step 1 - The Conventional way:
    Though the Position Search view uses Department Security to give access to the Locations and Business Units; security can still be enabled using Locations and BU's by ensuring the following set up is properly done:
    1) In the Security by Department Tree Definition using the Row Security Permission List used in the User Profile Page, include all those departments (under which the employees data fall basically departments into which employees are hired using positions)

    2) In the Security by Permission List Definition - using the Row Security Permission List used in the user profile page, include the Business Units (in your case for HRMS security - Business Unit = GBLAL) using the default set ids of which the Location Definitions have been defined.

    3) After ensuring the set up and after ensuring that in the Set Control value of GBLAL Table Set Sharing for Location Record Group is properly done; you need to run the Refresh SJT Class All Process to ensure that the security based on location gets enabled along with Department Security.

    Step 2 - Using Tree Based Security:
    1) Define a Location Tree based on the hierarchy the data is required to be accessed.
    2) Attach this Tree to the Set Control Value of the Business Unit in the Set Control Value Definition. Though by doing this you would need to keep updating the Location Tree whenever you create new locations or modify the Location Definitions.

    No comments

    Please refrain for marketing messages and unnecessary back links.

    Post Top Ad

    Post Bottom Ad