HCM Data Regulations

PeopleSoft HCM Data Regulated using the below setup information.
Business Units
Table Sets
Set ids
Record Groups
Business Unit Option Defaults
Org Defaults by Permission List

Now we will look at each item and try to understand what they meant to the organization.
Business Unit:

Set Up HRMS, Foundation Tables, Organization, Business Unit, Business Unit 

You create business units  to track and report specific business information.For HCM, you must establish at least one business unit.
If your organization uses same processing rules , it make sense to have a single business unit; if you use different rules in different companies, countries, or functional areas, you may choose to create multiple business units.

Example : Banking treats each branch as a business unit, which means that the bank could do reporting for its people within each branch.


Tableset sharing:

Sharing rows of data in a tableset across business units or limiting rows to a single business unit.

Before you set up tableset controls setup Business Unit, Setid and Record Groups.

Understanding Table Set:
Table Set ID:
setID:
PeopleTools, Utilities, Administration, TableSet Ids
Use the above page to setup Logical SetID.
A set of data rows in a control table that is identified by the same high level key.

The highlevel key that identifies a set of data rows. There are two types of setIDs:

• Physical SetIDs
  The setID of a business unit (BUSINESS_UNIT = SETID). The rows of data in a physical setID have a one to one relationship with the business unit.
• Logical SetID
  A logical setID that is generic and determined by business rules other than business unit. Logical setIDs enable you to share rows of data across multiple business units.

Record Groups:
PeopleTools, Utilities, Administration, Record Group

Record Group is a group of records which will be shared by Setid across business units.You can make Record Group to be use of default Setid on this page, else it will be assigned using Table Set Control with group of Record Groups.

Table Set Control:
PeopleTools, Utilities, Administration, Table Set Control
Assigning Group of Record Groups to a Setid using a Set Control Value which could be business unit, country, reg region ...etc.

Example : When you give XXX as business unit on Job data page, it will pull the record groups for the set control value XXX and gets the list of all the departments or job codes from the record group corresponding to the Setid used on the set control page.

Org Defaults by Permission List:
Set Up HRMS, Foundation Tables, Organization, Org Defaults by Permission Lst, Defaults

On the Org Defaults by Permission List component (OPR_DEF_TBL_HR) set up primary permission lists with: Default values for the following fields: Business Unit, SetID,Company,Country,Regulatory Region, To Currency, Currency Rate Type.

Business Unit Option Defaults:
Set Up HRMS, Foundation Tables, Organization, Business Unit Options Defaults, Business Unit Options Defaults
When users access an HCM component, the system populates some of the fields, such as business unit, company, and country using the values you associated with the user's primary permission list. You can also associate default values with setIDs on the Business Unit Options Defaults page (BUS_UNIT_OPT_HR).

To set up business unit defaulting:
On the Tableset Control – Record Group page (SET_CNTRL_TABLE1), select the SetID that controls business unit defaulting for this business unit.

1. This enables you to share defaulting rules across business units.
   
2. Enter the setID's default values on the Business Unit Options Defaults component. 

Hope this gives fair understanding on Data Regulations using Business Unit, Set id and Table Set Sharing.

Row Level Security

Restricting Data to the Persons who are not authorized to see and also providing access to the data who are authorized to see data is called Data Security.
Row Level Security Prevents the user from being able to access data they are not allowed via the search page.

Security Installation Settings :
Set Up HRMS, Security, Core Row Level Security, Security Installation Settings
Settings are Include Home/Host, Include Additional Assignments, Job Actions that Trigger Future Dated Security Rows.

Security Sets:
Set Up HRMS, Security, Core Row Level Security, Security Sets
Defining what data to be Secured
    Security Set Table :
Transaction Sec. Join Table : Transaction Tables like SJT_PERSON, SJT_DEPT..etc
SJT Temp Table : Temporary table that is used during the SCRTY_SJTUPD Application Engine process that refreshes the transaction security join table. This table must be a copy of the Transaction Sec Join Table along with the PROCESS_INSTANCE field.
SQLID for Value Field List : SQLID of the SQL object that contains a list of the fieldnames found in the transaction security join record. This SQL is used in the App Engine Process SCRTY_SJTUPD when the transaction security join record is refreshed.
Security Access Types for this Set : This is a read-only grid that displays all of the security types that have been created for this security set and indicates which ones have been enabled

   Security Update Groups:
Groupings of data can be selected for refresh on the Refresh Trans.This allows the process to be run for just a subset of data in the SJT instead of having to refresh the entire table.


Security Type :
Set Up HRMS, Security, Core Row Level Security, Security Types
Defining How the data is secured
  Security Type Table :
Enabled :  Enable or Disable of the Security Type
Include Future Dates : Future Dated Actions can be viewed by the persons for the actions specified on the Security Installation component (Not only job, other records having future dated can be handled)
Use Department Security Tree : Check box indicates that the security access type is based on a department security tree
Transaction Table : Transaction record that contains the attribute that this security type is based on. In this case, it is the Department ID in the JOB record.
Security Keys : Provide the keys based on that data secured.Security Key1, Security Key2, Security Key3, Prompt Rec for Sec Key1,Prompt Rec for Sec Key2 and Prompt Rec for Sec Key3.
If the field is a translate value then a view must be created to return those translate values.

Special Job Security Versions : System only displays this group box when the transaction record is JOB. The fields shown will depend on which of these have been enabled on the Security Installation Settings component

   Security Type SQL:
SQLID's for the SQL objects used in the Application Engine program SCRTY_SJTUPD for refreshing the transaction SJT.

Security by Department :
1)Create the Department Security Tree
2)Create permission list
PeopleTools, Security, Permissions & Roles, and Permission Lists
3)Assign Departments to the Permission List
Set Up HRMS: Security: Core Row Level Security: Security by Dept Tree

4)Refresh the SJT_CLASS_ALL process
Set Up HRMS: Security: Core Row Level Security: Refresh SJT_CLASS_ALL

5)Assign the row security permission list on the User Profile General Page
PeopleTools, Security, User Pofiles, User Pofiles, General


Security by Permission List:

Use the Security by Permission List component for all security types that are not based on a department security tree.

1) Create Permission List
PeopleTools, Security, Permissions & Roles, and Permission Lists
2) Set up Security Set, Security Access Type and Keys
Set Up HRMS, Security, Coe Row Level Security, Security by Permission List
3) Group the Permission Lists into One Role
PeopleTools, Security, Permissions & Roles, Roles
4) Assign Roles to the Users using User Profile, Roles Page
5) Refresh SJT_CLASS_ALL, SJT_OPR_CLS and Refresh SJT Trans Process.

Nightly SJT Refresh Process to handle the future dated transactions. i.e when future dated transactions become active, it will delete the previous current data.

 Security Data Inquiry
Set Up HRMS, Security Core Row Level Security, Security Data Inquiry
This component is very useful for testing the Row Level Security after implementing and also very helpful in debugging issues.

Person Model

Person Model is an effective way of tracking employee, Contingent Worker and Person Of Interest in the Organization based on the Organizational/Employee Instance, Assignments with (Employee, Contingent Worker) and without (Person Of Interest) job information .

let us understand important Fields from Person Model.
PER_ORG : How a person is related to the organization (EMP - Employee, CWR - Contingent Worker, POI - Person Of Interest)
ORG_INSTANCE_ERN : How Many Employement Instances a person is having in the Organization.Each Employee Instance should have minimum of one Assignment
EMPL_RCD : How Many Job Assignments a person is having for a Employement Instance in the organization.
POI_TYPE : Person Of Interest Type (Un Known, External Trainer ..etc). Base table to store different Types  is PS_POI_TYPE_TBL, which can be configured going through the navigation Set Up HRMS, Foundation Tables, Organization, Person of Interest Type.

let us understand Important Records from Person Model
PS_PERSON : Every person you enter in the system will have one record in PERSON.Contains the ID and a person’s static data (such as birthdate and birthplace).
PS_PERS_DATA_EFFDT : Maintains Personal History.
PS_PER_ORG_INST : Stores Employement Instances (ORG_INSTANCE_ERN) of a person.
PS_PER_ORG_ASGN : Person Organizational With Assignment i.e Job Assignments(EMPL_RCD) for each Employement Instance(ORG_INSTANCE_ERN).Each row is uniquely identified by the EMPLID, ORG_INSTANCE_ERN and EMPL_RCD .
PS_PER_POI_TYPE : Person Organizational With out Assignment. Person organizational relationships that do not require an assignment (i.e. JOB data). Each row is uniquely identified by the EMPLID and the POI_TYPE (the person of interest type).
PS_PS_POI_TYPE_TBL : Person Of Interest Type,  which can be configured going through the navigation Set Up HRMS, Foundation Tables, Organization, Person of Interest Type.
PS_PER_POI_SCR_DT : History record of information directly related to one Person of Interest relationship without a job (PS_PER_POI_TYPE).
PS_PER_POI_SCRTY : Row Level Security Contains the field and values of data that can be used to define data Permission Security Access for relationships.
PS_PER_POI_TRANS : This is the generic transaction history record for persons of interest

let us look at the navigation's used in the Person Model

Create POI Type : Set Up HRMS, Foundation Tables, Organization, Person of Interest Type.
Creating a Person : Workforce Administration, Personal Information, Add a Person and Workforce Administration, Personal Information,Biographical, Add a Person
Adding a New Employee Instance : Workforce Administration,Organizational Relationships, New Employement Worker Instance
Adding a POI : Workforce Administration,Organizational Relationships, Add a POI Relationship.
Person Organizational Summary : Workforce Administration, Person Organizational Summary
PERSONAL_DATA Snapshot Settings: Set Up HRMS , System Administration, Database Processes, PERSONAL_DATA Settings
PERS_REFRESH Process : Set Up HRMS, System Administration, Database Processes, Refresh Personal Data.
HR_PERSDATA For Future Dated Rows : Set Up HRMS, System Administration, Database Processes , Update Personal Data - Future.

PERSONAL_DATA Snapshot Reporting Table
The first is for the related display of the NAME field in the PeopleTools User Profile page (USER_MAINT component) The second is for customer written processes and pages.

I hope all this information is useful for understanding what is Person Model.