import_data and model account with account_account_type (RESEND)

[Richard PALO]

In the French plan, there are unfortunately 7 instances of account_account_type_template
with the name 'Autres'... but in the xml, there are indeed unique ID's...

Is the mapping of these (xml id => sql id) stored somewhere it can be accessed
to somehow facilitate import? That is, it would be very useful to be able to
use the xml id in import_data as unique label for the sql id.

Example:
> id,name,active,code,kind,parent,party_required,reconcile,deferral,type
> 409600,Fournisseurs - Créances pour emballages et matériel à rendre,True,409600,other,4096,True,True,True,Autres

If I try this, the import fails because there are :
7 instances of account types with the name 'Autres'.

Currently, I have locally changed line 180 in account_fr.xml from :
> <field name="name">Autres</field>
to
> <field name="name">Autres créances</field>
and updated my csv for import accordingly.

Alternately, all the account types names must be made unique (in conformance to the xml id).
If this is the only solution, please confirm and I'll file an issue with a suggested patch.

BTW, this happens to be an example of manually adding the account padded with
zeros to 6 places as I can't seem to get a working trytond-account_code_digits
with account_fr on 4.6 (or default). There are other cases as well.

--

Richard PALO

[Cédric Krier]

On 2018-04-18 17:40, Richard PALO wrote:
> In the French plan, there are unfortunately 7 instances of account_account_type_template
> with the name 'Autres'... but in the xml, there are indeed unique ID's...
>
> Is the mapping of these (xml id => sql id) stored somewhere it can be accessed
> to somehow facilitate import?

In "ir.model.data".

> That is, it would be very useful to be able to
> use the xml id in import_data as unique label for the sql id.

Better to write a proteus script.

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

[Richard PALO]

Le 19/04/2018 à 17:38, Cédric Krier a écrit :
> On 2018-04-18 17:40, Richard PALO wrote:
>> In the French plan, there are unfortunately 7 instances of account_account_type_template
>> with the name 'Autres'... but in the xml, there are indeed unique ID's...
>>
>> Is the mapping of these (xml id => sql id) stored somewhere it can be accessed
>> to somehow facilitate import?
>
> In "ir.model.data".

Great, for example in my case in hand I find a record with
fs_id = 'creances_autres' having db_id = 196
which is correct for account_account_type_template

Guess I'm not sure what do I need to do to get 'creances_autres' (unique xml id)
to work instead of using the name 'Autres' for the 'type' (last field in account.csv)
Seems account_account_type_template record id's differ from account_account_type ids.

Perhaps first updating the 'type' field in each data record using the fs_id (e.g. 'creances_autres')
to the value found looking up account_account_type having 'template' = the db_id (196)
followed by the actual import_data?

That is, using the real 'id' instead of 'name' should work, right?

>
>> That is, it would be very useful to be able to
>> use the xml id in import_data as unique label for the sql id.
>
> Better to write a proteus script.
>

?? I believe migrate.py is a proteus script, no?

I'm in: load_csv(Model.get('account.account'), load['account'])

which invokes Model.import_data...

--
Richard PALO

[Sergi Almacellas Abellana]

El 19/04/18 a les 18:14, Richard PALO ha escrit:

> Le 19/04/2018 à 17:38, Cédric Krier a écrit :
>> On 2018-04-18 17:40, Richard PALO wrote:
>>> In the French plan, there are unfortunately 7 instances of
>>> account_account_type_template
>>> with the name 'Autres'... but in the xml, there are indeed unique
>>> ID's...
>>>
>>> Is the mapping of these (xml id => sql id) stored somewhere it can be
>>> accessed
>>> to somehow facilitate import?
>>
>> In "ir.model.data".
>
> Great, for example in my case in hand I find a record with
>   fs_id = 'creances_autres' having db_id = 196
> which is correct for account_account_type_template
>
> Guess I'm not sure what do I need to do to get 'creances_autres' (unique
> xml id)
> to work instead of using the name 'Autres' for the 'type' (last field in
> account.csv)
> Seems account_account_type_template record id's differ from
> account_account_type ids.

You can use the following code to get the db ids:

pool = Pool()
ModelData = pool.get('ir.model.data')

db_id = ModelData.get_id('account_fr', 'creances_autres')

And then you can get the type of your company with:

Type = pool.get('account.type')

type, = Type.search([('company', '=', company.id), ('template', '=',
db_id)])


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

[Richard PALO]

Le 20/04/2018 à 11:35, Sergi Almacellas Abellana a écrit :
>
> You can use the following code to get the db ids:
>
> pool = Pool()
> ModelData = pool.get('ir.model.data')
>
> db_id = ModelData.get_id('account_fr', 'creances_autres')
>
> And then you can get the type of your company with:
>
> Type = pool.get('account.type')
>
> type, = Type.search([('company', '=', company.id), ('template', '=',
> db_id)])
>
>

Thanks, I'm finding the correct account.account.type instance now with
the following simplified snippet:
> md, = ModelData.find(['fs_id', '=', data[-1]])
> at, = AccountType.find(['template', '=', md.db_id])
>

But import_data() still balks...

Doesn't seem to like either at.id nor str(at.id)

Looked a bit at the code, which suggests that .rec_name should be used,
but that fails as well

> data[-1] = at.rec_name
> Account.import_data(header, [data], Account._config.context)
>

The exception message, which is for a type 'provisions_charges',
the first record in my file, gives:
> trytond.exceptions.UserError: ('UserError', ("Relation not found: 'Plan de types de compte (France)\\\\Passif\\\\Provisions\\\\Provisions >pour charges' in account.account.type", ''))
The updated 'data' record is as follows:
> ['158200', 'Provisions pour risques et charges litiges', 'True', '158200', 'other', '158', '', '', 'True', 'Plan de types de compte
> (France)\\Passif\\Provisions\\Provisions pour charges']

I'm wondering if it's a quoting problem returned from rec_name?

Any suggestions?
--
Richard PALO

[Richard PALO]

Le 20/04/2018 à 20:15, Richard PALO a écrit :

>
> Thanks, I'm finding the correct account.account.type instance now with
> the following simplified snippet:
>> md, = ModelData.find(['fs_id', '=', data[-1]])
>> at, = AccountType.find(['template', '=', md.db_id])
>>
>
> But import_data() still balks...
>
> Doesn't seem to like either at.id nor str(at.id)
>
> Looked a bit at the code, which suggests that .rec_name should be used,
> but that fails as well
>
>> data[-1] = at.rec_name
>> Account.import_data(header, [data], Account._config.context)
>>
>
> The exception message, which is for a type 'provisions_charges',
> the first record in my file, gives:
>> trytond.exceptions.UserError: ('UserError', ("Relation not found: 'Plan de types de compte (France)\\\\Passif\\\\Provisions\\\\Provisions >pour charges' in account.account.type", ''))
> The updated 'data' record is as follows:
>> ['158200', 'Provisions pour risques et charges litiges', 'True', '158200', 'other', '158', '', '', 'True', 'Plan de types de compte
>> (France)\\Passif\\Provisions\\Provisions pour charges']
>
> I'm wondering if it's a quoting problem returned from rec_name?
>
> Any suggestions?
>

BTW, It's choking in import_data's get_many2one()

--
Richard PALO

[Richard PALO]

Unless I'm missing something, this can not work currently.

The query generated to lookup 'rec_name' uses the simple 'name' :
> 'SELECT "a"."id" AS "id", "a"."balance_sheet" AS "balance_sheet", "a"."company" AS "company", "a"."create_date" AS "create_date",
> "a"."create_uid" AS "create_uid", "a"."display_balance" AS "display_balance", "a"."income_statement" AS "income_statement", "a"."name" AS
> "name", "a"."parent" AS "parent", "a"."sequence" AS "sequence", "a"."template" AS "template", "a"."write_date" AS "write_date",
> "a"."write_uid" AS "write_uid", CAST(EXTRACT(%s FROM COALESCE("a"."write_date", "a"."create_date")) AS VARCHAR) AS "_timestamp" FROM
> "account_account_type" AS "a" WHERE (((("a"."name" = %s))) AND ((("a"."company" IN (%s))))) ORDER BY "a"."sequence" ASC NULLS FIRST,
> "a"."id" ASC LIMIT 2'

but get_rec_name() returns the hierarchy of names when there is a parent type,
case not treated for but which is *always* the case for account_account_type.

If I set on the header 'type:id', then the lookup seems to expect the identifier of
the account_account_type_template and not the instance of it in account_account_type
as it invokes ModelData.get_id() much like Sergi mentioned (and must be specified
like 'account_fr.provisions_charges'

This seems to imply indirectly what I feared in that the simple name *must* be unique
else the supporting code must know about treating for hierarchical names
and/or know about treating the instantiated template tables
and/or have a means to stipulate that the db 'id' is supplied for relations
(something like 'type:dbid').

cheers,
--
Richard PALO

[Cédric Krier]

On 2018-04-21 09:09, Richard PALO wrote:
> but get_rec_name() returns the hierarchy of names when there is a parent type,
> case not treated for but which is *always* the case for account_account_type.

Indeed, it will be good to customize the search_rec_name like in
party.category.

> If I set on the header 'type:id', then the lookup seems to expect the identifier of
> the account_account_type_template and not the instance of it in account_account_type
> as it invokes ModelData.get_id() much like Sergi mentioned (and must be specified
> like 'account_fr.provisions_charges'

Yes ':id' suffix works only for XML id because they are the only unique
ID valid on different databases.


The script openerp2tryton is just a starting skeleton and the CSV import
is not the most powerful tool. It was used in openerp2tryton for simple
case. But it is still more powerful to write proteus script instead.

[Richard PALO]

Le 21/04/2018 à 10:23, Cédric Krier a écrit :
> On 2018-04-21 09:09, Richard PALO wrote:
>> but get_rec_name() returns the hierarchy of names when there is a parent type,
>> case not treated for but which is *always* the case for account_account_type.
>
> Indeed, it will be good to customize the search_rec_name like in
> party.category.
>
>> If I set on the header 'type:id', then the lookup seems to expect the identifier of
>> the account_account_type_template and not the instance of it in account_account_type
>> as it invokes ModelData.get_id() much like Sergi mentioned (and must be specified
>> like 'account_fr.provisions_charges'
>
> Yes ':id' suffix works only for XML id because they are the only unique
> ID valid on different databases.
>
>
> The script openerp2tryton is just a starting skeleton and the CSV import
> is not the most powerful tool. It was used in openerp2tryton for simple
> case. But it is still more powerful to write proteus script instead.
>

I tried adding the method search_rec_name() on account_account_type
but it doesn't seem to get called during import_data(). missing glue?

re: ':id', this is fine and preferred.
The point is that only the template classes have this (directly getting the dbid),
the instantiated classes need to reference that via template=dbid

So I'll just update account_account_template instead of account_account and do so
prior to creating the chart of accounts.. should have thought of that sooner:-/

WRT proteus script, I guess I don't understand, openerp2tryton seems to me a proteus
script as it *is* using proteus... how could it not be?

cheers,
--
Richard PALO

[Cédric Krier]

On 2018-04-21 10:23, Cédric Krier wrote:
> On 2018-04-21 09:09, Richard PALO wrote:
> > but get_rec_name() returns the hierarchy of names when there is a parent type,
> > case not treated for but which is *always* the case for account_account_type.
>
> Indeed, it will be good to customize the search_rec_name like in
> party.category.

I wrote a generic Mixin for such tree model: https://bugs.tryton.org/issue7383