Implementing Business Module: advice needed

[Derek Atkins]

Bill Gribble <grib@linuxdevel.com> writes:

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

Not necessarily -- if you have a distributed company you may have
multiple billing departments even though you are keeping one set of
books.  So I'd like to not assume that you only have one A/R or A/P
account ;)

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

I figure this way it can be a key to the UI that it needs to behave
differently.

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

*smiles* I agree, but I don't want to be the one to implement this ;)

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

I guess I was not viewing Invoice/Customer/etc. numbers as
user-settable.  Just user-rememberable :) If the numbers are
guaranteed unique by the program then I don't see the harm in making
them the key.

But you're right -- for history's sake we'd want to use UIDs so that
as you change customers' info you can get a history going back.  So an
invoice you printed N years ago wouldn't "change" if you change the
customer info.

It just makes it more challenging if you change customer info while
you have live orders -- references would be off to older entries in
the database (unless you go and backfil the GUID change when you
update the customer).  It just means that as you change information in
one record you need to be more proactive about determining what else
needs to be changed to reflect it.

> b.g.

-derek

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