10 min read

Defining the catalogue

The type of products you are selling will determine the structure of your store.

Different types of products will have different requirements in terms of the information presented to the customer, and the data that you will need to collect in order to fulfill an order.

Base product definition

Every product needs to have the following fields which are added by default:

  • Title
  • Stock Keeping Unit (SKU)
  • Price (in the default store currency)
  • Status (a flag indicating if the product is live on the store)

This is the minimum you need to define a product in Drupal Commerce—everything else is customized for your store. You can define multiple Product Types (Product Entity Bundles), which can contain different fields depending on your requirements.

Physical products

If you are dealing with physical products, such as books, CDs, or widgets, you may want to consider these additional fields:

  • Product images
  • Description
  • Size
  • Weight
  • Artist/Designer/Author
  • Color

You may want to consider setting up multiple Product Types for your store. For example, if you are selling CDs, you may want to have a field for Artist which would not be relevant for a T-shirt (where designer may be a more appropriate field).

Whenever you imagine having distinct pieces of data available, adding them as individual fields is well worth doing at the planning stage so that you can use them for detailed searching and filtering later.

Digital downloads

If you are selling a digital product such as music or e-books, you will need additional fields to contain the actual downloadable file. You may also want to consider including:

  • Cover image
  • Description
  • Author/Artist
  • Publication date
  • Permitted number of downloads

Tickets

Selling tickets is a slightly more complex scenario since there is usually a related event associated with the product. You may want to consider including:

  • Related event (which would include date, venue, and so on)
  • Ticket Type / Level / Seat Type

Content access and subscriptions

Selling content access and subscriptions through Drupal Commerce usually requires associating the product with a Drupal role. The customer is buying membership of the role which in turn allows them to see content that would usually be restricted. You may want to consider including:

  • Associated role(s)
  • Duration of membership
  • Initial cost (for example, first month free)
  • Renewal cost (for example, £10/month )

Customizing products

The next consideration is whether products can be customized at the point of purchase. Some common examples of this are:

  • Specifying size
  • Specifying color
  • Adding a personal message (for example, embossing)
  • Selecting a specific seat (in the event example)
  • Selecting a subscription duration
  • Specifying language version of an e-book
  • Gift wrapping or gift messaging

It is important to understand what additional user input you will need from the customer to fulfill the order over and above the SKU and quantity.

When looking at these options, also consider whether the price changes depending on the options that the customer selects. For example:

  • Larger sizes cost more than smaller sizes
  • Premium for “red” color choice
  • Extra cost for adding an embossed message
  • Different pricing for different seating levels
  • Monthly subscription is cheaper if you commit to a longer duration

Classifying products

Now that you have defined your Product Types, the next step is to consider the classification of products using Drupal’s in-built Taxonomy system.

A basic store will usually have a catalog taxonomy vocabulary where you can allocate a product to one or more catalog sections, such as books, CDs, clothing, and so on. The taxonomy can also be hierarchical, however, individual vocabularies for the classification of your products is often more workable, especially when providing the customer with a faceted search or filtering facility later.

The following are examples of common taxonomy vocabulary:

  • Author/Artist/Designer
  • Color
  • Size
  • Genre
  • Manufacturer/Brand

It is considered best practice to define a taxonomy vocabulary rather than have a simple free text field. This provides consistency during data entry. For example, a free text field for size may end up being populated with S, Small, Sm, all meaning the same thing. A dropdown taxonomy selector would ensure that the value entered was the same for every product. Do not be tempted to use List type fields to provide dropdown menus of choices. List fields are necessarily the reserve of the developer and using them excludes the less technical site owner or administrator from managing them.

Pricing

Drupal Commerce has a powerful pricing engine, which calculates the actual selling price for the customer, depending on one or more predefined rules. This gives enormous flexibility in planning your pricing strategy.

Currency

Drupal Commerce allows you to specify a default currency for the store, but also allows you to enter multiple price fields or calculate a different price based on other criteria, such as the preferred currency of the customer.

If you are going to offer multiple currencies, you need to consider how the currency exchange will work; do you want to enter a set price for each product and currency you offer, or a base price in the default currency and calculate the other currencies based on a conversion rate?

If you use a conversion rate, how often is it updated?

Variable pricing

Prices do not have to be fixed. Consider scenarios where the prices for your store will vary over time, or situations based on other factors such as volume-based discounts.

Will some preferred customers get a special price deal on one or more products?

Customers

You cannot complete an order without a customer and it is important to consider all of their needs during the planning process.

By default, a customer profile in Drupal Commerce contains an address type field which works to the Name and Address Standard (xNAL) format, collecting international addresses in a standard way. However, you may want to extend this profile type to collect more information about the customer. For example:

  • Telephone number
  • Delivery instructions
  • E-mail opt-in permission

Do any of the following apply?

  • Is the store open to public or open by invitation only?
  • Do customers have to register before they can purchase?
  • Do customers have to enter an e-mail address in order to purchase?
  • Is there a geographical limit to where products can be sold/shipped?
  • Can a customer access their account online?
  • Can a customer cancel an order once it is placed? What are the time limits on this?
  • Can a customer track the progress of their order?

Taxes

Many stores are subject to Sales tax or Value Added Tax(VAT) on products sold. However, these taxes often vary depending on the type of product sold and the final destination of the physical goods.

During your planning you should consider the following:

  • What are the sales tax / VAT rules for the store?
  • Are there different tax rules depending on the shipping destination?
  • Are there different tax rules depending on the type of product?

If you are in a situation where different types of products in your store will incur different rates of taxes, then it is a very good idea to set up different Product Types so that it’s easy to distinguish between them. For example, in the UK, physical books are zero rated for VAT, whereas, the same book in digital format will have 20% VAT added.

Payments

Drupal Commerce can connect to many different payment gateways in order create a transaction for an order. While many of the popular payment gateways, such as PayPal and Sage Pay, have fully functional payment gateway modules on Drupal.org, it’s worth checking if the one you want is available because creating a new one is no small undertaking.

The following should also be considered:

  • Is there a minimum spend limit?
  • Will there be multiple payment options?
  • Are there surcharges for certain payment types?
  • Will there be account customers that do not have to enter a payment card?
  • How will a customer be refunded if they cancel or return their order?

Shipping

Not every product will require shipping support, but for physical products, shipping can be a complex area. Even a simple product store can have complex shipping costs based on factors such as weight, destination, total spend, and special offers.

Ensure the following points are considered during your planning:

  • Is shipping required?
  • How is the cost calculated? By value/weight/destination?
  • Are there geographical restrictions?
  • Is express delivery an option?
  • Can the customer track their order?

Stock

With physical products and some virtual products such as event tickets, stock control may be a requirement. Stock control is a complex area and beyond the scope of this book, but the following questions will help uncover the requirements:

  • Are stock levels managed in another system, for example, MRP?
  • If the business has other sales channels, is there dedicated stock for the online store?
  • When should stock levels be updated (at the point of adding to the cart or at the point of completing the order)?
  • How long should stock be reserved?
  • What happens when a product is out of stock?
  • Can a customer order an out-of-stock product (back order)?
  • What happens if a product goes out of stock during the customer checkout process?
  • If stock is controlled by an external system, how often should stock levels be updated in the e-store?

Legal compliance

It is important to understand the legal requirements of the country where you operate your store. It is beyond the scope of this book to detail the legal requirements of every country, but some examples of e-commerce regulation that you should research and understand are included here:

  • PCI-DSS Compliance—Worldwide
  • The Privacy and Electronic Communications (EC Directive) (also known as the EU cookie law)—European Union
  • Distance Selling Regulations—UK

Customer communication

Once the customer has placed their order, how much communication will there be? A standard expectation of the customer will be to receive a notification that their order has been placed, but how much information should that e-mail contain?

  • Should the e-mail be plain text or graphical?
  • Does the customer receive an additional e-mail when the order is shipped?
  • If the product has a long lead time, should the customer receive interim updates?
  • What communication should take place if a customer cancels their order?

Back office

In order for the store to run efficiently, it is important to consider the requirements of the back office system. This will often be managed by a different group of people to those specifying the e-store. Identify the different types of users involved in the order fulfillment process. These roles may include:

  • Sales order processing
  • Warehouse and order handling
  • Customer service for order enquiries
  • Product managers

These roles may all have different information available to them when trying to locate the order or product they need, so it’s important for the interface to cater to different scenarios:

  • Does the website need to integrate with a third-party system for management of orders?
  • How are order status codes updated on the website so that customers can track progress? In a batch, manually or automatically?

User experience

How will the customer find the product that they are looking for?

  • Well-structured navigation?
  • Search by SKU?
  • Free text search?
  • Faceted search?

The source of product data

When you are creating a store with more than a trivial number of products, you will probably want to work on a method of mass importing the product data.

Find out where the product data will be coming from, and in what format it will be delivered. You may want to define your Product Types taking into account the format of the data coming in—especially if the incoming data format is fixed.

You may also want to define different methods of importing taxonomy terms from the supplied data.

Summary

Once you have gone through all of these checklists with the business stakeholders, you should have enough information to start your Drupal Commerce build. Drupal Commerce is very flexible, but it is crucial that you understand the outcome that you are trying to achieve before you start installing modules and setting up Product Types.

Resources for Article:

Further resources on this subject:

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here