There is no added value in storing the book and account together
The book is easily retrieved from the account (as was
illustrated in the gnc_account_imap_new function).
I looked through the commit history to understand why this struct
was originally created and a long time ago it also had
a reference to a kvp frame.
Open transactions in the context of the importer represent
freshly downloaded transactions. They can't possibly be
valid matches. Filtering them out early is a minor performance
optimization. For large imports it avoids having to traverse
a long list of splits multiple times.
Multiple reasons:
- they only have meaning in bank or cash contexts, but the importer is meant
to be more generic.
- 'Withdrawal' is misleading in that the code behind it caters very
generically for cases where values should be negated before being
used. A 'Withdrawal' is only a single use case of this behaviour.
New names are 'Amount' (iso 'Deposit')
and 'Amount (Negated)' (iso 'Withdrawal')
This requires GncPreTrans objects to be aware of the multi_split
preference to be able to estimate whether empty date or
description fields should be flagged as error or not.
Revisit the fix. It still made assumptions about the way
payment transactions were created. It can now handle
payment transaction either in the payment account
currency or in the post account currency.
- Show proper amount in dialog when applying or editing an existing transaction as payment
- Be more careful not to waste the existing payment split
- If the user changed the payment amount while starting from an existing transaction
unreconcile the changed payment split
- Avoid needlessly changing transaction currency (only do so if the user chose
a new transfer account and the old currency is neither the new transfer account's
currency nor the post account's currency)
We can't handle the case where a transaction has splits in more than one
APAR account. Instead of only warning that some of them will be lost
refuse to continue and leave it to the user to fix the transaction first.
When the individual CSV separator buttons were being updated, the
associated call could be triggered several times. To stop this, block
the call back for the individual buttons when they are updated and call
it at the end.
gnc_commodity_compare is used for sorting and so needs to have a less-than
return value. The only place it's used presents nothing to the UI; a GncGUID
ordering is fast and stable.
GnuCash allows only one commodity per book for any namespace/mnemonic pair, so
the exhaustive string comparisons are superflous. While the current engine
design allows only one instance of any object, meaning that a pointer comparison
is sufficient to determine equality, that may not be true in the future, but the
GncGUID is guaranteed to sufficiently identify a single commodity. Note that
gnc_commodity_equiv is used to enforce that single-commodity rule and so cannot
use GncGUID comparison.
