Do products need a SKU?
Alrighty, I'm trying to summarize a discussion that occurred in IRC today surrounding the need / name for the SKU on products. We talked about this in our San Francisco sprint last October, but I didn't recall reaching a conclusion away from SKUs. In fact, our white board picture and various blog posts and threads on the product specification presume a SKU field as an essential part of the product entity. This hasn't been challenged thus far, and I still want to contend for its inclusion and acceptance based on some observations below. That said, these issues bear further consideration and will serve to more clearly define what a product will be.
First, let me say that I accept that SKU is a bit of a misnomer. Technically it stands for "Stock Keeping Unit", but not everything people have sold with Ubercart or will sell with Drupal Commerce has a stock value in the traditional sense. In those cases, it's more like a sales tracking value than a stock keeping unit, but I'm comfortable with this "outside the box" use for the SKU for reasons outlined below.
Ok, so the basics. What is a SKU? It is a unique, alphanumeric, merchant-defined identifier for the product. Its primary purpose is as a human readable product identifier that's at the same time concise and meaningful. It will be used for product searching / entry, displayed on product pages and order displays if desired, used in reports, and used for various stock tracking and picking applications. I'm guessing this value will be used in other ways, too.
One question is why not just use the $product->product_id? We do in fact have a serial numeric ID for products in addition to the unique SKU. Do we need this? I think so, and that's because a numeric value isn't very meaningful. Someone may in fact have a small number of products for sale and just end up using this numeric value, but it's insufficient for sites with a large number of products. It also doesn't convey any sort of relation between products, like SKUs with minor adjustments for various attributes (the regular example being TSHIRT-S, TSHIRT-M, TSHIRT-L).
Ok, so why not use the product title for differentiation? Here I believe this fails to be concise and will not communicate differentiation. When selling the same product with 5 different size values, the title will be the same with the size field having different values. But lest I be seen as exaggerating this point, it still could work, but whatever solution we cook up wouldn't be concise and could be liable to multilingual confusion.
Now, here's the kicker, and it's inspired by the fact that Magento uses the SKU field explicitly as "as a unique identifier for this product, across all stores and websites." I want to assume people will have multi-site stores, and the SKU will be constant for the merchant across all web properties as in Magento. What might not be constant is the title (multilingual, marketing segmentation, etc.) or the internal $product->product_id. Having a short alias for the specific product will be very beneficial here, but making SKUs optional and trying to support things like multi-site based on product_ids will lead to difficulty.
So, why not keep the SKU but name it something else? We may in fact be able to find something that more closely captures the meaning of the field... like "Product ID Alias" or "Short Product Name". But those have their own confusion level and aren't readily familiar to anyone. Furthermore, for situations where this field functions as a SKU, it won't be intuitive that this is indeed the stock keeping unit.
I understand that there are concerns with how well SKU will be understood internationally, but as I pointed out in IRC, the GoodRelations RDF Ontology for e-commerce is comfortable specifying SKUs and is itself an international document. My hunch is that we could try to find a term that is more "translatable," but in so doing we'll have to completely invest the new term with meaning as opposed to giving millions of people a head start in understanding what we're referring to.
So... to summarize:
- I think keeping the SKU as an essential part of the product as discussed before is a good thing.
- I think defining it for everyone is essential: The SKU is a unique, alphanumeric, merchant-defined value assigned to a product that is concise and meaningful. [This definition should itself become more concise if possible.]
- I think it's worth having this as an assumed part of the product for a variety of reasons related to usability and "codeability."
- I think it's worth maintaining alongside the site specific numeric product_id, but we should implement Tokens and SKU patterns so sites that don't want to bother setting SKUs can default them to some pattern based on the product_id. [Note: this effectively makes SKUs "optional," and a contrib module can easily disable the form element from the product form, or we can introduce a "force pattern" checkbox on product types that doesn't allow individual product SKU overriding.]
- I think it's better to use a term that's used in other systems than to create an original term for this value that we would then have to teach to everyone.
In other words, I don't think there will be a viable alternative to SKUs as currently implemented, but I don't want to dismiss anyone's concerns... I'd rather just define the term and implement it in such a way that concerns are validated and addressed. After screwing this up once ("Model" in Ubercart, later changed to SKU externally while still $product->model internally), I really think sticking with SKU will pay off, especially in relation to other e-commerce systems.
Comments
SKUs
Totally agree, Ryan.
In fact, I'd go so far as to say that not only should SKU be kept in (it is what business owners know and understand), but that it'd be really nice if there was a "recommended replacement by SKU" feature, such that where the e-tailer is out of stock of that SKU, the system can recommend other SKUs. The SKU acts as a shorthand between e-tailer and client when discussing replacements, etc.
And of course alongside SKU, which is the e-tailer's reference, there should be a Supplier SKU; the unique reference from the original manufacturer. That helps the client research further if the manufacturer has a decent website. Likewise, the Supplier SKU may have a replacements table (multiple suppliers supply the same/similar item to the e-tailer).
Keep SKU, keep it required
Like the word "Taxonomy" which also doesn't mean much to about the same percentage of the population who has no idea what a "SKU" is, I advocate calling things what they actually are.
A quick search for sku reveals the Wikipedia page for Stock-keeping unit which will help anyone who's unclear about the terminology.
VS. if you call it "Unique alpha-numeric product ID", then someone who does have that business background will be filing support requests about "Where do I fill in a product SKU?"
So keep the field, keep the name, keep it required. Reduce ambiguity by an improved field description and how-to documentation.
SKU is fundamental
The importance of the SKU in the supply chain cannot be understated. Thinking in terms of scale, the SKU is more than just an identifier for a product - the SKU is a unique identifier for each and every product variant, including bundles and intangibles such as fees, often following a pattern. Looking to the future, I can see Drupal routinely plugging into ERP systems even in small businesses.
That SKU concept is pretty stinking important, allowing flexibility beyond $product->product_id and not locked down to a particular pattern, because business rules change per, well, business. But the availability of a SKU should be a constant -- a starting point to scale any operation.
In short, I love having it required because it future-proofs d7c.
Unneeded
I can understand all of the reasons listed above, and although initially I disagreed with simply the naming, I now I really question if it's needed at all, and here's why.
First, I think we need to ask ourselves how we measure the success of the project. I believe one measurement of success, is how little code must be written to correct the assumptions we make during development. Another measure of success is how intuitive the system. Finally, I think it is important that we provide an easily extensible system that allows us to easily implement contrib modules, and custom features to meet the needs of individual clients.
Next we should discuss the purpose of the SKU. Aside from a simple unique id, a sku also goes a bit farther, in small shops, where the sku can be named something that means something, like your tshirt example above. In other cases, the unique id is regulated by various standards bodies(UPC, EAN, JAN, GTIN).
Additionally, there are many occasions when SKU's are not needed. For many small sites, especially those selling non-physical goods, the SKU is simply another field to populate to create a product. In facet in Ubercart there is a module for disabling the fields that commonly unused, including sku.
With all of this in mind, I believe that there are many ways requirements around something as simple as a unique identifier, and I believe our best option is to provide a system that works for the user who doesn't need a sku, and a system for the person who requires a UPC, EAN, and GTIN. In this case, I think the best thing we can do is not assume someone is going to need a SKU, but provide a system that allows them to easily add the SKU module if needed.
SKU != UPC
A SKU is an internal ID for tracking stock purposes, and has never once been the same as a UPC code at any of the crappy cashier jobs I've ever held. UPC, EAN, etc. fields only make sense for certain types of products, so I totally agree with those being optional.
A SKU, though, is not an "extra" field; it's basically your product's primary key. Exposing this field to users just makes good sense, since the vast majority of people use it. And even if you're selling purely virtual stuff, it's still far more meaningful to have a SKU like "LULLABOT-VIDEO-002" than "24". By all means, have an add-on "SKU auto-populator module" akin to Node Autotitles for those who don't care what this is set to.
I appreciate the effort to not hard-code assumptions, but you're building an online shopping system here. The fact that products are going to have a primary key, and that industry-wide this primary key is called a "SKU", is a pretty safe assumption to make. :)
SKU == Primary Key
I think you hit the nail on the head when you said the SKU is the primary key, however not all users want to specify their primary key. In other cases, users want to use UPC, or other primary keys. In this case I think it's best to leave the Primary key as just that, a primary key, in this case, the product_id field.
In this case though, we are not talking about making the SKU the primary key, the database has a product_id field as a serial, and a product_sku. So we are really making two assumptions. 1, the customer wants a custom unique identifier, and 2, the customer wants that unique ID to be called SKU. That seems kinda silly when we could simply have a SKU field, optionally enabled, or also optionally disabled.
Well, of course you need
Well, of course you need product_id to make joins faster. But the "practical" primary key (i.e. the one that appears on all the reports) makes far more sense being the SKU number.
I still think an optional, token-enabled "SKU auto-populator" module would be a better move here than an optional SKU module. It would ensure external systems (ERP as the above mention) could always rely on the field being there regardless of configuration options, it would help educate newbie store owners about what a SKU field is and why they probably want one even if they haven't thought about it yet, and it would also allow them to set up their own rules on how the field is pre-populated, like [product:product_id]-[node:created]-[node:title] or whatever other silly rules they want.
But best of luck in whatever you guys decide to do! :)
A vote against compulsory SKU
$product->product_id is the primary key, not SKU, correct? Therefore, reasons for making the SKU compulsory centre around your assumptions about the businesses that may use Drupal Commerce. If a business is selling only registrations to an annual conference sure they can make an SKU that is CONF-2010 followed next year by CONF-2011 or even set up a module to do this automatically for them. The real question though is why should they have to? They have no need for an SKU; an automatic and hidden primary key is perfectly adequate for their needs. Making them set up anything for an SKU is unnecessary configuration.
So, I'd propose that Drupal Commerce ship with a compulsory SKU turned on by default, but with a hidden $product->product_id which is the primary key, so instead of the user having to set up how the SKU is populated, it can just be turned off.
Finally, in the interface there should be a single place where if an SKU is being used, the site architect can define how the SKU will be referred to throughout all parts of the interface, both admin-facing and user-facing (e.g. in product creation forms and on the default invoice templates), so a bookstore can always display ISBN-13 instead of SKU, for instance.
Just my 2c. :)
Business key, Technical key
The product_id is a technical key. This is the primary key, its validity scope is the system defining it (here drupal commerce). This is what you'll use to make your sql joins...etc
Users must not know it or see it or use it this is the .
The SKU is a business or natural key. Its scope is wider that the system (here drupal commerce) Theorically any business entity has the unique key that helps identify the same product on different systems/documents/users that communicate with each others.
And i think this even applies to Orders and invoices. These should have the order_id, the primary key plus an order number, which is the one used to print on documents etc
worth looking at
http://www.bcarter.com/intsurr1.htm
http://en.wikipedia.org/wiki/Natural_key
http://en.wikipedia.org/wiki/Surrogate_key
Keep SKU and add UPC, etc
I vote for mandatory SKU with a default autopopulate.
Also, must have a nonmandatory field for Universal Product Code (UPC), European Article Number (EAN), Global Trade Item Number (GTIN) and Australian Product Number (APN) ( http://en.wikipedia.org/wiki/Stock-keeping_unit ) and ISBN.
These are international standards that people have to pay to obtain. In order to sell something retail, you have to have UPC in USA. When they have UPC, etc., that could autopopulate the SKU field. If people have a UPC, etc., they will want to use it as SKU.
It would be great to have ability to generate barcode from UPC, etc in Drupal commerce. http://en.wikipedia.org/wiki/Universal_Product_Code
Don't need a SKU, need a string unique identifier
We don't need a SKU (as in Stock keeping unit), but we do need a string unique identifier. Numeric primary keys (like the product ID) are very useful and mandatory internally, but they do very little good for import/export and communication with external systems.
For those scenarios, we desperately need a string unique identifier that *can be* (but don't *need to be*) chosen by the store owner. Adding that at a later stage would be just a pain.
Of course, that human-choosable and human-readable unique identifier don't need to be mandatory. It should and will be automatically generated if possible... and as far as I know, it's already the case in the current code (we use the machine name pattern of Drupal 7 for that, and generate a SKU based on the product title).
I think the most flexible
I think the most flexible approach (as mentioned a few times above) would be to require an SKU, but have the option to have it automatically generated based on a product title or other field (e.g. UPC, EAN, ISBN, ...) through the token module, much like path/pathauto.
This would give site builders the option to decide whether this required field should be explicitly exposed / filled in by the store administrator, or should be just an identifier used in the background.
Regarding the naming issue: I assume this will be displayed as a translatable label, so I don't really see an issue with keeping the SKU label. If this would confuse some users, they'd always have the option to rename "SKU" to something like "Unique product ID" through the Locale or String Overrides module. Or am I missing something here?
Seems like the label "SKU" is not loved by everybody
May be we should have it default to SKU, and give a chance to the admin to change it to something more meaningful to his business. Just like in D6, when you create a content type, you are allowed to change the label of the title field.
So make the default name SKU, but if the admin wants ISBN instead let him change the label.
Keep the SKU but use a flexible approach
I have to agree with:
"I think the most flexible approach (as mentioned a few times above) would be to require an SKU, but have the option to have it automatically generated based on a product title or other field (e.g. UPC, EAN, ISBN, ...) through the token module, much like path/pathauto."
I read over use scenarios with here http://bit.ly/aUDb and can see why SKU's are needed in a robust ecomm product. I like the option of flexibility though so you are not locked into one way of doing things.
SKU is not for everybody
I understand and agree with near everything that has been said to this point.
There have already been valid examples provided for non-stock situations and I've personally faced times where I've been forced to create a SKU for a stocked item that hadn't been ordered/received knowing full well that the code I use wouldn't match whatever would eventually be used in the real stock-keeping system.
I understand the urge to force SKU entry, but it has already been acknowledged elsewhere on here that in the real world Commerce and it's predecessor, Ubercart, are often used in conjunction with other systems that are superior in functionality in their respective fields. By forcing (or not) entry of a SKU it also forces business practises to follow suit, which could be a major turn-off.
There is enough reason on both sides of this discussion to consider an alternative, that being providing an option to make the SKU required. I presume it will be possible to categorise product entities, in which case providing the option at the product entity category level while also having a global default which can be set would be reasonable.
Comments, as always, are welcome.
Yes on SKU, It's Needed
Some great points have already been made in the post and comments, but I wanted to also voice support for the need to keep SKUs. So, along with a "ditto" to many of the comments, I also think that SKU is the most logical term to use (as well as being conceptually quite important). Even if it's confusing for some, I think it's the least confusing option. And I do understand because I've had to explain this to clients many times.
Many things can change: titles, even product ID numbers. Unless I am misunderstanding, we're still essentially talking about a node ID - if it's deleted and then added again, it's changed. The SKU provides stability as an identifier. And I was nodding a couple of times reading comments from Webchick...the rest of her ID here :-). I've had many clients who didn't have an SKU or other unique product identifier set-up. Her example about a Lullabot video is similar to what I have often suggested as a default, logical SKU scheme. I've often suggested using a letter-number scheme such as starting with a 3 letter abbreviation for the product's primary category along with a 3 or 4 digit (incrementing) number. So beauty products might be BEA001, BEA002, etc., and even something this simple is more clear than a random number.
Unless there is another term that comes to mind that is startlingly more clear, I think SKU as a term is still the best. Education can help the fewer cases of confusion than the overall benefits.
And as Webchickenator also mentioned, an auto-populate module is completely feasible if needed.
This discussion seems focused
This discussion seems focused on single-store applications. What about their use for a marketplace application (UC Marketplace) where individual sellers have access to defining an SKU for a single product?
I have looked into the "auto SKU" but still seems a little messy, at least I feel setting it up is quite confusing.
UPC != SKU != Part Number != Primary Key
This thread is a classic case of programmers deciding that they know better than their customers.
The terms UPC and SKU are more meaningful than the simple "primary key" ideas presented above.
UPC: The UPC for a product is the same for everyone. It's kind of like DNS, in that you need a company registration to get a UPC. The UPC of a product is the same regardless of where you buy it. It has a certain format, and looks something like COMPANY_NUM-PRODUCT_NUM-CHECKSUM. You can purchase UPC databases filled with the type of stuff you can buy at department stores.
SKU: This is a Stock Keeping Unit, and it includes not only a Product, but also the Unit Of Measurement used for tracking that product. The SKU is internal to a company. It is alphanumeric, and sometimes it follows naming conventions. A vendor may have the SKUs 1234B, 1234R, 1234G to distinguish between Blue, Red, and Green versions of Part Number 1234.
A UPC is managed by an international standards organization. A SKU is managed within a single company. Some vendors revise the SKU every time they make a change to the product, and some (like Dell) track a separate revision number for each SKU or Part Number. My power supply is Rev. A00, for example.
A SKU is NOT the same as primary key. If I'm a reseller, it's entirely possible that two different vendors of two different products would both choose "1234" as their SKU. When I fill out Purchase Orders, I will probably use the vendor's SKU for products... so a SKU is not unique (but in practice, it usually is, just because each company has its own SKU conventions).
A Part Number is separate again. It is like a SKU without the Unit Of Measurement.
Finally, a primary key is not always an AUTOINC integer. Within a single SQL database, that autoinc key may work, but in distributed systems where the warehouse receiving computer talks to the inventory control computer, which talks to the accounting computer, and they all run separate 3rd-party software, the primary key might very well be a universally unique UUID number.
Mandatory SKU and Secondary Indexes?
I'm just learning D7DC so need to find out more about how all the comments in this thread were (will be) instantiated since some go back a year.
IMO, In a robust commerce system there must be a mandatory SKU associated with each object in the cart as an external reference number. Internal reference numbers are typically derived from the system/db architecture and are only meaningful to the system.
Other "standard" identifiers such as UPC and ISBN must be retained as those identifiers and they must be secondary indexes to the SKU.
IMHO, If these conventions are adhered to the platform is open and scalable. If not, the platform is riddled with mini-forks?
The architecture should work
The architecture should work as you expect: there's a unique ID in the system ($product->product_id), a merchant defined SKU ($product->sku), and the ability to add fields for additional identifiers (we're doing a book store right now at Commerce Guys that adds an ISBN field, for example). Derek mentions above the additional need for a UUID, and I agree the necessity, esp. for multisite stores. Hopefully the UUID project can adapt to provide these for any entity on Drupal 7. recidive is a big Commerce contributor, so I see it as quite likely he'll be thinking of moving this direction anyways.
Hope that helps clear things up. : )
EDIT: Quick update to say the D7 port issue of UUID does address the approach I mentioned above and seeks to make it a core feature for D8: http://drupal.org/node/1005138