Re: For those interested in the CRM/Entity management

[Stroller <..hidden..>]

On 20 Jun 2007, at 22:57, Ed W wrote:
> 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 makes perfect sense when you're a database programmer, but not  
if you're an accountant.

Paper invoices have the address printed at the top of each one.  
Likewise invoices in Ledger should contain the whole address in each  
one, IMO.

I see what you're trying to do, and if you're a database programmer  
or administrator you might think I'm crazy for suggesting this but  
IMO it's better to have duplicate data. When you normalise you make  
things more complicated and introduce the risk of a record becoming  
changed (linked to an different entity) after its been posted. I  
appreciate that good a programmer will endeavour to ensure that this  
never happens, but nevertheless from a certain perspective duplicate  
data in posted invoices _is_ "correct" - the address belongs  
_separately_ to separate records.

Let's consider a "normalised" paper trail. We print out an invoice to  
send to the customer - it has their address on it, the details of  
items & services sold and a total amount owing. The logical thing to  
so is not keep a copy of the whole invoice but to simply record  
customer number, item numbers & amount in a ledger. But the tax man  
does not allow us to do this - he requires us to keep a whole copy of  
the invoice, wasting more paper and consuming much more space in our  
filing cabinets. Whether we produce it with carbon paper, a  
photocopier or by printing it out twice on our laser printer, our  
copy of the invoice has to be exactly the same as the one we sent out  
(not just the relational data required to produce an exact copy).  
Likewise Ledger should keep a whole copy of the invoice, and not to  
to take short cuts (however efficient they may seem).

Stroller.