The Employment Dimension has a number of conformed domains which are used in many of the HCM metrics. These domains must be configured correctly for the reports to contain accurate information.
Optional or Mandatory
This task is optional, however the default configuration might not adequately reflect the OLTP setup, so this should be reviewed to ensure the reports are accurate.
Applies to
All sources.
Task description in detail
Configure the domain mappings related to the Employment Dimension. The most important one of these, as it is used by many metrics, is the mapping to worker type and subtype. These are designed as a hierarchy, where worker types from different systems can be conformed onto a single classification. Worker Type is primarily used to distinguish between Employees and Contingent Workers, and Worker Subtype gives a more detailed breakdown within each type.
The domain mapping for Worker Type is derived from the source domain "System Worker Type and User Worker Type". This is derived differently for each source system, and examples are given below for each.
Example for E-Business Suite
The System Worker Type and User Worker Type domain is based on:
System Person Type
User Person Type
Example Requirements: By default contingent workers are all grouped together. Add a sub-type of contingent workers for Interns, identified by the corresponding User Person Type.
Example Implementation:
CWK~INTERN -> CONTINGENT_INTERNThe remaining definition for regular contingent workers is already seeded so no change required.
The table shows how the resulting domain mappings will look, with rows 1 and 2 showing the seeded domain mappings:
| Source Member Code | Column 1 Member Code | Column 2 Member Code | Target Member Code |
|---|---|---|---|
|
CWK~__ANY__ |
CWK |
__ANY__ |
CONTINGENT_CONTINGENT |
|
EMP~__ANY__ |
EMP |
__ANY__ |
EMPLOYEE_REGULAR |
|
CWK~INTERN |
CWK |
INTERN |
CONTINGENT_INTERN |
Multiple match is allowed, for example a contingent worker with person type "Intern" would match the mapping to either CONTINGENT_CONTINGENT or CONTINGENT_INTERN. The exact match on User Person Type takes precedence over "any" type, so the result would be CONTINGENT_INTERN.
Example for Peoplesoft
The System Worker Type and User Worker Type domain is based on:
Organizational Relationship
Person of Interest (POI) Type
Example Requirements: By default, contingent workers are grouped together. Add a sub-type of contingent workers for Interns, identified by the corresponding POI Type.
Example Implementation:
Add the following mappings to the domain map System Worker Type and User Worker Type -> Worker Subtype:
CWR~INT -> CONTINGENT_INTERN
The remaining definition for regular contingent workers is already seeded so no change is required.
The table shows how the resulting domain mappings will look, with rows 1 to 3 showing the seeded domain mappings:
|
Multiple match is allowed, for example a contingent worker with POI Type 'Intern' would match the mapping to either CONTINGENT_CONTRACTOR or CONTINGENT_INTERN. The exact match on POI Type takes precedence over 'any' POI Type, therefore the result would be CONTINGENT_INTERN.
Example for Fusion
The setup in Fusion is exactly the same as for E-Business Suite.
Dependency
None.