Re: [tryton-dev] Move origin issue when in same period
On 2018-05-08 22:46, Richard PALO wrote: > BTW, why does save(), for example on a move, automatically save() its lines? > Is the problem because origin is unidirectional? Because proteus simulate the behavior of other clients. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ -- 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/20180508205226.GC12271%40kei.
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.
Re: [tryton-dev] Move origin issue when in same period
On 2018-05-08 18:48, Richard PALO wrote: > 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)? 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. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ -- 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/20180508175617.GA12271%40kei.
[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.