How to print balance by party by account?

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?

IIUC what you are searching for is what is should be implemented on Issue 7438: General ledger for party required - Tryton issue tracker

If you are in a hurry you can use a sql query to compute the needed data, as the information is already on the database.

It’s clear party balance and GL reports are necessary (Issue 7438: General ledger for party required - Tryton issue tracker), but there are also enhancements needed to aged balance.

For example, by definition, the balance should be detailed by account but there should probably be a [minimal] means to filter accounts as well.

A use case we have for clients (under the French plan) accounts receivables that have been assigned (https://www.investopedia.com/terms/a/assignment-of-accounts-receivable.asp) are typically in distinct accounts (ex: 4116x). We prefer these be filtered out.

There are probably other cases, so maybe aged balance should have a configuration means to select which accounts be used, or not.

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.