They were using complicated algorithm to get the split account. Also
change leader output from account/null to account/#f.
It is simpler to return #f if there is no 'leader'
changes:
- hr.po:3638 => added accelerator mark
- hr.po:7788 => added accelerator mark
- hr.po:10957 => removed accelerator mark
- hr.po:16166 => no change, ignored
- some minor other changes in wording
These functions were unnecessarily complex and used to build html
report. Tests are not mandatory here... All tests still pass which
means the html-documents are being built up correctly.
this will modify a test which was calibrated to record purchase price
only. fix transaction creation to add prices for both purchase and
sales, and also fix test which was assuming no sale price was bring
recorded.
This is the general case for any transaction creation. Rewrite other
transaction creation routines to use it. All tests still work
unchanged, which confirms this function works well.
This will allow tests to create multisplit transactions, of an
arbitrary number of splits. If the list-of-split's values are not
balanced (i.e. total 0), the engine will create an Imbalance-CUR
split.
The motivation is to allow creation of complex multisplit
multicommodity transactions eg USD50 + GBP20 (USD25) = EUR66 (USD75)
as well as their prices GBP/USD = 25/20 and EUR/USD = 75/66.
* USD -50
* USD -25 = GBP -20
* USD +75 = EUR +66
This will be useful in creating tests for stock-based reports, whereby
stock sales need splits in STOCK/ASSET/INCOME accounts.
Previous logic would cycle through accounts' sub-accounts, and each
sub-account would be queried for inclusion in accounts; if not
present, the accounts would be appended by all sub-accounts.
Logic would dictate that only the missing sub-account should be added
to the accounts list.
No functional change is expected; previous behaviour would generate an
unnecessarily long resulting accounts list (includes sub-accounts as
many times as there are sub-accounts).
1. remove split-seen? helper function. use a simple list.
2. they were maintaining 2 lists for in, 2 lists for out. simplify to
1 list each.
3. convert single-use function to named let
4. remove transaction date filter - transactions were already
date-filtered by the query prior.
5. use simple lists instead of split/account hash tables. use the
incredible versatile srfi-1 functions.
6. s-report-value can be defined earlier
7. clean up whitespace so that line maxwidth is 80
8. tests already exist in test-cash-flow.scm
The (cashflow-barchart-calc-money-in-out) function was copied verbatim
from cash-flow.scm (apart from the returned list being shorter). reuse
function from cash-flow.scm.
Test already exists in test-cashflow-barchart.scm
old code was confusing; returns non-#f if either of following is true:
- elts is null list
- elts is 1-element list
and report-commodity is a member of this 1-element list
change to much more intelligible code
allows it to compare numbers with +/-inf.0 -- 10E9 is an arbitrary
number to compare numbers.
(< N +inf.0) is guaranteed to be #t for all numbers N whereby N is not
also +inf.0.
(Release Note - developer section)
Modification to gnc:account-get-balances-at-dates.
formerly it would accept an optional #:ignore-closing? boolean to skip
closing transactions.
it would be more general to accept a #:split->amount function whose
default is xaccSplitGetAmount. calling (split->amount split) should
return amount from the split. if the function returns #f, it
effectively skips the split. this will allow a more general
account-balance list accumulator, allowing novel balance strategies
e.g. split->amount may test split void status and return the split
xaccSplitVoidFormerAmount, test description/memo and return an amount
depending on description contents, or test the split and return 1 or 0
which will return a tally of splits.
the direct equivalence for the previous #:ignore-closing? keyword
argument is #:split->amount (lambda (s) (and (not (xaccTransGetIsClosingTxn
(xaccSplitGetParent s))) (xaccSplitGetAmount s)))
NOTE: the modifications to category-barchart.scm and net-charts.scm
will use the #:split->amount kwarg as well.
This function is extensively tested in the commit
53cab269f4
