Payroll Instructions
Recommendation, 2007 April 15
Editor:
Chuck Allen, HR-XML Consortium, Inc.
Contributors:
Terry Malone-Burrell, Ceridian Employer Services; Elizabeth O’Neal, Employease; Jason Brown, Employer Payment Solutions; Rich Barritt, Fidelity; Chris Pierpan, Fidelity; Chris Brown, Hewitt Associates; Scott Cowley, IBM; Mark Grasso, Rewards Plus; Adam Sroka, Rewards Plus; Jean Handel-Bailey, SAP; Joe Lalla, Towers Perrin; Penni Kessler, Ultimate Software
Copyright © 2007 HR-XML Consortium, Inc.
Abstract
This document describes HR-XML’s PayrollInstructions specification. This specification defines an XML schema for structuring pre-payroll change requests for deductions and certain other adjustments to pay.
Table of Contents
1.3.1 Items Outside of Design Scope
1.4 Terminology: “Deduction” and “Benefit”
2 Supported Business Processes
2.2 Business Process Scenarios
3.1.11 Other Global Complex Types
4 Implementation Considerations
5 Appendix A - Document Version History
6 Appendix B – Related Documents
7 Appendix C – Reference Examples
7.2 Scenario 1 - New Business Transaction
7.3 Scenario 2 - Change Transaction. 36
7.4 Scenario 3 - Cancellation Transaction
PayrollInstructions Version 1.0 is designed to enable the submission of payroll deduction requests and other instructions to an organization that processes payrolls. The type of instructions covered by the specification include those for deductions from employees’ pay as well as adjustments to employer payments and liabilities that must be considered in payroll calculations (see Section 1.4, Terminology: “Deduction” and “Benefit”).
The goal of the HR-XML Consortium’s PayrollInstruction project was development of a specification, including an XML schema, for structuring pre-payroll change instructions.
Employers have more choices than ever before about how they process payrolls, handle employee benefit elections and enrollments, and pay for and administer benefit programs. As a result of employers outsourcing of their HR and payroll functions and as a result of innovative benefit program offerings, a greater number of parties may be involved in the transmission of payroll data than in the past.
The purpose of the HR-XML Consortium’s PayrollInstructions specification is to provide guidance on how to structure exchanges of payroll instructions relating to certain deductions and adjustments. When employees change their benefit elections or otherwise experience work or life events that change their benefits coverage or pay, corresponding changes to payroll amounts often are necessary. Before a payroll is processed, an employer, its third party benefits administrator, and its payroll service provider usually must transmit, reconcile, and process instructions related to the payroll deductions and adjustments. A variety of business and legal requirements determine the specific information that is included in any given payroll instruction.
The HR-XML Consortium’s PayrollInstructions specification is designed to be useful to a wide-range of payroll trading partners. It also was designed to flexibly support instructions for a wide-range of employee services and benefits programs. The PayrollInstructions specification can be used to transmit payroll deduction instructions for medical insurance, flexible spending accounts, life insurance, short and long term disability insurance, accident insurance, savings accounts, and employee stock purchase plans as well as for other types of programs that exist today or may exist in the future. The PayrollInstructions specification also can be useful for transmitting instructions related to voluntary or non-benefit deductions, such as those for charities, union dues, savings bonds, savings/credit union accounts, personal loans, personal and business membership fees, tuition and book fees, transportation fees, parking fees, etc. The list is endless as to what a person may pay for through voluntary payroll deductions.
The HR-XML Consortium’s PayrollInstructions specification gives employers flexibility and saves them time and money when integrating systems with benefits administrators, benefits providers, and payroll processors. Employers may be more willing to offer employees services and benefits from new providers if integration with trading-partner systems can be achieved with little or no up-front integration costs. For benefits, payroll, and HR vendors, a standard schema for handling PayrollInstructions eliminates the need to devote time and money to the task of building unique interfaces with customers and trading partners. Typically, this type of integration work provides little unique value to the customer and creates barriers to acquiring new business and new partnerships.
Version 1.0 of the PayrollInstructions schema is designed to support payroll change instructions for:
PayrollInstructions Version 1.0 focuses on change instructions for deductions and adjustments related to employer-provided benefits, subsidies, and similar programs. Later versions may support a broader range of instruction types, such as those for garnishments, pay increases, etc.
There are a wide variety of payroll instructions that are not addressed within PayrollInstructions Version 1.0. Outside the scope of the Version 1.0 specification are payroll instructions for:
Note that since PayrollInstructions Version 1.0 is not intended to support the initial setup of a person on a payroll or benefits system, it is assumed that instructions apply only to payees or plan participants who already have been added to payroll and benefit administration systems through enrollment and payroll setup processes.
As described in Section 2.3, the PayrollInstructions specification was designed to support the batch transmission of instructions. Beyond providing a basic structure to support batch processing, the specification does not yet specify detailed processing rules. Trading partners will need to agree on rules for handling “Add,” “Change,” “Correction” instructions or other types of changes their business relationship may dictate.
The HR-XML Consortium’s PayrollInstructions specification is intended to be sufficiently flexible to handle a wide variety of instructions. As discussed above in Section 1.3, Scope, the schema is designed to handle one or more payroll change instructions per employee for one or more employees. Thus, within the schema’s PersonInstruction element one or more Instruction is permitted. A single instruction may contain either a Benefit or a Deduction. For purposes of the PayrollInstructions schema, these components are defined as follows:
§ A Deduction is an instruction related to a liability of the employee. For example, a deduction might be made to pay for a benefit elected by an employee, such as auto insurance.
§ A Benefit is an instruction related to a liability of the employer. For example, an instruction related to an employer-provided transit subsidy would be an example of Benefit.
Note that in the PayrollInstructions schema, DeductionType and BenefitType are similar in structure. The HR-XML Consortium’s Payroll workgroup considered using a generalized structure that could accommodate both deductions and benefits. However, the group decided that separate structures for these two types would provide more clarity and would better accommodate trading-partner extensions as well as future refinement.
The HR-XML Consortium’s PayrollInstructions specification is intended to be useful in a wide variety of contexts and business process scenarios. The PayrollInstruction specification does not prescribe or require a particular model for payroll or benefits administration. However, sections below describe some of the typical business process scenarios in which the PayrollInstructions specification is useful.
The PayrollInstructions specification is intended to support pre-payroll instructions. Note that the transmission post-payroll contributions data might be accomplished using the HR-XML Consortium’s PayrollBenefitContributions schema.
Below are brief descriptions of some of the roles played by entities involved in the exchange of PayrollInstructions:
The following sections show the use of the PayrollInstructions schema within two scenarios:
§ An employee makes a benefit election or an enrollment that will change a deduction or benefit amount in his or her paycheck.
The second scenario is similar to the first. However, in this scenario, the employee directly logs into to a site hosted by the third-party administrator to request the election or enrollment change.
Pre-payroll instructions for deductions and benefits typically are transmitted in a batch mode. HR-XML’s PayrollInstructions specification was designed to support batch transmission of instructions. The schema also might be useful in supporting near-real time submission of individual instructions if required.
The mode attribute of the Instruction element can be used to distinquish the reason an individual instruction was included within the payload.
Possible values for mode are enumerated within the schema. The enumerations chosen for the mode attribute are consistent with similar values used within the HR-XML Consortium’s Benefits Enrollment specification.
Enumerated values for mode are: Add; Audit; Change; Correction; Delete; Suspend; and Terminate. For example, Add may be used for new instructions. Change, Correction, Suspend, Delete, and Terminate would relate to different types of changes made on existing Instructions. As the name suggests, Correction is a change instruction to rectify prior errors. Delete might entail complete removal of the instruction from the system of the trading partners, whereas a suspend instruction might indicate merely to “de-activate” the instruction temporarily or indefinitely. “Audit” is intended to support periodic comparisons of data between sending and receiving systems (To accomplish such a comparison, a conforming XML document should include all available Instruction data (marked with a mode value of Audit) as of an agreed-upon effective date).
Note that the enumerated values for mode are merely possible values. Additional values are allowed if they are prefixed with an “x:” As explained in Section 1.3.1, Items Outside of Design Scope, the specification provides a basic structure to support batch processing, but it does not yet specify detailed processing rules. Trading parters need to decide on the set of values appropriate for supporting the transactions between them and will need to decide the meaning of those values within the context of their business relationship.
In most cases, a payroll instruction will include a fixed amount for the deduction or adjustment. However, in some cases, it might be desirable to transmit a formula to calculate the amount or to transmit information sufficient to retrieve the amount from a schedule or lookup table stored on the receiving system.
HR-XML’s PayrollInstruction schema supports fixed amounts, but it also provides several different methods for transmitting information for calculated amounts. These methods are identified and illustrated below:
The “Fixed” method is used for a non-calculated, known amount. For example, you may know that a health deduction amount is a fixed $24.32 per pay run.
<Fixed>
<Value>24.32</Value>
</Fixed>
This method is used to transmit a calculated percentage amount. For example, you may know that a retirement contribution is 5.5 percent of $6,800.
<Percent>
<Basis>
<BasisValue>6800.00</BasisValue>
</Basis>
<Percentage>5.5</Percentage>
</Percent>
Alternatively, the amount value could be a percentage of an amount that would not be known until later during the pay run. For example, a deduction might be equal to 5.5 percent of the employee's gross pay.
<Percent>
<Basis>
<BasisVariableName>GrossPay</BasisVariableName >
</Basis>
<Percentage>5.5</Percentage>
</Percent>
Linear
Using this method, the amount value is calculated from a simple linear model. For example:
y = -19.25 + 0.035 * DisposableIncome + Number of North
Carolina State Income Tax Exemptions + .0001 * 16
Any linear model, with as many terms as needed, could be used.
<Linear>
<YIntercept>-19.25</YIntercept>
<Argument index="1">
<ArgumentVariableName multiplier="0.035">DisposableIncome</ArgumentVariableName>
</Argument>
<Argument index="3">
<ArgumentValue multiplier="0.0001">16</ArgumentValue>
</Argument>
<Argument index="2">
<ArgumentVariableName>NumNCSITExemptions</ArgumentVariableName>
</Argument>
</Linear>
In this example, the calculated value is determined from a lookup table, which is specified. For example, worker's compensation (WC) rates are based upon the worker's compensation code or classification for the work being performed. One would associate the pay type with a WC code so that the dollar amount for the associated WC premium could be determined.
<Lookup>
<LookupTable>
<LookupTableName>North Carolina Worker's Compensation for
Pheonix Fund and Company ABC (this is table with id 37)</LookupTableName>
<LookupTableEntry>
<Key>8018</Key>
<Value>0.21</Value>
</LookupTableEntry>
<LookupTableEntry>
<Key>8088</Key>
<Value>0.52</Value>
</LookupTableEntry>
<LookupTableEntry>
<Key>5213</Key>
<Value>5.49</Value>
</LookupTableEntry>
</LookupTable>
<LookupKey>5213</LookupKey>
</Lookup>
The following is another example of the lookup method where the table is specified via an Id with complex primary key. In this example, the calculated value is determined from a lookup table, which is referred to by Id. WC table change yearly, so it is best to keep the WC lookup table in a database and then just refer to it, as opposed to sending it along with each request.
<Lookup>
<LookupTableId idOwner="EPS" validFrom="2002-04-01" validTo="2003-03-31">
<IdValue name="TBL_WC_RATES.ER_ID">ABC</IdValue>
<IdValue name="TBL_WC_RATES.TABLE_ID">37</IdValue>
</LookupTableId>
<LookupKey>5213</LookupKey>
</Lookup>
In this example, the amount is calculated from a schedule. A basis amount determines the tier or level to apply a formula or amount. The basis amount in this case is 1329.82, so we would apply the second tier formulation.
(-infinity,1500) = 25
(1500,3000) = GrossPay * 14.25%
(3000,infinity) = Apply a predefined lookup table using the
HoursWorked as the key
to determine the value.
<Schedule>
<ScheduleTable>
<ScheduleTableName>Schedule Lookup for Company ABC</ScheduleTableName>
<ScheduleTableEntry>
<IntervalLow>NegativeInfinity</IntervalLow>
<IntervalHigh>1500.00</IntervalHigh>
<Fixed>
<Value>25.00</Value>
</Fixed>
</ScheduleTableEntry>
<ScheduleTableEntry>
<IntervalLow>1500.00</IntervalLow>
<IntervalHigh>3000.00</IntervalHigh>
<Percent>
<Basis>
<BasisVariableName>GrossPay</BasisVariableName>
</Basis>
<Percentage>14.25</Percentage>
</Percent>
</ScheduleTableEntry>
<ScheduleTableEntry>
<IntervalLow>3000.00</IntervalLow>
<IntervalHigh>PositiveInfinity</IntervalHigh>
<Lookup>
<LookupTableId idOwner="EPS" validFrom="2002-04-01" validTo="2003-03-31">
<IdValue name="TBL_WC_RATES.ER_ID">ABC</IdValue>
<IdValue name="TBL_WC_RATES.TABLE_ID">721</IdValue>
</LookupTableId>
<LookupKey>HoursWorked</LookupKey>
</Lookup>
</ScheduleTableEntry>
</ScheduleTable>
<ScheduleValue>1329.82</ScheduleValue>
</Schedule>
In this second example, the schedule is assumed to be stored in a database table and is specified using an Id.
<Schedule>
<ScheduleTableId idOwner="EPS" validFrom="2002-01-01" validTo="2002-12-31">
<IdValue name="TBL_TAX_SCHEDULES.ER_ID">ABC</IdValue>
<IdValue name="TBL_TAX_SCHEDULES.TABLE_ID">987</IdValue>
</ScheduleTableId>
<ScheduleValue>132.98</ScheduleValue>
</Schedule>
In this example, the calculated amount is a trading partner specific formula that has 4 arguments y = f(x1,x2,x3,x4) with named arguments:
Disposable Income
Number Of NC State Income Tax Exemptions
Variable3
Number Of Federal Income Tax Exemptions
<Extended>
<Function>MyTradingPartnerAgreedFunction</Function>
<Argument index="1">
<ArgumentVariableName name="Disposable Income">DisposableIncome</ArgumentVariableName>
</Argument>
<Argument index="2">
<ArgumentVariableName name="Number Of NC State Income Tax Exemptions">NumNCSITExemptions</ArgumentVariableName>
</Argument>
<Argument index="3">
<ArgumentValue name="Variable3">160</ArgumentValue>
</Argument>
<Argument index="4">
<ArgumentVariableName name="Number Of Federal Income Tax Exemptions">NumFedExemptions</ArgumentVariableName>
</Argument>
</Extended>
The principal design requirement was the development of a schema that was sufficiently comprehensive and flexible to handle a wide range of pre-payroll instructions.
The PayrollInstructions schema includes a number of component schemas. The dependencies among these schemas is presented in the table below:
|
Schema |
Description |
Component Schemas |
|
PayrollInstructions.xsd |
The principal PayrollInstructions schema. |
/CPO/PersonName.xsd /CPO/EntityIdType.xsd /CPO/UserArea.xsd /CPO/ISOUtilities.xsd /CPO/xStringPatternExtensionType.xsd /Payroll/BenefitDeductionCategoryType.xsd /Payroll/Frequencies.xsd /Payroll/TransactionCodes.xsd /Payroll/CalculatedValues.xsd |
|
BenefitDeductionCategoryType.xsd |
Defines a simple type, BenefitDeductionCategoryType, which is the union of a type defining country-specific enumerations and the type implementing HR-XML Consortium’s “pattern enumeration extension” convention. |
/CPO/xStringPatternExtensionType.xsd /Payroll/USBenefitDeductionCategoryType.xsd |
|
Frequencies.xsd |
Contains an enumeration of frequencies (for example, “Hourly”, “Daily”, “Weekly”, etc.) unioned with the type implementing HR-XML Consortium’s “pattern enumeration extension” convention. |
/CPO/xStringPatternExtensionType.xsd |
|
TransactionCodes.xsd |
Contains an enumeration of “transaction codes” – Add, Audit, Change, Correction, Delete, Suspend, Terminate. These are based on those used in the HR-XML Consortium’s Enrollment specification. This set of enumerations is unioned with the type implementing HR-XML Consortium’s “pattern enumeration extension” convention.
|
/CPO/xStringPatternExtensionType.xsd |
|
CalculatedValues.xsd |
Defines six methods for calculating: Fixed, Percent, Linear, Lookup, Schedule, and Extended. See Section 2.4, Calculation Methods. |
/CPO/EntityIdType.xsd /CPO/xStringPatternExtensionType.xsd |
Some of the component schemas listed in the third column were not defined as part of the PayrollInstructions specification, but were defined by the HR-XML Consortium’s Cross Process Objects (CPO) and other workgroups. For further information, see Section 6, Appendix B – Related Documents.
|
Component Name [Global types listed at the end of the table.] |
ContentModel* |
Definition |
|
/ |
PayrollEmployer - [complexType]
- S (1/1)
|
PayrollInstruction includes one or more payroll change instruction per employee, for one or more employees of a single employer. Version 1.0 of the schema will support only pre-payroll deduction and benefit instructions. Later versions may support a broader range of pre-payroll instructions. |
|
/
PayrollInstructions/ |
EmployerId
- EntityIdType - S
(1/*) |
Contains information identifying the employer to which the payroll pertains. At a minimum, this component contains an EmployerId. |
|
/
PayrollInstructions/ PayrollEmployer/ |
- EntityIdType - S (1/*) |
An EmployerId. This would be an identifier relevant to the system processing the payroll. |
|
/
PayrollInstructions/ PayrollEmployer/ |
- xsd:string - S (0/1) |
The name of the employer. |
|
/
PayrollInstructions/ PayrollEmployer/ |
- EntityIdType - S (0/*) |
A government-issued identifier relevant or required for payroll processings. For example, within the United States an EmployerGovernmentId usually would be a Federal Employer Indentification Number. |
|
/
PayrollInstructions/ |
PayrollPerson
- [complexType] - S
(1/1) |
This a payroll change instruction for a single payee. Multiple PersonInstructions can be batched within PayrollInstructions. |
|
/
PayrollInstructions/ |
- xsd:string - |
Identifies the version of the schema. |
|
/
PayrollInstructions/ |
- CurrencyCodeType - |
A three letter code identifying a currency. The code must conform to ISO 4217, Representation of Currency and Funds. Note that implementers also can specify currency |
|
/ PayrollInstructions/
PersonInstruction/ |
PersonId
- EntityIdType - S
(1/*) |
Information pertaining to the payee. |
|
/
PayrollInstructions/ PersonInstruction/ PayrollPerson/ |
- EntityIdType - S (1/*) |
An identifier for a payee included within a payroll. |
|
/
PayrollInstructions/ PersonInstruction/ PayrollPerson/ |
- PersonNameType - S (0/*) |
The name of the payee. |
|
/
PayrollInstructions/ PersonInstruction/ PayrollPerson/ |
- EntityIdType - S (0/*) |
A government identifier for a payee that is required or otherwise appropriate for payroll processing. For instance, in the United States, a Social Security Number would be a PersonGovernmentId. |
|
/
PayrollInstructions/ PersonInstruction/ |
PaymentDate
- LocalDateType - S
(0/1) |
A single payroll instruction for a payee. Note that multiple instructions are permitted per payee. |
|
/
PayrollInstructions/ PersonInstruction/ Instruction/ |
- TransactionCodeType - |
The mode attribute of the Instruction element can be used to distinquish the reason an individual instruction was included within the payload. Possible values for mode are enumerated within the schema. Enumerated values are: Add; Audit; Change; Correction; Delete; Suspend; and Terminate. Additional values are allowed if they are prefixed with an "x:" For further information, see Section 2.3, Batch Processing. |
|
/
PayrollInstructions/ PersonInstruction/ Instruction/ |
- LocalDateType - S (0/1) |
The date of a payroll draft or payment. |
|
Component Name [Global types listed at the end of the table.] |
ContentModel* |
Definition |
|
/ |
- DeductionType - C (1/1) |
Contains information for an instruction related to a deduction. See 1.4, Terminology: “Deduction” and “Benefit”. |
|
/
Deduction/ |
- ApplyToCompensationType - S (0/*) |
Indicates the compensation components to which a payroll instruction applies. Built-in values are: Base; Bonus; Commission; and Overtime. Additional values are permitted if prefixed with an "x:". |
|
/
Deduction/ |
- DeductionPlanType - S (1/1) |
Contains a collection of information identifying the benefit plan or program to which the deduction pertains. |
|
/
Deduction/ DeductionPlan/ |
- BenefitDeductionCategoryType - S (1/1) |
Identifies the type of plan or program to which the deduction pertains. The USBenefitDeductionCategoryType contains enumerations for the United States. The schema design contemplates enumeration sets for additional countries being added. Additional enumeration values are allowed if pre-fixed with "x:". |
|
/
Deduction/ DeductionPlan/ |
- xsd:string - S (0/1) |
The name of the plan or program to which the deduction pertains. |
|
/
Deduction/ DeductionPlan/ |
- EntityIdType - S (0/1) |
An identifier for the plan or program to which the deduction pertains. DeductionPlanId is of the type EntityIdentifierType. |
|
/
Deduction/ |
- LocalDateType - S (1/1) |
The date the deduction should begin. |
|
/
Deduction/ |
- xsd:integer - S (0/1) |
Contains a number indicating the order in which the deduction should be applied. |
|
/
Deduction/ |
- LocalDateType - S (0/1) |
Date deduction ends. It is assumed that DeductionEndDate is inclusive. |
|
/
Deduction/ |
- FrequencyType - S (0/1) |
The deduction frequency is for reoccurring deductions. This uses FrequencyType. Enumerations include: Daily, Weekly, Bi-weekly, Semi-monthly, Quarterly, Semi-annually, Annually, Month-Week-1, Month-Week-2, Month-Week-3, Month-Week-4, Month-Week-5, Month-Week-Last. |
|
/
Deduction/ |
- EntityIdType - S (0/1) |
DeductionCaseNumber is a reference number to tie the instruction to background information or other substantiating data. |
|
/
Deduction/ |
- PayrollDateType - S (0/*) |
DeductionOptionalDate allows the specification of dates that may be relevant or required by a receiving payroll system. A type attribute allows the following enumerations: WaitingPeriodStart, WaitingPeriodEnd, Eligibility, and Enrollment. Additional values are allowed, but must be prefixed with an "x:" |
|
/
Deduction/ |
- xsd:boolean - S (0/1) |
This indicates whether the deduction should be handled before applicable taxes are deducted. This is a boolean value - true or false. |
|
/ |
ApplyToCompensation
- ApplyToCompensationType - S (0/*) |
Globally scoped data type. See element or attribute declaration for definition. |
|
|
/
[DeductionType]/ |
- ApplyToCompensationType - S (0/*) |
Indicates the compensation components to which a payroll instruction applies. Built-in values are: Base; Bonus; Commission; and Overtime. Additional values are permitted if prefixed with an "x:". applyToCompensation accomodates the listing of multiple values. For example, the sender could specify that an instruction applies to "Base Overtime x:ThirdShiftPremium". |
|
|
/
[DeductionType]/ |
- DeductionPlanType - S (1/1) |
Contains a collection of information identifying the benefit plan or program to which the deduction pertains. |
|
|
/
[DeductionType]/ DeductionPlan/ |
- BenefitDeductionCategoryType - S (1/1) |
Identifies the type of plan or program to which the deduction pertains. The USBenefitDeductionCategoryType contains enumerations for the United States. The schema design contemplates enumeration sets for additional countries being added. Additional enumeration values are allowed if pre-fixed with "x:". |
|
|
/
[DeductionType]/ DeductionPlan/ |
- xsd:string - S (0/1) |
The name of the plan or program to which the deduction pertains. |
|
|
/
[DeductionType]/ DeductionPlan/ |
- EntityIdType - S (0/1) |
An identifier for the plan or program to which the deduction pertains. DeductionPlanId is of the type EntityIdentifierType. |
|
|
/
[DeductionType]/ |
- LocalDateType - S (1/1) |
The date the deduction should begin. |
|
|
/
[DeductionType]/ |
- xsd:integer - S (0/1) |
Contains a number indicating the order in which the deduction should be applied. |
|
|
/
[DeductionType]/ |
- LocalDateType - S (0/1) |
Date deduction ends. It is assumed that DeductionEndDate is inclusive. |
|
|
/
[DeductionType]/ |
- FrequencyType - S (0/1) |
The deduction frequency for reoccurring deductions. This is a type of FrequencyType. Enumerations include: Daily, Weekly, Bi-weekly, Semi-monthly, Quarterly, Semi-annually, Annually, Month-Week-1, Month-Week-2, Month-Week-3, Month-Week-4, Month-Week-5, Month-Week-Last. |
|
|
/
[DeductionType]/ |
- EntityIdType - S (0/1) |
DeductionCaseNumber is a reference number to tie the instruction to background information or other substantiating data. |
|
|
/
[DeductionType]/ |
- PayrollDateType - S (0/*) |
DeductionOptionalDate allows the specification of dates that may be relevant or required by a receiving payroll system. A type attribute allows the following enumerations: WaitingPeriodStart, WaitingPeriodEnd, Eligibility, and Enrollment. Additional values are allowed, but must be prefixed with an "x:" |
|
|
/ [DeductionType]/ |
- xsd:boolean - S (0/1) |
This indicates whether the deduction should be handled before applicable taxes are deducted. This is a boolean value - true or false. |
|
|
/
[DeductionType] / |
- xsd:boolean - |
This is a boolean flag to indicate whether an instruction is for reporting purposes only. For example, an employer may want to pass through an amount to its payroll processor that will appear on an employee's pay stub or wage statement, but require no actual payment or calculation by the payroll processor. |
|
|
/ |
DeductionCategory
- BenefitDeductionCategoryType - S (1/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
|
/
[DeductionPlanType]/ |
- BenefitDeductionCategoryType - S (1/1) |
Identifies the type of plan or program to which the deduction pertains. The USBenefitDeductionCategoryType contains enumerations for the United States. The schema design contemplates enumeration sets for additional countries being added. Additional enumeration values are allowed if pre-fixed with "x:". |
|
|
/
[DeductionPlanType]/ |
- xsd:string - S (0/1) |
The name of the plan or program to which the deduction pertains. |
|
|
/
[DeductionPlanType]/ |
- EntityIdType - S (0/1) |
An identifier for the plan or program to which the deduction pertains. DeductionPlanId is of the type EntityIdentifierType. |
|
|
|
|
|
|
|
/ |
- BenefitType - C (1/1) |
Contains information for an instruction related to a benefit or credit. |
|
/
Benefit/ |
- ApplyToCompensationType - S (0/*) |
Indicates the compensation components to which a payroll instruction applies. Built-in values are: Base; Bonus; Commission; and Overtime. Additional values are permitted if prefixed with an "x:". |
|
/
Benefit/ |
- BenefitPlanType - S (1/1) |
Contains information identifying the benefit plan or program to which the credit or benefit instruction pertains. |
|
/
Benefit/ BenefitPlan/ |
- BenefitDeductionCategoryType - S (1/1) |
Identifies the type of plan or program to which the benefit or credit pertains. The USBenefitDeductionCategoryType contains enumerations for the United States. The schema design contemplates enumeration sets for additional countries being added. Additional enumeration values are allowed if pre-fixed with "x:". |
|
/
Benefit/ BenefitPlan/ |
- xsd:string - S (0/1) |
The name of the plan or program to which the deduction pertains. |
|
/
Benefit/ BenefitPlan/ |
- EntityIdType - S (0/1) |
An identifier for the plan or program to which the benefit or credit pertains. BenefitPlanId is of the type EntityIdentifierType. |
|
/
Benefit/ |
- LocalDateType - S (1/1) |
Date benefit or credit starts. |
|
/
Benefit/ |
- LocalDateType - S (0/1) |
Date benefit or credit ends. It is assumed that BenefitEndDate is inclusive. |
|
/
Benefit/ |
- FrequencyType - S (0/*) |
With respect to a reoccuring benefit, the frequency with which the benefit or credit is applied. |
|
/
Benefit/ |
- xsd:string - S (0/1) |
BenefitCaseNumber is a reference number to tie the instruction to background information or other substantiating data. |
|
/
Benefit/ |
- PayrollDateType - S (0/*) |
BenefitOptionalDate allows the specification of dates that may be relevant or required by a receiving payroll system. A type attribute allows the following enumerations: WaitingPeriodStart, WaitingPeriodEnd, Eligibility, and Enrollment. Additional values are allowed, but must be prefixed with a "x:" |
|
/ |
ApplyToCompensation
- ApplyToCompensationType - S (0/*) |
Contains information for an instruction related to a benefit or credit. |
|
/
[BenefitType]/ |
- ApplyToCompensationType - S (0/*) |
Indicates the compensation components to which a payroll instruction applies. Built-in values are: Base; Bonus; Commission; and Overtime. Additional values are permitted if prefixed with an "x:". |
|
/
[BenefitType]/ |
- BenefitPlanType - S (1/1) |
Contains information identifying the benefit plan or program to which the credit or benefit instruction pertains. |
|
/
[BenefitType]/ BenefitPlan/ |
- BenefitDeductionCategoryType - S (1/1) |
Identifies the type of plan or program to which the benefit or credit pertains. The USBenefitDeductionCategoryType contains enumerations for the United States. The schema design contemplates enumeration sets for additional countries being added. Additional enumeration values are allowed if pre-fixed with "x:". |
|
/
[BenefitType]/ BenefitPlan/ |
- xsd:string - S (0/1) |
The name of the plan or program to which the deduction pertains. |
|
/
[BenefitType]/ BenefitPlan/ |
- EntityIdType - S (0/1) |
An identifier for the plan or program to which the benefit or credit pertains. BenefitPlanId is of the type EntityIdentifierType. |
|
/
[BenefitType]/ |
- LocalDateType - S (1/1) |
Date benefit or credit starts. |
|
/
[BenefitType]/ |
- LocalDateType - S (0/1) |
Date benefit or credit ends. It is assumed that BenefitEndDate is inclusive. |
|
/
[BenefitType]/ |
- FrequencyType - S (0/*) |
With respect to a reoccuring benefit, the frequency with which the benefit or credit is applied. |
|
/
[BenefitType]/ |
- xsd:string - S (0/1) |
BenefitCaseNumber is a reference number to tie the instruction to background information or other substantiating data. |
|
/
[BenefitType]/ |
- PayrollDateType - S (0/*) |
BenefitOptionalDate allows the specification of dates that may be relevant or required by a receiving payroll system. A type attribute allows the following enumerations: WaitingPeriodStart, WaitingPeriodEnd, Eligibility, and Enrollment. Additional values are allowed, but must be prefixed with a "x:" |
|
/
[BenefitType] / |
- BenefitTaxTreatmentType - |
Indicates the tax treatment of an employee benefit. Enumerated values are PreTax, PostTax, PreAndPostTax, and PostAfterPreTaxLimit. "PostAfterPreTaxLimit" indicates that the benefit is to be treated post-tax after the relevant pre-tax is reached. Additional values are permitted if prefixed with "x:". |
|
/
[BenefitType] / |
- xsd:boolean - |
This is a boolean flag to indicate whether an instruction is for reporting purposes only. For example, an employer may want to pass through an amount to its payroll processor that will appear on an employee's pay stub or wage statement, but require no actual payment or calculation by the payroll processor. |
|
/ |
BenefitCategory
- BenefitDeductionCategoryType - S (1/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[BenefitPlanType]/ |
- BenefitDeductionCategoryType - S (1/1) |
Identifies the type of plan or program to which the benefit or credit pertains. The USBenefitDeductionCategoryType contains enumerations for the United States. The schema design contemplates enumeration sets for additional countries being added. Additional enumeration values are allowed if pre-fixed with "x:". |
|
/
[BenefitPlanType]/ |
- xsd:string - S (0/1) |
The name of the plan or program to which the deduction pertains. |
|
/
[BenefitPlanType]/ |
- EntityIdType - S (0/1) |
An identifier for the plan or program to which the benefit or credit pertains. BenefitPlanId is of the type EntityIdentifierType. |
|
/
PayrollInstructions/ PersonInstruction/ Instruction/ |
- PayrollAmountType - S (0/1) |
Information necessary for determining the amount of the deduction or benefit. The currency attribute should be used for amounts when there is the possibility of instructions within the same batch using different currencies. If instructions transmitted using only one currency, use the currency attribute on PayrollInstructions to indicate the currency for the entire batch. The count can be used to give an accumulated count |
|
/
PayrollInstructions/ PersonInstruction/ Instruction/ Amount/ |
- LocalDateType - S (1/1) |
Start date relevant for calculation of deduction or benefit amount. |
|
/
PayrollInstructions/ PersonInstruction/ Instruction/ Amount/ |
- LocalDateType - S (0/1) |
End date relevant for calculation of deduction or benefit amount. |
|
/
PayrollInstructions/ PersonInstruction/ Instruction/ Amount/ |
- PayrollLimitType - S (0/*) |
Limits applicable to the instruction amount. |
|
/
PayrollInstructions/ PersonInstruction/ Instruction/ Amount/ AmountLimit/ |
- xsd:decimal - S (1/1) |
Maximum value limit for deduction or benefit. |
|
/
PayrollInstructions/ PersonInstruction/ Instruction/ Amount/ AmountLimit/ |
- xsd:decimal - S (1/1) |
A minimum value limit for deduction or benefit. |
|
/
PayrollInstructions/ PersonInstruction/ Instruction/ Amount/ |
- CalculatedValueType - S (1/1) |
Contains information necessary to calculate the amount of the deduction or benefit. Six methods for calculating values are provided: Fixed, Percent, Linear, Lookup, Schedule, and Extended. |
The following sections provide details for each calculation method. For examples, of each method, see Section 2.4, Calculation Methods.
|
/
CalculatedValue/ |
- CalculatedValueFixedType - C (1/1) |
The amount of the deduction or benefit. The exact amount is specified so there is no calculation required. |
|
/
CalculatedValue/ Fixed/ |
- xsd:decimal - S (0/1) |
A decimal value. |
|
/
CalculatedValue/ |
- CalculatedValuePercentType - C (1/1) |
Contains information necessary to calculate percentage. |
|
/
CalculatedValue/ Percent/ |
- BasisType - S (1/1) |
Basis information for percentage calculation. |
|
/
CalculatedValue/ Percent/ Basis/ |
- ArgumentValueType - C (1/1) |
An amount upon which a percentage is applied. |
|
/
CalculatedValue/ Percent/ Basis/ |
- ArgumentVariableType - C (1/1) |
A variable upon which a percentage is applied. For instance, an amount might be calculated as a percentage of "BasePay". |
|
/ CalculatedValue/
Percent/ |
- CalculatedPercentType - S (1/1) |
A percentage. For example, "3.5" percent. |
|
/
CalculatedValue/ |
- CalculatedValueLinearType - C (1/1) |
Linear function calculation. |
|
/ CalculatedValue/
Linear/ |
- xsd:decimal - S (0/1) |
The y-intercept of a linear function. |
|
/
CalculatedValue/ Linear/ |
- ArgumentType - S (1/*) |
An argument for linear function. |
|
/
CalculatedValue/ |
- CalculatedValueLookupType - C (1/1) |
Contains information necessary to calculate amount from a lookup table. |
|
/
CalculatedValue/ Lookup/ |
- EntityIdType - C (0/1) |
An identifier for the lookup table. |
|
/
CalculatedValue/ Lookup/ |
- CalculatedLookupTableType - C (0/1) |
Information about a table used to lookup an amount. |
|
/
CalculatedValue/ Lookup/ LookupTable/ |
- EntityIdType - S (0/1) |
An identifier for the lookup table. |
|
/
CalculatedValue/ Lookup/ LookupTable/ |
- xsd:string - S (0/1) |
A name for the lookup table. |
|
/
CalculatedValue/ Lookup/ LookupTable/ |
- CalculatedLookupTableEntryType - S (1/*) |
Information to lookup an amount from a table. |
|
/
CalculatedValue/ Lookup/ LookupTable/ LookupTableEntry/ |
- xsd:string - S (1/1) |
Key for table entry lookup. |
|
/
CalculatedValue/ Lookup/ LookupTable/ LookupTableEntry/ |
- ArgumentValueType - S (1/1) |
A decimal value. |
|
/
CalculatedValue/ Lookup/ |
- xsd:string - S (1/1) |
Key value for table lookup. |
|
/
CalculatedValue/ |
- CalculatedValueScheduleType - C (1/1) |
Contains information required to calculate an amount from a schedule table. |
|
/
CalculatedValue/ Schedule/ |
- EntityIdType - C (0/1) |
Indentifier for table for a schedule calculation. |
|
/
CalculatedValue/ Schedule/ |
- CalculatedScheduleTableType - C (0/1) |
A collection of information necessary to calculate an amount from a schedule. |
|
/
CalculatedValue/ Schedule/ ScheduleTable/ |
- EntityIdType - S (0/1) |
Indentifier for table for schedule calculation. |
|
/
CalculatedValue/ Schedule/ ScheduleTable/ |
- xsd:string - S (0/1) |
Name of table for schedule calculation. |
|
/
CalculatedValue/ Schedule/ ScheduleTable/ |
- CalculatedScheduleTableEntryType - S (1/*) |
Schedule entry. |
|
/
CalculatedValue/ Schedule/ ScheduleTable/ ScheduleTableEntry/ |
- CalculatedScheduleIntervalValueType - S (0/1) |
Low interval for schedule lookup. |
|
/ CalculatedValue/
Schedule/ ScheduleTable/ ScheduleTableEntry/ |
- CalculatedScheduleIntervalValueType - S (0/1) |
High interval for schedule lookup. |
|
/
CalculatedValue/ Schedule/ ScheduleTable/ ScheduleTableEntry/ |
- CalculatedValueFixedType - C (1/1) |
The amount of the deduction or benefit. The exact amount is specified so there is no calculation required. |
|
/
CalculatedValue/ Schedule/ ScheduleTable/ ScheduleTableEntry/ |
- CalculatedValuePercentType - C (1/1) |
Contains information necessary to calculate percentage. |
|
/
CalculatedValue/ Schedule/ ScheduleTable/ ScheduleTableEntry/ |
- CalculatedValueLinearType - C (1/1) |
Linear equation. |
|
/
CalculatedValue/ Schedule/ |
- CalculatedScheduleIntervalValueType - S (1/1) |
A value from a schedule table. |
|
/
CalculatedValue/ |
- CalculatedValueExtendedType - C (1/1) |
Function and argument for calculation. |
|
/
CalculatedValue/ Extended/ |
- xsd:string - S (1/1) |
An equation that takes one or more variables and returns a result. |
|
/
CalculatedValue/ Extended/ |
- ArgumentType - S (0/*) |
An argument for linear function. |
|
/
PayrollInstructions/ |
Deduction
- DeductionType - S
(0/1) |
Contains cumulative "control total" information for all instructions included in a single PayrollInstructions message. |
|
/ |
AmountStartDate
- LocalDateType - S
(1/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[PayrollAmountType]/ |
- LocalDateType - S (1/1) |
Start date relevant for calculation of deduction or benefit amount. |
|
/
[PayrollAmountType]/ |
- LocalDateType - S (0/1) |
End date relevant for calculation of deduction or benefit amount. |
|
/
[PayrollAmountType]/ |
- CalculatedValueType - S (1/1) |
Contains information necessary to calculate the amount of the deduction or benefit. Six methods for calculating values are provided: Fixed, Percent, Linear, Lookup, Schedule, and Extended. |
|
/
[PayrollAmountType]/ |
- PayrollLimitType - S (0/*) |
Limits applicable to the instruction amount. |
|
/
[PayrollAmountType]/ AmountLimit/ |
- xsd:decimal - S (1/1) |
Maximum value limit for deduction or benefit. |
|
/
[PayrollAmountType]/ AmountLimit/ |
- xsd:decimal - S (1/1) |
A minimum value limit for deduction or benefit. |
|
/
[PayrollAmountType] / |
- PayrollAmountDurationType - |
Attribute of amount. Allowed enumerations include Permanent and One-time. |
|
/
[PayrollAmountType] / |
- xsd:integer - |
A control total. |
|
/
[PayrollAmountType] / |
- CurrencyCodeType - |
A three letter code identifying a currency. The code must conform to ISO 4217, Representation of Currency and Funds. |
|
/ |
LimitMaxValue
- xsd:decimal - S
(1/1) |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[PayrollLimitType]/ |
- xsd:decimal - S (1/1) |
Maximum value limit for deduction or benefit. |
|
/
[PayrollLimitType]/ |
- xsd:decimal - S (1/1) |
A minimum value limit for deduction or benefit. |
|
/
[PayrollLimitType] / |
- PayrollLimitTypes - |
The type attribute of Amount specifies the calculation method. Allowed enumerations include: Fixed, Percent, Schedule, and Lookup. |
|
/ |
xsd:extension base: LocalDateType |
Globally scoped data type. See element or attribute declaration for definition. |
|
/
[PayrollDateType] / |
- PayrollOtherDateType - |
The type attribute of Amount specifies the calculation method. Allowed enumerations include: Fixed, Percent, Schedule, and Lookup. |
|
|
* This column shows a simple form of the content model for readability. Because of complex structures such as groups and nested occurrences, all of the content may not be included here. |
|
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Deduction, Benefit |
Enumerations to identify the type of payroll instruction. |
|
/ |
- [Union]: BasicPayrollLimitTypes,xStringPatternExtensionType |
Qualifies the period to be considered in applying a limit. Possible values are enumerated in the schema. Additional values are permitted if pre-fixed with “x:”. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: PerPayRun, PerMonth, PerQuarter, PerYear, PerLife |
Enumerations that qualify the period considered in applying a limit. Possible enumerations specified in the schema are: PerPayRun, PerMonth, PerQuarter, PerYear, and PerLife (a lifetime limit). |
|
/ |
- [Union]: PayrollBasicAmountDurationType,xStringPatternExtensionType |
Enumerations to qualify the duration of an amount. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Regular, One-time |
Enumerations to distinquish “Regular” re-ocurring amounts versus those that should be considered once. |
|
/ |
- [Union]: PayrollBasicDateType,xStringPatternExtensionType |
DeductionOptionalDate allows the specification of dates that may be relevant or required by a receiving payroll system. A type attribute allows the following enumerations: WaitingPeriodStart, WaitingPeriodEnd, Eligibility, and Enrollment. Additional values are allowed, but must be prefixed with a “x:” |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: WaitingPeriodStart, WaitingPeriodEnd, Eligibility, Enrollment |
Globally scoped data type. See element or attribute declaration for definition. |
|
/ |
- [Union]: BenefitBasicTaxTreatmentType,xStringPatternExtensionType |
Indicates amounts to consider in payroll calculations. Possible enumerations include: PreTax, PostTax, PreAndPostTax, PostAfterPreTaxLimit. Additional values are permitted if pre-fixed with “x:”. |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: PreTax, PostTax, PreAndPostTax, PostAfterPreTaxLimit |
Enumerations of tax treatment types. Enumerated values include: PreTax, PostTax, PreAndPostTax, PostAfterPreTaxLimit. |
|
/ |
- [Union]: ApplyToCompensationBasicType,xStringPatternExtensionType |
The union of HR-XML’s string pattern extension with a list of base compensation types. The string pattern extension allows additional values to be specified if pre-fixed with “x:” |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: Base, Bonus, Commission, Overtime |
Base compensation types enumerated in the schema: Base, Bonus, Commission, and Overtime. There are many more possible values. However, compensation components vary significantly depending on the employer, industry, employment and labor contracts, and pension and benefit plans. |
The PayrollInstructions schema was developed so that it would be useful in many jurisdictions. However, using country-specific enumerations is desirable to accurately categorize the type of benefit or deduction to which a payroll instruction pertains. To accommodate country-specific enumerations, the main PayrollInstructions.xsd includes the module “BenefitDeductionCategoryType.xsd.” That module defines a simple type, BenefitDeductionCategoryType, which is the union of a type defining country-specific enumerations and the type implementing HR-XML Consortium’s “pattern enumeration extension” convention. Under the pattern extension convention, the extended enumeration values are prefixed with a “x:”.
Version 1.0 of PayrollInstructions includes a USBenefitDeductionCategoryType to specify enumerations appropriate within the United States. Future versions may build in other country-specific enumeration lists. To localize the Version 1.0 PayrollInstructions schema with enumerations appropriate for other countries, BenefitDeductionCategoryType.xsd should be modified to include a module with a type defining the enumerations appropriate for the particular country. In addition, BenefitDeductionCategoryType should be modified to substitute the particular country-specific type for USBenefitDeductionCategoryType or, if desired, to union the country-specific type with USBenefitDeductionCategoryType and the type for the pattern enumeration extension.
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, any data exchange mechanism), organizations are advised to examine the privacy protections that may be required under applicable law or 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); U.S.-EU Safe Harbor Principles and FAQs (2000).
|
Date |
Description |
|
2002-07-19 |
First Draft |
|
2002-09-18 |
Added reference examples, updated schema |
|
2002-11-01 |
Addressed issues in last call review. |
|
2003-01-19 |
Addressed TSC issues. |
|
2003-02-11 |
Included edits from review |
|
2003-02-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. |
|
2004-07-06 |
An optional attribute xml:lang was added to the root element. |
|
2006-Feb-28 |
Approved by Consortium |
|
2007-April-15 |
Updated/Approved by Consortium |
|
Reference |
Link |
|
Effective Dating |
http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/EffectiveDating.html |
|
EntityId |
http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/EntityIdentifiers.html |
|
PersonName |
|
|
ContactMethod |
|
|
HR-XML-Extension |
|
|
PayrollBenefitsContributions |
http://ns.hr-xml.org/2_5/HR-XML-2_5/Payroll/PayrollBenefitContributions.html
|
|
BenefitsEnrollment |
http://ns.hr-xml.org/2_5/HR-XML-2_5/Enrollment/Enrollment.html |
For an example of batch, payroll instructions, see:
http://ns.hr-xml.org/2_5/HR-XML-2_5/Payroll/PayrollInstructions-eg.xml
On August 1, 2002, Mr. John A. Smith (SSN: 123-45-6789), an employee of International Engineering, Inc. purchased an auto policy and selects payroll deduction as the payment method. Mr. Smith's annual auto premium of $750 will be spread over his 26 bi-weekly paychecks. Each deduction will be in the amount of $28.85. His payroll deduction will begin with his Friday, August 23, 2002 paycheck. Mr. Smith works at the Dallas, Texas site.
<?xml version="1.0"?>
<PayrollInstructions 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
PayrollInstructions.xsd">
<PayrollEmployer>
<EmployerId>
<IdValue name="Employer Group Number">I12LENGINEER</IdValue>
</EmployerId>
<EmployerName>International Engineering, Inc.</EmployerName>
</PayrollEmployer>
<PersonInstruction>
<PayrollPerson>
<PersonId>
<IdValue name="Employee ID">12345</IdValue>
</PersonId>
<PersonName>
<GivenName>John</GivenName>
<MiddleName>A.</MiddleName>
<FamilyName>Smith</FamilyName>
</PersonName>
<PersonGovernmentId>
<IdValue name="Social Security Number">123-45-6789</IdValue>
</PersonGovernmentId>
</PayrollPerson>
<Instruction mode="Add">
<Deduction>
<DeductionPlan>
<DeductionCategory>x:Automobile Insurance</DeductionCategory>
</DeductionPlan>
<DeductionStartDate>2002-08-01</DeductionStartDate>
</Deduction>
<Amount currency="USD">
<AmountStartDate>2002-08-23</AmountStartDate>
<AmountValue>
<Fixed>
<Value>28.85</Value>
</Fixed>
</AmountValue>
</Amount>
</Instruction>
<UserArea/>
</PersonInstruction>
<UserArea/>
</PayrollInstructions>
On August 26, 2002, Mr. Smith added his teenage son, Greg, to his policy. The endorsement is in the amount of $525. Mr. Smith's new deduction amount will be $49.85 beginning with the September 6, 2002 paycheck.
<?xml version="1.0"?>
<PayrollInstructions 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
PayrollInstructions.xsd">
<PayrollEmployer>
<EmployerId>
<IdValue name="Employer Group Number">I12LENGINEER</IdValue>
</EmployerId>
<EmployerName>International Engineering, Inc.</EmployerName>
</PayrollEmployer>
<PersonInstruction>
<PayrollPerson>
<PersonId>
<IdValue name="Employee ID">12345</IdValue>
</PersonId>
<PersonName>
<GivenName>John</GivenName>
<MiddleName>A.</MiddleName>
<FamilyName>Smith</FamilyName>
</PersonName>
<PersonGovernmentId>
<IdValue name="Social Security Number">123-45-6789</IdValue>
</PersonGovernmentId>
</PayrollPerson>
<Instruction mode="Change">
<Deduction>
<DeductionPlan>
<DeductionCategory>x:Automobile Insurance</DeductionCategory>
</DeductionPlan>
<DeductionStartDate>2002-08-01</DeductionStartDate>
</Deduction>
<Amount>
<AmountStartDate>2002-09-06</AmountStartDate>
<AmountValue>
<Fixed>
<Value>49.85</Value>
</Fixed>
</AmountValue>
</Amount>
</Instruction>
<UserArea/>
</PersonInstruction>
<UserArea/>
</PayrollInstructions>
On October 4, 2002, Mr. Smith terminates employment with International Engineering, Inc. He accepted a new position with another company. He calls his insurance company to have his billing switched from payroll deduction to home bill.
<?xml version="1.0"?>
<PayrollInstructions 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
PayrollInstructions.xsd">
<PayrollEmployer>
<EmployerId>
<IdValue name="Employer Group Number">I12LENGINEER</IdValue>
</EmployerId>
<EmployerName>International Engineering, Inc.</EmployerName>
</PayrollEmployer>
<PersonInstruction>
<PayrollPerson>
<PersonId>
<IdValue name="Employee ID">12345</IdValue>
</PersonId>
<PersonName>
<GivenName>John</GivenName>
<MiddleName>A.</MiddleName>
<FamilyName>Smith</FamilyName>
</PersonName>
<PersonGovernmentId>
<IdValue name="Social Security Number">123-45-6789</IdValue>
</PersonGovernmentId>
</PayrollPerson>
<Instruction mode="Delete">
<Deduction>
<DeductionPlan>
<DeductionCategory>x:Automobile Insurance</DeductionCategory>
</DeductionPlan>
<DeductionStartDate>2002-08-01</DeductionStartDate>
</Deduction>
</Instruction>
</PersonInstruction>
</PayrollInstructions>


Summer of Sam (Spike Lee, USA, 1999), **1/2
The craft was, for the most part, there. It's just that the materials used in the crafting could have, perhaps, been better. This film seemed like a lesser Do the Right Thing, exploring many of the same themes, but with much less of an impact. Most of the acting is pretty good- at least better than average. John Leguizamo, Mira Sorvino, and Adrien Brody (among others) give good performances, but don't seem to have very good characters to work with. The viewer is never actually allowed to grow close enough to any of the characters to really care what happens to them. The story seems to be about how the enviroment of the time and place lead people to change and even turn on each other, but from the very beginning of the film, al the characters seem to be too wretched to really hold dear. Because of this, much of the tension simply seems forced, so when it is meant to explode, it really only seems to obscure itself somehow. Perhaps this is because Lee wastes his own stylistic talents here. He uses many clever stylistic techniquies and approaches, but because the characters and events have never become too involving, the bravura of the moment is lost and we're left with Lee's crafty camerawork or editing simply looking like a silly up-cropping of pretension. There was one scene that was actually somewhat satisfying: a Hollywood montage sequence of the neighborhood usuals all doing their things to get through the restless summer, most of them seeming to fall apart at least a littlein the process. This is all put to the tune of The Who's "Won't Get Fooled Again," and may be the best or most interesting seqeunces of the film, yet it loses its impact because it sticks out from the rest of the film which is mostly steps blow this. It would simply have worked better if the film had found a way to flow into and out of it, but it didn't and that is a shame because this film had probably a greater potential than was put to use.
-- TyroneZero's Movies, etc. http://members.tripod.com/~TyroneZero/film.html
Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


| Home | Libraries | People | FAQ | More |
These tests test the total time taken to execute all of Boost.Math's test cases for these functions. In each case the best performing library gets a relative score of 1, with the total execution time given in brackets. Times are shown for both single threaded runs and concurrent execution - the latter increases contension inside new/delete.
Table 1.14. Bessel Functions (50 digit precision)
|
Type |
Time |
|
|---|---|---|
|
cpp_bin_float_50 |
2.24409 (0.207745s) |
399 |
|
cpp_bin_float_50 (3 concurrent threads) |
2.87977 (0.266594s) |
463 |
|
cpp_dec_float_50 |
4.56157 (0.422285s) |
381 |
|
cpp_dec_float_50 (3 concurrent threads) |
5.66114 (0.524077s) |
424 |
|
mpf_float_50 |
1.03648 (0.0959515s) |
640961 |
|
mpf_float_50 (3 concurrent threads) |
1.50439 (0.139268s) |
2563517 |
|
mpf_float_50 (no expression templates |
1 (0.0925745s) |
1019039 |
|
mpf_float_50 (no expression templates (3 concurrent threads) |
1.52451 (0.141131s) |
4075842 |
|
mpfr_float_50 |
1.2513 (0.115838s) |
583054 |
|
mpfr_float_50 (3 concurrent threads) |
1.61301 (0.149324s) |
2330876 |
|
mpfr_float_50 (no expression templates |
1.42667 (0.132073s) |
999594 |
|
mpfr_float_50 (no expression templates (3 concurrent threads) |
2.00203 (0.185337s) |
4000039 |
|
static_mpfr_float_50 |
1.18358 (0.10957s) |
22930 |
|
static_mpfr_float_50 (3 concurrent threads) |
1.38802 (0.128496s) |
93140 |
|
static_mpfr_float_50 (no expression templates) |
1.14598 (0.106089s) |
46861 |
|
static_mpfr_float_50 (no expression templates) (3 concurrent threads) |
1.24535 (0.115288s) |
189227 |
Table 1.15. Non-central T Distribution (50 digit precision)
|
Type |
Time |
|
|---|---|---|
|
cpp_bin_float_50 |
2.38959 (38.5842s) |
0 |
|
cpp_bin_float_50 (3 concurrent threads) |
3.50535 (56.6s) |
28 |
|
cpp_dec_float_50 |
4.82763 (77.9505s) |
0 |
|
mpf_float_50 |
1.06817 (17.2475s) |
123749688 |
|
mpf_float_50 (no expression templates |
1 (16.1468s) |
152610085 |
|
mpfr_float_50 |
1.18754 (19.1749s) |
118401290 |
|
mpfr_float_50 (no expression templates |
1.36782 (22.0858s) |
152816346 |
|
static_mpfr_float_50 |
1.04471 (16.8686s) |
113395 |
Table 1.16. Platform Details
|
Version |
|
|---|---|
|
Compiler |
GNU C++ version 10.3.0 |
|
GMP |
6.2.0 |
|
MPFR |
262146 |
|
Boost |
107800 |
|
Run date |
Sep 30 2021 |


MicroPython tutorial for the pyboard¶
This tutorial is intended to get you started with your pyboard. All you need is a pyboard and a micro-USB cable to connect it to your PC. If it is your first time, it is recommended to follow the tutorial through in the order below.
- 1. Introduction to the pyboard
- 2. Running your first script
- 3. Getting a MicroPython REPL prompt
- 4. Turning on LEDs and basic Python concepts
- 5. Switches, callbacks and interrupts
- 6. The accelerometer
- 7. Safe mode and factory reset
- 8. Making the pyboard act as a USB mouse
- 9. The Timers
- 10. Inline assembler
- 11. Power control


A marvellous chrome extension which punishes your victims Facebook statuses if they go afk for too long!
The source code for this extension and download can be found on my Github
Upon installing the extension onto your victim's computer, it will silently run in the background and detect if they are inactive from their computer for more than four minutes (this can be changed).
After four minutes the extension opens up a tab of Facebook, posts a random teapot status and closes the tab as if nothing as happened!
The time counter shall restart after the user has made some activity - this ensures only one status is posted per afk.
I am not responsible for any loss of friends on Facebook, loss of actual friendship, divorce, nuclear war or humiliation caused by the use of this extension.


Baehatrice
Makeup
Graphic Design
Illustration
Others
About & Contact
Baehatrice
Makeup: SHAMAN
1. Native Witch
2. Cold
3. MUDANG
Makeup: Ethnic
1. Genie
2. Pattern
3. Feather
Makeup: Vivid
1. Pink
2. Dream Catcher
3. Black
Graphics: ULCHOO
1. Love
2. Money
3. Diamond
Graphics: Classic
1. Crown
2. Carpet
3. Cigarette
Graphics: Texture
1. Rock
2. Wall
3. Sand
Illustration: Myth&Religion
1. SARASWATI
2. VIRGIN MARY
3. QUETZALCOATL
Illustration: Icon
1. The Raw and the Cooked
2. Dreaming
3. Tsupuoo
Illustration: Characters
1. Zoo
2. Characters
3. MeerCam
1.Spatial Dynamics
1. Dragonfly1
2. Dragonfly2
3. Jellyfish
2.Installation
1. Mangrove
2. Disorder
3. MILAMALA
3.Processing
1. Dream Catcher
2. Mayan Calendar


Financial Regulator in South Korea Close to Classifying Unauthorized Cryptocurrency Exchanges as Illegal Fundraising under New Regulations
“Cryptocurrency exchanges can however apply for authorization to operate, on condition they implement standards and measures for customer protection and enhanced transparency.”
As reported by South Korean daily newspaper Hankyoreh, South Korea’s Financial Services Commission (FSC) is close to completing proposed regulations for cryptocurrency exchanges in the country – a move that will treat all unauthorized cryptocurrency exchanges as illegal fundraising. This move aims to crackdown on the use of cryptocurrencies for money laundering purposes.
Currently, all cryptocurrency exchanges are regarded as Electronic Commerce Transactions under the Act on Consumer Protection, meaning they are deemed an e-commerce website by anyone who registers as an online vendor. Examples of cryptocurrency exchanges in the country include Bithumb, Korbit and Coinone, amongst others.
The South Korean government sees cryptocurrencies as not a financial instrument, but rather a form of unauthorized fundraising. The FSC has previously remarked in September that it will ban all ICOs in the country. It has also actively recommended against the trading of cryptocurrencies. This reported new move to ban all cryptocurrencies exchanges in the country represents its biggest regulatory move yet.
End of cryptocurrencies in South Korea?
With regards to regulations, the answer is no. Despite seeing all cryptocurrency exchanges as illegal by default, exchanges can still apply for authorization to operate. However, to be authorized they will need to proof that they implement standards for consumer protection and be transparent at every stage of a transaction.
A statement from an official at FSC reads as follows:
“Cryptocurrency exchanges will be required to maintain standards for consumer protection, such as having separate deposits for customers’ assets, and for increasing transparency, such as having a procedure for confirming customers’ identity. The authorities will also be empowered to prosecute exchanges that break these rules.”
Another reason why this new move is far from the end of cryptocurrencies in South Korea is because the country is seeing huge interest in virtual currencies despite the conservative stance from its government. South Korea is reportedly the third largest bitcoin exchange market – after Japan and the U.S. – owning approximately eight percent of the global market share.
As reported by Forbes, South Korea is also “home to three of the world’s top five exchange houses for Ethereum, pushing 35-40% of the coin’s global trade.”
Steven Lim, Chief Strategy Officer (CSO) of cryptocurrency exchange Coinone has commented previously on the cryptocurrency fever in the country.
“People are crazed over it. Grandpas and grandmas come to our office lobby and say they want to put half a billion won ($447,000),” he said.
「 Declaration: Please indicate the source if repost the article in UNITIMES. Opinions expressed by Contributors belong to themselves. 」


Nicks Blog Bananza
My Links
My Blogs
About me
Contact Info
Guided Pairing session 1.1
something something


ABBOTT M00-226 Sinusitis Jeopardy!
Protocol
Inclusion/
Exclusion
Compliance
Addenda
Potpourri
$100
$100
$100
$100
$100
$200
$200
$200
$200
$200
$300
$300
$300
$300
$300
$400
$400
$400
$400
$400
$500
$500
$500
$500
$500
Credits...


from {{ elem.date }} in category {{ elem.categorie.name }} {% if elem.group %} by {{ elem.group.name }}{% elif elem.author == user %} by you{% endif %}
from {{ elem.date }} {% if elem.group %} by {{ elem.group.name }}{% elif elem.author == user %} by you{% endif %}
Information: {{ elem.inf.headline }}
from {{ elem.inf.date }} {% if elem.inf.author_is_admin %} by Admin{% elif elem.inf.group %} by {{ elem.inf.group.name }}{% elif elem.inf.author == user %} by you{% endif %}
Comment from {{ elem.date }} {% if elem.group %} by {{ elem.group.name }}{% elif elem.author == user %} by you{% endif %}:
{{ elem.text|linebreaksbr }}
{% endif %}
{% endfor %}
{% else %}
You haven't performed any activities. If you need help click FAQ at the navigation bar.


--- layout: page title: Presentations permalink: /presentations/ extra_css: presentations --- {% for post in site.posts %} {% if post.categories contains 'presentation'%}
{{post.content}}


Card demo
HAX, card demo
Cool stuff. Let's write about spongebob!
Cool stuff. Let's write about spongebob!


Address:123 Business Centre London SW1A 1AA
Phone: + 123 5647 89
Email: [email protected]
Website www.niwax.com
We will catch you as early as we receive the message
We hate spam, and we respect your privacy.


A Primer Into Selenium Automated Testing
A comprehensive Selenum documentation and example blog.
Introduction to Selenium Testing
Selenium was created with the intention to automate UI browser testing.
It contains support for Internet Explorer, Safari, Chrome, Firefox, and a multitude of other browsers. You can find more information directly from the Selenium site:
http://docs.seleniumhq.org/
Challenges this blog will provide solutions for:
- How to test multiple browser sessions simultaneously
- How to test multiple platforms simultaneously
- How to report test results
- How to create a framework and test library that my coworkers can use
- How to implement basic “expected” functionality of an automated test suite
Practical Application of Selenium’s Framework
Selenium itself is a very powerful tool, containing very few moving pieces. However, the solution to automated UI testing does not solely rely on Selenium. Rather, it combines many tools and frameworks to create an automation orchestration.
I plan on introducing each piece of my particular solution as separate posts in this blog and include code samples that will help you along your automated test journey.
Depth of Knowledge
In this blog, I will be covering the use of tools and frameworks that I have discovered in the short time that I have used Selenium. We will go over the basics of each tool and how it applies to Selenium.
Some topics that will be discussed include:
- Maven project lifecycle (dependency management, test execution, and reporting)
- JUnit (test running, test organization)
- Intermediate Java programming
- Continuous build/integration systems


Change the encryption keys at least once a year.
Changing encryption keys periodically makes it more difficult for an attacker to get access to a valid key.
Add a requirement to change the encryption at least annually to the information security policy as a part of the key management procedures. Change the encryption keys at least once a year.


Looks like the network is bad, try later ;).
Unexpected error! We are going to fix it soon!
Cars
No connected car. {{ year }} is calling ;).
Looks like the network is bad, try later ;).
This user already exists!
Unexpected error! We are going to fix it soon!
{{car.contents.name}}
{{car.contents.brand}} {{car.contents.model}}
Connect
Add one with Xee™
Discover Xee™


CMS MessageLogger: Open Issues Concerning Features Wanted by CMS
CMS MessageLogger Service
Open Issues Concerning Features Wanted by CMS
Multiple Message Categories
The requirement
A message can be issued with multiple categoriess, as in
edm::LogWarning(tracking&overflow) << "some more text";
This is to be treated as both a category=tracking message,
and an category=overflow
message.
Questions
What does it mean to be two types of message. The easiest thing to do would
be to issue two distinct messages but assumedly that is not the most desirable
behavior. The questions include:
- How should the output message look? (We implied that just including the
combined categories as the ID would be OK.)
- Which destinations should react to this message? (Probably destinations
that would react to either of the combined categories.)
- What should this do to the message counts for each category
for each destination?
- How is this treated for statistics? (Probably one message of each type;
but the first-two, last-one contexts might want to behave specially.)
Proposed treatment
When a message is issued
edm::LogWarning(tracking&overflow) << "some more text";
message counts for both "tracking" and "overflow" ID's are incremented.
If a given destination would react to either a "tracking" message
or an "overflow" message, it will react to this message, but only a single
copy of the message output will appear.
In that message output, the category will look like tracking&overflow,
and even if
the combined length is longer than the normally permitted length the full
combined categoriess will appear.
Statistics destinations will note the appearance of one "tracking" message
and one "overflow" message; thus the total of counts by message ID will no
longer match the total of counts by severity. The context (of the first
two and last one of each type of message) kept by the statistics destination
will react as it would to a single message of each of the categories. Thus it
is possible to have the same context (event number or whatever) noted twice
(in two different categories) caused by this one error message.
Work consequences
The "issue the message twice" attitude would require no work on ErrorLogger
internals, and routine work in the LogXYZ() functions. However, that is not
the desired behavior.
The above proposal will require modifying the nature of a message ID within
ErrorLogger. At some points it is a potentially compound ID; at others (for
example, in the limit maps and statistics maps) it is exactly as before.
This is non-trivial, as the messageID penetrates much of the package, but
as long as the behavior to shoot for is well-defined, this appears to be a
solvable task.
Decision and Plan
The proposed treatment described above is agreed upon.
In order that the user be able to use the multiple-category syntax as soon as
possible, we will temporarily implement the double-message treatment.
Destination Reporting to log4cplus
The requirement
We need a destination which, rather than sending to a file or ostream,
delivers the header and text of the message to the CMS log4cplus facility.
Questions
What do we do to use log4cplus, and what options does it have:
- Should we have a default destination of log4cplus, so that the user gets it
even without mention in the .cfg file?
- Is it mature enough to just use, or do we check out the package (and
if so, can we make needed tweaks)?
- What choices (if any) should we make if there are options in how to use
log4cplus?
- Are there any options which we should leave to the user via the .cfg file?
Proposed treatment
-
We create a ELlog4cplus destination class which reports to log4cplus.
This is similar to ELoutput, but probably formats the header and remainder
of the message separately.
-
We attach an ELlog4cplus destination always.
-
We provide a special named destination parameter "log4cplus" by which a user
can control filtering of messages to that destination.
-
We are told by CMS which log4cplus options to use, and we do not provide
further flexibility from the .cfg file for the user changing those options.
Work consequences
There are three potentially significant areas of work:
- Understanding how to use log4cplus may be easy (especially if the
product is mature and well documented) or arbitrarily hard. We can give no
estimate on how long this will take until we try it out.
- Creating the ELlog4cplus destination will be some non-trivial but
fixed amount of semi-routine work, since it is done with some knowledge of
how ELoutput works.
- Providing the parameters to control flexibility will take about half a day
per parameter, once we know what sort of .cfg control (if any) is needed by CMS.
Decision and Plan
Instead of the proposed treatment, we have created a
MLlog4cplus service which ensures that
an ELlog4cplus destination is attached to the logger. This has the
advantage of cutting any dependencies of MessageLogger on log4cplus (which is
in xdaq).
The log4cplus capability is as of 12/23/05 in place and tested. It is up to
the user to deal with log4cplus, in particular, to assign whatever appenders
are needed for the job.
Two temporary conditions are left:
-
We currently assign a file_appender writing to log4cplus.output whenever
the MLlog4cplus service is specified in the .cfg file; it is
probable that CMS will want to change this default action.
-
We have not yet done the work to allow the user to control, via the .cfg file,
MessageLogger filtering of the ELlog4cplus destination.
Probing for whether a message will be reported
The requirement
User code may sometimes generate messages which under many circumstances would
be ignored by all destinations. It would be desirable to be able to quickly
probe whether any destination would respond to a given message severity
and category, so that the work of preparing and formating the message items
can be skipped if appropriate.
There are two potential modes of usage for this capability. The naive mode is
to do the probe each time a message is to be prepared. Another mode is to
assume that the result of this probe will remain static, and to cache either
the first result or the first negative result. In that mode, a message
which would be ignored will cost only one conditional on the cached boolean.
Questions
Should we also try to automate this checking, to avoid the cost of the
operator << when the user appends items to the line to log a message?
Since the cost of a probe will not be trivial, should we cache results and
consider the probe of each message type to be a one-shot affair?
That is,
if you have learned whether this type of message is reported,
should we assume that this answer will not change.
This is not strictly true because of limits, but it may be a useful shortcut.
Proposed treatment
Create 4 new functions:
ProbeLogError (const std::string & category);
ProbeLogWarning (const std::string & category);
ProbeLogInfo (const std::string & category);
ProbeLogDebug (const std::string & category);
These would return true if any destination would respond to the
corresponding message.
The first time a message type is probed, we must issue some sort of special
two-phase command to the MessageLoggerScribe, and it must cause an actual check
useing ErrorLogger code.
Once a message type has been probed in this way, the answer will be cached.
We should implement this cache via a map
(in the local thread, to avoid the complications of locking against new
entries by other threads) of all messages already probed.
When the same message type is probed again, the map is consulted.
In order that we eventually get the efficiency of rapidly ignoring
which were previously reported but
have reached their limit, when a true result is found in the map,
one time in about twenty we should re-check.
We can
automate the check of the cached map to occur
whenever messages are issued. (The user still has the option of probing
to avoid work to prepare the items to be added to the message.)
The rules would be:
-
If a message has never been probed, the LogXYZ commands always send that
message along to the ErrorLogger.
-
If a message has ever been probed and found not to be reportable,
then the result of a probe (automatic or explicit) will be that the
message is not reportable. For unreportable messages,
operator << to the results of the LogXYZ commands become no-ops.
-
Every 11-th time the cache of results is used and delivers true,
that message is re-probed in case it is now being ignored. This interval
increases via an exponential backoff.
-
If a message has been probed and found to be reportable (either by the cache
or by a new actual probe),
then LogXYZ will send that message along to the ErrorLogger.
However, we can check the local map:
if a message has already been probed and found to be ignored,
then the operator << can become a no-op.
This presents another mode of usage, one which we can recommend:
The user probes a message category
just once, and relies on the system to obviate extra work by automatically
checking when appropriate.
We do have to warn about the effect of this on message statistics:
Messaages which are sent to the logger but ignored make it into the statistics,
but messages which are never even sent do not. (Assumedly, the user would
not care about the count of messages in categories which are completely
ignored.)
Quick temporary treatment
We can quickly implement the propbe functions as returning true, thus
allowing user code to start using this mechanism (with no efficiency gain
until we implement the actual probing) immediately.
This treatment is now in place.
Work consequences
The ErrorLogger currently has no means of probing for responding destinations.
This will need to be created. The difficulty should be moderate (time estimate
of 1 day).
The MessageLoggerScribe will need a new opcode to do the probe. The probe
data structure would be a pointer to one integer (not a bool, because the
probing end has to know when the result is now valid). The probe routine
(on the client side) will need to either sleep on that value changing, or
otherwise wait till the true/false value is established. This is not as
easy as the other part, but probably will take another 1 day.
The establishment of the cache will be easy,
but the re-writes of LogWarning etc. to take
advantage of known non-response results will be subtle.
In particular, the LogDebug macro may be very subtle if we don't want
to take the cost of forming and passing __FILE__ and __LINE__ when we don't
have to.
The total time estimate for this feature is three solid days.
Statistics Destination
The requirement
The ErrorLogger has a nice ELstatistics destination for summarizing
the messages.
We need a way for MessageLogger service users to to specify a
statistics destination.
Questions
- Should we let the .cfg file specify where statistics are to be sent,
or have some default destination?
- What should trigger the reporting of statistics? (For example, it could
be part of the end-of-job or end-of-run activity of the MessageLogger
service.)
- How should we obtain the "short context" to report the contexts of the
first two and last one of each type of message -- or should we punt that
feature?
Proposed treatment
-
We treat the statistics destinations analogously to the output destinations,
allowing the user to provide a list. This allows the user to control those
features of the statistics destinations (including threshold and output control)
which are needed.
-
By default, we create a single statistics destination sending its output to
the first of the output destinations (or to the log4cplus destination).
-
The issue of context is solvable (we can obtain the event number, for example)
but it is an open issue as to how we would do this. For a start, we could
disable the noting of contexts.
Work consequences
Other than the context issue, we can probably set up statistics in a day.
Other Filtering Options
The requirement
The ErrorLogger package supplies
other ways to specify limits and thresholds on which messages a destination will
report. For instance, one can set a limit for all message IDs except
a specified type.
The MessageLogger service might benefit from enabling some of these further
options via the configuration file.
This requirement may or may not finally be requested.
Questions
- Do we want exclusion limits?
- Do we want rapid-discard thresholds?
- Other flexibility (see the
ZOOM ErrorLogger documentation for possibilities)?
Proposed treatment
Additional parameters in the .cfg file, either destination-specific lines
within the destination PSet, or general lines within the service=MessageLogger
PSet.
Work consequences
Requires no modifications to the ErrorLogger package.
However, each degree of flexibility will require code in MessageLoggerScribe
to understand the parameter and issue appropriate calls to the ErrorLogger.
Also, each feature requires CMS MessageLogger service documentation (otherwise
it is next to useless). The total time to enable a feature is about half a day.
Context (e.g., event number) in Messages
The requirement
The ErrorLogger package supplies
ways to automatically append context information to messages. The intent
is to indicate event/run numbers without the message issuer having to think
about it. Perhaps the MessageLogger service should support this.
This requirement may or may not finally be requested.
Questions
What should we use as the context?
- How do we obtain the context (error number or whatever)?
- Is there a useful abbreviated form?
- Does getting the context take too much time?
Proposed treatment
We find out how to get context from an existing EDM service, and write a
context supplier (in the ErrorLogger sense) to do so). We propose that the
format of the context not be user configurable.
Work consequences
Requires no modifications to the ErrorLogger package.
Writing the context supplier is likely to take less than a day, assuming the
info is available from the EDM.
Support For Use Of endl in Messages
The requirement
Users are used to using std::endl as a line terminator.
The use of \n is already supported for this, but it might be
desirable to also support endl.
This requirement may or may not finally be requested.
Questions
Is endl any different in effect than \n?
Proposed treatment
The ErrorLogger package implementers originally attempted use std::endl
as a message terminator.
This led to technical difficulties we could not, at that time, surmount
(thus the introduction of the errmsg manipulator.
Jim Kowalkowski and Marc Paterno claim they know how to do this without
those difficulties. If so, we will adapt that technique, treating endl as
a "force line termination" directive (as opposed to a message terminator).
If this is not easy, we should not do it, as the gain is slight.
Work consequences
Requires learning how to handle endl, and implementing that in ELoutput
and other destinations. The danger is that the problem issues may be subtle, in
which case it is best to abandon the idea.
Multi-statement Building of Message Objects
The requirement
In the ErrorLogger package, the user can gradually build an ErrorObj containing
th message, and later dispatch it ot the logger. A similar capability
might be desirable in the MessageLogger service.
This requirement may or may not finally be requested.
Questions
-
What is the best way do instantiate the object?
-
How should the message be fired off to the log?
Proposed treatment
The ErrorObj in the ErrorLogger package already has its severity and ID imbedded
upon construction, and we propose to do the same here.
We would provide 3 classes (the Debug form has complications we choose not to
deal with: InfoMessage, WarningMessage, and ErrorMessage. The ctor would take
the message ID.
The user community would probably vote for some sort of send() member function
or special endmsg manipulator to indicate that the message is to be dispatched,
but this leaves around a dangerously already-sent message object. The correct
idiom is to dispatch the message when the object is destructed. The user code
should look like:
if ( problem_is_detected ) {
WarningMessage warn ("thistypeoftrouble");
warn << "information is";
while (there_is_more_information) {
warn << get_a_piece_of_information();
}
} // here warn goes out of scope and the message is dispatched
Work consequences
This would be straightforward since no ErrorLogger code need be modified.
Including documentation it should take a couple of days.
Post-configuration Control of Logging Behavior
The requirement
The current service allows control of the behavior of destinations (filtering
and thresholds) and the overall logger, only via job-start configuration
parameters found in the .cfg file.
We could also support modification of these choices under programmatic control.
This requirement may or may not finally be requested.
Questions
-
What degree of control should we support?
-
What is the syntax of the code controlling logging behavior?
Proposed treatment
We immediately step onto a slippery slope (more like, step off a steep cliff)
when we open up the idea of runtime control of these options.
Developing an interface for this control would take weeks at the least, and
there would inevitably be arguments over all the equally-good ways of expressing
the desired behavior.
The only sensible answers are to provide no post-configuration control at all,
or to provide everything in the ErrorLogger package. In the latter case, the
capability is provided by having the service provide points or references to
the actual ErrorLogger package objects, such as ELadministrator and the various
ELdestControl handles. The user would need to look in the ErrorLogger package
documentation for how to use these.
Work consequences
If we can stick to our guns about just providing handles to raw ErrorLogger
objects, this should not be too hard. There may be a bit of work in developing
an interface to get the ELdestControl for a given destination, but we
probably already have the structures in place for that.
If we need to develop a separate CMS-approved interface for post-configuration
adjustment of behavior, this will be a hopeless and endless task.
USCMS Software and Computing Home Page -
CMS MessageLogger Service Page
Mark Fischler
Last modified: December 1, 2005


gate.alignment.gui.actions.impl
Classes
AbstractAlignmentAction
AlignAction
AlignmentCache
FeatureTransferrerAction
RemoveAlignmentAction
ResetAction