Account core models

You can manage companies with identical or different legislations and with the same or different accounting organization in a single folder. This organization is called account core model and corresponds to a structure containing general ledger accounts.

Each legal company of the folder is associated with a model.

A same model can thus be associated with one or several legal companies, usually with an identical legislation or country.

A core model can manage up to 5 ledger keeping currencies (GESLED) and 20 dimension types.

../FCT/MULTILEDGER_ENG.jpg

Example of an account core model for a given company:

  • A social accounting system in euro on a general chart of accounts.
  • An analytical accounting system with three dimension types in euro on an analytical chart of accounts.
  • An IAS accounting system in euro with two dimension types on a general and analytical chart of accounts.

An accounting entry can contain exclusively or simultaneously entry lines of general, analytical, IAS, reporting type and so on.

An account core model is used to associate several charts of accounts, dimension types, accounts that are exclusively general or analytical, or both, and ledger keeping currencies, and is characterized by:

  • One or several ledgers. A ledger contains the chart code to be loaded and the dimension types if the ledger is of analytical type.
  • One or several ledger types (local menu 2644). A ledger type can be regarded as a General Ledger type. It is the entry point as well as the filter for most of the mass processing and inquiries.
The account core model must be created prior to the legal company.
If a link to accounting has been defined in Sage X3 People, in folders (GESADS), Links tab, the function cannot be accessed from Sage X3 People. If you try to access the function, the following warning message displays: This object is managed in X3. From Sage X3 People, you can select the values coming from the X3 folder, such as analytical dimension, account, etc. If there is no active link to accounting, the function can be accessed in Sage X3 People and the data is stored in the Sage X3 People folder.

Prerequisites

Refer to the documentation on Implementation.

Screen management

The screen displays the model identification and the list of ledgers in the model.

Entry screen

Block number 1

Account core model (GCM)

This code identifies the current record in a unique way.
Description (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 in your connection language, on creation or update.

You can add your translation in another language by using the Translation function (DES_AXX):

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

If a translation exists, logging on with this language makes the short description, long description or column header appear in your connection language. Otherwise, these descriptions are available in the folder language.

The connection language must be defined as a default language for the folder (GESADS).

Identification

Short description (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 in your connection language, on creation or update.

You can add your translation in another language by using the Translation function (DES_AXX):

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

If a translation exists, logging on with this language makes the short description, long description or column header appear in your connection language. Otherwise, these descriptions are available in the folder language.

The connection language must be defined as a default language for the folder (GESADS).
Legislation (LEG)

In multi-legislated folders, in which the LEG activity code is active, the Legislation fields display.

  • 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 LEGFIL has no legislation set, there is no default, so the Legislation field has to be entered.

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 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 do not display.
IAS depreciations (FLGIAS)

You can only access this field if the IAS management option, in activity code IAS, is activated. If the IAS depreciation field is selected, you can identify the Main IAS general ledger used in the depreciation context.

Block number 3

Main general ledger (GENLEDTYP)

This field is linked to the local menu 2644 - Ledger type (COMBOS). This field only submits the manual ledgers defined in LEDTYPAUT - Automatic ledger type parameter (TC chapter, MIS group).

The main general ledger is the only ledger (GESLED) 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 (GESCNX) 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 considering the data of the main general ledger.
  • In the Sales and Purchasing modules, accounts always display and are 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.
Main analytical ledger (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 not relevant.
Main IAS general ledger (IASLEDTYP)

This drop-down list field only suggests manual ledgers defined in LEDTYPAUT - Automatic ledger type parameter (TC chapter, MIS group).

This ledger type is used in the depreciation context setup (GESCNX). The depreciation context is defined at the company level. For a chart in this context, the chart identifies the ledger code and link it to the corresponding ledger code if the Depreciation basis origin is IAS valuation.

The main IAS ledger cannot be identical to the main general ledger or to the main analytical ledger.

Ledgers grid

General ledger type (LEDTYP)

This list is automatically loaded from the local menu 2644 - Ledger type (COMBOS). There can be up to 10 ledger types, which generally are:

  • The social accounting ledger.
  • The analytical accounting ledger.
  • The reporting-type ledgers, such as IAS, US GAAP.

Each accounting transaction, either it is directly entered by you in journal entry mode, generated via the automatic journals from an upstream module, or imported from an external application, is entered as a ledger type.

In a given model, if no ledger code is specified for a given ledger type, this ledger does not load.
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 - Automatic ledger type parameter (TC chapter, MIS group).

The ledger types listed by the LEDTYPAUT - Automatic ledger type parameter (TC chapter, MIS group) 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 this parameter 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 and dimensions. It is used to manage entries that can be set up on demand.

The account and analytical allocations loaded are deduced from the setup of the account codes and automatic journals and from the propagation rules defined in the other ledgers of the model.

The balancing rules or loading rules 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 a main ledger.

For an automatic ledger type, the entry posting does not require any specific setup. You can associate it with another ledger type of the current model, with the Source general ledger type field. Then, the entries of the automatic ledger are generated to be identical to those of the original ledger.

The only piece of information that can vary between the original and destination ledgers is the Currency in which the automatic reference base is kept, that can be different from the original reference base, along with the associated rules: Doc rate type, Rate type, Rate entry and Balancing option.

The automatic validation is used to keep accounts similarly to the social accounting, except for the reference base keeping currency, for reporting purposes.

This mechanism is not used to load a double accounting with different accounting structures. This type of action can be 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 and/or 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 see the commitments or budgets entered on the manual ledger.
Source general ledger type (ORILEDTYP)

This field is linked to the local menu 2644 - Ledger type (COMBOS).

You can only access this field if the current ledger type is Auto general ledger. If it is, the original ledger type is used to specify on which ledger the double accounting is based.
Ledger (field LED)

Code of the ledger (GESLED) containing the management characteristics of the current ledger type. For an automatic ledger, the code of the ledger is that of the original ledger type.

Accounting characteristics of the ledger:

  • The accounting type or types 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, you can dissociate the analytical balance update from the general balance.
Currency (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 (DOELED)

This field is 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, 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 the Summarize empty allocations checkbox selected.
Doc rate type (FLGVCRRAT)

This field is used to specify the exchange rate search method:

  • If the field is set to YES, the exchange rate is deduced from the exchange rate type of the original document.
  • If the field is set to NO, the exchange rate is searched according to a single Rate type. This makes it possible to manage a ledger in a currency different from the original ledger. For example, 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 (TYPRAT)

This field is linked to the Doc rate type. It makes it possible to specify the only exchange rate type used to search for the exchange rate, if the current ledger is not foreseeing the consideration of the exchange rate type of the original document.
Rate entry (DACRAT)

For each ledger type, you can specify different currency exchange rate entry terms:

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

For example, for a European ledger, the currency is generally expressed in the form 1€ = x currencies, but an Anglo-saxon ledger can express a different form: x£ = 1 currency unit.
Balancing option (RNDOPTBAL)

This column can only be accessed if you did not select to manage the balance for the ledger (GESLED). For a ledger set up with balancing, and to maintain a balance in the ledger keeping currency, you can use this field to determine how to handle the discrepancies.

It can take the following values:

  • A rounding discrepancy line is automatically generated to balance the entry in the currency or currencies concerned. This value corresponds to the Rounding variance option.
  • The difference is distributed arbitrarily onto the entry lines. This value corresponds to the Allocation option.
An analytical ledger, by nature, is not supposed to be defined as being balanced, because the Balance field is not selected in the ledger. This field is then cleared. For example, in a customer invoice, only the income accounts have an impact on the analytical accounting.

Controls grid

Ledger 1 (LED1)

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

Control type (CTLTYP)

By right-clicking in the Control type field, you can enter the following controls to perform them:

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 (GESGTE). For example, a 1000 debit/credit on the social ledger and a 2000 debit/credit on the IAS ledger is not accepted.

B: amount control by line

  • The amount posted on an entry line of ledger 1 must strictly correspond 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. For 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. For 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 or lines 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, as the quantity management is authorized on analytical accounts only.

Tables used

Refer to the documentation on Implementation.