Difference in prices between store front and admin

[neit]

I have recently noticed that the prices appear 1 penny more expensive in the admin area to the store front.

Obviously i would not like the customers to get charged more than
what the is advertised, but orders appear to reflect those in the
store admin area.

Is there any way to resolve this?

[kuroi]

Which version of Zen Cart are you using.

[neit]

Zen Cart 1.3.9h
and
Database Patch Level: 1.3.9e

[kuroi]

Could you give an example with the net product price and details of any taxes being applied to it.

[neit]

Heres 1 example:

Tax = 20.00%
Price (ex) = 116.52
Price (inc) = 139.82
Total (ex) = 116.52
Total (inc) = 139.82
Sub-Total: 139.83
Shipping: 0.00
Vat: 23.30
Total: 139.83
Price as advertised in store front: 139.83



A Second example which is different:

Tax = 20.00%
Price (ex) = 52.94
Price (inc) = 63.53
Total (ex) = 52.94
Total (inc) = 63.53
Price as advertised in store front: 63.52


I believe it must have something to do with rounding the decimals up or down.

[kuroi]

Do all your products attract 20% tax?

How do you enter your prices? (e.g. upload via spreadsheet, enter net prices via Admin, enter gross prices via Admin)

Are the prices you're showing us those that are on your screens or the actual prices held in the database (which are held to 4 decimal places)?

[neit]

Yes all products would attract 20%
Indivdual products I would through the admin and add prices as gross.
If I am adding thousands of products I would add products direct into the database using sql, as net prices then let the system work out the
gross tax from the vat rate.

These are what I actually see through the admin side then the product price the customer sees.

Below is what is actuall stored in the datase base for the 2 example prices above.
Example 1 price in database: 116.5248
Example 2 price in database: 52.9364

[kuroi]

OK, you're using the latest version of Zen Cart (the database patch level being "e" makes no difference here), which gives your the best shot at getting these calculations right.

The calculations sound like they should be simple - just add a bit of tax to a net price to get a gross price, right? Alas, not. They're inordinately complex, as they have to take into account discounts applied across multiple order lines, coupons applied across multiple order lines, taxes applied additively, taxes applied multiplicatively and scaling for quantities, and probably other complexities that I've missed.

Overlay that with there being more than one "right" answer in many cases, and the best that we can hope for is that Zen Cart will give consistent answers. And I think that's all your asking for here.

But it doesn't even do that. Despite valiant efforts by the developers, the way that Zen Cart has grown means that these calculation are performed in different ways in different parts of the code. I hear a whisper that consolidating them all into a single, consistent approach is part of the objectives for 2.0. Which is a way of saying that there's no magic code change that's going to fix this easily for you.

But there are things you can do.

The net prices that you have currently don't map to nicely rounded gross prices, so you're encouraging inconsistencies. I could reproduce your problem using your net prices, but it went away when I used net prices generated by entering 139.83 and 63.52 as the gross prices.

Well almost. The 139 price still wasn't quite right in the admin category listing, but it was the same on the admin product page as was used throughout for the customer, which is the main thing.

[neit]

So if I set it to only 2 decimals places for the net prices in
table Products and column products_price there would be no rounding up or down
it would just be whatever price is stored in the database, to decimcal places for all areas of the code.

Would this be correct?

Also do this with products_price_sorter

[kuroi]

Most likely the opposite alas. If you only work to two decimal place with net prices you will generate gross prices that need to be rounded for all except prices whose pence are divisible by 5.

The problem was actually that your gross prices weren't to 2 decimal places and so needed to be rounded.