The following notes have been taken from a mail David Jones posted to the dev list on 25/10/2005 with subject " New TaxAuthority Data Model"
To see how to set VAT for your store you may have a look at Show prices with included VAT in eCommerce (B2C)
The primary entity for the new tax calculation model is "TaxAuthority". In that entity there are various fields that are used to specify how the TaxAuthority operates. A TaxAuthority is identified by a Geo and a Party (the field names are taxAuthGeoId and taxAuthPartyId). We use the combination to represent the organization that is responsible for taxation and the geographic boundary it is responsible for.
Depending on what is passed in various things may be looked up in the database, like TaxAuthorities where the internal organization has a nexus (sufficient presence for taxation) based on productStoreId -> payToPartyId and the shipping (or if no shipping then billing) address. Another important lookup is the ProductCategory or categories relevant to the product. For example, in Australia staple foods are not subject to Goods and Services Tax, but prepared foods are. So flour, milk and eggs are tax free, but once you've baked a cake, if you sell it tax is payable. So you would organise these into two separate product categories.
This may help https://demo-trunk.ofbiz.apache.org/accounting/control/EditTaxAuthorityRateProducts?taxAuthPartyId=FRA_TA&taxAuthGeoId=FRA (cred: admin/ofbiz)
The PartyTaxAuthInfo entity is used to keep track of information about the TaxAuthority for a given Party. This is used for customers as well as internal organizations (ie the company or divisions of it and such) to keep track of tax ID numbers whether the Party is tax exempt for the TaxAuthority, and also (mainly for internal organizations) if the Party has a "tax nexus" in/for the TaxAuthority. By tax nexus I mean that the organization has a sufficient presence there to be required to collect taxes on behalf of the TaxAuthority.