Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

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"

Show prices with included VAT in eCommerce

To see how to set VAT for your store you may have a look at Show prices with included VAT in eCommerce (B2C)

TaxAuthority

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.

The main fields on the TaxAuthority entity right now that determine operational constraints are:

  • requireTaxIdForExemption: if Y then a tax ID must be on file for the customer to receive a tax exemption
  • taxIdFormatPattern: constrains the format of the tax ID, uses regexp syntax
  • includeTaxInPrice: for VAT style taxation, if Y sales tax will be included in prices shown to consumers

In general the TaxAuthority entity is a place for settings related to how the TaxAuthority operates, independent of categories (types) of products, and so on.

TaxAuthorityAssoc & TaxAuthorityAssocType

The TaxAuthorityAssoc and related Type entity are used to describe associations or relationships between TaxAuthorities. One example of such an association would be Exemption Inheritance where if a customer is setup to receive an exemption for one TaxAuthority then that may qualify the customer for exemptions for various other TaxAuthorities. The taxAuthorityAssocTypeId is used to define how the two tax authorities are associated.

TaxAuthorityCategory

The TaxAuthorityCategory entity is used to keep track of which ProductCategories are associated with the TaxAuthority. This is mainly to ease administration so that there is a place to attach categories that are created for taxation purposes so they can be easily referred to later, like when creating or updating a TaxAuthorityRateProduct record.

TaxAuthorityGlAccount

The TaxAuthorityGlAccount entity is used to configure which GlAccount should be used to gather sales tax transactions, and periodically balancing entries as the tax is paid to the Tax Authority organization.

TaxAuthorityRateType

The TaxAuthorityRateType entity contains information about different type of tax rates, or different types of taxes. It is used to organize the related rate entities like the TaxAuthorityRateProduct entity. Different types of rates (or taxes) include sales tax, use tax, income tax, export tax, etc.

TaxAuthorityRateProduct

The TaxAuthorityRateProduct entity is one of the more complex parts of the TaxAuthority data model. This entity is used for specifying the rate to use when the conditions for the sales tax being calculated match the settings on that record. When the tax is calculated various factors are passed in and all matching records are looked up and an adjustment (line/item level) is created for each matching record (generally one per TaxAuthority). Things that are passed in typically include:

  • taxAuthGeoId & taxAuthPartyId OR shipping address(es) (and optionally billing address)
  • point of title transfer (optional)
  • productId
  • purchase price
  • order pre-tax subtotal
  • productStoreId
  • taxAuthorityRateTypeId

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)

PartyTaxAuthInfo

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.

ProductStore

The ProductStore entity has some settings which are tax related. For stores that represent a company or division that is in a jurisdiction that uses a VAT style tax you can specify that taxes should be included in prices shown to consumers (the showPricesWithVatTax indicator) and if this is set to Y the vatTaxAuthGeoId and vatTaxAuthPartyId should be specified so that we know which TaxAuthority to calculate taxes for (in other cases this is decided based on TaxAuthorities where the company has a nexus and the order is being shipped to, or in some cases billed to if there is no shipping address).

2 Comments

  1. Paul Foxworthy

    TaxAuthorityRateProduct is intended to hold a tax rate levied by TaxAuthority for a transaction involving some productCategory. (Remember that in OFBiz, you can have multiple product categories for different purposes, so you can have a "taxable" or similar product category associated with products. You will probably want entirely different categories for customers to navigate and locate products to purchase.)

    The ProductStore is only relevant to sales. In fact, I would argue the ProductStore exists in TaxAuthorityRateProduct as a proxy for a location. In many Value Added Tax/Goods and Services Tax regimes, exports aren't taxed. In other words, in order to decide if tax applies, you need to know the geographical location of both the buyer and the seller. For sales, your ProductStore is the seller and you know its location.

    For a purchase order, you may also want to estimate the tax payable at the time you create the order. Your calculation is only an estimate, and an accounting liability for the tax will not exist until you receive a purchase invoice from the supplier. However, estimating the tax when a purchase order is created might be very valuable for cash flow projection. TaxAuthorityRateProduct does not have the necessary data to calculate the estimated tax. Your ProductStore is irrelevant to a purchase. TaxAuthorityRateProduct really should have a second GeoID for the Seller. In the long term, I would like to see that replace the ProductStore. A first step would be to add a sellerGeoId to TaxAuthorityRateProduct, which would be used if the ProductStore is null.

    1. Jacques Le Roux

      Hi Paul,

      That's interesting, at least for most cases. For isntance, I know it's more complicated in India (multi locations/rates) at the moment, but they also want to simplify the way they raise VAT.

      Also when reading you:

      However, estimating the tax when a purchase order is created might be very valuable for cash flow projection.

      Something OFBiz misses is accrual: http://www.mbtmag.com/articles/2014/09/managing-accruals-why-erp-systems-are-not-enough even basic. Of course this would be a long term goal...