Business Accounting Design Document, v0.1

[Ben Stanley]

Derek Atkins wrote

>Note that while most of these objects have an 'ID', the 'ID' is a
>counter and not a GnuCash GUID.  This is because business processes
>seem to reference these objects by number (customer number, invoice
>number, sales order number), so having a GUID seemed superfluous and
>unnecessary.  Also note that most objects state the ID should be
>unique -- by this I mean that there should only be one entry (row?)
>with that number.
>
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.

    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 
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 
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 
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.

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...)

What if you have a close relationship with a particular company, and you 
buy and sell things from/to them? Then you would need a customer and a 
vendor object for them. Perhaps these two share more information than 
this design currently exploits.

GST/VAT

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

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

Ben.