Business Accounting Design Document, v0.1

Josh Sled jsled@asynchronous.org
Tue, 20 Nov 2001 21:59:47 -0800


On Tue, Nov 06, 2001 at 05:12:49PM -0500, Derek Atkins wrote:

| 	    Design of a Basic Business Accounting Module

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

That's not the point of GUIDs ... and it is the point.

GUIDs are an internal ID which is never visible to the user... as both ben
and grib commented, they basically replace C[++]-pointers in the backends
... but more importantly, they insulate the object relationships from
the user expressing a whim about their-level ID for a Customer/Job/&c...

I think you likely want both.

| The object descriptions here are mostly done in C, for simplicity.
| SQL Definitions can be easily derived, as most of these objects were
| shamelessly grabbed from JobTracker and SQL-Ledger SQL table
| definitions (or in many cases changed to suit the needs herein).  In
| fact, these objects were designed specifically to be stored in a
| SQL-style database.

Why?  Why does it matter?  Do you have existing datastores that you want
to convert over?

| 2.1. Customer

| Customer {
[...]

|  char *	 Name;
|  char *	 Address1, * Address2, * Address3, * Address4;
|  char *	 Contact;
|  char *	 Phone;
|  char *	 Fax;
|  char *	 Email;
|  char *	 Notes;

I'd recommend using VCard for contact info [this, and Shipping], if
possible...  a) it's a level of detail and vocabulary that people are
used to and b) it's supported by other programs...

|  int	 Terms;

Eh?  I'm assuming this decodes somehow into "Net-15" , "Net-30" or
something...?

|  bool  TaxIncluded;

Is this really a property of a Customer?

|  float	 Discount;

Eh?

| 2.2. Job

| Job {
|  int	 ID;		// unique id
|  int	 CustomerID;

This is a case for GUIDs -- if the user changes their notion of a customer
ID, then you don't need to go fixup all the Job records...

|  char *	 Name;
|  char *	 Description;

If you really wanted to complicate^H^H^H^H^H^H^H^H^H^Hextend this, you
could add a table of notes ... but then ea. note has to have Authors and
Timestamps and Digital Signatures, Oh My!

|  bool	 Active;

Perhaps 'date completed', and (!valid(date_completed) == active)?

| 2.3. Vendor

Comments as per 2.1 Customer apply.

| 2.4. Sales Order
| 
| A Sales Order is an object that maintains order and service
| information.  It is basically a collection of billable (or
| non-billable) items that are applied to a Job and will eventually be
| invoiced.

Thought:
Non-billable := zero amount split/transaction
Billable := non-zero amount split/transaction
Fixed-cost service = Billable
Material item = Billable

I wonder if that simplifies things at all... I guess you do want to be
able to list them seperately on the invoice, but perhaps that can be done
as a KVP-frame elt.

| SalesOrder {

|  date	   Date;

This is the date-of-billing?  The date-of-sale?  What if there's a 6-mo
sales cycle?  Or even a 6-day sales cycle?

|  float	   Tax;

How is this not just a split in the transaction?

|  bool	   Billed;

Perhaps: date_billed and ( !valid(date_billed) -> !billed ) ?

| 2.6. Invoice

| Invoice {
[deletia]
|  chat *	 Notes;

So this is an array of IM "chat" logs... ;)

| 2.7. Employee

| Employee {

|  char *	 Language;	// To allow customization of the UI

Seems like a UI thing, not an engine thing... the language choice the
user runs the interface with will allow all customization of the UI.

|  char *	 ACL;		// Access Control List, for system permissions

There was discussion about this a while ago, I believe, WRT the SQL
backend ... I don't believe that this necessarily should be a feature of an
engine object... it seems more like a UI/engine-consumer thing... perhaps
first-order "Credentials" are in order, but not for the engine...?

|  float	 WorkDay;	// Default work day
|  float	 Rate;		// Default Billing Rate

What if this varies per job?

For instance, on one job, I'm out of my element technically [it's highly
hardware-based], and I do docs... on another [highly software-based],
I do software.  For the former, it's $30/hr ... for the latter, $80/hr.

| 2.8. Inventory
| 
| Inventory is a short-term "asset" when you keep materials in stock but
| don't want to charge the expense all at once.  The Inventory Object is
| a way to track what inventory you have in stock.

Seems like the recent PriceDB and Commodity work should apply wholly,
here... like a new Commodity type of description "Widget".

| 3.3. Inventory
[deletia]
| The only thing special about an Inventory account is that in order to
| purchase or use stock you need to update the Inventory List.

Inventory is weird, sometimes.  There's two classes:

. mass inventory -- screws and pens and paperclips ... you don't care
  about the individual elts, just the count of what you have an what remains.

. specific inventory -- $3000 PC/104 boards and Assemblies of other
  inventory components.

Perhaps that distinction [and it's implications] is not in the Realm
of GnuCash ... but it'd be nice for an external package to be able to
interface with GNC about that stuff.

| 6. Future Work

| (Payroll)

[ObSX] Hopefully Scheduled Transactions can be useful, here. :)

...jsled