Core HR to M3 Interface Data Synchronization

There will always be one and only one company being synchronized from the Core HR side of the interface. Any number of payroll companies can be associated with the Core HR company as “member” companies. An employee will always exist only once in the HR system. An employee SHOULD exist only once in the payroll system, across all companies associated with the Core HR company. If the employee does exist more than once in payroll, then only one “instance” of that employee will be updated since the system uses the employee’s SSN as the key. If there are multiple “instances” of that employee in a single payroll company then only the first “instance” of that employee will be updated. For situations where there are multiple companies in payroll being associated with an Core HR company, the “Department” field in Core HR is used to designate in which company an employee will reside in payroll. The Department field must match exactly to the company code in payroll and should be set up as a required field in Core HR with the appropriate selections in the list.

Technical Process

  1. The interface program gathers required information about the currently logged in user and HR company (see the section “Admin Console > User Setup”). The program passes this information to the Core HR Single Sign-On web page. The HR tab in the program then displays the Core HR system for that company.
  2. When the user clicks the “Sync” button the program gathers necessary data about the company and initiates a SOAP session with the Core HR web service/API.
  3. A collection of employees, and their associated collection properties, is returned from HR and the program then begins a loop, evaluating each employee.
  4. The program first utilizes the SSN on the employee to find a match in the payroll system; if unsuccessful, the program will then utilize the Core HR “PayrollEmployeeID” field followed by the “InfinityHREmployeeID” field to find a match in the payroll system. Note: For companies that have multiple payroll “member companies” (a many-to-one relationship), the Department selector in Core HR is used to designate which payroll company an employee belongs to.
    • If a matching employee is NOT found, then the “Create New Employee” process is started. (Note: When an employee is successfully linked/sync’d, the “Mail Stop” field in payroll is set to the “InfinityHREmployeeID” property from HR, which is the unique identifier in the HR system. Then the “PayrollEmployeeID” property in HR is set to the employee “id” field from payroll.)
    • If a matching employee is found, then the “Update Existing Employee” process is started.
  5. The employee is then created/updated in payroll depending on the process necessary. All employee data is passed through validations before attempting to create or update an employee. (See the section “Validations”.)
    • “Create New Employee” – The program creates a new employee object in payroll using the next payroll employee ID in sequence for that payroll company and populates the employee with the appropriate data from HR (see the section “Data Mapping”). When syncing a new employee into payroll, if the PayrollEmployeeID field is populated in HR the process attempts to use that ID in payroll instead of the next in sequence. (See the section “Data Mapping”.)
    • “Update Existing Employee” – The program updates the employee data in payroll. (See the section “Data Mapping”.)
  6. If the employee is created/updated successfully then the associated dependent collections of data are applied in the following order:
    • Deductions (HR Benefits)
    • Direct Deposits
    • Rates
    • Taxes

Note: Within the HR system you can exclude the above dependent collections from being exposed in the web service to not sync over into payroll using the Web Service Dashboard > Exclusions Tab. This can also be done in the Admin Console of the sync program for the Taxes dependent collections only.

  1. If all dependent collections are updated successfully then the interface program records the current time in the payroll database as the company’s “Last Successful Sync Time” then passes the employee collection object back to the Core HR system.

Deductions (HR Benefits)

Core HR returns a list of benefits set up on the HR employee. For each HR Employee Benefit with an Effective Date on or after the “Sync Deductions Start” date entered in the Admin Console, the Interface first loops through all of these employee benefits to validate that the HR “Plan Code” exists in the Millennium company and that none of the HR Benefit dates overlap each other. The Middleware also requires that the Deduction Dates in Millennium do not overlap with the HR Employee Benefit Effective and Expiration Dates.

As of version 1.0.3.398, if Deduction Code Alt 1 and Deduction Code Alt 2 are used in the HRIS with distinct Deduction Codes, the Middleware will process Deduction Code Alt 1 with the Pre Tax Employee Cost for the Rate and the Deduction Code Alt 2 with the Post Tax Employee Cost for the Rate.

If validated, the interface then loops through these same HR Benefits and attempts to find a matching deduction and/or fringe benefit in payroll. (Note: All benefits are processed as deductions with fringe benefits (i.e., earnings) as applicable except for Group Term Life (GTL) which is a fringe benefit (earning) only in payroll). The possible deductions and earnings code matches are those specified in the “Core HR” code group set up on the payroll company. (See the section “Implementation”). An HR Benefit is matched to a payroll deduction when the HR “Plan Code” and “Effective Date” both match the payroll deduction code and start date respectively. If such a match exists in payroll then the payroll end date and rate (if a deduction) or amount/units (if a fringe benefit) fields are updated with the HR Benefit values. If no such match exists and the HR Benefit is neither waived nor zero (0) employee cost, then a new deduction / earning is created in payroll with the start date, end date, and rate set to the HR Benefit values.

IMPORTANT: If a payroll deduction and/or earning is set up in the “Core HR” code group with a “Start Date” on or after the “Sync Deductions Start” date entered in the Admin Console and there does not exist a match as described above with an HR Benefit, then the deduction will be DELETED FROM PAYROLL! All deductions/fringe benefits in payroll with a Start Date on or after the “Sync Deductions Start” date will be kept in sync with HR.

Otherwise, the non-matched deduction / earning is checked against all of the HR Benefit updates to ensure that there does not exist any overlapping dates; if there is such a conflict, the Interface will generate an error and discontinue any further processing for that payroll employee. Any and all existing payroll deductions / earnings (history) will otherwise remain as is and will not be updated or deleted from payroll.

  • GTL (Group Term Life) – If the HR benefit “PlanCode” field equals “GTL” then the interface looks for an earning/fringe benefit in payroll with a code of “GTL” and a start date matching the “EffectiveDate” field from HR. If a match is found, then the payroll earning “units” field is updated to match the benefit “CoverageAmount” field from HR. The payroll earning “end date” field is also updated to match the “ExpirationDate” field from HR.
  • 401k – The 401k benefit in IHR must be setup as a retirement benefit type. The retirement benefit type is used to determine if the benefit is a 401k. Two benefit plans must be setup in IHR for either percentage or dollar amount contributions. Each benefit plan will have one coverage level. In the coverage level setup, the coverage input type must be set to either the percentage or the flat amount option. This coverage input type will be the key to payroll on how to map the contribution amount. The percentage sign (%) is no longer needed in the plan name to identify a 401k plan. If the HR coverage input type is a flat amount, then the HR benefit’s “PerEmployeeCost” field is used to set the payroll deduction “rate” field. The payroll deduction “end date” field is also updated to match the “ExpirationDate” field from HR.

Note: Two deduction codes are required in payroll, one for percentage and one for dollar amount.

Direct Deposit

Core HR returns a list of direct deposits on the employee in order of flat amounts first (ascending) then percentages (ascending).

  • Due to the criticality of the sequence of direct deposits in payroll, the program loops through the direct deposits returned from HR and matches them to the entries in payroll.
  • If any of the key information is different (i.e., ABA Routing number, account number, or account type), then the interface knows something has been changed in HR; it then removes that given direct deposit record from payroll and recreates using the data from HR with a blank Prenote Date.
  • Since the direct deposits are processed in the exact order required, the program assigns the sequence number in payroll by sequentially incrementing each direct deposit record.
  • (Note: Core HR returns all direct deposit items regardless of active status. These are filtered out by using the “IsActive” property returned from HR.)

IMPORTANT: If a direct deposit exists in payroll but it does not exist in HR, the direct deposit will be DELETED FROM PAYROLL! The list of direct deposits in payroll will be kept in sync with HR.

When populating the direct deposit data in payroll some data translation is necessary.

  • If the “DepositPercent” property is not equal to 0 (zero) in HR then the “amountCode” field is set to a percent sign (“%”) in payroll and the “amount” field is set to the value in “DepositPercent” from HR.
  • If the “DepositPercent” property IS equal to 0, then the “amountCode” field in payroll is set to blank and the amount field to the value passed from the “DepositAmount” property in HR.
  • The program looks for the word “Checking” in the “AccountType” property passed from HR. If it is found, the program sets the “checking” field to 1 (checked or true) in payroll. Otherwise the “checking” field is set to 0 (unchecked or false).

Compensation Rates

Core HR returns a list of the employee’s base rates in descending order by their “EffectiveDate” property (most recent first). The program determines the end date to put on the rate in payroll based on the “EffectiveDate” of the prior rate passed from HR.

  • If there is no prior rate (i.e. it is the first one) then the end date on the rate is set to 12/31/2100 (“forever”) in payroll.
  • If the “Update Base Autopay” option is enabled on the company in the Admin Console, then the “autopay” field in payroll is set to “Salary” if the “RateType” in HR is “Salary” or to blank if the “RateType” in HR is “Hourly”.
  • If the option is not enabled then the “autopay” field is always set to blank in payroll.

IMPORTANT: If a rate exists in payroll but it does not exist in HR, the rate will be DELETED FROM PAYROLL! The list of rates in payroll will be kept in sync with HR.

  • New Employees: Since it is necessary to use the Millennium Employee Creator object in payroll to create a new employee and the “baserate” field is a required field, the program sets the rate and salary to 0, initially. Then after the new employee is created it updates the rates using the same method as an existing employee. The function that updates the rates looks for this temporary, bogus rate of 0/0 and updates it with the first rate returned from HR.
  • Pay Schedule: The program first attempts to match the Core HR Employee Information “Pay Schedule” with the Payroll pay frequency by name (e.g., “Semi-Monthly” in Core HR = “Semi-Monthly” description in the payroll Frequencies tab); any “Pay Schedule” may be so matched regardless of the actual check dates but the match must be exact (e.g., “Bi-Weekly” will not match to “Biweekly”) non respective of capitalization. If no match is found, the program will then attempt to match the number of Core HR pay periods in the “Pay Schedule” to one (1) of five (5) payroll base pay frequencies: “W” – Weekly ( 52 pay periods); “B” – Biweekly ( 26 pay periods); “S” – Semi-Monthly (24 pay periods); “M” – Monthly (12 pay periods); and “Q” – Quarterly (4 pay periods).

Taxes

Core HR returns a list of employee Federal taxes and State taxes separately, in descending order by their “TaxYear” property (most recent first) with one and only one “Active Filing” set for state taxes. Since taxes are all stored in one table in payroll, the program groups these together. The program loops through the list and utilizes the most recent Federal and the one state “Active Filing” for each collection from HR. The properties from the first item are applied to the appropriate tax in payroll. The employee “workState” field is populated in payroll from the HR State tax “UnemploymentState” property.

  • Exempt Employees: If an employee is marked as “Exempt” in HR, the interface sets the employee’s taxes to “Married” status and “99” exemptions for Federal and CA State taxes. For Federal and all State taxes, the interface further sets the “additionalAmount” and “additionalPercentage” fields in payroll to 0 (zero) and sets the “overrideTaxCalc” field to 1 (checked or true).
  • New Employees: Since it is necessary to use the Millennium Employee Creator object in payroll to create a new employee and the “fitw” and “sitw” fields are required, the program sets the “fitw” field to “FITW” and the “sitw” field to the active HR Employee State Tax “IncomeFilingState” value; the “sui” and “workState” fields are set to the active HR Employee State Tax “UnemploymentState” value. After the new employee is created it updates the taxes using the same method as an existing employee. The function that updates the taxes looks at the first (most recent) tax entry for Federal and State and updates the other fields in payroll appropriately.
  • Tax Forms: The Core HR Employee Information “Tax Form” is matched by with the Payroll tax form by name only and must therefore by a valid tax form in Payroll (e.g., “W2”, “1099M”, “1009R”, “Other”). If the Core HR field is left blank, then any new payroll employee will be created with a default tax form of “W2”; otherwise, any employee with a blank Core HR “Tax Form” will not produce an error.
    Changing States: Due to the complicated nature of setting up new state taxes for employees in payroll, changing states is not supported by the interface. An error will be produced during synchronization. The appropriate taxes must be set up on the employee in payroll first. Then normal synchronization can resume for that employee.
  • Georgia Employees: For the handling of Georgia State Tax Allowances, logic was added where if the Allowances are greater than “2” and the State equals “GA” the additional allowances will populate the “Addl” field in M3. [Example: if in Core HR 3 were entered in the Allowances field, upon syncing the “Primary” field would be set to “2” and the “Addl” would be set to “1”.]

Accruals

If managing accruals in Millennium, the accruals would be returned from Millennium to Core HR. The sync will look to see if there are any changes in the employees payroll accrual record, accrual date change or modified date and if something has changed since the last sync it would pass the updated accrual information to Core HR. If there were no changes than no accrual collection would be passed.

Configuration for a given payroll accrual balance to be updated in HR requires the following:

  1. The “Update Time Off Accruals” is set as “From Payroll to HR” in the Admin Console.

    Data_Sync_-_Accruals_-_00.png

  2. Payroll time off accruals that will be updated in HR are those that are setup to print any type of hourly accrual on the employee’s paycheck (i.e., that show either “B” or “H” in the Millennium company “Accruals” tab “Check Stub / Desc” field).

    Data_Sync_-_Accruals_-_01.png

  3. There must be a matching accrual “Type” set up in HR for the given payroll Accrual Code (e.g., HR Type of “PTO” must exist for a payroll accrual code of “PTO”).
    ***Accrual Type in payroll is equivalent to Time Off Type in HR.
  4. The given payroll accrual has been updated subsequent to the last successful synchronization date/time as determined by either the payroll employee’s “Last Accrue Date” or the database “lastChange” date (i.e., the date at which the payroll system recorded the most recent change(s) to the employee accrual record). If the above configuration requirements are met then the “Available Hours” from the employee’s payroll accrual will update the employee’s HR time off “Balance” value upon the next successful synchronization of the HR company.

Validations

Before the sync process loops through the employee collection returned from HR, the company(s) in payroll is validated with the following requirements:
The standard employee status codes exist on the company level:

  • A – Active
    LOA – Leave of Absence
    T – Terminated
    R – Retired

Note: Full Time and Part Time Employee Statuses from HR map to Active in payroll. Undefined is ignored in the sync program.

Once the payroll company had been validated, each HR employee is validated with the following requirements before being created and/or updated.

  1. SSN, Last Name, and/or First Name are not blank.
  2. The Income Tax Filing and the Unemployment Filing state(s) exist in the payroll company for all employees that are not 1099M or terminated.
  3. The state “Filing Status” is a valid for the Income Tax Filing State.
  4. The “Tax Form” must be valid if not blank.
  5. The “CostCenter1-5” values from HR exist at the company level in payroll OR the payroll company has default values specified for each level being utilized.
  6. The “UserDefinedLookup1-5” values match to “yes”, “no”, “true” or “false”. (These fields are mapped to checkboxes in payroll.)
  7. The deduction codes exist at the company level in payroll.
  8. The Pay Schedule is not blank.
  9. There is not more than one (1) active 100% direct deposit item for the HR employee.
  10. The “TerminationReason” value from HR exists in the list of Term Reasons in payroll.
  11. The “”EmployeeType”” value from HR exists in the list of Employee Types in payroll.
  12. The “Ethnicity” value from HR exists in the list of Ethnicity Codes in payroll.
  13. The “EEOClass” value from HR exists in the list of EEO Class Codes in payroll.
  14. The “TimeManager” value from HR exists in the list of Supervisors in payroll. Note: The supervisor name from HR is matched to the “description” field in the list of supervisors in payroll. This field can be excluded from the sync by unchecking the “Sync Supervisors” box on the Admin Console.
  15. The “WokersCompCode” value from HR exists in the list of WC Codes in payroll.

Other general validations occur such as properly formatted dates, strings not being stored as numbers, etc.

Was this article helpful?
0 out of 0 found this helpful