Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Another Proposal fora New Tax System


legend

Recommended Posts

Posted

Hello

 

I have been working on creating exemptions for the tax regime at a store in Manitoba, Canada. The further I get into the db schema and the code, the more it seems to be an odd approach. To get it to work it appears to be somewhat awkward in its approach.

 

The tax structure used by osCommerce starts at the widest level - the geo zone and then descends to the local level. I was wondering if the opposite approach had been tried. That is, start at the city or municipal level, then the state and finally the national. The taxes applicable would then additive as follows:

 

city = x% for residents or 0% for non residents.

state = y% for residents or 0% for non residents.

country = z% for residents or 0% for non residents.

 

Tax exemptions could then be applied against each of these groups.

 

As for the geo-zone, it is essentially irrelevant as taxes are within the sole jurisdiction of the city/state/national governments. 'geo-zone' taxes are generally treaty based agreements designed only to harmonizing national taxes and not the levying of another level of taxes. However, if a 'geo-zone', such as the European Union, decided to impose a 'geo-zone' tax (such as VAT), that could be accounted for simply adding another level as follows:

 

city = w% for residents or 0% for non residents.

state = x% for residents or 0% for non residents.

country = y% for residents or 0% for non residents.

geo-zone = z% for residents or 0% for non residents.

 

The final tax amount could then be prioritized as is the current practice to account for those jurisdictions that calculate local taxes based on the vendor price plus federal tax (as is the case in Quebec).

 

Under this structure, exemptions to taxes would be straight forward. Essentially, it reverses the current focus. Currently it appears that the geography is considered first, and then the taxes applicable. Under this suggestion, the taxes are considered first and then whether or not they apply to the purchasers geographic location.

 

By way of example, Manitoba is a Province of Canada. Manitoba imposed a 7% provincial sales tax (PST). Canada imposes another 7% Goods and Services tax (GST).

 

Whether of not either or both of these taxes should be included in the final price to the customer would depend on the customers shipping address.

 

As for exemptions, aboriginals (natives) living on a reserve do not pay either the PST or GST. In addition, some federal crown corporations (charities) do not pay GST. And finally, dealers living in Manitoba do pay the GST but not the PST. Two columns could be added to the 'customers' table: first a 'tax_exemptions' column which would indicate whether or not this speicific customer was entitle to any tax exemptions and which would reference a 'tax_exemption' table, and, second, any tax exemption certificate number. This table would contain two columns: 'customers_id' and 'tax_rates_id'. For an aboriginal, this table would contain the two records" one for PST and one for GST.

 

The function 'tep_get_tax_rates()' would then be re-coded to sum the applicable taxes based on shipping address minus any applicable exemptions.

 

Further, a collateral benefit to this approach would be to simplify the store setup and any osCommerce contributions that invoke taxation, especially store activity reports. Governments everywhere have at least one thing in common: the tax departments are staffed by soulless bastards whose only joy in life is to make the entrepreneurs life miserable. Personally, I would find it rather challenging to explain to and convince any of these misbegotten wretches that the tax calculation aspects of osCommerce is in fact accurate.

 

Finally, I noticed that the coding places a burden on the server by calling 'tep_get_tax_rates()' for each product on each page. Would it not make it a lot easier to simply calculate the tax once and assign this value to a 'base_tax_rate' saved in the sessions/cookie. Then on checkout, the actual taxes would be calculated based on shipping address as well as a determination of any exemptions, if any.

 

It is not my intention to be presumptuous. It is abundantly evident that great deal of thought and effort has gone into the design of osCommerce. However, experience has shown that on occasion an alternative perspective on an issue can be helpful.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...