online balance info
Derek Atkins
warlord@MIT.EDU
25 Jun 2001 17:26:20 -0400
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 <nasa000@home.com> 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 <nasa000@home.com> 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 <nasa000@home.com> 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 -- linas@gnumatic.com -- http://www.gnumatic.com/
> > > > >
> > > > > _______________________________________________
> > > > > gnucash-devel mailing list
> > > > > gnucash-devel@lists.gnumatic.com
> > > > > 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
> > > > warlord@MIT.EDU 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
> > warlord@MIT.EDU PGP key available
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel@lists.gnumatic.com
> > 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
warlord@MIT.EDU PGP key available