queries xaccSplitGetNoclosingBalance (which is a pointer dereference)
instead of a more complex conditional-based snippet for split->amount,
should be faster.
The category-barchart change will choose the appropriate split->elt
function according to the account type. This is more efficient than
the old split->amount function which includes a conditional.
Note we don't need to test for account being income/expense:
asset/liability accounts do not have Closing transactions. Therefore
we can use xaccSplitGetNoclosingBalance for splits from any account
type.
if acc has no splits before report-date, the nosplit->elt will specify
the default value to be inserted in the result list.
e.g. consider:
dates are (date1 date2 date3 date4 date5)
account has splits starting after date2:
(gnc:account-accumulate-at-dates account dates
#:split->elt (const 'yea) #:nosplit->elt 'nay)
results in '(nay nay yea yea yea)
previously the payment-amount deduction loop used the
payment-split-list to obtain the invoice-posting-split's amount. this
would occasionally fail and would return the invoice-payment-split
amount, obtaining the wrong sign.
modify to retrieve the invoice total via gncInvoice API.
therefore payment-amount, minus gncInvoiceGetTotal(inv) amounts,
results in the overpayment amount.
previous code was very inefficient: if an account had N old splits and
balance-sheet reported on M recent dates, it would scan splitlist
multiple times: (1) to retrieve splits, (2) filter until
column-date, (3) find the last one. i.e. total O(N * M * 3).
this algorithm pre-generates the account's report-date splits by
scanning each account only once, creating M splits which are queried
by get-cell-anchor-fn via list-ref. i.e. O(N)
it is immedialtely converted to a vector because we want O(1)
access. from get-cell-anchor-fn
a future optimisation may scan the accounts' splitlists once per
report run, acquiring all required data (i.e. last period split,
split->balance, closing entries) in 1 pass, to generate a column-data
record.
this is a generalised form from gnc:account-get-balances-at-dates to
accumulate a list from report dates.
this function will scan through account splitlist, processing each
split via split->elt, accumulating results at date boundaries into the
results list. it uses ice-9 match for conciseness.
in: acc - account
dates - a list of time64
split->elt - an unary lambda. the result of calling (split->elt split)
will be accumulated onto the resulting list. by
default it returns the last split-balance before
date boundary, similar to gnc:account-get-balances-at-dates
out: (list elt0 elt1 ...), each entry is the result of split->elt
because:
* list? is O(N), because it needs to test for an improper
list. improper lists are lists whose last pair's cdr cell is not
'(). null? and pair? are both O(1).
* avoids reverse which is also O(N): guile has unlimited stack
therefore we can do non-tail-call loop first to pass as parameter to
the tail-call loop. this removes the need for prepend-and-reverse.
There was error in the trace file for GncPopupEntry of the format...
Object class GncPopupEntry doesn't implement property 'editing-canceled'
from interface 'GtkCellEditable' so added one.
If you list accounts with the "find accounts" dialogue, then delete an
account it has found (e.g. jump & delete), then return to the dialogue,
the dialogue doesn't refresh when the window regains the focus, so you
can accidentally jump to an account you have recently deleted which
will lock up Gnucash.
Fix this by listening to account events and then refresh the list.
Previously owner-report "Payment" links to APAR payment split. Best
link to the transfer account split thereby showing original
payment. Also creates a link for each transfer split although
theoretically there should only be one. e.g. if 2 non-APAR split in
payment transaction, it'll show "Payment Payment" in the "Type"
column.
For payments spanning multiple invoices, previously it would render
partial payment amount. But this info duplicates the invoice
details.
By rendering the full payment amount, it will ease tracking with other
invoices paid with same payment.
If the payment transaction originates from a different currency, the
invoice->payments table will render it in the originating currency.
... instead of payment splits to calculate payment amount, because
payment splits may be in a different currency. using APAR split total
minus invoice amounts is guaranteed to produce correct overpayment
amount in APAR currency.
Previous algorithm had assumed all payments would match attached
invoices. This updated algorithm does not assume.
Invoice: add into appropriate bucket and save invoice+splits into
list.
Payment: scan payments from invoice+splits to find appropriate
invoice, and deduct from the transfer account. The remainder is an
pre/overpayment and added into prepayment bucket.
It will always assume that the splitlist being processed will *all*
belong to one owner.
This commit will hide the APAR account anchor if there's only one
found. So, for majority of users with single AP/AR accounts, the aging
report will be very similar to old one. For users with multi APAR
accounts, each one will be shown with header (and anchor) and
indenting to highlight grouping.
Instead of rendering html-table all incrementally, build
account-and-owners and owners-and-aging lists first, leaving building
the html-table for the end. tofree is a list of owners which are
generated and must be freed after use.
Previous used 'total-number-cell' thereby unnecessarily right-aligning
total label cells.
Also xaccTransGetAccountAmount is more appropriate than
xaccTransGetAccountValue because the latter may retrieve numbers in a
currency other than APAR currency.
Previously each owner-table row's value would access split's
amount. But this fails for payments spanning multiple invoices,
because these (with a single split to bank) will have a split for each
invoice. Hence split->amount gets only 1 invoice payment amount.
This change modifies to obtain the sum total of split->amounts in the
APAR account thus handles multi-invoice payments correctly.
Pretty much the only place gnucash_sheet_get_block could crash is in
g_table_index, either because the GTable's GArray has been deleted or
the index is out of range. Add g_return_val_if_false tests for each
possibility.
For some reason on Ubuntu 18.04 that uses Gtk3.22.30 and maybe others
we have to set the scroll window content min height after the dialog
has been shown to get the correct scroll window height
The warning icon is used to show blocking and non-blocking warnings in
a payment. Increase visibility by showing the warning as a gtklabel
instead of a tooltip.
Completing a payment for a customer without associating with an open
invoice is allowable and is used for prepayments.
Previously this was done silently.
This commit will enable a warning to inform that the payment does not
have an invoice/bill document attached. This warning does not block
the payment however.
Previous trans->invoice strategy was flawed. A payment for multiple
invoices would always return the first invoice found.
A safer approach is to find split->invoice -- this enables a split
from a payment for multiple invoices to retrieve the corresponding
invoice.
The disadvantage is that we cannot jump from bank split to invoice
split anymore; this is acceptable because a payment which covers
multiple invoices would lead to ambiguity and would require UI to
select the invoice for jump.
