On 6/22/07, Joshua D. Drake <..hidden..> wrote:
David Tangye wrote:
> Its not crazy at all. Its correct analysis. And its not necessarily a
> case of duplicate data. Its a snapshot of an event whose information is
> often represented by the same data values each time. That is not
> duplicate data.
No it is entirely incorrect. Proper normalization with proper keys and
proper revisioning will allow distinct and exact representations of the
invoice data (if not the template which is actually irrelevant) regardless.
While what you are saying is correct, here ...
It is a simple matter (as an example) of not allowing
locations/addresses to be edited. When you insert it, it is there,
forever. You can mark it as active/inactive, and track the timestamp
which the change was made, but you never delete. Thus allowing the
invoice to keep correct data forever.
This part is slightly flawed. In essence you are referring to a different entity: the one that cant be changed because its attached to an invoice. Ie an address intersect with invoice entity (as per described in my previous post)
> 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.
> Yes.
No. That could only happen if you allowed editing of invoices which once
posted we won't.
:-). We all all correct here. You are referring to a slightly different situation.
> 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).
>
>
> Exactly.
Actually no. The taxman require that you be able to reproduce the
invoices not that they be paper (I know, I have been audited several
times, without any incident).
Again we agree. Chris and I are are also agreeing that the easiest way to do this is simply capture the invoice as first produced, in its entirety, and not using relational technology to store that image.
Auditors need to be satisfied that the document you present them is a faithful replica of the original. If its the same Acrobat file that got originally sent, they will only need to know that you do not have Acrobat Editor :-). If you say its reproduced from the application system that also produced the original, they might want to audit that system. I know which option is going to cause a lot less headache for me the user down the track.