In this post I will continue my series connected with my revision for the MB2-713 Certification (Microsoft Dynamics CRM 2016 Sales).
This time I’m going to look at the product catalog. In previous posts I have mentioned how products can be associated with opportunities but how do we define what those products are and how do they fit into the overall sales process?
The product catalog not only includes the definition of the actual products and services but also the units they’ll be sold in (unit groups) and the prices that will be charged. (Price lists) Plus products can be grouped into families and bundles as required. The components of the product catalog include;
- Discount lists, offer the ability to discount prices based on volume purchased.
- Unit Groups, these define how the products are sold or packages. (Examples might include, Single Units, Dozens, Box of 10 etc)
- Price lists, allow for differing pricing structures for specific customers and currencies.
- Price list items, allows prices for certain products to be defined and linked to price lists.
- Products, the product entity holds the key information about the product likes its name, description, unique ID, default unit group etc.
A product can be a physical item such as a chair or a can of beans. It is important to understand a product can also be service provided, such CRM Consultancy, a software support contract or even a dental checkup. In the case of services the products will be defined in units of time or single units. (1 hour of consultancy or 1 dental checkup.)
Before you can create a product you must have at least one Unit Group. Imagine you sell cans of beans. The basic unit for a can of beans might be 1 can (each). And they maybe bought by in cases of 24 cans. Or maybe even by the pallet load, which might be equivalent to 12 cases.
- 1 can.
- 1 case = 24 cans.
- 1 Pallet = 12 cases. (Or 288 cans)
Instead of defining a separate product codes for 1 can, 1 case, and 1 pallet. We define unit groups.
Unit groups can be found in the product catalog, which is in the settings area of CRM.
Below you can see that I have created a unit group for Canned Goods. I’ve named it like this because I might want to sell cans of peas, sweet corn and beans all using this one unit group. Notice that I have another unit group called “Default Unit”, this comes out of the box and is often used when products are stocked and sold only as singles.
By opening my canned goods Unit Group, you can see I have three units. Firstly, a single can. This is known as the base unit and will always have a quantity of 1. (All unit groups must have a base unit.)
Then I have a case which is linked to a single can as its base unit. This has a quantity of 24. Meaning a case is made up of 24 cans.
Next notice I have also defined a pallet. This doesn’t use the single can as its base unit but the case. A pallet is made up of 12 cases and a case of 24 cans. (So … 12*24 = 288 cans.)
Once you’ve created your unit groups you can start to create products. Under settings and product catalog you’ll find the products option. Here I can add product families, products and product bundles. I will cover families and bundles a little later. So first off I’m going to add a new product.
When defining a product, you’ll allocate a name, unit group (and default unit from that group), default price list and other items like the list price, cost price and standard cost.
It is important to be aware that some of these fields are not shown on the product form by default but do exist in the database. On my sample form below you can see I have added some of these fields to illustrate this. This is important because depending on your pricing approach the list price, standard cost and current cost maybe be used in the price calculation logic.
Also note that the product has a valid from and valid to date. These are for reference only! There is no out of the box system functionality to automatically retire a product from the valid to date is reached. If this functionality was required customizations could be created to enforce any required automation.
Notice that I have given the product a subject of “Default Subject”, this illustrates that products can (optionally) be linked to the subject tree. The subject tree can be used to categorize products. In my simplistic example I haven’t configured realistic options within the subject tree. (I don’t expect you to need to know how to customize the subject tree in the MB3-713 exam but you might need to know that is exists as a field on product.)
Also note, possibly a better approach to product categorization is to use product families. I will cover that concept in more detail in a future post.
The default price list is a business recommended field. If you save a product without entering a valid price list a warning notification will be given. But you can ignore this and publish the product if required.
Product Life Cycle
Products have a life cycle; they always start off as draft. Then, once fully defined we publish the product to make it active. After time a product maybe retired or revised.
Products start off in draft status. At this point they cannot be added to any transitional records, including opportunities, quotes, orders and invoices.
Only active products can be added to opportunities, quotes, orders or invoices. Products become active once published.
When a product is no longer relevant it is retired. (For example when a new version is created. CRM2015 replacing CRM2016 maybe!) Retired products cannot be added to any new opportunities, quotes, orders or invoices. But if the product already exists on an opportunity when retired it can continue with the rest of the sales cycle.
- Under Revision. This is used when products are being updated. Whilst this is happening the current version of the product is still available but any of the changes being made to this new version are not seen until activated.
- A retired product can be made active again by selecting the “Activate” button from the product ribbon. (Draft to Active is called publish, but Retired to Active is called Activate.)
- Only active products with valid price lists are available for addition to opportunities, quotes, orders and invoices.
- Making a product active does not restrict changes to the product detail.
- Making a product retired makes it read only and meaning it can no longer be maintained.
Cloning products is a simple process that helps when creating products that are similar. Take my earlier example of Beans. Beans are a canned goods sold in a particular way, but I might also sell cans of sweet corn, peas, carrots. (etc) The configuration of each of these maybe very similar. Being able to clone one of the products and then make amendments may make the time create all of these variations of canned goods quicker.
You can clone a product regardless of its state. Maybe you want to clone a retired product to become a new improved version of an old favorite.
Once cloned the new record is given a name based on the original with a suffix of an 18-digit long number that is derived from the date time. (e.g Baked Beans-201604170610464756)
The clone button can be found once one products have been selected in the product list view or directly on the product form.
When you select the clone button a warning message will be displayed stating that a new record will be created.
A new record is created and given a name based on the original with a suffix of an 18-digit long number that is derived from the date time. (e.g Baked Beans-201604170610464756)
Also notice that when the product is opened you can see that a similar code has been given a similar suffix.
You can now edit this new product and publish when ready.
I hope this post has given you a good introduction into the product catalog, in later posts I will build on these concepts by explaining price lists, product families, product bundles and such like. J