Created on 2021-04-05.10:25:55 by smn, last changed 7 days ago by roundup-bot.
New changeset 61e7597393ed by Nicolas Évrard in branch 'default': Computes GeneralLedger timespan on either dates or period https://hg.tryton.org/tryton-env/rev/61e7597393ed New changeset db9c14d3deb3 by Nicolas Évrard in branch 'default': Computes GeneralLedger timespan on either dates or period (scenario patch) https://hg.tryton.org/tryton-env/rev/db9c14d3deb3
New changeset 1b3d9d7a758f by Nicolas Évrard in branch 'default': Computes GeneralLedger timespan on either dates or period https://hg.tryton.org/modules/account/rev/1b3d9d7a758f New changeset 9f6bf9d17129 by Nicolas Évrard in branch 'default': Computes GeneralLedger timespan on either dates or period (scenario patch) https://hg.tryton.org/modules/account/rev/9f6bf9d17129
* Sergi Almacellas Abellana [2021-07-06 08:16 +0200]: >@nicoe I let you work on this issue. ACK
@nicoe I let you work on this issue.
For me review351991002 is a better solution because it does not alter
Move.query_get which is already too complex. And it will require to also include the context reset of review348161002.
But as-is it can not be backported, it should not have a changelog entry and it should work without modification of the scenario (I guess it the modifications are only to test the special case).
* Sergi Almacellas Abellana [2021-05-24 08:55 +0200]: > >Sergi Almacellas Abellana <email@example.com> added the comment: > >@nicoe could you share the difference between both patches? Yes I replied in a hurry yesterday. My patch considers that you use either periods or dates but not both thus it does not require to change MoveLine.query_get (basicaly you put the complexity in query_get I put it in get_account). But it misses your change on _cumulate (which is not related to the issue but is nice anyway because it resets the context). I also changed the tests differently (so that we can test on the same fiscalyear the period before the move are added, the period where they're added and afterwards).
@nicoe could you share the difference between both patches?
I also wrote a patch about this issue (but a different one)
I'm pretty sure there is a problem with
_cumulate and also one with period_ids being an empty list instead of None when no period is selected but dates are filled.
cumulate is not related. On the demo database there is no closed fiscalyear.
The problem is that the amounts of the current period are not included on the start balance. Let me put and example.
If you have a move on 09/04/2021 of 100€ you can observe the following behaviour:
Without start_date start balance is zero:
Using 10/04/2021 the start balance is zero.
On the second case, the start balance should be 100€ as the move is done before the date filter.
I do not understand the proposed change. For me the problem is not on GL but on
Here is a review348161002 that fixes the issue.
to_date must also be removed from the context when computing for non-closed years.
I notice when defining an start date on general ledger account the start balance is not computed correctly.
Can be reproduced on demo.tryton.org:
Fiscal year: 2020
Account: Main receivable
Start balance with no start date: 0€
Start balance with start date 1/10/2020: 0€ (should be 1924,45€)
Indeed neither general ledger line the balance with https://bugs.tryton.org/issue9791 works as expected when defining start date.
|2021-10-12 11:33:09||roundup-bot||set||messages: + msg70953|
nosy: + roundup-bot
status: testing -> resolved
|2021-09-21 15:24:35||reviewbot||set||messages: + msg70246|
|2021-09-07 11:57:58||reviewbot||set||messages: + msg69920|
|2021-09-02 15:09:28||reviewbot||set||messages: + msg69788|
|2021-07-06 14:01:30||nicoe||set||messages: + msg68728|
|2021-07-06 08:16:49||pokoli||set||messages: + msg68724|
|2021-07-06 08:16:22||pokoli||set||assignedto: pokoli -> nicoe|
|2021-07-05 23:45:10||ced||set||messages: + msg68721|
|2021-05-24 11:55:49||nicoe||set||messages: + msg67791|
Showing 10 items. Show all history (warning: this could be VERY long)