dealing with invoices and QIF imports

[Charles Day]

On Wed, May 28, 2008 at 10:55 AM, Charles Day <cedayiv at gmail.com> wrote:

> On Wed, May 28, 2008 at 9:46 AM, Derek Atkins <warlord at mit.edu> wrote:
>
>> Quoting Charles Day <cedayiv at gmail.com>:
>>
>>  Well no one is telling the importer that it's an income account. It must
>>> be
>>> defaulting, and it shouldn't do that if Assets:A/R already exists. An
>>> Asset
>>> account type should be considered compatible.
>>>
>>
>> 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


> -Charles
>
> name perhaps slightly different, like Assets:Accounts Receivable? That
>>> could
>>> explain the behavior.
>>>
>> Does he really have an existing GnuCash account named Assets:A/R, or is
>> the
>>
>> This question is irrelevant.  He's telling the importer to create an
>> account Foo:Bar.  If Foo:Bar doesn't exist then it will be created
>> with the correct type (in this case, Income).  If Foo exists and is
>> a compatible type then it will just create Bar.  However if Foo exists
>> and is NOT compatible then it will create Foo2 of the correct type.
>>
>> I'm not exactly sure why it creates Bar2 as well, but it does in this
>> latter case.
>>
>> In HIS case he asked for Assets:<Something>...  Assets already exists
>> but is incompatible with Income, so it creates Assets2.
>>
>> Note that compatibility is two-fold..  There is account-type compatibility
>> AND currency/commodity compatibility.  I believe that either case will
>> cause a new tree to get created.
>>
>>  -Charles
>>>
>>
>> -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
>>
>>
>