Time Card

Recommendation, 2007 April 15

Editor:

Bill Kerr, Oracle Corporation

Gail Bubsey, Kelly Services, Inc.

Kim Bartkus, HR-XML Consortium

Erwin Folmer, TNO

Authors:

Andreas Bold, SAP AG

Eva Decker, SAP AG

John DeRoche, Manpower, Inc.

Bill Kerr, Oracle Corporation

Erwin Folmer, TNO

Contributors:

Members of Time Expense Reporting workgroup

Abstract

The HR-XML Time Expense Reporting Workgroup has produced a simple, flexible definition of the elements required to express time and expense data. This document describes those elements, the expected usage, and the business processes meant to be supported.

Table of Contents

1 Overview.. 3

1.1 Objective. 3

1.1.1 Domain Issues. 3

1.1.2 Business Reasons. 4

1.2 Design Requirements. 4

1.3 Scope. 4

1.3.1 Major Components. 5

1.3.2 Items Within the Design Scope. 6

1.3.3 Items Outside of Design Scope. 7

2 Supported Business Processes. 7

2.1 Introduction and Actors. 7

2.1.1 Overview Activity Diagram.. 8

2.1.2 Actor: Time Capturing Device. 8

2.1.3 Actor: Time & Attendance Application. 9

2.1.4 Actor: Final Consumer Application. 9

2.2 Process: Posting of Raw Time Data. 10

2.2.1 Activity Diagram.. 10

2.2.2 Users. 10

2.2.3 Business Goal and Process. 10

2.2.4 Examples for Raw.. 12

2.3 Process: Posting of Processed Time Data. 13

2.3.1 Activity Diagram.. 13

2.3.2 Users. 14

2.3.3 Business Goal and Process. 14

2.3.4 Example of a Processed Timecard. 15

3 Schema Design. 16

3.1 Schema. 16

3.2 Schema Elements Explained. 17

4 Implementation Considerations. 30

6 Appendix A - Document Version History. 32

7 Appendix B – Related Documents. 33

8 Appendix C – Reference Examples. 34

1 Overview

1.1 Objective

· The objective of the TimeCard specification is to provide a simple definition of the elements required to report time worked, expenses incurred, and allowances provided.

Future versions are expected to allow for more sophisticated definition of tasks and expenses, however, this specification is flexible enough to handle typical ways that time worked is expressed, plus a simple format for the representation of expenses and allowances.

Time worked is typically expressed in the following ways

§ Time Events – Defined as a timestamp that marks the occurrence of a particular event. (ex. 8am began working)

§ Time Intervals – Defined as an expression of time to be paid or billed at a particular rate on a specific date during which a particular type of work was done. The time might be expressed as a total quantity, for example, on 7/1/01 worked 4 hours at 20.00 USD, regular, billable-hours on Project A. Or time could be expressed as an interval, for example 8am to 1pm, during which a particular activity took place.

· Expenses Incurred – Defined as a reimbursable amount incurred while working on assignment or project. Includes Date, value and currency indicator and additional data (ex. On 7/1/01 incurred 25.00 USD Non-Billable Meal Expense)

· Allowances – Defined as additional allowances or bonuses to be given for the duration of the time interval represented. These are different to Expenses Incurred as they usually represent eligibility such as meal allowance, off-site payments, dirty working bonus, etc. The allowance is made up of an amount, a quantity and allowance type.

1.1.1 Domain Issues

The Internet, and companies’ desire to use it’s functionality to control outlays, achieve efficiencies, and more deeply understand their use of resources, has created an electronic timekeeping boom. Once, it was only time clock users who directly created entries into timekeeping systems. Most project workers used paper for later data entry into project management systems. Similarly, the temporary services industry was dependent on mailed or faxed paper to represent approved time for which to both pay their employees and bill their customers.

Widespread access to the Internet has provided the opportunity to eliminate the paper element of these transactions, providing data in an electronic format to be used as input to payroll or project management systems. New web-based applications specifically designed to enhance the recording and approving of time are seeing expanding use. The challenge presented is one of getting the data out of these new applications and into the existing payroll or project management systems in a timely and cost effective manner.

The main issues presented to the HR community by these new applications are:

§ Legal requirements as to the gathering of payroll data and the timing of when control leaves one organization and is assumed by another.

§ Technical issues presented by the varying elements and formats of output being presented to payroll and project management applications.

1.1.2 Business Reasons

An industry standard vocabulary to describe time reporting transactions provides the means for a single company to receive such transmissions from multiple sources without having to establish, engineer, and implement many separate translation mechanisms. The ability to quickly and cost effectively accept data from new sources allows the efficiencies promised by the Internet and its applications to be realized.

1.2 Design Requirements

The final design will be flexible enough to accept time reported in many formats and describe it in terms of projects, tasks, accounting codes, etc., to as many levels as deemed necessary by the involved parties. The design will be broad enough to be used globally, and will contain the elements required to express a simple expense reimbursement transaction.

1.3 Scope

The design supports a one-way transmission of data from an “electronic gatherer” or sender to an “electronic processor” or receiver. Naturally, a receiver of one transmission could then transform the data in some way, and transmit to another entity, becoming the sender in that second transaction.

For example: It is common practice for employees to enter Time and Expense data into automated collection systems. That data is processed and sent to another party for approval processing. The data may then be sent to 3^rd party payroll and invoicing processing centers. Significant development and processing savings can be realized by each organization utilizing a standardized data exchange.

The Time and Expense Reporting specification allows for the capture and transmission of expense data of the type that typically would be reported on the timecard submitted by a temporary staffing agency employee or by an independent contractor. The specification is not intended as a generalized mechanism for the capture and reporting of business expenses, such as meal, travel, entertainment, or other similar business expenses. This type of generalized mechanism for transmitting expense data may be part of a future version of the specification.

1.3.1 Major Components

(Please see section 3.2 for a complete description of attributes and elements defined)

§ Id – an attribute to unique identify the data grouping. An Id attribute is allowed at each level of reporting: the TimeCard (individual record), and TimeInterval, TimeEvent, Expense (line item), and Allowance levels.

§ ReportedResource – a full description of the individual or resource to which the time record applies.

§ ReportedTime – a repeatable segment for the description of time worked or expense incurred. Includes sub-elements:

§ PeriodStartDate – typically a week starting date. (Flexible to include any period of time)

§ PeriodEndDate – typically a week ending date. (Flexible to include any period of time)

§ ReportedPersonAssignment – element describing the work assignment being reported.

§ TimeInterval – Repeatable grouping to describe time worked. Includes, among others, attributes of TimeInterval and Id, and elements for StartDateTime, EndDateTime, Duration, PieceWork, RateOrAmount, AdditionalData (further describes type of work such as ‘Overtime’, ‘Vacation’, ‘lunch’, etc.), Comment, and ApprovalInfo.

§ TimeEvent – Repeatable group element describing a time event. Includes among others, elements for EventDateTime, AdditionalData (further describes the event such as project milestones, punch clock events, etc.), Comment, and ApprovalInfo.

§ Expense – Repeatable group element describing expenses incurred. Includes elements Id, , ExpenseDate, ExpenseAmount, - AdditionalData (further describes the expense such as ‘Meals’, ‘Rental Car’, ‘Parking’, etc.), Comment, and ApprovalInfo.

§ Allowance – Repeatable grouping to represent bonuses or allowances to be paid for the period recorded. Includes the attribute type and the elements amount and quantity.

§ SubmitterInfo – a description of the person or system who created the time record, may be different from the individual.

§ ApprovalInfo – a description of the person who approved the time record as a whole, as well as when that approval was given. Note: the opportunity is available to provide approval data at each level of the timecard record, ex. for each interval, for the period, and for the record as a whole.

§ AdditionalData – allows for additional information on the time card. The element type was changed to allow for extension. For example, the SIDES 1.0 schema will extend this element with the CustomerReportingRequirements and ReferenceInformation schemas.

§ HRXMLExtension – a method for extending the schema.

1.3.2 Items Within the Design Scope

There are three major reporting types that are covered by the design:

1) Timestamped Event –Used to mark the occurrence of a particular event.

Example 1: punching on a punchclock machine;
Example 2: achievement of a milestone for a project.

2) Time Intervals – Activity expressed as an amount and unit of time as taking place on a particular date(s).

Example 1: 2001-09-20Z-03, (start date)

· 2001-09-21Z-03, (end date)

· P4H, (ISO standard data structure conveying 4 hours) (quantity)

· Assignment=A, (assignment identifier)

· Activity=Coding, (activity identifier)

Example 2: 2001-08-15Z-09, (start date)

· 2001-08-15Z-09, (end date)

· P1D, (1 day) (quantity)

· Activity=Holiday, (activity identifier)

Or Activity expressed as having taken place during a time range as expressed by date and time stamps.

Example 3: 2001-09-20T09:00Z-03, (start date and time)

2001-09-20T11:00Z-03, (end date and time)

Assignment=A, (assignment identifier)

Activity=Coding, (activity identifier)

This section may also be used to express piecework or flat rate items.

§ Example 4: 2001-08-11Z-09, (start date)

2001-08-11Z-09, (end date)

150 UNIT, (quantity)

Activity=Envelop Making, (activity identifier)

§ Example 5: 2001-08-02Z-08, (start date)

2001-08-02Z-08, (end date)

50.00 USD, (quantity)

Description=Bonus, (description)

Finally, the piecework element can also be used to describe non-traditional time units.

§ Example 6: 2001-08-11Z-09, (start date)

1 MANDAY (quantity)

3) Expenses – Expression of outlays. Amount, Currency, and multiple descriptors are provided.

§ Example 1: Amount=15.10, (amount)

Currency=CAD, (currency)

Assignment=A, (assignment identifier)

Description=Mileage, (expense description)

1.3.3 Items Outside of Design Scope

Batch processing. Multiple time cards may be transmitted through an envelope. This specification does not recommend any particular envelope or describe the method of batch processing.
Responses to transmitted records beyond protocol-level acknowledgement.
The onus remains upon the implementers to agree upon the business rules around the use of the passed data as well as its validation (ex. Valid project numbers or cost center ids)
Standardization of expense or time classifications or codes.

2 Supported Business Processes

2.1 Introduction and Actors

The recording and posting of time and expense data can be modeled via 2 major business processes.

§ The first process reflects the situation that the time and expense data is recorded in a Time Capturing Device with limited time management business logic. The time capturing device mainly serves to record the actual time and expense data of an employee as it occurred in real working life. Limited business logic means that this time & expense data is not yet evaluated by all the relevant legal, union or company specific rules. We therefore talk about “raw” time data in this context and call this business process Posting of Raw Time and Expense Data. It posts the data to a more dedicated Time & Attendance Application.

§ The second process reflects the situation where the time and expense data is consolidated in a Time & Attendance Application and is posted to one or multiple Final Consumer Applications. The final consumer applications are using time & expense data as an input in order to trigger more specific and sophisticated business processes such as payroll or billing. The final consumer applications do not create themselves. The final consumer applications are often only interested in parts of the time and expense data or in condensed views of the time and expense data. Since the consumer applications do not modify the personnel time and expense data themselves they expect to receive these data in a processed and approved way. We therefore call this business process Posting of Processed Time and Expense Data.

It is an important fact of the proposed design that the data transfer in these two major business processes of posting personnel time and expense data can be covered with the same schema, the schema for the Timecard.

The three participating actors will be characterized in more detail.

2.1.1 Overview Activity Diagram

2.1.2 Actor: Time Capturing Device

The actor Time Capturing Device represents the different realizations of electronic time sheets with only limited time management business logic.

Typical technical realizations of such electronic time sheets may be Excel sheets, browser based time sheets, PDA time capturing applications, but also the long known clock-in/clock-out time clock terminals.

These time sheet applications are the electronic analogues to the formerly used paper sheets. They have their own database(s) but only limited time management business logic. This means that we do not expect that these smaller applications can do the complete validations and calculations of all legal, union or company specific rules that are related to personnel time data. We therefore call this actor Time Capturing Device in order to differentiate clearly from the second actor, a dedicated Time & Attendance Application.

It is very typical that such time sheet solutions are developed in-house with company specific user interfaces and very specific validations but of course there are also time sheet applications included in product suites of time management vendors.

2.1.3 Actor: Time & Attendance Application

The major characteristic of a dedicated Time & Attendance Application is that such an application covers the complete functionality in order to do the full validations and calculations of all legal, union or company specific rules that are related to personnel time data. We summarize this validation and calculation functionality as Time Evaluation functionality.

It is also typical that such a Time & Attendance Application offers time recording applications, too. In comparison to the Time Capturing Devices mentioned above, the user interfaces are more sophisticated and are designed in order to guarantee a complete and efficient Time Administration for the different departments of a company.

Of course, this Time & Attendance Application has its own database(s). It is very common that Time & Attendance Applications support external interfaces for importing time data out of external databases.

Time & Attendance Application may

create new “raw” time data and change them via Time Administration user interfaces
change time data that is imported from external sources
add time data that is automatically calculated in Time Evaluation
enrich time data via automated Time Evaluation.

Thus this actor creates, updates and reads time card data.

2.1.4 Actor: Final Consumer Application

The Consumer Application represents all categories of applications that base (parts of) their business processes on personnel time data. It reads a timecard but does not create a timecard.

Typical examples are:

Payroll – (note that almost all payroll systems also include a limited time & attendance functionality, typically for negative time).
Controlling: Activity Reporting / Actual Costing
Sales & Distribution: Billing Process
Project System: Project Progress Controlling
Data Warehouse Systems: Time & Labor Reporting, Expense Reporting

2.2 Process: Posting of Raw Time Data

The Business Process “posting of raw time data” is a process between the actor “Time Capturing Device” (sender of the timecard) and the actor “Time & Attendance Application” (receiver of the timecard).

2.2.1 Activity Diagram

2.2.2 Users

The typical users who trigger the business process are

For recording the time & expense data of an employee: The employee himself (Time & Expense Reporting is one of the most used employee self service scenarios). In special cases, other users such as team leads, project leads or administrators may record the employee’s time & expense data as a deputy.
For triggering the data transfer to the receiving Time & Attendance Application: the user who recorded the time data or an administrator.

2.2.3 Business Goal and Process

Business goal: the user should specify for a specific period of time when, how long, what type, what task he worked or when he or she was absent.

Depending on the industry or the specific business requirements of the company, it may also be necessary to record where the work has been performed, what cost distribution is valid, which expenses occurred, whether the work is billable or not, etc. Even information on piece work may be needed.

Depending on the industry or the specific business processes of the company, the task may be described as a job code, a project number, or an order number.

Depending on the business practices of the company, the time recording may be done in a positive or negative way (recording all actuals or recording only the deviations from the schedule).

At this process level, the time data recorded are “raw” in the sense that they contain just the pure real facts. In this level, no automatically evaluated times or derived classifications such as night shift bonus are included.

The time specification itself can be done in different fashions, depending on the business processes in the company:

As a time event: this is a single timestamp that indicates the point in time (date and time) when information that is relevant to describe the work performed becomes valid (ex. starting point of work or break).
As a time interval: this represents the techniques that describe time elapsed. Time elapsed can be specified by

Begin date & begin time with end date & end time
Begin date & end date (if the receiving application(s) do not require time). Begin date & end date may be the same to mark that activity occurred on a particular day.

In the case of time event based recording, the duration of the work is only calculated in the time & attendance application after forming time pairs out of the single time events. In the case of time intervals, the duration may be recorded by the user directly or may also be calculated in the time & attendance application by comparing the work schedule, calculating breaks etc.

It is characteristic that the time & expense recording in this business process is performed close in time to the actual performance of the work. For example, the transfer of data to the Time & Attendance system is done once per day or once per week. But it also may happen, that it makes sense to transfer the time data multiple times per day. Especially in the case of time events, the Time & Attendance application may need this data immediately after recording.

An approval step on the Time Capturing Device is not a very typical scenario, but it can be supported if needed. It is more common that the approval step is done in the receiving Time & Attendance application.

Here the typical users would be Time Administrators (Clerks), Team Leads, Project Leads or Line Managers. The Time & Attendance application offers a more sophisticated user interface to let these user types efficiently check, approve, add and enrich the employee’s time data.

2.2.4 Examples for Raw

Example Timecard 1: This is an example where begin and end times are not needed, but where the elapsed time (the duration) is recorded directly.

Start	End	Type	Duration (hrs)	Amount + Currency	Task	Project or Order	Cost Center	Billable	Comment…
May 07	May 07	Regular	8		Repair	1212	700	x	Aaabbbccc..
May 07	May 07	Meal		$ 10		1212	700	x
May 08	May 11	Vacation
May 14	May 14	Regular	4		Production		800
May 14	May 14	Sickness	4
May 15	May 18	Sickness
…

Example Timecard 2: This is an example where begin and end times are required for all time data lasting less than one working day. In this example it is expected that the receiving Time & Attendance application would calculate the duration automatically based on the work schedule and break information.

Start		End		Type	Amount + Currency	Quantity+ uom	Task	Project or Order	Billable	Comment…
May 07	08:00	May 07	19:00	Prod. hrs			Repair	1212	x	Aaab..
May 07		May 07		Meal	$ 10			1212	x
May 08		May 11		Vacation
May 14	08:00	May 14	12:00	Regular		40 Piec.	Production
May 14	13:00	May 14	17:00	Sickness
May 15	08:00	May 18	12:00	Sickness
…	…

Example Timecard 3: This is an example where the work performed is recorded as clock-in / clock-out information and where absences or other time data that is not recorded at a time clock device is directly recorded in the Time & Attendance application, thus not included in this timecard.

TimeEvent Time		Type	Order
May 07	08:01	Clock-in	1212
May 07	12:03	Clock-out
May 07	12:32	Clock-in	1213
May 07	17:05	Clock-out
May 08	07:59	Clock-in	1213
May 08	10:04	Clock-out
	…

2.3 Process: Posting of Processed Time Data

The Business Process “posting of processed time data” is a process between the actor “Time & Attendance application” (sender of the timecard) and the actor “Final Consumer Application” (receiver of the timecard).

2.3.1 Activity Diagram

2.3.2 Users

The typical users who trigger the business process are:

For recording the time & expense data: The Time Administrator, the Team Lead, the project manager or the line manager. It is also possible that such a Time & Attendance application offers Employee Self Service applications that record the time data directly on the database of this T&A application.
For triggering the data transfer to the receiving Final Consumer Application: typically an administrator or an automated background system process.

2.3.3 Business Goal and Process

Business goal: Depending on the variations of their role (Administrator versus Manager) the users would:

Check the time data submitted by the employee’s timecard for correctness and completeness.

Optionally, approve this time data.
Complete the employee’s time data by information that is not known to the submitter of the raw time data or that the employee himself is not allowed to record. On the one side, this means that the time administrator may record manually additional information on special bonuses or pay rates. On the other side, this means automatic calculations done by Time Evaluation. Time Evaluation processes the legal, union and company specific rules to determine overtime or night shift bonuses etc. It calculates the net duration of the work performed by evaluating the break information in the work schedule etc.
The Time & Attendance Application may also condense the data: as an example, it creates time pairs out of the single time events. Or it may cumulate the single time data of the different days into weekly or monthly sums.
The Time & Attendance Application may select and prepare the time & expense data to the individual need of the final consumer applications. It may create special time cards for the payroll process, for controlling processes and for billing processes. And it triggers the transfer of these time cards to these consumer applications.

In this sense, the time data of these time cards are processed (they are enriched by more classifications than just the raw input data). They are final, in the sense that the consumer applications do not create new time cards.

The data format of the time & expense records in the final timecard is the same as in the process of posting raw time data. Typically, final time cards would not contain time events since it is unusual that the consumer application offers functionality that can form time pairs and time durations out of time events. However, this format could be used to portray events such as the achievement of a goal in a project plan.

Depending on the design of the business processes at a specific company it may occur that the time administrators or line managers only approve the time cards received from the employee via time capturing device and then post it to the receiving consumer applications without adding new time data.

But also the opposite situation may occur: Some T&A applications offer employee self service user interfaces that store the recorded time data directly on the database of the T&A application or the Time Administrator has the job to records all time data of organizational unit. In this situation the raw time data would not be imported from a previous time capturing device but created directly in the T&A application.

The business rules of the company may define that only approved data should be posted to the final consumer applications.

2.3.4 Example of a Processed Timecard

Example Timecard 4: A processed timecard: overtime and net durations have been calculated automatically.

Start		End		Type	Duration (hrs)	Amount+ Curr	Task	Projector Order	Cost Center	Bill	Comment
May 07	08:00	May 07	17:00	Regular	8		Repair	1212	700	x
May 07	17:00	May 07	19:00	Overtime	2		Repair	1212	700	x	Aaabbbccc..
May 07		May 07		Dirty W.		$ 20	Repair	1212	700
May 07		May 07		Meal		$ 10		1212	700	x
May 08		May 11		Vacation	32
May 14	08:00	May 14	12:00	Regular	4		Production		800
May 14	13:00	May 14	17:00	Sickness	4
May 15	08:00	May 18	12:00	Sickness	32
…	…

3 Schema Design

3.1 Schema

3.2 Schema Elements Explained

Elements and Attributes [Global types listed alphabetically in following table.]	ContentModel* Data type Occurrence: Sequence \| Choice \| All (minOccurs/maxOccurs) Attributes	Definition
/ TimeCard	- TimeCardType - (1/1)	A record describing the time and/or expense data of a person or resource for a given period.
/ TimeCard/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedResource	Person - TimeCardPersonType - C (1/1) Resource - [complexType] - C (1/1)	Container describing the person or resource for which time and/or expense is being reported.
/ TimeCard/ ReportedResource/ Person	- TimeCardPersonType - C (1/1)	Context definition: Container for the person who performed the work.
/ TimeCard/ ReportedResource/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedResource/ Resource	type - xsd:string - Id - EntityIdType - S (0/) ResourceName - xsd:string - S (0/1) AdditionalData - AdditionalDataType - S (0/)	The resource (non human) for which the time and/or expense is being reported. [Example(s): Room Designation, Contractor Supplied, Desk ]
/ TimeCard/ ReportedResource/ Resource/ type	- xsd:string -	Further defines the associated element in the context provided.
/ TimeCard/ ReportedResource/ Resource/ Id	- EntityIdType - S (0/*)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedResource/ Resource/ ResourceName	- xsd:string - S (0/1)	The name of a resource (non human), for which times and expenses may be reported. [BusinessRule(s): This element restricts the allowed values for the element ResourceName of the Resource element for the Time Card. ]
/ TimeCard/ ReportedResource/ Resource/ AdditionalData	- AdditionalDataType - S (0/*)	Allows trading partner specific structured information or extensions.
/ TimeCard/ ReportedTime	status - xsd:string - PeriodStartDate - AnyDateTimeType - S (1/1) PeriodEndDate - AnyDateTimeType - S (1/1) ReportedPersonAssignment - [complexType] - S (0/1) TimeInterval - xsd:double - C (1/1) TimeEvent - xsd:double - C (1/1) Expense - xsd:double - C (1/1) Allowance - xsd:double - C (1/1) AdditionalData - AdditionalDataType - S (0/) ApprovalInfo - ApprovalInfoType - S (0/) SubmitterInfo - SubmitterInfoType - S (0/1)	A container with reported time and/or expense data for a person or resource in a given period.
/ TimeCard/ ReportedTime/ status	- xsd:string -	The status of the associated item. If the status isn't specified, the implementer may place the record in whatever status seems appropriate given the context of the data. Although this is a string, documentation contains a list of recommended statuses with definitions. The recommended statuses are Raw, Processed, Submitted, Approved, Rejected, Final.
/ TimeCard/ ReportedTime/ PeriodStartDate	- AnyDateTimeType - S (1/1)	The starting date of the reported time. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601. ]
/ TimeCard/ ReportedTime/ PeriodEndDate	- AnyDateTimeType - S (1/1)	The ending date of the reported time. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601. ]
/ TimeCard/ ReportedTime/ ReportedPersonAssignment	Id - EntityIdType - S (0/1)	Allows a work assignment identifier to be expressed that will apply to all data within the ReportedTime container.
/ TimeCard/ ReportedTime/ ReportedPersonAssignment/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeInterval	type - xsd:string - required dayAssignment - DayAssignmentType - billable - xsd:boolean - actionCode - ActionCodeType - Id - EntityIdType - S (0/1) StartDateTime - AnyDateTimeType - S (1/1) EndDateTime - AnyDateTimeType - S (1/1) Duration - TimeCardDuration - S (0/1) Duration - TimeCardDuration - C (1/1) PieceWork - xsd:double - S (0/) RateOrAmount - xsd:double - S (0/) Allowance - xsd:double - S (0/) AdditionalData - AdditionalDataType - S (0/) ApprovalInfo - ApprovalInfoType - S (0/) SubmitterInfo - SubmitterInfoType - S (0/1) Comment - CommentType - S (0/)	A container used to report the duration and type of a work for a specified time period.
/ TimeCard/ ReportedTime/ TimeInterval/ type	- xsd:string -	Further defines the associated element in the context provided.
/ TimeCard/ ReportedTime/ TimeInterval/ dayAssignment	- DayAssignmentType -	Allows assignment of work performed on a "physical" time interval or day to another "logical" day. Mostly for evaluation purposes. [BusinessRule(s): Current (Start Date), Next (Start Date + 1), Previous (Start Date - 1) ] [Example(s): It is important to know for purposes of calculating pay which day should be considered the working day. For instance 10pm Sat to 6am Sun. Do we pay at time plus one half for Sat, or double time for Sun. The indicator will allow the pay system to make this determination. ]
/ TimeCard/ ReportedTime/ TimeInterval/ billable	- xsd:boolean -	Attribute used to indicate whether the time interval, time event, or expense is billable to a customer.
/ TimeCard/ ReportedTime/ TimeInterval/ actionCode	- ActionCodeType -	A code specifying the action to be performed on a particular record. [Example(s): Add, Change, Void, Unchanged. For example, when a manager corrects a time card, she would specify the previously reported Time Event or Time Interval was to be voided. ]
/ TimeCard/ ReportedTime/ TimeInterval/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeInterval/ StartDateTime	- AnyDateTimeType - S (1/1)	Defines the start date, and if applicable, start time of the interval, period, or event being reported. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601. ]
/ TimeCard/ ReportedTime/ TimeInterval/ EndDateTime	- AnyDateTimeType - S (1/1)	Defines the end date, and if applicable, end time of the interval, period, or event being reported. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601. ]
/ TimeCard/ ReportedTime/ TimeInterval/ Duration	- TimeCardDuration - S (0/1)	Specifies the duration of the reported work. [BusinessRule(s): If not specified, typically the duration is derived by the receiving system on the basis of work schedule information and/or Start/EndDateTime, ]
/ TimeCard/ ReportedTime/ TimeInterval/ Duration	- TimeCardDuration - C (1/1)	Specifies the duration of the reported work. [BusinessRule(s): If not specified, typically the duration is derived by the receiving system on the basis of work schedule information and/or Start/EndDateTime, ]
/ TimeCard/ ReportedTime/ TimeInterval/ PieceWork	Piece - [complexType] - S (1/1) Quantity - xsd:double - S (1/1)	Container for the id, description and/or quantity of the work piece.
/ TimeCard/ ReportedTime/ TimeInterval/ PieceWork/ Piece	Id - EntityIdType - S (0/1) PieceValue - xsd:string - S (1/1)	Container for the id and description of the work piece.
/ TimeCard/ ReportedTime/ TimeInterval/ PieceWork/ Piece/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeInterval/ PieceWork/ Piece/ PieceValue	- xsd:string - S (1/1)	Describes the type of work piece. [Example(s): Sweater, belt. ]
/ TimeCard/ ReportedTime/ TimeInterval/ PieceWork/ Quantity	xsd:extension base: xsd:double unitOfMeasure - xsd:string -	A numerical quantity that is assigned or determined by calculation or measurement. [Example(s): The number of shares to be vested, number of produced pieces, number of benefit Id cards, or number of positions to be filled. ]
/ TimeCard/ ReportedTime/ TimeInterval/ PieceWork/ Quantity/ unitOfMeasure	- xsd:string -	Unit in which the quantity is measured. [Example(s): Piece, Liters, Meters ]
/ TimeCard/ ReportedTime/ TimeInterval/ RateOrAmount	xsd:extension base: xsd:double currency - CurrencyCodeType - required type - xsd:string - required period - xsd:string - multiplier - xsd:double - toBeBilled - xsd:boolean - toBePaid - xsd:boolean -	Container for a rate or a flat amount to be applied to the reported work.
/ TimeCard/ ReportedTime/ TimeInterval/ RateOrAmount/ currency	- CurrencyCodeType -	A three-letter code identifying the currency of a monetary amount. [BusinessRule(s): Currency is represented in accordance with ISO 4217 ]
/ TimeCard/ ReportedTime/ TimeInterval/ RateOrAmount/ type	- xsd:string -	Further defines the associated element in the context provided.
/ TimeCard/ ReportedTime/ TimeInterval/ RateOrAmount/ period	- xsd:string -	Period used to further define the rate. [Example(s): Hourly, Weekly, BI-Weekly, Monthly Annually, Per Pay Period ]
/ TimeCard/ ReportedTime/ TimeInterval/ RateOrAmount/ multiplier	- xsd:double -	A multiplier to be applied to the related amount, rate, or variable. [Example(s): Some staffing calculations require a multiplier for custom overtime or wage factor. ]
/ TimeCard/ ReportedTime/ TimeInterval/ RateOrAmount/ toBeBilled	- xsd:boolean -	Indicates if this RateOrAmount is to be billed to the supplier of the resource.
/ TimeCard/ ReportedTime/ TimeInterval/ RateOrAmount/ toBePaid	- xsd:boolean -	Indicates if this RateOrAmount is to be paid to the resource that this timecard refers to.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance	type - xsd:string - required billable - xsd:boolean - actionCode - ActionCodeType - Id - EntityIdType - S (0/1) StartDate - AnyDateTimeType - S (0/1) EndDate - AnyDateTimeType - S (0/1) Amount - xsd:double - S (0/1) Quantity - xsd:double - S (0/1) AdditionalData - AdditionalDataType - S (0/) ApprovalInfo - ApprovalInfoType - S (0/) SubmitterInfo - SubmitterInfoType - S (0/1) Comment - CommentType - S (0/*)	Contains groups of allowances for the time period or interval.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ type	- xsd:string -	Further defines the associated element in the context provided.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ billable	- xsd:boolean -	Attribute used to indicate whether the time interval, time event, or expense is billable to a customer.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ actionCode	- ActionCodeType -	A code specifying the action to be performed on a particular record. [Example(s): Add, Change, Void, Unchanged. For example, when a manager corrects a time card, she would specify the previously reported Time Event or Time Interval was to be voided. ]
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ StartDate	- AnyDateTimeType - S (0/1)	Contains the (inclusive) date, period, or interval the event becomes active or begins. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601. ] [Example(s): Position start date, assignment start date, rate change, effective date ]
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ EndDate	- AnyDateTimeType - S (0/1)	Contains the (inclusive) date, period, or interval the event becomes inactive or ends. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ Amount	xsd:extension base: xsd:double currency - CurrencyCodeType - required	The monetary value of the associated item. [Example(s): Bill rate, invoice item, compensation, allowance. ]
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ Amount/ currency	- CurrencyCodeType -	A three-letter code identifying the currency of a monetary amount. [BusinessRule(s): Currency is represented in accordance with ISO 4217 ]
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ Quantity	- xsd:double - S (0/1)	A numerical quantity that is assigned or determined by calculation or measurement. [Example(s): The number of shares to be vested, number of produced pieces, number of benefit Id cards, or number of positions to be filled. ]
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ AdditionalData	- AdditionalDataType - S (0/*)	Allows trading partner specific structured information or extensions.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ ApprovalInfo	- ApprovalInfoType - S (0/*)	Container which holds information about when and by whom the entire Timecard was approved.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ ApprovalInfo/ Person	- TimeCardPersonType - S (1/1)	Context definition: Container for the person who approved the reported time interval allowance data.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ ApprovalInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ ApprovalInfo/ ApprovedDateTime	- AnyDateTimeType - S (1/1)	The timestamp when the time card was approved.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ ApprovalInfo/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ SubmitterInfo	- SubmitterInfoType - S (0/1)	Container with information describing when and by whom the entire Timecard was submitted.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ SubmitterInfo/ Person	- TimeCardPersonType - S (0/1)	Context definition: Container for the person who submitted the reported time interval allowance data.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ SubmitterInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ SubmitterInfo/ Source	- xsd:string - S (0/1)	The system that submitted the timecard. [Example(s): Time Clock, IVR, Web Time ]
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ SubmitterInfo/ SubmittedDateTime	- AnyDateTimeType - S (1/1)	The timestamp as to when the timecard was submitted.
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ TimeInterval/ AdditionalData	- AdditionalDataType - S (0/*)	Allows trading partner specific structured information or extensions.
/ TimeCard/ ReportedTime/ TimeInterval/ ApprovalInfo	- ApprovalInfoType - S (0/*)	Container which holds information about when and by whom the entire Timecard was approved.
/ TimeCard/ ReportedTime/ TimeInterval/ ApprovalInfo/ Person	- TimeCardPersonType - S (1/1)	Context definition: Container for the person who approved the reported time interval data.
/ TimeCard/ ReportedTime/ TimeInterval/ ApprovalInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeInterval/ ApprovalInfo/ ApprovedDateTime	- AnyDateTimeType - S (1/1)	The timestamp when the time card was approved.
/ TimeCard/ ReportedTime/ TimeInterval/ ApprovalInfo/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ TimeInterval/ SubmitterInfo	- SubmitterInfoType - S (0/1)	Container with information describing when and by whom the entire Timecard was submitted.
/ TimeCard/ ReportedTime/ TimeInterval/ SubmitterInfo/ Person	- TimeCardPersonType - S (0/1)	Context definition: Container for the person who submitted the reported time interval data.
/ TimeCard/ ReportedTime/ TimeInterval/ SubmitterInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeInterval/ SubmitterInfo/ Source	- xsd:string - S (0/1)	The system that submitted the timecard. [Example(s): Time Clock, IVR, Web Time ]
/ TimeCard/ ReportedTime/ TimeInterval/ SubmitterInfo/ SubmittedDateTime	- AnyDateTimeType - S (1/1)	The timestamp as to when the timecard was submitted.
/ TimeCard/ ReportedTime/ TimeInterval/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ TimeEvent	type - xsd:string - required dayAssignment - DayAssignmentType - billable - xsd:boolean - actionCode - ActionCodeType - Id - EntityIdType - S (0/1) EventDateTime - AnyDateTimeType - S (1/1) RateOrAmount - xsd:double - S (0/) AdditionalData - AdditionalDataType - S (0/) ApprovalInfo - ApprovalInfoType - S (0/) SubmitterInfo - SubmitterInfoType - S (0/1) Comment - CommentType - S (0/)	A container for a work time event that occurred at a specific point in time.
/ TimeCard/ ReportedTime/ TimeEvent/ type	- xsd:string -	Further defines the associated element in the context provided.
/ TimeCard/ ReportedTime/ TimeEvent/ dayAssignment	- DayAssignmentType -	Allows assignment of work performed on a "physical" time interval or day to another "logical" day. Mostly for evaluation purposes. [BusinessRule(s): Current (Start Date), Next (Start Date + 1), Previous (Start Date - 1) ] [Example(s): It is important to know for purposes of calculating pay which day should be considered the working day. For instance 10pm Sat to 6am Sun. Do we pay at time plus one half for Sat, or double time for Sun. The indicator will allow the pay system to make this determination. ]
/ TimeCard/ ReportedTime/ TimeEvent/ billable	- xsd:boolean -	Attribute used to indicate whether the time interval, time event, or expense is billable to a customer.
/ TimeCard/ ReportedTime/ TimeEvent/ actionCode	- ActionCodeType -	A code specifying the action to be performed on a particular record. [Example(s): Add, Change, Void, Unchanged. For example, when a manager corrects a time card, she would specify the previously reported Time Event or Time Interval was to be voided. ]
/ TimeCard/ ReportedTime/ TimeEvent/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeEvent/ EventDateTime	- AnyDateTimeType - S (1/1)	The timestamp for when the event occurred.
/ TimeCard/ ReportedTime/ TimeEvent/ RateOrAmount	xsd:extension base: xsd:double currency - CurrencyCodeType - required type - xsd:string - required period - xsd:string -	Container for a rate or a flat amount to be applied to the reported work.
/ TimeCard/ ReportedTime/ TimeEvent/ RateOrAmount/ currency	- CurrencyCodeType -	A three-letter code identifying the currency of a monetary amount. [BusinessRule(s): Currency is represented in accordance with ISO 4217 ]
/ TimeCard/ ReportedTime/ TimeEvent/ RateOrAmount/ type	- xsd:string -	Further defines the associated element in the context provided.
/ TimeCard/ ReportedTime/ TimeEvent/ RateOrAmount/ period	- xsd:string -	Period used to further define the rate. [Example(s): Hourly, Weekly, BI-Weekly, Monthly Annually, Per Pay Period ]
/ TimeCard/ ReportedTime/ TimeEvent/ AdditionalData	- AdditionalDataType - S (0/*)	Allows trading partner specific structured information or extensions.
/ TimeCard/ ReportedTime/ TimeEvent/ ApprovalInfo	- ApprovalInfoType - S (0/*)	Container which holds information about when and by whom the entire Timecard was approved.
/ TimeCard/ ReportedTime/ TimeEvent/ ApprovalInfo/ Person	- TimeCardPersonType - S (1/1)	Context definition: Container for the person who approved the reported time event data.
/ TimeCard/ ReportedTime/ TimeEvent/ ApprovalInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeEvent/ ApprovalInfo/ ApprovedDateTime	- AnyDateTimeType - S (1/1)	The timestamp when the time card was approved.
/ TimeCard/ ReportedTime/ TimeEvent/ ApprovalInfo/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ TimeEvent/ SubmitterInfo	- SubmitterInfoType - S (0/1)	Container with information describing when and by whom the entire Timecard was submitted.
/ TimeCard/ ReportedTime/ TimeEvent/ SubmitterInfo/ Person	- TimeCardPersonType - S (0/1)	Context definition: Container for the person who submitted the reported time event data.
/ TimeCard/ ReportedTime/ TimeEvent/ SubmitterInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ TimeEvent/ SubmitterInfo/ Source	- xsd:string - S (0/1)	The system that submitted the timecard. [Example(s): Time Clock, IVR, Web Time ]
/ TimeCard/ ReportedTime/ TimeEvent/ SubmitterInfo/ SubmittedDateTime	- AnyDateTimeType - S (1/1)	The timestamp as to when the timecard was submitted.
/ TimeCard/ ReportedTime/ TimeEvent/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ Expense	type - xsd:string - required billable - xsd:boolean - actionCode - ActionCodeType - Id - EntityIdType - S (0/1) ExpenseDate - AnyDateTimeType - S (1/1) ExpenseAmount - xsd:double - S (1/1) AdditionalData - AdditionalDataType - S (0/) ApprovalInfo - ApprovalInfoType - S (0/) SubmitterInfo - SubmitterInfoType - S (0/1) Comment - CommentType - S (0/*)	Container for individual expenses incurred.
/ TimeCard/ ReportedTime/ Expense/ type	- xsd:string -	Further defines the associated element in the context provided.
/ TimeCard/ ReportedTime/ Expense/ billable	- xsd:boolean -	Attribute used to indicate whether the time interval, time event, or expense is billable to a customer.
/ TimeCard/ ReportedTime/ Expense/ actionCode	- ActionCodeType -	A code specifying the action to be performed on a particular record. [Example(s): Add, Change, Void, Unchanged. For example, when a manager corrects a time card, she would specify the previously reported Time Event or Time Interval was to be voided. ]
/ TimeCard/ ReportedTime/ Expense/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ Expense/ ExpenseDate	- AnyDateTimeType - S (1/1)	The date that the expense was incurred.
/ TimeCard/ ReportedTime/ Expense/ ExpenseAmount	xsd:extension base: xsd:double currency - CurrencyCodeType - required	The monetary value of the expense.
/ TimeCard/ ReportedTime/ Expense/ ExpenseAmount/ currency	- CurrencyCodeType -	A three-letter code identifying the currency of a monetary amount. [BusinessRule(s): Currency is represented in accordance with ISO 4217 ]
/ TimeCard/ ReportedTime/ Expense/ AdditionalData	- AdditionalDataType - S (0/*)	Allows trading partner specific structured information or extensions.
/ TimeCard/ ReportedTime/ Expense/ ApprovalInfo	- ApprovalInfoType - S (0/*)	Container which holds information about when and by whom the entire Timecard was approved.
/ TimeCard/ ReportedTime/ Expense/ ApprovalInfo/ Person	- TimeCardPersonType - S (1/1)	Context definition: Container for the person who approved the reported expense data.
/ TimeCard/ ReportedTime/ Expense/ ApprovalInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ Expense/ ApprovalInfo/ ApprovedDateTime	- AnyDateTimeType - S (1/1)	The timestamp when the time card was approved.
/ TimeCard/ ReportedTime/ Expense/ ApprovalInfo/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ Expense/ SubmitterInfo	- SubmitterInfoType - S (0/1)	Container with information describing when and by whom the entire Timecard was submitted.
/ TimeCard/ ReportedTime/ Expense/ SubmitterInfo/ Person	- TimeCardPersonType - S (0/1)	Context definition: Container for the person who submitted the reported expense data.
/ TimeCard/ ReportedTime/ Expense/ SubmitterInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ Expense/ SubmitterInfo/ Source	- xsd:string - S (0/1)	The system that submitted the timecard. [Example(s): Time Clock, IVR, Web Time ]
/ TimeCard/ ReportedTime/ Expense/ SubmitterInfo/ SubmittedDateTime	- AnyDateTimeType - S (1/1)	The timestamp as to when the timecard was submitted.
/ TimeCard/ ReportedTime/ Expense/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ Allowance	type - xsd:string - required billable - xsd:boolean - actionCode - ActionCodeType - Id - EntityIdType - S (0/1) StartDate - AnyDateTimeType - S (1/1) EndDate - AnyDateTimeType - S (0/1) Amount - xsd:double - S (0/1) Quantity - xsd:double - S (0/1) AdditionalData - AdditionalDataType - S (0/) ApprovalInfo - ApprovalInfoType - S (0/) SubmitterInfo - SubmitterInfoType - S (0/1) Comment - CommentType - S (0/*)	Contains groups of allowances for the time period or interval.
/ TimeCard/ ReportedTime/ Allowance/ type	- xsd:string -	Further defines the associated element in the context provided.
/ TimeCard/ ReportedTime/ Allowance/ billable	- xsd:boolean -	Attribute used to indicate whether the time interval, time event, or expense is billable to a customer.
/ TimeCard/ ReportedTime/ Allowance/ actionCode	- ActionCodeType -	A code specifying the action to be performed on a particular record. [Example(s): Add, Change, Void, Unchanged. For example, when a manager corrects a time card, she would specify the previously reported Time Event or Time Interval was to be voided. ]
/ TimeCard/ ReportedTime/ Allowance/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ Allowance/ StartDate	- AnyDateTimeType - S (1/1)	Contains the (inclusive) date, period, or interval the event becomes active or begins. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601. ] [Example(s): Position start date, assignment start date, rate change, effective date ]
/ TimeCard/ ReportedTime/ Allowance/ EndDate	- AnyDateTimeType - S (0/1)	Contains the (inclusive) date, period, or interval the event becomes inactive or ends. [BusinessRule(s): This date is inclusive. Dates are represented in accordance with ISO 8601.
/ TimeCard/ ReportedTime/ Allowance/ Amount	xsd:extension base: xsd:double currency - CurrencyCodeType - required	The monetary value of the associated item. [ [Example(s): Bill rate, invoice item, compensation, allowance. ]
/ TimeCard/ ReportedTime/ Allowance/ Amount/ currency	- CurrencyCodeType -	A three-letter code identifying the currency of a monetary amount. [BusinessRule(s): Currency is represented in accordance with ISO 4217 ]
/ TimeCard/ ReportedTime/ Allowance/ Quantity	- xsd:double - S (0/1)	A numerical quantity that is assigned or determined by calculation or measurement. [Example(s): The number of shares to be vested, number of produced pieces, number of benefit Id cards, or number of positions to be filled. ]
/ TimeCard/ ReportedTime/ Allowance/ AdditionalData	- AdditionalDataType - S (0/*)	Allows trading partner specific structured information or extensions.
/ TimeCard/ ReportedTime/ Allowance/ ApprovalInfo	- ApprovalInfoType - S (0/*)	Container which holds information about when and by whom the entire Timecard was approved.
/ TimeCard/ ReportedTime/ Allowance/ ApprovalInfo/ Person	- TimeCardPersonType - S (1/1)	Context definition: Container for the person who approved the reported allowance data.
/ TimeCard/ ReportedTime/ Allowance/ ApprovalInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ Allowance/ ApprovalInfo/ ApprovedDateTime	- AnyDateTimeType - S (1/1)	The timestamp when the time card was approved.
/ TimeCard/ ReportedTime/ Allowance/ ApprovalInfo/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ Allowance/ SubmitterInfo	- SubmitterInfoType - S (0/1)	Container with information describing when and by whom the entire Timecard was submitted.
/ TimeCard/ ReportedTime/ Allowance/ SubmitterInfo/ Person	- TimeCardPersonType - S (0/1)	Context definition: Container for the person who submitted the reported allowance data.
/ TimeCard/ ReportedTime/ Allowance/ SubmitterInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ Allowance/ SubmitterInfo/ Source	- xsd:string - S (0/1)	The system that submitted the timecard. [Example(s): Time Clock, IVR, Web Time ]
/ TimeCard/ ReportedTime/ Allowance/ SubmitterInfo/ SubmittedDateTime	- AnyDateTimeType - S (1/1)	The timestamp as to when the timecard was submitted.
/ TimeCard/ ReportedTime/ Allowance/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ AdditionalData	- AdditionalDataType - S (0/*)	Allows trading partner specific structured information or extensions.
/ TimeCard/ ReportedTime/ ApprovalInfo	- ApprovalInfoType - S (0/*)	Container which holds information about when and by whom the entire Timecard was approved.
/ TimeCard/ ReportedTime/ ApprovalInfo/ Person	- TimeCardPersonType - S (1/1)	Context definition: Container for the person who approved the reported time data.
/ TimeCard/ ReportedTime/ ApprovalInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ ApprovalInfo/ ApprovedDateTime	- AnyDateTimeType - S (1/1)	The timestamp when the time card was approved.
/ TimeCard/ ReportedTime/ ApprovalInfo/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ SubmitterInfo	- SubmitterInfoType - S (0/1)	Container with information describing when and by whom the entire Timecard was submitted.
/ TimeCard/ ReportedTime/ SubmitterInfo/ Person	- TimeCardPersonType - S (0/1)	Context definition: Container for the person who submitted the reported time data.
/ TimeCard/ ReportedTime/ SubmitterInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ReportedTime/ SubmitterInfo/ Source	- xsd:string - S (0/1)	The system that submitted the timecard. [Example(s): Time Clock, IVR, Web Time ]
/ TimeCard/ ReportedTime/ SubmitterInfo/ SubmittedDateTime	- AnyDateTimeType - S (1/1)	The timestamp as to when the timecard was submitted.
/ TimeCard/ SubmitterInfo	- SubmitterInfoType - S (0/1)	Container with information describing when and by whom the entire Timecard was submitted.
/ TimeCard/ SubmitterInfo/ Person	- TimeCardPersonType - S (0/1)	Context definition: Container for the person who submitted the time card.
/ TimeCard/ SubmitterInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ SubmitterInfo/ Source	- xsd:string - S (0/1)	The system that submitted the timecard. [Example(s): Time Clock, IVR, Web Time ]
/ TimeCard/ SubmitterInfo/ SubmittedDateTime	- AnyDateTimeType - S (1/1)	The timestamp as to when the timecard was submitted.
/ TimeCard/ ApprovalInfo	- ApprovalInfoType - S (0/*)	Container which holds information about when and by whom the entire Timecard was approved.
/ TimeCard/ ApprovalInfo/ Person	- TimeCardPersonType - S (1/1)	Context definition: Container for the person who approved the time card.
/ TimeCard/ ApprovalInfo/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ TimeCard/ ApprovalInfo/ ApprovedDateTime	- AnyDateTimeType - S (1/1)	The timestamp when the time card was approved.
/ TimeCard/ ApprovalInfo/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ AdditionalData	- AdditionalDataType - S (0/*)	Allows trading partner specific structured information or extensions.

Global types (alphabetically listed)	ContentModel* Data type Occurrence: Sequence \| Choice \| All (minOccurs/maxOccurs) Attributes	Definition *
/ [ActionCodeType]	xsd:restriction base: xsd:string [Enumerations]: Add, Change, Void, Unchanged	Globally scoped data type. See element or attribute declaration for definition.
/ [AdditionalDataType]	type - xsd:string -	Globally scoped data type. See element or attribute declaration for definition.
/ [AdditionalDataType] / type	- xsd:string -	Further defines the associated element in the context provided.
/ [ApprovalInfoType]	approverType - xsd:string - Person - TimeCardPersonType - S (1/1) ApprovedDateTime - AnyDateTimeType - S (1/1) Comment - CommentType - S (0/*)	Globally scoped data type. See element or attribute declaration for definition.
/ [ApprovalInfoType] / approverType	- xsd:string -	Allows a description of the level or role of the approver. [Example(s): Supervisor, Manager ]
/ [ApprovalInfoType]/ Person	- TimeCardPersonType - S (1/1)	Contains information about a person.
/ [ApprovalInfoType]/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ [ApprovalInfoType]/ ApprovedDateTime	- AnyDateTimeType - S (1/1)	The timestamp when the time card was approved.
/ [ApprovalInfoType]/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ [CommentType]	xsd:extension base: xsd:string xml:lang - -	Globally scoped data type. See element or attribute declaration for definition.
/ [CommentType] /		Globally scoped data type. See element or attribute declaration for definition.
/ [DayAssignmentEnumerationType]	xsd:restriction base: xsd:string [Enumerations]: previous, current, next	Globally scoped data type. See element or attribute declaration for definition.
/ [DayAssignmentType]	- [Union]: DayAssignmentEnumerationType,LocalDateType, xsd:nonNegativeInteger	Globally scoped data type. See element or attribute declaration for definition.
/ [SubmitterInfoType]	Person - TimeCardPersonType - S (0/1) Source - xsd:string - S (0/1) SubmittedDateTime - AnyDateTimeType - S (1/1)	Globally scoped data type. See element or attribute declaration for definition.
/ [SubmitterInfoType]/ Person	- TimeCardPersonType - S (0/1)	Contains information about a person.
/ [SubmitterInfoType]/ Person/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ [SubmitterInfoType]/ Source	- xsd:string - S (0/1)	The system that submitted the timecard. [Example(s): Time Clock, IVR, Web Time ]
/ [SubmitterInfoType]/ SubmittedDateTime	- AnyDateTimeType - S (1/1)	The timestamp as to when the timecard was submitted.
/ [TimeCardDuration]	- [Union]: xsd:duration,xsd:decimal	Globally scoped data type. See element or attribute declaration for definition.
/ [TimeCardPersonType]	Id - EntityIdType - S (0/1) PersonName - [see include/import] - S (0/1)	Globally scoped data type. See element or attribute declaration for definition.
/ [TimeCardPersonType]/ Id	- EntityIdType - S (0/1)	A unique identifier used to reference the entity. The Id is associated with the higher level element.
/ [TimeCardType]	xml:lang - - Id - EntityIdType - S (0/1) ReportedResource - [complexType] - S (1/1) ReportedTime - xsd:double - S (1/) SubmitterInfo - SubmitterInfoType - S (0/1) ApprovalInfo - ApprovalInfoType - S (0/) AdditionalData - AdditionalDataType - S (0/*) UserArea - [see include/import] - S (0/1)	Globally scoped data type. See element or attribute declaration for definition.

4 Implementation Considerations

The workgroup has made the deliberate choice to leave the various type attributes as non-enumerated holders. A follow-up document pertaining to implementation suggestions will include anticipated values for many of these attributes, as well as further suggestions regarding the batching of records and other transmission related topics.

4.1 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.2 Action Code

The ActionCode defines how the receiver should process the transmitted data. The following list describes the purpose of each enumerated value:

"Add" means that the information should be used to create a new object. If an Id is given, no object with that Id should exist.
"Change" means to change the existing object with the given Id.
"Void" means to void an existing object with the given Id. Based on trading partner agreement and legal requirements this might delete an existing object or mark the object as cancelled. So the term void was used instead of delete, remove or cancel.
“Unchanged” means that the existing object with the given Id has not been changed.

4.3 Status

The status attribute of the ReportedTime element describes the status of the time card data, and makes it possible to handle the data in correct way. This status attributes makes it possible to handle complex processes including processes with complex approval processes, time machines, etc.

Within this document already two statuses were introduced: Raw and Processed. Below the table consist of currently all known statuses. Although implementations are not limited to this list we strongly encourage to use statuses according to this list. Never should statuses be used with the same naming but with different definitions. If new statuses are needed they can already be used within this Schema (no restriction in the Schema), however it is requested to add the new status as maintenance request to the time card workgroup.

Status	Definition
Raw	Raw implies that the data in this timecard has not had some added value such as hour rate applied. The data has probably originated from a timecard device or simple data capture and will be subsequently handed over to an application like T&A for added processing.
Processed	Processed usually indicated that the T&A or other application is handing off a completed timecard to one or more consuming applications such as payroll, billing etc. This does not imply that the timecard is finalized, and processing is completely done.
Submitted	The timesheet data has been entered by the resource and submitted to the approver but has not yet been approved.
Rejected	The timesheet data has been sent back to the resource for correction.
Approved	The submitted timesheet has been approved by the approver.
Final	The approved timesheet has been finalized by the supplier and cannot therefore be changed. The processing of the timecard is complete. This means that the processing of the timecard is completed.

5 Issues List

Issue

Anticipated

Resolution

Expression of non-standard time units – in this version a make-do solution offered by understanding between the trading partners or with values fitted into the piecework framework.

Future version

Lack of sophistication in the handling of expenses – in this version a minimal attempt was made to define requirements for expense reporting in favor of concentration on time reporting. It is expected that the expense portion of the schema will become more sophisticated in the next release.

Several maintenance requests (including for instance aligning allowances and expenses, or re-modeling of submitter and approver) have impact on the backward compatibility and are therefore not yet included.

Future version

(major release)

6 Appendix A - Document Version History

Date	Description
2002-Jan-30	Target/default namespaces changed.
2002-Mar-11	Move to v2. Remove batch, add extensions mechanism.
2002-Mar-19	Modified text to correctly describe the updated schema.
2002-Mar-20	Added reference examples.
2002-Mar-25	Added definitions table, final cleanup.
2002-Apr-1	Replaced example 6. Present for membership review.
2002-Apr-30	Approved Specification
2003-Feb-26	Approved recommendation by HR-XML Consortium. The default and targetNamespaces of all HR-XML schemas have been standardized. This recommendation is available as part of the HR-XML 2_0 architecture.
2003-Jul-18	- added allowance at reported times and time interval level -added multiplier, billed and paid at rate or amount
2003-Jul-21	- removed last of the groups (Turbo gets confused in the graphical representation) - in RateOrAmount changed type of multiplier to double, type of billed to boolean and type of paid to boolean - in TimeInterval/Allowance changed the type to doubleOrEmptyString and the name of allowanceQuantity to quantity - in ReportedTimes/Allowance changed type of Start and EndDate to AnyDateTime, changed Amount to type double with attribute currency
2003-Jul-24	- changed billed and paid to ToBeBilled and TobePaid - synchronized the two allowance structures
2004-Apr-23	- added xml:lang attribute to time card type - defined type CommentType with xml:lang attribute - changed all Comment elements to use CommentType and made them multiple occurrence - defined type DayAssignmentEnumerationType (current, previous or next) - added type DayAssignmentType as a union of DayAssignmentEnumerationType, LocalDateType and nonnegativeInteger - changed attribute dayAssignmentType of timeInterval and TimeEvent to use the type DayAssignmentType
2004-Apr-28	- added type ActionCode - added optional attribute actionCode for TimeInterval, TimeEvent, Allowance and Expense - changed enumeration value "Delete" in the enumeration of actionCode to "Void"
2004-May-13	Updated document based on schema changes.
2004-May-19	Submit for CPO/TSC review.
2004-Jun-04	Added guidelines for action code.
2004-Sep-10	Changed duration to used global type.
2005-Jan	- As per Schema Design Guidelines, all default values have been removed. - Substituted CurrencyType with ISOUtilities.xsd type called CurrencyCodeType
2005 Timecard 2.1	· Added Allowance at ReportedTime and TimeInterval levels to handle elements that are not an elapsed time. · Added multiplier, toBeBilled, and toBePaid attributes to RateOrAmount to handle invoicing information. · Replace the following groups with complex types. This was mainly to address the limitations of Turbo’s graphical representation. o AdditionalData, ApprovalInfo, Person, RateOrAmount,Id, Duration · Added xml:lang attribute to TimeCard and Comment to allow for multiple languages. · Increased allowed values for dayAssignment: o Created type DayAssignmentEnumerationType (current, previous or next) o Changed dayAssignment to use new DayAssignmentType. This is a union of DayAssignmentEnumerationType, LocalDateType and nonnegativeInteger. Added optional attribute actionCode for TimeInterval, TimeEvent, Allowance and Expense. It contains the enumerations ‘change’, ‘add’, and ‘void’.
2006-Feb-28	Approved by membership
2006-Apr-07	Changes documented for 2.5 release -MR28:Added billable indicator to Allowance, Replaced the Allowance element on TimeInterval with the richer Allowance element on ReportedTime level. -MR29: Added "Unchanged" to enumeration of ActionCodeType -MR63: Added SubmitterInfo element on every location where the ApprovalInfo element was already in place. -MR80: Removed the restriction on the status attribute of ReportedTime, and included within this documentation a list of proposed values with definitions. -MR90: Removed changed history from Schema and copied in this table
2007-Apr-15	Approved by Consortium

7 Appendix B – Related Documents

Reference	Link
TimeCard schema	http://ns.hr-xml.org/2_5/HR-XML-2_5/TimeCard/TimeCard.xsd
TimeCard examples	http://ns.hr-xml.org/2_5/HR-XML-2_5/TimeCard/TimeCard1.xml http://ns.hr-xml.org/2_5/HR-XML-2_5/TimeCard/TimeCard2.xml http://ns.hr-xml.org/2_5/HR-XML-2_5/TimeCard/TimeCard3.xml http://ns.hr-xml.org/2_5/HR-XML-2_5/TimeCard/TimeCard4.xml http://ns.hr-xml.org/2_5/HR-XML-2_5/TimeCard/TimeCard5.xml http://ns.hr-xml.org/2_5/HR-XML-2_5/TimeCard/TimeCard6.xml http://ns.hr-xml.org/2_5/HR-XML-2_5/TimeCard/TimeCard7.xml
Entity Identifier Type	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/EntityIdentifiers.html http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/EntityIdType.xsd
PersonName	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/PersonName.html http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/PersonName.xsd
PostalAddress	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/PostalAddress.html http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/PostalAddress.xsd
DateTimeDataTypes	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/DateTimeDataTypes.html http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/DateTimeDataTypes.xsd
SIDES schema	http://ns.hr-xml.org/2_5/HR-XML-2_5/SIDES/TimeCardAdditionalData.xsd
TSC Extension	http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/UserArea.xsd http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/HRXMLExtension.html

8 Appendix C – Reference Examples

Examples map to instances displayed in Sections 2.2.4 and 2.3.4.

Example 1:

<Id>

</Id>

</Person>

</ReportedResource>

<AdditionalData type="Task">Repair</AdditionalData>

<Comment>Aaabbbccc</Comment>

</TimeInterval>

</Expense>

</TimeInterval>

<AdditionalData type="Task">Production</AdditionalData>

</TimeInterval>

</TimeInterval>

</TimeInterval>

</ReportedTime>

</TimeCard>

Example 2:

<Id>

</Id>

</Person>

</ReportedResource>

<AdditionalData type="Task">Repair</AdditionalData>

<Comment>Aaabbbccc</Comment>

</TimeInterval>

</Expense>

</TimeInterval>

<Piece>

<PieceValue>gadget</PieceValue>

</Piece>

</PieceWork>

<AdditionalData type="Task">Production</AdditionalData>

</TimeInterval>

</TimeInterval>

</TimeInterval>

</ReportedTime>

</TimeCard>

Example 3:

<Id>

</Id>

</Person>

</ReportedResource>

</TimeEvent>

</TimeEvent>

</TimeEvent>

</TimeEvent>

</TimeEvent>

</TimeEvent>

</ReportedTime>

</TimeCard>

Example 4:

<Id>

</Id>

</Person>

</ReportedResource>

<AdditionalData type="Task">Repair</AdditionalData>

</TimeInterval>

<AdditionalData type="Task">Repair</AdditionalData>

<Comment>Aaabbbccc</Comment>

</TimeInterval>

<AdditionalData type="Task">Repair</AdditionalData>

</TimeInterval>

</Expense>

</TimeInterval>

<AdditionalData type="Task">Production</AdditionalData>

</TimeInterval>

</TimeInterval>

</TimeInterval>

</ReportedTime>

</TimeCard>

Additional Examples:

Example 5:

This example shows the recording of various expenses, a meal, and the purchase of a book. Each amount is charged to the same project (DUP1899), however each is associated to different tasks within that project.

<Id>

</Id>

<FormattedName>Michelle Hartwick</FormattedName>

</PersonName>

</Person>

</ReportedResource>