Tax Table Tracking

[Rich Johnson]

On Wednesday, December 15, 2004, at 11:06 PM, Derek Atkins wrote:

> [...snip...]
>
> I do NOT believe that backing out changes to the tax tables would EVER
> be correct.  Why should unposting an invoice change the existing tax
> tables?  That would be wrong, IMHO.
>
>> The question is really one of how to balance this (hopefully rare)
>> hassle against semantic clarity.
>
> Why do you care?
er...ease of bug finding/fixing.  Not to mention explaining why 'wrong' 
behavior is correct.

> Seriously..  I think the current behavior is the
> most correct that it can be.  Assume the change in HEAD (where you can
> reset the tax tables or keep them the same) -- the only time that
> could cause problems or confusion is if the tax tables changed AND you
> choose to keep the old (children) tax tables AND you add some new
> line-items.  But I think that's even more rare than anything else.

There's another case:  An entry has an incorrect tax table AND it is 
unposted without reverting AND the correct tax table has changed.   If  
there happen to be other entries referencing the modified tax table, it 
is possible to end up with multiple entries showing the same tax table 
but differing rates.  IMO, even allowing such a situation is just 
asking for trouble.  I would classify it as a usability flaw.
(One thing I didn't check is that I would expect to see similar 
behavior re the _account_ associated with the tax table entry.)

These scenarios arise whenever there's a divergence between what's 
_effective_ and what's _current_ in the tax tables.
>
>> Have you a suggestion for a term of art other than 'invariant' to
>> describe the usual situation?
>
> Not really.  It's close enough to an invariant.  Just leave out the
> portion of "only tied to {un,}posted invoices" and you'll be exactly
> an invariant.

Hmm, it  clears things up for me if I think of invoices as have three 
states, rather than two.
They are {unposted, posted, partially unposted}.  I don't like that 
"partially", there must be a better set of names for these.

--rich