Tax Table Tracking

[Derek Atkins]

Rich Johnson <rjohnson at dogstar-interactive.com> writes:

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

Heh.  I always thought it was fairly straightforward.  :)

> 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_.

No, the income is still accrued December 30th, but the invoice is
being re-posted after changes have been made to the Tax Table.  Why?
Well, perhaps you made a mistake, entered the wrong amounts, or just
need to correct some field in the invoice.

Why should you need to re-adjust the tax tables just because you made
a mistake and need to fix it?  Perhaps you applied a line-item to the
wrong account?

> 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.

Uh, maybe.  I don't see why we need it, tho.

> 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.

Yes, it is.  What we have no works closely enough to this without
being so pedantic, and is still correct in the vast majority of cases.
With the changes in HEAD I believe it's even more correct.

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.

> 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.

> --rich

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available