Tax Table Tracking

[Rich Johnson]

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

> Hi,
>
> Sounds about right.
>
> The only comment I have is that I wouldn't call them invariants, or,
> at least, not everything you've labeled is an invariant.  As you
> noticed, unposting an invoice does not maintain them all.  This is not
> a bug.  In HEAD the user has a choice to keep the taxtables or revert
> them (this change has not been back-ported to 1.8).
>
> Here's why this is not a bug: Assume you post an invoice on December
> 30th and the tax rate is 5%.  Then on January 2nd you realize you've
> made a mistake and need to unpost and repost the invoice.  Howver on
> January 1st the taxrate changed to 6%.  Your invoice still needs to
> use the 5% rates when you re-post it, so you want to continue using
> the immutable children.

Thanks,  I think I'm _finally_ beginning to grok the state machine of 
the business objects.

But that bit of unposting/reposting invoices bothers me.  I understand 
the argument--especially when you unpost an invoice when a tax rate 
disappears altogether  (e.g. a sales tax on Labor, or retail sales tax 
holidays).   What bothers me is that for this example the sale is made 
and income accrued upon posting (Jan 2nd) but the tax rate is 
back-dated to Dec 30th.  In effect you're modifying and reposting an 
invoice _as of Dec 30th_ and you want to use the tax in effect as of 
Dec 30th (although the record keeping is performed on Jan 2nd).  IOW 
this is tacitly handling tax _periods_.

Clearly explicit handling of tax periods would be an enhancement.  Can 
we get it put on the list?  I envision it being supported with with 
optional 'effective/expiration' fields added to the tax table entries.

I would argue that in lieu of explicit support for the tax periods, the 
  'pedanticly correct' process to change an invoice posted with an error 
would be
  -  back out changes to the parent tax table (if any),
  -  unpost the invoice, reverting to the parent tax table,
  - modify the invoice.
  - repost the invoice,
  - and finally restore the changes to the tax table (if any).
Admittedly this is awfully fussy.

The question is really one of how to balance this (hopefully rare) 
hassle against semantic clarity.

Have you a suggestion for a term of art other than 'invariant' to 
describe the usual situation?

--rich