.
 
Enterprise 6 Suite
Planning your accounts
Setting up your Enterprise 6 system

The following are some of the principle things that you will need to plan in order to make your accounting installation as successful as possible.

Please note that you can reduce the amount of work required to set up your accounts within Enterprise 6 if you use the accounting structures supplied as sample data.


General ledger accounts

Accounts are the Ônominal' or Ôgeneral' ledger headings by which you will classify all financial transactions posted to Enterprise 6.
To use the accounts features of Enterprise 6 it is naturally imperative that you decide on a format and structure for your accounts to appear in. To help you with this potentially complicated process, Enterprise 6 is supplied with some Ôstandard', working company accounts to build upon if required, and advice is available to you on this and other initial stages of using the system.

Normal accounting practice is to employ a three or four digit coding structure, prefixed by leading zeros if required. Five characters is the maximum per account code within Enterprise 6, and there is no system requirement dictating that you shouldn't, for example, use alphabetic characters. The two real requirements of an accounting structure are that it be sortable and insertable: that when sorted alphabetically it yields a meaningful order; and that logical Ôgaps' are allowed between distinct accounts to cater for later insertions.

Note that Company, Departmental or other breakdowns of essentially the same account headings should not be created as part of the accounts headings - these are separately entered as analyses - see below.

Once you have started posting transactions in Enterprise 6, do not delete or change the code of accounts that have been used. Insertions of new accounts, and changes of names or headings are permissible.

The following information is required:

Account name
Up to 40 characters long, representing the ÔNominal Ledger heading' of a traditional manual accounting system.

Profit and loss/balance
This must be set to either ÔP' or ÔB' to indicate whether this is a profit and loss or a Balance Sheet item.

Input/output/neither
The system needs to know for each account whether it is to be included in the calculations producing the total Inputs or Outputs figure as notified to the VAT Office. All Balance Sheet items (including the VAT accounts themselves) are ÔN' for Neither; all sales analysis accounts are ÔO' for Output; and most costs and overheads are ÔI' for Input, but excluding, for example, salaries, VAT/Taxes, leases etc, which should be ÔN'.

Group heading and report heading
These two headings together control how the Balance Sheet and the profit and loss reports are structured. When setting up your accounts, you can create the entire format of your profit and loss and Balance Sheet using these fields - meaning that these key accounting reports are almost completely user-definable (using the Ôaccounts headings' menu item described below).
The group heading (of B1 Net Current Assets in the illustrated example), and the report heading (of B2 Current Assets) are used to determine where this item will appear in the Balance Sheet. While the report headings are fairly simple, being used merely as a sorting device within the group headings, the group headings themselves are rather more complex. They control the way subtotalling is handled during the printing of the reports.

Prevent use of this account in general ledger postings
Switch this check box on if you want to disallow the use of this account code when entering transaction batches. When setting up accounts, this feature can be used, for example, to ensure that payments are issued or receipts received in the correct Ledger (Purchase and Sales respectively) rather than by journal in the general ledger. Recurring journal postings are allowed to break these rules, since they are often used to allocate instalment payments and receipts against invoices.

It is recommended that, when setting up the eight transaction types whose codes appear on the accounts page of Preferences, you switch on this check box. For the same reasons, you should also switch on this check box for all accounts affected by those transaction types.

Applicable analyses and applicable layers
You would use them to restrict the use of particular accounts to transactions relating to certain analyses (also known as cost centres) and layers (the latter if the multi-layer companion is present).


Accounts headings

Enterprise 6 features fully user definable multiple level but collapsible general ledger reports. The reports affected are the Trial Balance, the Profit and Loss and the Balance Sheet.

Setting up the accounts headings requires a certain amount of planning before implementation. Each accounts heading should be allocated to a report Level and each group of accounts headings should be allocated to a report group.

The various possible settings are perhaps best explained by example. The following refer to the Sales section of a profit and loss report of a sample set of accounts.

The group heading (‘GP1’) specifies that each of these accounts will appear in the ‘Gross Profit’ section of the report. The report heading is used to specify the sub-heading within the ‘Gross Profit’ section in which the account is to appear. The ‘Gross Profit’ section is therefore divided into two: P1A, ‘Produce Sales’, and P1B, ‘Miscellaneous Sales’. P1B is itself sub-divided into two further sections: P1BA, ‘Services’ and P1BB, ‘Bespoke Work’. Note how these codes both begin with ‘P1B’ - another example of a coding structure moving from the general to the specific.

When setting up the accounts headings, note the relationship between the structure of the accounts heading code and the report Level on which the heading is to appear, again moving from the general to the specific. Note also that, although ‘GP1’ is the report group, it should, itself, be entered as an accounts heading.


General ledger periods

Accounting periods are the subdivisions within a financial year. All accounting transactions must be allocated to a period.

A financial year or Fiscal Year generally consists of twelve periods, coinciding with the calendar months, but it does not necessarily coincide with the Calendar Year.

It is common to use months of the year as accounting periods. Some companies operate their accounts according to other accounting periods. For example, some organisations operate thirteen equal periods of 28 days, thus smoothing the vagaries of a calendar with varying length months. Others operate twelve monthly periods, plus a final period at the end of the financial year of one single day - into which any Ôlast-minute' or Ômop-up', or otherwise Ôforgotten' transactions may be posted.

Variable length accounting periods
Enterprise 6 is perhaps uniquely flexible among accounts packages. accounting periods don't need to be of a particular length and may be as short as one day, or (in theory) as long as an infinite number of years.

When you create a new period, you merely need to specify a period code that can be automatically sorted into a sequence. For example 2001/01 (the period code for January 2001) could equally be 2001/A, as long as the ensuing period codes are in strict logical sequence (2001/B, 2001/C').
For sorting reasons, it is advisable to begin the period code with the year to produce a sort order 2001/01, 2001/02, 2001/03 etc.


Analysis codes

Enterprise 6 optionally allows every single transaction to be given a level of analysis or cost centre on top of the normal ones of account, period, Date etc. These analyses could cater, for example, for multiple companies being accounted for together, or for a departmental breakdown. All reports could then be run either for particular analyses, or fully amalgamated.

The information stored is simply a four-character unique reference and a name - eg A - Department A, B - Department B etc. multiple levels of analysis can be catered for by use of suffixes: for example B1, B2 etc then B1A, B1B etc.

Additionally, when entering a new analysis, the opportunity is offered to enter alternative addresses and VAT/Tax Numbers, which will be used when printing out any documentation required by a transaction involving this level of analysis. This gives Enterprise 6 its multi-company handling capability.

Once the analyses have been set up, accounts, transaction codes, invoices, Orders and even Products and Companies can be allocated to an individual analysis (always user-modifiable), always accessing the list of analyses set up here by way of the wildcard. Please refer to the Personnel section of the Data Manager chapter for details on allocating members of personnel to a particular analysis.


Transaction types

Transactions are the basic transfers of funds in the accounting system. A transaction is where money is Ôposted' or transferred from one account to another - primarily from a sales account to a purchase account or vice-versa. This is the fundamental element in a double-entry system.

Enterprise 6 allows you to set up transaction types in advance. You tell Enterprise 6 the credit and debit sides of each transaction.

The advantage of the transaction type is that by making a single selection you can inform Enterprise 6 how to treat a particular transaction, without having to think about which accounts are affected, and whether these are to be debited or credited. For example, when you post the cash payment of a petrol receipt, it should debit the Vehicle Expenses account, credit Petty Cash and post the VAT amount to the Input VAT account. Once you have set up an appropriate transaction type, you will then only have to remember, in this example, to use the Petrol payment transaction type - saving time, and cutting down the potential for errors.

Certain transaction types must be available before the Sales and Purchase ledger systems are used, though the terms and codes can be your own. These include ones for basic payments and receipts, plus types for the posting of Sales invoices, the receipt of payments for the same, the receipt of Purchase invoices, and the payment of Purchase invoices.

Transaction code
A unique four-character reference to each type is required, preferably memorable and grouped logically by prefixes. For example, you might choose to group all payments (P...) and receipts (R...) together, or could choose different terminology, such as Inputs (I...) and Outputs (O...). A Petrol payment therefore might become PPET.

Debit account/credit account
Debit - the general ledger account TO which the posting is made.
Credit - the general ledger account FROM which the posting is made.

Debit acc range/credit acc range
It may be that the transaction type being set up may not have a fixed Debit or credit account. For example, you may have a choice of bank accounts or cash accounts which the Petrol payment transaction type may use. If so, and your account structure is suitably set up (with each account in the same area of the coding structure, for example, 27700 credit Card account (Visa) and 27710 credit Card account (access)), you may specify a range of appropriate Debit accounts using the Debit acc range fields.

VAT/Tax code
Here you enter whether this kind of transaction will be assumed to carry VAT/Tax to save time during entry, and, if so, at what rate.


 

Email: info@daybook.co.uk 
Copyright © 2004 Daybook Limited, All Rights Reserved.
Web page power, search engine optimization and content management by Caliban.

Daybook Data publishing Solutions for Qu...
online customer centre
What is Customer Relationship Management...
Windows compatibility
I need a system fully integrated with MS...
Business management software:
Best of...

Lead management
web presence
System which can update data on remote w...

Financial data integrity tools


Getting BI

What keeps the wheels of business turnin...
Mac financials in the UK
Publishing a Catalog with Framemaker
Daybook Enterprise 6 Release
Database Manager
Publisher 5 price list
Computer dealers and distributors
Working for Daybook