I have a customer who retails third party batteries, and some batteries can replace several OEM models.
For instance, 3rd party SKU 12345 may replace Toshiba N23 and HP 53214, thus my customer would like to create two products with the same SKU in front end (they are essentially the same product). However, Magento by default does not allow duplicated SKU.
My current solution is to set SKU to not required from the backend, and add another attribute called Model that allows duplicated values, and display the Model in front end.
Is there a better way to do this? Or is it possible to allow duplicated SKU?
Tian Bo
Noble Technologies
It sounds to me like you've found a good solution. I'm not so sure you should try to have duplicate values for SKU for two reasons.
First the whole point of SKU is that it is a unique identifier. That's its only reason for existing. If you're going to have duplicate values, then it's not a unique identifier; it's just another attribute. But of course Magento still needs a unique identifier to work, which means that this is an extra field, which takes us exactly where you are now.
That said we come to my second point which is this... I'm not exactly a Magento guru, but I've built my share of e-commerce sites and one thing I've learned is that they depend on certain unbreakable rules to work properly. One of them is that unique identifiers are unique, both on the database and application level. As such, a large part of the website depends on this to function correctly. Which I'm pretty sure goes for Magento too.
So trying to change such a basic premise in something so complicated will only lead to horrors and a slow descent into madness.
This sounds like a good solution that I extended a bit further, however what I did with multiple store was to create a visible attribute ITEM_SKU (Item SKU) - make it visible and searchable and then concatenate the store_id to Magneto SKU to make it unique.
So SKU becomes (Store_id "-" SKU).
It surprises me how often people are willing to break who-knows-what parts of Magento, just to get a specific piece working how they expect.
The proper way to allow for duplicate skus is NOT to (unless you'd like to re-write large parts of the framework). You CAN, however, add a custom attribute to products that shares all the same settings as "sku" minus the setting that requires values to be unique.
Changing product pages, emails, etc to show this value instead will require a little extra work but will save you headaches later.
Why don't you create 1 product (SKU 12345) and list this product in multiple categories. So your multiple categories will be Toshiba and HP. The same product (SKU 12345) will be listed in Toshiba and HP.
Related
I have an e-commerce site that provides made-to-order clothing. I've created a configurable product and just one associated product.
Is it possible to display all of the possible attribute combinations within just one associated product rather than manually add every combination?
I've tried allowing out of stock products to be displayed, but this didn't show all of the possible combinations.
I'm not hugely experienced with Magento, but I've used many CMS systems and inventory management products. I've never once seen a matrix / configurable / multi-variation / whatever you want to call it setup where you didn't have to create each combination as a distinct SKU. I'm not saying it's 100% impossible, but I'd view it as extremely unlikely and probably a waste of time to pursue.
Why not just create your configurable products and their sub SKUs via CSV import? It will be far easier and faster than creating them one at a time. Creating every combination will also be extremely easy. If you're not comfortable with Excel, you need to correct that yesterday if you want to be good at product management.
See this article:
https://www.siteground.com/tutorials/magento/import-products.htm
I've started working on a new Magento webshop which has roughly 250000 different products. Each product can have different conditions (new, used, damaged, etc., each with their own price.). Magento doesn't seem to have a method to implement this at the moment. Of those 250000 products, there are about 150000 different conditions in stock and another 150000 conditions which aren't in stock but do have a price (which can be put on the wishlist).
Some numbers: 1500 categories, drop down attributes (country) with > 300 options, integer attributes (year). Starting with two websites 6 languages each.
I've thought out two solutions to solve this problem:
Grouped / Simple product structure
We create a grouped product which is the container product, each condition will be a different simple product. We'll relate these products to the grouped product.
The nice thing about this solution is that is pretty easy to implement, we'll have to import the data in the correct way and all the information is exactly presented in the way we want.
New Product type
We create a new product type which can have multiple conditions, each with their own inventory. On checkout the inventory is substracted. The problem with this is that implementing the CatalogInventory model in this way probably is difficult and building a whole product type is time consuming and bugprone in general.
The advantage of this solution is this that there will be about 2-2.5x times less products in the system.
Others
Are there any other options to solve this? Maybe there is a module that does all this?
In conclusion: Of course I prefer the first solution but can Magento handle that? Does anyone have experience with this much Grouped Products? The system will have about 550000 products (grouped + simple) products in the system, what will be the performance implications of this? What happens when the site grows and we'll have twice the amount of products?
Without knowing more details I'd lean towards using a new product type or just adding the feature independently of product types if you have a use for configurable products (I definitely wouldn't try to duplicate the configurable product type). I'd disable inventory management and use some additional tables which hold individual item inventory with the per-item conditions and maintain a separate inventory that way. Use events and overrides to control the CatalogInventory stock status as needed. Creating new products constantly which are largely duplicates seems like a hassle worth avoiding if this is a long-term endeavor that needs to scale.
However, the Grouped/Simple method might be a viable short-term solution and appropriate if the project is in it's early stages and can't afford a huge initial expenditure. If well-planned, a script should be able to convert all of the old grouped/simple products into your new product type when ready to launch.
I understand how to programmatically create a product and also add to cart. I know this might sound dumb but is it is possible to generate a product on the fly and add that to the cart/quote but never actually save it in the database.
We want to create a made to order interface and I was thinking at the end it could add a bundle product with all the selections but that bundle product wouldn't actually exist in the backend.
I figured as long as you can make sure the quote and order has what it needs in terms of the product it would be ok, but obviously there is probably a lot that is tied to looking up stuff in the db on a specific sku or ID. I know that if you delete a product and then look at an order in the admin that causes issues, at least it did for this one scenario I was dealing with.
I was thinking of creating a giant bundle product that had like 6 different bundle items and each item could potentially have like 500 products and then based on what the user selects I programmatically add the bundle to cart. But then I wasn't sure if there would be a negative affect with having a gigantic bundle product like that as well.
UPDATE:
I don't think this will work, obviously there are a lot of information tied to the product in the database and we setup a test and right away we get an error for $item->getProduct(). We are moving forward with creating a giant bundle product and also the generic product with adding custom options on the fly, which Anda pointed out below. Any other suggestions will be greatly appreciated.
I'm not sure that clockworkgeek's approach is going to work. On every page load, Magento loads the items from the cart to make sure that they are still valid (in-stock, prices correct, etc), and amends the cart to reflect those values. My understanding of the system in the past has been that a product in the cart needs to have a corresponding database value to survive this process.
The "giant bundle product" approach is a pain, but in the past has been the best approach I have found. Attempting to change the values of the product (such as price or attributes) will be overridden by the cart checks, so you need a product w/ maximal flexibility, such as an overly-customized bundle product or configurable product.
Hope that helps!
Thanks,
Joe
Why not create a generic product in db and then set the product customization as custom options (additional_options) on the fly depending on the user selection. You can add custom options to the product (actually to the quote item) without having to save them in the database. I did this once for a website that sells glasses with prescription. The prescription was added as an option.
You can programmatically create Mage_Sales_Model_Quote_Items and add them to the cart. You've noticed it needs a product to match it's product ID but it needn't be a useful one. It could be a blank, disabled product, also created in code. All that's needed is a stub.
The necessary stuff for the cart is stored in the quote item - fields like name, value and quantity. Those fields are then copied directly to the order without using a product.
Mage::getModel('catalog/product')
creates a new product. you can add it to a cart, by doing something like this:
$cart = Mage::getSingleton('checkout/cart');
$product = Mage::getModel('catalog/product')
->setStoreId($storeid)
->setTypeId($type_id)
->setQty($quantyty)
->setWhatAttributYouWant($attribute);
$cart->addProduct($product);
product attributes you can find in the DB in tables that start like catalog_product_... or take an already created product, and see what attributes it has in the _data array (with debugger or just print_r($product->getData))
I have an e-commerce website where it is necessary to make a number of associations e.g. a product needs a category, manufacturer, associated products, etc.
When there is only a fairly small, limited amount of data e.g. Manufacturer I simple use a drop down or option boxes for the user to pick the relevent field / fields.
However for items such as associated products, where I have thousands or products it is not viable to use one of these methods. At the moment I use a searchable / paged table that the user then clicks a button to add the association, this works, but it is pretty time consuming for the user and not what I would consider an ideal solution to the problem.
Has anyone implemented a solution to this problem or could they offer any advice as to how they would come at this from a UI standpoint?
Thanks for any help you can be
The solutions I can think of are:
Auto-complete
Recent associations
Smart associations
There may be more depending on exactly what you're doing, so feel free to add more details or screenshots and I'll think on it more.
Auto-complete
Using an auto-complete field would speed up the process for your users since they wouldn't have to hunt through the table for the association. Rather they could just start typing and have a suggest box appear below the field that allowed them to select what they're looking for.
If you matched your auto-complete on several key fields (i.e. manufacturer and product name), there's a pretty good chance that the user would be able to find the association quickly.
You could also code the suggestion box in such a way that it showed multiple pieces of key data. That way if the user wasn't quite sure what they were looking for, typing a few characters in the field would give them an idea of what they could search with.
Recent Associations
Below your auto-complete field, you could add the 5 to 10 most recent associations that had been made. That would allow your users to quickly add many products to the same association without having to use the auto-complete each time.
Smart Associations
Separate from the above two mechanisms, a smart association is something I first saw when theming a Shopify store. They allow you to automatically create associations based on the products key fields by defining conditions to include or exclude products:
Create Association 'Pants'
Where product title contains string 'pants' or
Where product title contains string 'capri'
The above is controlled by a set of dropdowns and textfields and got around the pain of manually creating associations.
I have a situation:
I have products that are in a CodeIgniter Cart custom store.
Each product has an ID associated with it, but also has options for it (sizes).
These sizes all have different prices. (We're talking about photos being sold at different print sizes).
Because CI Cart updates, adds and deletes based on the product ID inserted, I am not able to insert one product with 2 different sizes.
As of now, the only solution I can think of is to pass the ID to the cart as IMAGEID_OPTIONID so that it contains both IDs.
However, I thought there might be an easier, more uniform way of doing this?
Or a better solution than an ID that isn't (on it's own) associated with anything specific unless i explode it..?
I recently built a site that had these constraints. In short, you'll want to create a distinction between "products" and "product groups". Think of it as managing the most discrete data units. In reality, shirt X sized medium is actually a different thing than shirt X sized large...doubly so if you have prices that are built on these qualities (this becomes more realistic when you consider cloth patterns or colors).
So anyway, if you have a "groups" table, a "product_groups" table, and a "products" table, you can keep all of these ideas distinct. On your products table, you can have columns for "size" and "color" (and any other distinguishing property you can think of) and a column for "price". Alternatively, you can go even more hardcore and make separate pricing tables that match up prices to unique products (this would be especially useful if you want to keep track of historical prices and discounts).
Then in your cart you can simply attach product_ids to cart_ids and perform a couple of joins to determine what "group" this product is a part of, what pictures are in that group (or exist for that product), and so on. It's not a simple problem, but following this line of thought should help get you on the right path.
One last point: keeping track of unique products like this also makes inventory accounting much, much more straightforward.