This concept provides an overview of how to configure promotion inclusion/exclusion groups and explains some implementation aspects.
In general, a promotion can be applied to orders, to shipping costs, or to a single product. The inclusion/exclusion feature applies to the product item level.
However, there may exist some products which should not be discounted at all. Therefore, an inclusion/exclusion feature has been implemented to define
The granularity varies from selecting categories to picking up single products. Selecting a category means that all products belonging to this category, and those belonging to any child category, will be considered.
There may exist products which cannot be discounted at all. It is inconvenient to define the set of excluded products for each promotion. Therefore, it is possible to define one product exclusion group which is valid for all promotions of an application.
Another way is to define a set of excluded categories. This is the more convenient way to exclude all products of a category instead of adding them to the exclusion list individually.
Setting up application level exclusion groups can be done at <channel> | Applications | <application> on the Promotions tab under Application Level Exclusions.
Application level exclusion groups are valid for all promotions of an application that belongs to a consumer channel.
Product inclusion/exclusion groups of a promotion can be defined for conditions, as well as for actions:
The promotion discount may be based on the order, an item, the shipping costs or a free gift. Each of these promotion discount types can be configured to trigger a specific promotion action, e.g., an item percentage off discount.
If a product is in an inclusion set at promotion level, but also in the application level exclusion set, it will not be considered! To overrule this regulation, the flag Override Application Level Exclusions must be enabled. In general, exclusions win over inclusions.
Per default, application level exclusions are stronger than promotion level definitions. However, each promotion can be configured to overrule the setting.
This subsection does not cover all implementation done in detail, but it explains some interesting aspects.
A promotion can have more than one rule. Internally, this is represented by an instance of
Rebate. Each rule consists of one or more conditions and one action. Currently, only one action can be configured, but the framework itself allows more than one action.
As mentioned before, each condition and action can have groups of included or excluded products, or categories respectively. Internally, inclusion/exclusion groups are represented by an instance of
RebateFilterGroup. It can be one of two types:
The scope is one of this.
All business logic to access filter groups, to assign them to/unassign them from conditions/actions are provided by
The items assigned to a rule filter group are referenced by
RebateFilterObjectAssignment. It maps the item's id (product or category uuid) to the rule filter group id.
RebateFilterGroupAssignment references a rule filter group to a condition or action.
The application level exclusion is represented by an instance of
RebateFilterGroup with scope APPLICATION. If there are neither product nor category exclusions defined, no
RebateFilterGroup will exist. If all products or categories are removed from an existing application exclusion group, the instance of
RebateFilterGroup will be removed as well.
RebateFilterGroupRepository provides methods to handle application-wide inclusion/exclusion groups.
Enfinity Suite/Intershop offers wizards to select products and categories. These wizards are used for assigning products or categories to inclusion/exclusion groups.
ViewPromotionRebateInclusionsExclusions provides call and callback nodes for the product and category wizards at promotion level, and the pipeline
ViewApplicationPromotionPreferenceInclusionsExclusions likewise at store level.
There are some important parameters which must be passed to the wizard for proper working.
Name of the component, not important.
Who calls the component. You can use it e.g. in component templates to place special text.
The start pipeline of the component.
The callback pipeline of your application.
The callback pipeline of your application will expect the returnValue with this dictionaryKey.
The callback-pipeline in case of "cancel" button is used (optional).
A pipeline within your application in case of "back" button at component.
In addition, all parameters passed to and through the wizard must be stored in a map named
PipelineComponentParameters. This map is kept in the session and passed back when returning to the caller pipeline.
Furthermore, each wizard requires some individual parameters:
select one or more products
ProductSelectionFinishButton- text of button, if should differ from "Finish"
select one or more categories
AlreadySelectedCategoryUUIDMap- map of uuid->uuid, lines are marked selected/grey
select one or more categories
AlreadySelectedCategoryUUIDs uuid iterator of categories, which already have been selected before
The central processing of assigning/unassigning items to and from a rule filter group is done in
ProcessPromotionRebateInclusionsExclusions-AssignOrUnassignAllObjects. Depending on the number of returned elements the assignment/unassignment of products/categories to/from the rule filter group may be performed in a batch job.
The threshold is configured in
# Threshold to perform the product and category assignment to a promotion's rebate filter group in a batch job. intershop.cartridges.bc_marketing.promotion.assignment.threshold = 1000
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.