[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: For those interested in the CRM/Entity management

On 6/21/07, Stroller <..hidden..> wrote:

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

I would also like to add some emphasis to what Stroller said above.
When I call up an invoice by invoice number, the data shown _must_ be
exactly what was printed on that invoice, be it yesterday or 5 years
ago.  This is a legal requirement that has nothing to do with the
database and good database programming practice.  It is also unwieldy
to ask me to maintain a PDF file separate from the database to show
what was reality versus what is normalized data vis-a-vis a bill sent
out last year.

While I appreciate and understand normalized data, we cannot discard
legal requirements with logical database arguments.  Once an invoice
is posted, it should be locked in concrete and not "normalized" or
changed in any way, be it name, address, tax data, etc. Changes are
the venue of reversing or adjusting entries on a separate invoice.
Personally, I don't need a perfect copy, I just need the data
displayed not to have changed in any way.

Yes, it would be nice to be able to write "the perfect database" based
on all the nice rules we've devised over the years.  The reality is we
absolutely must comply with legal requirements or be told by the tax
man to find/write software that can comply with the law.


David A. Bandel
Focus on the dream, not the competition.
           - Nemesis Air Racing Team motto