Discussions

Product Specification

This is a synthesis of various discussions and should be considered a rough draft. If anything has been left out, please mention in the comments and I'll update the post. When it's solid, I'll drop it in the docs and get to work.

----------

Drupal Commerce (hereafter DC) defines a new Drupal entity type called "Product." This entity includes a default title, SKU, and price (to be replaced by a price Field) along with general Drupal meta data (uid, created / updated timestamps, and status).

DC allows users to define any number of "Product types" that include the base product entity and any additional Fields necessary to define products of that type. (Consider the way the node system works, in that you can have as many node types as you want, each having its own set of Fields.) DC comes with a "Basic product" product type that is simply the product entity with no additional Fields.

Fields should be added to product types to define attributes of the product. DC maintains a single product -> unique SKU relationship and abandons the idea of multiple SKU variations on single products that existed in Ubercart. In other words, whereas in Ubercart you might define a single product with a base SKU that was altered based on a customer's attribute option selection, with DC you would instead define every variation of that product up front as a unique product using any number of Fields to define the specific attribute options assigned to each SKU.

Products may be displayed to customers through "Product reference" Fields attached to nodes (or any other fieldable entity). Product reference fields can reference single or multiple products. This Field will come with an "Add to Cart form" formatter that generates an Add to Cart form based on the selected products. When multiple products are referenced, the Add to Cart form will automatically create the appropriate form elements needed for the user to choose one of the products to add to the cart.

Example: A site selling t-shirts of multiple sizes should define a "T-shirt" product type. Attached to this product type would be a text Field that includes options for every possible size. The store owner would then create a new T-shirt product for every size of every style t-shirt he wants to sell, each having a unique SKU. (We can certainly provide simplified UIs for accelerated product entry.) If the t-shirts were to be displayed for sale, he would create a "T-shirt display" node type that included a product reference field with the Add to Cart form display. Then for each style t-shirt, he would add a title and description and reference the various sizes of that style via the product reference field. When that node is viewed, DC will display the various products in an Add to Cart form with a select list (or some other widget) for the customer to specify which product should be added to the cart.

See also:

Ryan Szrama
Posted: Jan 29, 2010

Comments

Ryan Ryan Szrama on February 7, 2010

This specification needs to be expanded to include what sorts of API functions should exist for product types and products (i.e. should there be a commerce_product_new() function and what should it do?) and what alter hooks should be available.

At present, I've also implemented a default product type, but I'm not sure it should stick around. If we do keep it, it should appear in this specification.

alexanderpas (not verified) on February 18, 2010

If you add SKU, Price and Stock as Fields
- SKU = Textfield (SKU representation)
- Price = Number (Price representation)
- Stock = Integer (Stock representation)

and create an 'Add to cart' "Button" Field, you could, in theory, create a product from every node type you want.

This can be, for example, very usefull when upgrading a "Product Gallery" into an actual Shop, by adding the required fields in the node type.

Now, In addition, with attached views, you can make it easy to make links to different variations of the same product, for example, in a different Color or a different size

The seperate node approach is also very good to allow searching through the products with exposed filters, as this allows you to only search for Red T-Shirts in the XXL size.

The only two problems with this approach is to give the customer a good overview when browsing the store and the manual labour required to enter a new product in different sizes, colors, and prints.

This is where Drupal Commerce can shine (besides checkout) by offering a multistep form where you can enter the Colors, Sizes and Prints, and afterwards, enter the SKU for all the possible combinations.

I also suggest to keep some kind of grouping (on the backend) for those products, to allow easy editing, trough a mass edit form, of all those products at once (for example, for price changes on all t-shirts)

Now, the other challence is discounts.

(note that i only used the t-shirt as an example, but you can use any type of product this way.)

harrisben on February 18, 2010

I don't recall where it is, but stock is not a default product field is it? Regardless of the answer, please make it a float and not an integer.