Hi Steve,

I've seen this movie before :-)

I was sure of it!

>Here's the basic abstraction: create an interface class, name it say TaxCalculator, and into this interface you pass an object that contains everything known about the item(s) being sold. This provides a stable interface that client-code can use forever without changing. In other words, the TaxCalculator class completely shields the clients from the complexity and evolution of the implementation.
>
>Then later, behind the scenes, the TaxCalculator class can evolve and adapt to whatever the crazy legislators will dream-up in the future. If you build everything with table-based metadata then you can make changes without recompiling.
>
>In our case, behind the scenes, we instantiate separate implementation objects for municipal, state, and federal taxes, and these get combined in series or in parallel depending on whether taxes are additive or whether they piggyback.
>

I suspected a complete rethinking of this would be best for the long term. As this was one of those "kicking and screaming" apps I was dragged into, I was hoping for a quick fix. Thanks for the guidance.