Implementation for G/L
This document is divided into two parts:
- Mandatory data, which has to be completed to run the basic routines in the G/L.
- Optional data, which needs to be completed when additional functionality is taken into use.
Entries in the following tables and files must be created, in the sequence given below, before you can start working with the G/L. Some codes are mandatory. For details on how to use the different maintenance programs and the meaning and usage of the values in the tables and files, see the Panel help.
- G/L control file
- Journal number series table
- Account file
- Pseudo account file
- Voucher number series table
- Voucher type table
- Document number series table
- Document type table
- System document type table
- Percentage table
- VAT handling code table
- VAT catalogue table
- Exchange rate table
- Summary level table
Mandatory data
The following information must be entered for the G/L to be able to run basic routines such as manual transaction entry:
| Table/File | To do | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| G/L control file | In the G/L control file a number of essential parameters are set. These are:
If you have converted transactions in DC1 Financials from another company, make sure that the field Last used reference number (SFLURX) in this file (SROSTYSF) is correct. |
|||||||||||||||||||||||||||
| Journal number series | Define the journal number series JOU for at least the current year. A number series for the following year is not mandatory, but should be defined. If the cut-off date is set to the beginning of a new financial year, you should also define the number series for the previous year. The number series JOU will be used by the system to number journals at transaction update. | |||||||||||||||||||||||||||
| Account file | The account file includes one section for each account part in the account structure as defined in the G/L control file. You can move between the different sections by entering the account part number in account part on the bottom of the panel.
When entering accounts to the account file all accounts will be given a number, a description and a YES/NO to indicate whether the account is open for input during transaction entry or not. If an account is not open for transaction entry it will only be used as a heading and break level in listings and reports. Further information is needed for the account part that has been defined as main in the G/L control file. On this account part you will define how the main account is to be combined with the other account parts in the account structure. You will also indicate if the account should be included in some of the routines such as revaluation etc. The field account number is alphanumeric. Summary identitiesIf you also intend to use summary identities (see Summary identity file), you can proceed in two different ways:
or
VAT on G/L levelTip: If you enter VAT on G/L level, you can proceed in two different ways:
or
|
|||||||||||||||||||||||||||
| Pseudo account file | Pseudo accounts are used by the system to create automatic accounting entries. A number of these pseudo accounts are integrated into the system and can only be used in specific routines. See Mandatory data for the A/R and Mandatory data for the A/P for additional information. These pseudo accounts have to be included in the pseudo account file to get the correct accounting and should never be used in any other areas.
The following types of pseudo accounts are needed:
The automatic postings are created via the following pseudo accounts:
The user defined part of these pseudo accounts, xxxx, is based on the transaction currency code. If the specific accounts are not found, the defaults XRG and XRL are used. If these are not found, XERROR is used. The contra entry of the gain/loss is the revaluation posting to the revalued account, which increases or decreases the system currency balance on the account. User defined pseudo accounts can also be created. In the G/L a user defined pseudo account can be used to shorten lengthy and cumbersome account strings. Instead of entering the actual account at transaction entry you can enter the pseudo account and the system will translate it to the complete account string. |
|||||||||||||||||||||||||||
| Voucher number series table | Define the voucher number series for the voucher types. Be sure to consider how the vouchers created from the different processes in the Routine table should be numbered, i.e. if some routines can share the same series, or if you want a different series for each routine. Each number series must be created for at least the previous and current year. It is recommended that you create the number series for the following year as well. Use the copy function to facilitate the input. The number series are allocated to the routines via the voucher types that you will create in the next step. | |||||||||||||||||||||||||||
| Voucher type table | Voucher types are used to categorise transactions in the G/L. It should be possible, from the voucher type, to derive the origin of the transaction, i.e. from what part of DC1 it came and how it was created. Voucher types are a central concept and search criteria when working with follow-up and account analysis in the G/L.
On each voucher type you will define possible routines for which it should be used. One routine can be defined as default. For G/L transactions it would make sense to create separate voucher types for manual entries and automatic entries created by the system. Be sure to consider how the vouchers created from the processes defined in the routine table should be numbered, i.e. if several routines can share the same series, or if you want an individual series for each routine. The number series are allocated to the routines through the voucher types. Any routine that you intend to use must be valid (i.e. active) for at least one voucher type. |
|||||||||||||||||||||||||||
| Document number series table | Define the document number series you want to use for numbering G/L documents, if the document number should not be given by the voucher number. The number series are allocated to the document types that you create in the next step. | |||||||||||||||||||||||||||
| Document type table | The document types are one of the most important concepts in DC1 Financials, and it is critical to know how the document type triggers different aspects of transaction entry and accounting.
The document types are used to categorise transactions within ledgers. This is especially true when working with the A/R and the A/P. Within the G/L, the voucher type is most likely the more important concept, but the document type can still control some accounting. The table is preloaded with the G/L document types corresponding to the G/L system document types in the System document table:
Before using the preloaded document types ensure that all parameters are set to get the correct document numbering, accounting etc. For further information, see the Panel help. |
|||||||||||||||||||||||||||
| System document type table | The table is preloaded with the following G/L system document types:
These document types will be used by the system if no other document type from the Document type table is indicated. If you want to connect other document types to the defaults, replace the default document types with other types from the Document type table. |
|||||||||||||||||||||||||||
| Percentage table | Enter the percentages to be used when creating the VAT handling codes. Percentages may also be used in DC1 Report Writer. | |||||||||||||||||||||||||||
| VAT handling code table | Define the VAT handling codes to be used when calculating and posting VAT transactions. The setup varies depending on whether you enter VAT on invoice or on G/L level. | |||||||||||||||||||||||||||
| VAT catalogue table | This table is only mandatory if you enter VAT on G/L level (defined in the G/L control file). A VAT catalogue is a way to group and sequence different VAT handling codes under one common concept. If VAT is entered on G/L level a VAT catalogue will be entered on the voucher type.
Define the VAT catalogues containing the VAT handling codes for different types of accounts that should generate VAT postings automatically. |
|||||||||||||||||||||||||||
| Exchange rate table | The system currency must have exchange rate 1,0000000 on all levels and for all periods as defined in the G/L control file. Exchange rates for the remaining currencies must be entered before you can enter any transactions. You need to define exchange rates for the time levels that will be used by the system as defined in the G/L control file. | |||||||||||||||||||||||||||
| Summary level table | Two summary levels are preloaded with the status pending creation. In order to activate these summary levels you use menu item Reorganise Summary Levels.
In the summary level table you define how transactions are to be summarised in the database for easy access. At least one summary level for main account has to be defined for enquiries on main account balances. Balance enquiries can only be made on values that have been defined as a summary level. DC1 Report Writer reports and Query groups can be run without having any summary levels defined. However this is not recommended as it means that the system will have to summarise all selected transaction every time they are to be presented. System performance will be affected accordingly. If the summary levels are thoroughly defined the performance in enquiry routines and report writing will be optimised. Define the summary levels that you need in the balance enquiry and DC1 Report Writer to get information presented according to you enquiry and follow-up structure. This should preferably be done before the installation is in production. Changes and amendments can be made at any stage. However you must be aware that to rebuild the summary levels can be a time consuming activity. |
Optional data
The tables described below are not essential to the basic routines of the system. Entries can be made now, later or not at all.
| Code | Description | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Summary identity file | The summary identities form an alternative way of storing and presenting the accounting information. They can be regarded as alternative charts of accounts. There are sixteen summary identity parts that can be connected to any account part in the chart of accounts. The summary identity parts are used to create summary levels for different account combinations that cannot be combined because of the structure of the Account file. The summary identity parts are defined in the G/L control file with a description and connection to a chosen account part in the chart of accounts. As soon as a summary identity part has been defined in the G/L control file it will be possible to enter accounts in the summary identity file.
Several account numbers in an account part can then be connected to a summary identity in the related summary identity part, and a balance is kept on the summary id level. More than one summary identity part can be related to the same account part, and as long as balances have not been created, you can change the relation between the summary identity parts and the account parts. Summary identities consist of up to ten characters, and the names of the summary identity parts consist of up to twenty characters If you intend to use summary identities, you can proceed in two different ways:
or
Several main accounts can be summarised into one summary identity. When an entry is made on an account the balance of all summary identities connected to the account will be updated. If the structure is changed at a later stage run the Rebuild summary identities routine and all information will be recalculated according to the new structure. In reports made in DC1 Report Writer a selection can be made combining account parts and summary identity parts, thus resulting in multi-dimensional. |
|||||||||
| Dynamic base option table | In a dynamic base option you define what kind of balances will be used when calculating percentages for the dynamic calculation/redistribution routine. Entries must be created in order to be able to create rules for dynamic calculation/redistribution. | |||||||||
| Combination check table | If there are certain combinations of accounts that must not be used even if the setup of the chart of accounts allows it, it is possible to block these combinations by not defining them in the combination check table. | |||||||||
| Account completion table | Account completion is an alternative method to shorten long account strings. See section Pseudo account file for additional information. If a combination of accounts is defined in this table it will only be necessary to enter the main account at transaction entry to get the entire account string. | |||||||||
| Pricing table | DC1 Financial gives the possibility to work with quantities and prices instead of amounts. If defined in this table it will be possible to enter a quantity at transaction entry and have the amount calculated by the system. | |||||||||
| Transaction entry template | The transaction entry screen can be customised to only show input fields needed by the user. Different entry templates can be made for different tasks. At transaction entry the user can choose the appropriate entry template. Default values for different fields can also be entered in the entry template. | |||||||||
| Budget curve table | The budget curves describe how a yearly budget amount should be allocated over the year. Entries must be created in order to be able to use curves when distributing budgets in the budget file or allocating amounts in the transaction entry routines. | |||||||||
| Budget description table | In the budget description you will define on what level a budget should be made, what keys should be included, and what balance types should be used. Budget descriptions can be entered now and/or later. | |||||||||
| Budget file | All budgets are entered and stored in the Budget file. It is possible to create up to 999 different budgets. Budgets can be entered now and/or later. | |||||||||
| Entry text table | Entries can be made if you want to use standardised texts for your G/L postings. | |||||||||
| Calculation and redistribution files | In the calculation/redistribution file rules are defined for automatic calculation of new entries based on existing entries, or redistribution of existing entries to other accounts and account combinations. Calculation/redistribution rules can be entered now and/or later. | |||||||||
| Standing orders file | A standing order can be created for vouchers that are entered repetitively over time, e.g. every month, every quarter etc., where the accounts and values are basically the same every time applied. Standing order rules can be entered now and/or later. | |||||||||
| Interface type table | Interface types must be defined before you can transfer G/L postings from pre-systems. | |||||||||
| Year end account table | In this table the rules for year end transactions are defined. Year end accounting rules can be entered now and/or later. | |||||||||
| Consolidation relationship | Company hierarchies for consolidation can be entered now and/or later if you want to use the consolidation routine. | |||||||||
| Consolidation conversion | Account part, account number and period relationships between companies in the consolidation structure can be entered now and/or later if you want to use the consolidation routine. | |||||||||
| Report specification | In this routine reports to be run in DC1 Report Writer are deigned. Reports can be created now and/or later.
Two reports are preloaded:
|
|||||||||
| Report version specification | If one report is used in many aspects it is possible to create versions of the same report instead of making a new report for every one needed. One example could be to make one version of a Profit and Loss statement for every profit centre. Report versions can be created now and/or later. | |||||||||
| Report group specification | If a large number of reports are printed at regular intervals it is possible to group these into a report group. By doing this it will be possible to print all reports in the group by initiating the printing of the report group. Report groups can be created now and/or later. | |||||||||
| Division table | When division concept is used, the divisions should be entered in the Division table. A prerequisite for the implementation of the division concept is that a Cost centre account part is defined in the G/L control file at company creation.
A division can embrace several cost centres. Cost centres are linked to a division by maintaining the Account file. |
|||||||||
| Inflation accounting group table | This table is used for G/L accounts revaluation due to inflation or deflation. G/L main accounts can be linked to an inflation accounting group. That is achieved by maintaining the applicable main accounts in the Account file.
The Inflation accounting group table entries contain revaluation percentage and inflation account, where resulting amounts will be posted. |
|||||||||
| Reason code table | If routine Cash Book is used in the system, this table should contain the reason codes used for posting cash book transactions. It is mandatory for each cash book transaction to have a reason code that provides analysis through the cash book transaction listing and search facility in the Cash book reconciliation function. | |||||||||
| Language table | It is possible to translate different codes in the system to the user language in the Language table.
The Special panel value translation table holds all the panel values defined in the Panel value control file for the subset *ALL. The panel values are used in various programs. For the General Ledger these are used in the following routines:
|
|||||||||
| Program function key table | This table is preloaded with the program function keys used in several routines.
For the General Ledger these are used in the following routines:
|