Business Accounting Design Document, v0.1

[Derek Atkins]

The following document is my first attempt at writing
down how I think a basic business accounting module
can fit into GC.  It's really just a documentation of
the module design, describing what pieces need to be
added into GC.  Most of the pieces actually live
outside of GC itself.

Please send me any comments or criticisms you have.
I consider this a working document at this point,
and anything to help flush it out would be greatly
appreciated.

Once this is flushed out a bit I'd like to try to 
implement some of it :)

Thanks,

-derek


	    Design of a Basic Business Accounting Module

			 Derek Atkins
			warlord@MIT.EDU

			  2001-11-06
		          version 0.1


0. Introduction

This document is a description of the Basic Business Accounting
module(s) of Gnucash.  It assumes a basic level of understanding
of double-entry accounting, business accounting, and Gnucash.
Later sections describe the necessary modifications to Gnucash,
including new GC Account types as well as new GC Objects for
business.

1. Overview

Most of Business Accounting fits outside the standard double-entry
accounting system, but it still overlaps in a number of places.  In
order to support basic business accounting profiles, Gnucash needs to
implement a few new account types and a bunch of new objects.  These
account types are part of the double-entry system but have semantics
slightly different from existing account types The object sit outside
the double-entry system but must still be maintained in the same
database.  Section 2 describes the new objects and Section 3 describes
the new Account types.

Section 4 describes the processes involved.  In particular, it
describes the new Druids that are used to help perform the business
accounting operations.

Next, business accounting requires a set of reports that are useful
for day-to-day, month-to-month operations.  These reports are
described in Section 5.

Finally, section 6 describes some of the work not detailed in this
document.  This document is only the tip of the iceburg in terms of
business processes.  Section 6 is an attempt to describe other modules
that are probably useful (or in some cases necessary) but are not an
integral part of this design.  The intent is that this design be
extensible to allow feature expansion by future modules.

2. New Objects

Business Accounting is different than personal accounting due to the
numerous business processes in place.  In personal accounting you
generally keep track of when you pay your bills, how much is in your
accounts, etc.  With business accounting, you need more detail; you
need to keep track of when bills arrive, when they are due, how much
your customers owe you, and when their payments are due, not to
mention how much you've spent towards jobs without even sending out an
invoice.

The following sections describe the new Business Objects, and what
information is necessary to be maintained.  Each set of Gnucash books
needs to maintain a list of each object.

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

2.1. Customer

A customer is a person or business who pays you to do a job (or set
of jobs).  You are generally providing goods and services to customers
(at least, one would hope ;).  It's basically a billable entity.

Customer {
 int	 ID;		// unique id
 char *	 Name;
 char *	 Address1, * Address2, * Address3, * Address4;
 char *	 Contact;
 char *	 Phone;
 char *	 Fax;
 char *	 Email;
 char *	 Notes;
 int	 Terms;
 bool	 TaxIncluded;
 float	 Discount;
 char *	 ShipToName;
 char *	 ShipToAddress1, * ShipToAddress2, * ShipToAddress3, * ShipToAddress4;
 char *	 ShipToContact;
 char *	 ShipToPhone;
 char *	 ShipToFax;
 char *	 ShipToEmail;
}

2.2. Job

A customer is generally paying you to do jobs (at least in terms of
service providers, like a software consultant ;) It's possible that
one customer may be purchasing multiple jobs from you (such as in a
construction industry), or a customer may be a one-shot deal.  A Job
Object allows you to have multiple projects simultaneously that bill
back to the same customer.

Job {
 int	 ID;		// unique id
 int	 CustomerID;
 char *	 Name;
 char *	 Description;
 bool	 Active;
}

2.3. Vendor

A Vendor is someone you pay; you buy goods and services from them in
the course of your business.  You may notice that a vendor looks
remarkably like a Customer.

Vendor {
 int	 ID;		// unique id
 char *	 Name;
 char *	 Address1, * Address2, * Address3, * Address4;
 char *	 Contact;
 char *	 Phone;
 char *	 Fax;
 char *	 Email;
 char *	 Notes;
 int	 Terms;
 bool	 TaxIncluded;
}

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.

The Sales Order is a catch-all object that collects information for
later invoicing to the Customer.

SalesOrder {
 int	   ID;
 int	   JobID;
 date	   Date;
 char *	   TypeCode;	// Billable Hours, non-Billable Hours,
			// Fixed-cost service, Material item, etc.
 char *	   Description; // Line-item description
 int	   TypeID;	// Line-item ID (referenced from to TypeCode)
 float	   Quantity;
 float	   Price;
 float	   Tax;
 float	   Discount;
 bool	   Billed;
 int	   InvoiceID;
}

2.5. Purchase Order

A Purchase Order is like a sales order, except in reverse.  It is
an object to keep track of ordered items that you expect to arrive
and be billed for from a Vendor.

PurchaseOrder {
 int	   ID;
 int	   VendorID;
 date	   Date;
 char *	   Description; // Line-item description
 float	   Quantity;
 float	   Price;
 float	   Discount;
 bool	   Purchased;
 int	   InvoiceID;
}

2.6. Invoice

An Invoice is a collection of Orders (purchase orders xor sales
orders) that are posted to an account.  The invoice is the object that
holds payment due-date and timliness information.  When a purchase or
sale is invoiced, an Invoice entry is created and the transaction is
logged in the appropriate account, referencing the Invoice number.

Once an Order entry has been Invoiced, it should become Immutable.
Note that each line-item in the Order can be invoiced separately, and
line-items from different Orders can be invoiced together.  In order
to invoice only part of a line-item (for example, you can only ship
part of the Quantity ordered) you need to split the line-item into a
second line-item so they can be invoiced separately.

Invoice {
 int	 ID;		// unique
 int	 BillingID;	// Job or Vendor ID
 guid	 PostGUID;	// GUID of Posted Transaction
 date	 Date;
 int	 terms;
 date	 DueDate;
 float	 Amount;	// Do we need a NetAmount?
 float	 Paid;
 date	 PaidDate;
 guid	 PaidGUID;	// GUID of Payment Transaction
 chat *	 Notes;
}

2.7. Employee

An Employee is an object for partial Job Tracking and Pricing.  An
employee can theoretically log into the system and apply their own
hours to specific jobs.

Employee {
 int	 ID;		// unique
 char *	 Username;
 char *	 RealName;
 char *	 Address1, * Address2, * Address3, * Address4;
 char *  Phone;
 char *	 Fax;
 char *	 Email;
 char *	 Language;	// To allow customization of the UI
 char *	 ACL;		// Access Control List, for system permissions
 float	 WorkDay;	// Default work day
 float	 Rate;		// Default Billing Rate
}

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.

Inventory {
 int	  ID;		// unique
 char *	  Name;
 int	  Quantity;
 char *	  Notes;
}

3. New Account Types

To support basic business accounting processes, only three new account
types are necessary: Account's Receivable, Account's Payable, and
Inventory.  Both A/R and Inventory account are Asset accounts, while
A/P is a Liability account.

3.1. Account's Receivable (A/R)

A/R is an Asset account that tracks how much money your customers
owe you.  Each transaction in A/R is either a record of a sale
yet to be paid, or a payment that results in actual cash to you.

When you Post an Invoice you create a GC transaction that Debits your
A/R account and Credits your Income Account (such as sales or
services).  When you Post a Receipt (payment from the customer) you
create a GC transaction that Credits the A/R account and Debits the
appropriate Cash account (bank).

In either case, the transaction references the Invoice being posted,
to more easily keep track of what invoices have been paid.

3.2. Account's Payable (A/P)

A/P is like A/R except in reverse.  It's a Liability account that
tracks how much money you owe your vendors.

When you post an Invoice you create a GC transaction that Credits your
A/P and Debits your Expense account.  When you post a payment to the
vendor you create a transaction that Debits your A/P and Credits your
Cash Account (where the payment originated).

3.3. Inventory

An Inventory account is a special asset account that links your
transactions to purchases and sales of Inventory items.  Each
transaction in the Inventory account is either:

 a) purchase of stock -- you credit your cash account and debit your
    inventory account, and update your Inventory list to reflect the
    new quantity of items in stock.

 b) sale/use of stock -- you credit inventory and debit your expense
    account.

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

4. Business Processes

The whole point of a computerized accounting package is to make life
easy for the user.  To do that, the business processes need to be
automated in such a way as to enable users to easily process their
information instead of thinking about the accounting. 

The following sections describe the various Druids that should easy
the accounting process.  These druids should enable the user to
quickly and effectively enter the information that needs to get into
the system and process the data through the various accounting steps.

4.1. Customer/Vendor Druid

This druid creates, edits, and possibly removes Customers and Vendors
from the database.

4.2. Job Druid

This druid allows you to create and edit new Jobs.  Once you finish a
job you can mark it inactive to keep it in the system when you no
longer need to reference it for new work.

4.3. Order Processing Druid

This druid allows you to enter new sales orders or edit existing sales
orders.  It allows you to enter time or materials for a Job.

4.4. Invoicing Druid

This druid allows you to bill your customers by finding outstanding
Orders and posting them.  One part of the druid will allow you to
print an invoice.  Then it will build the appropriate splits and post
the transaction to A/R.

In the case or vendor invoices, this druid will find open POs and post
them appropriately.

4.5. Payment Processing Druid

When payments go in and out, this druid allows you to mark invoices as
paid and post the appropriate transaction.

5. Reports

5.1. A/R, A/P Aging Report

This lets you see which Customers are behind on their payments, and
which vendors are owed money.

6. Future Work

(Fixed Assets / Depreciation)
(Payroll)