Account core models

• Account core model (field GCM)

This code identifies the current record in a unique way.

• Description (field DESTRA)

Standard title of the record being viewed.

By default the short title, the long title or the column header of a data are recorded (on creation/update) in the connection language of the user.
You can add your translation in another language using the Translation function:

• Click Translation from the Actions icon in the corresponding field.
• In the Translation window, add a new language code with the translation in this language.

A user who logs on with this language will view the short description, long description or column header in their connection language if a translation exists. Otherwise, these descriptions will be available in the folder language.

The connection language must be defined as a default language for thefolder.

• Short description (field SHOTRA)

The short description replaces the standard description when display or print constraints require it.

By default the short title, the long title or the column header of a data are recorded (on creation/update) in the connection language of the user.
You can add your translation in another language using the Translation function:

• Click Translation from the Actions icon in the corresponding field.
• In the Translation window, add a new language code with the translation in this language.

A user who logs on with this language will view the short description, long description or column header in their connection language if a translation exists. Otherwise, these descriptions will be available in the folder language.

The connection language must be defined as a default language for thefolder.

• Legislation (field LEG)

In multi-legislated folders (where the LEG activity code is active), the Legislation fields are displayed.

• If a legislation has been set in the LEGFIL (Legislation selection filter) parameter (SUP chapter, INT group), it is used as the default but can be changed if needed.
• If LEGFIL has no legislation set, there will not be a default, so the Legislation field will have to be entered appropriately.

If a legislation is entered in the record header, other fields entered must follow any rules applicable to the legislation.

If a legislation is not entered in the record header, it might be deduced from another element (such as the company, site, or employee) and again, other fields entered must follow any rules applicable to the legislation.

If a multi-legislation group of companies is selected, other fields entered must follow any rules applicable to the legislation of at least one company in the group.

Example

If you select a group of British (BRI) and French (FRA) legislation companies, you cannot enter a value in a field that is only applicable to the South African (ZAF) legislation.

In single legislation folders (where the LEG activity code is not active), the Legislation fields are not displayed.

• IAS depreciations (field FLGIAS)

This field can only be accessed if the IAS management option (activity code IAS) is activated. If field IAS depreciation is ticked, it will be possible to indentify themain IAS ledger used in the depreciation context.

• Main general ledger (field GENLEDTYP)

Field linked to the local menu 2644. This field only submits the manual ledgers defined in parameter LEDTYPAUT.

The main general ledger is the only ledger from which some legal or structuring operations are generated and can be carried out:

• VAT declaration and extraction of the 1099 file data
• Update open items
• Update the amounts for the BP situation
• Enrich the depreciation contexts for a depreciation schedule with a "CoA valuation" origin
• Propagate matching to the other ledgers of the model from manual and automatic matching
• Accounts used in the A/P-A/R accounting functions (the other accounts come from  reading the automatic journals and applying propagation rules)
• Post a payment: some entries are only generated by taking the data of the main general ledger into account
• In the Sales and Purchasing modules, accounts are always displayed and entered first for the main general ledger and then for the main analytical ledger
• All the standard automatic journals are parameterized considering that the main general ledger is the first one in the Ledgers grid in the accounting code model function; account propagation is therefore managed from this first ledger

 The main general ledger selected can be both a general and an analytical ledger.

• Main analytical ledger (field ANALEDTYP)

The main analytical ledger can be of social or analytical type. These values are defined in the local menu 2644 - Ledger type. The ledgers suggested are only the manual ledgers defined in the LEDTYPAUT - Automatic ledger type parameter (TC chapter, MIS group).

The main analytical ledger selected can be both a general and analytical ledger.

An account core model can contain up to 10 different types of ledgers and thus, up to 10 different general and/or analytical accounting systems.

If the current model does not provide for an analytical account book-keeping, choosing the analytical ledger type is of no real importance.

• Main IAS general ledger (field IASLEDTYP)

This drop-down list field only proposes manual ledgers defined in parameter LEDTYPAUT.
This ledger type is used in the depreciation context setup. The depreciation context is defined at the company level. For a chart in this context, the chart will identify the ledger code and make a link with the corresponding ledger code as long as its 'Depreciation basis origin' is 'IAS valuation'.
 The main IAS ledger cannot beidentical to the main general ledger orto the main analytical ledger.

• General ledger type (field LEDTYP)

This list is automatically loaded from local menu 2644. There can be up to 10 ledger types, which generally are:

• the social accounting ledger,
• the analytical accounting ledger(s),
• the reporting-type ledgers (IAS, US GAAP).

Each accounting transaction, either it is directly entered by the user in journal entry mode, generated via the automatic journals from an upstream module, or imported from an external application, is entered on a "ledger type".
In a given model, if no ledger code is specified for a given ledger type, this ledger will not be loaded.

• Auto general ledger (field CFMAUT)

An automatic ledger is linked to a 'source' ledger type: the same set of entries is used, but with a currency and valuation method that can be different from the one of the source ledger.
When creating the template, this field is set to 'Yes' by default if the ledger type of the line is listed in the LEDTYPAUT parameter.
The ledger types listed by the LEDTYPAUT parameter are always automatic ledgers, for all the templates in the folder. In order not to load them into a given model, the field must be set to NO. The ledger types not declared in LEDTYPAUT can be either manual or automatic types in a given model.

• Automatic ledger 'No'

A manual ledger type is a ledger that can be entered and that has its own allocations (accounts, dimensions). It is used to managed entries that can be set up on demand.
The account and analytical allocations being loaded will be deduced from the setup of the account codes and automatic journals but also from the propagation rules defined in the other ledgers of the model.
The balancing rules or loading rules (etc.) are specific to this ledger.
A template must include at least one ledger type that is not automatic.

• Automatic ledger 'Yes'

An automatic ledger cannot be entered as main ledger.
For an automatic ledger type, the entry posting will not require any specific setup.
The principle is to associate it with another ledger type of the current model(Original ledg. type). Then the entries of the automatic ledger are generated to be exactly identical to those of its original ledger.
The only piece of information that can vary between these two original/destination ledgers is the following: the Currency in which the automatic reference base is kept, that can be different from that of the original reference base, along with the associated rules (Journal exchange rate type, Exchange rate type, Exchange rate type entry mode and Balancing option).
The automatic validation is used to keep accounts in the same way as for the social accounting, except the reference base keeping currency, for reporting purposes.
Therefore this mechanism is not used to load a double accounting with different accounting structures, such an action being allowed by the manual ledger mechanism.

The management of commitments and/or budgets can be enabled on the manual ledger associated with the automatic ledger.

In this case:

When generating commitments/precommitments, if a manual ledger is associated with an automatic ledger, only the manual ledger is updated.

When creating or updating a budget, if a manual ledger is linked to an automatic ledger, only the manual ledger is updated.

You can use the analytical balance inquiry to view the commitments or budgets entered on the manual ledger.

• Source general ledger type (field ORILEDTYP)

Field linked to the local menu 2644.
This field can only be accessed if the current ledger type is automatic. If the case arises, the original ledger type is used to specify on which ledger the double accounting is based.

• Ledger (field LED)

Code of the ledger containing the management characteristics of the current ledger type. In the event of an automatic ledger, the code of the ledger is that of the original ledger type.

Accounting characteristics of the ledger:

• the accounting type(s) managed (general and analytical),
• the chart of accounts being used,
• the codes of the managed dimension types: up to 9 dimension types for 1 given ledger with a maximum of 20 dimension types for the model,
• the balancing, end-of-year and matching rules.

 The ledger is not mandatory in the account model. Therefore, a ledger type is only used if it points to a ledger code.

For a general and analytical ledger, and for tracked accounts on one or several dimension types, it is possible to dissociate the analytical balance update from the general balance.

• Currency (field CUR)

It is the ledger keeping currency in the model. Each managed ledger type is kept in a currency that is specific to it, with a maximum number of five different currencies for a given model.
For a given ledger, the amounts are made available in transaction currency and its countervalue, in ledger keeping currency.
Upon creation of a legal company, and when the accounting model is associated with the company, the accounting currency is deduced from the currency in which the main general ledger of the model is kept.

• Double entry (field DOELED)

Field related to the Russian legislation.

Every automatic ledger can be set up as a double-entry ledger.
When a ledger is identified as a "double-entry" ledger, then the entries from the source manual ledger are converted to the 'double-entry' format in this new ledger.

 There are several constraints when it comes to using this ledger:

• The double-entry ledger and its source manual ledger must have the same bookkeeping currency.
• The "Rounding variance" balancing option is forced on the double-entry ledger.
• The original manual ledger associated with the double-entry ledger, must have its "Summarize empty allocations" checkbox selected.

• Doc rate type (field FLGVCRRAT)

Used to specify the exchange rate search method:

• If the field is set to 'YES', the exchange rate is deduced from theexchange rate type of the original document,
• If the field is set to 'NO', the exchange rate is searched according to a single exchange rate type. This makes it possible to manage a ledger in a currency different from the original ledger. For instance, for a social ledger in EUR currency, the exchange rate type of origin is used. For the US GAAP reporting ledger in USD currency, the "Reporting" exchange rate type is used.

• Rate type (field TYPRAT)

This field is linked to the Doc exchange rate type. It makes it possible to specify the only exchange rate type used to search for the exchange rate, in the event of the current ledger not foreseeing the taking into account of the exchange rate type of the original document.

• Rate entry (field DACRAT)

For each ledger type, it is possible to specify different currency exchange rate entry terms.

• Multiplier: X transaction currency unit(s) = 1 ledger keeping currency unit.
• Divider: 1 transaction currency unit(s) = X ledger keeping currency unit.
• Both: X transaction currency unit(s) = Y ledger keeping currency unit(s), X and Y being accessible and modifiable.

For instance:if, for a European ledger, the currency is generally expressed in the form 1 € = x currencies, an Anglo-saxon ledger can express a different choice: x £ = 1 currency unit.

• Balancing option (field RNDOPTBAL)

This column can only be accessed if a ledger has the selection Balancing.
For a ledger set up with balancing, and to maintain a balance in the ledger keeping currency, the field Balancing option makes it possible to determine how to handle the discrepancies and it can take the following values:

• a rounding discrepancy line will be automatically generated to balance the entry in the currency(ies) concerned.
• the difference is distributed arbitrarily onto the entry lines.

 An analytical ledger is not supposed by its nature to be defined as being balanced (Balance field not checked in the ledger). The field Balancing option is then not entered.
For instance, in a customer invoice, only the income accounts will have an impact on the analytical accounting.

• Ledger 1 (field LED1)

Columns Ledger 1 and Ledger 2 are used to define the list of controls to be carried out for a ledger couple. For example, an amount on a social ledger will be split in an analytical ledger. The control is used to ensure that the original amount will be recovered.

• Ledger 2 (field LED2)

• Control type (field CTLTYP)

By means of a right click in field Control type, enter the controls to be performed:

A: journal thorough control

• the debit/credit total of the lines in transaction currency must be the same for both ledgers in a given journal,
  
• this kind of control is applied only if both ledgers are defined as mandatory in the journal type.
  Example:
  a 1000 debit/credit on the social ledger and a 2000 debit/credit on the IAS ledger will not be accepted.

B: amount control by line

• the amount posted on an entry line of ledger 1 must strictly correspod to the amount of ledger 2 on one or n entry lines,
  
• this kind of control is applied only if the propagation rules between the accounts in use are mandatory.
  Example:
  An entry line of 1000 on the social ledger cannot be linked to one or several lines of the IAS ledger whose sum is different from 1000 in a given journal.
  
• a control can be carried out via the line identifier used to link lines with a same nature/origin but of different ledger types.
  Example:
  - The same line identifier for the line on the 411 social account + the line on the corresponding 411 IAS account,
  - The same line identifier for the line on the 701000 social account + the line(s) on the analytical SALES analytical account + the line on the corresponding 701 IAS account.

C: line quantity control

• the principle is similar to that of the amounts, but concerns non-financial unit quantities.
  
• this control can be implemented only on two analytical ledgers, the quantity management being authorized on analytical accounts only.