All I have an issue with pricing on a product variant. Price per UoM = 2.56 Qty = 24 markup = 1.23 (23%)
Desired setup 2.56 * 1.23 = 3.1488 = rounded to 3.15 <--- UoM price 3.15 * 24 = 75.60 <-- Variant price, divides to UoM price Basically the issue is that the industry knows the cost per UoM, how ever widgets are sold in various lengths and the variants does everything but pricing perfectly. Customer divides price by UoM and gets 3.1488 which is correct but not what they thought was the price. What is actually happening 2.56 * 24 = 61.44 <-- the product variant price 61.44 * 1.23 = 75.5712 <-- 3 cents off, and if customer divides this by UoM it gives them a close but not real price per UoM. I understand the math involved and that some would not see this as a problem as the math is correct but is an issue of rounding in a certain spot, however it is in this case. Would this be solved best with a configurable pricing system much like the tax setup where basic math is available and then optional python code Andrew -- --- Andrew Latham - AKA: LATHAMA (lay-th-ham-eh) [EMAIL PROTECTED] - [EMAIL PROTECTED] If any of the above are down we have bigger problems than my email! Hind sight is most always 20/20 or better. --- _______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman/listinfo/tinyerp-users
