XForms-Transitional Testbed - expense claim form

This is part of a series of cross-platform experiments in incremental extensions to HTML4 forms that provide a stepping stone towards the much richer capabilities in XForms. This experiment provides an example of an expenses claim form for different currencies. Try filling out several amounts in the final column and then press submit. This will highlight the missing required fields in red along with the corresponding column headers. Note that the headers only clear when all of the missing fields in that column have been filled out.


Expenses incurred in other currencies


The source code for the above form is:

<form id="form1" name="form1">
<p><label for="employee_name">Employee name</label>
<input id="employee_name" name="employee_name" />
<label for="employee_number">Employee number</label>
<input id="employee_number" name="employee_number" /></p>

<p><label for="rationale">Please describe the reason for the
expenses, e.g. destination and purpose for a business trip</label><br />
<textarea id="rationale" name="rationale"></textarea></p>

<fieldset class="expenses" name="expenses" repeat-number="14">
<legend>Expenses incurred in other currencies</legend>
<label for="receipt">Receipt<br />number</label>
<label for="date">Date</label>
<label for="description">Description</label>
<label for="category">Category</label>
<label for="currency">Code</label>
<label for="rate">Rate</label>
<label for="amount">Amount</label>
<input name="receipt" datatype="number" size="4"
  title="number on paper copy of receipt"/>
<input name="date" datatype="date" size="18"
 title="date incurred" needed="defined(amount)"/>
<input name="description" size="30" title="reason for expense"
<select name="category" needed="defined(amount)"
 title="for tracking and calculation of sales tax">
<option value=""></option>
<option value="miles">Miles</option>
<option value="travel">Taxi amp;amp; Travel</option>
<option value="parking">Parking</option>
<option value="hotel">Hotel</option>
<option value="meals">Meals</option>
<option value="mobile">Mobile</option>
<option value="mobirental">Mobile Rental</option>
<option value="homephone">Home Phone</option>
<option value="books">Books</option>
<option value="postage">Postage</option>
<option value="other">Other</option>
<input name="currency" size="3" title="currency code"/>
<input name="rate" datatype="number" size="10" title="exchange rate"/>
<input name="amount" datatype="number" size="10" title="amount claimed"/>

<p><label for="sheet">Sheet number</label>
<input id="sheet" name="sheet" readonly="readonly"/>
<label for="total">Total claimed</label>
<input id="total" name="total" datatype="number" readonly="readonly"
 calculate="sumover(expenses, amount/(rate?rate:1))"/>
<button type="submit">Submit</button>
<button type="reset">Reset</button></p>


This is something most commonly encountered as a spreadsheet. An online web-based version would help to reduce the errors often encountered in submitting paper copies of spreadsheets. In principle, a web-based editing tool should also be cheaper to use than conventional spreadsheets which rapidly become complex and costly to maintain.

This form assumes 1.0 if the exchange rate is left blank. This is expressed as follows using the JavaScript conditional operator to test if the rate is defined and provide the appropriate value:

<input id="total" name="total" datatype="number"
 calculate="sumover(expenses, amount/(rate?rate:1))"/>

This is convenient for entries in your own currency. That might for instance be the case when claiming for hotel bills where your credit card statement tells you exactly what you were charged in your own currency. For cash payments in another currency, it would be helpful if you could enter the exchange rate once. This suggests that the default rate should depend on the currency code, and that that there needs to be separate fields to set the default exchange rates for different currencies.

Accountants may want to see the amount charged in the original currency as well as the amount claimed in your own currency. This necessitates adding a new column. If you choose to enter the own currency amount, this should override the value computed from the default exchange rate. This necessitates distinguishing computed values from manually entered ones. Having done this, it should also be possible for the default exchange rates to appear and be overrideable in exactly the same manner.

At first glance, this appears to introduce cyclic dependences. The exchange rate depends on the amounts in the local and non-local currency, whilst the local amount depends on the non-local amount and the exchange rate. This cycle is broken if we treat the manually entered value and the computed values as being different fields. Quite how to do this elegantly will be an interesting challenge!

For additional comments please see the own currency expense claim example

Dave Raggett <dsr@w3.org>