Extending EPiCommerce Tiered Pricing or What's your VisitorGroup Price For That SKU?

This is part 1 of 3 blog posts created to give you some background on how tiered pricing works in EPiCommerce and how you can extend it to do cool things like have pricing for visitor groups or other pricing scenarios you need to handle.

When you've used or demo'd the tiered pricing, you probably have used the dropdown for Sale Type and wondered "But how do I set pricing for customers in visitor groups or customers associated with organizations, or with a particular customer attribute other than price group?". Or perhaps you've thought "But what if I want to cover the [fill in your custom pricing scenario]?"

The built-in pricing provider can be easily extended to cover these scenarios and still be editable in Commerce Manager. When tiered pricing is extended, you can make new options available in Commerce Manager to allow site administrators to easily create a tiered price on a stock keeping unit (SKU) that's more specific to their custom scenarios. Before we cover how to do that, it helps to better understand how tiered pricing works.

The Technical Background on Tiered Pricing
From the Commerce Manager view, when you're editing tiered pricing in Commerce Manager, you're editing the rows of data in the SalePrice database table that are associated with a SKU, package, or bundle. From the API view, those tiered pricing rows are available from an Entry object as an array of SalePrice objects or as rows in the SalePrice datatable in the CatalogEntryDto. You probably won't use those objects representing sale prices unless your doing a custom import of catalog data. But you use them indirectly whenever you call StoreHelper.GetSalePrice() or StoreHelper.GetDiscountPrice(). The GetSalePrice() method (which is called inside GetDiscountPrice()) is essentially the built-in pricing engine. It parses through the list price (aka display price) for an Entry and its associated SalePrice rows to find the lowest applicable price for a SKU given the customer (if they’re logged in), date, quantity being purchased, and customer target information.

What is customer target information? This is information used to segment customers defined by the sale type and sale code. In the SalePrice datatable, these are the SaleType and SaleCode fields. The built-in segmentation are : Customer and Customer Price Group. Customer allows you to specify the username of a customer to provide a specific price for a SKU - mostly useful in B2B-type scenarios. The Customer Price Group is an attribute of the CustomerContact object that is configurable with the properties of users in the Customer subsystem; its marked as Customer Group when you're viewing/editing a customer in Commerce Manager. This allows you to specify the price of a SKU for customers which have the same price group specified. The default customer target is All Customers, which makes no distinctions based on customer target information (whether logged in or not).

So where are these customer targets defined? They are defined in the Configs/ecf.catalog.config file, in the SalePriceTypes section. This means you can add your own sale types. But if you add your own sale types, how are those used by the system to map pricing to a customer? And what are examples that demonstrate the power of this capability?

This is covered in parts 2 and 3, respectively…