Page 1 of 1
how to related size/color to sku - theory/design question
Posted: Mon May 21, 2007 12:27 pm
by Luke
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.
Posted: Mon May 21, 2007 3:10 pm
by Christopher
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.
Re: how to related size/color to sku - theory/design questio
Posted: Mon May 21, 2007 4:25 pm
by RobertGonzalez
The Ninja Space Goat wrote:it needs to find the correct sku and add it to the cart
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?
Posted: Mon May 21, 2007 5:12 pm
by Luke
@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.
Posted: Mon May 21, 2007 5:15 pm
by RobertGonzalez
I see. Sorry I can't be of more help. My brain is not working well at the moment.
Posted: Mon May 21, 2007 5:26 pm
by Luke
No problem, I seem to be having the same problem today.

Posted: Tue May 22, 2007 1:29 am
by Kieran Huggins
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"
Posted: Wed Jun 13, 2007 12:25 am
by Luke
now that I've had more time to think about this, you're absolutely right. people wouldn't have to conform to any kind of product sku. They could make up their own skus, I'd just have my own as well. And like kieran said, I'd just have to look the product up by it's properties. hmm...