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.
Related
We are exporting Magento orders to another platform and have noticed what seems to be a major issue in the tax calculation; hoping you guys can help..
enter image description here
In the example above; we have a shipping fee £6.95 (inc tax), a discount £5.80 and a product sales price of £116 (inc tax).
Total Inc. Tax is correct:
(£116 + £6.95) - (£5.80) = £117.15.
The Tax charged however is showing as £19.53 which I just can't replicate..
I've tried:
20% of £116 = £23.2
20% of £116 - £5.80 = £22.04
No permutation seems to deliver amount of tax charged that Magento is stating: £19.53
Can anyone shed some light on this for me?
Thanks in advance..
These figures are tax inclusive:
So convert them to tax exclusive by dividing by 1.2.
96.667
5.792
-4.833
Now that adds up to 97.625. 20% of that is 19.525 which needs to be rounded up to 19.53. The government wants all the half pence amounts!
The original tax inclusive amounts added to 117.15 so subtract the tax and you get a pre-tax amount of 97.62.
I am trying to generate a credit memo i have two question.
Whenever i try to create credit memo by pressing refund offline button it show error lik e"Maximum amount available to refund is $XXX" no matter what i fill in.![enter image description here][1]
What is the difference between adjustment refund and adjustment fee. All i understand is if we want to deduct some amount as processing fee we can write under adjustment refund then that amount will get deducted from total paid. But what is then refund adjustment for??
Attached screen shot
1. "https://imageshack.com/i/nhs8s7p"
2. "http://imageshack.com/a/img534/8696/3t2e.png"
Adjustment Refund: Amount to be added on the total amount refunded.
Adjustment Fee: Amount to be subtracted from the total amount refunded.
Take example your customer bought 2 chocolate each costing $5. However he/she wants to return one. In that case you have to return $5 which is correct mathematically (and this is what default magneto calculation shows you). But, you can change mind as business man, like
If you feel to giving return $6, write $1 in Adjustment Refund.
If you feel to give return $4, write $1 in Adjustment Fee.
"Maximum amount available to refund is $XXX" means you can not refund more than $10. In above example, you can not write more than $5 in Adjustment Refund.
Make sense? If yes, please mark answer as accepted.
Thanks
I will create a list of products that I wish to buy. Let's say they are all given a unique reference code. I have a list of suppliers I can buy from and for convenience each supplier uses the same reference code for each product.
Some suppliers charge shipping. Others only charge shipping if you spend less than a certain amount. Some suppliers discount certain products if you buy them more than once but there may be restrictions (such as by 1 get 1 free).
It is extremely easy to take the list of products I want to buy and tally up the total it would cost to buy all of them from each supplier. What I want to do though is create a script to work out whether it would be better to split the order.
For example:
Retailer A charges:
Product A - £5
Product B - £10
Product C - £10
Product D - £10
Shipping - £5
Retailer B charges:
Product A - £5
Product B - £12
Product C - £12
Product D - £30
Shipping - £5 - free if spending £20 or more
In this case, if I wanted to buy Product C only, the cheapest would be from retailer A.
If I wanted to buy:
1x Product A
2x Product B
1x Product D
The cheapest would be retailer B (because of the free delivery) for products A and B and to then split the order and purchase product D from retailer A (as the price even with delivery is significantly lower even with delivery included).
So in my head it's not a complex task and I can work it out very easily on paper. The question is, how I would translate this into code. I'm not looking for the code to do it - just some guidance on the theory of how to implement it.
If we restrict the problem to simply choosing which vendor to buy each product from, and you get a vendor-dependent reduction in shipping cost if you spend a vendor-dependent amount, then you can formulate your problem as an integer linear program (IP or ILP), which is a good strategy for problems suspected to be NP-hard because there has been a lot of research and software packages developed that try to solve ILP fast in practice. You can read about linear programming and ILP online. An ILP problem instance has variables, linear constraints on the variables, and a linear objective you want to minimize or maximize. Here's the ILP set up for your problem:
For each product that a vendor sells, you have one vendor-product variable that tells how many of the product you will purchase from the vendor. For each of these variables you have a constraint that the variable must be >= 0. For each product you wish to buy, you have a constraint that the sum of all the vendor-product variables for that product must equal the total number of the product that you wish to buy.
Then for each vendor that offers a shipping discount, you have a shipping discount variable which will be either 0 if you don't get the discount, or 1 if you do. For each one of these shipping discount variables, you have constraints that the variable must be >=0 and <= 1; you also have a constraint that says when you multiply each vendor-product variable for the vendor by the vendor's price for that product, and add it all up for the vendor (so you get the total amount you are spending at the vendor), this amount is >= the vendor's shipping discount variable multiplied by the vendor's minimum amount you need to spend to get the discount.
You also have for each vendor a vendor variable which is 1 if you use the vendor, and 0 if you don't. For each of these vendor variables A, you have constraints 1 >= A > =0 and also for each vendor-product variable B for the vendor, you have a constraint A >= B/N, where N is the total number of items you want to buy.
Finally the objective you want to maximize is made by multiplying each vendor-product variable by the vendor's price for that product, adding it all up (call this part of the objective X), and then multiplying each vendor's shipping discount variable by the shipping cost reduction you get if you get the discount, adding it all up (call this part of the objective Y), and multiplying each vendor variable by the vendor's undiscounted shipping cost, adding it all up (call this part of the objective Z) then your objective is simply to minimize X - Y + Z. This is all you need to define the ILP, then you can feed it into an ILP solver and hopefully get a solution quickly.
Mixed Integer Linear Programming is ok for your problem.
You can use a free solver such as Coin Clp. If you want to know about commercial MILP solver performances, you can find some benchmarks there : http://plato.asu.edu/bench.html.
If you want to have a rough idea of the time required to solve your problem, you can run your problem on NEOS Server : http://www.neos-server.org/neos/.
When you have a lot of 0-1 variable, you can also contemplate to use Constraint Programming which often suits better for heavy combinatorial problems.
Both MILP and CP algorithms use branch and bound technique, which is faster than naive enumeration.
Cheers
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.
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.