We’re in desperate need to establish a balance report by party and account for our auditor today.
I try to jig something with aged balance, but it seems to refuse to print by account if the party has moves in multiple accounts (which is frequent for us having need for an account by tax rate for VAT auditing purposes)
Trying from the GL/Balance report, no deal either… though it is strange that if I drill down into an account there is a box to click in order to cumulate by party… seems to no useful effect at the moment.
Has anybody got this to work or can suggest a work-around?
Another issue I’ve come across is that, typically, only the move lines created by an invoice have a maturity date.
Diverse movements such as by a bank statement do not set the maturity date
(which is somewhat logical, not being an invoice).
But the strange effect with these diverse movements is that they always show up in the third term when not reconciled, ignoring the date of the movement (which may be quite recent).
(see here: modules/account: 005dacf0b269 account.py)
Perhaps this case should be treated as if maturity date == effective date of the move line.
I do not understand why you need to set a maturity date on a bank statement move.
AIFAU the maturity date is used to determine when a receivable/payable line will be efective. A bank statement move is efective on the day that is done, so it does not make sense to set it’s efective date. Furthermore the statement move is used to compensate the pending amount of a receivable/payable.
That is why I said that maturity date is only for the move lines directly linked to an invoice.
But aged balance puts lines without maturity date at the last term.
For example, we have in december some bank charges debited that will be invoiced the first week of january.
The aged balance for 31/12/19 using the default terms of 30/60/90 days will show these amounts in the 90 day term… which is theoretically september!
(actually, that uncovers perhaps another bug because the comparison date computed seems to be 2/10/19 and not 30/9/19 … even choosing ‘months’ with terms 1/2/3 doesn’t change that)
These should show up in december, so the algorithm should probably check if there is no maturity date and use the effective move date for the comparison.
One could also argue that an invoice without maturity date could be considered immediately due at the date of invoice guaranteeing a more reasonable semantic.