Account core models

• Account core model (field GCM)

This code identifies the current record in a unique way.

• 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 the folder.

• 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 the folder.

• Legislation (field LEG)

Non-compulsory field containing the legislation code (miscellaneous table 909).

The entered value is used upon creation and validation of the folder and upon addition of data during legislation copy.

The data concerning the requested legislations and the common data (legislation code empty) on folder creation.

Only the records concerning the folder legislations are retrieved on folder validation.

The Legislation field is also used as a filter and checked upon movement selection and entry (entry of invoices, payments, journals etc.).

If the field is empty, the current record can be used whatever the legislation of the company concerned by the movement.

• 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)

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

The main analytical ledger is the only ledger from which some initializations (by default, the inquiry of dimensions can be done in the main analytical ledger) and some controls (it is mandatory to enter it in the BP invoice entry setup, but with a order that can be parametrized) can be processed.

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

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

In the event of the current model not foreseeing an analytical account book-keeping, the choice of 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 be identical to the main general ledger or to the main analytical ledger.

• 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 ledger (field CFMAUT)

An automatic ledger points to an original ledger type: a same set of entries will be used with a currency and a potentially different valuation method compared with that of the original ledger.
On model creation, this field is initialized by default to YES if the ledger type on the line is listed in the LEDTYPAUT parameter.
The ledger types listed in LEDTYPAUT are necessarily automatic types for all the models 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, loading etc. rules are thus specific to this ledger.
 A model must contain at least one ledger type that is not automatic.

• Automatic ledger 'Yes'

An automatic ledger cannot be referenced as a main ledger.
For an automatic ledger type, the posting of entries does not require any particular 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 information that can vary between these two original/destination ledgers is the following: the currency to keep the automatic ledger, that can be different from its original ledger, as well as the associated rules (Journal exchange rate type, Exchange rate type, Exchange rate entry mode and Matching option).
For instance, the automatic posting is used to keep an accounting identical with the social accounting, excluding the ledger keeping currency, and this, 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.

• 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.