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.
Related
I have an issue right now and I believe many people might have this issue I am wondering if someone has found a work around so my issue is I have products that I buy stock for on a daily basis due to excahnge rate and other things the same product sometimes costs me different every time so my issue is,
If I have a Samsung watch I have 5 units in stock that cost me £35 Then I see a good deal on them and buy another 10 units these cost me £30 but I still have the 5 units in stock that cost me £35 so how can I upload/update the 10 units making 15 units in total but have a seperate cost price for the 10 units compared to the 5 units as I need this for reporting profit and loss reports.
So Ideally I want to be able to update my stock qty each time I do so I need to set a new cost price for that same product for selected amount of qtys,
Right now I am currently making the same product/SKU Multiple times because the product is the same but has cost me multiple by prices and I do not want to not have it listed for sale until the other stock sells and I do not want to keep making multiple products as customers think the products are different..
Any help will be strongly appriciated!
Have you check Tire Price concept in magento ?
I think this will full fill your requirement.
Let me know if you have any query.
there's 3 types of items in our clothing web store (magento 2.3.1),
there are:
A) Bottoms
B) Tops
C) Sets (both a bottom and a top)
All of which come in different colors and sizes.
I'd love to know how set our products up, so far I thought of 2 scenarios:
Scenario 1)
Set the bottoms (A) and tops (B) as configurable products (add the color and size properties), and set the sets (C) as bundle products, then add A and B's as related products inside C.
That will allow the stock to be deducted when someone i.e only buys a top, so that the user can't buy the bundle if there are no more tops.
Scenario 2)
Set the sets (C) as a configurable product (add the color and size properties), but also add an extra property, on which they can select wether they want to only buy the bottom, only the top, or both (sets).
I like that scenario more, but if I do that, I run the risk of someone purchasing a set, when i.e there's no top in our stock (because people bought more tops for example, and no bottoms).
What would be the right way to deal with that issue? Any ideas would be appreciated.
Thank you
It all depends on your business model.
As I understand from what you wrote, you would like to sell tops and bottoms individually and also in sets.
Maybe the cleanest would be if you just create a bundle product for sets and allow people to not select either top or bottom.
Also with that, it would be okay if you show the individual products for bottoms and tops.
I'm making a shop with clothing. But there is a minimal order amount per order. Now i want to have a choice that the customer can make with different sizes.
So the minimal count is 10 pieces, and if a customer wants 4 size M, 5 size L and 1 size XL. what is the easiest way in code that i can accomplish this?
I'm using simple products associated with configurable products.
Maybe this could help :)
How to get the Total Quantity Of All the Items In your Shopping Cart
Given a list of products available in the store, i need to select set of products to my cart in such a way that, my cart value should be maximum it can.
Restrictions are like, cart has a dimension l*w*h. Products selected should individually and totally fit into the cart giving maximum possible value to cart. One 1 item per product can be selected.
I have product id, price, l, w, ht, weight of each product with me. How can this be accomplished???
I came up with a logic as below.
Calculate volume of the cart
Calculate volume of product and value of product per cubic cm using its price
Sort the product list based on value/cucm
Start adding products from the sorted list like 1st, 2nd , 3rd, etc. till the cart gets filled.
If a product cannot fit into the cart, skip it and select the next possible product from the sorted list.
Once list is obtained, check if any product in the selected list can be replaced with another product with less volume but results in more cart value.
But this is not getting me the correct product list with maximum cart value. What is the problem in the above logic?
Are the three dimensions integer valued with some finite bound ? Then it can be solved with dynamic programming. But I think there should some assumptions made, e.g. the partition of sub-problems should be end-to-end cutting planes etc. Without that dynamic programming would be infeasible.
The key trick here is that you need to account for possibilities that a box can be oriented in several ways, and it is the number of ways to align its own three dimensions along the three axes of the cart. It is 3! = 6 for three dimensions. So in the dynamic programming when you process the i-th product, include all the 6 ways interpret its 3 dimensions as L,W,H.
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.