Back in 2007 I was faced with designing a multi-currency catalog solution for Commerce Server. I knew from previous experience that we would need a general purpose solution, which we could employ for many clients.
Back then Commerce Server 2007 was new thus performance characteristics were new territory as well. I ended up designing a solution based solely on virtual catalogs. Basically one catalog for each price group/currency. You can read the details on multi-currency/price groups, which we’ve employed successfully numerous times since then.
Since 2007 we’ve gotten a new version of Commerce Server though no significant new features were added in the catalog system, and we’ve gained valuable new knowledge on both the pricing scenarios and limitation of the Commerce Server catalog system. With that information in hand I’m going to try my hand at redesigning the original multi-currency catalog structure from 2007 to both address performance issues and increased flexibility.
Virtual catalogs are slow and so they make a poor choice to expressing essentially a single piece of data. You might say that virtual catalogs perform perfectly well if you materialize them and you would be right. You gain in the order of 10x performance by materializing a virtual catalog but lose the ability to make any changes in them in the process.
Basing my original multi-currency solution on virtual catalogs seemed to make perfect sense, but with the added requirement of changing the category hierarchy two levels of modifiable virtual catalogs were needed, thus the ability to materialize was lost.
To make matters worse we rarely deal with clients who are inclined to go with an Enterprise license for their Commerce Server solution, so we don’t see very many full fledged staged solutions, which would take care of the challenge handily.
Virtual catalogs are by nature limited to two levels, i.e. you can have a total of three levels of catalogs, one with base catalogs and two with virtual catalogs. Are we to use one of these levels of virtual catalogs for pricing we lose it for other purposes, and gain very little other than the ability to store another price group per catalog.
What I’ve come to realize over the years is that product pricing is a completely separate issue from the product itself. While the two might seem like one and the same; in reality they aren’t. Sure the customer needs to be told a certain price, but more often than not the price is determined by context surrounding the product, rather than the product itself.
An example would be a seasonal business, which is highly dependant on calendar time, the product would probably sell for a higher rate at specific times of the year and lower rates the rest of the year, e.g. ChristmasTreesOnline.com. The context in this particular instance is time.
Now for business to business scenarios the context might be especially convoluted as you might go for pricing granularity, which allow organizations, groups within the organization, even individual people in the organization to have specific prices, e.g. memberships to the gym provided by your company or framework agreements made between supplier and customer. The context deciding the price is who you are in this case, not the product itself.
To handle the separate issue of pricing we need something akin to a service in domain driven design parlance. The service is responsible for looking up the right price based on whichever context is present for a given customer request.
Of course we need some sort of structure to maintain the pricing for individual price groups, and catalogs come in handy to solve this as I’ll show you next.
Our product catalog would in the new scheme continue to exist as we know and love it with one minor exception. The list price of the product is either to be ignored or used only to get an idea of what the pricing is like. The list price will not be picked up from the product catalog, which contains the marketing data for a product. Please note that I define marketing data in this instance as data used to display to potential customers, but other than that serve no purpose to the system.
In Commerce Server we have the notion of different types of catalogs, i.e. the product catalog and the inventory catalog. I’m going to introduce a third kind called the Pricing Catalog. As you might imagine a pricing catalog concerns itself only with price and as such contains only the bare minimum of data to identify a product.
The pricing catalog will have metadata to indicate that it is in fact a pricing catalog. Each pricing catalog reflects a single price group such as “Internet Users”, “Gold Customers”, whatever makes sense for the particular scenario.
Having pricing split out like this means that we can price products based on the calendar time context as a standard Commerce Server catalog has dates associated with it to allow us to display it within only a given period of time.
For a pricing catalog these fields are used to determine whether a price is valid or not, so you could have the seasonal pricing expressed as two different pricing catalogs for our ChristmasTreesOnline.com, one for holiday pricing and one for the rest of the year. The pricing service would then grab the pricing from the proper Pricing Catalog and display it to the customer.
Finally I propose a new kind of definition called the Pricing Definition. What this is is a specialized Product Definition used for creating Pricing in the Pricing Catalogs for advanced scenarios, e.g. complex pricing matrices defined in external systems such as an ERP.
Products, i.e. Prices, created based on a Pricing Definition would contain at least the SKU, name, description, and of course the list price. These specialized products go into a Pricing Catalog as we discussed in the previous paragraph.
Another context we discussed in a previous section is the organizational context, which might also influence product pricing. Fortunately Commerce Server comes with CatalogSets as a neat way of bundling catalog together. CatalogSets leveraged with our Product Catalogs and Pricing Catalogs would allow us to do multi-currency and, incidentally, a bunch of even more interesting scenarios.
Imagine if you will a scenario where our online retail outlet would like to give Internet customers access to only currencies, which make sense for their particular region, e.g. here in Denmark Euro and our national currency Kroner would make sense, while UK customers should be enabled to shop in either Pounds or Euro.
Simple! Create two catalog sets one called Denmark and one called UK. For the Denmark catalog set select our one product catalog containing all products or the one which reflects the range available in Denmark and select the two Pricing Catalogs Kroner and Euro. For the UK catalog set select Euro and Pounds Pricing Catalogs.
By way of the metadata on the catalogs we’re now able to display the same range for both UK and Danish customers, but in three different currencies with Pound being available to the British and Kroner available only to the Danish customers.
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.