For the accounts with party required, as we manage them as sub-account, we should display in the general ledger as children. It should be one row per party who has entries.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
I'm wondering if we should not add a check on the context (which can be marked as default) to allow the user to compute the value per party or to see the sum of the account when the value is unchecked.
> For me, this does not fulfill the requirement. We want to see the sub-account for each party with the debit/credit and balance.
Let me clarify: I agree with the requirement and with the pruposal. Just thought that may be a good addition to allow a check to enable or disable the "one row per party who has entries" like we do for party cumulate on general ledger lines.
On 2018-05-17 17:20, Sergi Almacellas Abellana wrote:
> > For me, this does not fulfill the requirement. We want to see the sub-account for each party with the debit/credit and balance.
>
> Let me clarify: I agree with the requirement and with the pruposal. Just thought that may be a good addition to allow a check to enable or disable the "one row per party who has entries" like we do for party cumulate on general ledger lines.
For me, they should be children of of the account so they can be
expanded or not.
It is unfortunate that this has stalled so long...
First, I'd like to recommend this be called 'auxiliary' reporting (Ledger and Trial Balance)
as that appears to be the generally accepted terminology for the subject.
This out of the way, the scope is easier as the task is the same as for general ledger but looped for all parties having movements in the period or at least an initial balance.
As to the auxiliary balance, it is somewhat the opposite of the aged balance.
That is, for the former, group by account then party .. the latter is grouped by party then by account
As with general ledger, it should be possible to filter based upon inital/end balance and mouvements (debit/credit) as well as which accounts and/or parties.
Here is review314091002.
I based on an AccountParty model which uses the first move line between account and party as unique id. I did not find useful to make it visible to the user for now.
I did not convert the GL into a tree because:
- it can not be searched
- the composition of the unique ID may reach limits if the company has a lot of parties
so I choose to use a tree open action like for the lines.
I also added a tree open action from the GL account party to open the corresponding lines with the cumulate per party.
Cédric Krieradded 1 deleted label and removed 1 deleted label