The GnuCash Csv Importer can deal with both cases,
but there has been user feedback that the format
with only the first line displaying transaction
details is confusing and/or not readily usable
in external tools.
Update csv transaction export format to include split values.
In the csv importer the 'GnuCash Export Format' option will
now include values. For compatibility with filex exported
from older gnucash versions the previous preset is still
available under the name 'GnuCash Export Format (4.x and older)'.
Transactions with capital gains processing can have
splits in transaction currency with a zero amount
and a non-zero value. To properly import those,
prefer the value column even if transaction
currency equals account commodity.
Previous (wrong) assumption was that in case
of a same-currency split, the amount would
always be the value.
Instead of a gnc:split->owner, use gnc:make-split->owner instead which
generates a split->owner function with its own hashtable. This
function (and its hash table) will be garbage collected in due course,
triggering the gncOwnerFreeing of all owners.
This is a better approach than gnc:split->owner which maintains a
single hash table. It could be buggy: a report calls gnc:split->owner
to query a split, fails to reset its hashtable via #f; the split's
owner is assigned or modified, and the next call to gnc:split->owner
will return the incorrect cached owner.
This commit introduces new column types 'Value' and 'Value (Negated)'
which can be used to indicate what the value of a split's amount
is in the transaction currency. These will only be used if the
transaction currency is different from the account commodity
of the given split. Otherwise the amount will simply be
used as value.
With the added multi-currency support it would be possible
to create imbalanced splits. A new check is added to detect
this beforehand and prevent users from continuing.
This required much of the verification logic to be revisited.
Before it was tracked in a separate column in the parse table.
However future checks on multi-currency inconsistencies
will be easier to implement if it's a member in each PreSplit.
- catch multiple exception types in one block
the exception handling code was the same anyway
- stop rethrowing the exception. The calling code
doesn't need this and just ignores it.
Remainder of the code ensures a GncPreSplit account is always
set to either the base account value or a value of an account
column. It's useless to try once more to set a base account
right before creating the preliminary transactions.
Use maps and vectors to move error messages around.
Only merge them into a string right before they
need to be passed to Gtk for presentation to the user.
Define them as a separate group and add a function
to test for this trait. Use that function
consistently instead of testing individual values
everywhere.
..., results in an invalid transaction that is uneditable, and a corrupted price database
This commit will change the transaction currency
to the from or base account's parent account currency if
the from or base account is not denominated in a currency.
This allows to import stock transactions directly into the stock
account.
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.
