Dealing with apparent discrepancies

For various reasons, sometimes figures produced by one part of the system may not appear to correspond with those produced by another part of the system. Normally there will be a logical explanation for this in terms of the procedures which have been carried out on the system by the operators, or in the expectations of the user as regards what ought to 'tally up' with what, and not a fault in the way in which the software should work. The purpose of this section is to make your job easier in terms of making the figures 'tally up', and how to change your operating procedures, if necessary, to avoid this.

Having said this, the exact circumstances of the usage of the system are beyond the control and knowledge of PremierVet, and often also beyond the control and knowledge of other operators in the same practice, so there may be circumstances in which an explanation is not possible, and we can therefore assume no responsibility or liability for figures apparently being wrong.

One important way of avoiding difficulties is in the administration of the system. One person should be in overall charge of the system and be informed of any important events such as hardware problems, power cuts etc. For ease of communication, contact with us should be through this one system manager, and where possible or necessary, problems should be reported in writing or by fax.

Another way is by ensuring that all operators have had sufficient training in the use of the system. (Especially the system manager!). Often training new members of staff in-house is not sufficient. Contact us for details of current prices for training. Additionally, make sure that there is sufficient time allocated to administration, troubleshooting and supervision of running the system by suitably trained staff.

Chapter contents

Historic VAT book and standard VAT book

These programs work in different ways:

• VAT Book
  The standard VAT book accumulates all the work entered or changes made during the current VAT book period and includes:
  1. New work entered
  2. Over the counter sales
  3. Usage of drugs and procedures
  4. Changes made to clinical records outwith the current period
  5. Payments made
  6. Work done broken down by analysis codes
  7. Discounts taken and surcharges entered

  Figures are accumulated from the above and summarised. When the period is reset the month concerned is updated, thus allowing another option (Monthly/Yearly figures) to print out a summary for each month over the year. There can be a problem of timing at the end of the month. For example; if the VAT book is reset after morning surgery, the work entered during morning surgery will be taken as work done for the prior month.

• Historic VAT book
  The historic VAT book scans all clinical records entered during the month of the year required and will determine the total fees and drugs breaking them down by veterinary surgeon, work done per surgery and VAT.

Differences between VAT books
When a printout of the month's work is compared with a historic VAT book printout for the same month there may well be a discrepancy. This can be caused by:

1. The timing problem mentioned above.
2. Over the counter sales - as these are not recorded as a clinical entry, the historic VAT book will not pick them up.
3. Corrections - corrections can be made to clinical records entered previously on the system. The standard VAT book will record a total for corrections carried out and the month in which the VAT book is being reset will be updated accordingly, independently of the month in which the correction was made. As the correction is made to the clinical record concerned, the historic VAT book will read the changed amount, but the monthly printout covering the clinical date will have been updated with the wrong amount.
4. Operator error - if when the work is being entered, an incorrect date is used (month or year), this work is processed by the standard VAT book as being in the current month, yet the historic VAT book will use the actual transaction date.

The only problems we have come across in operation of the standard VAT book are:

1. A system failure has meant you are unable to print out a VAT book,
2. The VAT book printout has been lost

It is because of these reasons that the historic VAT book option has been included in Premvet 5. The historic VAT book should therefore not form part of the normal operating procedures in other circumstances.

Discrepancies with the monthly/yearly summary
The monthly/yearly summary is based on the figures produced by the standard VAT book each time it is reset, and is subject to the same discrepancies with the historic VAT book as the standard VAT book.

In our opinion, reconciling the historic VAT book to the summary figures might be impossible because of the above factors. Reconciling the daily VAT book figures to the monthly summary should be a matter of adding the daily figures together and this should equal the month's figures, however, the following difficulties may arise:

1. End of year - if the system has been in use for over a year, and the summary files have not been reset at the year end then the subsequent year's figures will be added to the earlier figures.

2. The daily figure printouts which are being added up do not in all cases correspond to occasions on which the VAT book was reset, thus carrying the figures on to the subsequent day. Thus the figures are accounted for twice in the daily printouts and only once in the monthly summary.

3. The operator is asked, when resetting the figures on the VAT book, which month the figures are to be allocated to. This question might have been answered incorrectly. Please note that the default month is based on the current system date, so that if resetting the VAT book for say August's figures on the morning of the 1st September, this will default to [09], so answer correctly.

4. Either the VAT book or the monthly/yearly summary may contain spurious information, for instance if you have used the system to enter 'play' information. This may have been left in either the VAT book or the summary, and is still taken into account, even though the records in question have been removed. In order to avoid this happening a) do not use records other than the 'play' record for entering 'play' information b) if you have to, make sure that the VAT book is reset and an end of year done on the summary before deleting the records. See below for the procedure to be followed for deleting this as a set of previous year's figures.

5. Any of the above problems may be more difficult to trace and more likely to happen if you are in the habit of running separate VAT books for different client types.

6. Changes may have been done during the VAT book run which will cause a discrepancy between one part of reports and another. Changes and additions during the run will not be picked up if you say 'No' to the 'Was the printout satisfactory?' question.

7. If you use the sort routine in the validation to sort transaction records into date order, a transaction which is no longer in the VAT book may appear after a transaction which is in a client's record. This means that it will appear in the detailed listing in the standard VAT book.

8. If there are more than 7278 lines in the VAT book, any after this will not appear in the report.

9. Using the VAT book override option when editing records will cause inconsistencies sometimes, as will changing the number of the 'play record'.

Miscellaneous VAT book problems

1. VAT appears not to work out at standard rate
   Whenever a transaction is added on to the system, VAT is added. As the smallest unit of currency is one penny, the computer will round the amount to a penny. If we take an exaggerated example:

   Net 10p   VAT 2p
   10 Transactions at 10p =  1 + 20p VAT (Not 17.5%)
   

   When examining the VAT book bear this in mind as 17.5% of the net total may not always come to the VAT figure. Also, of course, zero rated transactions (like surcharges) need to be taken into account, and discount VAT (if applicable).

2. Analysis codes appear to be wrong
   All work entered on to the computer is given an analysis code. The analysis code is set automatically on automatically priced items. If you were to add up, for example, all vaccinations which have been given a unique code this should agree with the total for that code. If they disagree, the discrepancies will have been entered as a manual note with that analysis code.

3. Totals column in VAT book summary page is not the same as total for individual surgeries columns to its right. Also, the totals for different payment types in the payment summary do not add up to the total payments.

   The discrepancy is due to corrections to the standard VAT book. This refers to amendments which have been made to transactions which are not in the current VAT period. If you reset the VAT book daily, this means amendments to transactions on previous days. No further details are available on the system of which transactions are involved. Such amendments ought to be rare events necessitating explicit manual documentation in your records. However please note that amendments to the 'play record' may appear in the VAT book corrections on some versions of the software.

Procedures to be followed
Often it will be obvious which figures are correct, and it will not be necessary for you to investigate further. If it should be necessary, then detailed printouts of each individual transaction entered are an indispensable starting point for you. For this reason do not be afraid to make sure all relevant printouts are done, because usually the information cannot be reconstituted after the event.

Remember that the monthly/yearly summary figures are a repository of information which can be edited in the event of this being necessary if the correct procedures are not followed. If you wish you can reset the end of year to clear the summary out altogether. If so, pick an arbitrary year that you do not have figures kept for, e.g. '83', and the figures will be stored in the file 'v6figs.83'. Then from the operating system prompt delete this file.

Different forms of clients' transaction records

1. The short form may be different from the long form, and the long form is correct. If this problem is not fixed by running through the long form, then this will always be due to the following having been done:

   At some time, a transaction record was added or edited with text beginning with 'PAID' or 'paid', i.e. by not going through the correct option for adding payments.

   You will need to find the line in question, and edit the line to begin: 'Paid', i.e. capital 'P', small 'aid', otherwise the short form routine will not function correctly. Normally of course, editing payments is not recommended. In particular, do not edit a transaction for work done into a payment or vice versa, otherwise the figures in the management record may look a bit strange.

2. The validation program may report short form errors, which on examining the client's record appear to be spurious. This will be the case with clients who have so few transactions that the short form and the long form are identical. The short form information has not been created yet and therefore contains miscellaneous garbage. This message can be ignored, and will go away when sufficient transactions have been added.

3. If the short form contains records which disappear (i.e. the records themselves disappear, not the discrepancy) when the long form is run, then that client's chain contained a corrupted record which was fixed by the validation program. As the corruption would have destroyed the pointer to the next record in the client's chain, there is no way of the chain being rejoined at the time. Either all records in the short form or the latest ones only will disappear.

   The procedure to be followed is as follows: if a validation report includes the message 'Client XXXX clinical record XXXX corrupted', print out the free list for that client and find the first transaction in the chain. Then go in to the validation program and run option 'Reset W9'.

   This will ask you for the number of the client to fix. Answer accordingly. You will then be asked '<S>hrt, <W>9 or <M>r'. Answer 'M' for MR (management record). You will then be asked 'Old W9 XXXX, enter new W9'. Re-enter the number given as the old W9 number. You will then be asked 'Reset last in the chain?'. Answer 'Y' for yes.

   Enter the transaction number of the record where the chain is to be continued from when the current incorrect end of record for this client is reached. Please note that it is possible that sequential records in a chain may not always be in ascending order, so always look at the pointer to the next record (the first number after the colon) and follow the chain through making sure all genuine records are rejoined correctly. A chain may be broken more than once. The format produced by printing out the free list will be similar to this:

   1234:1235   999    31.12.85 This is a test                  13.95
   

   This example refers to transaction 1234. Contained in this record is the pointer to the next record in the client's chain, which here is record 1235. The next number is the client number.

   The financial amount of the corrupted record(s) will need to be accounted for. Look at the management record, if correct, for this and add a balancing transaction. Then restore the management record to its previous correct state. Please note that the balancing transaction will appear in the VAT book, and you should account for this by subtracting it manually from the figures generated.

4. When <U>p is accessed, the brought forward figures appear to be wrong. This is due to financial amounts being edited on the transactions. For the purposes of the <U>p facility, information on previous transaction number and current balance at that point are kept in a 'pointers back' file. Changing the financial amounts means that this file is no longer correct. If a transaction is deleted, however, the 'pointers back' file is re- created for that client, and thus sorts out the difficulty.

5. Management financial amounts differ from transaction totals and appear to be wrong. This can happen for a variety of reasons. Either use the 'restore balances' option in the validation menu, or edit the appropriate fields in the management record.

   When asking for help on editing the two-letter codes for editing these fields are not displayed, to try to stop these figures being edited frivolously. However, the codes are FX for fees, DX for drugs, VX for VAT, and PX for payments. The figure for balance due is calculated from the first four fields.

Figures on bills/fee notes/last billed amount etc.

1. Last billed amount appears to be wrong.
   This is due to someone going back and producing a copy invoice for some month in the past. If the billing amount is zero then this does not in itself reset the last billed amount. However, when the payment paying the bill off is entered this will reset any last discount offered/surcharge threatened, so that this information is not subsequently retrieved on going through the payment routine, but it will appear in the listing of last billed amounts in the invoicing program.

2. Fee note appears not to contain up to date information
   One possibility for this is that a composite bill has been generated automatically for all the animals this client has and you were expecting the bill for an individual animal.

3. Fee note/invoice does not come out
   First check that the printer is working with other printouts. If it is not, follow the procedure in the manual for troubleshooting this problem.

   Check that the client you are attempting to bill is of the correct type for a bill of this kind to be produced. Also check the 'send bill' field.

   If you are attempting to bill a record for a related chain from a record which is not the master of the chain, this will also not come out.

   Check that you have selected the correct options on the options screen before doing the billing run.

4. There appears to be a line missing from the bill
   Check the set up to see if the billing program has been set up to ignore lines for 0.00 which contain an exclamation mark (!).

   Check the line which appears to be missing and see if there is an incorrect date on that or a prior transaction record, for example for a strange year.

5. Discount/surcharge appears to be wrong
   If you have a customised bill, check that you are running the correct program, and not the standard invoicing program.

   You may be wrongly interpreting the way in which the program works out discounts and surcharges. Discounts are based on current month's fees and drugs excluding credits. Surcharges are based on the brought forward amount. You can have surcharges on statements, but not discounts. You cannot have automatic surcharges and discounts at the same time.

   If when looking at the client billing amounts summary listing, the amounts appear in the discounts column when you think they ought to appear in the surcharge column, this is because the surcharges have been automatically added. The client is then offered the option of deducting this amount, which is similar to offering the client a discount.

   You may have spurious lines which look like payment lines, but are actually transaction lines which have been edited. Check that they say 'Paid' (with a capital 'P' and small 'aid') not 'paid' or 'PAID' etc.

   The definition file (for fee notes) may be set up incorrectly. Remember that the functioning of automatically added surcharges is akin to discounts. (See how to customise fee notes in chapter 11 and chapter 19 of the manual).

Outstanding accounts and aged debtor listings

The difference between these two listings is analogous to the difference between management record amounts and clinical record amounts. The outstanding accounts listing is based only on the management record financial amounts, while the aged debtor listing is based on the clinical records. If there is a discrepancy between management and clinical (see above for how to fix), then there will be a corresponding difference between the outstanding accounts listing and the aged debtor listing.

The outstanding accounts listing does not normally take accounts which are in credit into account, but these are included in the aged debtor listing.

If there are transactions which are out of order, especially for the wrong month and year, this will cause the aged breakdown to appear to produce spurious amounts.

If there are transactions which are later than the current system date (wrong year?), then they will be accounted for in the outstanding accounts listings, but not in the aged debtor listing.

Make sure that the selection criteria you have chosen are correct. If clients are missing from one report and are present on the other, this will be the explanation for this problem. Here are some things to look out for which are common errors: Are all client types selected? Have you got spaces in one of the selection criteria rather than the message 'Ignore'?

Automatic pricing/stock items

1. The invisible discount field (character 4 of the discount field) will cause automatic pricing to give unexpected prices.
2. Reorganising the stock while stock items are included in procedures for destocking will cause the wrong items to be destocked.
3. There are five methods of using price banding. Make sure you understand how it is meant to work.
4. Make sure that macros you have set up work the way you thought they did.
5. Sometimes the order in which parameters are entered affects how they are interpreted.
6. If you have difficulties do not enter more than one item at a time.

Asterisks (anywhere)

In writing the software every effort was made to trade off displaying as much information as possible, against limiting the range of size of figures that would be displayed, and if the figure is genuinely too high to fit in, then the missing figure will have to be worked out and inserted manually.

Differences with manual records