Field mappings

The Employee Import allows these fields to be mapped from an external system's data:

  • CALGRP_NAME: Calculation group
  • ENT_POLICY: Entitlement policy
  • PAYGRP_NAME: Payroll group
  • SHFTPAT_NAME: Shift pattern
  • WBG_ID: Security group

For example, an external system might have three fields that describe the pay group to which an employee belongs. In this case, the Employee Import allows you the flexibility to map the combination of the three fields into the PAYGRP_NAME field.

These fields can receive up to 10 factors (10 external field values, separated by the tilde, ~, symbol), which are mapped to a single shift pattern, calculation group, payroll group, security group, or entitlement policy field.

The mapping definitions for these fields are specified in the Interface Layout page. See Defining the interface layout.

The Workforce Management application installs with a set of default standard mapping definitions, which are listed in the Mapping Definitions page:

  • Default ShiftPattern Mapping
  • Default PayGroup Mapping
  • Default CalcGroup Mapping
  • Default SecurityGroup Mapping
  • Default Entitlement Policy Mapping

These mappings do not perform any mappings by default; instead, they use the value in the file. This implies that the file must contain only one factor that maps directly to the application field (shift pattern, calculation group, payroll group, security group, or entitlement policy).

If any type of mapping is required for any of the fields, you must create a new mapping definition.

Some scenarios where you are required to create a mapping definition are described below (followed by XML mapping examples).

Example: One-to-one mapping

The external system field does not map directly to the Workforce Management field and a one-to-one mapping is required.

For example, if external shift pattern A is mapped to internal shift pattern ALL DAYS, and external shift pattern B is mapped to internal shift pattern ROTATING NIGHTS, this is the XML mapping:

<mapping>
<!-If factor 1 is A, maps to ALL DAYS -->
   <row-match> 
      <field-match fieldname="1" matchvalue="A"/> 
      <output-row> 
          <output-field name="1" value="ALL DAYS"/> 
      </output-row> 
  </row-match> 

<!-If factor 1 is B, maps to ROTATING NIGHTS -->
   <row-match> 
      <field-match fieldname="1" matchvalue="B"/> 
      <output-row> 
          <output-field name="1" value="ROTATING NIGHTS"/> 
      </output-row> 
  </row-match> 

</mapping>

The mapping definition must have all possible values that are in the CSV external file to be imported. If the Employee Import comes across a new value that does not have a mapping, this occurs:

  • If the field is defined in the Interface Reference Settings section, the appropriate action is implemented (either insert the record as new, or reject the record).
  • If the field is not defined in the Interface Reference Settings section, an error is generated for that record.

Example: Two-to-one mapping

The external system might have many fields (that is, many factors) that map to one Workforce Management field.

For example, if an external system has two factors that describe the Pay Group field, this is the XML mapping:

<mapping>

<!-If field 1 is HOURLY_FULLTIME and field 2 is A , then the record 
maps to P1. 
Note that fieldName corresponds to the index in the factor value. 
So for a value of "HOURLY_FULLTIME~A" in the PAYGRP_NAME field, 
fieldName 1 is HOURLY_FULLTIME and fieldName 2 is A -->
   <row-match> 
      <field-match fieldname="1" matchvalue="HOURLY_FULLTIME"/> 
      <field-match fieldname="2" matchvalue="A"/> 
      <output-row> 
          <output-field name="1" value="P1"/> 
      </output-row> 
  </row-match> 

<!-If field 1 is HOURLY_PARTTIME, then the record maps to P2 -->
   <row-match> 
      <field-match fieldname="1" matchvalue="HOURLY_PARTTIME"/> 
      <output-row> 
          <output-field name="1" value="P2"/> 
      </output-row> 
  </row-match> 

<!--A row-match element without field-match elements matches all rows, 
this is used when there is no match. Do not use this method if there 
are possible records that needs to be rejected -->
	
   <row-match> 
      <output-row> 
          <output-field name="1" copyfield="1"/> 
      </output-row> 
  </row-match>

</mapping>

Example: Many-to-one mapping

In a custom policy mapping, an employee can match multiple policies separated by a pipe (|) symbol. Each set of fields per pipe (|) symbol can have a maximum of 10 fields (factors) separated by the tilde (~) symbol.

For example, assume this is the XML mapping:

<mapping>

<!-If field name 1 is CA and field name 2 is EXEMPT and field name 3 is 
FULLTIME, then the record maps to P1 value from ENTPOL_NAME column in 
ENT_POLICY table-->

  <row-match>
    <field-match fieldname="1" matchvalue=”CA”/>
    <field-match fieldname="2" matchvalue=”EXEMPT”/>
    <field-match fieldname="3" matchvalue=”FULLTIME”/>
    <output-row>
      <output-field name=”1” value=”P1”/>
    </output-row>
  </row-match>

<!-If field name 1 is CA and field name 2 is EXEMPT and field name 3 is 
PARTTIME, then the record maps to P2 value from ENTPOL_NAME column in 
ENT_POLICY table-->

  <row-match>
    <field-match fieldname="1" matchvalue=”CA”/>
    <field-match fieldname="2" matchvalue=”EXEMPT”/>
 
    <field-match fieldname="3" matchvalue=”PARTTIME”/>
    <output-row>
      <output-field name=”1” value=”P2”/>
    </output-row>
  </row-match>

<!-If field name 1 is CA and field name 2 is NON-EXEMPT and field name 
3 is PARTTIME and field name 4 is NON-UNION, then the record maps to P3 
value from ENTPOL_NAME column in ENT_POLICY table-->

  <row-match>
    <field-match fieldname="1" matchvalue=”CA”/>
    <field-match fieldname="2" matchvalue=”NON-EXEMPT”/>
    <field-match fieldname="3" matchvalue=”PARTTIME”/>
    <field-match fieldname="4" matchvalue=”NON-UNION”/>
    <output-row>
      <output-field name=”1” value=”P3”/>
    </output-row>
  </row-match>

<!-If field name 1 is CA and field name 2 is EXEMPT and field name 3 is 
PARTTIME and field name 4 is UNION and field name 5 is MAX and field 
name 6 is UDF6 and field name 7 is UDF7 and field name 8 is UDF8 and 
field name 9 is UDF9 and field name 10 is UDF10, then the record maps 
to P4 value from ENTPOL_NAME column in ENT_POLICY table-->

  <row-match>
    <field-match fieldname="1" matchvalue=”CA”/>
    <field-match fieldname="2" matchvalue=”EXEMPT”/>
    <field-match fieldname="3" matchvalue=”PARTTIME”/>
    <field-match fieldname="4" matchvalue=”UNION”/>
    <field-match fieldname="5" matchvalue=”MAX”/>
    <field-match fieldname="6" matchvalue=”UDF6”/>
    <field-match fieldname="7" matchvalue=”UDF7”/>
    <field-match fieldname="8" matchvalue=”UDF8”/>
    <field-match fieldname="9" matchvalue=”UDF9”/>
    <field-match fieldname="10" matchvalue=”UDF10”/>
    <output-row>
      <output-field name=”1” value=”P4”/>
    </output-row>
  </row-match>

</mapping>

Assume that the ENT_POLICY field in the CSV file has this sample string format:

  • Emp1: CA~EXEMPT~FULLTIME~
  • Emp2: CA~EXEMPT~FULLTIME~|CA~EXEMPT~PARTTIME~
  • Emp3: CA~EXEMPT~PARTTIME~ ~|CA~NON-EXEMPT~PARTTIME~NON-UNION~
    Note: Value before the fourth tilde is empty for the first set.
  • Emp4: CA~NON-EXEMPT~PARTTIME~NON-UNION~ ~ ~ ~ ~ ~ ~| CA~EXEMPT~PARTTIME~UNION~MAX~UDF6~UDF7~UDF8~UDF9~UDF10~
    Note: Values before the fifth, sixth, seventh, eighth, ninth, and tenth tildes are empty for the first set.

When the Employee Import is run, the employees are assigned to these entitlement policies:

  • Emp1 is assigned to the P1 entitlement policy.
  • Emp2 is assigned to the P1 and P2 entitlement policies.
  • Emp3 is assigned to the P2 and P3 entitlement policies.
  • Emp4 is assigned to the P3 and P4 entitlement policies.