If you decide to use any of the Logistics or Accounting functionality then various options within Ledger setup need to be activated. As with any large system uzERP is flexible and a certain amount of pre-planning and testing will be necessary to get the system working how you would like. The order in which you do things in the set up phase is quite important and this document follows the order that you should use when setting up the ledgers part of the system.
The “Starter” database is a working system and has the options outlined already populated - you can then change these to suit.
Before setting up any codes it is a good idea to design your chart of accounts structure to give the analysis you require. uzERP supports several levels of analysis for general ledger transactions, including cost centres.
GL Summary and Analysis codes allow for the grouping of entries and balances within the General Ledger for reporting purposes. The structure of these codes is a one to many relationship between the three tables such that one GL Summary code relates to many GL Analysis codes…. and one GL Analysis code relates to many GL account codes. In this way the grouping can lend itself to any number of user defined reporting formats.
<span class-“attention note”>Although not strictly necessary, as you can go back later and amend the GL account codes within the Chart of Accounts, it is recommended that the Summary and Analysis codes are set up the before the chart of accounts to make input easier.</span>
GL Summary Codes - used to analyse accounting data at the highest level, these can be grouped together for the highest level analysis
GL Analysis Codes - a lower level analysis of GL balances for reporting Check out the sample data at http://demo.uzerp.com to get some ideas.
GL Account codes represent the chart of accounts for the system. Codes are split between Balance Sheet and Proft & Loss account and certain balance sheet codes will be be designated control accounts. If a GL Account code is designated as a control account, manual General Ledger Journal postings to this code are not allowed as ALL of the postings will be coming from a subsidiary ledger (Purchase Ledger, Sales Ledger, Cash Book) or process such as VAT processing.
The system REQUIRES the following GL Account codes to be set up to function correctly:
You are free to choose the nomenclature for the codes but they must exist and be unique and ALL, with the exception of retained profits and the currency differences code, should be set up as balance sheet control accounts.
All other GL Account codes are optional and should be set up in line with the chart of accounts you require. The GL Summary and Analysis codes help to analyse costs and balances in the ledger.
Cost centres are used for further analysis of entries in the General ledger. For example a departmental analysis of costs and revenue could be produced by allocating entries against the relevant costs centres and GL account codes.
Although this sort of analysis is optional, uzERP REQUIRES at least one GL Cost Centre code. This code will then be used as the default balance sheet and P&L account code for all entries in the system.
When entering a GL cost centre you need to specify the GL account codes that are valid for that GL cost centre. This will then limit the choices offered when making entries to the system so that only costs and revenue types expected are logged against the relevant GL cost centres. If using only one cost centre then make sure all codes are valid for that centre otherwise you will not be able to enter transactions correctly.
Each transaction within the General Ledger is allocated to a period based on the date of the transaction. The period set up is completely flexible in that the system can cope with any number of periods within the accounting year, for example 12 monthly periods, 13 four-weekly periods, or 4 quarterly periods.
When first setting up the system it is recommended that the periods that represent the first year are entered - from there on the system will always keep 12 future periods available. When setting up the periods you should also indicate which VAT period the transactions relate to - normally these will be quarterly periods.
There must be at least one currency for the system to function properly - this is known as the base currency. In addition the system will allow you to set up any currency you trade in and enter a conversion rate with the base currency. The fields for currency entry are:
The General Ledger parameter section specify how the system works, and provides defaults for background processing.
Twin Currency – usually the Euro in the Eurozone. If twin currency not required set to the same as base currency
For the system to function correctly there must be at least one bank account on the system. Each individual bank account must be allocated to a unique GL account code and this must already exist, and be set as a control account, before the bank account can be set up.
The bank accounts can be denominated in any currency that is used by the system, which obviously need to be in place before any other details can be entered.
The following information is required on entry
The balance field should be left at zero on entry.
At least one payment type is required - this is the transfer type for making transfers between accounts - in the default set up this will already be in the table. Other payment types can be entered as required.
There is the option enter a payment method against a payment type - this is used in the purchase ledger the determine the action to be taken when making a payment for a supplier who has this payment type set. At present there are two actions:
If no method is set the type can still be used in purchase ledger but no automatic action will be taken.
In sales ledger the payment type has no effect beyond identifying the source of a receipt for reporting purposes.
Payments terms are used in the sales and purchasing systems to determine when transactions are due for payment and whether discount should be applied.
Each Customer or Supplier is allocated a payment term from this list.
|45 Days from Invoice Date||Invoice||45||0||0|
|End of Month following Invoice Date||Month||0||1||0|
|End of Invoice Month plus 75 days with 2.5% Discount||Month||75||0||2.50|
|End of Month 2 following Invoice Date||Month||0||2||0|
Periodic payments can be used for standing orders, direct debits or items such as wages payments. The information required is as follows:
uzERP is designed around the requirements of the UK VAT system and tries to cater for this as much as possible through flexible tax periods, multiple product VAT rates and statuses for trading partners.
the VAT accounts MUST be set as control accounts for the VAT reports to work correctly.
In order to allow for flexible tax (VAT) reporting the system allows GL periods to be grouped into tax periods - these are set up in the GL Periods section where each GL period is allocated to a VAT period (usually a quarter). The transactions are then grouped together to allow for VAT reporting.
In the UK, as in most EU jurisdictions, the tax rate is applied based on the category of product being bought or sold. Under this section you can enter the various VAT rates that apply to the products you sell. You can enter as many different rates as you wish for reporting purposes, each with a different rate if necessary. The details required for each rate are:
In the UK the decision to apply tax is a combination of the tax on the product and the status of the trading partner (supplier or customer). The tax status determines whether tax is charged - this status is then used when setting up a trading partner in the purchase or sales ledger.
Last edited by uzerp, 2017-08-18 15:58:05