This is the 'official' release of the 3rd beta of Electronic Teller 2.9,
release version 2.9b3.

CONTENTS:

    - Introduction (purpose behind beta)
    - Installation
    - Files
    - Migration (using pre-2.9 accounts in 2.9)
    - Importing (from QIF files)
    - Usage (usage issues discussed briefly)
    - Service Desk 
    - Account Book 
    - Creating Transactions 
    - Postdating Transactions 
    - Editing Transactions 
    - Reconciling (Balancing) Accounts 
    - Drag and Drop 
    - First aid 
    - Budgets
    - Reports
    - Transaction fees
    - Cheque printer
    - Searching & replacing


                           INTRODUCTION 
                           ~~~~~~~~~~~~ 

This is the third and likely final ET beta.  2.9b3 contains some bug fixes 
as well as the rest of the functionality to bring it up to speed with 
2.80a, noteably reports, transactions fees, an updated cheque printer, and 
a search-and-replace function.

If you find a bug in this version, please report it by sending e-mail to

                        phcaron@travel-net.com

Also, try to provide as much information as you can about the bug:  what
led to it; can it be reproduced easily; how severe was it, etc.  I'm also
interested in knowing what users' opinions are.  Many fundamental changes
have been made to the interface in various aspects, all in the hopes of
making ET a little more user-friendly.  I may still have got things
wrong-headed, so, please, don't be shy.  Make your opinions known.


Please note that the information in this file is by no means complete.  It
provides a *brief* introduction to 2.9 -- nothing more.


                               INSTALLATION
                               ~~~~~~~~~~~~
Unzip the files in the archive to a directory and run the install.cmd Rexx
script.  You will be asked to supply a destination directory.  If you have
2.9b1 or 2.9b2 installed, you may install over that version.  See the 
'MIGRATION' topic below.

NOTE:  it's always a good idea to back up the ATM cards when installing
over a previous version.

If you are running a version earlier than the first 2.9b1, you must export
your existing ET accounts and reimport them using the QIF Converter (see
'MIGRATION' below for additional information).


                                   FILES
                                   ~~~~~
Included in the archive are the following files.  Depending upon your
needs, some may be safely deleted.  Files that are essential are prepended
with an asterisk (*); runtime dynamic link libraries are not included,
here:

    *etbook.exe    Account Book 
    etbuds.exe     Budget graphs / printing 
    etcalc.exe     Calculator 
    etcald.exe     Calendar and reminder utility
    *etdesk.exe    Service Desk 
    etprnc.exe     Cheque printer/designer
    etqifie.exe    QIF Converter (essential in importing pre-2.9 accounts) 
    restini.exe    'etdeskf.ini' INI restoration utility

    
                                 MIGRATION
                                 ~~~~~~~~~
A migration routine has been added to 2.9b2.  It's primary purpose is to
rearrange the data in the individual *.REC files for each ATM card to
accommodate a larger cheque number (10 digits from 5) and to reverse the
amounts for credit and liability accounts (something I overlooked in the
first beta's QIF converter).  Migration from 2.9b2 to 2.9b3 will 
only update the version number in the card's base.dat file.

Automatic migration is relevant *only* to cards and accounts created with
the first 2.9 beta.


                                 IMPORTING
                                 ~~~~~~~~~
To import your existing pre-2.9 ET account files, follow these simple steps
(WARNING:  do not have two copies of the program running concurrently; ET
scans the task list for window titles in order to communicate with itself.
If more than one copy exists, it will stop scanning at the first match,
which may not be the newer version):

1)  Open your existing pre-2.9 copy of ET

    i.   Open the folder containing the account(s) to be exported.  
    ii.  Select the account to export.  
    iii. Select 'Export to QIF...'  from the 'Accounts' 'Maintenance'
         submenu.  
    iv.  Check the 'Regular transactions', 'Categories', 'Classes' boxes in
         the 'ET Converter' dialog.  
    v.   Click 'OK' to invoke the file dialog, and enter a filename.  
    vi.  Repeat steps i through v for each account to be exported.
      
2)  Close ET and open version 2.9.  
3)  Recreate the folder(s) into which you want the newly-exported Accounts
    placed ('Cards -> New...').  
4)  Access the newly-created card and invoke the QIF importer ('Cards ->
    Import QIF...').

The rest should be pretty self-explanatory with the exception of a few
items.  On export, ET will use the system's country settings in creating
the date, so it is possible to have (for 31 Jan.  1995) one of the
following three formats:

    1/31/95     (US) 
    31/ 1/95    (European) 
    95/ 1/31    (Canadian)

Rather than guess at what format is used in the QIF file (or assume that it
corresponds to the system's country settings), the converter will display
the first transaction in the Date Format dialog with the date parsed in
accordance with the default (US) format.  If it looks right, then click
'OK'.  Otherwise, use the 'Up' 'Down' buttons to shift the date elements to
reflect the format, and click 'OK'.  If the format is incorrect, the
converter will import records until it reaches a date with an element out
of range.  For example, if the US (mm/dd/yy) format was used when, in fact,
the European (dd/mm/yy) format ought to have been used, as soon the
converter reaches a date whose month exceeds 12, a fatal error will be
raised and the conversion stopped.

IMPORTANT QIF IMPORT STRATEGY:  automatic (re)linking takes place during
import.  So, if you are importing 10 accounts, for example, and one account
is linked to all 10 at some point, then one of two things will happen:

1) if the account to which a transaction is linked does not exist, a flag
will be set for the transaction before it is added to the account being
imported so that it can be easily retrieved when the link account is later
imported.  

2) if a link account already exists, one of the index files will be scanned
for a possible match to relink the new transaction with an existing one.
If a match does not exist, a new transaction will NOT be created.  Instead,
it will be logged in a separate window and displayed along with any other
failed links when the last imported record is complete.  For each failed
relink, an entry in the window will appear as follows:

    SOURCE ACCOUNT:     <Name of account being imported>
    TARGET ACCOUNT:     <Name of account link account>
    DATE (mm/dd/yyyy):  date of transaction in US format
    [NUMBER:            cheque number]    --| these are mutually exclusive
    [CODE:              transaction code] --| and appear if applicable
    PAYEE/DESCRIPTION:  transaction particulars
    AMOUNT:             amount of transaction
    CLASS:              (only if applicable)
    MEMO:               (only if applicable)
    ----------------------------------------------------------------------

The information in the window can either be saved to file or printed.  If
it is deemed that this transactions should be rekeyed, then you will have
some knowledge of what goes where.

3) If a match is found, relinking will take place automatically.

In order for a match to be deemed valid, all but the category and amount
fields of the source and link transactions must correspond exactly.  If a 
match is not found with an exact date comparison, then the date will be 
expanded to the source transaction's month (that is to say, regardless of 
the actual day within the month).  If still no match is found, the link 
will be considered failed, and the source transaction logged to the dialog 
mentioned above.

Previously, I suggested that the order of imported accounts might prove 
important, and it has, but not for the reasons I gave, i.e. a time-saver. 
The QIF Converter was reworked again for the 3rd beta and the a number of 
accounts imported in random order.  The outcome was always the same, and 
correct.

                           USAGE - SERVICE DESK
                           ~~~~~~~~~~~~~~~~~~~~
The Service Desk remains largely unchanged with the exception of sizeable
container windows (position the mouse over the vertical bar, press RMB &
drag).

The 'Folders' paradigm has changed in 2.9 for two reasons:  

1) folders don't quite make sense for a program called 'Electronic Teller',
but an ATM (Automatic Teller Machine) card does; 
2) I hope that moving away from the 'Folders' term will clear up the
confusion that has existed in the past, e.g.  Why can't I move accounts to
another folder?  etc.  Like all ATM cards, ET's cards can be set up to
access many accounts, and you can access other accounts on other cards if
these are setup as such, but that's about the extent of it.  At any rate,
setting up new cards remains largely unchanged with the exception of
terminology.

Creating accounts is slightly different in two respects:

1) The date field has been replaced by a calendar.  Selecting the date in
the calendar is sufficient to inform ET that the initial transaction is to
be dated that selected date.

NOTE:  initial transaction dates are treated loosely in 2.9.  Although an
account's creation date can be 1 Jan.  1996, for example, with a starting
balance of $1.00, a subsequent addition to the account on 31 Dec.  1995 to
the amount of $2.00 will transfer the creation date from Jan.  1 to Dec 31
as well as the initial balance.

2) Closing the notebook creates the account.  This is to ensure that the
notebook is more CUA compliant.  If the account name entryfield is left
blank, no account will be created.


                           USAGE - ACCOUNT BOOK
                           ~~~~~~~~~~~~~~~~~~~~
The Account Book has changed dramatically from an end-user point of view.
The single container has been placed into a notebook and replaced by an
owner-drawn listbox.  The notebook will contain pages for each year a
transaction in the account exists, from latest to earliest.  This means
that, for an account with transactions spanning 1995 to 1996, two pages
will be initially displayed in reverse order (1996, 1995).  All records for
1996 will be loaded into the listbox on startup.  The 1995 records will be
loaded only if the notebook page is selected.  The amount of records loaded
per pass is determined by the size of the listbox window.  If, for example,
it is estimated that the window will contain 50 records, the records will
be enumerated approximately 50 at a time (the date determines the actual
number, but it will never be less than the amount of records that can fit
in the visible portion of the listbox) with a one-half second pause in
between each load, until all records are loaded.  The one-second pause
exists to allow the user to perform duties while the loading process is
underway, so that he/she doesn't have to sit idly while ET is churning
away.

ET manages this by serializing access to the data files.  Although tests 
have shown pretty good stability, here, it's a good idea not to try 
invoking a function before something appears in the listbox.

Many of the icons have also been changed.  Two reasons for this.  First of
all, I lost all my old icons following a complete C:  drive failure.
Second, the old ones were, well frankly, somewhat ugly.  If in doubt, watch
the status area of the window while moving the pointer over the icon.  It
should tell you what its purpose is.

Some buttons in the button bars are also somewhat specialized, providing
access to different functions depending upon the state of the Ctrl key when
the button is clicked.  The trashcan button, for example, will delete
transactions or, if deleted transaction are selected, shred them.  If the
Ctrl key is depressed when this button is clicked, the selected
transactions will be restored, or undeleted.  Again, watch the status area
for clues.  A word about shredding:  SHREDDED RECORDS CANNOT BE RESTORED.


                       USAGE - CREATING TRANSACTIONS
                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Major changes, here, too.  The notebook has been replaced by a single and
more straightforward (I hope) dialog box.  Moreover, it is no longer
possible to add transactions to multiple accounts in a single session.  All
transactions are added to the account from which the dialog was invoked (or
the selected account if invoked from the Service Desk).

To create a transaction (from the Transaction dialog), follow these steps:

1) Double-click on a calendar date

    OR  go to the date field and use the Up/Down; Ctrl+Up/Ctrl+Down keys to
        scroll to the desired date

    OR  enter the date manually.

If you opt for the 3rd option, enter it correctly, in accordance with your
system's country settings, i.e.  mm/dd/yyyy or dd/mm/yyyy or yyyy/mm/dd.

2) Go to the Number field and enter either a cheque number of a transaction
code, i.e.  ATM.  Line completion is available here, so if ATM already
exists, typing 'A' will expand the field to to first code matching that
prefix.

    OR  if a cheque, simply enter '!'  (without the single quotes).  This 
        will assign the next cheque number in the series to the Number 
        entryfield when you go to another field.

    OR  press the F2 key to get a popup listbox of existing transaction 
        codes

    OR  right-click anywhere in the entryfield for the list

    OR  press the Up/Down keys to scroll the existing list

Any numeric value entered into this entryfield is considered a cheque.  A
numeric value is anything that begins with a number, e.g.  123ABC will be
interpreted as cheque #123.  On the other hand, ABC123 will be considered a
code in its entirety.

3) Go to the payee field and enter the payee or particulars.  If a
memorized transaction exists for this information, the field will be
expanded to contain that information (as well as the credit or debit,
category, class, and memo fields).  If the transaction code field is blank,
it, too, will be given a value if one exists for the memorized record.

    OR  press F2 to get a list of existing memorized transactions

    OR  right-click in the window for a view of that list.

    OR  press the Up/Down keys to scroll the existing list

If a memorized transaction exists, is displayed, and contains a cheque
number, you will be asked if you would like the next cheque number in the
series applied to the item.  Replying 'Yes' will assign the next number to
the Number field.  'No' assigns the memorized number to the Number field.

If you choose not to accept the memorized transaction, press F3 to undo the
changes made by the expansion.  All but the 'Particulars/Payee' fields will
be returned to their state prior to the expansion.

4) Enter a value in the Credit field

    OR  enter a value in the debit field.

If both fields are 0, you will be requested to confirm the transaction
before it is entered into the container.

If both fields contain a value that is not zero, the transaction will be
rejected.

5) Tab to the category field and enter your data (line completion applies)

    OR  press F2 for a list of existing categories

    OR  right-click anywhere in the entryfield for a list of existing 
        categories

    OR  press the Up/Down keys to scroll the existing list

6) Tab to the class field and enter your data (line completion applies)

    OR  press F2 for a list of existing classes

    OR  right-click anywhere in the entryfield for a list of existing 
        classes
    
    OR  press the Up/Down keys to scroll the existing list

7) Tab to the memo field and enter your data

8) Click 'Append' to create a regular transaction

    OR  click 'As Split' to create a split transaction for the selected 
        regular (or parent) record in the container

Splits must have a valid parent record selected in the transaction
container.  If none is selected or exist, the 'As Split' button will be
disabled.  When a split is created, it will be added to the container as a
child of the parent, in standard OS/2 container usage, i.e.  a + enclosed
within a box will appear to the left of the parent container record.
Expand the container to view, or edit, or 'Remove' splits.

New records that appear in the transaction container are not actually
written to file until the 'OK' button is clicked to dismiss the dialog.
This allows you the opportunity of making changes, removing records, etc.
before actually committing the records to file.

Once a record has been 'Append'ed to the container, you can then elect to
memorize it (by checking the 'Memorize' box) or postdate it (by checking
the 'Postdate' box).


                      USAGE - POSTDATING TRANSACTIONS
                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Postdated transactions appear in the account ledger using a half-toned text
attribute -- it's slightly more difficult to read, but *is* readable and
clearly denotes a postdated entry.  The amount of the transaction is not
tabulated into the overall balance.

To postdate a transaction, first select it from the transaction container,
and click the 'Postdate' checkbox.  If the transaction is successfully
postdated, the box will remain checked.  You can either remove postdating
by unchecking the box, or edit the postdated options by clicking the 'Edit
postdate...'  button.

Postdating transactions is somewhat different from previous versions of ET.
Most important is that postdated options are saved in 'setups'.  In order
to postdate a record, a setup must either already exist, or one must be
created.  When the Postdate dialog is invoked on a transaction that has not
yet been postdated, it's 'Particulars/Payee' information will be displayed
and suggested as a postdate setup name.  If such a setup already exists,
the options previously defined will be preselected.  You can either leave
them unchanged or make alterations.

WARNING:  any changes made to a setup has a card-wide affect.  That is to
say, if you change the frequency of an existing setup entitled 'First of
Month', all records making use of that 'First of Month' setup will be
affected.  Similarly, if you delete the 'First of Month' setup, all records
making use of that setup will no longer be postdated!

NOTE:  the calendar/reminder utility shares the postdate dialog but its
setups are independent of all ATM cards.  IOW, deleting a reminder setup
has no effect on any transaction in any account on any card.

All postdate options are preserved when the dialog is dismissed.  So,
making changes to an existing setup are not preserved if the 'Cancel'
button is clicked.  Similarly, options for a new setup are preserved when
'OK' is clicked.  To create a new setup, enter a name in the combobox and
click 'Add'.  To delete an existing setup, select it from the combobox and
click 'Delete'.  To change a setup's name only, select it in the combobox,
make the necessary changes, and click 'Change'.

There are now four possible postdate frequency options:

1) ONE TIME

    Select this option if the transaction is postdated but is not to be
    repeated after the expiry date is reached.

2) SIMPLE

    This is the simplest to set up.  Any combination of the three spin- 
    buttons (Days, Months, Years) is permitted.  So, setting them to:

        Days <1> Months <2> Years <3>

    will advance the transaction's next date to 3 years, 2 months, and 1 
    day from the moment day it becomes due.

    The maximum values for each spinbutton are:

        Days:  31 Months:  11 Years:  99

3) RECURRING DATE

    There are two spinbuttons in the 'Date options' groupbox with possible
    values enclosed within angled brackets:

        On the <1st to 31st> 
        of every <month>, <2nd to 11th month>, <Jan to Dec>

    The first spinbutton represents an actual monthly calendar date.  If 
    you select the '31st' obviously not every month has 31 days.  ET will
    assume that you mean on the last of month and adjust the next date
    accordingly.

    The second spinbutton can be set to repeat monthly '<month>', every <x>
    month, or every specific month '<Jan> ...  <Dec>'.  The syntax should 
    guide you in creating a valid postdated transaction.

4) RECURRING WEEKDAY

    This is the most flexible of all, but also the most difficult to setup.
    There are three spin buttons, with possible values enclosed within 
    angled brackets:

        On <1st to 4th>, <last> <Sun to Sat> 
        of every <week>, <2nd to 4th week>, <month>, <2nd to 11th month>

    Again, let the syntax be your guide.  If you are creating an entry for 
    a bi-weekly paycheque, deposited into your account every second Friday,
    then you would spin the buttons as follows:

        On <---> <Fri> of every <2nd wk>

    If, on the other hand, your account is deducted on a specific day of 
    the month, every month, and, if that day happens to be the last Monday 
    of the month, you would spin the buttons as follows:

        On <last> <Mon> of every <month>

    A number of verifications are made before postdated options are 
    accepted:

        1)  the transaction's initial date of the month must correspond to 
            the postdated date of the month, where applicable.  

        2)  the transaction's week in the month must correspond
            to the postdated week option, where applicable.  

        3)  the transaction's weekday must correspond to the postdated 
            option's weekday, where applicable.


                       USAGE - EDITING TRANSACTIONS
                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To edit one or more transactions, select them from the Account Book, and
select the 'Edit...'  menu item

    OR  press <Enter>

    OR  press and hold the Ctrl key and click the transaction button

    OR  invoke the transaction dialog and drag selected records into the
        transaction container while holding the 'Ctrl' key

Any of these actions will invoke the Transaction dialog into which the
selected records will be displayed in the container.  Double-click on the
records to recall their values into the entryfields, make the changes and
click 'Change'.

Changes are not actually committed to file until the dialog is dismissed by
clicking the 'OK' button.  You can, if you wish, add additional records by
following the above procedures or by holding the Ctrl key and dragging one
or more transactions from the Account Book container into the Transaction
dialog's container.  You can also also create additional records at this
time by following the instructions outlined in the 'Usage - Creating
Transactions' topic.

There is no limit on the number of transactions that can be created and/ or
edited in one session.  The only limitation is that all transactions are
destined for the same account, and additional instances of the dialog are
not permitted.


                      USAGE - RECONCILING AN ACCOUNT
                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Account reconciliation has been greatly simplified, as well.  The
cumbersome dialog of pre-2.9 has been replaced by a more user-friendly
version.  The dialog itself is divided into two parts:  

    1) entryfields, 
    2) listbox.

The entryfields are used to specify certain necessary pieces of information
required for a valid reconciliation:


Previous balance:  specifies the ending balance at the last recon-
ciliation, or the accounts starting balance if working from a new account,
or the sum of all cleared transactions if working from an imported QIF file

Increase by:  specifies all credits that should be applied to the
account being reconciled, such as interest payments made to you during the
period between the last reconciliation and the reconciliation date or any 
other item that increases the account's balance.

Decrease by:  specifies all debits that should be applied to the account
being reconciled, such as fee payments deducted from your account or
charged to your account; in short, all items that deduct from an account's 
balance.

New balance:  specifies the balance as it appears on your statement.

Statement:  is the date upon which the reconciliation is to take place.
Typically, this will mirror the date of the statement.

When these data are entered, you can begin clearing transactions by
double-clicking on those that are to be cleared (or selecting them and
pressing <Enter>).  Cleared transactions are denoted by a check mark to the
left of the transaction.  To unclear a transaction, simply double-click on
it a second time.  (Un)clearing a transaction automatically moves the
cursor to the next record.  If there are more transactions in the listbox
than will appear in the window, the window will be scrolled so that it is
situated at the second-to-top-most position in the listbox (this may take
some getting used to).

As transactions are cleared, the (+), (-), and (=) status areas of the
window will be adjusted to reflect the total credits, debits, and balance
respectively.  When the (=) area's amount matches that entered in the 'New
balance' entryfield, ET will consider the reconciliation to be accurate 
and will sound a beep. Any difference between these two amounts will be 
reported when the 'Reconcile' button is clicked, allowing you to abort the
final stages.  Of course, adjust the 'New balance' manually will fool ET
into thinking that all is well, but this is not a recommended practice.
The oversight is intentional, however -- a sort of fudge factor that is
there if absolutely necessary.


                           USAGE - DRAG AND DROP
                           ~~~~~~~~~~~~~~~~~~~~~
Version 2.9 makes extensive use of OS/2's drag & drop capabilities.  ET
complies with the standard OS/2 drag & drop options, e.g.

    Move = drag button 
    Copy = Ctrl + drag button 
    Link = Shift + Ctrl + drag button

Here, briefly, is a list of what can be done:

    Move    ... permitted to any opened account book on the same card

            ... permitted to any account icon in the Service Desk on the 
                same card

            ... disallowed if the source and target accounts are the same 
                (obviously)

            ... permitted when dragging an ATM card or selected accounts 
                to the shredder

    Copy    ... permitted to any opened account book or account icon in 
                the Service Desk, including the source of the drag, but not 
                to accounts on different cards

            ... permitted when dragging selected transactions to the 
                transaction dialog container.

            ... permitted when dragging an ATM card or selected accounts 
                to the shredder

    Link    ... see below

            ... permitted when dragging an ATM card or selected accounts 
                to the shredder

Links require special consideration given the fact that a listbox is used
rather than a container, which means that there is no sure way of knowing
if a record has been dropped on a record or white space.  Here are the
following rules for valid linking:

1) If the source window has multiple records selected, the target must not
have any selected.  An accepted drop will copy the selected source
records into the target account and link them.

2) If the source window has one record selected as does the target window,
no new record will be created; rather the source will be linked to the
target and neither record values will be altered, with the exception of the
category which will reflect the linked account's name within square
brackets.

The long and the short of this is:  if you want to link with an existing
transaction in the target account, select it before initiating the drag.
If you want to duplicate records from the source in the target account,
deselect all records in the target and select the relevant records in the
source before initiating the drag.


                                 FIRST AID
                                 ~~~~~~~~~
If your account(s) appear to suffer irrevocable damage, have a look at the
first-aid option from the Service Desk.  Selecting an account and invoking
first aid will allow you to repair three things:

    1) ending balance or ('Sums') 
    2) damaged index files ('Indices') 
    3) forward balance error ('Balance')

Electronic Teller maintains a sums table for every year an account has a
transaction, and displaying a running balance is largely contingent upon
the accuracy of this table.  If your running balance appears to be off,
click the 'Sums' button in the first aid dialog.

To speed things along, ET uses index files.  The bulk of the data, however,
is kept in the *.REC file in the ATM card's directory.  If this key file
ever becomes corrupted, you have only a backup to fall back upon.  If, on
the other hand, one or more index files become corrupted, click the
'Indices' button in the first aid dialog.  This will read the entire *.REC
file and reconstruct the indices, sums table, and forward balance.

Reconciliation depends a great deal upon an accurate forward balance (your
initial balance when the account is first created or your last reconciled
balance).  This can be repaired by clicking the 'Balance' button in the
first aid dialog.

Of course, there's nothing as safe as a backup, and ET makes this process
even safer by creating an ascii file of the card's entries from the
etdeskf.ini file -- a global ATM card file used to save such things as the
sums table I mentioned above.  This ascii file can be used to reconstruct a
card's INI entries with the 'restini.exe' utility.  What this utility will
do is read the 'etdeskf.rc' file, restoring code handles and names,
memorized transaction handles and structures, category handles and
structures, class handles and names, cheque design structures, postdated
setups, as well as the budget entries (budgeted and actual amounts) and the
accumulated bank fees.  Do not rely on this utility completely, because it
is only as good as the last backup.


                                  BUDGETS
                                  ~~~~~~~
Budgets are complete.  If budgets exist for your categories in the QIF
file, then they will be automatically imported by the QIF converter.  Note,
however, that ET will permit multiple budgets, based upon a year.  So, it
is possible, therefore, to have a budget for a subcategory named
'Utilities:Electricity' for both 1995 and 1996.  During import, the current
system year is always used.

To create a budget, you must invoke the Settings notebook (Card -> Settings
from the Service Desk), (Records -> Settings from the Account Book), or
'Settings' in the Transaction dialog.  The page labelled 'Budgets' contains
a number of controls.  Simply select the category for which the budget is
to be created and enter the appropriate amounts in the twelve entryfields.
Click 'Save' to save the budget amounts for that category.  You can copy an
entire category budget from one year to another by selecting the budget and
selecting the target year in the second spin button.  Click 'Copy' and then
'Save' to preserve the budget.  'Undo' will always revert to the previous
amounts.

Budget graphs and printing are available from the Service Desk once an ATM
card has been accessed.  Upon startup, the 'Summary' graph will be set as
the default.  Clicking the 'ref' button to the right of the 'Trans.  Year'
spin button will read in the relevant data from the account(s) and begin
plotting the graph.  There are three types of graphs available:

1 - Income or Expense Category

This will display a breakdown of the budgeted and actual amounts for a
category throughout the entire 'Trans.  year'.  The 'Budget year' will be
used for purposes of comparison.

2 - Income or Expense Group

Depending upon the list of categories displayed, this option will total the
budgeted and actual amounts for each displayed category and display a
breakdown of those totals for each month of the 'Trans.  year', using the
'Budget year' budget.

3 - Summary

This graph will display a total of the following six items:

    i   - Budgeted Income 
    ii  - Actual Income 
    iii - Budgeted Expense 
    iv  - Actual Expense 
    v   - Budgeted Income less Expense 
    vi  - Actual Income less Expense

To view graph #1, simply double-click on the desired category in the
listbox.  To view graph #2, click the 'Group' button.  And, to view graph
#3, click the 'Summary' button.  To apply a budget defined for another year
to the transac- tions for a specific year, spin the 'Budget year' button
and click the 'ref' button to the right of that button to refresh the
display.  To view results for a specific transaction year, spin the 'Trans.
year' button and click the 'ref' button to its right to refresh the
display.  Depending upon the amount of records for a given year, refreshing
the transaction year can take anywhere from a few seconds to a minute or
more.  The process is threaded, and can be cancelled at any time by
clicking the 'Close' button.  Summary and Group graphs are also threaded
and can also be cancelled by clicking the 'Close' button.  Only the
accounts which are selected in the 'Accounts' listbox will be included into
the actuals amounts for both graphing and printing.

To print a budget, click the 'Print...'  button, select a printer (the
printer will be remembered from session to session), select what type of
category to include in the budget report (either Income and/or Expense),
and, if you would like empty budgets (those that have neither a budget or
actual amount for the entire year) included, check the 'Include empty' box.
Click 'Print' to begin the process.  Click 'Cancel' to abort the print job.

What is included in a budget graph and report is any transaction with a
valid category.  This includes regular and split transactions.  ET does not
differentiate between a regular and split transaction, so if a category is
specified for both the regular transaction and each split, duplication will
occur.  What is not included in the actuals totals are records that have
been flagged for deletion or postdated transactions.


                                  REPORTS
                                  ~~~~~~~
Creating a report is a simple matter of selecting the accounts from the ATM
card, selecting the desired type, and specifying a 'From:' and 'To:' date 
range.  This is commong to all report types.  Some types require additional
user-interaction.

Five report types are available:

    1)  Transaction
    2)  Budget
    3)  Cheque Usage
    4)  Unreconciled Records
    5)  Transaction Fees


TRANSACTION reports list account contents in the following order:
~~~~~~~~~~~
        Date    Code  Description  Memo  Category  Clr Amount

Date        contains the transaction's date, formatted in accordance with 
            the system's country settings.
Code        contains either the transaction's cheque number of code, e.g. 
            ATM.
Description is the transaction's payee or particulars.
Memo        is what it states
Category    is a combination of category:subcategory/class or whatever
            will fit on the line.
Clr         will be either blank if the transaction is neither cleared nor 
            a split; 'X' if the transaction is cleared; '-s-' if the 
            transaction represents a split.
Amount      is a signed amount


A number of subtotalling options for this report are available. 
These are:

    1) None
    2) Weekly
    3) Two weeks
    4) Half month
    5) Monthly
    6) Quarterly
    7) Six months
    8) Yearly
    9) Category (family)
   10) Category (single)
   11) Class
   12) Payee

The 'Category (family)' option subtotals by an entire category type, e.g.
transactions using, for example, "Utilities:Electricity" and
"Heating:Electricity" will be subcategorized individually.  The categories
that are included are selected by the user, and only those that appear in
the selected account(s) are made available.

The 'Category (single)' option subtotals by individual category items. 
For example, if the 'Electricity' subcategory were selected, the two 
category families "Utilities:Electricity" and "Heating:Electricity" 
would be subtotalled together, since they share a common child, i.e. 
"Electricity."  Again, the categories that are included in the report are 
user-selected.

Subtotalling by Class and Payee is also user-selectable.  That is to
say, only those classes and payees for which a transaction exists will be
made available, and those that are selected will be included in the report.


BUDGET reports subtotal by category thus:
~~~~~~
    Category        Budget      Actual      Difference      Mth

                                                            Jan
                                                            Feb
                                                            Mar
                                                            Apr
                                                            May
                                                            Jun
                                                            Jul
                                                            Aug
                                                            Sep
                                                            Oct
                                                            Nov
                                                            Dec

The first step in creating a budget report is selecting the categories that
are to be included, both from the 'Income' and the 'Expense' lists.  If you
wish to omit a category type entirely, simply uncheck the box beneath the 
list.  The next step is selecting the months that are to be included for 
each budget and actual months.  These are preselected based upon the 
previously selected date range, but can be changed prior to generating the 
budget report.  Any unselected month will be assigned budget, actual, and 
difference values of 0 to avoid skewed or incorrect totals.


CHEQUE USAGE reports make use of the same format as the Transaction report.
~~~~~~~~~~~~
A Cheque Usage report picks all the transactions within the date range that
contain a valid cheque number.  Numbers are listed in reverse order and any
missing or duplicate cheques are enumerated at the bottom of the report.  A
special note about duplicate cheques:  if a link exists for a cheque, and 
both the source and link accounts are included in the report, then a 
duplicate entry will appear.  This erroneous duplication could be avoided, 
but would require additional code to overcome what could be seen as a 
feature.


UNRECONCILED RECORDS reports make use of the Transaction report format.
~~~~~~~~~~~~~~~~~~~~
This report lists all records that have yet to be cleared.  Rather than 
leave the 'Clr' column blank, three dashes (---) appear so that a manual 
checking can be performed if desired.

TRANSACTION FEES reports makes use of Electronic Teller's transaction fees
~~~~~~~~~~~~~~~~
The Transaction Fees report also makes use of the Transaction report 
format, except each defined transaction code, e.g. ATM, WIT, etc. is 
grouped on a per-month basis, and after each month for each code, a 
breakdown like the following is shown:

(1)    ATM transactions for August 1996:               10
(2)    Free transactions per month:                     3 
(3)    Free exceeded by:                                7

(4)    Minimum monthly balance:                    700.00
(5)    Minimum balance required:                 1,000.00
(6)    Amount owing if balance met:                  3.50
(7)    Amount owing if balance shortfall:           10.00
                                                 ========
(8)    Total owing:                                 10.00


The numbered lines are as follows:  (1) is the number of codes found for 
the month; (2) the amount of free transactions defined in the Settings 
notebook for this code per month; (3) the number of transactions exceeding 
the free count; (4) the account's minimum monthly balance; (5) the minimum 
monthly balance required to qualify for 'Free' transactions, as defined in 
the Settings notebook; (6) the amount owing if the minimum monthly balance
is met (amount * (total count - exceeded count)); (7) the amount owing if
the minimum monthly balance was not met (amount * total count); (8) the
total amount owing for the given code for the given period -- either (6) or
(7) but not both.  In the above example, it is assumed that each 'ATM'
transaction costs 1.00 on a balance shortfall and .50 if the balance is
met.  Ten transactions were found with a minimum monthly balance of 700.00,
300.00 less than the required minimum.  Because the miminum balance has 
not been met, the cost associated with the shortfall is assigned to the 
'Total owing' (8) row, or 10.00.  If the balance had been maintained, then 
the amount owing would have been 3.50 ( .50 * ( 10 - 3 ) ).

At the end of the report, all the (8) are tabulated to present an overall 
total of all transaction fees for the defined period.


TRANSACTION FEES
~~~~~~~~~~~~~~~~
To create transaction fees, select an account from the Service Desk or open
an account book, and invoke the settings notebook.  The final page, 
entitled 'Fees' will be displayed.  Simply turn to that page.  You will see
a list of all codes defined for the account.  Select then codes for which a
fee is to be created, and tab to the first of the four entry fields below. 
These are:

(1)    Free items per month:
(2)    Minimum balance req'd:
(3)    Cost if balance not met:
(4)    Cost if balance met:

(1) represents a count of items for which no charge is attached if the 
minimum monthly balance is met.  In other words, this item affects only the
'Cost if balance met' item.  (2) represents the minimum monthly balance 
used to determine if the count of items should be adjusted and whether a 
cost should be applied to the '...balance not met' or '...balance met' 
items.  (3) represents the charge per transaction if the minimum monthly 
balance is met (cost * (total count - free count)).  (4) represents the 
cost if the minimum monthly balance is not met ( cost * total count).

Transaction fees are relevant to individual accounts in individual ATM 
cards.


                              CHEQUE PRINTER
                              ~~~~~~~~~~~~~~
When the cheque printer dialog is first invoked, two listboxes appear with 
associated buttons beneath each.  The left box, 'Queued cheques' contains a
list of all cheques transactions that were selected prior to invoking the 
printer.  'Designs' contains a list of all existing designs.  Initially, 
this listbox will be empty.  In order to print cheques, a design must first
be created.  Do so by following these steps:

1)  Click 'Create...'
2)  Assign the design a name ('Design:')
3)  Specify the number of cheques per page.  This number is used in both 
    determining the amount of space between cheques on multiple cheques 
    printing and in deciding when to send the printer a new page command.
    Possible values range from 1 to 5 or continuous.  The 'continuous'
    option means, simply, that no new page code will be sent to the
    printer; instead, it will be assumed that the cheques are not on
    indidivual sheets of paper but on continuously fed paper.
4)  Determine the dimensions of an individual cheque in millimeters.  
    these are important in two respects:  (1) the width will determine the
    amount of space cheque fields can be dragged.  If you require an 
    unusual left margin, you can increase the width of the cheque to create
    greater horizontal space.  The height is important in determining the
    spacing in between cheques if more than one cheque exists per page.
5)  The 'Window scale:' is used solely to accomodate the design window
    to your display so that the size can more closely match the actual
    cheque dimensions.  On my display (small font @ 1024x768), the scale
    of 4 is ideal.  Possible values range from 1 to 10.
6)  If the cheque number is to be printed, check the 'Print cheque number'
    box.
7)  If the dates are to be combined, e.g. '1 Jan 96' rather than '1 Jan' 
    and '96' as separate fields, check the 'Combine date fields' box.
8)  If your cheques accomodate stubs, check the 'Cheque includes stub'
    box.
9)  Drag the fonts you want to use for the individual cheque fields to
    the Cheque Design cheque fields.  Because the font use will affect
    the positioning of the printed item, it's a good idea to do this
    before actually dragging fields.
10) Begin positioning the individual fields.  Bear in mind that the 0x0
    coordinate corresponds to the lower left-hand side of the window.  So,
    measure your fields from bottom left to top right.  Bear in mind, 
    also, that the X:  and Y:  coordinates are merely an approximation; and
    so this is mostly a trial and error sort of endeavour.  To test your
    design, click the 'Test...'  button on the 'Design Setup' dialog.
    The status area of the window will inform you of a field's position
    and font as the mouse is moved over the field.  The 'X:' field 
    reports the item's horizontal position, from the left-hand side of
    the window; the 'Y:' field reports the item's vertical position from
    the bottom of the window.

Once you have created one or more designs, select the one you want to use 
for the printing session, and click 'Print...'  If you wish to remove any 
cheques from the print list, simply select them and click 'Remove'.  As 
each cheque is spooled, a check mark will appear to the left of the item.


                           SEARCHING & REPLACING
                           ~~~~~~~~~~~~~~~~~~~~~
To search and optionally replace transaction data, click on the magnifying 
glass in an account book.  This will invoke the 'Search and Replace' dialog
from which a search is defined and an optional replacement string 
specified.

Any of the following 6 transaction fields can be searched:

    1) Number or Code
    2) Payee or Description
    3) Amount
    4) Category
    5) Class
    6) Memo

And, any of the following 3 transaction status options can be applied:

    1) Deleted
    2) Postdated
    3) Voided


The desired option is selected from the 'Field' combination box.  If the 
'Status' is set to 'None', then no filtering is performed during a search.
That is to say, any record matching the search criteria, regardless of 
whether it is cleared, deleted, postdated, uncleared, or voided, will be 
included in the results list.

If a status is specified, then only those transactions which meet the 
status requirement will be considered for inclusion into the results list. 
If a 'Search' criterion is also specified, then the transactions in 
question must also meet thosee requirements.  NOTE:  that no search
criterion need be entered when searching for transactions of a given
status.  If the 'None' status is selected, then a search string must be
provided in order for the search to take place.

Next, a date range for the search is entered.  The 'to' date is inclusive. 
As elsewhere in Electronic Teller, the [Ctrl] PageUp/ [Ctrl] PageDown keys 
can be used to cycle the date by [month] and day.

The 'Search' is where the search string is entered.  If you are searching a
code, payee, category, or class, you can right-click in the search field
(or tab to it and press F2) to get a list of existing items.
Alternatively, you can enter any complete or substring.  

If you wish to limit the search by case or exact match, check the 
appropriate boxes beneath the 'Search' entryfield.  If the case checkbox is
left unchecked, the search and found strings will be converted to uppercase
prior to examination.  If the exact box is left unchecked, the found string
will be searched to determine if it contains the substring specified by
'Search'.  Thus, a payee search of 'wit' will result in a hit for all
payees containing that string, e.g.  withdraw, withold, Joe Witaker, etc.

If you wish to search split transactions, ensure that the 'Omit splits in 
search' box is left unchecked.  By default, splits not included in 
searches, although they are not available if specifying a status criterion,
since, by definition, if the parent is deleted, postdated, or voided, so,
too, are the splits.

Before any 'Replace' can take place, the search must first be executed.  A 
replace can then proceed only if at least one 'hit' was made.  If you 
attempt to replace a code, category, or class with an item that does not 
exist, you will be asked if you would like to create that item.  If you
answer No, the replacement will not take place.

The 'Options' menu contains a number of options, much like those that are 
found in all account books' 'Record' menu.  You can, for example, delete or
undelete, shred, void or restore, create or edit transactions.  The same 
text attribute and colour sequence used in account books is also used in 
results list box.


