$0 split transactions are not getting imported from QIF correctly.
Non-zero transactions get imported fine.
The problem is gnucash is flipping what is a withdrawal vs a deposit for $0
splits.
The following QIF file shows the incorrect import.
The signs on the Savings transfer are the same on both
A zero amount is neither a deposit nor a withdrawal. It is merely a
vehicle to hang a comment on. GnuCash wouldn't know the difference.
On Sun, Sep 27, 2020 at 1:43 PM B Wooster wrote:
> $0 split transactions are not getting imported from QIF correctly.
> Non-zero transactions get imported fin
If zero amounts are the issue, any chance of getting an option to treat it
as positive?
Maybe there should be an option to treat it as +0?
Or better still, if looking at other transactions can show that split
amounts are to be treated - such as Salary shows up in Total Withdrawal
column (of Checkin
On Sun, Sep 27, 2020 at 4:21 PM B Wooster wrote:
> If zero amounts are the issue, any chance of getting an option to treat it
> as positive?
> Maybe there should be an option to treat it as +0?
> Or better still, if looking at other transactions can show that split
> amounts are to be treated - s
Gnucash 4.2 was re.leased this morning, why don't you try the current
version - lots of fixes in the importers in version 4.1 I think it was
Cheers David H.
On Mon, 28 Sep 2020 at 06:24, B Wooster wrote:
> If zero amounts are the issue, any chance of getting an option to treat it
> as pos
Hello, BWooster:
I think I may see a terminology difference, which might be interfering
with you making your question clear in this forum.
On 2020-09-27 11:41, B Wooster wrote:
$0 split transactions are not getting imported from QIF correctly.
Non-zero transactions get imported fine.
In Gnu
Thanks everyone, I think once I clean up my example and terminology, I'll
file a bug.
Certainly the checking account is all fine as far as total balance is
concerned - but then importing further accounts messes up every account -
including checking.
That is the same even if I include both checking
Please file a bug, and include .qif and screenshots from Quicken to
illustrate the transaction.
On Sun, 27 Sep 2020 at 23:06, B Wooster wrote:
> Thanks everyone, I think once I clean up my example and terminology, I'll
> file a bug.
>
> Certainly the checking account is all fine as far as total
Very few of us veteran users have imported Quicken files with release 4.x
importer, but in the 'olden' days many of us found that due to the many
liberties that Quicken allowed, we needed to start test imports with tiny
chunks , see whether accounts were assigned correctly or not, matches
found, e
Found an existing bug report about this, from 2008, and recent comments
from Quicken users pointing out how this makes it impossible to move to
gnucash oh well.
I added my "me too" waiting on the bug (12+ years... wonder if there is
hope?!!) https://bugs.gnucash.org/show_bug.cgi?id=551459#c10
That is interesting. I had not seen that bug report. It goes back to
GnuCash Release 2.2.something. It seems like a real stretch to have a zero
value transaction in account 'C' to record a transfer between accounts 'A'
and 'B'. Quicken did and does allow some strange things I don't recall
havin
I don't use QIF files, so I have no direct stake in this question. But,
reading the discussion in bug 551459
(https://bugs.gnucash.org/show_bug.cgi?id=551459), it seems to me that
we have the following situation:
1. different bookkeeping applications (Quicken, Moneydance) use what is
ostensib
Confirmed that removing the special processing if statement based on sum of
totals fixes the import problem in gnucash for Quicken files.
https://bugs.gnucash.org/show_bug.cgi?id=551459#c16 has details, and
building locally for a one-time import operation fixed it for me.
Essentially, remove the ne
13 matches
Mail list logo
