Business Accounting Design Document, v0.1

Derek Atkins warlord@MIT.EDU
07 Nov 2001 18:36:30 -0500


Ben Stanley <bds02@uow.edu.au> writes:

> The GUID is used with the file readers/writers to re-construct the 
> pointer relationships between objects. This is done by building a table 
> relating GUIDs to pointers to objects while reading in the file. If you 
> create objects without GUIDs but using IDs instead, you would have to 
> replicate this mechanism. I think it would be simpler for you to include 
> user-invisible GUIDs in your objects and use the existing 
> re-construction mechanism than to re-implement it in terms of IDs.

I don't plan to use the file reader/writer; I plan to use SQL
directly.  Perhaps this is a poor long-term solution, but then again
I'm not being paid to build "the right" long-term solution. ;)
Considering the object are NOT going to be read or written using the
existing readers/writers (including the existing Backends), then I
think going through extra effort to make them work is, well, extra
effort.

>     2. New Objects
> 
> 
> On the subject of your object descriptions, there was some discussion of 
> using gnomecal or evolution to manage addresses. I suppose we need to 

Well, gnomecal is a calendar, so I'm not sure how that helps.  As for
evolution, it is NOWHERE near ready.  I'd like to get something
working.  We can figure out how to share data later.

> start somewhere... if we keep the implementation hidden behind some 
> opaque api, then this could be added later as an optional backend. I 
> just cringe when I see the fields of a form laid out in C. I think that 

Well, the program is written in C...  Keep in mind that Accounts and
Splits and Transactions are all C structures, too.  If you don't like
it, you are more than welcome to re-implement what I do ;)

Seriously, the reason I sent out C structures was more for simplicity
than anything else.  C structures convey, IMHO, the most information
in the least space.  I suppose I could have also sent SQL table
definitions, which are just about as compact.  XML is way too verbose,
and quite honestly I'm hoping to avoid using XML in my implementation.

> there needs to be a user-customisable capacity here, perhaps done with 
> key-value pairs, so that extra fields can be added by the user / 
> application customiser. A business system would be implemented by an IT 

To what extent?  I mean, there isn't that much customizability in the
rest of Gnucash.  The dialogs are all implemented in C -- they are
fairly static.  Sure, the look-and-feel is changable due to libglade
(and yes, I'm working with glade to design the UI) but there is still
some rigidity.

> group (for a large organisation). For a small organisation, some default 
> setups could be provided along the same lines as what you have provided 
> in your struct defs. I see you mentioned storage in SQL database; 
> perhaps I don't know what I'm talking about.

See, here's the rub -- you need to pre-define your SQL tables.  Tables
are, for all intents and purposes, equivalent to C structures.

> I think that the address of the customer and of the vendor and even the 
> shipping address are all addresses, and perhaps should be stored as a 
> struct of their own kind. (employee address too...)

Perhaps, but I'm not convinced that's the best thing to do.  Even if
you have a close relationship with a particular company, the odds are
you'll have a different contact for use as a customer or a vendor.

> GST/VAT
> 
> Do you have any thoughts on simplifying business procedures for keeping 
> track of GST/VAT for invoicing?

Nope.  I was planning to punt on that for now.  We don't have GST or
VAT here in the US, just Sales Tax.

> That's my only thoughts so far.
> Good work!

Thanks,

-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