SPEC: virtual account within chart of accounts

[ffries]

Title

This is a discussion to support/adapt OpenERP notion of virtual account. Which could be translated in French as "compte de regroupement" as virtual account as several children accounts.

Present behavior

Dolibarr allows to use both solutoins : create a single 401 account and create dedicated children-accounts to 401. With the arrival of FEC rules, it becomes necessary to export FEC data each of fiscal year and this may (or may not) impact Dolibarr chart of accounts.

French administration welcomes a single 410 client account or "few of them" in the FEC export. But remember, this is only for verification purpose.

On the converse, a company might be interested in creating as many as 401 children accounts as possible, to have fine-grain client management. Also, in some countries, it might be illegal to run a middle-size company using a single 410 account. So a solution is needed to allow all solutions and still rely on a rock-solid SQL database allowing direct accounting queries.

Proposed behavior

We propose to adapt OpenERP solution,which is to tag each account as "virtual" or "real" within the chart of accounts using a binary value "True" or "False".

A "real" account speaks for itself. If 410 is tagged "real", then all transactions should occur on 410.

A "virtual" account is an account with one or several children. In the example of 410 account, it will create a sub account name 410 000000 which is in fact the default 410 account. Each new client can have a dedicated client account within the 410 range.

As a consequence, the chart of accounts should also store the lenght of children accounts. The lenght is the total number of alphanumaric values, i.e. 410 000000 is 6+3=9. Just an example. It should also be possible to use alpha values, as proposed by the administation.

To query the 410 account, you only need to run a "SELECT sum()" on all 410 children.
Also, when doing a FEC export/import, only the 410 reference is exported to follow the administration guidelines.

Discussion

Please discuss this proposal and I will modify the SPECs accordingly.

[ffries]

I double checked "Memento Pratique Françis Levebvre" (2010, old but still good):
In short, because there are two pages of explanations, "334 Structure décimale des comptes"

When accounts are 2 or 3 digits long, 0 termination is for summing accounts ending with 1 to 8

Let's take for example class 4: "Créances et dettes à un an au plus":
410 sums all accounts from 411 to 418.
419 is for depreciation. 419 is not a child of 410. 419 is a child of 41.

With virtual accounts, this could be coded the following way:
4=>virtual
41=>virtual (parent 4)
410=>virtual (parent 41)
41x with x from 1 to 8 => real accounts (parent 410)
419 => real account, with parent 41

In fact, 41 and 410 are not the same accounts!
41 = 410+419

Dolibarr offers only 410 in the chart of accounts.

Without virtual account, we might not be able to code the PGCD.
I will propose a patch to:

• add a virtual binary in the chart of accounts using "virtual" True/False.
• recode the PGCD to support the complete range of accounts.

This is the only solution to have a working hierarchal chart of accounts, that we will be able to use with SQL queries. We could leave the chart of accounts as if, but it would require immense coding in PHP and would not work in the end.

[ffries]

To be more precise :

table llx_accounting_account
account_parent varchar(32) DEFAULT '0',

should be :
account_parent_rowID int DEFAULT '0',
account_vitual boolean

When this is done, rowID can be the only reference for an account and used accordingly.

[BebZ]

I am not a dev, but, ImhO, i think it is a great point of view/feature.
Note that current dev of module "accounting expert" is made for french accountancy, in a first time.
I don't know if FEC is only french, or also international?
Also, the current accounting method doesn't really support many "zeros" at the end of accounts (don't know really why) maybe @aspangaro or @Darkjeff can explain ;)

[Darkjeff]

It's for export. like this we have a function to add 0 in order to adapt the lenght of account

[github-actions]

This issue is stale because it has been open 1 year with no activity. If this is a bug, please comment to confirm it is still present on latest stable version. if this is a feature request, please comment to notify the request is still relevant and not yet covered by latest stable version. Without comment, this issue will be closed automatically by stale bot in 15 days.