TL;DR + Update(2018.02.26)
If you want Intel + Nouveau on daily use and need Nvidia Optimus sometimes, or vice versa, check out my Github repo.
Negativo17 Drivers Installation Shortcut
dnf config-manager --add-repo=https://negativo17.org/repos/fedora-nvidia.repo
sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686
sudo dnf install cuda-devel
Battery Life Matters
Since the release of Fedora 26, Mesa doesn't conflict with Nvidia anymore. Generally, the Nvidia driver can be installed from either Bumblebee or Negativo17's repo. Both methods are easy to install, but the former one is likely to have more problems.
A brief comparison table:
| Bumblebee | Negativo17 | |
|---|---|---|
| Nvidia Driver Version | Old | Up to date |
| Usage | Turn on when needed | Always on with Nvidia Optimus |
| Status | No updates since 2013 | Still being maintained and has good support |
| Platform | Wayland & X | Only on X |
I'd like to have more battery life with my laptop. Thus, Bumblebee seems to be a good choice at first glance. However, there are various issues with it. Some are listed here, and lots of them are listed here. A major reason is that the Bumblebee project has been lack of support for a looooong time. Also Bumblebee is not compatible with TLP(I have tried the recommended fix, but it was in vain.). At last, I gave up on Bumblebee.
Solution
How can I disable the Nvidia card without Bumblebee? The only way is to prevent the Nvidia modules from loading at boot time. After trying for days, I came up with the following solution:
- Create a new Nvidia-enabled entry at the bottom of the Grub menu:
- Add a new entry to
/etc/grub.d/40_custom
. Just simply copy the newest entry from/boot/efi/EFI/fedora/grub.cfg
.
- Add a new entry to
- Disable Nvidia modules on all boot entries except customized ones:
- Add
modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm
toGRUB_CMDLINE
in/etc/default/grub
.
- Add
- Regenerate Grub Menu:
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
This script does the work above. To run it, you have to disable Secure Boot.
I've made sure the method above is effective with tlp-stat
. On my laptop, if the Nvidia card is on, the electric current will not be lower than 1300mA; Otherwise, it can be as low as 750mA.
As of now, my Nvidia card is usually off. And it can be turned on either using Nouveau or booting from the last entry in Grub.


| 030:040 Khan | : |
Allah is He Who created you, then provided food for you, then will cause you to die, then (again) He will give you life (on the Day of Resurrection). Is there any of your (so-called) partners (of Allah) that do anything of that? Glory be to Him!  Is there any of your associate-gods who does aught of it? Glory be to Him, and exalted be He above what they associate (with Him)! |
| 030:040 Pickthal | : |
Allah is He Who created you and then sustained you, then causeth you to die, then giveth life to you again. Is there any of your (so-called) partners (of Allah) that doeth aught of that? Praised and Exalted be He above what they associate (with Him)! |
| 030:040 Rashad | : |
GOD is the One who created you. He is the One who provides for you. He is the One who puts you to death. He is the One who resurrects you. Can any of your idols do any of these things? Be He glorified. He is much too exalted to have any partners. |
| 030:040 Sarwar | : |
It is God who has created you and given you sustenance.  Can any of your idols do such things? God is too Exalted to be considered equal to anything else. |
| 030:040 Shakir | : |
Allah is He Who created you, then gave you sustenance, then He causes you to die, then brings you to life. Is there any of your associate-gods who does aught of it?  Is there any of your so-called associate-gods, who can do any of these things? Glorified be HE and exalted far above that which they associate with HIM. |
| 030:040 Yusufali | : |
It is Allah Who has created you: further, He has provided for your sustenance; then He will cause you to die; and again He will give you life. Are there any of your (false) "Partners" who can do any single one of these things? Glory to Him! and high is He above the partners they attribute (to him)! |
Concepts/Themes Covered: أركان الإسلام > التوحيد > توحيد الله تعالي > حمد الله تعالى وتسبيحه والثناء عليه Pillars of Islam> Islamic> Oneness of Allah> Praise be to Him أركان الإسلام > التوحيد > توحيد الله تعالي > وحدانيته Pillars of Islam> Islamic> Oneness of Allah> Singularity and Being Unique أركان الإسلام > التوحيد > توحيد الله تعالي > يحيي ويميت Pillars of Islam> Islamic> Oneness of Allah> Gives Life and Death أركان الإسلام > التوحيد > الشرك والمشركون > تنزيه الله جلّ جلاله عن الشريك Pillars of Islam> Islamic> Polytheism and the Polytheists> Allah's Freedom from Partnership
This tool uses eight English parallel translations for the Holy Quran imported from Mr. Clay Smith. You can also visit Qurany Concepts for browsing the Quran themes or topics. If you want to search the Holy Quran for keywords, please visit Qurany Keywords.


Hi, my name is Enrique and I'm also known as Gorwast on the Internet, I'm a student of computer systems, I'm interested in technology and the development of them in general, I have my own personal projects in github to have a record of my knowledge and use them in a larger project in the future, feel free to take a look at what I've done


String
constructors and calls to methods like toString()
or substring()
when they can be replaced with a simplified expression.
For example, calls to these methods can be safely removed in cases
like "string".substring(0)
, "string".toString()
, or
new StringBuilder().toString().substring(1,3)
.
Example:
System.out.println(new String("message"));
After the quick-fix is applied:
System.out.println("message");
Note that the quick-fix removes the redundant constructor, and this may affect String
referential equality.
If you need to preserve it even though it is considered bad practice, suppress the warning or configure the settings to ignore
redundant String
constructors.
New in 2018.1


fishing threads lines strength luminosa Arachnocampa tensile thread Zophobas bar metal silk adhesive prey different energy New adhesion capture properties Zealand dry larva values {border-style humidity web . ± . line mechanical px;} #ffffff;} (Fig. higher spider using droplets (). Biology block high orb single spiders low tasmaniensis Experimental [], collected mold Opell conditions contact glue measured peeling used \documentclass[pt]{minimal} \setlength{\oddsidemargin}{-pt} \usepackage{amsbsy} \usepackage{amsfonts} \usepackage{amsmath} \usepackage{amssymb} \usepackage{mathrsfs} \usepackage{upgreek} \usepackage{wasysym} attached differences force length measurements probe resin strain water wet µN/mm) Figure data dried glowworm lower probes transducer ./jeb. bonding droplet extensibility motor small taken tests (≅. air frame highly light px; species {font-family (), (\phi Biological PVS University Waitomo adhesives font-size long orb-weaving relative use (Diptera: . MPa Measurements Nature Science Society \begin{document}$${\rm{\Delta caves central double; egg humid mass pulled study substrate surface mm (. GPa) (. N/m) (Table .–. Adhesion Adhesive Anatopynia Australian Gosline Peeling RH) Royal Tensile ability border-color border-width elastic epoxy exhibit fibroin glycoprotein grid.. heavy indicate larval linear material measurement. measurements. native pin polar present rachnocampa showed shown similar situ slightly solid; upper viscid viscous weight wrapped {font-style {font-weight (.) (P < .) (maximum (see (≅– . N/m Bombyx Byern Cave Commons Creative Department Hendricks However, Institute Merritt Physiology RH = % Table abdomen acquisition analyses angle attachment biological biomechanical block, bold breaking catch cave cave. changes composition conditions. consequence core cos courier; damage drying em; force = . handling however, http://orcid.org/--- images insects known laboratory lacewing larger larvae layer lines, mori nest nests ones paper provide pt;} relatively shows significant software stickiness stored structure studies surfaces taking test tested threads, times tourist u-shaped von webs N/m


Angiography.cdv_nb¶
-
oct.Angiography.
cdv_nb
(self)¶ Compute angiography frames using the CDV algorithm with noise-bias correction .. note:
This is an upgrade to the previous CDV algorithm that improves performance using a noise-bias correction. Reference: Braaf, B., Donner, S., Nam, A. S., Bouma, B. E., & Vakoc, B. J. (2018). Complex differential variance angiography with noise-bias correction for optical coherence tomography of the retina. Biomedical Optics Express, 9(2), 486. https://doi.org/10.1364/boe.9.000486
Args:
- Output:
self.processedData[‘angio’] (np.array): Reconstructed angiography frame self.processedData[‘weight’] (np.array): Reconstructed weight frame


|
Nakama .NET Client SDK 3.8.0
Nakama .NET Client SDK
|
An export of all information stored for a user account. More...
Inherited by Nakama.Console.ConsoleAccountExport.
Properties | |
| INakamaapiAccount | Account [get] |
| The user's account details. | |
| IEnumerable< IApiFriend > | Friends [get] |
| The user's friends. | |
| IEnumerable< IApiGroup > | Groups [get] |
| The user's groups. | |
| IEnumerable< IApiLeaderboardRecord > | LeaderboardRecords [get] |
| The user's leaderboard records. | |
| IEnumerable< IApiChannelMessage > | Messages [get] |
| The user's chat messages. | |
| IEnumerable< IApiNotification > | Notifications [get] |
| The user's notifications. | |
| IEnumerable< IApiStorageObject > | Objects [get] |
| The user's storage. | |
| IEnumerable< IConsoleWalletLedger > | WalletLedgers [get] |
| The user's wallet ledger items. | |
An export of all information stored for a user account.
|
get |
The user's account details.
|
get |
The user's friends.
|
get |
The user's groups.
|
get |
The user's leaderboard records.
|
get |
The user's chat messages.
|
get |
The user's notifications.
|
get |
The user's storage.
|
get |
The user's wallet ledger items.


Prompt functions in a way similar to a Terminal, Bash shell, Windows CMD shell, or Powershell. You enter a command and hit ENTER
and the computer responds with a result. For very simple commands like help
or list-modules
, that's all you need. Some commands, though, may require additional data or they may allow you to provide additional options.
Specifying a target or context for a command: For commands that operate on an object like a user, or that require a context like a page, you simply provide that information after the command. For example, to find the user jsmith using the get-user
command, you would type: get-user jsmith
followed by the ENTER
key to submit it. If you will be specifying flags (see next paragraph), those should always come after the target/context of the command.
Specifying Options to Commands: Some commands require even more data or allow you to specify optional configuration information. In Prompt we call these "flags". These should come after any target/context needed by the command (see above paragraph) and must be preceded with two hyphens or dashes (--
). There should be no spaces between the dashes and there should be no space between the dashes and the name of the flag. If then flag requires a value, you add that after the flag.
As an example of using flags, take the get-user
command. By default, you would specify the username of the user you want to find. However, you can also search by their email address. In that case, you would use the --email
flag. Here's how you would use it:
get-user --email<EMAIL_ADDRESS>If the value of a flag is more than one word, enclose it in double quotes like so:
set-page --title "My Page"


UNFLATTEN(1) UNFLATTEN(1) NAME unflatten - adjust directed graphs to improve layout aspect ratio SYNOPSIS unflatten [-f] [-llen] [-clen ] [ -o outfile ] [ files ] DESCRIPTION unflatten is a preprocessor to dot that is used to improve the aspect ratio of graphs having many leaves or disconnected nodes. The usual lay‐ out for such a graph is generally very wide or tall. unflatten inserts invisible edges or adjusts the minlen on edges to improve layout com‐ paction. OPTIONS The following options are supported: -l len The minimum length of leaf edges is staggered between 1 and len (a small integer). -f Enables the staggering of the -l option to fanout nodes whose indegree and outdegree are both 1. This helps with structures such as a -> {w x y z} -> b. This option only works if the -l flag is set. -c len Form disconnected nodes into chains of up to len nodes. -o outfile causes the output to be written to the specified file; by default, output is written to stdout. OPERANDS The following operand is supported: files Names of files containing 1 or more graphs in dot format. If no files operand is specified, the standard input will be used. AUTHORS Stephen C. North<EMAIL_ADDRESS>Emden R. Gansner<EMAIL_ADDRESS>SEE ALSO gc(1), dot(1), acyclic(1), gvpr(1), gvcolor(1), ccomps(1), tred(1), lib‐ graph(3) 21 January 2001 UNFLATTEN(1)


#include <CNSCache.h>
Public Member Functions | |
| CNSCache () | |
| ~CNSCache () | |
| void | MountCache (TpObjCntin *father, unsigned long NRegs, unsigned char FRot, unsigned int NPgs, unsigned long TamBuff) |
| void | ReadPage (unsigned long, void **) |
| void | WritePage () |
| void | NewPage (unsigned long, void **) |
| void | FlushCache () |
Definition at line 108 of file CNSCache.h.
Definition at line 211 of file CNSCache.h.
Definition at line 219 of file CNSCache.h.
| void CNSCache< TpObjCntin >::FlushCache | ( | ) |
Definition at line 371 of file CNSCache.h.
References CNSCACHE_NIL.
Referenced by CStorage::FlushCache().
| void CNSCache< TpObjCntin >::MountCache | ( | TpObjCntin * | father, |
| unsigned long | NRegs, | ||
| unsigned char | FRot, | ||
| unsigned int | NPgs, | ||
| unsigned long | TamBuff | ||
| ) |
Definition at line 228 of file CNSCache.h.
References CNSCACHE_NIL, and TxCrescBlocos.
| void CNSCache< TpObjCntin >::NewPage | ( | unsigned long | reg, |
| void ** | page | ||
| ) |
Definition at line 353 of file CNSCache.h.
References CNSCACHE_NIL, and TxCrescBlocos.
| void CNSCache< TpObjCntin >::ReadPage | ( | unsigned long | reg, |
| void ** | page | ||
| ) |
Definition at line 296 of file CNSCache.h.
References CNSCACHE_NIL.
|
inline |
Definition at line 116 of file CNSCache.h.


{% extends 'base.html' %} {% block content %} {{block.super}}
Located at: {{hospital.location}}
{{hospital.email}}
{{hospital.phone}}


---
external: true
format: html
date: 2014-12-15 17:01:47 Z
title: Animated Page Transitions with React.js
link: http://coenraets.org/blog/2014/12/animated-page-transitions-with-react-js/
author: Christophe Coenraets
permalink: /admin/blog/2014-12-15-animated-page-transitions-with-react-js
type: post
status: publish
tags:
- PhoneGap Network
---
After exploring React in my previous post, I started experimenting with ways to implement animated page transitions in mobile web and Cordova-based apps. ReactCSSTransitionGroup provides the basic infrastructure for CSS-based animations. But after a few promising experiments, I ran into this problem. I also wasn’t sure this approach would give me enough control to implement […]


This project is aimed at collecting and standardizing various High Frequency Reporting (HFR) data, i.e. monthly collection/submission of weekly data, from USAID PEPFAR operating units and partners. A standardized output will make it easier to conduct analysis at the HQ level across all the operating units USAID supports. As of period 2020.01, all submissions are required to be sent in either one of two templates in order to standardize the process. The guidance as well as futher documentation and data can be found on Google Drive.
Available features and changes are noted in NEWS.md
The HFR process works on a four week cycle, called a period, detailed in the HFR calendar. At the end of each period, USAID implementing partners submit data via submission templates on key indicators data disaggrated by week to the in country USAID team who in turn send it to Washington.
A team in USAID Washington on the OHA/SIEI division, process and validate the submission to ensure they follow the guidance and have no major errors. This processing occurs in R via this Wavelength package. The processed file is imported into a relational database that contains pertinent PEPFAR information, including PEPFAR MER results and targets from the latest quarter of the current year are added to the global HFR dataset
A Tableau workbook located on USAID’s Tableau server is linked to SQL View extract from the database. The standard visuals provide a detailed look at trends over time and how weekly results compare the remaining weekly average targets needed to achieve the fiscal year targets.
You can create a flat file by installing this package, Wavelength
and running hfr_process_template()
. If you need to combine multiple country/partner files, you will need to utitlize the map_dfr()
function from the purrr
package.
Below is an example code to use to create a flat file for a country submission. You will need the country/partner data files and to specify the output folder path where you want the file to be saved.
## SETUP
#install
install.packages("devtools")
devtools::install_github("USAID-OHA-SI/Wavelength")
#load the package
library(Wavelength)
## EXAMPLE WITH ONE FILE
#file path for the
path <- "~/WeeklyData/Saturn"
output_folder <- "~/WeeklyData/Output"
#process Excel file for Saturn
hfr_process_template(path, output_folder)
#process Excel file for Saturn with full validation
datim_folder <- "~/Datim"
hfr_process_template(path, output_folder, datim_path = datim_folder)
## EXAMPLE WITH MULTIPLE FILES
#install purrr if you don't already have it
install.packages("purrr")
#file path for the
files <- list.file("~/WeeklyData", full.names = TRUE)
output_folder <- "~/WeeklyData/Output"
#process Excel file for all submitted file in WeeklyData
purrr::map_dfr(.x = files,
.f = ~ hfr_process_template(.x, output_folder)
#process Excel file for all submitted file in WeeklyData with full validation
datim_folder <- "~/Datim"
purrr::map_dfr(.x = files,
.f = ~ hfr_process_template(.x, output_folder, datim_path = datim_folder)
If you have an HFR dataset stored locally and want to read it into R, you can use the hfr_read()
function. This function utiltizes vroom
for quicker import times and makes adjustments for the various column types without R having to guess.
## EXAMPLE READING IN A PROCESSED HFR FILE
#HFR file path
path <- "~/WeeklyData/Output/HFR_2020.01_Mars_20201123.csv"
#process Excel file for Saturn
df_hfr_mars <- hfr_read(path)
The official PEPFAR MER data are stored in a DHIS2 system called DATIM. Indicators are collected on a quarterly basis and are compared to targets for each fiscal year. We use the MER data to create gap targets (ie how much of the fiscal year target needs to be completed with the cumulative quarterly results so far) as well as to identify offical partner names as well as the offical organizational hierarchy.
DATIM allows for API call so as to access site level results and targets. The pull_mer()
script allows users with DATIM account to extract this data, which is also stored on the HFR Google Drive. In addition to pull_mer()
two other API call extract org unit information from DATIM (pull_hierarchy()
) and mechanism and partner information (pull_mech()
).
To run pull_mer()
you will need to install additional packages (keyringr
, curl
, httr
, and jsonlite
). Since DATIM needs your credentials, you will need to securely store them on your machine, following the documentation laided out in the keyringr
package vignette.
#ACCESSING AND STORING DATIM DATA
#identify the operating units you want to pull targets for
ou_list <- c("Saturn", "Mars")
#provide your credentials
myuser <- ""
#API MER Pull
purrr::walk(.x = ou_list,
.f = ~ pull_mer(
ou_name = .x,
username = myuser,
password = mypwd(myuser), # or if not stored, just your password in quotes
quarters_complete = 3, #current quarter of data availability
folderpath_output = "out/DATIM" #path on your machine
)
)
#pull hierarchy
ouuids <- identify_ouuids(myuser, mypwd(myuser)) %>% dplyr::pull(id)
df_orgs <- purrr::map_dfr(.x = ouuids,
.f = ~ pull_hierarchy(.x, myuser, mypwd(myuser)))
#pull mechanism info
df_mech_info <- pull_mech()
The global HFR dataset that feeds into the Tableau workbook on the server pulls from all the processed country HFR (all historic data to date) and the locally stored DATIM data. This process is now conducted in the database, but previously it was run locally. The hfr_append_sources()
function brings together these data sources for the Tableau workbook. You will need to have the HFR data stored in one folder and DATIM data stored in another. If you have countries with historic data but not for the current period, you should include those files in the HFR folder so they can be included in the global dataset.
#APPEND DATA
#create an appended data source
df_combo <- hfr_append_sources(folderpath_hfr = "out/processed",
folderpath_datim = "out/DATIM",
start_date = "2019-06-03",
weeks = 4, #update with current HFR dates
max_date = TRUE)
Validation checks are run when processing the submitted data, ensuring that everything is there and uniformly processed. Some of the checks include: - all variables are lower case and match the codebook - ensuring dates all match the HFR reporting calendar - indicators are only HFR indicators and spelling match - disaggregate components (agecoarse
, sex
, and otherdisaggregate
) are only what is noted in the codebook These validations are built into the hfr_process_template()
at various points via the validation_*()
scripts and appear inline when processing.
#VALIDATE DATA
#submission file path
path <- "~/WeeklyData/Saturn"
#validations appear in the console
hfr_process_template(path)
#alternative, validate, adjusting the submission date automatically
hfr_process_template(path, round_hfrdate = TRUE)
Extra validation checks can be run after processing the submitted data, and correction / update made right before data ingestion : - all operating units are valid - all orgunit uids are valid and matched with their respective operating unit - all mechanism codes are valid and matched with their respective operating unit - age coarse and sex are valid options - val is either NA or a positive integer These extra validations functions are in hfr_qda_utilities
and hfr_dqa_checks
files.
Set hfr data folder and load look up data
# HFR Data
dir_data <- "..."
# HFR Period dates
valid_dates <- Wavelength::hfr_identify_pds(fy=2020)
# ORG Levels
org_levels <- read_csv(file = "file_orglevels")
# ORGs
orgs <- read_csv(file = "file_orgs")
# Mechanisms
ims <- read_csv(file = "file_mechanisms")
Validate and report errors for HFR forenames: this will list out all errors related to ISO3 codes and Mechanism Code
# Validate processed files
hfr_processed_files <- validate_submissions(levels = org_levels,
ims = ims,
pfolder = dir_hfr_pd208,
pattern = "HFR_2020.08")
# Report Errors from processed files
report_submissions_errors(hfr_processed_files,
mechanisms = ims,
export = F)
Validate processed file content (focus on operating units)
# Read data from all files
hfr_data <- hfr_read_all(dir_data,
pattern = 'HFR_2020.xx',
source = T)
# Check for invalid operating units
hfr_data %>%
is_ou_valid(df_orgs = orgs) %>%
filter(valid_ou == FALSE) %>%
distinct(source, operatingunit, valid_ou) %>%
arrange(source)
Fix operating units with errors (using mech code and/or country iso3 code)
# Use mechanism code to update operating units
hfr_data <- hfr_data %>%
update_operatingunits(levels=org_levels, orgs=orgs, ims=ims)
# Check if there are still any invalid operating units (for invalid mech_code)
hfr_data %>%
is_ou_valid(df_orgs = orgs) %>%
filter(valid_ou == FALSE) %>%
View()
# Use iso3 code (second attempt)
hfr_data <- hfr_data %>%
update_operatingunits(levels=org_levels, orgs=orgs)
# Check again for invalid operating units
hfr_data %>%
is_ou_valid(df_orgs = orgs) %>%
filter(valid_ou == FALSE) %>%
View()
Run a full validation on the data (with all the operating units errors fixed)
# validate hfr data from processed files and return errors
errors <- validate_hfr_data(hfr_data, org_levels, orgs, ims, valid_dates)
# Explore the errors
errors %>% glimpse()
Confirm all the validations by marking valid processed files as validated files
# update the name of files
confirm_validations(hfr_data = hfr_data,
hfr_errors = errors,
dir_files = dir_data)
Note: data ingesting can now proceed with only validated files while the rest is being fixed / updated.
Disclaimer: The findings, interpretation, and conclusions expressed herein are those of the authors and do not necessarily reflect the views of United States Agency for International Development. All errors remain our own.


{% extends 'base.html' %} {% load static %} {% block content %} Blogs Home Create Blog posts and let everyone knowsyour intresting story or Read some ofthe story of other's life .
{{post.content}}


Registration of E-voting
Please enter the following information. Fields marked with an asterisk (
*
) are required.
Personal Information
*
First Name:
*
Last Name:
*
Age:
*
Gender:
Male
Female
Others
*
Phone number:
*
Address:
*
State:
*
City:
*
Pincode:
*
ID proof:
Select ID proof
Aadhaar Card
PAN card
Passport
Driving Licences
Voter Id card
*
ID Number:
*
Email address:
*
Create Password:
*
Confirm Password:
Submission
Check all the
Terms and Conditions
BACK


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
· 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 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.
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.
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.
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.
(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.
There are three major reporting types that are covered by the design:
1) Timestamped Event –Used to mark the occurrence of a particular event.
2) Time Intervals – Activity expressed as an amount and unit of time as taking place on a particular date(s).
· 2001-09-21Z-03, (end date)
· P4H, (ISO standard data structure conveying 4 hours) (quantity)
· Assignment=A, (assignment identifier)
· Activity=Coding, (activity identifier)
· 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.
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)
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.
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.
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
Thus this actor creates, updates and reads time card data.
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:
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).
The typical users who trigger the business process are
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:
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.
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 |
|
|
|
… |
|
|
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).
The typical users who trigger the business process are:
Business goal: Depending on the variations of their role (Administrator versus Manager) the users would:
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.
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 |
|
|
|
|
|
|
|
… |
… |
|
|
|
|
|
|
|
|
|
|
|
Elements and Attributes [Global types listed alphabetically in following table.] |
ContentModel* |
Definition |
|
/ |
- TimeCardType - (1/1) |
A record describing the time and/or expense data of a person or resource for a given period. |
|
/ TimeCard/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ |
Person - TimeCardPersonType
- C (1/1) |
Container describing the person or resource for which time and/or expense is being reported. |
|
/ TimeCard/ ReportedResource/ |
- TimeCardPersonType - C (1/1) |
Context definition: Container for the person who performed the work. |
|
/ TimeCard/ ReportedResource/
Person/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ReportedResource/ |
type - xsd:string
- |
The resource (non human) for
which the time and/or expense is being reported. |
|
/ TimeCard/ ReportedResource/
Resource/ |
- xsd:string - |
Further defines the associated element in the context provided. |
|
/ TimeCard/ ReportedResource/
Resource/ |
- EntityIdType - S (0/*) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ReportedResource/
Resource/ |
- xsd:string - S (0/1) |
The name of a resource (non
human), for which times and expenses may be reported. |
|
/ TimeCard/ ReportedResource/
Resource/ |
- AdditionalDataType - S (0/*) |
Allows trading partner specific structured information or extensions. |
|
/ TimeCard/ |
status - xsd:string
- |
A container with reported time and/or expense data for a person or resource in a given period. |
|
/ TimeCard/ ReportedTime/ |
- 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/ |
- AnyDateTimeType - S (1/1) |
The starting date of the reported
time. |
|
/ TimeCard/ ReportedTime/ |
- AnyDateTimeType - S (1/1) |
The ending date of the reported
time. |
|
/ TimeCard/ ReportedTime/ |
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/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ReportedTime/ |
type - xsd:string
- required |
A container used to report the duration and type of a work for a specified time period. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- xsd:string - |
Further defines the associated element in the context provided. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- DayAssignmentType - |
Allows assignment of work
performed on a "physical" time interval or day to another
"logical" day. Mostly for evaluation purposes. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- xsd:boolean - |
Attribute used to indicate whether the time interval, time event, or expense is billable to a customer. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- ActionCodeType - |
A code specifying the action to
be performed on a particular record. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- AnyDateTimeType - S (1/1) |
Defines the start date, and if
applicable, start time of the interval, period, or event being reported. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- AnyDateTimeType - S (1/1) |
Defines the end date, and if
applicable, end time of the interval, period, or event being reported. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- TimeCardDuration - S (0/1) |
Specifies the duration of the
reported work. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- TimeCardDuration - C (1/1) |
Specifies the duration of the
reported work. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
Piece - [complexType]
- S (1/1) |
Container for the id, description and/or quantity of the work piece. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ PieceWork/ |
Id - EntityIdType
- S (0/1) |
Container for the id and description of the work piece. |
|
/ TimeCard/ ReportedTime/ TimeInterval/
PieceWork/ Piece/ |
- 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/ |
- xsd:string - S (1/1) |
Describes the type of work piece.
|
|
/ TimeCard/ ReportedTime/
TimeInterval/ PieceWork/ |
xsd:extension base: xsd:double |
A numerical quantity that is assigned
or determined by calculation or measurement. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ PieceWork/ Quantity/ |
- xsd:string - |
Unit in which the quantity is
measured. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
xsd:extension base: xsd:double |
Container for a rate or a flat amount to be applied to the reported work. |
|
/ TimeCard/ ReportedTime/ TimeInterval/
RateOrAmount/ |
- CurrencyCodeType - |
A three-letter code identifying
the currency of a monetary amount. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ RateOrAmount/ |
- xsd:string - |
Further defines the associated element in the context provided. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ RateOrAmount/ |
- xsd:string - |
Period used to further define the
rate. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ RateOrAmount/ |
- xsd:double - |
A multiplier to be applied to the
related amount, rate, or variable. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ RateOrAmount/ |
- xsd:boolean - |
Indicates if this RateOrAmount is to be billed to the supplier of the resource. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ RateOrAmount/ |
- xsd:boolean - |
Indicates if this RateOrAmount is to be paid to the resource that this timecard refers to. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
type - xsd:string
- required |
Contains groups of allowances for the time period or interval. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- xsd:string - |
Further defines the associated element in the context provided. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- xsd:boolean - |
Attribute used to indicate whether the time interval, time event, or expense is billable to a customer. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- ActionCodeType - |
A code specifying the action to
be performed on a particular record. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- 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/ |
- AnyDateTimeType - S (0/1) |
Contains the (inclusive) date,
period, or interval the event becomes active or begins. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- AnyDateTimeType - S (0/1) |
Contains the (inclusive) date,
period, or interval the event becomes inactive or ends. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
xsd:extension base: xsd:double |
The monetary value of the
associated item. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ Amount/ |
- CurrencyCodeType - |
A three-letter code identifying
the currency of a monetary amount. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- xsd:double - S (0/1) |
A numerical quantity that is
assigned or determined by calculation or measurement. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- AdditionalDataType - S (0/*) |
Allows trading partner specific structured information or extensions. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- ApprovalInfoType - S (0/*) |
Container which holds information about when and by whom the entire Timecard was approved. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ ApprovalInfo/ |
- TimeCardPersonType - S (1/1) |
Context definition: Container for the person who approved the reported time interval allowance data. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ ApprovalInfo/ Person/ |
- 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/ |
- AnyDateTimeType - S (1/1) |
The timestamp when the time card was approved. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ ApprovalInfo/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- SubmitterInfoType - S (0/1) |
Container with information describing when and by whom the entire Timecard was submitted. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ SubmitterInfo/ |
- TimeCardPersonType - S (0/1) |
Context definition: Container for the person who submitted the reported time interval allowance data. |
|
/ TimeCard/ ReportedTime/ TimeInterval/
Allowance/ SubmitterInfo/ Person/ |
- 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/ |
- xsd:string - S (0/1) |
The system that submitted the
timecard. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ SubmitterInfo/ |
- AnyDateTimeType - S (1/1) |
The timestamp as to when the timecard was submitted. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ Allowance/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- AdditionalDataType - S (0/*) |
Allows trading partner specific structured information or extensions. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- ApprovalInfoType - S (0/*) |
Container which holds information about when and by whom the entire Timecard was approved. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ ApprovalInfo/ |
- TimeCardPersonType - S (1/1) |
Context definition: Container for the person who approved the reported time interval data. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ ApprovalInfo/ Person/ |
- 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/ |
- AnyDateTimeType - S (1/1) |
The timestamp when the time card was approved. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ ApprovalInfo/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/ TimeInterval/ |
- SubmitterInfoType - S (0/1) |
Container with information describing when and by whom the entire Timecard was submitted. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ SubmitterInfo/ |
- TimeCardPersonType - S (0/1) |
Context definition: Container for the person who submitted the reported time interval data. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ SubmitterInfo/ Person/ |
- 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/ |
- xsd:string - S (0/1) |
The system that submitted the
timecard. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ SubmitterInfo/ |
- AnyDateTimeType - S (1/1) |
The timestamp as to when the timecard was submitted. |
|
/ TimeCard/ ReportedTime/
TimeInterval/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/ |
type - xsd:string
- required |
A container for a work time event that occurred at a specific point in time. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- xsd:string - |
Further defines the associated element in the context provided. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- DayAssignmentType - |
Allows assignment of work
performed on a "physical" time interval or day to another
"logical" day. Mostly for evaluation purposes. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- xsd:boolean - |
Attribute used to indicate whether the time interval, time event, or expense is billable to a customer. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- ActionCodeType - |
A code specifying the action to
be performed on a particular record. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- AnyDateTimeType - S (1/1) |
The timestamp for when the event occurred. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
xsd:extension base: xsd:double |
Container for a rate or a flat amount to be applied to the reported work. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ RateOrAmount/ |
- CurrencyCodeType - |
A three-letter code identifying
the currency of a monetary amount. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ RateOrAmount/ |
- xsd:string - |
Further defines the associated element in the context provided. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ RateOrAmount/ |
- xsd:string - |
Period used to further define the
rate. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- AdditionalDataType - S (0/*) |
Allows trading partner specific structured information or extensions. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- ApprovalInfoType - S (0/*) |
Container which holds information about when and by whom the entire Timecard was approved. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ ApprovalInfo/ |
- TimeCardPersonType - S (1/1) |
Context definition: Container for the person who approved the reported time event data. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ ApprovalInfo/ Person/ |
- 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/ |
- AnyDateTimeType - S (1/1) |
The timestamp when the time card was approved. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ ApprovalInfo/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- SubmitterInfoType - S (0/1) |
Container with information describing when and by whom the entire Timecard was submitted. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ SubmitterInfo/ |
- TimeCardPersonType - S (0/1) |
Context definition: Container for the person who submitted the reported time event data. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ SubmitterInfo/ Person/ |
- 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/ |
- xsd:string - S (0/1) |
The system that submitted the
timecard. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ SubmitterInfo/ |
- AnyDateTimeType - S (1/1) |
The timestamp as to when the timecard was submitted. |
|
/ TimeCard/ ReportedTime/
TimeEvent/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/ |
type - xsd:string
- required |
Container for individual expenses incurred. |
|
/ TimeCard/ ReportedTime/
Expense/ |
- xsd:string - |
Further defines the associated element in the context provided. |
|
/ TimeCard/ ReportedTime/
Expense/ |
- xsd:boolean - |
Attribute used to indicate whether the time interval, time event, or expense is billable to a customer. |
|
/ TimeCard/ ReportedTime/
Expense/ |
- ActionCodeType - |
A code specifying the action to
be performed on a particular record. |
|
/ TimeCard/ ReportedTime/
Expense/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ReportedTime/
Expense/ |
- AnyDateTimeType - S (1/1) |
The date that the expense was incurred. |
|
/ TimeCard/ ReportedTime/
Expense/ |
xsd:extension base: xsd:double |
The monetary value of the expense. |
|
/ TimeCard/ ReportedTime/
Expense/ ExpenseAmount/ |
- CurrencyCodeType - |
A three-letter code identifying
the currency of a monetary amount. |
|
/ TimeCard/ ReportedTime/
Expense/ |
- AdditionalDataType - S (0/*) |
Allows trading partner specific structured information or extensions. |
|
/ TimeCard/ ReportedTime/
Expense/ |
- ApprovalInfoType - S (0/*) |
Container which holds information about when and by whom the entire Timecard was approved. |
|
/ TimeCard/ ReportedTime/
Expense/ ApprovalInfo/ |
- TimeCardPersonType - S (1/1) |
Context definition: Container for the person who approved the reported expense data. |
|
/ TimeCard/ ReportedTime/
Expense/ ApprovalInfo/ Person/ |
- 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/ |
- AnyDateTimeType - S (1/1) |
The timestamp when the time card was approved. |
|
/ TimeCard/ ReportedTime/ Expense/
ApprovalInfo/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/
Expense/ |
- SubmitterInfoType - S (0/1) |
Container with information describing when and by whom the entire Timecard was submitted. |
|
/ TimeCard/ ReportedTime/
Expense/ SubmitterInfo/ |
- TimeCardPersonType - S (0/1) |
Context definition: Container for the person who submitted the reported expense data. |
|
/ TimeCard/ ReportedTime/
Expense/ SubmitterInfo/ Person/ |
- 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/ |
- xsd:string - S (0/1) |
The system that submitted the
timecard. |
|
/ TimeCard/ ReportedTime/
Expense/ SubmitterInfo/ |
- AnyDateTimeType - S (1/1) |
The timestamp as to when the timecard was submitted. |
|
/ TimeCard/ ReportedTime/
Expense/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/ |
type - xsd:string
- required |
Contains groups of allowances for the time period or interval. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- xsd:string - |
Further defines the associated element in the context provided. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- xsd:boolean - |
Attribute used to indicate whether the time interval, time event, or expense is billable to a customer. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- ActionCodeType - |
A code specifying the action to
be performed on a particular record. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- AnyDateTimeType - S (1/1) |
Contains the (inclusive) date,
period, or interval the event becomes active or begins. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- AnyDateTimeType - S (0/1) |
Contains the (inclusive) date,
period, or interval the event becomes inactive or ends. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
xsd:extension base: xsd:double |
The monetary value of the associated item. [ [Example(s): Bill rate, invoice item, compensation, allowance. ] |
|
/ TimeCard/ ReportedTime/
Allowance/ Amount/ |
- CurrencyCodeType - |
A three-letter code identifying
the currency of a monetary amount. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- xsd:double - S (0/1) |
A numerical quantity that is assigned
or determined by calculation or measurement. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- AdditionalDataType - S (0/*) |
Allows trading partner specific structured information or extensions. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- ApprovalInfoType - S (0/*) |
Container which holds information about when and by whom the entire Timecard was approved. |
|
/ TimeCard/ ReportedTime/
Allowance/ ApprovalInfo/ |
- TimeCardPersonType - S (1/1) |
Context definition: Container for the person who approved the reported allowance data. |
|
/ TimeCard/ ReportedTime/
Allowance/ ApprovalInfo/ Person/ |
- 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/ |
- AnyDateTimeType - S (1/1) |
The timestamp when the time card was approved. |
|
/ TimeCard/ ReportedTime/
Allowance/ ApprovalInfo/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- SubmitterInfoType - S (0/1) |
Container with information describing when and by whom the entire Timecard was submitted. |
|
/ TimeCard/ ReportedTime/
Allowance/ SubmitterInfo/ |
- TimeCardPersonType - S (0/1) |
Context definition: Container for the person who submitted the reported allowance data. |
|
/ TimeCard/ ReportedTime/
Allowance/ SubmitterInfo/ Person/ |
- 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/ |
- xsd:string - S (0/1) |
The system that submitted the
timecard. |
|
/ TimeCard/ ReportedTime/
Allowance/ SubmitterInfo/ |
- AnyDateTimeType - S (1/1) |
The timestamp as to when the timecard was submitted. |
|
/ TimeCard/ ReportedTime/
Allowance/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/ |
- AdditionalDataType - S (0/*) |
Allows trading partner specific structured information or extensions. |
|
/ TimeCard/ ReportedTime/ |
- ApprovalInfoType - S (0/*) |
Container which holds information about when and by whom the entire Timecard was approved. |
|
/ TimeCard/ ReportedTime/
ApprovalInfo/ |
- TimeCardPersonType - S (1/1) |
Context definition: Container for the person who approved the reported time data. |
|
/ TimeCard/ ReportedTime/
ApprovalInfo/ Person/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ReportedTime/
ApprovalInfo/ |
- AnyDateTimeType - S (1/1) |
The timestamp when the time card was approved. |
|
/ TimeCard/ ReportedTime/
ApprovalInfo/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ ReportedTime/ |
- SubmitterInfoType - S (0/1) |
Container with information describing when and by whom the entire Timecard was submitted. |
|
/ TimeCard/ ReportedTime/
SubmitterInfo/ |
- TimeCardPersonType - S (0/1) |
Context definition: Container for the person who submitted the reported time data. |
|
/ TimeCard/ ReportedTime/
SubmitterInfo/ Person/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ReportedTime/
SubmitterInfo/ |
- xsd:string - S (0/1) |
The system that submitted the
timecard. |
|
/ TimeCard/ ReportedTime/
SubmitterInfo/ |
- AnyDateTimeType - S (1/1) |
The timestamp as to when the timecard was submitted. |
|
/ TimeCard/ |
- SubmitterInfoType - S (0/1) |
Container with information describing when and by whom the entire Timecard was submitted. |
|
/ TimeCard/ SubmitterInfo/ |
- TimeCardPersonType - S (0/1) |
Context definition: Container for the person who submitted the time card. |
|
/ TimeCard/ SubmitterInfo/
Person/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ SubmitterInfo/ |
- xsd:string - S (0/1) |
The system that submitted the
timecard. |
|
/ TimeCard/ SubmitterInfo/ |
- AnyDateTimeType - S (1/1) |
The timestamp as to when the timecard was submitted. |
|
/ TimeCard/ |
- ApprovalInfoType - S (0/*) |
Container which holds information about when and by whom the entire Timecard was approved. |
|
/ TimeCard/ ApprovalInfo/ |
- TimeCardPersonType - S (1/1) |
Context definition: Container for the person who approved the time card. |
|
/ TimeCard/ ApprovalInfo/ Person/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ TimeCard/ ApprovalInfo/ |
- AnyDateTimeType - S (1/1) |
The timestamp when the time card was approved. |
|
/ TimeCard/ ApprovalInfo/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ TimeCard/ |
- AdditionalDataType - S (0/*) |
Allows trading partner specific structured information or extensions. |
|
Global
types |
ContentModel* |
Definition * |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Add, Change, Void, Unchanged |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
type - xsd:string - |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [AdditionalDataType] / |
- xsd:string - |
Further defines the associated element in the context provided. |
|
/ |
approverType - xsd:string
- |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [ApprovalInfoType] / |
- xsd:string - |
Allows a description of the level
or role of the approver. |
|
/ [ApprovalInfoType]/ |
- TimeCardPersonType - S (1/1) |
Contains information about a person. |
|
/ [ApprovalInfoType]/ Person/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ [ApprovalInfoType]/ |
- AnyDateTimeType - S (1/1) |
The timestamp when the time card was approved. |
|
/ [ApprovalInfoType]/ |
- CommentType - S (0/*) |
Allows for textual comments. |
|
/ |
xsd:extension base: xsd:string |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [CommentType] / |
|
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: previous, current, next |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
- [Union]: DayAssignmentEnumerationType,LocalDateType, xsd:nonNegativeInteger |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
Person - TimeCardPersonType
- S (0/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [SubmitterInfoType]/ |
- TimeCardPersonType - S (0/1) |
Contains information about a person. |
|
/ [SubmitterInfoType]/ Person/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ [SubmitterInfoType]/ |
- xsd:string - S (0/1) |
The system that submitted the
timecard. |
|
/ [SubmitterInfoType]/ |
- AnyDateTimeType - S (1/1) |
The timestamp as to when the timecard was submitted. |
|
/ |
- [Union]: xsd:duration,xsd:decimal |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
Id - EntityIdType
- S (0/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ [TimeCardPersonType]/ |
- EntityIdType - S (0/1) |
A unique identifier used to reference the entity. The Id is associated with the higher level element. |
|
/ |
xml:lang - - |
Globally scoped data type. See element or attribute declaration for definition. |
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.
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).
The ActionCode defines how the receiver should process the transmitted data. The following list describes the purpose of each enumerated value:
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. |
|
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
Future version (major release) |
|
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 |
|
Reference |
Link |
|
TimeCard schema |
|
|
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 |
|
Entity Identifier Type |
http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/EntityIdentifiers.html |
|
PersonName |
|
|
PostalAddress |
|
|
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 |
Examples map to instances displayed in Sections 2.2.4 and 2.3.4.
 Each amount is charged to the same project (DUP1899), however each is associated to different tasks within that project.
<TimeCard xmlns="http://ns.hr-xml.org/2007-04-15" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ns.hr-xml.org/2007-04-15.xsd">
<ReportedResource>
<Person>
<Id>
<IdValue>77598</IdValue>
</Id>
<PersonName>
<FormattedName>Michelle Hartwick</FormattedName>
</PersonName>
</Person>
</ReportedResource>
<ReportedTime status="Raw">
<PeriodStartDate>2001-07-01</PeriodStartDate>
<PeriodEndDate>2001-07-31</PeriodEndDate>
<ReportedPersonAssignment>
<Id>
<IdValue>DUP1899</IdValue>
</Id>
</ReportedPersonAssignment>
<Expense type="Meal" billable="true">
<Id>
<IdValue>55588</IdValue>
</Id>
<ExpenseDate>2001-07-19</ExpenseDate>
<ExpenseAmount currency="CAD">123.95</ExpenseAmount>
<AdditionalData type="Task">17W9</AdditionalData>
<Comment>Dinner with Consultants</Comment>
</Expense>
<Expense type="Misc." billable="true">
<Id>
<IdValue>55589</IdValue>
</Id>
<ExpenseDate>2001-07-20</ExpenseDate>
<ExpenseAmount currency="CAD">77.21</ExpenseAmount>
<AdditionalData type="Task">17W8</AdditionalData>
<Comment>Book: XML for Simpletons</Comment>
</Expense>
</ReportedTime>
<SubmitterInfo>
<Person>
<PersonName>
<FormattedName>Amanda Hardaway</FormattedName>
</PersonName>
</Person>
<SubmittedDateTime>2001-07-31T11:00:00</SubmittedDateTime>
</SubmitterInfo>
<ApprovalInfo approverType="1st Level">
<Person/>
<ApprovedDateTime>2001-08-03</ApprovedDateTime>
</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).
<TimeCard xmlns="http://ns.hr-xml.org/2007-04-15" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ns.hr-xml.org/2007-04-15.xsd">
<ReportedResource>
<Resource type="car">
<Id>
<IdValue>A4513585</IdValue>
</Id>
<ResourceName>ABC1 Corporate Limo</ResourceName>
<AdditionalData type="owner"> Office of the president</AdditionalData>
</Resource>
</ReportedResource>
<ReportedTime status="Raw">
<PeriodStartDate>2001-08-06</PeriodStartDate>
<PeriodEndDate>2001-08-12</PeriodEndDate>
<TimeInterval type="Regular" dayAssignment="current" billable="true">
<Id>
<IdValue>4501</IdValue>
</Id>
<StartDateTime>2001-08-06</StartDateTime>
<EndDateTime>2001-08-06</EndDateTime>
<Duration>PT2H</Duration>
<RateOrAmount currency="USD" type="Hourly" period="Hour">250.00</RateOrAmount>
<AdditionalData type="Project">19004-A17W1</AdditionalData>
<ApprovalInfo approverType="Manager">
<Person>
<Id>
<IdValue>000001</IdValue>
</Id>
<PersonName>
<FormattedName>Maxwell Short</FormattedName>
</PersonName>
</Person>
<ApprovedDateTime>2001-08-13T10:00:00</ApprovedDateTime>
<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>
<ApprovalInfo approverType="CEO">
<Person>
<Id>
<IdValue>00003</IdValue>
</Id>
<PersonName>
<FormattedName>Quinn Montgomery</FormattedName>
</PersonName>
</Person>
<ApprovedDateTime>2001-08-13T11:23:00+05:00</ApprovedDateTime>
</ApprovalInfo>
</ReportedTime>
<SubmitterInfo>
<Person>
<Id>
<IdValue>125549</IdValue>
</Id>
<PersonName>
<FormattedName>Lucy Henderson</FormattedName>
</PersonName>
</Person>
<Source>QATimes</Source>
<SubmittedDateTime>2001-08-10T16:47:00+05:00</SubmittedDateTime>
</SubmitterInfo>
</TimeCard>
Example 7:
<TimeCard xmlns="http://ns.hr-xml.org/2007-04-15" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ns.hr-xml.org/2007-04-15.xsd">
<ReportedResource>
<Person>
<Id>
<IdValue>d026194</IdValue>
</Id>
</Person>
</ReportedResource>
<ReportedTime status="Approved">
<PeriodStartDate>2006-05-01</PeriodStartDate>
<PeriodEndDate>2006-05-18</PeriodEndDate>
<TimeInterval type="Regular" billable="true">
<StartDateTime>2006-05-07</StartDateTime>
<EndDateTime>2006-05-07</EndDateTime>
<Duration>PT8H</Duration>
<Allowance type="Riskallowance" billable="true">
<StartDate>2006-05-06</StartDate>
<ApprovalInfo>
<Person>
<PersonName>
<FormattedName>Elvira Annevelink</FormattedName>
</PersonName>
</Person>
<ApprovedDateTime>2006-05-09</ApprovedDateTime>
</ApprovalInfo>
</Allowance>
<SubmitterInfo>
<Person>
<PersonName>
<FormattedName>Erwin Folmer</FormattedName>
</PersonName>
</Person>
<SubmittedDateTime>2006-05-08</SubmittedDateTime>
</SubmitterInfo>
<Comment>Aaabbbccc</Comment>
</TimeInterval>
<Expense type="Meal" billable="true">
<ExpenseDate>2006-05-07</ExpenseDate>
<ExpenseAmount currency="USD">10</ExpenseAmount>
</Expense>
<TimeInterval type="Vacation" actionCode="Add">
<StartDateTime>2006-05-08</StartDateTime>
<EndDateTime>2006-05-11</EndDateTime>
</TimeInterval>
<TimeInterval type="Regular" actionCode="Change">
<StartDateTime>2006-05-14</StartDateTime>
<EndDateTime>2006-05-14</EndDateTime>
<Duration>PT4H</Duration>
</TimeInterval>
<TimeInterval type="Sickness" actionCode="Unchanged">
<StartDateTime>2006-05-14</StartDateTime>
<EndDateTime>2006-05-14</EndDateTime>
<Duration>PT4H</Duration>
</TimeInterval>
<TimeInterval type="Sickness" actionCode="Void">
<StartDateTime>2006-05-15</StartDateTime>
<EndDateTime>2006-05-18</EndDateTime>
</TimeInterval>
</ReportedTime>
</TimeCard>


---
layout: no_foot
title: Flint Justice Partnership Official Website
---
Thanks for RSVP'ing! Meet in the north courtyard of West Quad (Chicago House side) at 4 pm on Saturday, September 5. Click here to add the event to your google calendar!
Click here to RSVP again.


Preparation time
less than 30 mins
Cooking time
1 to 2 hours
Serves
Serves 4
Mulled spices go into the apple sauce for this wintry pork recipe – ideal to be served over the Christmas period with a glass of mulled cider.
For the pork, preheat the oven to 230C/475F/Gas 8.
Bring a kettle of water to the boil. Place the pork on a metal rack suspended over the sink or a bowl and pour the boiling water over the pork, allowing to drain.
Pat the pork dry with kitchen paper, then rub all over with the olive oil and season, to taste, with the salt flakes and freshly ground black pepper. Roll the pork into a neat cylinder and tie with butchers' string.
Place the pork into a roasting tray and roast for 30 minutes.
Reduce the oven temperature to 180C/350F/Gas 4 and cook the pork for a further 1-1¼ hours, or until the crackling is crisp and the meat is tender and cooked through.
Meanwhile, for the roasted apple, place the apples onto a roasting tray.
Mix the spices together in a bowl, then sprinkle the mixed spices over the apples and stir to coat.
Dot the butter over the top of the apples and then pour over two tablespoons of water.
Place in the oven with the pork and roast for 20 minutes, or until the apple is tender. When ready to serve, roughly mash with a fork, add sugar and seasoning, to taste.
For the mash, place the potatoes into a pan of salted water and bring to the boil. Reduce the heat and simmer for 12-15 minutes, or until the potatoes are tender.
Drain the potatoes and return to the pan. Place over a low heat for one minute to dry off any excess moisture.
Mash the potatoes well or pass through a ricer into a clean saucepan.
Meanwhile, place the butter and milk into a saucepan and bring to a simmer, then beat the butter and milk into the mashed potato. Season, to taste, with salt and freshly ground black pepper.
For the greens, heat a separate frying pan until medium hot, add the butter and 50ml/2fl oz water and bring to a boil, then add the spring greens and fry until just wilted. Season with a touch of salt, black pepper and ground nutmeg.
Remove the pork from the oven, place the meat onto a plate and set aside to rest for 15 minutes. Bring the juices in the roasting tin to a simmer over a medium heat.
To serve, carve the pork into slices and serve with some mash, the spring greens and a dollop of roasted apple. Finish with a drizzle of pan juices.


FALLOCATE
Section: User Commands (1)Updated: Jul 2009
Index Return to Main Contents
NAME
fallocate - preallocate space to a file.SYNOPSIS
fallocate [-n] [-o offset] -l length filenameDESCRIPTION
fallocate is used to preallocate blocks to a file. For filesystems which support the fallocate system call, this is done quickly by allocating blocks and marking them as uninitialized, requiring no IO to the data blocks. This is much faster than creating a file by filling it with zeros.As of the Linux Kernel v2.6.31, the fallocate system call is supported by the btrfs, ext4, ocfs2, and xfs filesystems.
The exit code returned by fallocate is 0 on success and 1 on failure.
OPTIONS
- -h, --help
- Print help and exit.
- -n, --keep-size
- Do not modify the apparent length of the file. This may effectively allocate blocks past EOF, which can be removed with a truncate.
- -o, --offset offset
- Specifies the beginning offset of the allocation, in bytes. Suffixes of k, m, g, t, p, e may be specified to denote KiB, MiB, GiB, etc.
- -l, --length length
- Specifies the length of the allocation, in bytes. Suffixes of k, m, g, t, p, e may be specified to denote KiB, MiB, GiB, etc.
AUTHORS
Eric Sandeen<EMAIL_ADDRESS>Karel Zak<EMAIL_ADDRESS>SEE ALSO
fallocate(2), posix_fallocate(3), truncate(1)AVAILABILITY
The fallocate command is part of the util-linux-ng package and is available from ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/.
Index
This document was created by man2html, using the manual pages.
Time: 05:29:03 GMT, December 24, 2015


Poet • Author of Intrusive Beauty • Teacher
Joseph J. Capista’s collection Intrusive Beauty was selected by Beth Ann Fennelly for Ohio University Press’s 2018 Hollis Summers Poetry Prize. Poems by Capista have appeared in AGNI, The Georgia Review, The Hudson Review, Ploughshares, Poetry Daily, and Slate. Work in education has taken him into group homes, high schools, universities, preschools, and a state penitentiary. He teaches creative writing and expository writing at Towson University.
A recipient of awards from the Bread Loaf Writers’ Conference, the Sewanee Writers’ Conference, the Maryland State Arts Council, and the National Endowment for the Humanities, Capista holds an MFA from Warren Wilson College. He and his spouse reside in Baltimore, where they raise their daughters.


|
Gloucester-Mathews
GAZETTE-JOURNAL
|
|
Copies or transcriptions
of these weddings are offered at a basic rate of $5 each. Please allow
six weeks to fill your order.


Hi,
I am Sergi, a web & CMS developer based in United Kingdom. I am specialised in HTML, CSS, Javascript and PHP based technologies like TYPO3, Wordpress and Zend.
Hi,
I am Sergi, a web & CMS developer based in United Kingdom. I am specialised in HTML, CSS, Javascript and PHP based technologies like TYPO3, Wordpress and Zend.


RWI Element Game
Restart Game
Player: 0
CPU: 0
Choose your Element
How to Win
Fire beat Grass
Water beat Fire
Grass beat Water
X


FANTASTIC MR. FOX
by Roald Dahl
illustrated by Donald Chaffin; Alfred A. Knopf, New York.
FANTASTIC MR. FOX
by Roald Dahl
illustrated by Donald Chaffin; Alfred A. Knopf, New York.
FANTASTIC MR. FOX
by Roald Dahl
illustrated by Donald Chaffin; Alfred A. Knopf, New York.
FANTASTIC MR. FOX
by Roald Dahl
illustrated by Donald Chaffin; Alfred A. Knopf, New York.
FANTASTIC MR. FOX
by Roald Dahl
illustrated by Donald Chaffin; Alfred A. Knopf, New York.


Home
After alot of coding and troubleshooting the code, i finnaly got it to work! Yeah!:)
PARENT
CHILD 1
CHILD 2
CHILD 3
Stretch All


Bogomark
Benchmark the
bogosort
sorting algorithm
[
source
]
Size
Iterations
[
csv
] [
reset
]
Size
Average
Minimum
Maximum
Iteration
Milliseconds
Steps