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
Copyright © 2007 HR-XML Consortium, Inc.
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.3.2 Items Within the Design Scope
1.3.3 Items Outside of Design Scope
2 Supported Business Processes
2.1.1 Overview Activity Diagram
2.1.2 Actor: Time Capturing Device
2.1.3 Actor: Time & Attendance Application
2.1.4 Actor: Final Consumer Application
2.2 Process: Posting of Raw Time Data
2.2.3 Business Goal and Process
2.3 Process: Posting of Processed Time Data
2.3.3 Business Goal and Process
2.3.4 Example of a Processed Timecard. 15
4 Implementation Considerations
6 Appendix A - Document Version History
7 Appendix B – Related Documents
8 Appendix C – Reference Examples
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 3rd 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 |
|
|
||||