I agree.
Since I haven't played with the QIF importer lately, which of these
problems with QIF doesn't the present QIF importer address? If it
address the problems, why mess with it? If it doesn't I guess it still
requires some work.
Regardless of how well/not well the QIF importer works, it should have
no impact on how a OFX importer should work. They are significantly
different -- enough so, that a seperate importer seems warranted.
Especially, since this importer would have to manage both versions 1.6
and 2.0 of OFX (and they are different).
Nasa
On 25 Jun 2001 17:26:20 -0400, Derek Atkins wrote:
> The problem is that when clearing a transaction you have an idea of
> what transactions are already there. If you have multiple no-info
> transactions, there is other information to match them to existing
> transactions already entered without assuming that both no-info
> transactions (which look the same) transact to the same account.
>
> For example, you have two no-info transactions in the QIF file, but on
> the same day as transaction #1 you have a transaction for the exact
> same amount already entered into Gnucash, earlier, by hand. Similarly
> you have pre-entered transaction that matches transaction #2 based on
> amount and date.
>
> OTOH, trying to use that same no-info transaction to ENTER a
> transaction is much more difficult. At that point you have to know
> that the peer account is. And you have nothing which which to make
> assumptions. You cannot assume that similarly-marked no-name
> transactions belong in the same account. And you can't ask the user
> to choose a default, because it might be wrong.
>
> Let me give you a real-world example from my personal experience. I
> have two mortgages from the same company, and I use NetBank's online
> bill-pay service to pay both bills every month. My monthly statement
> has two entries:
>
> 7/1/01 MORTGAGE - ONLINE PAYMENT $1000
> 7/1/01 MORTGAGE - ONLINE PAYMENT $300
>
> Obviously I want to keep track of these mortgages separately (they ARE
> different accounts after all). If I pre-enter these transactions into
> GC, then sure, you can easily match the former transaction with my
> first mortgage, and the latter transaction with my second mortgage.
> However, if you are using a QIF file with these transactions to enter
> information into Gnucash for the first time, how is Gnucash supposed
> to know that these two transactions belong in two different accounts?
>
> The answer: it can't. It needs some amount of user intervention, and
> it cannot effectively automate the process without (IMHO)
> turing-complete tests or heuristics.
>
> That's the problem with QIF entry without enough information.
>
> -derek
>
> Nathan "A." Smith <[EMAIL PROTECTED]> writes:
>
> > I was assuming clearing via online systems -- however, the format of the
> > file being received by gnucash should be the same either way. Thus
> > allowing the user the choice.
> >
> > Nasa
> >
> > On 25 Jun 2001 16:59:26 -0400, Derek Atkins wrote:
> > > Are you assuming clearing via online systems or incorporation via
> > > online systems? I want to be able to use download QIF/OFX in order
> > > to load transactions into Gnucash, and then manually clear them at
> > > the end of the month with the paper statement.
> > >
> > > -derek
> > >
> > > Nathan "A." Smith <[EMAIL PROTECTED]> writes:
> > >
> > > > Ok, I used nbmym terms -- categories are income/expense accounts. The
> > > > users would have to assign an income/expense account for the first time
> > > > a payment/debit goes through, then use that for then on out (pretty much
> > > > like it does now). Nothing from the bank would be needed (or really
> > > > wanted - unless we want to export the income/expense accounts back to
> > > > the bank as categories).
> > > >
> > > > As you noted, not all entries that look the same will have the same
> > > > income/expense account - thus an "cleared" screen would be necessary to
> > > > allow the user the opportunity to correct any improperly placed
> > > > transactions. We would need this anyways to make the user review what
> > > > has been cleared - just in case something clears that he/she may dispute
> > > > (has never happened to me).
> > > >
> > > > Nasa
> > > >
> > > > On 25 Jun 2001 15:46:15 -0400, Derek Atkins wrote:
> > > > > What category? There is not enough information to determine which
> > > > > category to use. And not all entries that look the same are
> > > > > really meant to go to the same 'category'.
> > > > >
> > > > > -derek
> > > > >
> > > > > Nathan "A." Smith <[EMAIL PROTECTED]> writes:
> > > > >
> > > > > > Couldn't we just credit the category? Since that is already saved -- a
> > > > > > simple solution already exists.
> > > > > >
> > > > > > Nasa
> > > > > >
> > > > > >
> > > > > > On 25 Jun 2001 12:15:59 -0500, Linas Vepstas wrote:
> > > > > > > On Thu, Jun 21, 2001 at 11:29:06PM -0400, John Klar was heard to remark:
> > > > > > > > Linas wrote: (2nd point)
> > > > > > > > > OFX also seems to loose inter-account transfer info, and has
> > > > > > > > > mal-formed, badly capitalized and cryptic info in 'payee' and
> > > > > > > > > 'memo' fields, at least based on samples I've looked at.
> > > > > > > >
> > > > > > > > v1.02 doesn't seem to have a Payee :( and memo looks like whatever
>string
> > > > > > > > the payee emitted to your FI
> > > > > > > >
> > > > > > > > > Its a bit cleaner than QIF to parse (e.g. it should indicate the
> > > > > > > > > currency of the transaction). But its not a double-entry system;
> > > > > > > > > all you know is that money came, or went, but you are never clear
> > > > > > > > > on to whom, or how or why.
> > > > > > > >
> > > > > > > > I'm not seeing this.
> > > > > > > >
> > > > > > > > <FITID> should be "unique", but I'm detecting some rollover compared
> > > > > > > > to a statement pulled from last year.
> > > > > > > > <TRNTYPE> gives me "how" (CHECK,CREDIT,DEBIT,CASH,XFER)
> > > > > > > > C&D are electronic
> > > > > > > > <NAME> gives me "why" (SH DRAFT,DEPOSIT,PURCHASE,WITHDRAW,
> > > > > > > > TRANSFER TO mumble)
> > > > > > > > <CHECKNUM> correlates the check
> > > > > > > > <MEMO> includes additional detail. In the case of 102, this
> > > > > > > > is where the PAYEE info is.
> > > > > > >
> > > > > > > Some banks are better than others. The following from the
> > > > > > > gnucash samples driectory, a canadian bank:
> > > > > > >
> > > > > > >
><STMTTRN><TRNTYPE>DEBIT<DTPOSTED>20010102225126.000[-5:EST]<TRNAMT>80.00<FITID>2001010201648450<NAME>**PAYMENT
> THANK YOU - PAIEMENT</STMTTRN>
> > > > > > >
> > > > > > > whazzat? where'd it come from? why? what memo?
> > > > > > >
> > > > > > > (having the unique id in fitid is indeed batter than what QIF supports
> > > > > > > and makes it easy to detect multiple instances of teh same trasnaction).
> > > > > > >
> > > > > > > the problem is that gnucash can indeed debit one account by 80,
> > > > > > > but what account should be credited by a matching 80 ? We'll
> > > > > > > need to develop some heuristics, or possibly take some ugly default
> > > > > > > values. The 'ideal' interface would have some wizard pop up and ask
> > > > > > > 'hey next time we see one of these 'PAYMENT THANKYOU' things, what
> > > > > > > account should we put it in?', and remember the user's answer.
> > > > > > >
> > > > > > >
> > > > > > > --linas
> > > > > > >
> > > > > > > --
> > > > > > > Linas Vepstas -- [EMAIL PROTECTED] -- http://www.gnumatic.com/
> > > > > >
> > > > > > _______________________________________________
> > > > > > gnucash-devel mailing list
> > > > > > [EMAIL PROTECTED]
> > > > > > http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
> > > > >
> > > > > --
> > > > > 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
> > > > > [EMAIL PROTECTED] PGP key available
> > > >
> > >
> > > --
> > > 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
> > > [EMAIL PROTECTED] PGP key available
> > > _______________________________________________
> > > gnucash-devel mailing list
> > > [EMAIL PROTECTED]
> > > http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
> >
>
> --
> 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
> [EMAIL PROTECTED] PGP key available
> _______________________________________________
> gnucash-devel mailing list
> [EMAIL PROTECTED]
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
