Re: COGS incorrect when invoices are reposted

[David Tangye <..hidden..>]

On Wed, 2006-09-20 at 18:40 -0700, Chris Travers wrote:

> > You are going to waste 95% of your energy in the near future if you do
> > not start developing in the *correct* order.
> 
> With all due respect, we may have slightly different ideas of the
> correct approach.
I appreciate that your approach reflects your situation, however I am
not speaking of your specific needs.
>   I don't think that we or our customers can afford
> for us to re-engineer the entire application from scratch which is
> what would be necessary in a bottom-up develop.
See above; and I am talking top-down, not bottom up.
> 
> Note that most of the projects which have tried this approach are in
> perpetual development with no releases ever.
I absolutely disagree. Many might, but most hacked projects bog down
when lack of planning, scope etc come back to bite them. One example:
SLQ Ledger. Its potential for much significant functional improvement is
close to zero. And as I think you have more or less said before, you are
inheriting that potential.
>   As much as I would agree
> with you if we were engineering from scratch, the situation simply
> isn't that simple here.  We have to put food on the table somehow, and
> our customers need something better than SQL-Ledger.
You have stated this before and I accept it. I am simply stating as
clearly as I can how to get to where you will have 'something better
than SQL-Ledger'. I do accept that what you have done is a significant
tidy up/bug fix with limited though very useful improvements.
>   In this case, an
> incrimental approach is *far* better than the attempt to build
> everything from the ground up.
Incremental is always better when you have a sound schema to work off. 
As we agree though, the problem is the database. It seems you ought to
start a version 2, that is soundly based, and accept that limited
version 1 changes will still be an inevitable overhead to suit customer
pressure.
> BTW, I think that Josh will agree me that mere 3nf is insufficient for
> the db schema and that we need to be focusing on normalizing the data
> as close to 5nf as possible,
I should have stated, that I think 3nf is crucial, and if everyone can
go to 5nf together and not get bogged down in modelling-theory wars,
then that is great.
>  and that a great deal of attention needs
> to be paid to the semantic outlay of the data.
'semantic outlay'? Is this 'semantics'/terminology/naming. I believe
they are absolutely crucial. Concise naming is crucial, and I found one
of the most underrated and in cases derided concepts in bad development
projects. The old lazy ignorant argument 'What should we care what the
actual name is? We know what it means.' The fact is most people then
take away different ideas about 'what it means', and that's where the
bugs start coming from. 'What it means' is defined in the
requirements/documented etc etc, I know I do not need to restate this.