The changes from
8ed40078b0
and
78c8e8f3af
caused the importers to reset everything in the preview page whenever opening this
page, including when navigating back from a future page. This can be very frustrating
if many settings were adjusted but one went back just to tweak a single one.
With these changes the importer will only be reset whenever the user selects a
different file in the file chooser. So even navigating back to the file chooser,
but not changing files will keep the import state.
With the improved support for multi-currency imports, it
can happen an incomplete transaction needs an exchange
rate (or balancing split amount) before the transaction
can be imported. This commit adds a context menu entry
to set exchange rates on such transactions.
The menu is only enabled for unbalanced transactions
for a destination account has been set.
This is really a variation of bug 796955, except that in this case
even less data was provided in the csv file, so we needed
extra code to defer second split generation to the generic import
matcher.
The missing details can be either transfer account,
transfer amount and/or price.
The generic import matcher has more options to find this
information: the transfer account can be guessed from
import maps or manually selected by the user.
Only when that one is known, we can consider transfer
amount. In a single currency situation, this is easy.
In the multi-currency case we currently need either
a price or a transfer amount from the csv import data.
This second commit implements the suggestion from
that bug to add a 'Transfer Amount' column type to
the importer to avoid rounding errors that could
happen with exchange rates.
Behaviour is as follows:
If
single line provides a price
And
at some point in the import process we get into a
situation where the base account and transfer
account have a different commodity
Then
transfer_acct amount = base_acct amount * price
If on the other hand base_acct and transfer_acct turn
out to have the same commodity, price is ignored.
Partly fixes bug 798550 (https://bugs.gnucash.org/show_bug.cgi?id=798550)
Guile's * form when applied to rationals doesn't reduce and since
guile uses gmp for unlimited precision arithmetic produces numbers
that can't be passed back to C functions because they're too big for
any normal C integer types.
- Remove unused member variables from AccountPickerDialog struct
- Rename boolean function parameter to better describe what it represents
- Simplify a few constructs and condidionals
- remove unused constructor
Kept separate from actual logic changes
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.
