Info
This Migration Guide applies for 7.10.12.2+ and 7.9.4.11+.
Introduction
A basket may contain several promotions that are triggered by a condition or by a promotion code. In the past the created order of a basket that contained promotions only stored the IDs of the used promotions without any further information. The ID was then used to retrieve the information from the existing promotion objects in order to display them in several order detail views in the back office as well as in the My Account | Order History | Order Details section. This approach is very efficient because no redundant information is stored. However, the disadvantage was that promotions had to remain in the system for a long time or even for the system lifetime because the impacts of a removal of a promotion were not entirely clear. As a result, the number of promotions in the system increased more and more, making it very difficult to manage the promotions. The total number of promotions in the system, including the ones that are not active, also influenced the whole system's performance significantly.
In order to overcome these problems mentioned before, the order creation process has been adapted to store the relevant information of all used promotions directly at the order.
Since an order can contain multiple promotions which include a lot of textual information for multiple languages, the data might need a lot of space when storing all information is necessary. For that reason, the promotion information stored in the order has been restricted. The following table provides an overview about the information that is stored:
Promotion Field | Description | Displayed | Languages |
---|---|---|---|
UUID | Internal UUID | Backoffice | - |
Promotion ID | Promotion ID that is entered when creating a promotion | Backoffice | - |
Disable Messages Flag | Flag that indicates if the maintained title/long title is displayed for this promotion or not | Storefont | - |
Promotion Code | Used promotion code if promotion was code-based | Backoffice | - |
Amount Net | Net amount of the promotional discount | Backoffice/Storefront | - |
Amount Gross | Gross amount of the promotional discount | Backoffice/Storefront | - |
Display Name | Name of the Promotion | Backoffice | max. 3 languages* |
Title | Promotion Title (shown in the order details) | Storefront | max. 3 languages* |
Long Title | Promotion Long Title (promotion details dialog in order details) | Storefront | max. 3 languages* |
Legend:
Orders that include the promotional information are marked with a boolean attribute value "PromotionMessagesFlag".
Note
The complete promotional information that is maintained in the back office and displayed in the storefront consists of
Only the values printed in bold type are stored in the order. For this reason it is recommended not to remove the promotion from the system until a certain time, especially after legal claims are expired.
The OrderBO
extension "OrderBOAppliedRebateExtension"
to retrieve the promotional data from the data has been partly deprecated since all methods that return a collection of "AppliedRebateBO"
rely on existing promotions in the system. As a replacement there is a new OrderBO
extension called "OrderBOPromotionInformationExtension"
which contains all methods that have been deprecated with the same name, but returning a collection of "PromotionInformationBO".
All other methods from OrderBOAppliedRebateExtension
that are not deprecated can also be found in the new OrderBOPromotionInformationExtension
and can be used likewise.
The same applies for "OrderProductLineItemBOAppliedRebateExtension
" and "OrderShippingBucketBOAppliedRebateExtension
". All methods returning a collection of "AppliedRebateBO"
are deprecated and should not be used anymore. There are new extensions "OrderProductLineItemBOPromotionInformationExtension
" and "OrderShippingBucketBOPromotionInformationExtension
" to retrieve the new "PromotionInformationBO
".
From ICM version 7.10.16.1 on these new extensions are only available for migrated (see next chapter 'Migration') or newly created orders. Otherwise the extensions are null. This can be used to distinguish between old orders that are not migrated yet and new respective migrated orders.
OrderBOAppliedRebateExtension | OrderBOPromotionInformationExtension |
---|---|
Collection<PromotionInformationBO> getAppliedItemValueRebates() | |
Collection<PromotionInformationBO> getAppliedItemValueRebates(boolean hasPromoCode) | |
Collection<PromotionInformationBO> getAppliedOrderValueRebates() | |
Collection<PromotionInformationBO> getAppliedOrderValueRebates(boolean hasPromoCode) | |
Collection<PromotionInformationBO> getAppliedOrderShippingRebates() | |
Collection<PromotionInformationBO> getAppliedShippingRebates() | |
Collection<PromotionInformationBO> getAppliedShippingRebates(boolean hasPromoCode) | |
Collection<PromotionInformationBO> getAppliedRebates() | |
Collection<PromotionInformationBO> getAppliedRebates(String promoCode) | |
Collection<PromotionInformationBO> getAppliedRebates(boolean hasPromoCode) |
OrderProductLineItemBOAppliedRebateExtension | OrderProductLineItemBOPromotionInformationExtension |
---|---|
Collection<PromotionInformationBO> getAppliedRebates(); | |
Collection<PromotionInformationBO> getAppliedRebates(String promoCode); | |
Collection<PromotionInformationBO> getAppliedItemValueRebates(); | |
Collection<PromotionInformationBO> getAppliedItemShippingRebates() | |
Collection<PromotionInformationBO> getAppliedItemGiftRebates() | |
Collection<PromotionInformationBO> getAppliedItemHiddenGiftRebates() |
OrderShippingBucketBOAppliedRebateExtension | OrderShippingBucketBOPromotionInformationExtension |
---|---|
Collection<PromotionInformationBO> getAppliedShippingRebates() |
All standard ISML templates (back office and storefront) can handle promotional information from the orders as well as information from existing promotion objects. Since an order is marked if the promotional information is included or not, the templates include conditions to support both cases. The back office templates usually provide a link to the used promotion if the promotion exists in the system. If it does not exist in the system, the title is displayed without link.
The promotional information is stored automatically at the order for all new orders. As long as existing promotions should not be removed from the system, there is no need to migrate old orders since all templates involved are prepared to handle old and new orders as well. Nevertheless, a clean up of expired and inactive promotions should be done from time to time. If this is done, a migration of old orders is recommended to obtain the information displayed for the customers in the storefront as well as for the Shop Manager in the back office.
A migration pipeline has already been prepared, but a migration job the executes the pipeline has to be created manually as described in the next section.
The log file of the job contains information about migrated orders:
[2019-07-16 15:30:39.344 +0200] [JobExecutor288850583] [Job:MigrateOrdersWithPromoInfo] [Req:R4sKAEsBIU0AAAFr7VdhcPr6] INFO ProcessOrderPromotionInformation - No orders to migrate for channel: Shopping Live [2019-07-16 15:30:39.358 +0200] [JobExecutor288850583] [Job:MigrateOrdersWithPromoInfo] [Req:R4sKAEsBIU0AAAFr7VdhcPr6] INFO ProcessOrderPromotionInformation - No orders to migrate for channel: Reseller Channel [2019-07-16 15:30:39.367 +0200] [JobExecutor288850583] [Job:MigrateOrdersWithPromoInfo] [Req:R4sKAEsBIU0AAAFr7VdhcPr6] INFO ProcessOrderPromotionInformation - No orders to migrate for channel: inTRONICS Business [2019-07-16 15:30:42.242 +0200] [JobExecutor288850583] [Job:MigrateOrdersWithPromoInfo] [Req:R4sKAEsBIU0AAAFr7VdhcPr6] INFO ProcessOrderPromotionInformation - Migrated 1000 of 58662 orders for channel: inTRONICS
Now it can be decided if the job must be executed several times or not.