I've seen this movie before :-)

As a general principle, whenever we see a big CASE statement, it's probably a candidate for replacement by an object whose class' purpose is to make such decisions.

In this case, we know two things: 1) the tax rates will probably change sooner or later, and 2) the tax type will also likely change, and as soon as you sell into Canada and Mexico (assuming you don't already) you'll definitely see this. In some jusrisdictions, taxes are additive, while in others, they piggy-back. Therefore you don't want to hard-code the tax rates or the the mechanisms used to calculate the tax.

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.

A great abstraction for this behind the scenes action is the Builder design pattern as explained in Gamma and Helm.

**--** Steve

>I have a client that is moving a VFP6 app from a local to a regional level, and now requires an extension to handle an additional level of tax calculation. Any pointers to a better solution I am more than willing to consider. Table structure changes and rules are allowed :>)
>
>As of now, I have (3) numerics holding state, county, and local tax rates. To deal with clothing sales, we also have (3) logicals to determine the exempt status, .T. indicating that clothing is exempt in this jurisdiction. To add to my grief, NYS does not exempt any one item >$110. Up to this point, I have been handling it similar to the below pseudocode:
>

>IF saleitem >$110
>  totaltaxrate = statetax+countytax
>  do_the_calc_and_storeit()
>ELSE
>  DO CASE
>    CASE state_exempt AND county_exempt
>      totaltaxrate = 0
>      do_the_calc_and_storeit()
>    CASE state_exempt AND !county_exempt
>      totaltaxrate = countytaxrate
>      do_the_calc_and_storeit()
>    CASE !state_exempt AND !county_exempt
>      totaltaxrate = statetaxrate + countytaxrate
>      do_the_calc_and_storeit()
>  ENDCASE
>ENDIF
>

>Adding the additional level for municipal/local makes this method seem very inefficient to me, and confusing to say the least. As the rates/rules change annually at a minimum, maintenance is not a major concern.
>
>Anyone have a better method?