A/R, A/P, Invoicing features

[Bill Gribble]

On Mon, 2001-11-05 at 12:02, Derek Atkins wrote:
> The biggest question I've not been able to answer is whether Employees
> (for time billing), Customers, and Vendors should each have their own
> account (or set of accounts), or if lists of Employees, Customers, and
> Vendors should exist similarly to the list of Commodities.  I'm
> ignoring inventory for the moment.

The standard approach here is for these things to have their own table. 
You have a "contact database" that you use to build records for each
vendor, customer, and employee.

Then you attach a customer/vendor/employee id number to transactions,
invoices, sales orders.  In gnucash you could do this with KVP info. 
You can then write reports that generate results for a specific
customer, because you can query out the transactions that are specific
to that customer. 

> The next big question is how to treat billable items between the time
> they are "charged" and the time they are "invoiced"?  For example,
> let's say that employee E spends 16 hours this week on project P,
> being charged to Customer C.  The customer wont be billed (invoiced)
> until next week, but somehow we need to record the charges without
> actually posting to A/R.

That's the sales order.  ATM gnucash doesn't have anything even remotely
like this, and it's going to be sort of a trick to make it happen ...
one way or another you're going to have to add a lot of new stuff to the
backends. 

> One approach is to have an asset account "Billable" and then have a
> sub-account for each customer.  When you bill time, you xfer "hours"
> from employees to the Billable:Customer.  But then what do you do when
> you invoice?  It would seem like you would need to have a sub-account
> of A/R for each Customer, so when you invoice you would xfer the
> invoice amount from Billable:Customer to A/R:Customer.  And then when
> the customer pays you, your receipt is a xfer from A/R:Customer to
> "Bank".

I think you need to think of this as entire new sets of data structures
for gnucash rather than trying to wedge the concepts into the existing
framework.  Invoices, Customers, Sales Orders are all first-class
business objects like Transactions.  Sales orders can be "invoiced" to
create invoices, and invoices hit the ledger in the form of
transactions.  

The lack of these things is why gnucahs is a personal finance program
and not a small business accounting program :)  You are tackling a big
problem. 

b.g.