Indicative Data
Recommendation, 2007 April 15
Document Editor:
Kim Bartkus, HR-XML Consortium
Schema Editors:
Buddy Kresge, BenefitsXML
Paul Kiel, HR-XML Consortium
Contributors:
Joanne Fritz, ADP
Buddy Kresge, BenefitsXML
Vamsee Srikakolapu, CitiStreet
Chris Clark, Fidelity
Toby Shaw, Hewitt
Kim Bartkus, HR-XML Consortium
Chuck Allen, HR-XML Consortium
Paul Kiel, HR-XML Consortium
Lon Pilot, Lon Pilot, LLC
Bill Kerr, Oracle
Jean Handel Baily, SAP
Copyright © 2007 HR-XML Consortium, Inc.
Abstract
This document describes the specification for XML indicative data exchange between Business Process Outsourcers (e.g., TBOs, HROs, TPAs, etc.), their clients and other vendors.
Table of Contents
1.2.2 Items within the Design Scope
1.2.3 Items outside the Design Scope. 5
2 Supported Business Processes
2.3 Employee Indicative Data Maintenance
3.1.2 Schema Elements/Attribute Details
3.2.2 Schema Elements/Attribute Details
3.3.2 Schema Elements/Attribute Details
3.4.2 Schema Elements/Attribute Details
3.5.2 Schema Elements/Attribute Details
3.6.2 Schema Elements/Attribute Details
3.7.2 Schema Elements/Attribute Details
3.8.2 Schema Elements/Attribute Details
3.9.2 Schema Elements/Attribute Details
3.10 Indicative Reusable Types
3.10.1 Schema Elements/Attribute Details
4 Implementation Considerations
4.3 Information Not Known by Source System
4.5 Elements Prepended with “Is”
4.10 PayCycleFrequency and payRateFrequency
4.11 UserArea Extension Element
4.12 IndicativeBatch.xsd vs. IndicativeData.xsd
4.13 Use (not abuse) of the EmployeeGroup element
4.14 Use of TransactionType and changeType
5 Appendix A – Open Issues. 46
6 Appendix B - Document Version History
7 Appendix C – Related Documents
8 Appendix D - HR Administrator Task Processing Scenarios
1 Overview
The project will deliver several schemas to support the exchange of "indicative data." The phrase indicative data is used to describe basic employee census data (sourced from payroll or HRIS systems) that is supplied by an employer to a third-party administrator or business process outsourcer (BPO). The data transfers could be batch transfers for the purpose of initially populating the system of an outsourcing company or service providers or the transfers could be a single, real-time maintenance or corrective changes.
A comprehensive HR-XML standard for HR data is required. Creating or modifying defined HR-XML standards would simplify data exchange between companies engaged in HR related activities. A single industry standard would revolutionize HR/benefits outsourcing administration and spur pre-programmed HR-XML by software companies. These HR-XML standards could be defined for the conversion and maintenance of employee data as well as data error reporting.
1.1 Objective
The objectives of this project are to provide HR-XML standards to:
· Simplify data exchange for converting and updating participant data.
· Encourage ERP and other software companies to pre-program additional functionality using HR-XML standards.
· Enable real-time maintenance transactions between employer and outsourcing service providers and/or between difference outsourcing service providers.
· Make routine data exchanges easier to setup and maintain between and among employers and payroll, benefits, consulting, actuarial, and other service providers.
1.1.1 Domain Issues
· Current HR-XML standards lack data necessary for exchange of indicative data
· Multiple proprietary formats exist for employee data exchange
1.1.2 Business Reasons
Adopting new HR-XML standards for indicative data exchange would:
· Reduce the costs for all companies involved in exchanging employee data
· Accelerate receipt of benefits and information by employees
· Accelerate delivery times for implementing new clients on BPO platforms
· Enable informed decisions by companies considering outsourcing as to the technical and structural requirements for data exchange
· Facilitate real-time data exchange and processing
1.2 Scope
Most of the components required for the indicative data project have been developed for broad re-use internationally. Any country-specific components will be implemented within the localization architecture recommended by the HR-XML Technical Steering Committee.
1.2.1 Major Components
The Indicative Data specification includes a high level indicative schema that may be used independently or within the Indicative Batch schema. Additionally, eight reusable types are defined in separate schemas. A ‘reusable’ schema was also developed, which contains XML fragments that are used throughout the specification.
· Batch or ‘Real Time’
· Employer
· Personal
· Employee
· Employment
· Job
· Organizational
· Remuneration
· Affiliations
· Reusable Component
1.2.2 Items within the Design Scope
This specification includes data exchange between Business Process Outsourcers (e.g., TBOs, HROs, TPAs, etc.), their clients and other vendors. It does not include the transaction between an Applicant Tracking System and the HRMS. The data in an HRMS system that is in scope for this schema is data that is required for the initial setup and on-going maintenance for benefits administration and payroll. As far as payroll is concerned, the actual information to “run payroll” is covered in HR-XML’s PayrollBenefitsDeduction and PayrollInstructions schema.
1.2.3 Items outside the Design Scope
This specification is NOT intended to contain all of the information contained in an HRMS system. Specifically, data around pure “internal HR” functions are beyond the scope of this schema. For example, training, skills, assessments, grievances, performance, competencies, etc. are not covered by this schema.
2 Supported Business Processes
2.1 Trading Partner Roles
There are two primary participants when considering the usage of the Indicative Data schema. At the most rudimentary level, you have the Employer and the Payroll/Benefits Outsourcer (“Outsourcer”). The Employer (or its surrogate) is the “system of record” for all indicative data. That is, the Employer will provide the necessary information from its HRMS to an Outsourcer. This indicative data will enable the Outsourcer to fulfill their service obligations (agreed to with the Employer in their outsourcing contract).
However, there are really two “functional” roles that exist in every Indicative Data business case; that of a “Sender” of information and that of a “Receiver” of information. From an operations standpoint, who is dubbed to be an authorized sender or receiver is usually at the direction of the Employer. For example, an Employer may be the initial “sender” of indicative data to a benefits eligibility & enrollment outsourcer. In that case, the Outsourcer would play the role of the “receiver” of indicative data (as they will load that data into their systems – thus “receiving” the data). Now, the employer may, in turn, instruct that outsourcer to send indicative data to yet another outsourcer. In that case, the first Outsourcer would now take on the role of “sender” (as they are sending the data, per the instructions of the Employer) and the other Outsourcer is the “receiver” (as this second outsourcer must now load that data into their systems).
Note: A “Sender” can send more indicative data than is required by the “Receiver”. However, there is no implication or obligation that the receiver has to consume ALL sent information. A receiver only needs to consume that indicative data that is of interest to the Outsourcer. This “agreement” allows an Employer to have one Indicative Data XML document and send it to multiple Receivers/Outsourcers.
2.2 Client Setup
2.2.1 Summary
“Congratulations! You are our chosen outsourcer!” Great…..now what?!
This very use case was the initial impetus for the creation of the Indicative Data schema. Prior to the introduction of Indicative Data, the schemas in HR-XML’s benefits and payroll space had assumed the passing of information between trading partners during “normal” day-to-day operations. However, what was missing was the schema that allowed employee indicative data to be passed prior/“in order” to start day-to-day operations. In other words, data needed to be passed prior to the commencement of outsourced services. This period is often referred to in the industry as “client setup”.
For example, a benefits enrollment & eligibility Outsourcer cannot begin to enroll employees until that outsourcer knows a) who the employees are b) the employee indicative data to determine benefits eligibility.
Likewise, a payroll vendor might need to know detailed information about the employee in order to determine when their payroll is run.
Both of these situations illustrate the need for the Outsourcer to “setup”/establish the employer’s employees in systems(s) prior to the providing services.
2.2.2 Use Case Scenarios
- Initial indicative data feed, from Employer, for one time establishment of employee population. Outsourcer now has employee information in their system(s). Now they can start running the business processes for which they’ve been contracted. For example, a benefits outsourcer may determine eligibility or a payroll outsourcer may determine payroll groups.
- An Outsourcer, acting as a “Sender” surrogate for the employer, sends data to another Outsourcer (“Receiver”). This enables the second outsourcer to initially “load” their system(s) with the appropriate indicative data.
2.2.3 Diagrams
Data feed from Employer (sender of IndicativeData) to Outsourcer (receiver of IndicativeData). Outsourcer runs necessary business processes.
Employer instructs OutsourcerA to send indicative data to OutsourcerB. Outsourcer runs necessary business processes.
2.3 Employee Indicative Data Maintenance
2.3.1 Summary
Once an Employer has been “setup” with the Outsourcer, changes to indicative data may need to be reported to the Outsourcer. The reason is that sometimes data changes may alter the way the employee is serviced by the Outsourcer. For example, an address change may trigger a change in what medical benefits the employee can receive. An employee becoming an executive may alter the way that employee is handled when contacting the call-center. The possibilities are endless.
The Indicative Data schema can be used post-initial-setup to facilitate ongoing exchanges of employee indicative data between a Sender (i.e. Employer) and Receiver (i.e. Outsourcer).
2.3.2 Use Case Scenarios
- Sender transmits indicative data changes for certain employees (e.g. changes only)
- Sender refreshes indicative data at certain intervals so as to keep the Outsourcer’s systems in synch with the Employer’s HRMS (full files)
- Indicative data is resent at the beginning of important benefits/payroll administration business processes (e.g. open enrollment)
2.3.3 Diagrams
Employer (sender of IndicativeData) sends ‘changes’ to Outsourcer (receiver of IndicativeData). Outsourcer processes changes.
Employer sends ‘full file’ to Outsourcer. Outsourcer updates database.
3 Schema Design
3.1 Indicative Batch
3.1.1 Schema Diagram
3.1.2 Schema Elements/Attribute Details
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
TransactionType - IndTransactionTypeEnum - S
(1/1) |
Aggregates a number of related indicative transactions together into a single transmission. |
|
/ IndicativeBatch/ |
- IndTransactionTypeEnum - S (1/1) |
In the context of a batch
transaction, specifies if it is a full or changed payload. |
|
/ IndicativeBatch/ |
- AnyDateTimeType - S (1/1) |
The date the XML file was created
by the system transmitting the information. |
|
/ IndicativeBatch/ |
- EntityIdType - S (0/1) |
Code identifying the transaction
originator, typically the sender's taxpayer |
|
/ IndicativeBatch/ |
- xsd:string - S (0/1) |
Name of the transaction originator. |
|
/ IndicativeBatch/ |
- AnyDateTimeType - S (0/1) |
Date representing baseline for change data. |
|
/ IndicativeBatch/ |
- EntityIdType - S (0/1) |
Code identifying the
transaction's recipient typically the recipient's taxpayer |
|
/ IndicativeBatch/ |
- xsd:string - S (0/1) |
Name of the transaction recipient. |
|
/ IndicativeBatch/ |
- EntityIdType - S (0/1) |
An identifier to tie the original
transaction to the acknowledgement of that transaction. |
|
/ IndicativeBatch/ |
- UserAreaType - S (0/1) |
Allows the user to extend the specification in order to provide additional information that is not captured in the standard. |
|
Global
types |
ContentModel* |
Definition |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Change, Full |
Globally scoped data type. See element or attribute declaration for definition. |
3.2 Indicative Data
3.2.1 Schema Diagram
3.2.2 Schema Elements/Attribute Details
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
- IndEmployeeRosterType - (1/1) |
Data necessary to administer a
benefits, pension, or payroll plan that is not necessarily tied to any
payroll or benefits action. |
|
/ IndicativeData/ |
- IndOrganizationRefType - S (1/1) |
Container for employer-related information. |
|
/ IndicativeData/ |
- IndEmployeeType - S (1/*) |
Contains general information about the employee. |
|
/ IndicativeData/ Employee/ |
- IndPersonalInfoType - S (0/1) |
Contains various data about a person. |
|
/ IndicativeData/ Employee/ |
- IndEmployeeInfoType - S (0/1) |
A collection of employee-related information about an individual. |
|
/ IndicativeData/ Employee/ |
- IndEmploymentInfoType - S (0/1) |
A collection of information about a current or former employment engagement of the person. |
|
/ IndicativeData/ Employee/ |
- IndJobPositionInfoType - S (0/1) |
Contains information about the work a person does at an organization. |
|
/ IndicativeData/ Employee/ |
- IndOrganizationalInfoType - S (0/1) |
Contains information about the employee’s place within the organization's structure. |
|
/ IndicativeData/ Employee/ |
- IndRemunerationInfoType - S (0/1) |
A collection of information about remuneration for a particular job or position. |
|
/ IndicativeData/ Employee/ |
- IndAffiliationInfoType - S (0/1) |
Contains information about an individual's participation in a professional or industry group or association in which the employer has an interest. |
|
/ IndicativeData/ Employee/ |
- UserAreaType - S (0/1) |
Allows the user to extend the specification in order to provide additional information that is not captured in the standard. |
|
/ IndicativeData/ |
- UserAreaType - S (0/1) |
Allows the user to extend the specification in order to provide additional information that is not captured in the standard. |
|
Global
types |
ContentModel* |
Definition |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Add, Correct, Delete, Update |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
Employer - IndOrganizationRefType - S
(1/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
changeType
- IndChangeTypeEnumType - |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndEmployeeType] / |
- IndChangeTypeEnumType - |
Specifies
how the receiving system should process the data being transmitted from the
sending system. |
|
/
[IndEmployeeType] / |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
/
[IndEmployeeType] / |
- LocalDateType - |
The date
through which the event is active or valid, or the date the event ends. |
|
|
OrganizationName
- xsd:string - S
(0/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndOrganizationRefType]/ |
- xsd:string - S (0/1) |
The name by which an organization or enterprise is known as established under the laws of a country, state, province or ruling governmental body for the purpose of conducting business transactions. |
|
/
[IndOrganizationRefType]/ |
- EntityIdType - S (0/1) |
Unique identifier for the organization. It may be an internal identifier assigned by the sender. |
|
/
[IndOrganizationRefType]/ |
- EntityIdType - S (0/1) |
Unique
externally issued company identifier. |
|
/
[IndOrganizationRefType]/ |
- EntityIdType - S (0/1) |
A unique legal identifier for an entity. |
3.3 Person Info
3.3.1 Schema Diagram
3.3.2 Schema Elements/Attribute Details
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
- IndPersonalInfoType - S (0/1) |
Contains various data about a person. |
|
|
xsd:extension base: IndBasePersonalInfoType |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [IndPersonalInfoType]/ |
- IndDependentInfoType
- S (0/*) |
Contains information related to
the dependent. |
|
/ [IndPersonalInfoType]/
Dependent/ |
- IndDependentRelationship
EnumExtensionType - S (1/1) |
Describes the nature of the relationship or connection between two elements or entities. |
|
/ [IndPersonalInfoType]/
Dependent/ Relationship/ |
- IndDependentRelationshipEnumType - C (0/1) |
A list of standard values. |
|
/ [IndPersonalInfoType]/
Dependent/ Relationship/ |
- xsd:string - C (0/1) |
A string used to extend a list of non-standard values. |
|
/ [IndPersonalInfoType]/ |
- UserAreaType - S (0/1) |
Allows the user to extend the specification in order to provide additional information that is not captured in the standard. |
|
/ |
PersonLegalId - EntityIdType - S (0/*)
|
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [IndBasePersonalInfoType]/ |
- EntityIdType - S (0/*) |
A unique government or other
legal identifier for a person. |
|
/ [IndBasePersonalInfoType]/ |
- EntityIdType - S (0/*) |
A unique identifier for an legal id that had been incorrectly recorded or
transmitted. |
|
/ [IndBasePersonalInfoType]/ |
- EntityIdType - S (0/*) |
A unique identifier for a person. |
|
/ [IndBasePersonalInfoType]/ |
- EntityIdType - S (0/*) |
A unique identifier for an person id that had been incorrectly recorded or
transmitted. |
|
/ [IndBasePersonalInfoType]/ |
- EffectiveDatedPersonNameType - S (0/*) |
The name of a person. |
|
/ [IndBasePersonalInfoType]/ |
- LocalDateType - S (0/1) |
A person's birth date. |
|
/ [IndBasePersonalInfoType]/ |
- LocalDateCertifiedType - S (0/1) |
Date of death for subscriber or
dependent. |
|
/ [IndBasePersonalInfoType]/ |
- GenderCodeType - S (0/1) |
Describes the sex of the person
based on representation of human sexes. |
|
/ [IndBasePersonalInfoType]/ |
- IndMaritalStatusType - S (0/*) |
Contains information on the marital status of the person. |
|
/ [IndBasePersonalInfoType]/ |
- EffectiveDatedContactMethod WithPrecedenceType - S (0/*) |
Contains information to contact a
person or entity. |
|
/ [IndBasePersonalInfoType]/ |
- CitizenshipType - S (0/*) |
Specifies the country or countries where a person retains legal citizenship. |
|
/ [IndBasePersonalInfoType]/
Citizenship/ |
- CountryCodeType - S (1/1) |
Contains the ISO 3166-1
two-character country code. |
3.4 Employee Info
3.4.1 Schema Diagram
3.4.2 Schema Elements/Attribute Details
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
- IndEmployeeInfoType - S (0/1) |
A collection of employee-related information about an individual. |
|
/ |
EmployeeId - EntityIdType - S (0/*)
|
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [IndEmployeeInfoType]/ |
- EntityIdType - S (0/*) |
A unique identifier for an employee. |
|
/ [IndEmployeeInfoType]/ |
- EntityIdType - S (0/*) |
A unique identifier for an employee
id that had been incorrectly recorded or transmitted. |
|
/ [IndEmployeeInfoType]/ |
- EffectiveDatedContactMethod WithPrecedenceType - S (0/*) |
Contains information to contact a
person or entity. |
|
/ [IndEmployeeInfoType]/ |
- RemunerationBasisEnumType - S (0/1) |
Specifies how a person is
remunerated. |
|
/ [IndEmployeeInfoType]/ |
- EmploymentLevelEnumType - S (0/1) |
Container to indicate full-time or part-time employment. |
|
/ [IndEmployeeInfoType]/ |
- ResourceRelationshipEnumType - S (0/1) |
Indicates whether the worker is
an employee or sub-contractor. |
|
/ [IndEmployeeInfoType]/ |
- EmploymentTermType - S (0/1) |
Expresses the classification of
the employment contract. |
|
/ [IndEmployeeInfoType]/ |
- LaborBargainingUnitStatus EnumType - S (0/1) |
Specifies the status of a person
within a labor bargaining unit. |
|
/ [IndEmployeeInfoType]/ |
- ForeignStatusEnumType - S (0/1) |
The foreign national status in
relation to the home country of the organization. |
|
/ [IndEmployeeInfoType]/ |
- VIPType - S (0/1) |
A Boolean value to indicate the person is a VIP. |
|
/ [IndEmployeeInfoType]/ |
- ExecutiveType - S (0/1) |
A Boolean value to indicate the person is an executive. |
|
/ [IndEmployeeInfoType]/ |
- OfficerType - S (0/1) |
A Boolean value to indicate the person is an officer of the organization. |
|
/ [IndEmployeeInfoType]/ |
- PercentOwnerType - S (0/1) |
A Boolean value to indicate the person owns a percentage of the company stock. |
|
/ [IndEmployeeInfoType]/ |
- xsd:boolean - S (0/1) |
A Boolean value to indicate the person is retired. |
|
/ [IndEmployeeInfoType]/ |
- IndRetirementInfoType - S (0/*) |
Contains information about the person's retirement. |
|
/ [IndEmployeeInfoType]/
RetirementInfo/ |
- IndOrganizationRefType - S (0/1) |
Contains information about the organization. |
|
/ [IndEmployeeInfoType]/
RetirementInfo/ |
- LocalDateType - S (0/1) |
Specifies the date a person
intends to retire. |
|
/ [IndEmployeeInfoType]/
RetirementInfo/ |
- LocalDateType - S (0/1) |
Specifies the first day on which
the person was retired and no longer worked (is classified as retired). |
|
/ [IndEmployeeInfoType]/ |
- EntityIdType - S (0/*) |
Contains information used to group
employees for a business purpose. |
|
/ [IndEmployeeInfoType]/ |
- UserAreaType - S (0/1) |
Allows the user to extend the specification in order to provide additional information that is not captured in the standard. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: FullTime, PartTime |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Regular, Temporary |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
xsd:extension base: EmploymentTermEnumType |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[EmploymentTermType] / |
- xsd:boolean - |
Indicates if the position is for an internship. |
|
/
[EmploymentTermType] / |
- xsd:boolean - |
A
Boolean value to ndicate whether the position is based on seasonal needs. |
|
/ |
xsd:extension base: xsd:boolean |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[ExecutiveType] / |
- xsd:string - |
Further
defines the associated element in the context provided. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Domestic, Inpatriate, Expatriate, LocalNational, ThirdCountryNational |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
Organization
- IndOrganizationRefType - S (0/1) |
Globally scoped data type. See element or attribute declaration for definition. |
3.5 Employment Info
3.5.1 Schema Diagram
3.5.2 Schema Elements/Attribute Details
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
- IndEmploymentInfoType - S (0/1) |
A collection of information about a current or former employment engagement of the person. |
|
/ |
IsEmployed - xsd:boolean - S (0/1)
|
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [IndEmploymentInfoType]/ |
- xsd:boolean - S (0/1) |
Indicates whether the person is employed or not. |
|
/ [IndEmploymentInfoType]/ |
- IndProposedHireInfoType
- S (0/1) |
Contains information about a person that has been offered and/or accepted a job but hasn’t started yet. |
|
/ [IndEmploymentInfoType]/
ProposedHireInfo/ |
- LocalDateType - S (0/1) |
The date the position,
assignment, or contract is expected to begin. |
|
/ [IndEmploymentInfoType]/
ProposedHireInfo/ |
- IndCancelHireType - S (0/1) |
Contains information about the cancellation of a hire. |
|
/ [IndEmploymentInfoType]/ |
- IndEmploymentLifecycleType
- S (0/*) |
Container for all employment-related information as it relates to the person. |
|
/ [IndEmploymentInfoType]/
Employment/ |
- IndHireInfoType
- S (0/1) |
Contains information about the hire. |
|
/
[IndHireInfoType] / |
xsd:restriction base: xsd:string [Enumerations]: NewHire, Rehire, Acquisition |
Describes
the type of hire. |
|
/ [IndEmploymentInfoType]/
Employment/ HireInfo/ |
- LocalDateType - S (0/1) |
Date the person was originally
hired by the organization. |
|
/ [IndEmploymentInfoType]/
Employment/ HireInfo/ |
- LocalDateType - S (0/1) |
The date this person was first hired by the organization. |
|
/ [IndEmploymentInfoType]/
Employment/ HireInfo/ |
- IndAdjustedHireDateType - S (0/*) |
A hire or rehire date that has been adjusted to accommodate a break in service or other similar circumstances. |
|
/ [IndEmploymentInfoType]/
Employment/ |
- xsd:boolean - S (0/1) |
A Boolean value to indicate the person is on leave of absence. |
|
/ [IndEmploymentInfoType]/
Employment/ |
- IndLOAInfoType
- S (0/*) |
Contains information about the leave of absence. |
|
/
[IndLOAInfoType] / |
xsd:restriction base: xsd:string [Enumerations]: Active, Inactive |
Specifies
the status of an employee while on leave of absence. |
|
/
[IndLOAInfoType] / |
xsd:restriction base: xsd:string [Enumerations]: Paid, Unpaid |
Specifies
the status of a person's remuneration during leave of absence. |
|
/ [IndEmploymentInfoType]/
Employment/ LeaveInfo/ |
- LocalDateType - S (0/1) |
The (inclusive) date a person
started on leave of absence. |
|
/ [IndEmploymentInfoType]/
Employment/ LeaveInfo/ |
- LeaveReasonType - S (0/1) |
Describes why a person is going on a leave of absence. |
|
/ [IndEmploymentInfoType]/ Employment/
LeaveInfo/ |
- LocalDateType - S (0/1) |
Indicates the date of the last day the person worked for the employer. |
|
/ [IndEmploymentInfoType]/
Employment/ LeaveInfo/ |
- LocalDateType - S (0/1) |
The date a person is scheduled to
return to work. |
|
/ [IndEmploymentInfoType]/
Employment/ LeaveInfo/ |
- LocalDateType - S (0/1) |
The date a person returned to
work. |
|
/ [IndEmploymentInfoType]/
Employment/ |
- xsd:boolean - S (0/1) |
A Boolean value to indicate the person has been terminated from the position. |
|
/ [IndEmploymentInfoType]/
Employment/ |
- IndTerminationInfoType
- S (0/1) |
Contains information about the termination. |
|
/
[IndTerminationInfoType] / |
- xsd:boolean - |
A
Boolean value to indicate the event is voluntary. |
|
/ [IndEmploymentInfoType]/
Employment/ TerminationInfo/ |
- xsd:string - S (0/1) |
The reason why the employment relationship was terminated. |
|
/ [IndEmploymentInfoType]/
Employment/ TerminationInfo/ |
- LocalDateType - S (0/1) |
The date the relationship between
the organization and employee ends. |
|
/ [IndEmploymentInfoType]/
Employment/ TerminationInfo/ |
- LocalDateType - S (0/1) |
Indicates the date of the last day the person worked for the employer. |
|
/ [IndEmploymentInfoType]/
Employment/ TerminationInfo/ |
- LocalDateType - S (0/1) |
The (inclusive) date a person
last received remuneration for the particular assignment, job or position. |
|
/ [IndEmploymentInfoType]/ |
- UserAreaType - S (0/1) |
Allows the user to extend the specification in order to provide additional information that is not captured in the standard. |
|
/ |
xsd:extension base: LocalDateType |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndAdjustedHireDateType] / |
- xsd:string - |
Further
defines the associated element in the context provided. |
|
/ |
xsd:extension base: TrueValueOnlyEnumType |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [IndCancelHireType]
/ |
- LocalDateType - |
Specifies
a cancellation date. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Employed, NotEmployed |
Globally scoped data type. See element or attribute declaration for definition. |
|
|
xsd:extension base: xsd:string |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[LeaveReasonType] / |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: true |
Globally scoped data type. See element or attribute declaration for definition. |
3.6 Job Position Info
3.6.1 Schema Diagram
3.6.2 Schema Elements/Attribute Details
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
- IndJobPositionInfoType - S (0/1) |
Contains information about the
work a person does at an organization. |
|
/ |
JobPositionDetail - IndJobPositionDetailType - S (0/*) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [IndJobPositionInfoType]/ |
- IndJobPositionDetailType
- S (0/*) |
A collection of related details
about the job and position. |
|
/ [IndJobPositionInfoType]/
JobPositionDetail/ |
- IndJobEntryReasonEnumExtensionType
- S (1/1) |
|
|
/ [IndJobPositionInfoType]/
JobPositionDetail/ JobEntryReason/ |
- IndJobEntryReasonEnumType - C (0/1) |
A list of standard values. |
|
/ [IndJobPositionInfoType]/
JobPositionDetail/ JobEntryReason/ |
- xsd:string - C (0/1) |
A string used to extend a list of non-standard values. |
|
/ [IndJobPositionInfoType]/ |
- EntityIdType - S (0/1) |
Unique code to identify the shift. |
|
/ [IndJobPositionInfoType]/ |
- IndJobScheduledHoursType - S (0/*) |
Describes the frequency and
number of hours a person is expected (or scheduled) to work. |
|
/ [IndJobPositionInfoType]/ |
- UserAreaType - S (0/1) |
Allows the user to extend the specification in order to provide additional information that is not captured in the standard. |
|
/ |
validFrom
- LocalDateType - optional
|
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndBaseJobPositionDetailType] / |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
/
[IndBaseJobPositionDetailType] / |
- LocalDateType - |
The date
through which the event is active or valid, or the date the event ends. |
|
/
[IndBaseJobPositionDetailType]/ |
- EntityIdType - S (0/1) |
Reference to a uniquely identifiable position. |
|
/
[IndBaseJobPositionDetailType]/ |
- xsd:string - S (0/1) |
A short
phrase describing the position the way it would be listed on a business card
or in a company directory. |
|
/
[IndBaseJobPositionDetailType]/ |
- IndJobLevelInfoType - S
(0/1) |
A
grouping of similar jobs in terms of function, job duties, tasks,
responsibilities, job evaluation method, or similarity in pay philosophy. |
|
/
[IndBaseJobPositionDetailType]/ JobLevel/ |
- xsd:string - S (0/1) |
Identifies a specific salary structure or program used either throughout, or in specific segments of, an enterprise. |
|
/
[IndBaseJobPositionDetailType]/ JobLevel/ |
- xsd:string - S (0/1) |
Defines the
salary range or band that a job falls within, based on the formal structure. |
|
/
[IndBaseJobPositionDetailType]/ JobLevel/ |
- xsd:string - S (0/1) |
Pinpoints a position's specific level or point within a salary range or band. |
|
/
[IndBaseJobPositionDetailType]/ |
- xsd:string - S (0/1) |
A grouping of jobs under one or more classification schemes that is meaningful to an organization. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Acquisition, Demotion, Hire, Lateral, Promotion, Transfer |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
xsd:extension base: xsd:decimal |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndJobScheduledHoursType] / |
- IndScheduledHoursBasisEnumType - |
The
interval or increment in which an event is measured. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Daily, Weekly, Every2Weeks, Monthly, SemiMonthly, Every2Months, Quarterly, Annually, SemiAnnually, Every4Weeks |
Globally scoped data type. See element or attribute declaration for definition. |
3.7 Organization Info
3.7.1 Schema Diagram
3.7.2 Schema Elements/Attribute Details
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
- IndOrganizationalInfoType - S (0/1) |
Contains information about the employee’s place within the organization's structure. |
|
/ |
Organization - IndEmployeeOrganizationRefType - S (0/*) |
Globally scoped data type. See element or attribute declaration for definition. |
|
|
/ [IndOrganizationalInfoType]/ |
- IndEmployeeOrganizationRefType - S (0/*) |
Contains information about the organization. |
|
|
/ [IndOrganizationalInfoType]/ |
- IndEmployeeOrganizationalUnitRefType - S (0/*) |
Contains information about a sub-entity or entities within an organization that have no unique legal identification or designation. |
|
|
/ [IndOrganizationalInfoType]/
OrganizationalUnit/ |
- xsd:string - S (0/1) |
The name by which an organizational unit is known as established by its owning organization. |
|
|
/ [IndOrganizationalInfoType]/
OrganizationalUnit/ |
- EntityIdType - S (0/1) |
Unique identifier for the organizational unit. This may be an internal identifier assigned by the sender. |
|
|
/ [IndOrganizationalInfoType]/
OrganizationalUnit/ |
- OrgAccountingCodeType - S (0/1) |
Describes a unique code for the purpose of financial tracking, billing or reporting. |
|
|
/ [IndOrganizationalInfoType]/ |
- IndEmployeeWorkSiteRefType - S (0/*) |
The address in which the participant is currently working. |
|
|
/ [IndOrganizationalInfoType]/
WorkLocation/ |
- xsd:string - S (0/1) |
A descriptive identifier within
the given context. |
|
|
/ [IndOrganizationalInfoType]/
WorkLocation/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
|
/ [IndOrganizationalInfoType]/
WorkLocation/ |
- PostalAddressType - S (0/1) |
A mailing address. Describes a
postal address used for delivery of mail. The address may include the country
code, postal code, a region, municipality, delivery address, and the
recipient. |
|
|
/ [IndOrganizationalInfoType]/ |
- UserAreaType - S (0/1) |
Allows the user to extend the specification in order to provide additional information that is not captured in the standard. |
|
|
/ |
validFrom
- LocalDateType - optional
|
Globally scoped data type. See element or attribute declaration for definition. |
|
|
/
[IndEmployeeOrganizationalUnitRefType] / |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
|
/
[IndEmployeeOrganizationalUnitRefType] / |
- LocalDateType - |
The date
through which the event is active or valid, or the date the event ends. |
|
|
/ |
xsd:extension base: IndOrganizationRefType |
Globally scoped data type. See element or attribute declaration for definition. |
|
|
/
[IndEmployeeOrganizationRefType] / |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
|
/
[IndEmployeeOrganizationRefType] / |
- LocalDateType - |
The date
through which the event is active or valid, or the date the event ends. |
|
|
/ |
validFrom
- LocalDateType - optional
|
Globally scoped data type. See element or attribute declaration for definition. |
|
|
/
[IndEmployeeWorkSiteRefType] / |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
|
/
[IndEmployeeWorkSiteRefType] / |
- LocalDateType - |
The date
through which the event is active or valid, or the date the event ends. |
|
|
/
[IndEmployeeWorkSiteRefType] / |
- xsd:decimal - |
Specifies
the percentage of time allocated to a particular assignment. |
|
|
/ |
xsd:extension base: xsd:string |
Globally scoped data type. See element or attribute declaration for definition. |
|
|
/
[OrgAccountingCodeType] / |
- xsd:string - |
This optional attribute is available to provide additional information. |
|
|
/ [OrgAccountingCodeType]
/ |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
|
/
[OrgAccountingCodeType] / |
- LocalDateType - |
The date
through which the event is active or valid, or the date the event ends. |
|
3.8 Remuneration Info
3.8.1 Schema Diagram
3.8.2 Schema Elements/Attribute Details
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
- IndRemunerationInfoType - S (0/1) |
A collection of information about remuneration for a particular job or position. |
|
/ |
RemunerationDetail - IndRemunerationDetailType - S (0/*) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [IndRemunerationInfoType]/ |
- IndRemunerationDetailType - S (0/*) |
Contains detailed information about the payment made to a person. |
|
/ [IndRemunerationInfoType]/
RemunerationDetail/ |
- IndPayRateType - S (1/1) |
The pay rate for the person. |
|
/ [IndRemunerationInfoType]/
RemunerationDetail/ |
- IndPayRateFrequency EnumExtensionType - S (1/1) |
Specifies the term of the pay rate. |
|
/ [IndRemunerationInfoType]/
RemunerationDetail/ PayRateFrequency/ |
- IndPayRateFrequencyEnumType - C (0/1) |
A list of standard values. |
|
/ [IndRemunerationInfoType]/
RemunerationDetail/ PayRateFrequency/ |
- xsd:string - C (0/1) |
A string used to extend a list of non-standard values. |
|
/ [IndRemunerationInfoType]/
RemunerationDetail/ |
- IndRemunerationEnumExtensionType - S (1/1) |
Specifies the type of remuneration. |
|
/ [IndRemunerationInfoType]/
RemunerationDetail/ RemunerationType/ |
- IndRemunerationEnumType - C (0/1) |
A list of standard values. |
|
/ [IndRemunerationInfoType]/
RemunerationDetail/ RemunerationType/ |
- xsd:string - C (0/1) |
A string used to extend a list of non-standard values. |
|
/ [IndRemunerationInfoType]/ |
- IndPayrollCycleFrequencyType - S (0/1) |
Defines how often the paycycle
occurs. |
|
/ [IndRemunerationInfoType]/ |
- IndPayGroupType - S (0/1) |
A grouping of employees to facilitate a payroll business process. |
|
/ [IndRemunerationInfoType]/ |
- UserAreaType - S (0/1) |
Allows the user to extend the specification in order to provide additional information that is not captured in the standard. |
|
/ |
validFrom
- LocalDateType - |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndRemunerationDetailType] / |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
/ [IndRemunerationDetailType]
/ |
- LocalDateType - |
The date
through which the event is active or valid, or the date the event ends. |
|
/ |
xsd:extension base: IndPayrollCycleFrequency EnumExtensionType |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndPayrollCycleFrequencyType] / |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
/
[IndPayrollCycleFrequencyType] / |
- LocalDateType - |
The date
through which the event is active or valid, or the date the event ends. |
|
/ |
xsd:extension base: xsd:string |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndPayGroupType] / |
- LocalDateType - |
The date
the event begins, is active or valid. |
|
/
[IndPayGroupType] / |
- LocalDateType - |
The date
through which the event is active or valid, or the date the event ends. |
|
/ |
StandardValue
- IndPayRateFrequencyEnumType - C (0/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndPayRateFrequency EnumExtensionType]/ |
- IndPayRateFrequencyEnumType - C (0/1) |
A list of standard values. |
|
/
[IndPayRateFrequency EnumExtensionType]/ |
- xsd:string - C (0/1) |
A string used to extend a list of non-standard values. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Hourly, Daily, Weekly, Every2Weeks, SemiMonthly, Monthly, Every2Months, Every4Weeks, Quarterly, SemiAnnually, Annually |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
xsd:extension base: xsd:decimal |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndPayRateType] / |
- CurrencyCodeType - |
A
three-letter code identifying the currency of a monetary amount. |
|
|
StandardValue
– IndPayrollCycleFrequency EnumType - C (0/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[IndPayrollCycleFrequency EnumExtensionType]/ |
- IndPayrollCycleFrequencyEnumType - C (0/1) |
A list of standard values. |
|
/ [IndPayrollCycleFrequency
EnumExtensionType]/ |
- xsd:string - C (0/1) |
A string used to extend a list of non-standard values. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Weekly, Every2Weeks, SemiMonthly, Monthly, Every 2 months, MonthWeek1, MonthWeek2, MonthWeek3, MonthWeek4, MonthWeek5, MonthWeekLast, Quarterly, SemiAnnually, Annually, Once |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: BasePay, Commission, Bonus, Incentive, ShiftDifferential |
Globally scoped data type. See element or attribute declaration for definition. |
3.9 Affiliation Info
3.9.1 Schema Diagram
3.9.2 Schema Elements/Attribute Details
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
- IndAffiliationInfoType - S (0/1) |
Contains information about an individual's participation in a professional or industry group or association in which the employer has an interest. |
|
/ |
LaborBargainingUnitMembership - LaborBargainingUnitMembershipType - S (0/*) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [IndAffiliationInfoType]/ |
- LaborBargainingUnitMembershipType - S (0/*) |
Contains information about membership within a labor bargaining unit. |
|
/ [IndAffiliationInfoType]/
LaborBargainingUnitMembership/ |
- xsd:string - S (0/1) |
The name by which an organization or enterprise is known as established under the laws of a country, state, province or ruling governmental body for the purpose of conducting business transactions. |
|
/ [IndAffiliationInfoType]/
LaborBargainingUnitMembership/ |
- EntityIdType - S (0/1) |
Unique identifier for the organization. It may be an internal identifier assigned by the sender. |
|
/ [IndAffiliationInfoType]/
LaborBargainingUnitMembership/ |
- EntityIdType - S (0/1) |
A unique identifier for a member of an association or affiliation. |
|
/ [IndAffiliationInfoType]/ |
- UserAreaType - S (0/1) |
Allows the user to extend the
specification in order to provide additional information that is not captured
in the standard. |
|
/ |
validFrom - LocalDateType
- optional |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[LaborBargainingUnitMembershipType] / |
- LocalDateType - |
The date the event begins, is
active or valid. |
|
/
[LaborBargainingUnitMembershipType] / |
- LocalDateType - |
The date through which the event
is active or valid, or the date the event ends. |
3.10 Indicative Reusable Types
3.10.1 Schema Elements/Attribute Details
|
Global
types |
ContentModel* |
Definition |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Primary, Secondary, Tertiary |
|
|
/ |
xsd:extension base: ContactMethodType |
|
|
/ [EffectiveDatedContactMethod
WithPrecedenceType] / |
- ContactMethodPrecedenceEnumType - |
Specifies the order of contact
preference. |
|
/ [EffectiveDatedContactMethod
WithPrecedenceType] / |
- LocalDateType - |
The date the event begins, is
active or valid. |
|
/ [EffectiveDatedContactMethod
WithPrecedenceType] / |
- LocalDateType - |
The date through which the event
is active or valid, or the date the event ends. |
|
/ |
xsd:extension base: LocalDateType |
|
|
/ [LocalDateCertifiedType] / |
- LocalDateType - |
The date the associated element was
certified. |
4 Implementation Considerations
4.1 Introduction
The successful adoption of any standard requires consistent interpretation among trading partners. This section provides some practical guidelines for implementing the HR-XML Indicative Data specification. While an attempt is made to recommend a preferred approach for interpretation, it is recognized that the capabilities of the source and receiving systems may vary widely from the suggested approach. In these cases, trading partners should confer and agree on the appropriate approach.
4.2 Data Privacy
Human resources data, by its very nature, is personal data. The laws of many jurisdictions as well as codes of fair information practice require organizations to handle personal data in a way that protects individuals from loss of privacy.
The data exchange specifications developed by the HR-XML Consortium are designed to be useful across many jurisdictions and within a variety of business contexts. It is not feasible for the HR-XML Consortium to develop specific privacy guidance for every jurisdiction or business context in which the Consortium's specifications might be implemented. When implementing data exchanges using the HR-XML Consortium's data definitions (or, for that matter, using any other type of data exchange mechanism), organizations are advised to examine the privacy protections that may be required under applicable law and codes of fair information practice.
For information on protecting personal data, general references include: European Union Data Protection Directive (95/46/EC); the Association Computing Machinery Code of Ethics (1992); Canadian Standards Association Model Code for the Protection of Personal Information (1995 – PIPEDA); and U.S.-EU Safe Harbor Principles and FAQs (2000).
4.3 Information Not Known by Source System
4.3.1 Required Data
If the source system does not store a required element and a “notKnown” enumeration is defined, “notKnown” should be sent instead of any default. A trading partner agreement is required if an element is required and the sender is not able to provide it.
4.3.2 Optional Data
Some elements in the Indicative Data schemas are required while others are optional which provides for flexibility. Receiving systems must perform their own integrity checking and validation.
If an optional element is not known or not captured by the source system, the corresponding tags and/or content SHOULD NOT be sent in the payload.
4.4 Effective Dating
Lower level (child) effective dating supersedes higher level (parent) effective dates. For example, the individual was an employee of the organization in 2004, but worked as a Sales Clerk starting March 15, 2005.
<Employee validFrom="2004-10-01">
<JobPositionInfo>
<JobPositionDetail validFrom="2005-03-15">
<PositionTitle>Sales Clerk</PositionTitle>
</JobPositionDetail>
</JobPositionInfo>
</Employee>
4.5 Elements Prepended with “Is”
Many elements are prepended with “Is”, e.g., IsEmployed, IsDisabled, IsVeteran, IsTobaccoUser, IsOnLeave, etc. These elements allow for string or numeric Boolean values of true/false or 1/0.
If the value equals true or 1, it indicates that the person is employed, is disabled, is a veteran, is a tobacco user, is on leave, etc. If the value equals false or 0, then the opposite is true; the person is not employed, is not disabled, is not a veteran, is not a tobacco user, is not on leave, etc.
Trading Partners should agree on the values to be used.
4.6 Job History
To pass job history, repeat JobPositionDetail as many times as necessary, i.e., for each job occurrence. Be sure to include the validFrom and validTo attributes, as well as the other desired elements, as they show each period during which the person held each job.
Refer to Example A7 in the IndicativeDataReferenceExamples document for more details.
4.7 Job and Position
This specification assumes that benefits are more likely based on jobs not positions.
A job is the total collection of tasks, duties, and responsibilities assigned to one or more individuals whose work generally has the same nature and level within a company. A position is one instance of a job. It is the total collection of tasks, duties, and responsibilities requiring the employment of a single employee.
For this specification, characteristics of both job and position were used.
4.8 Leave of Absence
Refer to Example A7 in the IndicativeDataReferenceExamples document for more details.
Use of LeaveDate within this element allows the user to tie a set of leaves together if they wish. For example, a user may treat a particular set of leaves that’s connected in time as comprising one continuous leave, e.g., a personal leave transitions to STD and eventually progresses to LTD. LeaveReason and validFrom would change, but LeaveDate would remain the same.
The employeeLeaveStatus and remunerationLeaveStatus attributes of LeaveInfo SHALL be the statuses the person had during the entire leave. Once the statuses are set they SHALL not change. If the statuses change, a new LeaveInfo structure SHALL be used to transmit the new statuses.
A known issue exists for the situation where the employeeLeaveStatus and/or the remunerationLeaveStatus attributes of LeaveInfo are the only data that change and no other information about the leave changes. For example, an employee takes a personal leave for four weeks; the first two weeks are paid using vacation and the second two weeks are unpaid. This issue will be addressed in a future release. However, as a workaround, a new LeaveInfo structure SHALL be passed and the validFrom attribute of the LeaveReason element SHALL be the effective date of the employeeLeaveStatus and/or the remunerationLeaveStatus change.
<Employment>
<IsOnLeave>true</IsOnLeave>
<LeaveInfo employeeLeaveStatus="active" remunerationLeaveStatus="paid">
<LeaveDate>2005-05-01</LeaveDate>
<LeaveReason validFrom="2005-05-01">Personal</LeaveReason>
<ScheduledReturnToWorkDate>2005-05-29</ScheduledReturnToWorkDate>
</LeaveInfo>
<LeaveInfo employeeLeaveStatus="active" remunerationLeaveStatus="unpaid">
<LeaveDate>2005-05-01</LeaveDate>
<LeaveReason validFrom="2005-05-15">Personal</LeaveReason>
<ScheduledReturnToWorkDate>2005-05-29</ScheduledReturnToWorkDate>
</LeaveInfo>
</Employment>
4.9 Organization
This element does not include the entire organizational structure of the company. It merely provides information about (or acts as a pointer to) the employee’s placement within the company’s organization.
4.10 PayCycleFrequency and payRateFrequency
PayCycleFrequency specifies how often the pay cycle occurs or, in other words, how often a person is paid, e.g., weekly, biweekly, etc. payRateFrequency is used with PayRate and specifies the term (time period) of the person’s PayRate that’s in the source system, e.g. annual, weekly, hourly, etc. PayCycleFrequency and payRateFrequency may or may not have the same values in the source system.
For example, assume an employee earns US$24,024.00 per year.
|
If PayCycleFrequency is … |
Then the employee would be paid … |
|
Weekly |
$462.00 each week |
|
Biweekly |
$924.00 every other week |
|
If payRateFrequency is … |
Then the employee’s pay rate would be … |
|
Annual |
$24,024.00 |
|
Weekly |
$462.00 |
|
Hourly |
$11.55 |
4.11 UserArea Extension Element
UserArea elements are provided throughout the specification to allow the user to extend the specification in order to provide additional information that is not captured in the standard. It may be used to include proprietary information or localized data. A UserArea may also be linked to another schema (HR-XML or likewise) for validation, e.g., HR-XML Benefits Enrollment or a proprietary schema.
4.12 IndicativeBatch.xsd vs. IndicativeData.xsd
The IndicativeBatch.xsd includes all elements of the IndicativeData.xsd but adds additional top-level elements that facilitate passing information between trading partners in a “batch” mode. That is, where a file is created and transported to a trading partner. In these cases, additional information may be required to “track” and uniquely identify this “batch” of information. IndicativeBatch.xsd helps to fulfill these transport requirements.
IndicativeData.xsd can be used for “non-batch” situations. For example, as a schema for software developers to generate Java/C# classes, for web service development, etc.
4.13 Use (not abuse) of the EmployeeGroup element
This element was introduced with some trepidation for fear of misuse, so as an implementation consideration it is suggested that this element is used as a last resort, not as a first option.
The notion of an “employee group” is pretty pervasive in the benefits/payroll industry. Typically, this concept “groups” employees by a set of “characteristics” (e.g. union, non-union, full-time, part-time, hourly, salary, etc.). This grouping is done to support some type of business processing (e.g. pay union, hourly people every other Friday) or for internal decision making (salaried, non-union employees are eligible for Visions Plan XYZ). Employee groups are fluid, in that they change quite often as the employer sees fit.
IndicativeData has gone through great pains to ensure that we have modeled employee characteristics individually. This ensures that an employees characteristics, represented in one XML document, can be sent to multiple trading partners, and the receiving trading partner can then collate any given employee into the appropriate “employee group(s)”.
Again, it is recommended that this element be used only if there is no “home” for the individual characteristic(s) that you wish to express for a given employee. For example, one would NOT use the EmployeeGroup element to express “full-time hourly”. Rather, the following elements would be populated: RemunerationBasis with ‘hourly’ and EmploymentLevel with ‘full time’. As another example, to express the concept of ‘regular part-time’, the following elements would be populated: EmploymentLevel with ‘part time’ and ‘EmploymentTerm’ with ‘regular’.
4.14 Use of TransactionType and changeType
The IndicativeBatch.xsd schema provides an element, TransactionType, which specifies to a trading partner that is ‘receiving’ a batch file, whether the contents of the file represent a ‘full’ file or a ‘changes only’ file. The values of this element are ‘change’ and ‘full’.
IndicativeData.xsd schema includes an optional attribute for each employee, changeType, which is used to describe the type of change being communicated to the receiving system. The values of this attribute are: add, correct, update, and delete.
These two elements do interact. If the TransactionType is ‘full’, the changeType SHALL NOT be used. If the TransactionType is ‘change’, the changeType MAY be used to communicate the exact nature of the change being transmitted.
4.14.1 TransactionType
When using IndicativeBatch.xsd, the following guidelines are provided for using the TransactionType element:
- ‘Full’ is used to provide a snapshot of a set of employees at a given point in time.
- ‘Change’ is used to send only those employees where data has ‘changed’ since the previous transmission.
4.14.2 changeType
When using IndicativeData.xsd, the following guidance is provided for using the changeType element:
- As mentioned previously, this transaction should only be used if TransactionType is change.
- ‘Add’ is used to send a brand new record that the receiving system does not have. If the receiving system already has it, this may be an error, depending on the Trading Partner Agreement. ‘Add’ is the recommended default value.
- ‘Update’ is used to provide new information and assumes the receiving system already has the employee record on file. This new information may or may not overwrite existing information but provides for communicating state changes to information. For example, if a person’s marital status changes from unmarried to married, the source system would use the ‘update’ value of change type and send the new marital status value.
- ‘Correct’ is used to specify that a piece of information is in error and needs to be fixed. It is assumed that the receiving system would overwrite the old information with the new. For example, if a prior communication included the misspelled name of an employee, the source system would use ‘correct’ and send the appropriate name element and fix the data.
- ‘Delete’ gives the receiver the option of completely removing the information from the system.
- If changeType is not included in the transaction (i.e., left out), the receiving system should assume it’s a full file replacement. A source system may use this if it does not know whether the receiving system has the data or not. If the receiving system already has the data, this may be an error, depending on the Trading Partner Agreement.
- To clear a particular piece of data that was sent in error, such as date of death, it is recommended that the source system resend the entire employee record.
5 Appendix A – Open Issues
|
Issue |
Disposition |
|
Leave of Absence - employeeLeaveStatus and/or remunerationLeaveStatus attributes of LeaveInfo change, but no other leave data changes. |
See section 4.8 for temporary workaround. In future release, need to add effective dates to employeeLeaveStatus and remunerationLeaveStatus. |
6 Appendix B - Document Version History
|
Date |
Description |
|
2004-Oct-08 |
Initial Draft |
|
2005-May-12 |
Send out for final workgroup review. |
|
2005-July-15 |
Updated based on CPO review: Changed some date types (updated diagrams/tables). Added localization sentence to definition tables where appropriate. |
|
2005-Nov-17 |
Updated based on TSC review. Replaced all enumeration extensions and date extensions. Standarized enumerations to UpperCamelCase. |
|
2005-Dec-08 |
Replaced BaselineDate non-extended date (no NkNa). Replaced localized OvertimeStatus with localized FLSAStatus. |
|
2006-Feb-28 |
Approved by Consortium |
|
2007-April-15 |
Updated/Approved by Consortium |
7 Appendix C – Related Documents
8 Appendix D - HR Administrator Task Processing Scenarios
The following list describes the tasks an HR Administrator may perform and some of the Indicative Data that is associated with them. Many of these scenarios are used for the Indicative Data Reference Examples.
These scenarios assume all tables and security have been set up.
Hire an Employee
Personal data (name, address, I9 info, contact info, etc)
Organizational data (company, business unit, department, position, etc)
Salary information (salary, etc)
Other misc info (vet status, full/part-time, other status)
General position information
The Company decides to reorganize
New organizational data (company, business unit, department, position, etc)
Employee’s job is changed as the result of the reorg and the employee relocates.
Employee transfer (BU, Location)
New salary informaiton
New employee data
Employee becomes disabled, goes on Short Term Disability and FMLA leave
Employee status
Leave information
Employee Returns from STD and FMLA leave
Employee status
Leave information
Employee Resigns/Terminates
Termination dates, reasons, etc.
Employee returns to company
Re-hire (see hire process above)
**This list is not all-inclusive.