Transaction Import

Use this utility to load transactions into CAPITAL from external files. The external files being imported must have been generated by the CAPITAL File Export utility.

You can only import and export transactions between the same versions of CAPITAL. If you wish to export transactions for import into another copy of CAPITAL, be sure that both systems are upgraded to the same version and revision number. Only then perform the export.

If you are loading customer or supplier transactions into the system and transactions already exist with the same transaction numbers, CAPITAL will not import them. You will be given the option to print a report of all transactions that clashed, and were not imported.

If you are loading other types of transactions into the system, CAPITAL will give you the option to abort the import or replace the transactions already in the system.

Issues Involved In Loading Transactions From Other Companies

If you wish to load transactions entered in other companies, into your own company, then planning and organisation will be required. The main issues to consider are:

1. Transaction Number Sequences

Has each company been given a set of unique/distinct transaction or audit numbers to issue? For example, your first company may work with the transaction number range 100000-199999, your second company with the range 200000-299999 and so on. However, it would be better to uniquely prefix transaction numbers for each company.

For example (to use a somewhat simplistic example), your Victorian state office might start with the prefix V for all invoice transactions. They could then issue invoice numbers from V1000- onwards. Queensland might have the prefix Q and issues transactions from Q1000- onwards.

Besides the benefit of making an accidental clash between sets of transactions impossible, CAPITAL permits you to lock the transaction sequence of a number range, so that users cannot accidentally change the assigned number sequences.

To change the number sequence, run the INSTALLATION Workshop program, and then select from the Install menu Advanced|Transaction Sequences. See Transaction Sequences Setup for more information.

Each transaction's transaction number must be unique to the system. If a transaction number already exists, CAPITAL will not import that transaction. (You can print a report listing all transactions that were not imported due to such clashes.) If you have planned carefully, there should be little or no transaction number clashes occurring.

2. Managing Changes

Transactions exported out of CAPITAL are done so based on a specified date range. For example, all transactions from the 1st of June 2000 to the 31st of June 2000. What happens if a user exports these transactions, gives them to you, then makes a change to one or more of the transactions in this date range?

Even if they export the same data and send it to you again, you will be unable to load it into your system and update your records with the changes. This is because the import utility will refuse to import transaction numbers that already exist in your system. (At least for customer and supplier transactions.)

CAPITAL takes the conservative approach of not allowing such overwriting of data to occur because there is no way it can determine if the changed transaction should replace an existing transaction or if it conflicts with an entirely different transaction. Replacing the transaction under these circumstances would result in data loss. The other problem--relating to allowing transactions to be replacement--is that you may have already issued payments to those transactions, or performed a bank reconciliation, or printed reports, etc. Allowing transactions in your system to be replaced with external transactions could corrupt the work done in your own company.

To avoid these problems consider the following procedures:

Disallow changes to transactions in prior periods once data has been exported and sent to you. Users can be prevented from changing transactions in prior periods if the security system is used. The security system supports time based restrictions. You can, for example, stop users from editing transactions past a certain date.
When changes need to be made, enter them as credit notes, adjustments, etc., in the current period that has not yet been exported. Don't go back and edit old transactions. (Which is generally not recommended as good accounting practise anyway.)

3. Establish Procedures For Opening & Closing Accounts

Keep in mind that you are only exporting and importing transaction files. These transactions will be associated with customer or supplier accounts that must also exist in the company you are importing them into.

Consider the following procedures to deal with this issue:

Decide who opens the account, i.e., your head office or each branch company, and the procedure for notifying other companies or branches in your organisation of the new account details.
Will these account details be maintained manually? For example, will the account details be printed on a report and faxed to the branch or head office company? Or will updates be via a data file that gets exported and read in by other companies? Who within your organisation is responsible for creating and issuing this data file?
How will account codes be determined when opening a new account? What chance is there of this new account code clashing with another account also recently opened? Should a procedure be put in place for issuing account codes to avoid this possible problem?

4. Other Types of Clashes & Conflicts

Some types of conflicts may happen rarely but may be inevitable. Consider the situation where an invoice is transferred to your system and your company issues 'payment' on that transaction. The company that created the transaction, however, later on decides to issue an adjustment note for that invoice or part of that invoice.

CAPITAL will determine that there is a problem as the transaction has already been fully paid. The problem will be reported when you run a customer or supplier Account Recalculation. In this situation you will need to decide what to do. Should the adjustment/credit note be issued to another transaction in the system that is unpaid? Should you change the payment allocation in order to allow for the credit note? Should only the head office company issue credit notes? (This would avoid the problem but may be operationally too restrictive.)

If you will be regularly sharing data between different companies then the systems that are sharing information should be set-up to work with a consistent expense or general ledger coding scheme. For example, if a supplier transaction has been assigned to the general ledger code 13000, then the general ledger account 13000 should be found in the company that you are importing the data into. While you can enter the missing codes after the data is loaded, the system will operate more smoothly if you agree on the general ledger codes to be used by all companies, before you begin importing.

A further issue to consider relates to bank accounts. If you are importing transactions that have bank account codes not found in your own system, then the bank balances cannot be updated as the data is imported. If this situation arises you should add the missing banks to your system and recalculate your bank balances.

5. Issuing Payments

Who will issue payments/cheques? If the head office company, i.e.,, your company, is the only company that issues cheques, do you also wish to keep each branch company up to date on which accounts were paid? Is a printed report listing the payments/cheques and invoices allocated to be faxed to them? Or will such information only be available when a customer or supplier directs its inquiry to your head office?

Account Recalculations are Important...!

Once transactions are imported into your system from an external source it is important to check for allocation problems. For example, an imported adjustment or credit note may refer to invoice 3291 which may not exist in your accounting records.

To perform the recalculation function do this:

From the CAPITAL main menu select Special|Installation Workshop.
From the INSTALLATION Workshop main menu select Diagnose.
Select Recalculate Customers or Recalculate Suppliers, depending on the type of file you have imported.

Other users cannot add or change customer or supplier transactions while this utility is scanning your files.

If any problems are found they are listed on the screen and an error report can also be printed.

If a problem is found, you can correct the error by either:

Editing and retotalling the transaction. (Making whatever corrections you need to do, depending on the nature of the problem.)
Note the details of the transaction, then delete it, and reenter it.

Internal Errors

You may also receive internal error/warning messages when starting CAPITAL after importing files. This may mean:

That the configuration of the export company varies in important respects from that of the import company. For example, the export company may not have the cash management system activated and does not process payment types. Whereas the import company does require this information. To avoid problems both companies should be consist in all major respects. For example, if the export company handles foreign currency accounts, so should the import company.
CAPITAL may detect data corruption problems with your data. See the notes from the prior section for guidelines on correcting them.

____________________________