On Wednesday, December 15, 2004, at 11:06 PM, Derek Atkins wrote:
er...ease of bug finding/fixing. Not to mention explaining why 'wrong' behavior is correct.[...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?
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
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
