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.
This change was inspired by mildred's #PR1247 and uses the new
GncReportCombo to allow selection of 'Saved Invoice reports' when the
invoice print button is used or when printing multiple invoices.
This change presents a dialog with the default for the report combo set
to the properties setting. This dialog has a timeout which is
adjustable under properties and will stop if a key is pressed or combo
popped so that a different report template can be selected and used.
There is also an 'OK' button that stops the time out and prints and a
'Cancel' button which cancels the print.
This commit changes the preference in Business->'Report for Printing'
to be saved as a book property and allow the selection of any Invoice
Report to be used as the default.
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.
