How can I apply only the highest discount rule under customer cart?
Imagine 2 rules, one with 10% and another one with 15%.
When the customer goes to the cart, he needs to receive 15% of discount.
Is it possible?
Please note that I would not like to consider the rule priority. I would like to guarantee that the customer will always receive the best promotion.
Related
I'm trying to program a simple FIFO (Price/Time Priority) order matching program, but I'm not too sure if I've got the logic correct:
for each unfilled buy order (newest first):
filter orders by buy price > sell price
while buy order not filled:
fill best priced sell order
if multiple equal cheapest sell orders:
fill oldest
if remainder of most recently filled sell order is not 0:
create new sell order for remainder
I've run this on a simulation of 500 buy and sell orders respectively, but to be honest don't have a reference to check whether it's matched orders appropriately - and trying to run through the transactions by hand would be incredibly time consuming. Can anyone confirm I've got this right?
Does anyone know what algorithm Paypal uses to round? I'm doing some testing with discount promo codes on my site, and I'm coming up with different totals than what Paypal comes up with when I pass the same discount amount using the "discount_rate_cart" variable.
For example, a couple of items on my site total $309.95. Applying a 10% discount ( 309.95 * .9 = 278.955) should yield a total of $278.96, as .955 should round up to .96. However, when I pass the total $309.95 and the 10% discount to PayPal, they come up with a total of $278.95. They rounded down when they should have rounded up.
Does anybody know why this is happening? Please note, I'm not doing anything fancy like currency conversion here, just simple algebra for giving discounts on the total cost of the shopping cart.
So the algorithm is banking rounding but on a transaction by transaction basis. This means the discount is a transaction of its ow e.g.
10% of $309.95 is $30.995 and bank rounding is to the nearest even number being $31.00.
Therefore:
$309.95
-$ 31.00
========
$278.95
So theoretically if you had a discount of $30.987 this will round to $30.98 not $30.99.
Today I was studying how Magento tax calculation works to understand the difference between the behaviors for "Tax Calculation Method Based On".
I traced deep into Mage_Tax_Model_Sales_Total_Quote_Tax which implements all methods in the _unitBaseCalculation, _rowBaseCalculation, _totalBaseCalculation.
I discovered that they produce exactly the same results. So why did they go through the trouble of implementing them ?
For example, unit-price calculation goes to the trouble of calculating the tax for the single unit and then dividing the discount amount by the qty (if tax applied after discount), then subtracting both, and then multiplying again by the quantity... which just introduces rounding errors.
Whereas Row Total calculation is the most intuitive one (which takes the price from the row "subtotal") minus discount amount (if tax applied after discount).
While the third one is just an aggregation of the second, calculated at once.
This just introduces confusion and obfuscation to the tax calculation logic. Can anyone shed a light onto why this was done ?
(Rounding errors ? Backward compatibility ? Candidate for TheDailyWTF prize ?)
EDIT: For the record this is true as of Magento 1.6 and 1.7, don't know about older versions.
I found this from: https://gist.github.com/2572772 (by Alan Storm it seems)
This feature was probably motivated by individual local rules (or client requests) as to how taxes should be calculated, as fractional amounts could add up differently depending on when adding and rounding occurs. THat said, I haven't run through the code to see if my guesses are right so YMMV. Other areas to consider for future research.
How does each mode play with shopping cart price rules and store wide discounts
For shopping cart price rules, it goes through painstaking trouble to divide the discount amount (which may not be divisible by the quote item quantity thus introducing a rounding error) so that the end result is the actually the same process, but only with different "when"s and "where"s as to rounding.
Here is the scenario. I have a configurable product which has two attributes. However, the price increment for the second attribute is dependent on the first. The price increments are a combination of fixed and percentage. So, lets assume the two attributes in question are size and colour - the amount added on for larger sizes is fixed, but the amount added on for different colours is a percentage.
The issue is that magento is adding the percentage increment for colour to the base price, not to the price plus the fixed increment for size.
As an example, let assume my product is available in three sizes, small medium and large; and in three colours, red, green and blue. The increment for medium and large are £5 and £10 respectively, and the increment for colour is 5% for green and 10% for blue (to be applied dependent on the size selected). My product has a base price of £100.
A customer purchasing a medium red product would pay £105, however magento applies the same price to a customer purchasing a medium blue product (because the percentage increase is calculated BEFORE the size is selected).
Is there any way to handle this so that the correct percentage increase is calculated AFTER the size is selected?
Cheers
Simon
Generally I do not like to recommend this extension as it makes pricing in Magneto way more complicated and time consuming (I just got out of it myself and it was not the fault of the module), but I think this might be the solution for you:
http://www.magentocommerce.com/magento-connect/simple-configurable-products.html
Basically this modifies the way Configurable products are priced so that it uses the price of the simple product and not the values contained in the super attributes.
The upside is that the price of the simple product is the price that it will be sold for on the configurable page.
The downside is that it is very easy to have the website do some funky things with pricing if you are not careful. For example we had a lot of scenarios where the configurable product price was $10.00, but all the simple products price was $8. Each item in the dropdown had a "negative upcharge" in there.
This was not the modules fault, rather carelessness of people managing the products.
I have setup a shopping cart price rule of 10%. If I add a product value 33.95 in the cart and apply that rule, it shows discount of 3.40 which is suppose to be 3.39. I am assuming its rounding up to 2 digit and may be needs changing to 3 digit (I'm assuming this) but don't know where to make this change.
Welcome to the world of rounding errors in Magento.
Usually, it is not a cause for major concern, as the cart total is correct; but the row level items are calculated wrong. This also effects the admin order display and invoice PDFs.
Different versions have different rounding bugs, there isn't a fix in the strictest sense, we just patch them as we go along.