[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: For those interested in the CRM/Entity management
- Subject: Re: For those interested in the CRM/Entity management
- From: Shaun Laughey <..hidden..>
- Date: Wed, 20 Jun 2007 12:01:29 +0100
On Wed, 2007-06-20 at 11:52 +0100, Stroller wrote:
> On 20 Jun 2007, at 06:04, Chris Travers wrote:
> > ...
> > I understand what you are saying, but I still disagree. Instead I
> > think we are talking two different things.
> > 1) Invoices need to be entirely self-contained. They need to store
> > all information required to recreate and track them. We may want to
> > add a lot more metadata (even if it looks like duplication) to the
> > invoice to make that possible. That is the best way of tracking
> > customer state information at time of invoice.
> Hear, hear!!
> I find the way relational data is currently applied to old invoices
> to be *ledger*'s greatest shortcoming.
> Company changes address, I look up an old invoice & print a duplicate
> and its address is wrong.
> I know others have posted suggesting ways to keep previous addresses
> associated with old invoices, but IMO invoices aren't suited to a
> relational structure. Invoices have a unique status as a legal
> document - once the invoice is published that address BELONGS to the
> invoice. Even if another invoice is printed to the same customer &
> address the same data belongs separately to both invoices and is not
> shared between them,
> Having invoice records contain all the data shown on the invoice
> itself is the best way to ensure the invoice is set in stone, IMO.
+1 to Stroller - every good system I've used, designed or pleased to pay
for has had the invoice address and other details recorded against the
invoice not the customer.
It may copy them from the customer at invoice time but after that they
become part of the invoice.
I think the use of linked lists is a complication that isn't really
py r2 ltd.