dealing with invoices and QIF imports
Leigh Morresi
dgtlmoon at gmail.com
Wed May 28 19:13:50 EDT 2008
hi all
thanks for your feedback on this, so it sounds like charles is going to
take a closer look at the QIF importer account type mapping/checking?
Mapping my income payments to Import:QIF sounds good, in essense i guess
this means those QIF items just sit in a holding-queue and i delete them
once ive marked the corresponding invoice as payed, sounds good to me
i've been using this script of mine
http://dgtlmoon.com/qif_gnucash_python_preprocessor
to preprocess the QIF entries with some regex and put a corresponding
"L" cateory to them
cheers
leigh
On Wed, 2008-05-28 at 12:37 -0700, Charles Day wrote:
> On Wed, May 28, 2008 at 11:26 AM, Derek Atkins <warlord at mit.edu>
> wrote:
> Quoting Charles Day <cedayiv at gmail.com>:
>
>
> The QIF is. You should know that.
> QIF Accounts are Asset/Liabilities.
> Everything else is Income/Expense. So
> yes, there is a default account
> type based on the actual QIF
> transaction information. Whether or
> not
> this is right or wrong I leave for
> another day, but the way the QIF
> importer is currently structured makes
> it very hard to just remove
> this....
>
>
> I think the rules are looser than that for QIF
> payee/memo mappings, but
> maybe his QIF doesn't provide an payee or memo
> so a category mapping is
> getting used. It's true that if a category
> mapping is being used and a new
> GnuCash account is being created (checkmark
> appears in the mapping page),
> then the created account type will be Income
> or Expense. But regardless, if
> the user specifies (via the GUI) an existing
> GnuCash account to use for a
> category mapping, then in my opinion the
> importer ought to honor that choice
> regardless of account type (the commodity
> still must match). If it's not
> doing that, then that seems like a bug to me,
> or at least overrestrictive
> babysitting. What's your opinion?
>
>
> I just tried reproducing this, and in fact the QIF
> importer *does* allow a
> category to be mapped to an existing GnuCash account
> with an Asset account
> type. So that's not the problem. -Charles
>
>
> I believe it's a raw Payee/Memo mapping that is purely
> Income/Expense.
> So if the transaction has no L line, it's assumed to be
> Income/Expense.
>
>
>
> I can now reproduce this problem, but it's got nothing to do with the
> Asset account type. You can map to that type of account, no sweat. I
> believe the problem is that account types A/Receivable and A/Payable
> are completely unknown to the QIF importer. I could just add specific
> support for these two types, if you think that's good enough. Should
> be easy. But in general it really seems to me that if a user picks or
> approves use of an existing GnuCash account then the importer should
> use that account, regardless of account type, as long as the commodity
> matches (since we are still restricted to single-currency imports).
> That might be a bigger change though. Your thoughts?
>
>
> -derek
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord at MIT.EDU PGP key available
>
>
>
--
Leigh Morresi
+61401883741
dgtlmoon at gmail.com
http://dgtlmoon.com
skype: dgtlmoon
More information about the gnucash-user
mailing list