Time Card

Recommendation, 2004-08-02

This version:

TimeCard.doc

Previous version:

TimeCard.doc

Editor:

Bill Kerr, Oracle Corporation

Gail Bubsey, Kelly Services, Inc.

Kim Bartkus, HR-XML Consortium

Authors:

Andreas Bold, SAP AG

Eva Decker, SAP AG

John DeRoche, Manpower, Inc.

Bill Kerr, Oracle Corporation

Contributors:

Members of Time Expense Reporting workgroup

©2004 HR-XML. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America.

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.

Status of this Document

2004-Aug-2: This specification has been updated from the 2003-November release. Additionally, the version number (2004-08-02) has been updated on the document title page and the “version” attribute of the “xsd:schema” element.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1 Overview.. 3

1.1 Objective. 3

1.1.1 Domain Issues. 4

1.1.2 Business Reasons. 4

1.2 Design Requirements. 4

1.3 Scope. 5

1.3.1 Major Components. 6

1.3.2 Items Within the Design Scope. 7

1.3.3 Items Outside of Design Scope. 8

2 Supported Business Processes. 8

2.1 Introduction and Actors. 8

2.1.1 Overview Activity Diagram.. 9

2.1.2 Actor: Time Capturing Device. 9

2.1.3 Actor: Time & Attendance Application. 10

2.1.4 Actor: Final Consumer Application. 10

2.2 Process: Posting of Raw Time Data. 11

2.2.1 Activity Diagram.. 11

2.2.2 Users. 11

2.2.3 Business Goal and Process. 11

2.2.4 Examples for Raw.. 13

2.3 Process: Posting of Processed Time Data. 14

2.3.1 Activity Diagram.. 14

2.3.2 Users. 15

2.3.3 Business Goal and Process. 15

2.3.4 Example of a Processed Timecard. 16

3 Schema Design. 17

3.1 Schema. 17

3.2 Schema Elements Explained. 18

4 Implementation Considerations. 31

4.1 Data Privacy. 31

4.2 Action Code. 32

5 Issues List 32

6 Appendix A - Document Version History. 32

7 Appendix B – Related Documents. 33

8 Appendix C – Reference Examples. 33

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. TimeCard 2.1 has been enhanced as described below:

· 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

o ApprovalInfo

o Person

o RateOrAmount

o Id

o 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’.

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

A full diagram of the schema is available at:

http://ns.hr-xml.org/2_3/HR-XML-2_3/TimeCard/TimeCard.jpg

A high level diagram can be found below.

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) 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)	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)	Contains information about a person. 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:restriction base: xsd:string [Enumerations]: Raw, Processed - - 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/)	A container with reported time and/or expense data for a person or resource in a given period.
/ TimeCard/ ReportedTime/ status	xsd:restriction base: xsd:string [Enumerations]: Raw, Processed	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.
/ 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/) 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. 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. [2] Contains information on whether the job/position is temporary or regular. [Synonym(s): PositionClassification ] [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, ] [Example(s): Regular (Position is ongoing without a scheduled termination date); Temporary (Position has a scheduled termination date or expiration date) ]
/ 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 - currency - 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	- currency -	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.
/ 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 Amount - xsd:double - S (0/1) Quantity - xsd:double - S (0/1)	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/ Amount	xsd:extension base: xsd:double currency - currency - required	The monetary value of the associated item. [Example(s): Bill rate, invoice item, compensation, allowance. ]
/ TimeCard/ ReportedTime/ TimeInterval/ Allowance/ Amount/ currency	- currency -	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/ 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)	Contains information about a person. 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/ 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/) 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 t ]
/ 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. 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 - currency - 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	- currency -	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)	Contains information about a person. 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/ 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/) 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. 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 - currency - required	The monetary value of the expense.
/ TimeCard/ ReportedTime/ Expense/ ExpenseAmount/ currency	- currency -	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)	Contains information about a person. 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/ Comment	- CommentType - S (0/*)	Allows for textual comments.
/ TimeCard/ ReportedTime/ Allowance	type - xsd:string - required 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/) 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/ actionCode	- ActionCodeType -	A code specifying the action to be performed on a particular record. [Example(s): Add, Change, Void. 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 - currency - required	The monetary value of the associated item. [Example(s): Bill rate, invoice item, compensation, allowance. ]
/ TimeCard/ ReportedTime/ Allowance/ Amount/ currency	- currency -	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)	Contains information about a person.
/ 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/ 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)	Contains information about a person.
/ 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/ SubmitterInfo	- SubmitterInfoType - S (0/1) Person - TimeCardPersonType - S (0/1) Source - xsd:string - S (0/1) SubmittedDateTime - AnyDateTimeType - S (1/1)	Container with information describing when and by whom the entire Timecard was submitted.
/ TimeCard/ SubmitterInfo/ Person	- TimeCardPersonType - S (0/1)	Contains information about a person.
/ 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)	Contains information about a person. 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	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.
/ [currency]	xsd:restriction base: xsd:string	Globally scoped data type. See element or attribute declaration for definition. Annotation: Conforms to ISO 4217:1995. The currency codes represented are made up of the two-character country code (ISO 3166-1) plus a one-character currency designator.
/ [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.
/ [EmptyString]	xsd:restriction base: xsd:string	Globally scoped data type. See element or attribute declaration for definition.
/ [emptyStringOrDouble]	- [Union]: xsd:double,EmptyString	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.
/ [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.

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.

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.

Future version

6 Appendix A - Document Version History

Version	Date	Description
2.0	2002-Mar-11	Move to v2. Remove batch, add extensions mechanism.
2.0	2002-Mar-19	Modified text to correctly describe the updated schema.
2.0	2002-Mar-20	Added reference examples.
2.0	2002-Mar-25	Added definitions table, final cleanup.
2.0	2002-Apr-1	Replaced example 6. Present for membership review.
2.0	2002-Apr-30	Approved Specification
2.0	30 Jan 2002	Target/default namespaces changed.
2.0	2003-Feb-26	Approved recommendation by HR-XML Consortium. The default and targetNamespaces of all HR-XML schemas have been standardized to "http://ns.hr-xml.org". This recommendation is available as part of the HR-XML 2_0 architecture.
2.1	2004-May-13	Updated document based on schema changes.
2.1	2004-May-19	Submit for CPO/TSC review.
2.1	2004-Jun-04	Added guidelines for action code.
2.1	2004-09-10	Changed duration to used global type.
2.1	2004-08-02	Approved by membership

7 Appendix B – Related Documents

Reference	Link
TimeCard schema	http://ns.hr-xml.org/2_3/HR-XML-2_3/TimeCard/TimeCard.xsd
Entity Identifier Type	http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/EntityIdentifiers.html http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/EntityIdType.xsd
PersonName	http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/PersonName.html http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/PersonName.xsd
PostalAddress	http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/PostalAddress.html http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/PostalAddress.xsd
DateTimeDataTypes	http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/DateTimeDataTypes.html http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/DateTimeDataTypes.xsd
SIDES schema	http://ns.hr-xml.org/2_3/HR-XML-2_3/SIDES/TimeCardAdditionalData.xsd
TSC Extension	http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/UserArea.xsd http://ns.hr-xml.org/2_3/HR-XML-2_3/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>gadget</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>

<Id>

</Id>

</ReportedPersonAssignment>

<Id>

</Id>

<Comment>Dinner with Consultants</Comment>

</Expense>

<Id>

</Id>

<Comment>Book: XML for Simpletons</Comment>

</Expense>

</ReportedTime>

<FormattedName>Amanda Hardaway</FormattedName>

</PersonName>

</Person>

</SubmitterInfo>

</ApprovalInfo>

</TimeCard>

Example 6:

This example shows the recording of the use of a resource (limo), and its associated cost ($250 per hour), against a particular project number (19004-A17W1).

<Id>

</Id>

<ResourceName>ABC1 Corporate Limo</ResourceName>

<AdditionalData type = "owner"> Office of the president</AdditionalData>

</Resource>

</ReportedResource>

<Id>

</Id>

<Id>

</Id>

<FormattedName>Maxwell Short</FormattedName>

</PersonName>

</Person>

<Comment>Confirmed that previous verbal approval of the limo's use was given by the CEO and should be charged against this project.</Comment>

</ApprovalInfo>

<Comment>Limo was used for this emergency with verbal approval of the CEO.</Comment>

</TimeInterval>

<Id>

</Id>

<FormattedName>Quinn Montgomery</FormattedName>

</PersonName>

</Person>

</ApprovalInfo>

</ReportedTime>

<Person>d

<Id>

</Id>

<FormattedName>Lucy Henderson</FormattedName>

</PersonName>

</Person>

<Source>QATimes</Source>

</SubmitterInfo>

</TimeCard>