Implementing Business Module: advice needed

[Bill Gribble]

On Wed, 2001-11-07 at 12:28, Derek Atkins wrote:
> a) The A/R, A/P, and Inventory account types.  These need to make
>    changes to the actual engine to support these types of accounts.
>    There is no way to plug in new account types.

There is no need for these to have new account types.  They are just
Asset and Liability accounts.  There is only one Accounts Payable and
one Accounts Receivable account anyway.

Of course I don't think it's really a big deal if you want to add these
types to the enumeration of existing types.

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

> b) Invoices: A/R and A/P accounts need to reference Invoices.  I agree
>    that this can be done via KVP data, so it may not be much of an
>    issue.  However, I'd like it such that when you open an A/R or A/P
>    account, you can not only "see" the Invoice number but also have a
>    hot-link to the Invoice itself (and possibly a link to the Payment
>    Druid or some other set of Druids).

Sure, that sounds like a nice way to implement the GUI, but I don't see
what it has to do with the engine.  You'll need some gui to control for
what accounts this type of register is used; most business accounting
packages show the customer, invoice, etc for every transaction in every
account, because every transaction has them.  Seems like something that
could be turned off or on at the top level in gnucash.

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

True.

> Also, as I stated in my design proposal, I don't plan to use GUIDs for
> most of the objects.  The reason is that most everything it
> "numbered", so why have multiple numbers to identify an object?
> Considering you need to access "Invoice #10245" or "Customer #6914" or
> "Job #145" or "PO #84", what's the purpose of a GUID?  Note that
> commodities don't have GUIDs ;)

Commodities ought to have GUIDs, and probably will in the next few
weeks, because we are working on an inventory system that needs to tie
back in to the commodity table.  Job numbers, invoice numbers, SKU
numbers, etc are user-settable fields and should not be used as unique
keys.  that's why we have GUIDs. 

b.g.