Implementing Business Module: advice needed

[Derek Atkins]

Bill Gribble <grib@linuxdevel.com> writes:

> On Wed, 2001-11-07 at 11:23, Derek Atkins wrote:
> > I'm trying to come up with a solution that is both simple to implement
> > but also simple to maintain.  Similarly, it would be nice if the
> > business features were optional.
> 
> IMO, business features being optional is mandatory.  Most users of
> gnucash don't want them... not in a passive "I don't have desire for it"
> way, but in an active "I have a desire for it not to be there" way. 

I agree that all the business UI stuff should be separate.  You're
also right that in most cases, the business objects don't need to
be linked into the main engine.  The two exceptions to this are:

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.

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

> Let's take an example; say, a customer database.  What do you need in
> order to implement this?   In the most basic case (where no info flows
> from the customer DB to the rest of the app), 
> 
>   - you need a dialog to view and edit the database.
>   - you need some API for the dialog to use to edit the database 
>   - you need a database. 

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.

> Well, if we assume for the moment that the "business module" requires an
> SQL database on the backend, all you need is some widgetry for the
> editor and a few C files in a gnc-module.  When the module is loaded
> it can poke a menu item to open the editor into the app's menus. 

This works for pretty much everything except what I mentioned above.

> Now if you want to connect the customer database to the existing Gnucash
> data structures, just use the KVP tables to store the GUID of a Customer
> record in the relevant Transaction.  You'd need to do a little more
> widgetry to allow this part of the transaction to be viewed and edited.

How hard is this widgetry?

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 ;)

-derek

PS: Thanks for your recommendations.

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available