sql & gnucash

Derek Atkins warlord@MIT.EDU
26 Jun 2001 14:12:21 -0400


linas@linas.org (Linas Vepstas) writes:

> One posibility is OTP -- open trading protocol.  This was issued
> by a small company some 3 years back.  Don't know if its dead or allive.
> It seemed to be designed specifically for communicating the transfer of 
> 'stuff' from one vendor to another, and resumably, money counts as
> 'stuff'.   Haven't reviewed it in a long time.

There is the Internet Open Trading Protocol working group in the IETF
(www.ietf.org/html.charters/trade-charter.html) which may be what you
mean, or may have taken this up.

> All that gnucash really wants is 'from' and 'to' accounts that are 
> somehow uniquely identified (therby making the translation tables
> maintainable).  The lack of these unique identifiers hurts.

Well, it wants a bit more than that, but that would be sufficient,
IMHO.  For example, what happens if you are trading between two
commodity accounts (stock/mutual fund/etc)?  You know the
cost-per-share of one account, and you know the total value of the
transaction.  However you dont know the cost-per-share in the second
account.  So, how do you enter this into the gnucash database?
Currently, gnucash assumes a cost-per-share of $1, which is obviously
wrong in most cases.

> But in another sense, it *is* a hard problem:  Say vendor A transfers
> money from account A to vendor B's account B, and does so monthly.
> However, vendor B may want to account for this in a more complex
> fashion: 50% of that payment is widgets, 35% is services and 15% 
> is tax.  Automating/translating that is 'hard'.  Worse, the percentage
> splits may vary month to month...

This is a very similar (and related) problem to what I just stated.
Perhaps one way to do this would be to provide half-a-transaction?  If
you could mark a transaction as only half-completed, then you wouldn't
get messed up as much.

This is particularly an issue during the loading of any financial
transaction file, be it QIF, IIF, OFX, or the GTP (Gnucash Trading
Protocol ;)

The real problem is that we want a balanced system but you can only
get one-sided information without the ability to automatically
pattern-match for the opposite side of the same transaction.

> (viz: OFX may show I wrote a check for $100 to grocery ABC.  But in
> fact, for me, it was $50 of groceries, and $50 cash back.  I can't
> really fault OFX for failing to know this.)

-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@MIT.EDU                        PGP key available