Implementation of a Basic Business Accounting Module

			 Derek Atkins
			warlord@MIT.EDU

			  2001-11-18
		          version 0.2


0. Introduction

This document describes the implementation of Business Accounting
within Gnucash.

1. New Data Types

Four new data types are created: Customer, Vendor, Employee, and Job.
The first three types may eventually hook into Evolution or some
external contact-management database.  Each must keep track of contact
information, billing/payment information, etc.

Currently these data types are implemented as stand-alone data
structures.  Unfortunately this is rather brittle.  Adding a kvp would
add some amount of extensibility, but that's for future work.

Each data type may be accessed via GUID.  Some data types point to
each other (Job's belong to Customers, and Customers have a list of
Jobs).  Future work: add additional lookup mechanisms, perhaps
searches based on names or customer IDs.

2. Orders (Job, Sales, Purchase)

An order is a list of non-posted transactions between either Income
and A/R or Expense and A/P accounts.  A Job or Sales order is a list
of transactions that provide income to the company; a Purchase order
is an expense.  Each order is tied to a Customer/Job or a Vendor and
is typed internally to keep track of how it should behave.

Each order is stored as an unconnected Account.  Each entry in the
order is stored as a zero-value split (just like a scheduled
transaction).  These splits are not actually posted anywhere, the
Account of the split points to the Order.  The real split accounts and
values (among other order information) is stored in kvp frames.

When an order transaction is posted in an invoice, it becomes flagged
as immutable and a pointer to the invoice is added to the transaction
kvp frame.  At that point, the "transaction" cannot be modified
anymore.  When orders are completed, fully invoiced, and "closed",
they can be moved from the list of active orders to the list of
processed orders.  This will keep the list of "active" orders
relatively small but allow processed orders to remain in the system.
There seems to be no need to actually cache processed orders.

Access to Order split information is via an API, rather than through
the kvp directly.

3. Invoices

Invoices tie order entries to posted transactions.  An invoice can
contain transactions from multiple Orders, and multiple transactions
from one order can be split into different Invoices.

Like an order, an Invoice is implemented as a disconnected Account.
Each invoice contains pointers to each transaction included in the
invoice (and similarly, the transactions include pointers to the
invoice).  These pointers are located in the kvp frame of zero-value
splits stored in the Invoice's account.

The invoice account points to the posted transaction that enters the
invoice amounts in the Chart of Accounts, in particular in the A/R or
A/P account.  Similarly, the kvp section of the posted transaction
contains a pointer to the Invoice.  Additional Invoice information is
stored in the kvp frame, such as terms, due date, payment date,
payment transaction, etc.

Like orders, invoices can be moved from 'active' to 'inactive' once
they are paid.  This implies that, like orders, there are two lists of
invoices, the active invoices and the inactive/paid invoices.

An invoice can also be created for viewing or printing, but that is a
separate matter.

4. A/R, A/P

Accounts Receivable and Accounts Payable are special Asset and
Liability accounts (respectively) that are linked into the standard
Chart of Accounts.  For all intents and purposes these are normal
accounts except that posted transactions are linked to invoices.  The
link is a kvp entry containing the invoice GUID.

5. Reports and Druids

Yet to be created/designed... Reports allow you to search and display
current state, create A/R and A/P aging reports, etc.  Druids will let
you easily record orders, create and post invoices, and process
receipts and payments.