SAP Web Channel Experience Management E-Commerce: Pricing Engines

[KaHa]

This is again one of the WCEM Blogs, which claims to talk about “one of the most important decisions during implementation and configuration of WCEM”. Well, choosing the right pricing engine for your shop actually is an important decision. Basically the challenge for you will be to balance business requirements for flexibility in price calculation against performance and load considerations.

The good thing is, that you can adjust your decision later if your requirements change or you feel that another setup fits better to the needs of your users and your company. This would not impact your users. Most probably they wouldn’t even recognize it, unless they may see e.g. personalized prices.

Below I will try to bring some light into the different options, their strengths and gaps.

So let’s start then. The areas, which are affected by the Pricing Engine decision, are:

• Price display in Catalog
• Price display in Cart (to be differentiated between Java Cart and Backend Cart)
• Price display in Checkout

For each of these areas different options can be chosen.

Price display in Catalog

For the Catalog you may choose between “List Prices” and “Dynamic Pricing”:

Let’s postpone the third option for a moment.

List prices

“List Price” option is simply, what is says. The prices shown in the catalog are determined by a simple table lookup like:

Product	Price
Computer Intel® Core™ i3-2350M	499,- €
Computer Intel® Core™ i5-2450M	599,- €

This way of determining the price is pretty straight forward, simple and fast. Just the Java WebServer and the catalog engine are involved in the determination. Technically it is based on a condition table, which is replicated to the catalog engine (e.g. A304 for the famous PR00 condition type in ERP).

“List Price” fits always, where you want to show standard or default prices in the catalog and where the determination depends on one (the product) or two criteria only. On the other hand it is not very flexible. If you want to show prices,

• Which are personalized to your user
• Which involve discounts (strike through prices)
• Which involve Promotions and campaigns

the “List Price” option is not the first choice. In this case the other option “Dynamic Pricing” can position its strengths.

Dynamic pricing

Using “Dynamic Pricing” the prices shown in the catalog are determined or better calculated by a dedicated pricing engine. All pricing engines, which are used in WCEM, are based on SAP’s Condition Technique. Condition Technique is quite comprehensive and powerful (yes I am a fan), but requires unfortunately a certain level of knowledge to be able to turn its capabilities into value. For those, who are interested to become a fan, I can only recommend Preisfindung und Konditionstechnik in SAP ERP (unfortunately in German only). In the catalog it is technically based on SAP’s “Internet Pricing and Configurator” engine (IPC). Hence the Java WebServer, the Catalog Engine and the backend WebAS (the Virtual Machine Container part) are involved in the determination.

Dynamic Pricing fits always, where you want to show prices

• Which are personalized to your user
• Which involve discounts or surcharges
• Which involve Promotions and Campaigns
• Which depend on multiple criteria in different combinations
• Which at least potentially match the prices determined in Checkout

On the other hand, Dynamic pricing requires much more system resources compared to List prices. In addition to the fact, that Dynamic Pricing is actually a price calculation, keep in mind that for every price determination the backend WebAS is called (even if these calls are of course optimized).

Mixed

The mixed pricing method is, as its name says, a combination of list price and dynamic price. This mode was designed to bring more marketing into list price configured shops. The idea behind is simple: by default all prices displayed in the catalog are list prices retrieved from the catalog engine and for certain products targeted by a campaign, the price is retrieved by IPC.

At runtime, we can determine if some of the products about to be displayed on a catalog listing page are part of a campaign. The user could also manually enter a coupon number and would expect to see right away the special prices.

In short, a mixed pricing mode catalog is in list price mode by default, except if some campaigns are active. In this case, IPC kicks in and displays campaign prices only for the relevant products part of the campaign.

Price display in Java Cart

In the Java Cart you don’t have a completely free choice of the pricing method. Actually it is pretty much influenced by the pricing method chosen for the catalog.If you did choose “Dynamic Pricing” in the catalog for the reasons mentioned above, the Java Cart uses in any case “Dynamic Prices” as well in order to stay on the comprehensive level defined in the catalog.If you did choose “List Prices” in the catalog, you may again choose between staying with “List Prices” and switching to “Dynamic Pricing”. This is driven by the following setting in the WCB:

Staying with “List Prices” is preferable when you technically want to make sure, that the prices in the catalog and in the cart match and when your focus is to keep resource consumption at the lowest level possible. It is also an option, if you are running against an ERP-Backend and want to avoid using the IPC.

You would switch to “Dynamic Pricing” if you want at least in the cart show prices

• Which are personalized to your user
• Which Involve discounts or surcharges (Strikethrough Prices)
• Which involve Promotions and Campaigns
• Which depend on multiple criteria in different combinations
• Which at least potentially match the prices determined in Checkout

Please be also aware, that

• Scales
• Taxes
• Shipping Costs
• Free Goods

can be taken into consideration and shown respectively only, if “Dynamic Pricing” is chosen for the Java Cart.

In the Java Cart “Dynamic Pricing” is technically based on the IPC. Hence the Java WebServer, the Catalog Engine and the backend WebAS (the Virtual Machine Container part) are involved in the determination.

My personal favorites are using “List prices” in the Catalog and “Dynamic Pricing” the Java Cart, when low resource consumption is key. Otherwise I prefer “Dynamic Pricing” because of the flexibility it offers and because of the chance to keep pricing consistent through the complete process.

Price display in Backend Cart/ Price display in Checkout

Because of the nature of this cart type and of this process step respectively, you don’t have a choice here. “Dynamic Pricing” is used always. The price calculation is based on the integrated pricing functionality of the backend Sales Order. This means the same price calculation is running as if the order would be entered in the backend. All exits, data and determinations you might have introduced to the Sales Order functionality on the backend, apply.
When running against a CRM Backend, pricing is technically based on the IPC. Hence only the backend WebAS is involved in the determination.
When running against an ERP Backend, pricing is technically based on SD Pricing functionality. Hence only the backend WebAS is involved in the determination.

Further Information

• SAP ERP Central Component Application Help: Pricing and Conditions
• SAP WCEM 2.0 Application Help: Pricing in the Shopping Cart
• SAP WCEM 2.0 Application Help: Pricing in the Product Catalog

More WCEM Blogs to check out

Please check SAP Web Channel Experience Management - Blog INDEX for further blogs.