Thinking about it overnight the problems of setting up all the exclusions for each customer concerns me. It seems to me that although it requires no changes in the code, it would be far easier to use a scheme in which the tax applied is a function of the customer's location.

Of course the scale of the problem is a function of how wide an area the mobile practice is doing business over. It is is all of Texas then there are some 2600 tax locations.  If the practice is only doing business over say 10 different tax locations then the scale of the problem is less and Tim A's suggestion of using the 2.0 'tax set by practice location' solution is applicable. In fact, if one looks at all the 2600 odd tax locations, there are only 10 different total tax rates (0.0625, 0.0650, 0.0675, 0.0700, 0.0725, 0.0750, 0.0775, 0.0800, 0.0813, 0.0825). So in terms of applying the correct tax rate we only need 10 different practice locations.

We already have a practice location field for each customer - whose title/label we can easily adjust to 'Tax Location' by modifying the archetype. [Since the practice is a mobile one, you don't need the Customer's Practice Location to reflect the arm of the business involved - which is what it is used for by multi-site practices.]

Now we come to the reporting problem. We need to be able to figure out the tax breakup for each customer from their location. You have probably figured out that OpenVPMS allows one to hold multiple locations/addresses for each customer so we need a rule to say which is used for the tax location. We could use the Billing Address or add a new contact purpose Tax Location via Administration|Lookups|Contact Purpose.

Now although the purists would want the tax breakup for a given location to be held separately, there is no real downside in modifying the contact.location archetype to hold 4 taxation names, tax numbers and their rates. Since everybody is paying 6.25% Texas state tax, you do need to record this here. Also if you want to have tighter validation and better normalisation, you could have a lookup containing the tax names,  numbers, and rates (eg Sabine County, 4202006, 0.05) and just put the lookup code(s) in the location contact.

Adding a field in OpenVPMS is a piece of cake - in general, one adjusts the archetype and magically the field appears on the screen ready to use - no java code changes needed. See http://www.openvpms.org/forum/referred-client-option for a neat example. As a second example, we needed to add a Language field to the customer record so that we could send out appointment reminders in either Cantonese or English.  We added the following to party.customerperson.adl

        <node displayName="Language" name="language" path="/details/language" type="java.lang.String" minCardinality="1" >
            <assertion name="lookup.local">
                <propertyList name="entries">
                    <property name="C" value="Cantonese"/>
                    <property name="E" value="English"/>
                    <property name="D" value="Dual"/>
                </propertyList>
                <errorMessage>Language is mandatory</errorMessage>
            </assertion>
        </node>

and the customer information screen is now as below. (The HKID field is a example of 're-purpose by changing title' - this is normally the Travel field which we don't need, but we did need to hold the customer's Hong Kong ID number. If I knew then what I know now, I would have just hidden the travel field and added the HKID field, but at the time I didn't have the confidence/knowledge to do so.)

Meanwhile back at the reporting side.  Given the above design (ie the customer's location contact with purpose 'Tax Location' holds up to 4 applicable  tax rates and their names), all we need is a tweaked version of the one of the sales reports that goes though all sales (and credits) in the specified period and totals the tax amounts by each tax name/number.

Given that the practice is not going to initially have hundeds of customers, you can probably start initially with a 1.9 system and use the customer 'exclude tax' facility to get the appropriate tax rate for the customer. Then switch to tax-set-by-practice location when 2.0 becomes available.

Two other pieces of information:

a) tax on invoice: all you need to do is set the Prices Include Tax option in the practice record to Off - then your invoices will print the ex-tax amounts against the line items with an asterisk if tax is applicable.  You might want to tweak the standard reports_en_US.properties to change the tax name from 'State Tax' to say 'Applicable Tax'

b) for each line item we record both the inc-tax amount and the tax amount, so the tax amount is available reporting - in your case we just need to aportion this via the Tax Location contact tax information into the various state, city, county and other pots.

Hope this helps.  If you need help tweaking the archetypes, please yell.

Regards, Tim G

Timothy - are you absolutely certain that for a mobile practice, the sales tax payable is a function of the customer's location rather than the business's location?

As far as I can see from https://www.taxjar.com/states/texas-sales-tax-online/#how-to-collect-sal... the tax is a function of the business'es location, and not the customer's.  Specifically:

So if the business is based in Texas, then irrespective of where the customer lives, you charge the tax based on the business location.  It only gets tricky if the practice is located in say New Mexico, but most of the practice's customers are in Texas.

If the above is indeed the case, then the whole problem goes away.  If the mobile practice's address is in say Gause, Tx 77857 then irrespective of where the customer is the tax rate is State Tax 6.25% + Milam County tax 0.05% = 6.75%.

When doing the sales tax return we simply aportion 6.25/6.75 of the tax we charged as State Tax and 0.05/6.75% as Milam County Tax.

Regards, Tim G

I thought it would be worthwhile recording the outcome of the above.

We ended up with:

1. a modified part.customerperson archetype - to add a Tax Location field
2. 3 new archetypes to define the Tax Locations (2497 of them), the Taxes (1507 of them) and which taxes apply at which locations
3. two reports - one to list the taxes applicable at each location and the total rate at that location, and one to generate the data for the Texas 114 and 116 forms

Initially the system will run 1.9 with some 8 different total tax rated defined, and each customer having all of these except 1 disabled. When 2.0 with 'tax rate set by practice location' becomes available, this will be used instead.

This has been an interesting excercise in seeing how far one can tweak OpenVPMS to suit local conditions - in this case a mobile vet working in a state where the sales tax is a function of where the vets's customers live. Note that some (they have big ranches in Texas) are actually spread across more than one tax location. [These will have multiple customer accounts.]

Regards, Tim G