Diving straight into the topic,
An Effective Date is the date from which the row of data associated with the date becomes valid for use and or becomes effective.Before the corresponding effective date occurs any data if present in the application will not be picked up by the system for any processing.
for example, if your PS_LOCATION_TBL has rows with an effective date of 01.01.2016 then till end of 31st Dec 2015 these rows will not show up in any of the pages where the PS_LOCATION_TBL is used.
Another example, if an employee has a row in the PS_JOB table with an effective data of 01.01.2016 with an action “Transfer to Afflilate”, the employee shows up on the rolls of the parent company till end of day 31st Dec 2015 and reflects on the rolls of the affilate company from 01.01.2016.
Care has to be taken while choosing effective dates for control tables especially, because in many cases inbuilt peoplecode compares effective dates of control data and may ignore any data which is greater than a particular effective date. Hence for particular control tables care should be taken to chose the earliest possible effective date.01.01.1900 is a safe bet which many implementations follow.
Effective Status is a value associated with an effective dated row, the possible values are “Active” and “Inactive”. The default value is “Active”, you can mark a row as “Inactive” when is does not hold any value for your implementation.
for e.g. if you organisation revises the list of designations and decides to stop using a set of 50 designations, then the effective status of these 50 designations can be set to “Inactive”, by doing so the 50 designations aka Jobcodes will not show up in the Jobcode prompts on the relevant pages.
When you go through planning your implementation of PS HCM, it is important to conceptualise the way in which your organisation’s data will be represented in HCM, if your organisation is spread across various countries or if your organisation has various business areas like manufacturing,logistics, pharmaceuticals etc you may opt for a multi company representation at the highest level.
Once this is out of the way next you may want to look at then grouping data with some similarities in business rules, payroll processing etc together , these logical groups are what are referred to as Business Unit. so you may group all KPO under one business unit for example, you may group Sales into another and all corporate functions into another, Business units are thus flexible structures that enable you to put together data which can be handled uniformly together. As another example if you are an IT organisation, you may want to group each of your verticals as BUs or another approach would be to organise each of your client accounts as a BU or even each geographical location of your organisation can be a BU. There is thus this flexibilty but do remember that a BU always ties to an employee’s job data and an user will be able to see other control data like Jobcodes, Salary plans etc for an employee based on the employee’s BU so take cognizance of this fact while planning the data setup. And do remember your PS HCM implementation requires atleast one BU to be created.
Set IDs & Table Sets
A set ID is a primary key present in all the control tables and a set ID lets you to control which set of rows in a control table can be shared across BUs.
The set of all the rows in a control table having the same set id is a Table Set.
And sharing table sets across various BUs is table set sharing.