|
By brianwatson - Wed 18 Nov 2015
|
I'm new to Kartris so what I'm about to say may be wrong but it seems as if product pricing is controlled at version level and the price input includes tax.
Here in the UK and other parts of Europe Value Added Tax (VAT) is susceptible to change and so if VAT changed I'd need to edit the price of all product versions. Surely this is wrong. I would expect the ex VAT price to be stored and the tax added so that in the event of such a tax change only the tax rate value needs updated and this in turn is added to the base price to calculate the new value inc. VAT.
Now I accept that in the event of a tax rate change some retailers might chose to leave prices of existing stock as they are and if that was the design ethos then there should be an option to add or deduct the tax from the input value so that the actual ex VAT price is stored and the current retail price including vat given if a calculated (+ VAT) price is not to be used, but looking at the tblKartrisVersion attributes this does not appear to be available.
Many of my clients also deal business to business and so wish to show the Ex VAT price in addition to the inc VAT price, but from the templates this is only possible when multiple versions are set even if there is indeed only the one version. Do I have to build custom templates to overcome this and if so how might this be affected with future updates?
|
|
By Paul - Wed 18 Nov 2015
|
Kartris can handle EU vat, assuming you correctly choose 'EU' as the tax regime during setup. If not, you can change that within the web config file.
Once in the back end, you can tweak settings for tax, which determines whether the prices you enter and inc or ex vat.
http://userguide.kartris.com/Default.aspx?headID=72
There is also a page in the back end for setting tax rates, you can create multiple rates, so if you have items that have zero VAT or lower rate 5% vat, you can do that too.
But we'd suggest locating the 'regional setup wizard' in the back end, this should help configure VAT properly so you charge it to EU country customers where appropriate, and also zero rate sales to other EU nations when the customer is VAT registered and provides a valid EU vat number (these are checked against the EU's web service).
|
|
By brianwatson - Wed 18 Nov 2015
|
I already had the general.tax.euvatcountry set to GB but the general.tax.pricesinctax was set to Y rather than N. I've now changed that thanks. The frontend.display.showtax was already set to Y.
Previously it displayed duel pricing i.e. £700 ex VAT £840 inc Vat (the aforementioned change means all prices already entered include VAT and so the value will be incorrect until these are changed) but the page now shows £840 Value Added Tax (VAT) 20% (both being as entered into the language and tax configurations) but the price shown is without the actual calculated price inclusive of VAT which is illegal.
We can show a price inclusive of VAT or both prices, exclusive and inclusive of VAT, providing the ex VAT is not given greater prominence, but we cannot show ex vat plus tax as currently shown.
In short the general.tax.pricesinctax set to Y shows the correct format only I want to store the value in the database tblKartrisversions.V_Price as the ex Vat price and calculate the price including tax at whatever rate has been applied or whatever that might change to in future.
|
|
By Paul - Thu 19 Nov 2015
|
This isn't possible because it leads to rounding problems.
When set to pricesextax, the rounding regime is per row. So it will total items on each row of the basket (e.g. there might be 10 or 15 of one item, which appear on same row), then apply VAT, then round it to the right number of decimal places for the currency (normally 2 for most currencies). This is how Sage accounts tends to total tax for business invoices.
If pricesinctax is selected, rounding occurs per item - this is because it is a consumer oriented regime. So each item has tax subtracted and then the ex tax price is rounded to 2 dp, and then multiple items are added on each row.
Because of the extax calculation being per row, you can't show an inc tax price because it would be rounded, and so if someone adds multiple items to the basket, the amounts for ex and inc tax might be pennies out due to the rounding.
If you must display an inc and ex tax price as amounts, then you'd have to enter inc tax prices, or enter ex tax prices and then use the markup tool to increase them by 20%.
Obviously if the VAT rate changed, and you wanted to retain the same 'ex tax' price, then it would be relatively easy to run the mark up prices tool again to make the required % increase to prices.
Markup prices tool is bottom of product menu. You can either specify items by criteria and then apply a % up or down, or you can create a file of SKUs and prices and upload that to update items to exact prices.
|
|
By brianwatson - Fri 20 Nov 2015
|
With all due respect I think your design ethos is fundamentally flawed. Every item has a price exclusive of tax. That does not differ if tax rates change but the price including tax is susceptible to change as tax rates alter. Basing your design on an inclusive of tax price might appear beneficial to retailers you offer items for sale at prices like £9.99 and they will no doubt round prices up or down as tax rates change but it falls far short of what is needed to meet all needs especially those selling in the B2b environment.
If I do as you suggest then whenever tax rates change all prices need updating. Even those retailers with prices rounded to 1p off the pound need to make substantial changes and after all we could be looking at hundreds of thousands of items. Whereas altering one set tax rate value that is reflected on the site against all items using that related tax are immediately updated across the entire site.
I accept your point that rounding post tax can cause issue with decimal places but there are numerous ways to manage this. A simple method would be to take the v_price from the database as ex tax, add the tax to offer a calculated unit price appropriately rounded, quantity is then multiplied against the unit price and you post each line item with the rounded tax value, after all invoice line items will not be related otherwise tax and price changes would affect historic transactions.
I should also explain that I'm seeking to replace an e-commerce system that I build for a client in 2002. It has lasted this long because it met all his needs including a convoluted multi discount structure that cannot be met with Kartris. I need to avoid major redesign because doing so would create problems with future updates and deviates from the plan to have him with a solution that many developers can support. I am looking to retire soon and want my customer to be on a stable and well supported platform, I thought Kartris looked promising but this tax issue is going to be a deal breaker.
|
|
By Tiggywiggler - Sun 3 Jan 2016
|
Brian,
Where did you get to with this please mate? Did you find the resolution you were after?
|
|