Hello,
I noticed that when VAT (tax) is disabled, the base price with tax is calculated as 0 too (not as equal with product price/cost).
I'm attaching a screenshot.
This is not the original VM product list, so I guess, you have to show the code behind it.
It's on a test site - J 3.9.12 and VM 3.6.2 10159, with the default sample data.
You can do this experiment on a test site:
1. Disable VAT (rule #1)
2. Make an order
3. See it on backend.
I see, you are in backend in order edit, I thought you are talking about the invoice.
Does that still happen with 10177?
http://dev.virtuemart.net/projects/virtuemart/files
There is a lot of bug fixing going on, 18 revisions behind is a lot.
Try directly 10179
http://dev.virtuemart.net/attachments/1204/com_virtuemart.3.6.3.10179_package_or_extract.zip
I updated the test site to 10179, I made another test order and the result is the same.
actually it is a bit a philosophical thing, if there is no tax, we do not have a baseprice with tax.
It would be expected that baseprice with tax to equal baseprice if tax is 0 :D
hm...
100 * 0 = 0
Diri, I do not agree. Tax = 0% gives
Baseprice with tax = Baseprice + (Baseprice * 0 / 100) = Baseprice
Jörgen @ Kreativ Fotografi
Jörgen, you are absolute correct.
Adding tax to baseprice should be performed but, I stumpled over this and similar misbehaviours very often when testing import of data and using VM's functions for price calculation before and after by adding and editing products in VM BE and watching DB as well as VM BE and FE.
Following VM development almost since very beginning I never trusted it after several tries because it didn't perform real realiable calculations in every version. I have tendency to assume being simply to old and to stupid to understand it.
For me it's similar like being dependant on auto values for primary keys in DB tables - this has never been and is not really reliable in each and every case, no matter which DB you use as backend. I'm simply tired of slowing down and blow up DB in multiuser environments using "tricks" like adding a datetime field in each row. My code calculates values for keys for itself in case of need and it's output is reproducable and storage in DB can be tested during runtime. Always. In case there is no error when storing data I can calculate reliable and reproducable values of real important data. With auto values it might happen values in another row are changed when application's FE and/or BE are fast enough or DB is under heavy load or ... .
Remark for those not believing last paragraph:
mySQL mentions such problems somewhere in documentation. Google might be your friend.
Quote from: Milbo on October 16, 2019, 19:32:12 PM
if there is no tax, we do not have a baseprice with tax.
I'd say that, mathematically, baseprice + 0 (no tax) = baseprice.
Or maybe it would be a good idea to not see it in the order if there is no tax, otherwise it is confusing.