DualCalc > Detailed Help

(Page last updated:  12th November 2006)

Important Notes:

It is important that you read through the guidance here carefully before using the program.  It is equally important that you understand the figures to be used in a calculation (ie what should be included or excluded and what assumptions should be made).  Obviously, if you describe a loan incorrectly or put the wrong figures into a calculation, the calculator will not give you the correct statutory answer.

Remember that all the repayments due under a loan must be entered into the calculator for both APR and rebate calculations - for rebate calculations this includes the payments due after the borrower settles.  You may have to make certain assumptions about payments due in the future and these will be governed by the Total Charge for Credit, Rebate on Early Settlement, Settlement Information, Early Settlement, Advertisements or Agreements Regulations.

Please also remember that the figures used to calculate the APR for a loan will not necessarily be the same as those used to calculate the rebate due under it, you may, for example, have to amend the repayment amounts because of changes in interest rates or exclude certain payments or charges.

Additionally, the APR used in an Actuarial Rule rebate calculation will not necessarily be the same as the result you got using the program to calculate the agreement's APR, nor will it necessarily be the rate shown in the agreement or advertisements for the agreement (click here for more information).

See the Office's FAQs on the Regulations in question for detailed guidance.

• DualCalc help
  
  
• different modes
• describing loans
• 'single' loans
• 'simple' loans
• 'complex' loans
• combining methods
• using panels
• 'VCR' controls
• tidying panels
• editing panels
• resetting the calculator
• what are levels?
• what are extras?
• what are advances?
• what are series?
• entering amounts
• entering times and dates
• describing early settlement
• so what does the actuarial formula do?
• checking input
• saving and loading calculations
• doing calculations
• calculation results
• comparing results
• logging calculations
• program options
• calculation analysis
• viewing logs
• printing calculations
• additional tools
• closing the program

Starting the program ...

When you start DualCalc its main dialogue should normally appear straight away:  [click here for the dialogue].

However, you might receive one or more messages before this:

'Another copy/other copies of DualCalc are running':  this isn't a problem, you are allowed to run several copies, although it might sometimes cause minor difficulties.  This is just a warning in case you'd forgotten that you'd already run a copy or it's hiding behind something else (if you get this when you know they're aren't other copies running [see here]).

'This seems to be the wrong type of options file!':  it looks like the file containing your option for how DualCalc is setup has been corrupted.  This isn't too serious, just [reset and save your preferred options].

'This seems to be the wrong type of tools file!':  it looks like the file containing details of your add-in tools has been corrupted.  Unfortunately you will have to re-write it manually or re-install the tools' .add files [see here for more details].

'The .add file '{something}' seems to be the wrong type!':  DualCalc has found an .add file in its 'Tools' folder and is trying to use it to add a tool to the list of those available, but there is something wrong with the file [see here for more details].

'I can't find the file for the tool: {something}... it will be deleted from your toolset.':  DualCalc has found that one (or more) of the programs in the list of available add-in tools has gone missing.  This could be normal, if you intentionally delete a tool this is how DualCalc corrects your list of those available.  If this is not the case you will have to re-install it [see here for more details].

Different 'Modes'

The calculator operates in several modes in which it does different things and looks slightly different on screen.  For example, in one mode it calculates APRs and another it calculates rebates and, when dealing with rebates, some extra boxes used to provide information about the rebate calculation required are available on screen - for APR calculations these boxes are 'greyed out'.

The modes are controlled by some of the buttons on the right of the dialogue which toggle or cycle between two or three settings.  These buttons also indicate the current mode, rather than what they do when you click on them.  To remind you of this, the text on them is in square or curly brackets.  So, for example, if the APR/Rebate mode button is labelled [APR] the calculator is currently set to do APR calculations and clicking on it will switch the calculator to Rebate calculations and the button to [Rebate].  Curly brackets are used where the button cycles betwen several modes.

The modes available are:

Describing Loans

Basically a loan is a series of sums of money changing hands between the borrower and lender - an accountant might call them 'cash flows'.  Typically there's one cash flow from the lender to borrower (the loan) followed by a series of cash flows back from borrower to lender (the repayments).  Sometimes there will be several advances of credit from lender to borrower, this is less common but the program can deal with it.

Your job is to describe these cash flows to the program by telling it how much they are (in pounds sterling) and when they are made (in 'time periods').

As mentioned in the table above, the program provides three modes for describing Single, Simple and Complex loans. In fact you could use the Complex mode for all loans, the calculator just removes the distraction of unnecessary boxes in the dialogue.

'Single' Loans

Single loans are those where there is basically one advance and one repayment of credit, although the program also allows you to enter a repayment at the start of the loan to deal with things like up-front fees or down-payments.

Please note that all amounts should be given in pounds and the time of the repayment can be given either as a date (after the 'relevant date') or in periods (eg weeks or months).

Typical examples of single-repayments loans would be things like pawnbroking or cheque-cashing agreements.

You can provide figures for the following amounts in the boxes at the top-left of the dialogue:

The amount and time of the repayment is dealt with as an 'extra repayment' Click here for more details

'Simple' Loans

Most loans are quite straightforward with a sequence of regular, equal repayments as their basis, and you can use the Simple mode to describe them.  In this mode the headings to the two left-hand columns in the dialogue are 'Regular £' and Number, indicating the amount and number of the Regular repayments.

All amounts should be given in pounds and, as far as timing is concerned, in simple loans the program assumes that times are measured in the 'Periods in a year' you select (eg weeks or months - if you choose 'Years&days' you are, in effect, telling the program the repayments are annual).

The first Regular repayment is assumed to be made one time period (eg week, month or year) after the start of the loan and subsequent ones at one period intervals.  So, if 'Periods in a year' is set to Months and the 'Number' of regular payments is set to 12, they are assumed to be made 1, 2, 3 ... 10, 11 and 12 months after the 'relevant date'.

Typical examples of simple loans would be things like straightforward in-store credit to buy a dishwasher or television or an HP deal on a car, but sometimes these types of loans require a more complex calculation.

You can provide figures for the following amounts in the boxes at the top-left of the dialogue:

The amount and number of regular repayments are dealt with as a repayment 'level' Click here for more details

'Complex' Loans

For more complex loans the program provides a number of methods for describe the amounts and times of repayments and advances in addition to those at the top of the dialogue.  The names used for these methods are peculiar to this and the earlier credit calculators:  they have very specific meanings here, but you will probably not find them used generally by consumers or the credit industry and they do not appear in the Regulations.

The complex method is intended to deal with any type of loan.

The table below gives a brief description of these methods, click on the links in the left-hand column for more details:

Combining Methods

It is important to stress that you can use these methods in combination.  If you describe a loan as having two levels and three extra payments they will all be included in the calculation.  This is intended to give you the maximum flexibility in describing loans.

In general, if you're faced with a complex loan you can describe several ways, the rule is to use levels if you can (easy to enter and easy for the program to deal with), then where they won't work, think about using 'Series' (harder for the program but still easy to enter) and only enter 'Extras' yourself as a last resort where there's no pattern to the payments at all.

Similarly both the 'Loan' and any advances are taken into account, but you have, and are likely to need, less choice here.

Using 'Panels'

Apart from Series (see later) things we've called 'panels' are used to describe more complex loans, for example the two columns of boxes in the image below, used to enter Levels, are referred to as the 'Levels Panel'.  There are of course similar panels for 'Extras' and 'Advances'.

A Panel displays 10 rows of information - initially the first 10 Levels, Extras or Advances.  However there are generally more than 10 rows available to enter information - by default there are enough rows for 250 Levels, 2,500 Extras and 50 Advances, but these can be changed by clicking on the 'Options' button.

Note:  the numbers down the left-hand side of each panel indicate the rows currently displayed.  They are only there so you can keep track of where you are in the panel, these numbers have no particular significance for the amounts, number or times of the payments they are describing - although the order in which Levels are entered is significant.

'VCR' Controls

You can use the 'VCR' (video cassette recorder) type controls underneath each panel to display further rows.

The buttons act slightly differently depending on the number of rows available in the panel.  In its default setting, if there are 200 rows or less, the outer buttons in the VCR controls are labelled ||< and >|| and take you to the beginning or end of the available rows.  Where there are more than 200 available, the outer buttons are labelled << and >> and take you backward or forward 100 rows.

The inner buttons (< and >) step you backward or forward 10 rows, so they simply move the panel back or on to the next set of rows.

Holding down the Shift key when you click on the button will increase the steps by a factor of five (ie 500 rows for the outer buttons and 50 rows for the inner buttons).  This should enable you to locate a required rows quite quickly, even if there are thousands of rows.

The VCR controls will also 'wrap around' the available rows', taking you to the end if you go back from the start or to the start if you forward from the end.

Additionally, the panels will always 'stop off' at the first and last set of rows, so if you use << or >> from a point which would take you beyond the start or end, you arrive at the start or end instead.

Tidying Panels

Although it's logical to do so, you are not restricted to always filling in the next vacant row in a panel - you could, if you wanted to, describe a loan with two levels by putting the first one in row 10 and the second in row 193.  However, the program needs things done a little more neatly so, when you start a calculation, or use some of the other facilities in the program, it will 'tidy' the panels for you, moving the contents of the rows upward and closing up any gaps.  It will also remove:

any Levels rows where the length is blank or Zero, even if an amount has been entered

any Extras or Advances rows where the amount of the payment is blank or Zero, even if a time or date has been entered

... because a Level with no payments in it, or an Extra or Advance of nothing, are 'non-events' which can have no effect on the results of the calculation.  There is also a separate tool available to delete blocks of rows (see here for information on tools).

Remember that Levels of amount Zero are valid (they represent periods where no payments were made but affect the timing of subsequent levels) and Extras or Advances with a Time/Date of Zero are also valid - they are simply payments which happen right at the start of the loan.

You can also tidy up the panels yourself at any time by clicking on the 'Tidy' button.

When tidying the panels the program usually also checks that all the data currently displayed in the dialogue is valid before making a note of it - see 'Checking Input' for more information.

Note:  when it tidies the panels it sets them to display the next available blank entry.  If there happen to be an exact multiple of 10 rows used in the panel, you will be presented with the next 10 (all blank) rows, but this doesn't mean all your entries have disappeared, they are just in the earlier rows.  More often you will find that there is something in the first few rows of the panels displayed after a 'Tidy'.

Editing Panels

For levels, the order in which payments appear in the rows is significant for their timing - the levels are assumed to occur in the order the appear in the rows.  You might want to amend the levels information by inserting an additional row to put a level in the right place.  The program provides a series of insert buttons marked '<-' down the right-hand side of the Levels panel to allow you to do this.  The row next to the button you click on, and all the rows below it, will be moved down one to make room for your new level.

If there is already information in the last Levels row available, you will be warned that it will be lost.

For Extras and Advances, because you describe the amount AND time at which they are made, the row or order they are in isn't important, but an extra or advance of amount Zero is a 'non-event' and will also be ignored and deleted from the panel by 'Tidy'.  If you want them to appear in a logical order, e.g. in your final log or printout of a calculation (e.g. time/date order, or the largest advance first) you should enter them in that order.

Whenever it has to store the information you have entered (eg when you start a calculation or change a panel with the VCR controls), the program checks the data you have entered in the dialogue, so you may get a warning that something 'invalid' has been found.  All the data in the dialogue is checked and it will not necessarily be something in the panel you are currently editing which has caused the problem - look for an entry marked 'INVALID=> (click here for more information on checking entries)'.

If all the entries are okay, the information is stored in memory and the panel whose VCR control you have used is updated with new row numbers and filled with the data for those rows currently held in memory.

The panels are not automatically tidied when you use the VCR controls in case, eg, you deliberately left gaps to fill later.

Resetting the Calculator

If you want to start an entirely new calculation, or you've messed up describing the loan and want to start again, you can use the 'Reset' button to clear everything out of the dialogue and put it back to its starting state.

You will be asked to confirm that you want to wipe everything out before the program goes ahead.

Resetting the calculator does not alter the current settings for the mode buttons or the selections in the drop-down (combo) boxes.

What are 'Levels'?

A Level is a series of repayments similar to regular repayments but a loan can have several levels one after another.  The first repayment in the first level is assumed to be made one time period (e.g. week or month) after the start of the loan and subsequent ones at one period intervals.  The first repayment in subsequent levels are assumed to be made one period after the last one in the previous level.

So, if a loan had 12 repayments of £100 followed by 36 of £85 and a further 12 of £120, this could be described as 3 levels:

In the program, the first level is assumed to start at the start of the loan and subsequent levels start when the previous level ends.  The first repayment in a level is assumed to be made one period after the start of the level.  This might seem a bit confusing at first, but it makes the length of the level in periods and the number of repayments in a level the same - the program in fact uses the term 'Length' for the number of repayments in a level.

If there are any breaks in the regular pattern of repayments described using levels, you must enter them as a level of Zero amount.  If there is a delay before the first repayment in a pattern of levels is made, you should also enter this as a level of Zero amount, but its length will be one less than the delay.  For example, if a loan has 36 monthly repayments but 'nothing to pay for six months' you could enter this as two levels, a Zero level of length 5 and a second level of length 36 - it might help to remember that a loan without a delay could be described as 'nothing to pay for one month'.

Levels cannot be used to describe the dates of payments, they will only work in time periods.  A level can only have a whole number of repayments (e.g. not 12.5) and must have more than zero - if you set the number of payments to zero the level will actually be ignored and deleted from the dialogue before the calculation is carried out.

They are called levels because of the way they look in diagrams like this, sometimes used to describe a loan's repayments:

          Amount ^
       (£) |
                 |
                 |
              40 +                           |-x-x-x
                 |                           |     |
              30 +           |-x-x-x-x-x-x-x-x     |
              25 +-x-x-x-x-x-x               |     |
              20 +           |               |     |-x-x-x-x-x-x
                 |           |               |     |           |
                 |           |               |     |           |
                 |           |               |     |           |
                -+-----------+---------------+-----+-----------+-> time
                             6              14    17          23 (periods)

... here '-' represents the period leading up to a repayment and 'x' represent the repayment being made.  If you initially find the idea of 'Levels' confusing and are not sure how to apply them to a loan, it might help to jot down something like this.  This diagram describes a case where there are 6 repayments of £25, then 8 repayments of £30, then 3 repayments of £40 and, finally, 6 repayments of £20.  Note that the repayments in the first level occur at times 1 to 6 and the subsequent levels start where the previous one ends, so the second has payments at times 7 to 14 and so on.

Click here for information on entering amounts
Click here for information on entering lengths

What are 'Extras'?

Extras (extra repayments) are individual repayments of any given amount at any given time which are 'extra' to those (if any) described in Initial sum/Deposit, Final sum and Levels.  Extras are described by their amount and the time or date on which they are made

The name 'Extras' is perhaps a little confusing but comes from the old DOS programs and is based on the fact that you can usually describe most of a loan using Levels, so these are 'extra' to those repayments.  However you can, and sometimes have to, describe a loan using only Extras.  The term 'other repayments' or 'Others' has also been used for these in the past.

You could picture extra repayments as single x's in the diagram above

Click here for information on entering amounts
Click here for information on entering times and dates

What are 'Advances'?

Advances (or 'extra advances') are individual advances by the lender to the borrower of any given amount at any given time in addition to that described in a Loan/Cash price.  Advances are described by their amount and the time or date on which they are made

You do not have to describe the first or only advance in an agreement as a Loan/Cash price, you can use an advance in a complex calculation instead.

Click here for information on entering amounts
Click here for information on entering times and dates

What are 'Series'?

A Series is a sequence of repayments which is more flexible than Levels.  It allows for repayments which are regular but don't necessarily start at a particular time, can have intervals longer than one period or month between the repayments and aren't necessarily all the same amount.

In older programs a series was entered as a third set of repayment data in response to a series of prompts, like Levels or Extras, however most users seemed to find this confusing and some mistakenly entered the same payments as both Levels and Series.  In DualCalc the 'Series' button opens another dialogue which you can use to describe the series, and then write the repayments into the panels as Extras or Advances, hopefully this will be less confusing because there is no longer a separate set of details in which the user can duplicate payments.

The 'Series' button is only available in Complex calculation mode, when you click on it the program first checks the data in the dialogue (so you may get a message about 'invalid' entries) and then tidies the panels.  It does this because it needs to know that all the data you have entered so far is okay to be saved in memory and then work out where it can start inserting new extras or advances in the rows.

Once it's done this, you should see this dialogue:

The amounts of the repayments in a series can be entered here, or they can be left blank.

The timing of the repayments in a Series is described by:

• the time or date of the first payment
• the number of repayments
• the interval between repayments, in periods

You can select the 'interval units' to be 'Periods', 'Months', 'By date' or 'Days'.  The days option was introduced from version 1.01a of DualCalc, and the by dates option from version 1.03.

The 'Months' option is provided to deal with loans which have regular monthly repayments which are to be entered as dates.  In this mode the payments inserted will be on the same day of the month as the start date you entered, unless that day is the end of the month, in which case the end of the month will be for each date instead.

The 'By date' option also deals with monthly periods but treats the end date slightly differently in that it always uses the same date as the start date, enless that date is beyond the end of the month.  So, for example, is the start date is 29/02/2004, 'Months' will detect that this is the last day of the month and produce payment dates of:  31/03/2004, 30/04/2004, 31/05/2004, 30/06/2004, 31/07/2004, 31/08/2004, 30/09/2004, 31/10/2004, 30/11/2004, 31/12/2004, 31/01/2005, 28/01/2005 ... etc. whereas 'By dates' will produce:  29/03/2004, 29/04/2004, 29/05/2004, 29/06/2004, 29/07/2004, 29/08/2004, 29/09/2004, 29/10/2004, 29/11/2004, 29/12/2004, 29/01/2005, 28/01/2005 ... etc.

Note:  the 'By date' method is how DulCalc operated when 'Months' was selected prior to version 1.03.  This has been modified to conform to the Office's view on how to interpret months [click here for more information] and the 'By date' option introduced to deal with cases where the repayments are, for example, on the 28th of each moonth starting in February - which one you use depends on the pattern of payments you want to enter.

The 'Days' option is provided to deal with loans which have weekly, fortnightly etc payments but you still need to enter the times of the payments as dates.  An oversight in earlier versions of the program meant that you could only deal with most actuarial calculations for weekly agreements by entering all the dates manually.  Note:  we have opted for 'days' here because, in addition to allowing you to enter the payment interval as 7 for weekly payments, 14 for fortnightly and so on, it will also deal with less common, non-weekly intervals - eg, a payment every 30 days.

Once you have set the values for your series you can use the [Extras]/[Advances] to select which you want to enter and the 'OK =>' button to insert the series of payments you have described into the Extras or Advances Panels.  If you have left the payment amount blank, you will then have to enter the individual amounts of each of the payments, if you don't they will all be ignored and deleted from the panel when it is next tidied.

Remember, if ALL the payments are the same (or perhaps only a few are different), it will be much easier to enter an amount in the Series entry dialogue.  Any different ones can be changed afterwards.  If there are a lot of different payments in an agreement, filling in the amounts individually will be quite labourious.  There are a number of ways around this:

• if some of the payments are the same it might be easier to enter them as several series and give an amount for each,

• you can use cut and paste to copy values from one row to the next:  enter the amount in one row and then double-click on it and key Ctrl-C (for copy), then you can click in any other rows where the amount is the same and key Ctrl-V (for paste),

• you can use the input rows or the import data tools to enter data, these can also be used in combination with Series entries [click here for more information],
• if you are able to write programs or scripts which can generate text files (or use some other facility to do so in an automated way), it may be possible to produce a saved calculation file to deal with more complex agreements without having to sit and enter all the values yourself - [click here for more details]

Also, from version 1.03 DualCalc also offers a more advanced use of the series entry.  This allows you to enter several series at the same time by inputting amount and number values separated by semi-colons (but you cannot enter several values for the other entries).  For example, if you enter:

Payment amount(s) £: 199.95;265.55
Number(s) of payments:12;48

... the program will enter 12 payments of £199.95 followed by 48 payments of £265.55 into the panel.

If you enter more number values than amount values the additional number values will be ignored.  If you enter more amounts than numbers, the last number value will be used for any additional amounts, so for example, entering:

Payment amount(s) £: 100;125;130;150
Number(s) of payments:12

... will produce 12 payments of £100.00 followed by 12 of £125.00, 12 of £130.00 and 12 of £150.00.

Entering Amounts

Amounts are entered as digits with the pence to the right of the decimal point (full stop) - ie in the normal way.  Do not include the '£' or any other currency symbol in the entry

You can also use the amount or rate entry boxes to carry out calculations.  For example, if there are three payments required at the outset of the loan you could enter them in the 'Initial sum' box as, eg:  '=120+12.50+66.32'.  When the dialogue is tidied and checked this will be replaced with the result:  198.82.  (The '=' sign isn't strictly necessary for amounts and rates, the calculation will still be carried out if it is left off.)

You can also enter more complex calculations in the format understood by the BASIC programming language (similar to that used in most spreadsheets).

Notes:

• The symbols used are:
  
  

  +   add
  -   subtract
  *   multiply (ie not 'x' or '×')
  /   divide (ie not '÷')
  ^   raise to the power (not '**'), eg 12^2 is 12 squared or 144
  E   times 10 to the power (not 'e'), eg 1.25E6 is 1,250,000
  

• round brackets can be used to control the order of calculation, for example:

  100*((1+21.4/100)^(1/12)­1)

  ... could be used to convert an effective annual rate of 21.4 to a monthly period effective rate (but you can also use the 'Rates' tool to do this).

• the calculators also use the correct 'BODMAS' precedence in applying operations:  Brackets, Order (actually this means 'Power' but you can't pronounce 'BPDMAS' so easily - and, incidentally, it's pronounced 'bod-mass'), Division, Multiplication, Addition, Subtraction.

  So, 3*2-3*2 = 0, because the two multiplications are done first to give 6-6 (if you punch this into most calculators you'll get '6' as the answer, which is wrong).

The Input Calculator Tool

You can use the 'Calculator' button which produces the following tool dialogue:

Essentially this offers you the same facilities for doing calculations as the individual input boxes, but with a wider box so you can see all (or more of) your calculation.  Additionally, you can display intermediate results in your calculation, or review the final result, by keying '='.

Note: you don't have to key '=' before using 'OK =>' (see below) to insert your result into the main dialogue, the text in the calculator will be evaluated before it is transferred.

Inserting Tool Results

The four tools with their own buttons at the bottom right corner of the dialogue can insert their results into the main dialogue when you click on their 'OK =>' button.  This is simpler than having to cut and paste results from the tool to the main dialogue.

You should indicate where you want the result entered by selecting the input box (clicking on it or tabbing to it) before starting the tool.  For example, if you want to calculate the value to be entered as the first level amount or Regular repayment, click on that edit box and then on the 'Calculator' button.  Enter you calculation and then click on the tool's 'OK =>' button to insert the result in the selected box.

The insert facility also checks that the input you have selected is appropriate to the chosen tool: for example, if you select the 'relevant date' entry, you can only use the 'Calendar' tool to enter a date.  Similarly the inputs which accept amounts will not let you use the calendar to enter dates , and will also warn you about using the intervals or rates tools (although, as they produce numbers, you can choose to proceed).

Entering Times, Dates and Lengths

'Times' are numerical entries where a time/date is required and are regarded as describing the timing of a payment in the periods entered in 'Periods in a year', alternatively, you can set the periods in a year to 'Years&days' and enter dates.

Dates are entered in the format DD/MM/YYYY, and you only need to use one digit where the day or months is less than ten, but you should preferably give all four digits for a year.  You can also use '.' or '-' to separate the figures in a date (but you should use the same separator twice, so 12-12/2004 or 12.12-04 are regarded as invalid).  When the entries are tidied and checked the dates are always shown in DD/MM/YYYY format.

If you only give two digits for a year (DD/MM/YY) DualCalc will try to guess the four digit year you meant by using the one 50 years either side of the current date.  For example, it is currently 2005 and if you enter 06 it will assume 2006.  If you enter 86 however, it will assume 1986.  Of course it might make the wrong guess here, which is why you should really use four digits.

Lengths are always entered as numerical values and must be whole numbers greater than zero - other values will be regarded as invalid.

You can also use the date, length and time entry boxes to carry out calculations.  However, to avoid possible confusion, eg '12/5/09' being treated as a calculation rather than a date, you MUST put an '=' sign at the start of the calculation in date/time boxes.

The Interval Converter Tool

When making calculations using times or dates it can be handy to have some way to convert between two dates and the interval between them in periods.  The interval converter tool, which you can call up by clicking on the 'Intervals' button, bottom right of the dialogue, does this:

The values for 'days in a year (DIY)' and 'periods in a year (PPA)' (see below) are taken from the main dialogue entries so you should set these to the required values before clicking on 'Intervals'.  If you have already entered one, the relevant date is also transferred over into the converter as the start date - but this can be amended.

By default the converter ist se to convert two dates to an interval periods (the radio button next to the interval entry is selected), so to do this type of calculation simply enter the dates into the first two text boxes and click the 'Convert' button at the bottom to calculate the interval, which will appear in the third text box.  The words 'date:' in the two date prompts are buttons and clicking on these will open the Calendar Picker tool mentioned below.

The coverter accurately calculates the time in years and part-years from the start date to the end date, and then multiplies this by PPA to convert it to periods.

Although this calculation is accurate in the context of the statutory definitions, it will often give a result which is not a whole number.  It may be more appropraite to use a less precise result in your calculation and the {Exact}/{Truncate}/{Round}/{1 dp} ... {5 dp} button is provided so you can choose whether to use the exact result or truncate the interval to whole periods or round it to the nearest whole periods or 1 .. 5 decimal places as required.  This is a 'tumbling' button (rather like the 'toggling' in the dialogues, but it rotates around several different settings).

The procedure to find the date which is a particular interval from another date is similar.  Use the radio buttons to indicate which date you would like to calculate, enter the other date and the interval and click 'Convert'.

The converter uses the factor DIY/PPA to convert the interval in periods to a date and, particularly because this conversion is done without using the program's function to calculate periods accurately, you may find discrepancies in the resulting date - eg calculate the start date for an end date of 12/12/2006 with an interval of 23 months and the result given is 10/01/2005 not 12/01/2005 as you would expect.  It is advisable to think about the result given and, if necessary, alter it.

These sort of calculations do however provide a general idea of when an event happened - eg if a consumer tells you they settled a loan at the time of the 23rd repayment on 12/12/2006 you can at least determine that it probably started in January 2005.

The convertor also provides a 'back door' to accessing the day code values used internally by the program - this is really a debugging/programming tool rather than anything you are likely to find useful.  When a date result is selected, the tumbling precision button becomes a toggling button which switches the displayed result between a date and day code.

The tool will insert the result currently selected by the radio buttons into the main dialogue when you click on the 'OK =>' button and you should really only use it with entries which accept times or dates[see 'Inserting Tool Results'].

The Calendar Picker Tool

When making calculations using dates it can be useful to have a calendar to enter them.  The calendar picker tool, which you can call up by clicking on the 'Calendar' button, bottom right of the dialogue, does this:

This tool uses a standard Windows calendar facility.  Initially, the calendar itself will not be displayed (as in the left-hand image) and you can click on the three elements of the date displayed and alter them with the up/down cursor keys.  Alternatively, you can click on the down arrow at the end of the date input to drop the calendar down (as shown in the right-hand image).

When the calendar is displayed you can use the left and right arrows at the top to change the month, or click on the month name to produced a menu of months from which you can make a selection.  You can also click on the year at the top to display up/down arrows which can be used to change the year.  Clicking on a date within the month will close the calendar and transfer it to the date input.

The tool will insert the chosen date into the main dialogue when you click on the 'OK =>' button and you should only use it with entries which accept dates [see 'Inserting Tool Results'].

The 'relevant date':

This term is taken from the Total Charge for Credit Regulations and refers in the program to the date from which the times or periods describing the repayments are measured.  When using times, the relevant date can either be entered as Zero or blank (a relevant date of any other numerical value would not make much sense and is regarded as invalid).  When using dates you should enter the relevant date in DD/MM/YYYY format and also set the periods in a year to Years&days.

Some aspects of the program expect a relevant date to be provided, ie the rebate calculations when you specify the time of settlement as a date and series entry when you ask it to write a series of dates into the panels.

Periods in a year:

The Periods in a year (also known as 'periods per annum' or 'PPA') can be selected from a combo (drop-down) box which contains the three statutory alternatives:  Weeks (52 periods in a year), Months (12 periods in a year) or Years&days (1 period in a year).

You can also use this selector to enter other common values: Half-years (2 pa), 4 months (3 pa), Quarters (4 pa), 2 months (6 pa), 4 weeks (13 pa) and 2 Weeks (26 pa) which will still, technically, provide a statutory calculation (because these are simply multiples of weeks and months).

For greater flexibility, the program also allows you to enter other numerical values directly into the combo box, eg '365', '356.25', '90', '360' etc but remember that these will not necessarily be statutory calculations.  The program will warn you if a non-statutory value (anything other than weeks, months or Years&days) is being used before continuing with the calculation.

Days in a year:

The Days in a year (or 'DIY') is primarily provided to select which of the three statutory ways of counting the number of Days in a year should be used.  The old (pre-2000) Total Charge for Credit Regulations regarded all days as a 365th of a year (even in a leap year).  The current Regulations allow a choice of either regarding all days as a 365.25th of a year or a 365th of a normal year and a 366th of a leap year.  These are provided in a combo (drop down) menu as 365, 365.25 or '365&366'.

This value is used in three ways in the program:

1. In statutory calculations, to convert the period between two dates to years and days.  The Regulations require periods to be measured in 'years and days' so the approach adopted by the program is to count from the earlier date to the later one, first in whole years and then convert any remaining days to a decimal part of a year using DIY.

2. In certain non-statutory calculations, the factor PPA/DIY is used to convert the length of a period in days to periods.  For example, if enter the time of a repayment as a date 30 days after the relevant date but do not set the periods in a year to Years&days, assuming the PPA is set to Months and the DIY is set to 365.25, the time used would be 30*12/365.25 = 0.985626283 months

3. In certain non-statutory calculations, the factor DIY/PPA is used to convert periods to a number of days.  For example, if the deferment of a settlement date was entered as two periods (as opposed to the statutory two Months) when PPA was set to months and DIY set to 365.25, then the settlement date would be deferred by 2*365.25/12 = 60.875 days.

Generally these 'non-statutory' calculations arise where you describe a loan partly using times and periods and partly using dates, or where you use something other than weeks, months or Years&days as the periods in a year.  When the program detects this you are warned that the calculation does not conform to the Regulations and asked to confirm that you wish to continue.

Describing Early Settlement

Repayments:

It is important to remember that, for rebate calculations all the repayments due under a loan must be entered into the calculator - this includes the payments due after the borrower settles.  You may have to make certain assumptions about payments due in the future and these will be governed by the Total Charge for Credit, Early Settlement or Agreements Regulations.

The Meaning of 'Repayments of Credit':

When entering the repayments to be used in an Actuarial Rule rebate calculation under the 2004 Early Settlement Regulations, it is important to remember that Regulation 1(4) provides that references to 'repayments of credit' in the Regulations comprise:

repayments of the credit advanced; and

payment of any amount included in the total charge for credit (TCC) and payable at the same time as repayments of credit.

In the Office's view, 'Repayments of credit' do not therefore include any amount within the total charge for credit (TCC) which is not payable at the same time as repayments of the credit advanced and these should be omitted from the values entered into the program when describing the repayments to be used in an Actuarial Rule rebate calculation.

We recognise that, mathematically, such amounts should be included - there is no reason to distinguish between charges paid at the same time as repayments and those paid at other times - however, in our view, this is what the wording of the Regulations requires.

Rebate method:

The first thing the program needs to know is what type of early settlement calculation you want it to do.  The program deals with both the old Rebate on Early Settlement Regulations and the 2004 Early Settlement Regulations so the 'Rebate method' combo box provides three alternatives:

Actuarial:  the method required by the 2004 Early Settlement Regulations,

Rule of 78:  the method required for most loans under the old 1983 Rebate on Early Settlement Regulations,

Pro-rata Rule:  the method required under the old 1983 Rebate on Early Settlement Regulations for loans where the credit is repayable in a single lump sum (including where the charges are paid in instalments).

Settlement ...

The time of settlement has two elements in the Regulations:  the actual settlement date and a deferred date which can be used for the purposes of the rebate calculation, reducing the amount of the rebate.  In the program the second date is entered by describing the statutory deferment which is to be added to the settlement date, rather than by entering a second, deferred date.

Settlement date:

This can be entered as a time (in periods from the start of the loan) in simple calculations or as a date.  When you use a date you must also enter a relevant date so the program can calculate how long into the loan settlement occurs.

28 Days and Using Dates

The program generally expects you to do Actuarial Rule rebate calculations under the 2004 Early Settlement Regulations based on dates rather than times and will warn you about using times in a complex calculation.

This is because:

• the Early Settlement Regulations set the majority of settlement dates to be delayed to 28 days after the date on which the borrower requests a settlement statement;

• the formula for the calculation of an Actuarial Rule rebate uses time values which represent the interval between repayments and the (delayed) settlement date;

• the Total Charge for Credit Regulations continue to require any intervals which are not whole weeks or months to be calculated in years and days (which, because of the varying number of days in a month, requires the use of specific dates).

Consequently, only a few rebate cases (those where the periods between the repayments and the deferred settlement date happen to be exact numbers of months or weeks) can be correctly calculated without resorting to dates - and this will be compounded if the trader chooses to defer settlement by 30 days rather than one month.

This does not arise with the Rule of 78 or Pro-rata Rule calculations under the earlier 1983 Rebate regulations, because they put the settlement date at the next payment due after a 28-day delay, and measured time values from the start of the loan - which in most cases meant whole weeks or months could be used.

Note:  the program does not (from version 1.01a) warn you about using times in simple actuarial calculations, as you cannot do anything else.  The assumption is that you are aware that the calculation you are doing is only appropriate in certain specific circumstances.

Adding 28 days:

The 2004 Early Settlement Regulations require most settlement dates to be set to 28 days after a given date, eg the date the borrower gives notice that they wish to settle and, under the old Settlement Information Regulations, the settlement date is the next payments due after 28 days after the request.  You can probably add four weeks to a date for yourself but, to save you reaching for a calendar, DualCalc provides a small tool which will add 28 days to a date in the 'Settlement date' text box for you.  From version 1.00a of the program, this takes the form of a small [+] button at the end of the text box.

If the program is in 'Simple' mode (ie the prompt says 'Settlement time' rather than 'date') the button will be greyed out.  If the current value in the settlement date box is not a date, the tool will ignore you.  If the date happens to be invalid, the tool will label it as such and won't try to add 28 days.

Note: if you click the button repeatedly, a further 28 days will be added each time.

Before, On or After Settlement

Regulation 4(1) of the 2004 Early Settlement Regulations provides that the amount of the minimum rebate is the difference between:

• the total amount of the repayments of credit that would fall due for payment after the settlement date if early settlement did not take place; and

• the amount given by the formula in Regulation 4.

The definitions of the terms in the formula in turn refer to:

• m = the number of advances of credit made before the settlement date,

• n = the number of repayments of credit made before the settlement date,

This raises the question of what to do with any repayments of credit which fall due on the settlement date.

The Office's view is that the wording in the head to Regulation 4(1) should be read to include repayments of credit due on the settlement date.  This is because of the conditional clause 'if settlement did not take place' - ie if the borrower changed their mind and didn't settle on that date, then the repayment due on that date would immediately thereafter become payable.  Repayments due on the settlement date should therefore be included in the sum from which the result of the formula is deducted.

So What Does the Actuarial Formula Do?

Without going into the detail of the maths, in principle, the formula estimates the balance outstanding on the account at the (deferred) time of settlement.

Take as a straightforward example a loan of £6,000 repaid by 60 monthly instalments of £142.53.  The APR is 16.0.  You could calculate the balance on the account after each payment is made by adding interest at the periodic rate equivalent of the APR (which is about 1.2445% a month in this case) to the balance and then deducting the repayment.  Over the first year this would give you these results:

Time	Interest	Balance
0	-	6000.00
1	74.67	5932.14
2	73.83	5863.44
3	72.97	5793.88
4	72.11	5723.45
5	71.23	5652.15
6	70.34	5579.97
7	69.44	5506.88
8	68.53	5432.88
9	67.61	5357.97
10	66.68	5282.12
11	65.74	5205.32
12	64.78	5127.57

Although the approach it uses is different, the formula is, in effect, calculating the balance in the final column.  So for example, assuming no deferment, the result of the formula where the settlement date was the time of the sixth repayment would be £5,579.97.  The effect of one month's deferment would be to add the interest due in the following month (£69.44) to the result, so in a case where the deferred settlement date was the time of the seventh repayment, the result would be £5,649.41.

Put simply, the logic used in Regulation 4(1) is that the future repayments the borrower will make will repay what is currently owing plus the future charges which would have applied after settlement (and which should be rebated), so 'rebate = future repayments - current balance'.

Why do you say 'in principle' and 'estimates'?

'In principle':  because, in practice, some of the anomalies in the 2004 Early Settlement Regulations mentioned elsewhere in these notes mean that the rates and repayments we are required to use in the formula don't actually provide an estimate of the real balance at the time of settlement.

'estimates':  because, with agreements where the rate of interest has changed before the borrower settles, an accurate assessment of the balance outstanding at the time of settlement (eg in a table such as the one above) would require you to use the relevant rates for the periods in which they applied.  The formula instead uses a single rate which, in effect, 'averages out' the changing rates over the lifetime of the loan - this would be the case even if the formula used a rate recalculated to reflect rate changes since the agreement, rather than the original APR.

What about future advances of credit?

You might notice that the formula deals with advances of credit which have already been made, but the head to Regulation 4(1), while referring to future repayments of credit, makes no mention of future advances of credit which were due to be made on or after the settlement date.

This could lead you to believe that you should account in some other way for any such future advances, eg by adjusting the future repayments used in the rebate calculation to account for the fact that those advances would no longer be made.

In fact no adjustment is necessary.  The future advances are already accounted for because the APR to be used in the formula assumes that the advances are made, and the future repayments referred to in Regulation 4(1) represent the repayment of the current balance, the future charges and any future advances.

Deferment:

Deferment can be described as one of four statutory values:  None, 30 Days, 1 Month or 2 Months (from the old Rebate Regulations).  Note that these periods are always treated as months or days - even if the periods used to describe the loans are something else.

Alternatively you can enter the deferment as a numerical value, in which case it is regarded as being specified in periods, the 'Interval' tool may be useful in calculating the value in periods.

Excluded Sum:

The old 1983 Rebate on Early Settlement Regulations allowed that certain charges which are included in the total charge for credit may be excluded from it for the purpose of calculating the rebate.

In Rule of 78 and Pro-rata calculations (under the old Regulations) the sum in question can simply be deducted from the TCC used in the calculation, so this can be done in a very straightforward way by entering the total amount of the charges to be excluded in the 'Excluded sum' text box.

In the 2004 Early Settlement Regulations things are more complicated because they say these sums may be excluded from the calculation of the rebate.  The Actuarial calculation is based on an APR and the times at which the excluded charges were to be made will also be taken into account in the result.  The Excluded sum box is not therefore available in this mode.  Instead, you should first describe the loan without the excluded charges and calculate an APR for that.

APR/Period Rate Input:

You need to provide the Actuarial Rule rebate calculation with the APR to be used in the calculation.  The program provides two ways of doing this:  you can either enter the APR in the APR text box or the period rate in the Period rate text box.  If you enter both, the APR will over-ride (and over-write) the period rate value when the calculation is carried out.

The APR to be Used

You need to think quite carefully about the APR value you use here.

It appears that the intention was that an Actuarial Rule rebate should be calculated using a rate which reflects any changes (such as variations in the rate of interest) which have occurred under the agreement before settlement, and assuming that the conditions applying at the time of settlement would continue for the rest of the loan (the first version of the DTI's guidance on the Regulations said as much).

However, the Regulations actually require you to do the calculation using the agreement's 'APR' which is, by definition, calculated based on the original conditions at the time the agreement was made.  While this would reflect any specific rate changes set down in the original terms of the agreement (for example the end of a discount rate), changes in variable rate agreements (eg, where the rate changes are determined by rate or market fluctuations and are not known when the agreement was made) will not be taken into account.

The APR to be used is also subject to any 'Excluded charges' (see above).  You may therefore need to re-calculate an APR for the agreement, removing excluded charges, but assuming that other circumstances remain as they were at the time the agreement was made.  It may be equally valid to recalculate the APR by adjusting the loan amount.

For example if a lender advances a borrower £5,000 plus the cost of a £500 credit broker's fee, the loan repayments will be calculated to repay the full £5,500 but, because the fee forms part of the TCC it is not regarded as credit under the Act, so the agreement's APR would be calculated for a loan of £5,000 repaid by the higher repayments.

The APR to be used in the actuarial calculation could be recalculated by finding the repayments which would pay off the smaller £5,000 loan and using those.  However, it may be more convenient to simply adjust the loan amount to £5,500 and calculate the APR for that loan - the result should be the same.

Note:  the rate appearing in the agreement's documentation may not be the correct APR to use in the calculation, because the lender is permitted to use certain tolerances in calculating the rate to be disclosed in an agreement (and similarly in an advertisement - so the same goes for a rate you might see there) - for example the rate can be up to 1 too high or 0.1 too low or the amounts or times of the repayments used can be slightly different from those actually required.  The 2004 Early Settlement Regulations make no allowance for those tolerances, so you may need to first recalculate an exact APR for the agreement, disregarding any tolerances.

The Period Rate Converter Tool

It may be useful to have a facility to convert between annual and period rate.  The period rate converter tool, which you can call up by clicking on the 'Rates' button, bottom right of the dialogue, does this:

To convert a period rate to an annual rate:

Select the periods in a year from the drop-down 'Periods in year' combo box (initially this will be set to the periods in a year in the main dialogue, so you may not need to change it).  If the periods you need aren't supplied simply enter a number into the top of the box,

Enter the period rate as a percentage in the 'Period rate (%)' text box,

Ensure the radio button to the right of the 'Annual rate (%)' text box is selected,

Click on the 'Convert' button and the corresponding effective annual rate expressed as a percentage will appear in the 'Annual rate (%)' text box.

To convert an annual rate to an period rate:

Follow the same procedure as above but enter the annual rate as a percentage in the 'Annual rate (%)' box and ensure the radio button next to the 'Period rate (%)' text box is selected.

The tool will insert the chosen rate into the main dialogue when you click on the 'OK =>' button and you should really only use it with entries which accept dates [see 'Inserting Tool Results'].

[Click here for more information on converting period rates.]

Checking Input

When you enter something in the program's dialogue it has yet to be stored in its internal memory.  If you click on one of the program's control buttons (with a few exceptions) or use the VCR controls to display more panel rows, it program will verify the information in the dialogue before storing it away.

If it finds information which it does not think is valid, the program will flag this by including 'INVALID=>' at the start of the entry and display an alert box saying 'Invalid entries detected, please correct them and try again.'  If you see this you should scan the dialogue for any entries marked 'INVALID=>'.

Note:  There is no need to change the rows displayed in the panels with the VCR controls when looking for invalid entries, the program is only checking the rows currently displayed, the content of other rows will already have been checked before they were stored away.

The sort of things which the program will find invalid are:

• arithmetical errors, eg '1/0' (one divided by zero - because the result is infinity)

• values which are not acceptable for the particular input, eg a negative or fractional value for the length of a level

• incorrect dates, eg 31/2/2004 (only 28 or 29 days in February - and the program will check appropriately for leap years)

  Note:  dates entered in amount boxes won't generally get picked up, eg an initial sum of '1/12/2004' will be regarded as a calculation (1 divided by 12, divided by 2004) which will be rounded to £0.00 in the display)

When you see an 'INVALID=>' entry you need to correct it before the program will do a calculation.  What you entered is retained to the right of the arrow so you can alter it.  You don't actually need to remove 'INVALID=>' from most boxes because the program will do that for you, provided the revised entry is valid.  However, in 'combo' (drop-down) boxes, you will find that Windows won't scroll the text across and you need to delete 'INVALID=>' to get at what you've entered (or you can simply double-click on the text and key 'Delete' or Ctrl-X to get rid of it all).

If the entry contains characters which shouldn't be there - eg you enter the amount of the loan as 'wibble' or (even though it might make sense to us) 'ninety nine' - obviously you need to use numbers (see entering amounts) - the program will simply strip out the invalid characters leaving the ones which make sense, so '100 pounds' will simply be stripped down to '100' and '£5,000' to '5000'

Further checks:

The program also carries out further checks when a calculation is started, eg to see if the combination of data entered makes sense - ie for things like the loan having no repayments, the incorrect use of times and dates, or other more complex combinations which don't make sense.  These are carried out in the individual calculations after the dialogue has been checked and tidied, so you may find there is a short delay before they appear.

In some cases the program merely warns you that the calculations is being done the wrong way but lets you confirm that you wish to continue.  This is done for a number of reasons:

You may only wish to do an approximate calculation to confirm that something is 'about right' and it might be much quicker to describe the loan in a non-statutory way.

You may want to do 'experimental' calculations - eg, 'what if the Regulations allowed this?'

If you are an enforcement officer advising a trader or consumer on calculations, it may help you to identify what they are doing wrong by giving you the same 'wrong' answer.

Further details are given with the descriptions of the individual entries but, briefly, the following lists the further messages which might appear and their consequences:

First there are some checks on the amounts:

• There are no advances! - the program has added up the loan and all the advances and they come to zero.  The program stops the calculation at this point.

• There are no repayments! - the program has added up the initial and final sums and all the repayments and they come to zero.  The program stops the calculation at this point.

• The repayments are negative! - the program has added up the initial and final sums and all the repayments and they come to less than zero.  The program stops the calculation at this point.

• The charges are negative, do you want to continue? - the total amount payable is less that the total advanced.  In case you are knowingly doing some sort of unusual calculation, you are given the opportunity to continue.

Then there are checks on the timing information:

• The Periods in a year are zero or less! - the entry used for Periods in a year is invalid.  The program stops the calculation at this point.

• Calculations using dates require a relevant date! - the program has detected that you have used dates but haven't entered a relevant date.  When you enter dates they are ultimately converted to numbers measuring the time in periods from the relevant date to the payment date and it can't do this without a relevant date.  The program stops the calculation at this point.

• Both dates and times are used in the calculation, do you want to continue? - the program has detected that you have entered some timings (including the relevant or settlement dates) using dates and others using times (eg by using levels, or numerical values for the times of extras or advances).  Effectively, the Regulations give you a choice of describing timings in one of weeks, months (for either of which you can use times in the program) or years and days (for which you can use dates).  So strictly, you shouldn't be mixing times and dates.  However, the program can generally make sense of mixed times and dates and, in case you are knowingly doing some sort of unusual calculation, you are given the opportunity to continue.

• Times or dates BEFORE the relevant date have been used, do you want to continue? From version 1.01a, there is an additional check to detect and warn the user about the use of dates/times which are before the relevant date.  Strictly, under the Total Charge for Credit Regulations, a payment made before the relevant date should be assumed to be made ON the relevant date.

• Dates are being used with periods other than years and days, do you want to continue? - the program has detected that you are using dates but don't have the Periods in a year set to 'Years&days' so it's going to have to fudge calculating the timings from the dates rather than use the correct method.  In case you are knowingly doing some sort of unusual calculation, you are given the opportunity to continue.
  
  You're quite likely to get this warning in conjunction with the previous one.

• Non-statutory Days in a year have been used, do you want to continue? - the program has detected that you have entered something like '360' as the days in a year (actually, this is sometimes used in accounting).  In case you are knowingly doing some sort of unusual calculation, you are given the opportunity to continue.

• Non-statutory Periods in a year have been used, do you want to continue? - the program has noticed that you've entered something like 'Quarters' or '99' as the number of periods in a year (although technically 'Quarters' is valid as it's a multiple of 'Months').  In case you are knowingly doing some sort of unusual calculation, you are given the opportunity to continue.

• The time of the Final sum is invalid or unknown! - the program has detected that the time of the last repayment is zero or less.  This would only arise where you have used a 'Final Sum' to describe the only repayment under a single instalment agreement.  In such cases it is also necessary to enter the number of regular repayments or the length of a level (even though the amounts of the repayments or level are zero) to establish the time at which the final sum is paid.

  Note:  you cannot use the time or date of a zero amount extra repayment or advance to establish the time the final sum is paid, because zero amount extra repayments or advances are tidied out of the calculation before it is carried out and checked.  If you want to enter the time of a single instalment as a date, the correct approach is to enter it as an extra repayment, rather than use Final sum.

  There are also some additional checks for rebate calculations:

• Please use a settlement time for simple calculations! - simple calculations don't use dates and the program has detected that you've entered the time of settlement as a date (the program actually refers to the values as a 'time' in simple calculations).  The program stops the calculation at this point.

• Thirty-day deferment is not valid for Rule of 78 or Pro-rata calculations! - the 30-day period was introduced with the 2004 Early Settlement Regulations and the program has detected that you are trying to use it with a calculation from the old 1983 Rebate on Early Settlement Regulations.  The program stops the calculation at this point.

• Thirty-day deferment requires the calculation to be done using dates! - in order to defer the settlement by thirty days the program has to calculate the timings using dates and has detected that you have used times somewhere.  The program stops the calculation at this point.

• Actuarial Rule calculations should generally be done using dates, do you want to continue? - the program has detected that used have used times in a complex actuarial calculation.  Generally you should use dates (see here for details).

• A non-statutory deferment has been used, do you want to continue? - the program has detected that you have entered something like '3' for the deferment.  In case you are knowingly doing some sort of unusual calculation, you are given the opportunity to continue.

And there are some further checks on the settlement date and the deferment:

• The settlement date is on or before the relevant date/time! - the program has detected that the time of settlement is at or before the start of the loan.  The program stops the calculation at this point.

• The deferred settlement date is after the last payment! - the program has calculated the deferred time of settlement and noticed that it goes beyond the end of the loan, so there will be no rebate.  The program stops the calculation at this point.

Saving and Loading Calculations

You may find that you want to save a partly completed calculation and come back to it later, for example, because you need to find more information or do something urgent.  The program provides this facility if you click on the 'Save' button.

Note:  the program will check and tidy your calculation before saving it so you may have to correct any errors first and will lose any gaps you left in the rows, any zero length levels and any zero amount extras or advances.

Assuming the calculation is okay to save, you will be presented with a standard Windows 'Save as' dialogue:

• locate the folder you want to save in and provide a filename

• If you select a file which already exists, Windows will check whether you want to replace it

• The program provides a folder called 'Saved' in the same location you install it, but you don't have to use that - you could for example make your own in 'My Documents'

• Calculations are saved as plain text (ASCII) files and should have the file extension '.txt'.  If you don't provide an extension, '.txt' will be added automatically.

Loading calculations

The procedure for loading a saved calculation is similar to saving, click on the 'Load' button, locate the folder where you previously saved the file (the program will initially open the saved folder you specify in options - see here), locate your file and click 'Open'.

Scanning ...

After you load a calculation it is scanned to make sure that all the values in the rows which have been entered (not just those currently in the display) are valid.  If DualCalc spots a problem it will tell you and pause, displaying the offending block of rows with any problem entries marked 'INVALID =>'.  You should correct the invalid values before clicking 'OK' in the error message.

TIP:  move the error message to one side of DualCalc's main dialogue before editing the entry - otherwise, when you click on the main dialogue, the error message will go and hide behind it and you will have to move DualCalc (and maybe other windows) to find it.

When you click 'OK' in the error message, the program will check the current entries again, in case there's still something wrong, and then continue scanning.

If you load a calculation saved by DualCalc there should not be any errors, in which case this process will be virtually invisible (although, on a slow PC, calculations with a large number of row entries may take a while to scan).  Scanning is there for those cases where you load (or import) values produced by, or taken from, other software.

Click here for details of how calculations are saved.

Click here for information on importing data.

Doing Calculations

To start a calculation simply click on the 'Calculate' button.

The dialogue will be greyed out and the program then checks your input.  If it finds anything wrong you will have to correct it (see 'checking input' for details) and, if it's a complex calculation, it will then tidy the panels.

Further checks for a consistent calculation will be made and then the calculation will start.

APR Calculations:

These can be quite tricky as the program has to search for the right answer rather than just calculate it.  It tries first with a very powerful mathematical method called The Newton-Rapheson Method of Successive Approximations (or just 'Newton's Method') which can find the answer very precisely in only five or six attempts but can also get stuck.  If this happens the program switches to a slower 'Bisection Method' (which might take 40 or more attempts).  The information at the bottom of the dialogue reports the number of attempts and certain mathematical information about the progress of the current method.  If the program switches methods, this will change from reporting 'Newton ...' to 'Bisection ...'.  Should the bisection method fail too, the program has to give up and report that the APR could not be calculated.

Note:  during an APR calculation, you can force the program to switch to the bisection method by holding down the 'Alt' (for 'alternate method') key.

In practice however you are unlikely to meet circumstances where Newton's method fails, and more unlikely to find one where both fail.  If you do, it's likely that there is something wrong with the way you have described the agreement, so check your input carefully.

Calculation Results

Once the program has found an APR, rebate etc, the dialogue will switch to 'Results' mode where the filled-in boxes containing the results to your calculation are available along with certain other buttons, and the 'Calculate' button changes to an 'Enter' button.  The boxes for entering information remain 'greyed-out'.  If you wish to amend the loan details, click on the 'Enter' button (which changes back to 'Calculate') make your changes, and click on 'Calculate' again.

The boxes used to display the results are editable - this is because the information is a bit clearer presented this way and, more importantly, allows you to cut and paste the results into other programs if you wish - eg into a word processor.  This does of course also allow you to change the results on screen, however there's no point in doing this because this has no effect on the internal results stored by the program, so when you come to record the results (eg in a log or by printing - see below) any changes will be ignored.

Changes to the APR and Period rate results will however be used in a subsequent Actuarial Rule rebate calculation (see here for details).

The following table lists the results displayed and what they mean:

Comparing Results

If you are an enforcement office or consumer adviser you may want to use the program to check results carried out by someone else.  If so, there are a few things to remember ...

Checking APR Results:

Generally APR results are pretty straightforward, either the result corresponds or it doesn't.  However, you should bear in mind that both the agreements and advertisements Regulations permit certain assumptions and tolerances in an APR calculation and if, for example, your initial result does not agree with a lender's, the program leaves it to you to consider what assumptions they might have used and recalculate using them to see if you then get a figure which corresponds to the lender's.

Also, if you are, for example, assisting a trader who has produced their own program or spreadsheet for APR calculations, you may find it more useful to compare their untruncated/unrounded result with the program's effective annual rate result.  Although the APRs may correspond, smaller differences here might still suggest that there is something different with the way they are applying the calculation.  On the other hand, a good correlation here (eg to 6 or 9 decimals places or more) probably indicates that they are doing the same thing, and their method is less likely to produce incorrect APRs in other circumstances.

Checking Rebate Results:

Rebate calculations can be more problematic and it is perhaps worth stressing that the final settlement amount given by the program may not be the whole story.  Lenders may in some cases, quite legitimately, be able to add charges or interest resulting from default to this figure - provided their agreement makes provision for this (however they cannot add an additional charge for early settlement as this would contravene the Consumer Credit Act).  The figure also assumes that the borrower makes all the repayments up to and including the settlement date - so the borrower will usually have to make a final repayment in addition to the settlement figure.

Some lenders add the final repayment to the settlement amount, which is why the program gives the "settlement plus final payment" figure.  You may find that, although the rebate is the same, the settlement figure corresponds to this rather than the 'statutory' settlement figure.

In some cases lenders will assume that the borrower will not make any of the repayments due after the date of the settlement statement and add these to the settlement figure as well.  In this case their figure might differ from the program's 'statutory' result by perhaps two or three repayments.

Nonetheless, provided the total sum the borrower ends up paying, (ie the repayments during the intervening period plus the settlement amount) is the same, the program's result can be regarded as confirming those arrived at by the lender.

The position is more difficult where some lenders also appear to assume that interest will accrue on the 'unpaid' payments due before settlement and factor this into their calculation too.  In some cases their systems may even project current state of the account on until the contractual end of the loan - so they assume that the payments due between the date the settlement statement is produced and the settlement date all remain outstanding and accrue interest until the end of the loan.  This results in a larger total charge for credit (because it includes interest on the 'arrears' of payments) and, paradoxically, a much larger rebate than would otherwise be expected, but also gives a larger settlement figure.

Such lenders may recalculate the sum due and refund and excess if the borrower makes further payments before settling.  However, the validity of assuming that sums have remained outstanding and accrued interest for the rest of the loan when the borrower has in fact settled early may be questionable.

Logging Calculations

You will probably want to record the results of your calculations somewhere.  The basic way of doing this provided by the program is a facility to 'log' calculations.  Logging stores all the details of the calculation (your input) and the results (the program's output) in a file.  This is distinct from saving a calculation, where only your input is recorded.

You can log calculations by clicking on the 'Log' button, which is only available while the results are being displayed.

From version 1.01a, you can add a description to your logs using the 'Describe calculation' tool in 'Tools' (see here).

The same description will be included in all subsequent logs and printouts until you change it.  This is useful if you are doing several calculations on the same case, but could be annoying if you forget and the printout for your next case is labelled with a description from a previous one.  So, if a description has been set, the program will prompt you to confirm it each time you log or print a calculation.  You can clear the description by clicking 'Cancel' or the '[X]' button in the prompt or change it by amending the text and clicking 'Okay'.

One additional wrinkle here is that including the text '\n' (without the quotes) in your description causes a new-line in the resulting log or printout.  So, if you enter the text:  "Operator: Brian Stewart\nMrs Jones\n123 Acacia Avenue\nAnytown\nAT1 2BB\nCar loan with Jollycheap Finance" into the prompt, your log or printout will contain (after the time and date information) the following:

Description:
Operator:  Brian Stewart
Mrs Jones
123 Acacia Avenue
Anytown
AT1 2BB
Car loan with Jollycheap Finance

Notes:

• the current description is saved along with the loan details and re-loaded as part of that saved calculation,

• the current description is also saved as part of your program's setup in 'Options'.  You can use this to set a default setup which will be loaded every time you start DualCalc - and you should make sure your description is set to the default you require before saving your setup.

The format used for logs is a web page.  When you click on the button a standard Windows save dialogue will open and you should use this to enter the name of, or locate, the log file you want to use.  If you use an existing filename, Windows will ask if you want to 'replace' the file.  In fact what will happen is that the file will be replaced with one which contains the existing logged calculations and your new one.  Calculations are entered into the top of the log file so the most recent is always at the top.

If you want to discard an existing file and use the same name for a new log rather than add calculations to it, right-click on the file in the dialogue (which will automatically place its name in the 'save as' box in the dialogue) and then select 'Delete' from the pop-up menu.

This is a straightforward example of a logged calculation:

DualCalc - APR and Rebate Calculator

Version 1.01 © Crown Copyright 2005
Office of Fair Trading
by Brian Stewart

Calculation Log File

Simple APR Calculation
Logged:  Wed.15 Jun 2005,16:10:23

Program Options

Clicking on the 'Options' button opens a further dialogue, shown below, which allows you to set certain options which control the program's output (saving, logging, displaying messages, or printing) or the defaults when it first starts up (calculation modes and the maximum number of panel rows).

You can us this dialogue to change the following ('*' indicates an option which requires a restart of DualCalc to take effect):

DualCalc - APR and Rebate Calculator
Version 1.01a © Crown Copyright 2005
Office of Fair Trading
by Brian Stewart

Calculation Log File

----------------------------------------------------------------

Simple APR Calculation
Logged: Wed.15 Jun 2005,15:48:57

Description:
User, Brian Stewart

Loan Details:
Loan Amount = £100.00, (time = Zero)

Periods in a Year = Months

Advance/Repayment Details:
Regular Repayment = £10.00, Number = 12 (times 1 to 12)

APR Results:
Loan Totals ...
Total Amount Advanced = £100.00
Total Amount Payable = £120.00 (TAP)
Total Charge for Credit = £20.00 (TCC)
Rate Results ...
Period Effective Rate = 2.92285407691%
Nominal Annual Rate = 35.074248923%
Effective Annual Rate = 41.299898415%
Annual Percentage Rate = 41.3 (APR)

----------------------------------------------------------------

There is a tool available to reset all the options to their default values (see here).

Calculation Analysis

Sometimes you will want to be able to understand how a calculation was carried out - or 'prove' to a court or trader that the result is right.

Ticking 'Analyse' in the 'Options' dialogue (see above) asks the program to include additional analysis information in its logged or printed output.  The information provided depends on the type of calculation:

APR Calculations:

The equation in the Regulations calculates APR as the rate at which the present values (PVs) of the advances and repayments under the loan are equal.  For this type of calculation the program provides an analysis of the PV of each repayment and advance in the calculation.

Having the program check its own results may not be seen as independent confirmation but, in fact, different formulae in separate routines are used to calculate APRs and display PVs so, for example, some of the PVs displayed by the analysis option could be double-checked manually to confirm that they are correct.

As they are not statutory formulae taken from the regulations, it may also be necessary to show that the more complex formulae used by the program to calculate the PVs of regular repayments and levels in one step (rather than calculating each payment separately) operate correctly.  To do this, after the PVs of the individual regular repayments or the repayments in a level, the program also provides the total of those PVs, obtained by simply adding up the previously printed values.  This is followed by a figure, referred to as a 'composite' PV, obtained using the more complex formula.

Here is an example log containing a PV analysis:

Complex APR Calculation
(including Present Value Rule analysis)
Logged:  Wed.15 Jun 2005,16:39:55

Rule of 78 Rebate Calculations:

The general formula for the Rule of 78 is a fraction something like this:

... where 'm' is the total number of instalments "not yet due" at the (deferred) settlement date, 'n' is the number of instalment payable under the agreement, 'A' and 'a' are the amounts and times (counted from the relevant date) of the payments under the agreement and 'B' and 'b' are the amounts and times (counted from the deferred SETTLEMENT date) of the payments "not yet due" at that date.  The suffixes to A, a, B and b (ie the 1, 2, 3, ... m and n figures) indicate the particular payment in question.  'K' represents the total charge for credit (TCC) of the agreement.

You can see from this that the rebate is obtained by multiplying the TCC by a fraction (the Bb's over the Aa's) found by adding together multiples of the amounts and times of payments.  The details the program provides for a Rule of 78 Fraction analysis are in the following format:

Complex Rule of 78 Rebate Calculation
(including Rule of 78 Fraction analysis)
Logged:  Wed.15 Jun 2005,16:46:49

The values for the upper and lower halves of the fraction are given as separate 'components'.  Note that, in the above example settlement takes place at time 1 and there is two months deferment - taking us to time 3.  Only payments occurring AFTER that time will affect the upper-half of the fraction:  so we have zeros for the upper components where they are earlier.  Also, the values to be added to the upper-half are calculated counting the time from the settlement date NOT the relevant date, so for example, the Upper component entry for time 5 is calculated as 20 x 2 and not 20 x 5.  All payments count towards the lower-half of the fraction and the time is calculated from the relevant date, so for example the Lower component for time 5 is calculated as 20 x 5.

Pro-rata Rule Calculations:

These calculations are more straightforward, being based only on the length of the loan, the time of (deferred) settlement and the total charge for credit.  Consequently, only a fraction value for the whole loan is shown, which is calculated as (time remaining from deferred settlement to end of loan) / length of loan:

Complex Pro-rata Rule Rebate Calculation
(including Pro-rata Rule Fraction analysis)
Logged:  Wed.15 Jun 2005,16:57:12

Actuarial Rule Calculations:

The analysis produced for these calculation is similar to that for the Rule of 78 in that they are broken down into two parts only, in this case, the values for the payments before and on or after the (deferred) settlement date are analysed - the 'before' payments are those used in the formula, so the results of applying the formula to each payment are given:

Complex Actuarial Rule Rebate Calculation
(including Actuarial Before/After analysis)
Logged:  Wed.15 Jun 2005,17:06:13

This example also illustrates how dates are analysed.  You can see that where dates have been given the program also reports that date as periods and a number of days (this is calculated by the program from the time in periods, rather than relying on the user's input and may therefore sometimes be slightly out).

Additionally, to help with analysing the program's actuarial results, the time from the date of a payment to the deferred settlement date is also reported as 'Settlement' periods and days.  In this case dates after the deferred settlement date are reported with negative values.

The 'r-factor':

The Regulations require the use of a value 'r' in Actuarial Rule rebate calculations which is the periodic rate equivalent of the APR expressed as a percentage.  Please note that the 'r-factor' reported in the analysis above is equal to 1 + r, not r.  This is reported because all the terms in a calculation actually use a value of 1 + r and this was felt to be more useful if you wanted to 'manually' check the accuracy of the results for one or more terms.

Note:  all loans in the examples above are illustrative rather than realistic and have fairly high repayments over a short period.

Viewing Logs

You can view logged calculations by clicking on the 'View Log' button.  This opens a standard Windows dialogue which asks you to locate the file you want you view, and the log will then be displayed using your browser (in fact you can use this to view any .htm file stored locally).

Printing Calculations

Clicking on the 'Print' button will cause the program to print the results of a calculation giving the same information as in a log (click here for details).

Additional Tools

Clicking on the 'Tools' button brings up a dialogue something like this:

Exactly what it will look like depends on the program version and the tools which have been added to your individual setup, so the above is only an illustration.  To use a tool, select it from a list (if there are more than shown here there will be a scroll bar beside the list) and click on the 'Run' button underneath.

As you can see DualCalc's Tools are split into three categories:

Calculation Tools:

These are things which might make life a bit easier when entering calculations but aren't likely to be needed very often, so they don't warrant a button or gadget of their own in the main dialogue.  Here's what they do:

• 'Describe calculation' - running this tool produces a prompt which allows you to set the description which will be added to logs or printouts (see here).

  

  This description will be saved along with the other details of a calculation and can also be set to a default (eg the user's name or department) using 'Save option settings' in 'Options'.  If a description is set you will be asked to confirm or amend it using this tool each time you log or print a calculation.  You can clear the description by clicking on 'Cancel' or '[X]' in this tool's dialogue;

• 'Early settlement examples' - this tool calculates the three early settlement examples required by the Agreements Regulations using the loan currently described in the calculator.  You do not have to enter the settlement times/dates or the APR (if required).  The time/date of the last payment is used as the basis for the one-quarter, one-half and three-quarters settlement times/dates.

  You have to be in Rebate Mode to use this tool and will be asked to switch modes if you are in APR mode.  Make sure your loan details are still valid - for example, the program will warn you that you can't use 'Levels' to describe a Complex Actuarial rebate calculation (the levels will be included in the APR calculation but omitted from the rebate calculations) and offers the user the opportunity to use the currently displayed APR instead.

  The rebate will be calculated by the currently selected method.  If your description of the loan is not valid, the tool will warn you about possible problems for the first of the three calculations (and possible for the APR calculation too), or may stop carrying them out if the problem aborts a calculation.  After the first rebate calculation warnings are switched off to avoid giving you the same warnings three times.

  You can opt to log the results, otherwise they will each be presented in a prompt (in case you want to copy and paste it somewhere else) before continuing to the next calculation.  If you log the results, each will include a brief description identifying the examples and the log will be displayed when the tool finishes the calculations.

  If your calculation uses dates (and only dates), you can also opt to use the date of the next repayment due after each example date.  This is found by starting with the example date and searching through the extra repayments for the earliest whose date is greater than the one-quarter, one-half or three-quarters date.  Only the repayments in 'Extras' are checked because:  'Levels' don't use dates, so the 'next repayment' option is not available; 'Advances' are not repayments; the Initial sum/Deposit won't be made after an example date; and the time of the 'Final sum' is used the start point of the search.

• 'Input or delete panel columns' - if you're dealing with a fairly complicated calculation it may be useful to be able to enter blocks of several values at once.  Equally, if you get something wrong (particularly if you've been using the 'Series' button or the Import tool described below), it can be a real pain to have to start again or individually alter, delete or 'zero' all the wrong entries to get rid of them.  To some extent, this tool duplicates the functions of the Series button, but it's more versatile in some ways (eg, it allows you to overwrite entries) and more limited in others (eg you can't use it to enter dates).  It also allows you to delete blocks of rows from a panel.

  (This replaces the earlier tool which only provided a facility to delete rows.)

  When you run the tool you will see this dialogue:

  

  How it works, a few rules, etc:

  The 'input value' is the number, eg an amount or time, you want entered into the panel column:

  • the tool will only add or overwrite one column at a time, if you want to enter both amounts and times, use the tool twice, overwriting the other column in the same rows the second time

  • you cannot use the tool to enter dates, you can however enter dates with the series tool and then input the amounts with this tool

  • a 'rule' allows you to specify that the value changes periodically.  The format is {value};{increment};{step}:

    • value is the starting value,
    • increment is the amount by which it changes (you can use '-' if the value goes down rather than up),
    • step is how often it changes, eg a step of '12' mean that the value will change after every twelfth payment

    For example, entering the rule '125;2.50;3' would produce amount values of 125.00, 125.00, 125.00, 127.50, 127.50, 127.50, 130.00, 130.00, 130.00 ... and so on.  It's unlikely that you would come across many real loans where the payments follow this sort of pattern, but specifying a rule may be useful for experimental calculation: eg, 'how does such and such operate where a loan has increasing/decreasing repayments?'

    Using a rule is however particularly important when entering times (or all the times will be the same!), for example to produce the times 12, 13, 14, 15 ... and so on, use '12;1;1'.

  The 'input action and target' selector offers the following options:

  

  • you can choose to add or overwrite a column of data (eg the amounts of level repayments).  If you add data, the panels are 'tidied' first and the data added to the following empty rows

  • if you choose to overwrite a column of data, any data already in that and the following column rows (depending on how many rows you indicate) will be lost

  • the 'First row' input is only available where you choose to overwrite or delete columns and tells the tool where to start entering values (the default is row one if you leave it blank).  The delete and overwrite options do not tidy the data first and overwriting allows you combine data with timing data entered using the 'Series' button or the import data tool mentioned below - this may need some planning, and remember that the 'Series' button does automatically tidy the entries so you need to write times or dates with that before importing the payment amounts

  • the 'Last row' input is always available and tells the tool where to stop entering values, alternatively, you can enter a number preceded by '+' which tell the tool how many rows to alter (note:  if you leave this input blank all the available rows to the end will be altered)

  • the tool will not try to alter values beyond the end of the panel's rows and if you enter a 'Last row' which is the same as the 'First row' only the first row will be altered.  The tool will object if the last row is less than the first

  • the tool will ask you to confirm overwrites or deletions, eg:  'Delete level rows 1 to 12, are you sure?' or 'Overwrite extra rows 5 onwards, are you sure?'

  Deleting Rows:

  You can also use the tool to delete rows completely (amount and time/date) using the options at the end of the drop-down list.  The input value is not available when you choose to delete rows, because in these cases the tool enters zero into the appropriate length or amount columns and then 'tidies' the panel to delete the rows.

  WARNING:  leaving the first/last row values blank will delete all the entries in the panel.

• 'Import raw data into rows' - this tool in intended to enable you to transfer payment data (amounts and/or times or dates) from other software into DualCalc.

  

  'Raw' data means data which does not contain the associated labels such as 'Extra_1=' which DualCalc normally expects to find when loading a 'saved calculation', instead it contains just the text of the numerical information.

  How it works, a few rules, etc:

  • data can only be imported into the panel rows, other information such as the loan amount should be entered manually

  • the data must be in a text file:  if you try to load something else, such as an Excel (.xls) spreadsheet file, it may apparently work but the result will be unpredictable and almost certainly unrelated to the data you wanted from the spreadsheet

  • you can however save your spreadsheet (or the relevant part of it) as a comma or tab delimited text file and import that, or data in a word processor can be saved as plain (ASCII or DOS) text, and imported as raw data

  • what the import function does in detail is read through the file until it sees characters it recognises as valid for amounts or dates (ie: '1234567890.E-/'), and then keeps on reading them in until it sees something (such as a space, a comma, a tab, a newline or other text) which is not a valid character, at which point it concludes it has come to the end of that piece of data

  • the function repeatedly reads items of data and inserts them into the program's rows in the manner requested until it reaches the end of the file (or the end of the available rows) so, if the order is important (ie data about levels), you must get it in the right order before importing it, or import it in the right order if it is in several places

  • a comma is not recognised as a valid data character (in fact it's commonly used as a separator in 'comma separated value' .csv files) so amounts must be formatted as, eg 5123.45 not 5,123.45, which would be misread as two pieces of data: 5 followed by 123.45.  Also the 'European' format, using decimal points to separate numerals and a comma as the decimal point (eg 5.123,45) will be misread as 5.123 followed by 45, as will the 'Scientific' format, using spaces in place of commas (eg 5 123.45)

  • the inclusion of 'E' (uppercase only) as a valid data character means that exponential or 'engineering' format numbers (eg 5.12345E3) are recognised (in this case, as 5123.45).  The inclusion of '-' in the valid characters means that negative values can be imported (even if the program might subsequently find them to be invalid)

  • the inclusion of '.-/' in the valid characters means that dates can also be imported (although only into the second extra or advance columns which accept dates) in the format dd.mm.yyyy, dd-mm-yyyy or dd/mm/yyyy.  If incorrectly read into an amount column, the full date will be read but will be interpreted as just the day value (ie in 25/12/2006 everything up to the six will be extracted from the file, so the next value to be read will be assumed to somewhere after it, but it will be evaluated as just 25).  Two digit years (yy) can also be read as dates and will be converted to yyyy format with the 50-year rule DualCalc uses for typed input

  • calculations cannot be imported.  For example:  '(5*12)/3' will actually be read as three data values '5', '12' and '/3' (which will probably be evaluated as zero), rather than being evaluated as 20.

  

  • you can choose (through the options in the drop down list shown above) to add or overwrite either pairs of data (eg extra amounts and times/dates) or a single column of data (eg the amounts of level repayments).  If you add data, the panels are 'tidied' first and the data added to the following empty rows

  • you can also choose to overwrite single columns of data and any data already in that and the following column rows (how many depending on how much data you import or how much is in the file) will be lost

  • The 'first row' input is only available where you choose to overwrite columns and tells the tool where to start entering values (the default is row one if you leave it blank).  The overwrite options do not tidy the data first and allow you combine data from different sources or parts of a document or to combine payment data with timing data entered using the 'Series' button or the input columns tool mentioned above - this may need some planning, and remember that the 'Series' button does automatically tidy the entries so you need to write times or dates with that before importing the payment amounts

  • The 'last row' input is always available and tells the tool where to stop entering values, alternatively, you can enter a value preceded by '+' which tell the tool how many values to enter (note:  if you leave this blank all the available rows to the end will be filled)

  • the tool will not try to import values beyond the end of the panel's rows and if you enter a 'Last row' which is the same as the 'First row' only the first row will be imported.  The tool will object if the last row is less than the first

  • the tool will ask you to confirm overwrites eg:  'Overwrite level rows 1 to 12, are you sure?' or 'Overwrite extra rows 5 onwards, are you sure?'

  • The tool will warn you if it comes to the end of the specified or available rows before it has imported all the data in the file with the rhetorical question 'All rows filled, more data in file?'

  • The Clipboard

    even more usefully in many cases, you can also transfer data from the Windows clipboard into rows by using the 'Clipboard' button.  In fact all this does is copy the text on the clipboard into a file called 'clipboard.txt' in the Resources folder and put that filename into the 'Import data from file' box - consequently all the above rules about the format of files apply equally to text copied onto the clipboard.

    An example:

  Copying the (admittedly somewhat meaningless) data in the marked areas in either of the well know programs on the left and using the 'Clipboard' button can produce the result below. This should work with most software, including plain text editors or web browsers. You may need to take care with some formats such as PDFs as the data may not come out in the expected order.  If you hit this snag, it may help to cut and paste into a text editor such as Notepad and use this to check or reformat the text before saving and importing it

  TIP:  the clipboard.txt file is left in place once it's written.  This means you can import the same data again later by locating it with the 'Browse' button (it's in DualCalc's Resources folder and Browse will probably open in the 'Saved' folder, so you need to go up one level, down into Resources, and look for 'clipboard.txt').  This will work even if you've changed the clipboard, shut down and re-started the program, or even the PC, in the interim - the file's only changed when you use the 'Clipboard' button again.

  NOTES:

  Despite all the 'rules' above, in most cases importing data, including data on the clipboard, works quite seamlessly and may save you a great deal of time when you have to deal with a complex pattern of payments which are in an electronic format.

  After your data is loaded the relevant panel rows are 'scanned' in the same way as for a loaded calculation [see here for more information].

  Remember you can also always use straightforward cut and paste on individual entries in the calculator, this facility additional lets you transfer large chunks of data in one go.

• 'Use exact monetary amounts' - generally, when you enter or load a sum of money DualCalc will round it to the nearest penny before using it in a calculation.  This make sense because no-one can actually pay £123.45678 as a repayment, but it can be an annoyance if you are, for example, trying to check something for accuracy or use a result to illustrate a particular point and the rate or amount the program comes up with is slightly out because it's rounded the payments you entered up or down.  This tool allows you to get DualCalc to use the exact amounts you enter or load (the tool itself explains how rounding is switched back on), but remember that a statutory calculation and result should probably be based on the actual (rounded) values the borrower will pay;

• 'Adjust the displayed precision' - DualCalc (or rather the BBC BASIC language in which it is written) uses a 'format control variable' to determine how numerical values are displayed.  This is quite complex: it's a four byte hexadecimal value also controlling he conversion of numbers to strings and the format to be used, but this tool allows you to adjust the last two bytes, the first of which controls the number of digits in the output and the second the field width in which values are printed.  The default value DualCalc uses is &C0C (that's ampersand, cee, zero, cee), the '&' symbol indicates that the value is hexadecimal and '0C' is the hexadecimal equivalent of 12 decimal, so this sets the program to display values rounded to 12 decimal places in a 12 character field (the leading zero for the first byte isn't necessary).

  

  Altering this value allows you to change the precision with which rate results (and monetary amounts, if you use the previous tool) are displayed.  You might want to do this, eg, to demonstrate that your result agrees with someone else's to a given number of decimal places.  Depending on your printer setup, more digits and/or a wider field-width may make your printouts look messy - if this happens, try a smaller font.

  You can read full information on the print control variable [on the BBC BASIC website by clicking here] (but remember this tool only allows you access to the 'PP' and 'WW' bytes).  Essentially you should use precision values from 9 to F, field values from A to F and where possible they should be the same.  So the values I would suggest (in order of increasing precision) are: &90A, &A0A, &B0B, &C0C, &D0D, &E0E, and &F0F.

  This is a 'one shot' adjustment, the value you enter is not stored permanently anywhere and when you close and restart the program DualCalc will go back to its default value.

• 'Convert dates with PPA/DIY' - the program normally converts an interval between two dates to periods by calculating the interval in years and decimal parts of a year, taking account of the days in a year (DIY), and then multiplying the result by the periods in a year (PPA).

  This tool switches on converting these intervals by the alternate method of simply multiplying the number of days in the interval by PPA/DIY.

  Neither method is statutory, calculations with dates should be done in Years&days.

  Choose 'Okay' in the tool to switch to the PPA/DIY method or 'Cancel' to use the normal method.

• 'Switch off warnings' - the program can produce quite a few messages about possible problems with your calculation (see here).  If you're doing several non-standard calculations and are well aware of the things you are being warned about this can be quite annoying, so this option switches them off for you (the tool itself explains how they are switched back on).  Obviously use this with caution, and be aware that checks which would stop the calculation (rather than just check whether you want to continue) will just result in the calculation being aborted with no message at all;

Program Utilities:

These are more general or technical 'housekeeping' facilities.  Here's what they do:

• 'Save and Quit' - as it says, saves the current contents of the dialogue and calculation and quits DualCalc.  The calculation will be automatically re-loaded when DualCalc is restarted.  This is for those occasions when you want to shut down the program or the PC, don't want to lose your calculation and don't want to muck about choosing/remembering a filename.

• 'Reset options' - resets the options setup by deleting the saved information and then closes and re-starts the program so the default options are applied (see here for details);

• 'Reset templates' - for use when you upgrade (see here for details), deletes the HTML templates and then closes and re-starts the program so the default versions are built (from version 1.01a the new templates are generally distributed with the program so this shouldn't really be necessary, but this will also replace customised or mangled templates with the default ones);

• 'Print again (via browser)' - prints the last thing you printed through the browser again, even if you've done other calculations or shut down the program/PC since - this relies on the fact that the program builds the page to be printed through the browser but doesn't bother to delete it after printing, so it stays there until it's overwritten by printing via the browser again;

• 'Open program folders' - opens the 'save', 'log' and 'resources' folders so you can access the files stored there.

Add-in Tools:

These are additional external tools to be run in conjunction with DualCalc to provide extra facilities.  They can be either BBC BASIC programs, or any other file or program which your PC can open.  If you're a programmer, it is possible to add your own external tools (see here for details).

In the above example several external tools have been added:

The first two are packaged with the program.  These are small web pages containing JavaScript programs to carry out specific calculations (run them for more information):

Card Charges Calculator
Card APR Calculator


The remainder are a Windows program and Windows compliant versions of a couple of the old DOS credit programs, adapted to work with DualCalc.  These are available from my 'DualCalc Developer's' website by clicking here.

Closing the Program

When you're finished with the calculator, simply key 'Alt-F4' or click on the program's close button [X].  A query box will appear asking if you're sure you want to close the program.  Either click 'OK' to finish, or click on 'Cancel' if you've changed your mind.  There are a couple of minor anomalies with closing the program you might encounter (click here for details).

If you encountered a spurious 'Another copy/other copies of DualCalc is/are running' message when DualCalc started - ie when you know there isn't another copy running (eg because you previously had a power failure or a Windows crash and DualCalc was unable to record the fact that it had stopped running) you can remove one extra 'phantom' copy from the count of those running by holding down the 'Ctrl' key while you click on 'OK'.  If the message said there were several 'phantom' copies running you will have to do this for each one or, to get rid of them all at once, hold down 'Shift' while you click 'OK'.

The 'Information Line'

The bottom line of the program's dialogue provides general information on what's going on.  When it is waiting for your input it just displays the program's version and copyright information.

The messages you will see here include:

"Tidying data, please wait ..."
"Checking input, please wait ..."
"Inserting level, please wait ..."
"Adding extra/advance payment series, please wait ..."
"Calculating totals, please wait ..."
"Carrying out [indicates type] calculation, please wait ..."
[technical information about the calculation in progress]
"Logging calculation, please wait ..."
"Printing calculation, please wait ..."
"Printing calculation via browser, please wait ..."
"Spooling calculation, please wait ..."
"Saving calculation, please wait ..."
"Loading calculation, please wait ..."
"Saving options, please wait ..."
"Resetting data, please wait ..."