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
Related
I can get bid and ask data from my market data provider but I want to convert this in OHLC values.
What is the good calculation using bid/ask? I saw in a post that for a specific period:
Open = (first bid + first ask) / 2.
High = Highest bid
Low = Lower ask
Close = (last bid + last ask) / 2
Is it true?
You are getting confused with terminology. In forex:
Ask is the price that you, the trader, can currently buy at.
Bid is the price that you, the trader, can currently sell at.
OHLC are historical prices for a predetermined period of time (common time periods at 1 min, 5 min, 15 min, 30 min, 1 hour, 4 hour, daily and weekly) and are usually used to plot candle stick charts (and tend to be based on the Bid price only).
Open - This is the bid price at the commencement of the time period.
High - This is the highest bid price that was quoted during the time period.
Low - This is the lowest bid price that was quoted during the time period
Close - This is the last bid price at the end of the time period.
Conversion between the two is not always straightforward or even possible. What many beginners (including myself) stumble upon:
Ohlc data represents trades that did actually happen. Bid and ask represent requests for trades that might never happen.
Simplified example:
Let's say investor A wants to sell 100 shares of a specific company for 20$ each, so he places ask(100,20) on the market. Investor B wants to buy 100 shares of the same company, but only wants to pay 18$ each, so he places bid(100,18).
If both are not willing to change their price, no trade will happen and no ohlc data will be generated (if no other trades occur in this timeframe).
Of course, one can assume that if trades happen in a specific time frame, h will be the highest price someone is willing to pay (highest bid) and l will be the lowest price someone is willing to sell for (lowest ask), as those orders have the highest chance of being met. But I think o and c values really depend on which bids/asks actually turned into a trade.
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.
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.
when we credit memo an order the reward points are not being removed – is there a way to set this so it does remove the points when a credit is processed?
Thanks
You will need to deal with the reward points manually since there is no way to have this work automatically. The customer may already have used the credit points by the time of your refund.