Bussiness model for GnuCash?

[Rick van Rein]

Hey all,

I've been reading up on the discussions about the small bussiness model for
GnuCash. Please allow me to toss in my twopence.

To give it some scoping, I'm more a software architect than a bookkeeper.

-Rick van Rein.


JobTracker: keeps track of separate costs
SQL-Ledger: proper accounting

Derek> What I'd like to do is combine these two sets of features into
Derek> Gnucash, but I'm not sure how to map all this onto the Gnucash
Derek> "account" architecture.

Be cautious here -- GnuCash is intended as a `lean and mean' application,
and the mere fact that it has a GUI does not mean it should contain all
functionality itself.  Before desktops got mainstream, it has always been the
Un*x way to make targeted, powerful `components' that connect easily. Nothing
wrong with a desktop -- but it is not a reason alter this powerful architecture.

With the database desktop for GnuCash, there is a trivial way of integrating
the accounting facilities of GnuCash with the customer-charging of another
application -- certainly when they share the same database. Keep in mind that
different users can be assigned different rights for the diversity of tables in
a database, so that's certainly possible. And, it has the lovely power of
genericity that's so pleasing about Un*x.


Derek considers charging every single item to a Billable:Customer account...

Derek> The problem with this approach is that it's just too klunky.  You need
Derek> to create 'N' different accounts for each customer you add (one under
Derek> Billable, one under A/R, etc.).  Moreover, what do these separate
Derek> accounts really _mean_?  Do they have a real-world equivalent or are
Derek> they just there to make Gnucash happy?

Firstly, there seems to be nothing wrong with using descriptive fields,
or as Bill suggests, KVPs.  But you'd want to denote the Job in the
description, not the Customer, otherwise you mix Jobs up when you run multiple
for one Customer.

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

Hmmm... dare I disagree? From the perspective of administering finance, is this
true? From the perspective of customer management, sure, but that's another
perspective and I repeat my point that this may be dealt with in another
application, in order to keep GnuCash focussed.

For example, a constraint to the contact database would (under the Dutch tax
system) mean that all changes of contact info are tracked, not merely used to
overwrite the old information. Before you know it you are doing version
management. Other countries may add other weird constraints. Do we really want
to include all this complexity in GnuCash? I suppose we should make a
"completely yes" or "completely no" decision here, right?

Derek> Yes, but right now I've got nothing but time (at least until I find
Derek> another job or find some consulting work).  It's better than twiddling
Derek> my thumbs, and if I do get some consulting, well, maybe it would even
Derek> be useful to me :)

It's not uncommon that activities like these result in jobs in the direction.

			                         w
Derek> Design of a Basic Business Accounting Module  --  Derek Atkins

Wow -- extensive documentation -- well-done!
My remarks below are mainly from a software engineering perspective.

Here's where I would vouch the stuff should go:

Customer :- external contact mgr tool
Job :- GnuCash, using KVP to link separate billable items in (more follows)
Vendor :- external contact mgr tool
SalesOrder :- GnuCash (items linked to Job by KVP)
PurchaseOrder :- GnuCash
Invoice :- GnuCash
Employee :- external personell mgr tool or external contact mgr tool
Inventory :- external stock mgr tool or GnuCash (stock or foreign currency)

Loose remarks:
 * Why do you split SalesOrder from PurchaseOrder, yet combine both into
   Invoices? Should there not be Invoices vs. "Outvoices" also?
 * Why is there no Tax field in PurchaseOrder? Gotta charge the VAT back
   from the tax office!
 * Tax handling is extremely complex -- better not treat it explicitly?
 * You may /assume/ that OrderIDs are numbers, but don't enforce them!
   Mine, as an example, look like
   	DNS.vanrein.org renew gnucash.org 1yr -> 2002

The aging report that you propose is really great!

Bill> And there *should* be a way to plug in new account types.  That's the
Bill> kind of extensibility stuff I think we should be adding to support
Bill> business features.

Yup, agreed. No need to add new "bussiness objects" just extend the enumeration
-- and why not make it user configurable?

Derek?> You also need some way to associate this particular database with the
Derek?> set of books you have open, because some other set of books would be
Derek?> using some other customer list.  For example, multiple companies using
Derek?> the same SQL server but maintaining different books.

Ehm... a database server always separates different databases.
You always access one using dbname/username/password.
Where username/password are not portable over dbname's, even.



Dare I toss in an idea here?


The "Transaction" concept in GnuCash is very general, but it's very local in
time, while actually there are often multiple of these steps needed to get a
payment processed properly.

This brings to (my) mind the idea of /nested/ Transactions. A top-level
Transaction, which you call a Job, comprises of a number of smaller ones, the
current Transactions in GnuCash. The user can select the level at which he
wishes to consider the system (there's the option for the user who doesn't want
to see too much confusing detail).
At the detailed level, he sees every single JournalEntry, whereas in the
overview level, the JournalEntries that cancel each other (wonna-receive on a
A/R account cancels against the actual payment) are combined to give a better
overview. This allows a quick overview of "who owes me" by looking at the A/R
and noting that anything still there hasn't been resolved yet.

This idea is actually the incorporation of workflow into GnuCash. Now I'm not
proposing to build workflow functionality into GnuCash, instead I want to
point, again, at the central database that a workflow tool can use to generate
assignments to call a customer about a missed payment, or to deliver to him, or
whatever else you may desire. I think GNUe, as well as alternatives (Uniface?)
should pick up at this point. Heck, for the home user, a phone book app would
suffice!