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