Re: [tryton-dev] Move origin issue when in same period
Le 08/05/2018 à 19:56, Cédric Krier a écrit : The origin must be saved before being assigned if you want to store the saved id. I submitted https://bugs.tryton.org/issue7421 to prevent the exception raising. Ok, I'm trying the following, based upon what I see e.g. in modelstorage.py: if move_origin.id is None or move_origin.id < 0: move_origin.save() # work-around for same period origins new_move.origin = move_origin This should keep use of save() down to the handful of cases where id is actually < 0 BTW, why does save(), for example on a move, automatically save() its lines? Is the problem because origin is unidirectional? -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/0f71a0b0-c227-606b-94c0-5863c58658e8%40netbsd.org.
[tryton-dev] Move origin issue when in same period
I came across a difficulty noticed during FEC generation (French plan) where I get the following exception: ... File "/trytond/modules/account_fr/account.py", line 315, in get_reference return line.move.origin.rec_name AttributeError: 'str' object has no attribute 'rec_name' To briefly explain the issue, it concerns a reversal entry having origin set to the initial entry at the same date (ie:cancel). As these entries are bulk loaded via an openerp2tryton migration script, Move.save() is invoked for all the moves in the period, period by period. What I notice is that the origin saved in the database is "account.move,-272790" so I presume the error is related to the fact that the referenced move is not yet saved when the origin was set, even though when really saved, the origin move will have been saved. Indeed, all the moves where the reversal entry is in a different period have the origin with a non-negative number, with no problem during FEC generation. It concerns only the moves generated in the same period for this scenario. So the question I pose, without resorting to individual saves on the moves which would probably have disastrous timing repercussions on the import (>35K moves), is there perhaps an outside chance that something is forgetting to verify the state (.reload()?) of the origin move prior to saving? Any other suggestion(s)? If needed, I can probably provide a proteus test script demonstrating the problem. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/a3bd28c5-d59e-f70b-c959-ae12474e5d40%40netbsd.org.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
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 -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/9bfd1cb1-5170-c0c5-3ab8-3622500bf459%40netbsd.org.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
Le 20/04/2018 à 20:22, Richard PALO a écrit :
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)PassifProvisionsProvisions >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()
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
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/d5cfeb94-ff1e-9875-1236-6f9e38d06f01%40netbsd.org.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
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)PassifProvisionsProvisions >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
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/19d49c68-e468-547f-8acf-1a2540086a5d%40netbsd.org.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
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)PassifProvisionsProvisions >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
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/68a6d8e7-be89-0b41-8de2-959f181cfa85%40netbsd.org.
Re: [tryton-dev] import_data and model account with account_account_type (RESEND)
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
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/190da4e6-afab-7482-0fa5-80769f105f8d%40netbsd.org.
[tryton-dev] pg_repack (resend)
I'm curious if anybody has tried and been able to get pg_repack (http://reorg.github.io/pg_repack/) working on a tryton db... cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/b1278bfb-31b8-714d-19c4-d2a63b93ec92%40netbsd.org.
[tryton-dev] import_data and model account with account_account_type (RESEND)
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 : Autres to Autres créances 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 -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/bb88ca9a-ddc0-2da3-9cd2-100a4458cba6%40netbsd.org.
Re: [tryton-dev] Tax Code Usage
Le 15/03/2018 à 12:48, Cédric Krier a écrit : Hi, I'm working on https://bugs.tryton.org/issue6013 For the migration, I need to define for each tax line if the amount is tax or base. So I write a script that use the existing couple (tax, code) from the tax definition to decide if it is a tax or a base. This works on the assumption that no tax code is used for both. Has anybody an counter example? Thanks, I notice in the French plan, that this seems to be the case. Go to the nested tax code list and note, for example, tax code 0030 is twice (base and tax) "Livraisons d'électricité, de gaz, de chaleur ou de froid imposables en France (base)" "0030""BAOU" "Livraisons d'électricité, de gaz, de chaleur ou de froid imposables en France" "0030""BAOU" -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/2ed75f08-437a-8635-0520-ac5e5fde2243%40netbsd.org.
[tryton-dev] product_brand?
Out of curiousity, has anybody already an implementation of product_brand working for recent (4.4+) tryton? -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/94cbfcfb-70c3-2ab4-9fe0-ccae6473287a%40netbsd.org.
Re: [tryton-dev] 80 cols on XML file
Le 20/12/2017 à 16:45, Bernat Brunet a écrit : 2017-12-20 15:55 GMT+01:00 Cédric Krier <cedric.kr...@b2ck.com <mailto:cedric.kr...@b2ck.com>>: Hi, I think we should remove the 80 cols limit on XML file. The rational is that XML file are indented by 4 spaces with at least 2 indentation ( and ) but also XML is quite verbose. So we reach the limit very quickly and so we add line break which makes the XML more difficult to read. Also most of the time 'pyson' attribute already exceed the limit and it can not be break in multiple line. I think we should be more flexible. For example the line with 'model' and 'id' is more readable when not split. But is more readable if each attribute is on his own line. So I think the style should be one line with all attributes or one attribute per line, but not allow mixed. +1 For me will be better if it's one attribute per line. Because sometimes when working with the laptop all in one line wont be good. I'm starting to tend toward what certain software do in terms of leaving that sort of formatting to pretty printers like xml_pp, xmlstarlet or what have you. In general, the output file is most certainly not intended to be interpreted directly by a human without some sort of tool or program (read: filter). In other words, it could simply all go on one line. cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/080b7372-020e-6cae-7b27-9c63f98627ca%40netbsd.org.
Re: [tryton-dev] resend:upgrade warnings with recent develop branch
Le 03/05/2017 à 10:12, Cédric Krier a écrit : On 2017-05-01 22:39, Richard PALO wrote: [resend, g$ggle still broke, apparently] full upgrade with recent 'develop' shows the following: 4815 140668832162880 [2017-05-01 16:35:10,058] WARNING trytond.backend.postgresql.table Unable to set column company of table account_fiscalyear_invoice_sequence not null ! Try to re-run: trytond.py --update=module If it doesn't work, update records and execute manually: ALTER TABLE "account_fiscalyear_invoice_sequence" ALTER COLUMN "company" SET NOT NULL Indeed I have 25 records where company is not set here (single company db). Is this a case where I need to manually set the company (id=1), or is it a possible omission in the migration code to check? I'm pretty sure it is because you are migrating between two development versions. We do not support such migration, only between releases. I am pretty sure that this base was always on a released version since creation (03/2015) which I believe was on 3.4. It is only very recently, after 4.2 in waiting for last few bits for 4.4 (which has subsequently been released) that it is on the trunk master. The questions remain, though, as to the rectification needed. -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/7346ef4e-1c3a-db69-7321-fec84fa0c7cf%40netbsd.org.
[tryton-dev] resend:upgrade warnings with recent develop branch
[resend, g$ggle still broke, apparently] full upgrade with recent 'develop' shows the following: 4815 140668832162880 [2017-05-01 16:35:10,058] WARNING trytond.backend.postgresql.table Unable to set column company of table account_fiscalyear_invoice_sequence not null ! Try to re-run: trytond.py --update=module If it doesn't work, update records and execute manually: ALTER TABLE "account_fiscalyear_invoice_sequence" ALTER COLUMN "company" SET NOT NULL Indeed I have 25 records where company is not set here (single company db). Is this a case where I need to manually set the company (id=1), or is it a possible omission in the migration code to check? I see as well: 4815 140668832162880 [2017-05-01 16:35:29,739] INFO trytond.convert Deleting 58@ir.property from account_payment.property_payment_group_sequence 4815 140668832162880 [2017-05-01 16:35:29,739] WARNING trytond.convert Could not delete id 58 of model ir.property because model no longer exists. 4815 140668832162880 [2017-05-01 16:35:29,760] INFO trytond.convert Deleting 57@ir.property from product.property_cost_price_method 4815 140668832162880 [2017-05-01 16:35:29,761] WARNING trytond.convert Could not delete id 57 of model ir.property because model no longer exists. 4815 140668832162880 [2017-05-01 16:35:29,761] INFO trytond.convert Deleting 1@ir.property from product.property_product_cost_price_method 4815 140668832162880 [2017-05-01 16:35:29,762] WARNING trytond.convert Could not delete id 1 of model ir.property because model no longer exists. 4815 140668832162880 [2017-05-01 16:35:29,773] INFO trytond.convert Deleting 2@ir.property from party.property_party_sequence 4815 140668832162880 [2017-05-01 16:35:29,774] WARNING trytond.convert Could not delete id 2 of model ir.property because model no longer exists. Not clear if these can simply be deleted or not. id | create_uid |create_date | res | value | write_uid | field | write_date | company +++-+---+---+---++- 1 | 0 | 2015-03-22 04:43:04.18063 | | ,fixed| | 732 || 2 | 0 | 2015-03-22 04:44:17.036349 | | ir.sequence,1 | | 909 || 57 | 0 | 2016-05-06 17:12:16.543205 | | ,fixed| | 732 || 58 | 0 | 2016-05-07 03:53:08.345128 | | ir.sequence,4 | | 2404 || (4 lignes) I noticed that there are two other records with a null 'res', namely for the default client and supplier accounts in account.account. I guess I presume they are okay but should there be some value set for 'res'? Something like 'party.party,1' which is the party id of the company? Cheers, -- Richard PALO -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/3b2c72fe-864f-7dfd-b8fb-365d09a29e1c%40netbsd.org.
[tryton-dev] reconciliation in GeneralLedgerLine
I prototyped adding display of line.reconciliation.name in General Ledger reports iff the reconciliation date is '<=' to the end_date of the end_period (if specified) or of the fiscal year. This seems to work nicely in the generated report, but for 'correctness' I'd like to filter the column already in the GeneralLedgerLine output screen instead. I initially thought to put the fields.Many2One for account.move.reconciliation I added in a fields.Function and provide a 'getter' function get_reconciliation, but then I realised that I probably didn't have the context necessary (namely GeneralLedgerAccountContext) in order to do pick up fiscalyear and end_period. How could this be done? Is there any way to filter columns as opposed to records? cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/05d06957-fc0c-3059-68f0-841198ff6a47%40netbsd.org.
[tryton-dev] Re: github not in sync
/stock_package_shipping_ups (4.2.0-6-ge63541a) 104ec3d54ac92d66486861b1fe89a1385901499a trytond/modules/stock_product_location (4.2.0-5-g104ec3d) c44893cb3507e761d9900c34345648a1cd763acc trytond/modules/stock_shipment_measurements (heads/develop) da6936a4fce48c014a495068639cb3fd53c7b397 trytond/modules/stock_split (4.2.0-3-gda6936a) e5d026b620625c36898476184ce9b3327a36616a trytond/modules/stock_supply (4.2.0-12-ge5d026b) b190a6c886b0972d928508181a6c63433e3a0b69 trytond/modules/stock_supply_day (4.2.0-3-gb190a6c) a7d9acf4f42771306cd7a5f1b0f545a4963dad9d trytond/modules/stock_supply_forecast (4.2.0-4-ga7d9acf) 3414044824cbd1813f0e62559a28205efded31c4 trytond/modules/stock_supply_production (4.2.0-12-g3414044) ddd172c59c9a9e09e253b59c91198530cd02a14a trytond/modules/timesheet (4.2.0-4-gddd172c) 9fd54b5ee98170144cdeb68854bd90d56c763ba6 trytond/modules/timesheet_cost (4.2.0-3-g9fd54b5) 63db637ad5a22e5986e5d83bf12d5d23e2e84349 trytond/modules/web_user (4.2.0-3-g63db637) 9e2e7a6a7fa67b559d268db87a586f67a212a23c trytond/modules/webdav (4.2.0-4-g9e2e7a6) cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/f646a0ef-e155-e841-552c-8244b590d9c3%40netbsd.org.
Re: [tryton-dev] github not in sync
Le 27/03/2017 à 00:39, Cédric Krier a écrit : On 2017-03-26 12:54, Richard PALO wrote: Just finally tried to use the github mirror as I'm much more confortable with git, but there seems to be a number of modules either missing or not up to date.. Could you provide the list? Quickly checking, the following seem to be missing: account_deposit account_payment_sepa_cfonb account_tax_rule_country sale_extra sale_stock_quantity stock_lot_sled for those not up to date, there's at least the following: account_dunning* bank sale_invoice_grouping timesheet_cost Also, for those that are there, any particular reason that they aren't added as submodules located in trytond's trytond/modules (admittedly it's not *that* difficult to add them, but still...) What would it bring? What disadvantage could it add? How will it be possible to have only a subset? How will it work with the mirror script? To start with, 'git clone --recursive' brings all submodules (similar to 'hg nclone', I guess). I'm not sure why you would want only a subset, but if a dev only wants to selectively pick submodules, then he would probably not use recursive on the initial clone, then only init/update the module(s) needed. Don't know much about your script, either, but I would imagine you could add whatever hooks you might need into your master git repository that will ultimately pushed to github (and/or bitbucket and/or elsewhere). Cheers, -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/a5034ba4-bc1e-6051-da0e-fb7c6488baef%40netbsd.org.
[tryton-dev] github not in sync
Just finally tried to use the github mirror as I'm much more confortable with git, but there seems to be a number of modules either missing or not up to date.. Also, for those that are there, any particular reason that they aren't added as submodules located in trytond's trytond/modules (admittedly it's not *that* difficult to add them, but still...) cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/5f54057e-7958-8a99-44d6-c8ce027b38c7%40netbsd.org.
[tryton-dev] Re: performance of chart of accounts?
Le 24/01/2017 à 11:03, Cédric Krier a écrit : On 2017-01-24 07:52, Richard PALO wrote: Le 23/01/2017 à 21:53, Cédric Krier a écrit : On 2017-01-23 07:16, Richard PALO wrote: Are there any tuning remedies? If not, what would things be like if we were to migrate a company with an average of over 5500 movements per year? Normally it should not depend on the number of moves. For me, the slowness is the number of queries but not the computation of the balance/debit/credit. Those computations should be almost linear (with a very small coefficient). Perhaps this could be split up to run parallel by the top (N) level(s), for example, in French PCG, run parallel queries for each class (1 .. 8) or subclass (1[0-8], 2[0-9] et cetera)... I do not think it will improve. There are very few parts that could be run in parallel like the SQL queries (but only if # accounts > 1000) and the cumulate function (but it should normally iterate only once). Also the machineries to make it parallel will probably cost more then it will benefit, without talking about the complexity it will create. Yeah, I can understand diminishing returns... will just have to avoid using + except at low levels... thanks for the explanations. Also, unfortunately it appears that the 'views' still only update the final balance field and not the debit/credit fields. I thought I already filed an issue including that way back but can't seem to find it. Is it on 'purpose' to exclude displaying the total movements debit/credit as well as, Yes it is on purpose (since 1.0). okay, though this makes it awkward online, will have to deal with this via custom reporting. eventually, the initial balance in the chart of accounts? I guess you are looking for the General Ledger instead of the Chart of Account. (which will load much faster as it is a list) in many respects, especially using filters, GL is indeed somewhat more versatile. Now that I try to compare, is there really any reason not to simply replace chart of accounts by reports->general ledger? No it makes no sense as GL is based on the CoA. CoA? The views would/should probably need to be added back, though, as they seem to be missing in both the display and in the reports. Usually, account without moves are not shown on the GL. View accounts have never any moves. But it could be discussed but probably on tryton@ where accounting guys should be. except I can't seem to post any longer neither directly nor via gmane group interface... As to the threaded performance, I've been meaning to check out using uwsgi, but it's still a bit premature to spend time on that for the moment. As I said, it will not help for this specific issue because it is the client who perform sequential request because of the design of GTK expand all feature and the lazy loading of Tryton. I did mean for other use cases, naturally. cheers -- Richard PALO -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/o67p6j%24cp8%241%40blaine.gmane.org.
[tryton-dev] Re: performance of chart of accounts?
Le 23/01/2017 à 21:53, Cédric Krier a écrit :
On 2017-01-23 07:16, Richard PALO wrote:
[2nd resend via gmane... googlegroups seems busted as usual]
Nothing to do with google groups, we configured to not allow anonymous
post, only members can. It is configured on gmane if there was still a
web interface.
I'm not so sure, I have [tried to have, anyway] my two primary email addressses
registered via tryton{,-dev,-fr}+subscr...@googlegroups.com with both confirmed.
typically one works or the other (but not both) and neither seem to work
directly any more for some reason...at least not consistently between the
groups.
This one that finally worked was sent to group:gmane.comp.python.tryton.devel
Previously it seemed to be the opposite, I needed to send directly to
tryton*@googlegroups.com
Perhaps related to previous discussion of GL and perhaps of Issue4028 and co,
I have two bookyears in a db now under tryton 4.2 with PCG French
(neither closed yet) and a total of 103 movements (2/3 from older bookyear)
Opening the chart of accounts for the later year (2016), selecting
the only line 'Plan comptable (French)' and doing a full expand ('+')
takes on the average 4 *minutes* on a quiet system!
Full expand is quiet expensive because of the behavior of GTK.
It triggers an event on each node to open them. The client tries to
optimize as much as possible. We load all sibling children of the first
parent at once to minimize the number of queries. But it is a compromise
between manual expand and automatic expand.
It seems to peg a single core on a 32GB 12*core system (2,3G AMD 6338P)
running PostgreSQL 9.6.1 locally and directly on the socket (not the tcp port).
Usual Python threading model. The embedded server is the default
from Werkzeug which is only threaded. For better performance it is
better to use a pre-forked WSGI server.
But for this case, it will not change anything because each queries are
serialized, they depend on the result of the previous to do the next one
(read children to request the second children level).
Are there any tuning remedies? If not, what would things be like if we
were to migrate a company with an average of over 5500 movements per year?
Normally it should not depend on the number of moves. For me, the
slowness is the number of queries but not the computation of the
balance/debit/credit. Those computations should be almost linear (with a
very small coefficient).
Perhaps this could be split up to run parallel by the top (N) level(s),
for example, in French PCG, run parallel queries for each class (1 .. 8)
or subclass (1[0-8], 2[0-9] et cetera)...
Also, unfortunately it appears that the 'views' still only update the final
balance field and not the debit/credit fields.
I thought I already filed an issue including that way back but can't seem to
find it.
Is it on 'purpose' to exclude displaying the total movements debit/credit as
well as,
Yes it is on purpose (since 1.0).
eventually, the initial balance in the chart of accounts?
I guess you are looking for the General Ledger instead of the Chart of Account.
(which will load much faster as it is a list)
Now that I try to compare, is there really any reason not to simply replace
chart of accounts
by reports->general ledger? The views would/should probably need to be added
back, though, as they seem to be missing in both the display and in the reports.
This is particularly frustrating in the French PCG as the account names are
structured 'in context' (check out classe 2 or 6, for example).
Also, I just noticed too that filters don't seem to do much (on name or code)
in the
'chart of accounts' so 'general ledger' seems to much more flexible here.
As to the threaded performance, I've been meaning to check out using uwsgi, but
it's still a bit premature to spend time on that for the moment.
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/o66tjl%2453o%241%40blaine.gmane.org.
[tryton-dev] performance of chart of accounts?
[2nd resend via gmane... googlegroups seems busted as usual]
Perhaps related to previous discussion of GL and perhaps of Issue4028 and co,
I have two bookyears in a db now under tryton 4.2 with PCG French
(neither closed yet) and a total of 103 movements (2/3 from older bookyear)
Opening the chart of accounts for the later year (2016), selecting
the only line 'Plan comptable (French)' and doing a full expand ('+')
takes on the average 4 *minutes* on a quiet system!
It seems to peg a single core on a 32GB 12*core system (2,3G AMD 6338P)
running PostgreSQL 9.6.1 locally and directly on the socket (not the tcp port).
Are there any tuning remedies? If not, what would things be like if we
were to migrate a company with an average of over 5500 movements per year?
Also, unfortunately it appears that the 'views' still only update the final
balance field and not the debit/credit fields.
I thought I already filed an issue including that way back but can't seem to
find it.
Is it on 'purpose' to exclude displaying the total movements debit/credit as
well as,
eventually, the initial balance in the chart of accounts?
cheers
--
Richard PALO
--
Richard PALO
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/o6474i%24mkt%241%40blaine.gmane.org.
[tryton-dev] Re: RFC on autocompletion of zip-city
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 25/06/14 01:20, Cédric Krier a écrit : On 17 Jun 01:24, Cédric Krier wrote: Hi, I started an POC [1] to add autocompletion of zip code and city on addresses. It just adds a Model to store the couple zip-code per country (and optionally per subdivision). I also plan to write a proteus script to load such couples from http://www.geonames.org/ [1] https://bugs.tryton.org/issue4004 The script has been added. I tested with some countries so be sure yours are working. As far as I see there were only talk about naming which is out of the scope. This is quite cool... needs proteus to install . I tried importing 'FR' since over an hour now, it's still running.. (pgadmin3 shows country_zip at just over 26K at the moment ) Notice the following in the postgres logs: LOG: connexion reçue : hôte=::1 port=54129 LOG: connexion autorisée : utilisateur=tryton, base de données=trytest LOG: déconnexion : durée de la session : 0:00:00.212 utilisateur=tryton base=trytest hôte=::1 port=47725 LOG: connexion reçue : hôte=::1 port=32949 LOG: connexion autorisée : utilisateur=tryton, base de données=trytest LOG: déconnexion : durée de la session : 0:00:00.218 utilisateur=tryton base=trytest hôte=::1 port=54129 LOG: connexion reçue : hôte=::1 port=61172 LOG: connexion autorisée : utilisateur=tryton, base de données=trytest LOG: déconnexion : durée de la session : 0:00:00.136 utilisateur=tryton base=trytest hôte=::1 port=32949 LOG: connexion reçue : hôte=::1 port=34565 LOG: connexion autorisée : utilisateur=tryton, base de données=trytest LOG: déconnexion : durée de la session : 0:00:00.142 utilisateur=tryton base=trytest hôte=::1 port=61172 LOG: connexion reçue : hôte=::1 port=36351 LOG: connexion autorisée : utilisateur=tryton, base de données=trytest LOG: déconnexion : durée de la session : 0:00:00.149 utilisateur=tryton base=trytest hôte=::1 port=34565 LOG: connexion reçue : hôte=::1 port=53505 LOG: connexion autorisée : utilisateur=tryton, base de données=trytest LOG: déconnexion : durée de la session : 0:00:00.131 utilisateur=tryton base=trytest hôte=::1 port=36351 It seems that each record is a new connection (database open/update/close)? FR has over 51K records. I know this is a one-time per db operation, but imagine multiple databases, and multiple countries I wonder if it would be quicker to do something like convert to trytond csv format and do a single transaction bulk load? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUgtaJAAoJECAB22fHtp27uBkH/2EboDId2IQvIdYqE/fWg+GN GMyTUWjPbfpdCW9FFaFp3ZsXRt7JUb4imnvnH1cAWt0GOiAO7/FvXwnC8ZrpdjEC tg6791T7xhbeXl1HcghGy3RZ1+f/KHXsWsC2iHbcwQ+N8tZyQzcDZFOLnq66fTle T27VqUewZe9N6uiplhnFNbRMbDRkdoNMD+VgJI/6DwUqf6o0A1hhMK9Cmc2p/x07 wkOUlSdjKnO4j9NDRs2OE0sY7RyMwCgF0gNB8sPRABtpzI9n+zvBg+XJpbUICRdY B4N5kjHvHrTP8a1gV965mq5le1Hag3Yj+0f0GyKz7wtuedgVFQpbCv+Ig0RWzBs= =ZSmw -END PGP SIGNATURE-
