I have a theory / design question, but it is not for PHP. I have had this same problem with just about every e-commerce site I build. Let's say I'm building a shoe store. My shoe store sells shoes from 20 different manufacturers. Every manufacturer has their own way of building product skus and how they relate to their different sizes/colors. Some assign every color and every size to its own sku. Some assign a base sku, and then an attribute with the color/size. So, to make everything consistent, I assign every color and every size to its own internal SKU (our own product number). This works great to get everything consistent, but it makes attribute selection difficult.
Let's say I have a shoe size 5 and it is yellow. The other options are sizes 1-10 and colors red, orange, and blue. Every combination of these has its own product sku. I need to have two drop-downs with all colors and all sizes, and when I click "add to cart" it needs to find the correct sku and add it to the cart. This sounds easy, but whenever I try and think of how to do it, I'm stuck. I don't really want to limit my skus to any sort of naming convention since I plan on releasing this solution as a module/plugin to the commerce package I'm using. Thanks for reading.
how to related size/color to sku - theory/design question
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I have found that I have to, unfortunately, do both. I assign a SKU to every "thing" that can be purchased. That usually includes every color/size having its own SKU. This is because the SKU both a stock keeping unit and a purchasable unit -- so it has to do double duty. In addition I create a record for a "base sku" because that contains the displayable information about the item. The "base sku" is what the product is referred to as. The specific SKUs are variations with specific qualities.
I often separate the "base sku" out to what I usually call a category table. It contains the hierarchical records that define the product catalog. The topmost nodes have no parent. The bottom most nodes are marked as "base skus". That table is really all content stuff related to selling the products.
When you get down to a point where the user can actually purchase an item, most of the presentation stuff comes from the category table -- except the list of specfiv SKUs data. I usually create a Model class for each general product type. It fetches the base record and all the SKUs that have that "base sku" as their parent. The Model then provide the general data to the View, plus what is available, not-available, back-ordered, inventory, whatever.
I often separate the "base sku" out to what I usually call a category table. It contains the hierarchical records that define the product catalog. The topmost nodes have no parent. The bottom most nodes are marked as "base skus". That table is really all content stuff related to selling the products.
When you get down to a point where the user can actually purchase an item, most of the presentation stuff comes from the category table -- except the list of specfiv SKUs data. I usually create a Model class for each general product type. It fetches the base record and all the SKUs that have that "base sku" as their parent. The Model then provide the general data to the View, plus what is available, not-available, back-ordered, inventory, whatever.
(#10850)
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Re: how to related size/color to sku - theory/design questio
Could it build it if it can't find it? Then you can make sku's up as needed and use what is already created. Or am I totally not seeing the bigger picture of what you want to accomplish?The Ninja Space Goat wrote:it needs to find the correct sku and add it to the cart
@arborint - I don't think there is really any way around that, is there? The problem is that I don't have 100% freedom within my development system. I have to follow a lot of rules since I'm working in mivascript. I'm going to try and implement something like what you are talking about within this system though. I just need to sit and think a while. Thanks!
@Everah - we have been using sort of a hack to "build" the final sku number. It works, but it isn't scalable. I'd like to be able to resell the solution to the community as a plugin/module and it would be pretty restricting to end-users to have to conform their product skus to fit my module.
@Everah - we have been using sort of a hack to "build" the final sku number. It works, but it isn't scalable. I'd like to be able to resell the solution to the community as a plugin/module and it would be pretty restricting to end-users to have to conform their product skus to fit my module.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Maybe stop thinking SKUs and start thinking search by property/value pairs instead. If each product has a primary key in your product table, use that as a "shortcut search" once you've identified the product.
i.e. get the product as "type: shoe / style: fluffy / color: pink / size: 5"
That will return a whole product object / array, which includes a PK called "ninjaSKU" (among other properties, like mfgr SKU)
Then you can refer to it by it's PK like so: "ninjaSKU: 51235"
i.e. get the product as "type: shoe / style: fluffy / color: pink / size: 5"
That will return a whole product object / array, which includes a PK called "ninjaSKU" (among other properties, like mfgr SKU)
Then you can refer to it by it's PK like so: "ninjaSKU: 51235"