Re: For those interested in the CRM/Entity management

[Ed W <..hidden..>]

Jeff Kowalczyk wrote:

--- ..hidden.. wrote:
  

+1.  An argument could even be made that an invoice, once produced,  
should become an opaque blob of data.  I can't think of any reason to  
modify a produced invoice.  Any amending of an invoice should surely  
create a new, separate document?
    

True, that reversal-only policy is the stated direction for LedgerSMB.

+1 for snapshotting lookup data into finalized documents such as invoices, and
providing a SP interface for data introspection and verification (*) only, no
modification (which was the intent all along, I believe).
  

I think we are all agreed that snapshotting the invoice is a requirement.  But:

- lets assume that most invoices contain the same address time and time again,
- hence we start thinking about normalising that address record rather than duplicating it endlessly
- this leads us to something like "address" being some kind of abstract object
- we clearly need to know the "customer" object that this address matches to - otherwise how do we know that this "customer A" is or is not the same as another invoice to "customer A" (or even the same as "customer B", only we changed the name at some point)
- So we now seem to need a bunch of address records which can be linked to by an invoice, and have a foreign key back to the "customer" record.

Seems like if you read back a few emails to my previous post that we are back full circle to a model which looks something like contacts with a structured history trail?  You can look at it from either direction, but I think it's a similar model either way?

Are we all on the same page now?  I think it's helpful to review the kind of "use cases" that I sketched out and perhaps dream up some more - I think it helps figure out if we have got the model right if we see that we can do all the operations which will be finally needed.

Ed W