DomainValidationError when installing experimental localization module

Support Developer
1

I am busy setting up an accounting localization module for South Africa: GitHub - Uber5/tryton-account-za-experimental: Accounting Localization Module for South Africa for Tryton, Experimental. When I install the module in a fresh database, I get this error:

trytond.model.modelstorage.DomainValidationError: The value “1” for field “Payable” in “South African Account Type Chart\Liability\Current Liabilities\Payable” of “Account Type Template” is not valid according to its domain.

The domain for field “payable” is:

 payable = fields.Boolean("Payable",
    domain=[
        If((Eval('statement') != 'balance')
            | Eval('assets', False),
            ('payable', '=', False), ()),
        ],
    states={
        'invisible': ((Eval('statement') != 'balance')
            | Eval('assets', False)),
        })

When I debug the relevant code (trytond/trytond/model/modelstorage.py · 19eb86603b10b6c5992f631fe44a352817e84b14 · Tryton / Tryton · GitLab), I see this:

→ raise DomainValidationError(
(Pdb) records[0].payable
1
(Pdb) records[0].statement
‘balance’
(Pdb) records[0].assets
1

As I understand it, the condition of the domain constraint is not met. Why do I get a DomainValidationError, then?

I am using trytond 6.8.10.

2

More context: I generated account.xml and tax.xml as described here: DomainValidationError when installing · Issue #1 · Uber5/tryton-account-za-experimental · GitHub

3

Hello,

If think the condition is met.

Eval('assets', False) will evaluate to True (since its value is 1), so the first branch of the If will be used (| means or): payable must be False.

4

That makes sense, thanks @JCavallo ! It does not solve my problem yet, though.

My next question is: Why does Eval('assets', False) evaluate to True? assets is not set for this account template, neither for any of its parents. So I would expect assets to be False or None.

5

Are you sure records[0] is the one that fails ?

Does debugging invalid_record yields the same field values ?

Also, the domain that you see in the account module may have been overriden in another module, you can print cls.payable.domain to make sure of it.

6

This is what I get in the debugger for invalid_record:

(Pdb) invalid_record
Pool().get('account.account.type.template')(148)
(Pdb) invalid_record.name
'Payable'
(Pdb) invalid_record.assets
1

There is only one account.account.type.template with name “Payable”, so this must be the one.

And here is the domain:

(Pdb) cls.payable.domain
[If(Or(Not(Equal(Eval('statement', ''), 'balance')), Eval('assets', False)), ('payable', '=', False), ())]

My understanding: (1) The domain is not overwritten by another module. (2) The reason for invalid_record.assets being True is still a mystery.

7

Since I am not very familiar with the details of accounting configuration, my next step would be to debug the create function on the template, and check what parameters it gets.

But this is just debugging, I do not have a real clue as to why the field would be True.

You could try explicitely setting assets to False in your xml file, maybe that would do it (though I would still be curious what set the value to True in the first place).

8

A payable should not have the asset flags and this is what it is validated by the domain.

Assets must me receivable accounts (or other kinds of assets).
You should fix the definition of your accounts to match the domain.

9

@pokoli Thank you for explaining this, it makes sense. My definition does not have the assets flag, though. Why ist assets still 1?

@JCavallo setting assets to False explicitly works! See my latest commit.

This works for me as a workaround. The behavior observed is not intuitive, though, especially as I’ve seen other account templates / localization modules where assets was not set to False for payable accounts explicitly.

10

@fishbein2 The most probable is that a xml record with the same id was loaded which had the assets flag to True. Maybe you iterated / renamed ids in the xml file?

Tryton update does not “unset” field that are not explicitely defined in the xml file, so this can happen (and is a real pain to understand).

What you could try is to create a new DB from sratch, and install your module without your latest commit to see if the problem still happens. I did not mention it earlier because your opening post said that it was already the case, but the symptoms match.

11

@JCavallo I can confirm your suspicion: To verify, I started with an empty database, with the field assets being unset for the Payable account. The result is that I was able to install the module, and configure the chart of accounts for the new company successfully. (I had to fix another, unrelated issue, though.)

I feel the pain of this scenario, i.e. not being able to “unset” a field by omitting it :wink: … fortunately this is a problem of module development only, not so much for users installing modules. At least this is my understanding. What I may decide to do (to avoid this issue going forward): I can change my script that creates account.xml so that it does not rely on default values, but rather writes all values explicitly. Let me know if you think this is a good approach.

Thanks for your help today, @JCavallo and @pokoli ! Tryton has an amazing community, and I hope I can contribute back at some point.

12

Forcing the values for all field may not be worth it.

As you correctly deduced, it is only a real problem during development, unless you change the fields in a subsequent release, but in that case you will usually be aware of the problem (especially since it already bit you once).

13

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.