logic error to calculate last period date pair for col-header.
pnl report-dates are stored as a list of time64. consider a regular
profit&loss for "quarterly income & expense amounts for last
calendar year". dates are 1-jan to 31-dec. the report-dates are
'(1-jan 1-apr 1-jul 1-oct 31-dec). the inc/exp accounts balances are
queried for the above dates, and the delta change (sans closing
entries) constitutes the desired answer.
the col-header needs to report "1-jan to 31-mar", which it does by
retrieving 2 consecutive dates in the list (1-jan 1-apr), then
decrease second date by 1 day to obtain "1-jan to 31-mar" . however
this fails for the last period which would return '1-oct to 30-dec'.
this commit changes display for last period to return last report-date
so that the header is fixed to '1-oct to 31-dec'.
this is cosmetic for header dates only, calculations of periodic
income/expense amounts were never affected and included entries on the
last report-date (e.g. 31-dec as above).
minor efficiency change. append-reverse is faster than append, and
storing the appended lists is rather convenient for this
report which uses them a lot.
Remove the "minus 1" to amount-depth for some accounts with children
and display-amount is 'immediate-bal. This means amounts are now
strictly(*) indented according to account depth instead of a weird
formula if account-has-children and immediate-bal.
(*) when subtotal-mode isn't "canonically tabbed"
This reverts commit 35ed4cf2, restoring indenting for account
summary. The next commit will fix the indented amounts to land under
the 'Balance' header.
This fixes: Bug 797332 - Account Summary Report balance lacks
indentation
This required some tweaks in the core csv import code
- first don't unset other deposit/withdrawal columns when selecting a second one
- amounts have to be summed for all deposit/withdrawal colums
I have added a new member function 'add' in addition to 'set' and 'reset'
That function will only work for deposit or withdrawal columns
Before we used a colon separated prefix, but thas was error prone.
The downside: Our translators have to review serveral messages.
Tip: Use a tool like KDiff3 for merging.
Q_('ctxt|msg') expands to g_dpgettext(NULL, 'ctxt|msg',0) and should be
interpreted as a message with message context. According to
https://www.gnu.org/software/gettext/manual/gettext.html#Language-specific-options
this glib extension is supported using the 'g' suffix to the keyword spec.
This was missing in our xgettext invocation.
tbl-width is not necessarily an even number; tbl-width being odd would
result in a half-fraction when calculating number of
empty-cells. convert to the appropriate integer.
this is the proper fix for the bug fixed by d865b149.
assoc-ref (or better, assq-ref because we're comparing symbols) is
used to lookup from the 'car's of a list of pairs, and return the
found pair's 'cdr'. the previous use of 2-element lists demonstrate a
lack of understanding how to encode the list of pairs. rewrite using
proper pairs rather than 2-element lists, which means the assq-ref
does not need a subsequent 'car' to retrieve the desired symbol.
* this function has a typo in name
* all uses of accounts-get-all-subaccounts were followed by appending
the result to the original accounts list. we have already rewritten to
use the better function in previous commit. this is now obsolete.
* inline its last use, omit sorting. list is sorted anyway afterwards.
All uses of gnc:acccounts-get-all-subaccounts were immediately
followed by appending the result to the original accounts list. Use
gnc:accounts-and-all-descendants instead which is more efficient.