Websphere Comerce Marketing and Merchandising SubSystem







IBM WCS Promotions

Promotions allow you to offer customers incentives to purchase. WebSphere Commerce supports numerous types of promotions .Promotions can be created from either Management Center or Web sphere Commerce Accelerator.


Websphere Commerce Promotions
Websphere Commerce Promotions




Promotion groups
Promotion groups, as the name implies, group promotions according to their type. These groups have no hierarchical structure, or priority. By default, each store has the following promotion groups:

1.Product Level Promotions  
2.Order Level Promotions 
3.Shipping Promotions
 
Product Level Promotions can be
  1. Percentage off per item.
  2. Fixed amount off per item.
  3. Fixed amount off for all.
  4. Buy X, get one or more items at a discount.
  5. Free gift with purchase.
Order Level Promotions can be
  1. Percentage off.
  2. Fixed amount off.
  3. Free gift with purchase .
Shipping Promotions can be
  1. Free shipping.
  2. Discounted shipping for an order using a selected ship mode.
  3. Discounted shipping for all items using a selected ship mode.
  4. Discounted shipping per item using a selected ship mode.

Promotion organization
Promotions are owned by stores. They can be uniquely identified by the store they belong to, their name, version and revision. Promotions are organized into Promotion Groups, which are also owned by stores. Each promotion belongs to one, and only one, promotion group. Optionally, a promotion can be associated with a campaign.

Promotion policies can be optionally associated with promotion groups. When a policy is associated with a promotion group, it applies to all promotions in that group. When a promotion policy is not associated with any group, it is considered global, which means it is applicable to any and all promotions. Promotion policies are owned by individual stores as well.

Promotion life cycle

A business user creates a promotion in the inactive state. From that point forward, the promotion can be activated, modified, and deleted.When a promotion is first created, it is inactive.When an inactive promotion is activated, a new version of that promotion is created and marked active. The original promotion is then marked as obsolete.An active promotion can be withdrawn, marking it as inactive.
Promotions are static. When changes are made to a promotion, a new revision is made. The new revision inherits the state of the promotion before the change. The original promotion is then marked as obsolete.Promotions in either active or inactive state can be modified or deleted. The changes take effect immediately after they are made.

Promotion engine components

Promotion engine comprises a series of configurable components. All of these configurable components are specified in a configuration XML file, WCSPromotionEngineConfig.xml. The promotion engine is configured per Web Sphere Commerce instance; it is not possible to have different configurations for stores in the same instance.

The promotion engine evaluates promotions for customers while they shop on the storefront. The evaluation process has several stages and involves different components of the promotion engine (PromotionAgendaBuilder, PromotionSequenceBuilder)
        
PromotionAgendaBuilder
PromotionAgendaBuilder is registered with the promotion engine, is called to build an agenda for this invocation. An agenda functions similar to a table that contains a list of promotions to be evaluated, and all of the applicable policies for each promotion.

PromotionSequenceBuilder
Once the agenda is built, the promotion engine calls the registered PromotionContextFactory to create a promotion context. Next, the promotion engine calls a registered PromotionSequenceBuilder to sort all of the promotions listed in the Agenda to decide the sequence in which to evaluate the promotions. After the sequence is determined, the initialization phase of a call to the promotion engine is finished.

Promotion engine then iterates through the sequence built earlier and evaluates the promotions individually. When a promotion is evaluated and deemed applicable, the promotion engine looks up the promotion execution agenda and finds all of the application promotion policies for this promotion. It then initializes the promotion control block (PCB) and tentatively applies the promotion. After the promotion is tentatively applied, the promotion engine applies the applicable promotion policies individually. If a violation is detected, the PCB is rolled back, and the promotion is not applied. If no violation is found after all of the policies have been applied, the PCB is committed. This means that this promotion is now applied to the order. This process continues until all of the promotions in the sequence have been evaluated. Then, a PromotionArgument object is built based on the content of the Promotion Context and returned as the result of this invocation.

Promotion evaluation sequence
In order to  configure the promotion engine for a custom sequence builder
Edit the promotion engine configuration XML file in an editor. 
WC_eardir/xml/PromotionEngineConfiguration/WCSPromotionEngineConfig.xml
Update the following code segment:
<PromotionExecutionSequenceBuilder impl="
com.ibm.commerce.marketing.promotion.runtime.DefaultSequenceBuilder"/>

The segment in bold should be updated to reflect either the custom sequence builder, or one of the following sequence builders:

StorePathSupportedSequenceBuilder
This is the default sequence builder. It supports all of the WebSphere Commerce features and business models. It evaluates promotions in the following order:
  1. Coupon promotions.
  2. Promotion codes (promotions for an asset store are evaluated before those from the related stores).
  3. Group order of the promotion group to which the promotions belong.
  4. Assigned priority.
  5. Store sequence in the STOREREL table.
StorePathSupportedGroupFirstSequenceBuilder
This sequence builder is similar to the first, except that it evaluates promotions according to the group to which they belong first. It evaluates promotions in the following order:
  1. Group order of the promotion group to which the promotions belong.
  2. Coupon promotions.
  3. Promotion codes (promotions for an asset store are evaluated before those from the related stores).
  4. Assigned priority.
  5. Store sequence in the STOREREL table.
DefaultSequenceBuilder
A former default sequence builder that does not support B2B business models. It evaluates promotions in the following order:
  1. Coupon promotions.
  2. Promotion codes
  3. Group order of the promotion group to which the promotions belong.
  4. Assigned priority
StaticSequenceBuilder
It evaluates promotions in the following order:
  1. Group order of the promotion group to which the promotions belong.
  2. Assigned priority
  3. You may also see the following sequence builder, which is not intended to be used directly:
  4. PromotionExecutionSequenceBuilder.java
  5. A dummy interface to facilitate customization. Any custom sequence builders must call this interface.
The two commands that call the promotion engine are:
  1. PromotionEngineOrderCalculateCmdImpl
  2. PromotionEngineDiscountCalculationCodeCombineCmdImpl
When the promotion engine is called, it processes any promotions for the current order, and returns a PromotionArgument.The order subsystem is then responsible for interpreting the results (PromotionArgument) returned by the promotion engine and storing the results the respective order and order item adjustment tables. Due to limitations in the order subsystem, not all Adjustments are supported by the order subsystem.

Code snippet to get applied promotions for an order

Below is the Code snippet to get the list of promotions applied to an order.

String orderId = "10000";
OrderKey orderKey = new OrderKey(new Long(orderId));
PromotionArgumentSessionBeanPersistenceManager promoManager = new PromotionArgumentSessionBeanPersistenceManager();
PromotionArgument promArg = promoManager.load(orderKey);
Iterator prmoExeRecds = promArg.getPromotionExecutionRecords();
while(prmoExeRecds.hasNext()) {
PromotionExecutionRecord promoExeRecd = (PromotionExecutionRecord) prmoExeRecds.next();
Promotion promotion = promoExeRecd.getPromotion();
System.out.println("Promo Name: " + promotion.getName());
}



Combine Promotions with other promotions
1)Combine with other promotions- Stackable promotions
This promotion can be combined with all other promotions in an order. In addition, this promotion can be stacked on top of other promotions in the same group, which overrides certain promotion policies. Specifically:
For catalog entry promotions: If a catalog-entry promotion has already applied to an item, then this type of promotion will be applied on top of the existing promotion.
For shipping promotions: If a shipping promotion has already applied to an item, then this type of promotion will be applied on top of the existing promotion.
For order promotions: If an order promotion has already applied to the order, then this type of promotion will be applied on the top of the existing promotion.

The priority of promotions determines whether a stackable promotion will apply to an order. If an order qualifies for multiple promotions in the same group, the promotion with the highest priority is applied first. If subsequent promotions are stackable, then those promotions are applied in order of priority.

2)Exclusive within the same group
If a promotion with this setting is applied, no other promotions from the same promotion group can be applied to the order. For example, if this promotion is a catalog-entry promotion, no other catalog-entry promotions can be applied to the order.

3)Exclusive within an order
If a promotion with this setting is applied, no other promotions can be applied to the order.This option is labeled Exclusive within all groups

Priority of promotions

You can assign a priority to a promotion. When a single order qualifies for multiple promotions from the same promotion group, the promotion with the highest priority is applied first. In cases where multiple promotions are permitted, the promotions are applied in order from highest to lowest priority. For example, consider a store that offers two order-level promotions:

A 20% off your order promotion with a priority of 1.
A $50 off your order promotion that has a priority of 5.

If a customer's order qualifies for both, the second promotion is applied first, since it has the higher priority of 5. To assign a priority value, choose a number from 0 (lowest priority) to 1000 (highest priority).

In certain cases only the promotion with the highest priority is applied, with any other promotion not applied to a purchase regardless of its Combination with other promotions setting. For example, if the first promotion evaluated has an exclusive within an order setting, no other promotion is applied, even if it has a stackable setting. If multiple promotions have the same priority, the promotion engine randomly selects the order to evaluate the promotions. The remaining promotions are then applied based on their Combination with other promotions setting.

Steps to Make Product Promotions as Stackable

Out of the box, product promotions cannot be stacked, which means only 1 product promotion per item. Product promotions can be stacked with the following configuration and updates in database

Step1)Disable the policy 'Product: Any order item can only participate in one promotion' from px_policy  table .

Disabling the policy lets multiple product promotions be evaluated, otherwise just the one with the highest priority goes in (or in the case of equal priorities, whichever happened to be evaluated first.)

update px_policy set status=1 where px_policy_id in (select px_policy_id from px_policy where name like 'Product: Any order item can only participate in one promotion') and storeent_id = 11001;

update px_policy set xmlparam=replace(xmlparam,'Active','Inactive') where px_policy_id in (select px_policy_id from px_policy wherename like 'Product: Any order item can only participate in one promotion') and storeent_id = 11001;

Step2) Update\Save all promotions from accelerator/Management center so that existing promotions will be updated and can be stacked. Restart the server.

Step3)Setting PriceAdjustmentBasedOnStandardOfferPrice attribute in  WCSPromotionEngineConfig.xml.

In the WCSPromotionEngineConfig.xml, you have to disable the behavior true to false. This change will allow all the price adjustment based on discounted price or contract price displayed in the shop cart.

Product-level discount promotions are applied to the standard offer price. You can specify how the promotion engine handles cases where the offer price that a customer sees (as a result of a contract, or a price negotiation with a Customer Service Representative, for example) is less than the price that would result from applying the promotion.

<PriceAdjustmentBasedOnStandardOfferPrice>
true</PriceAdjustmentBasedOnStandardOfferPrice>

If this value is set to true, then the promotion discount is not applied if the offer price that a customer sees is less than the price that would result from applying the promotion. If it is set to false, then the promotion is applied.

Steps to Make Shipping promotions as Stackable

Out of the box, shipping  promotions cannot be stacked, which means only 1 shipping  promotion per item. Shipping  promotions can be stacked with the following configuration and updates in database

Step 1)Disable the policy 'Shipping: Any order item can only participate in one promotion'from px_policy  table .

Disabling the policy lets multiple product promotions be evaluated, otherwise just the one with the highest priority goes in (or in the case of equal priorities, whichever happened to be evaluated first.)

update px_policy set status=1 where px_policy_id in (select px_policy_id from px_policy where name like 'Shipping: Any order item can only participate in one promotion')  and storeent_id = 11001;

update px_policy set xmlparam=replace(xmlparam,'Active','Inactive') where px_policy_id in (select px_policy_id from px_policy wherename like 'Shipping: Any order item can only participate in one promotion') and storeent_id = 11001;

Step 2) Update\Save all promotions from accelerator/Management center so that existing promotions will be updated and can be stacked. Restart the server for the changes to take effect.


Steps To Make Order promotions as Stackable

Step 1)Disable the policy ‘Order: One per group'from px_policy  table.

update px_policy set status=1 where px_policy_id in (select px_policy_id from px_policy where name like ‘Order: One per group ' and storeent_id = 11001);

update px_policy set xmlparam=replace(xmlparam,'Active','Inactive') where px_policy_id  in (select px_policy_id from px_policy where name like 'Order: One per group'  and storeent_id = 11001;);

Step 2) Update\Save all promotions from accelerator/Management center so that existing promotions will be updated and can be stacked. Restart the server for the changes to take effect.

Promotion Data Models

PX_PROMOTION  -This table contains promotions.

PX_GROUP- This Table contains the promotion groups for the site.

PX_GRPPOLICY -This table contains relationships between promotion groups and promotion policies.

PX_POLICY - This table contains promotion policies.

CATENCALCD -  A row in this table indicates that a CalculationCode is attached to a CatalogEntry. And it is also attached to the CatalogEntry's PRODUCT_ITEM children (or all CatalogEntries) for the specified Store. And also it is attached to TradingAgreement (or all TradingAgreements).

CATGPCALCD – A row in this table indicates that a CalculationCode is attached to all CatalogEntries (and their PRODUCT_ITEM children) in a CatalogGroup for the specified Store and TradingAgreement (or all TradingAgreements).

CLCDPROMO -This table stores information about the relationship between the Calculation Framework and the promotion standalone infrastructure. Each calculation code matches one promotion in the PX_PROMOTION table.

PX_USAGE -This table tells about statistics the promotion usage. Also contains the ORDERS_ID of the orders to which the promotion was applied.

PX_COUPON -This table contains all of the coupons issued to individual customers. Also contains the ORDERS_ID of the orders to which the coupon was applied.

PX_DYNATTR -This table contains the details about any dynamic attributes that belong to promotion entities, such as promotion groups, promotion policies, and others.

PX_PROMOARG- This table contains details about how promotions are applied to an order. This table contains the history of promotions applied to an order.
PX_PROMPROM-Reserved for IBM internal use.

PX_TPLTGRP - Reserved for IBM internal use.

PX_TEMPLATE- Reserved for IBM internal use.

Enabling debug / Trace for promotion engine

Open WCSPromotionEngineConfig.xml

Change

<DefaultBehavior>
<StatelessInvocation>true</StatelessInvocation>
<CheckTargetingAtRuntime>true</CheckTargetingAtRuntime>
<SkipTargetingOnCodeEntered>true</SkipTargetingOnCodeEntered>
<PriceAdjustmentBasedOnStandardOfferPrice>true</PriceAdjustmentBasedO     

 nStandardOfferPrice>
 <Debug>false</Debug>
 </DefaultBehavior>

to

<DefaultBehavior>
<StatelessInvocation>true</StatelessInvocation>
<CheckTargetingAtRuntime>true</CheckTargetingAtRuntime>
<SkipTargetingOnCodeEntered>true</SkipTargetingOnCodeEntered>
 <PriceAdjustmentBasedOnStandardOfferPrice>true</PriceAdjustmentBasedOnStandardOfferPrice>
 <Debug>true</Debug>
 </DefaultBehavior>


Save and Restart the server.
 
Merchandising associations in Websphere Commerce

The merchandising associations are used to increase store sales by recommending similar products. In addition to promotional associations such as cross-selling, up-selling, and suggested accessories, key words highlight extra semantic information of merchandising relationships, such as requires and comes with.

Merchandising association has one source catalog entry and a target catalog entry. For example, if a shirt has a tie as an accessory, the shirt can be the source entry and the tie can be the target entry. A source catalog entry can have multiple associations, therefore multiple target entries. Continuing the previous example, the shirt can have both a tie and cufflinks as accessories. In this case the shirt remains the source entry, while the tie and cufflinks are each target entries. After a merchandising association is created, from the source catalog entry you can determine its associated target catalog entries.

We can create the following catalog entry merchandising associations as listed below.

Cross-sell
A merchant suggests other catalog entries based on an already chosen catalog entry. Eg:A merchant can suggest a printer when a  Desktop is purchased.

Up-sell
A merchant suggests a better catalog entry based on the one selected. Eg: a merchant can suggest a higher quality LED TV when a low-end model is selected.

Accessory
A merchant suggests an accessory that will complement the selected catalog entry .Eg: A merchant can suggest an extra storage device when a laptop is selected.

Replacement
A merchant indicates that the relationship between two catalog entries is considered equivalent. Replacement is only valid when two catalog entries are of the same catalog entry type: product, package, bundle or dynamic kit. For example, if one type of brand name laptop is sold out, a merchant can suggest a different brand name laptop, as long as both laptops are products.

Custom
You can create custom merchandising association types based on your requirements. Eg:Offer a down-sell merchandising association to suggest lower-priced catalog entries based on the selected catalog entry.Merchandising associations can be static, which is a fixed relationship, or dynamic, which customizes rules and queries to form personalized associations.

Merchandising association Management
We can manage merchandise association from Web sphere Commerce Accelerator. We can find, create, delete and change merchandise association between catalog entries.


Merchandising association in Websphere Commerce



Merchandising association in Websphere Commerce

Merchandising associations Tables
MASSOC  :This table holds all of the possible semantic specifiers that can be used when associating CatalogObjects.The semantic specifier may be "REQUIRED", "NONE", "TEMP", or "COMES WITH". Other types of specifier can be added.

MASSOCTYPE: This table holds all of the possible types of associations that can exist between CatalogObjects.E.g.: of massocytpe will be X-SELL", "UPSELL", or "ACCESSORY".

MASSOCCECE :This table holds the merchandising associations that exist between CatalogEntries. 

MASSOCGPGP: This table holds the merchandising associations that exist between CatalogGroups.


1 comment:

  1. I really appreciate information shared above. It’s of great help. If someone want to learn Online (Virtual) instructor lead live training in TECHNOLOGY , kindly Contact MaxMunus
    MaxMunus Offer World Class Virtual Instructor led training on TECHNOLOGY. We have industry expert trainer. We provide Training Material and Software Support. MaxMunus has successfully conducted 1,00,000 + trainings in India, USA, UK, Australlia, Switzerland, Qatar, Saudi Arabia, Bangladesh, Bahrain and UAE etc.
    For Demo Contact us.
    Saurabh srivastava
    MaxMunus
    E-mail: saurabh@maxmunus.com
    Skype id: saurabhmaxmunus
    Ph:+918553576305
    www.MaxMunus.com


    ReplyDelete