Deposit accounts on Spanish Chart

[Sergi Almacellas Abellana]

Hi,

The account_deposit module defines a new kind of account (Deposit
account) but there is no deposit account on the Spanish CoA. After a
little bit of digging i found that the Spanish CoA includes deposit
accounts for customers (4380) and suppliers (4070), so this accounts
should be marked as deposit. This requires to add the account_deposit as
dependency of the account_es module, but not sure if this is the best
way as this module also adds new functionaly on party and invoice which
is not relevant to people not using the deposit functionaly. So my doubt
is the following:

- Why is the deposit type defined on the account_deposit module and not
on the account base module?

--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

[Cédric Krier]

On 2018-02-07 16:26, Sergi Almacellas Abellana wrote:
> Hi,
>
> The account_deposit module defines a new kind of account (Deposit
> account) but there is no deposit account on the Spanish CoA. After a
> little bit of digging i found that the Spanish CoA includes deposit
> accounts for customers (4380) and suppliers (4070), so this accounts
> should be marked as deposit. This requires to add the account_deposit as
> dependency of the account_es module, but not sure if this is the best
> way as this module also adds new functionaly on party and invoice which
> is not relevant to people not using the deposit functionaly.

You may put those account inside a extra depend module.
But usually, you have 1 account deposit per party so you create them and
they do not come from the standard chart.

> So my doubt
> is the following:
>
> - Why is the deposit type defined on the account_deposit module and not
> on the account base module?

Because we did not think that standard chart of account would need it
and we did not want to add new type if no code is using it.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Sergi Almacellas Abellana]

El 07/02/18 a les 16:43, Cédric Krier ha escrit:

> On 2018-02-07 16:26, Sergi Almacellas Abellana wrote:
>> Hi,
>>
>> The account_deposit module defines a new kind of account (Deposit
>> account) but there is no deposit account on the Spanish CoA. After a
>> little bit of digging i found that the Spanish CoA includes deposit
>> accounts for customers (4380) and suppliers (4070), so this accounts
>> should be marked as deposit. This requires to add the account_deposit as
>> dependency of the account_es module, but not sure if this is the best
>> way as this module also adds new functionaly on party and invoice which
>> is not relevant to people not using the deposit functionaly.
>
> You may put those account inside a extra depend module.

The main issue here is that this account should be included on the
balance sheet so probably the best is to use the deposit kind when the
account_deposit module is installed and the other type when not installed.

> But usually, you have 1 account deposit per party so you create them and
> they do not come from the standard chart.

But the code groups by line party [1], so it's possible to have multiple
parties on the same account (as the party required flag should be set
for this accounts). Furthermore, I don't see how each party gets it's
deposit account assigned. Am I missing something?

[1]
http://hg.tryton.org/modules/account_deposit/file/11e8fdac3d6b/party.py#l52

[Cédric Krier]

On 2018-02-07 17:27, Sergi Almacellas Abellana wrote:
> El 07/02/18 a les 16:43, Cédric Krier ha escrit:
> > On 2018-02-07 16:26, Sergi Almacellas Abellana wrote:
> >> Hi,
> >>
> >> The account_deposit module defines a new kind of account (Deposit
> >> account) but there is no deposit account on the Spanish CoA. After a
> >> little bit of digging i found that the Spanish CoA includes deposit
> >> accounts for customers (4380) and suppliers (4070), so this accounts
> >> should be marked as deposit. This requires to add the account_deposit as
> >> dependency of the account_es module, but not sure if this is the best
> >> way as this module also adds new functionaly on party and invoice which
> >> is not relevant to people not using the deposit functionaly.
> >
> > You may put those account inside a extra depend module.
>
> The main issue here is that this account should be included on the
> balance sheet so probably the best is to use the deposit kind when the
> account_deposit module is installed and the other type when not installed.

I do not think it is possible to do that.

> > But usually, you have 1 account deposit per party so you create them and
> > they do not come from the standard chart.
>
> But the code groups by line party [1], so it's possible to have multiple
> parties on the same account (as the party required flag should be set
> for this accounts). Furthermore, I don't see how each party gets it's
> deposit account assigned. Am I missing something?

Indeed deposit account must have party checked.

[Sergi Almacellas Abellana]

El 07/02/18 a les 17:51, Cédric Krier ha escrit:

> On 2018-02-07 17:27, Sergi Almacellas Abellana wrote:
>> El 07/02/18 a les 16:43, Cédric Krier ha escrit:
>>> On 2018-02-07 16:26, Sergi Almacellas Abellana wrote:
>>>> Hi,
>>>>
>>>> The account_deposit module defines a new kind of account (Deposit
>>>> account) but there is no deposit account on the Spanish CoA. After a
>>>> little bit of digging i found that the Spanish CoA includes deposit
>>>> accounts for customers (4380) and suppliers (4070), so this accounts
>>>> should be marked as deposit. This requires to add the account_deposit as
>>>> dependency of the account_es module, but not sure if this is the best
>>>> way as this module also adds new functionaly on party and invoice which
>>>> is not relevant to people not using the deposit functionaly.
>>>
>>> You may put those account inside a extra depend module.
>>
>> The main issue here is that this account should be included on the
>> balance sheet so probably the best is to use the deposit kind when the
>> account_deposit module is installed and the other type when not installed.
>
> I do not think it is possible to do that.

I've achieved it by adding the the following code at the end of the xml
definition:

<data depends="account_deposit">
<record id="pgc_4070_normal" model="account.account.template"
update="1">
<field name="kind">deposit</field>
<field name="party_required" eval="True"/>
</record>
<record id="pgc_4380_normal" model="account.account.template"
update="1">
<field name="kind">deposit</field>
<field name="party_required" eval="True"/>
</record>
</data>

>
>>> But usually, you have 1 account deposit per party so you create them and
>>> they do not come from the standard chart.
>>
>> But the code groups by line party [1], so it's possible to have multiple
>> parties on the same account (as the party required flag should be set
>> for this accounts). Furthermore, I don't see how each party gets it's
>> deposit account assigned. Am I missing something?
>
> Indeed deposit account must have party checked.
>

Then it's possible to define a single account with multiple parties. So
for me it makes sense to mark the accounts on deposit on the account chart.

[Cédric Krier]

Are you sure that the ir.model.data is correct when the module
account_deposit is activated?

[Sergi Almacellas Abellana]

El 07/02/18 a les 18:22, Cédric Krier ha escrit:

fs_values only contains the values of the last update (kind and
party_required) but other fields are not computed. Which if i understand
correctly this is not correct.

Is this something that we should fix?

[Cédric Krier]

If we want to use this feature, yes the fs_values must reflect the sum
of what was written by the module.

[Sergi Almacellas Abellana]

El 08/02/18 a les 20:23, Cédric Krier ha escrit:

I'm not sure if it's worth to implement it. Let me explain: Currently we
are forced to update a record definition of the same module because the
new kind is not defined on the same module but on another one. The
problem is that account_es doest not depend on account_deposit and we
don't want to add the dependency. Normally this is fixed by adding the
code on a third module that depends on both modules.

I don't think there are so much uses cases for defining the same record
(with different values) on two different modules. Indeed I can not see
any other usage that fixing this issue.

For me it will be simpler to define the deposit kind on the account
module (so CoA modules can define accounts with the deposit kind). I
don't see any drawback of allowing this kind on the account module.

[Cédric Krier]

On 2018-02-12 10:03, Sergi Almacellas Abellana wrote:
> > If we want to use this feature, yes the fs_values must reflect the sum
> > of what was written by the module.
> I'm not sure if it's worth to implement it. Let me explain: Currently we
> are forced to update a record definition of the same module because the
> new kind is not defined on the same module but on another one. The
> problem is that account_es doest not depend on account_deposit and we
> don't want to add the dependency. Normally this is fixed by adding the
> code on a third module that depends on both modules.

I think there are use cases where it will be useful just like the
"depends" attribute on record because it increases the modularity.
Indeed I think we could extend the "depends" to the "field" tag and have
something like this:

<record>
<field name="kind">other</field>
<field name="kind" depends="account_deposit">deposit</field>
</record>

The parser should use the latest value matching the condition.

> I don't think there are so much uses cases for defining the same record
> (with different values) on two different modules. Indeed I can not see
> any other usage that fixing this issue.

No because it is an hack but having values depending on the modules is a
use case.

> For me it will be simpler to define the deposit kind on the account
> module (so CoA modules can define accounts with the deposit kind). I
> don't see any drawback of allowing this kind on the account module.

I think it is a too simple solution which does not scale.


On another point of view, the kind attribute is maybe the problem. A
selection field is maybe too limited and we may need a multiselection.
But using a Many2Many field will not be good for performance so we may
need to find a way to create MultiSelection fields.

[Sergi Almacellas Abellana]

El 12/02/18 a les 10:30, Cédric Krier ha escrit:

> On 2018-02-12 10:03, Sergi Almacellas Abellana wrote:
>>> If we want to use this feature, yes the fs_values must reflect the sum
>>> of what was written by the module.
>> I'm not sure if it's worth to implement it. Let me explain: Currently we
>> are forced to update a record definition of the same module because the
>> new kind is not defined on the same module but on another one. The
>> problem is that account_es doest not depend on account_deposit and we
>> don't want to add the dependency. Normally this is fixed by adding the
>> code on a third module that depends on both modules.
> I think there are use cases where it will be useful just like the
> "depends" attribute on record because it increases the modularity.
> Indeed I think we could extend the "depends" to the "field" tag and have
> something like this:
>
> <record>
> <field name="kind">other</field>
> <field name="kind" depends="account_deposit">deposit</field>
> </record>
>
> The parser should use the latest value matching the condition.
>

Ok I see your point and I agree that this will improve the modularity of
the system. JFR, I've created an issue to implement it:

https://bugs.tryton.org/issue7127


And also updated the spanish chart of accounts to use it:

https://bugs.tryton.org/issue7126