Modifying Submitted Orders in IBM Websphere Commerce

Modifying submitted orders in IBM WebSphere Commerce 8, its limitations and customization options

The new IBM Websphere Commerce Suite 8 (IBM WCS) supports many check-out scenarios. However, modifying submitted orders via 3rd party software and presenting the results to the customer on the shop storefront require a tailored interaction between Order Management and IBM WCS.

In E-Commerce, order submission is perceived as a final act. The buyer has accepted the offer, we have a deal. Fixed and clear. Yet there are situations where the buyer or seller has a good reason to modify the initial order even after it has been submitted. The buyer may want to add something to their cart or change the quantity of the ordered product. The seller may need to remove an item that is not in stock or replace it with a similar product (if the buyer accepts this). These are everyday situations, especially in industries where orders usually consist of many items, and it takes some time before the order is assembled and ready for shipment. Enabling both parties to make these modifications will improve the user experience and ramp up business efficiency at the same time.

In this post, we will look into two user stories:

• “The picker story”

Picker makes changes to the order using 3rd party software; changes are applied to the IBM WCS after the order has been submitted.

• “The buyer story”

Buyer wants to modify the already submitted order.

The picker story

Let’s take a closer look at how the 3rd party Order Management system (OMS) modifies the submitted order and passes the modifications back to IBM Websphere Commerce to complete the order. Here I present a hands-on use case for a food retailer.

In groceries, products are sold by weight. The buyer may order one pound of apples, but five apples never weigh exactly one pound. There will always be some discrepancy compared to the target quantity. In order to ensure the buyer will pay for what they get, the order has to be recalculated to match the shipped quantities.

Picker has to modify the original order to match the picked quantities or they may replace or delete some items that are not in stock. Picker records the changes in the 3rd party OMS. When the modified order is complete and ready for shipment, the 3rd party OMS passes the modified data back to IBM WCS to upgrade the initial order.

The “Picking” process flow

User logs into an online store, adds items to the shopping cart and submits the order. 3rd party OMS receives the submitted order, modifies it, completes the picking and sends the order to WCS to prepare the order for shipment. The user is able to see the modified order in the online store under My Account / Order History.

OOTB Websphere Commerce options for changing submitted orders

A user with the proper role, like a CSR (Customer Service Representative), can carry out some modifications to the submitted order in WebSphere Commerce Accelerator.  Basically, the supported changes are adding/removing items and modifying the final total product price. (For more information, see: https://www.ibm.com/support/knowledgecenter/en/SSZLC2_8.0.0/com.ibm.commerce.user.doc/tasks/tcochg.htm).

WebSphere Commerce Accelerator is useful for business users with some experience in WebSphere Commerce. The most attractive feature for CSR users is the ability to log-in to a storefront and enact the user, changing the pending (not submitted) orders in the storefront.

Order Recalculation WS (Web Service)

Considering the “Picking” user story, we need to develop a web service to process the modified order data that includes order items’ IDs in new quantities to recalculate prices and promotions and to modify the initial order in WCS. We may also need to modify the order status (we can use one of the WCS order statuses) to mark the order as “Ready for shipment” for example.

Let’s say, for example, that during picking some items were removed and new ones were added. The 3rd party OMS will call the Order Recalculation (OR) web service to pass the request. OR will modify the order to reflect the modifications made in the picking process and send it back to the 3rd party system as ready for shipment. Here we need a custom order process logic to recalculate the order based on the input data. The input data contains order items’ identifiers and corresponding quantities. Ideally, order recalculation would recalculate prices and promotions based on current prices and promotions. However, retailers might want to offer the user items for the price at the time of the initial order submission (which may have been some days ago).

Ensuring the submitted prices and promotions after order is picked

In the period between the order submission and the start of the picking process, the prices can change, especially if the picking process takes a few days to complete. Perhaps the initial promotions are no longer valid or they have expired. Retailers may not want to promise the user an item at a certain price, and then after the picking process is completed, the user would need to pay another, higher price.

The retailer needs to consider the cost of promising the user items at the old price and based on old promotions. As a developer, you need to be extremely careful when calculating and modifying promotions and prices in IBM Websphere Commerce. For the new items, we can reuse some of the OOTB logic to calculate and apply the prices, but for the old items, we need to do the calculations based on the old prices and amounts (prices of the initially submitted items). For old items, we must modify the data in respective tables in the database. If possible, reuse the Promotion Engine logic for calculating promotions. Here we face a challenge – how to handle old prices and old promotions if they are no longer valid?  For example, we have a promotion “Buy X, get Y at 50 % off”. Let’s assume X was removed during the picking process.  In this case, Y should be charged at full price. Nevertheless, a retailer may want to grant customers the initial discount.

Let’s add these requirements to our user “Picking” story:

1. Old items (old items are items in the initially submitted order, new items are items added during the picking process) have old prices with old promotions applied (even if these promotions are no longer valid).
2. If old item is increased in quantity, it is thereafter considered a new item and requires a new position.
3. New items have new – current prices and current promotions are applied.
4. When evaluating Catalogue-entry-level promotions, only new items are considered (If 2+1 promotion is active and old items already has 2 and the new item has 1, the promotion will not be applied, because old items are ignored when validating promotion consideration).
5. New (current active) order-level promotions are applied to all items (old and new).

The above conditions may not seem logical or intuitive, but for specific businesses, this could be the required condition. When we are required to change an order and keep some items at old prices and promotions, we would probably need to keep the original order and modify a copy of it, just for calculation purposes. This is especially needed if we allow the picker to call the OM web Service multiple times (to run in-between calculations before the final calculation). In a simple scenario, picker would pick items only once.

Considering the process requirements, we might need to modify the Websphere Commerce storefront under My Account/ Order History to present the buyer with the original (submitted order) as well as the modified (picked order) order, the latter representing an invoice.

How to handle payments

In the order modification scenarios described so far, the final price will very likely differ from the price of the initial order. Consequently, the Websphere Commerce OOTB payment process has to be upgraded to a two-step payment model to handle these differences.

By submitting the order, the first payment step is executed – authorization and reservation of funds. In the second step, the OM web service executes the payment – funds are received. The two-step payment process is required for all payment providers, e.g. credit card or PayPal. Payment providers normally allow for a 10-15% higher payment as reserved funds. To handle two-step payments, we need to customize the integration with Payment Plug-in and develop a Web service (Final Payment) to verify the final invoice and complete the payment.

The buyer story

So far, we have looked into the process invoked by a 3rd party OMS to prepare the order for shipment. Now, we would like to enable buyers to change orders themselves within a certain timeframe, let’s call it lead time before the picking process starts.

In many web stores, the picking process might start just a few hours before the desired delivery date.  Why not allow customers to add an item or two in the meantime, before the picking starts?  Let’s assume the customer submitted an order on Friday, with the desired delivery on Monday afternoon. The customer runs out of milk on Sunday and would like to add some to the order.

Considering the out-of-the-box features, the customer cannot modify the order after it has been submitted. If we are to alter the default process, we have to consider:

• Modifications to the storefront My Account/ Order History page – added option “Change order”
• Business logic to set the order “lead time”. If lead time is exceeded, “Change order” is not permitted.
• Business logic for creating a copy of an order, keeping a reference to the original order and redirecting the copy to the Shopping Cart
• Modification of the Shopping Cart storefront, displaying a note like “You are modifying order X.”
• Business logic for all steps of the Checkout process to verify if lead time is exceeded. In that case, the customer should be allowed to cancel the modifications or move the contents to a new order.
• Business logic on order submission, so that the old order is soft-deleted and its submitted (modified) copy can be modified again.

To sum up, upon order change, we have to put the contents of the original (submitted) order in a new (pending) order. Technically speaking, no customization is needed for calculating prices and promotions, because we use the OOTB order processes. We just need a system for order copy tracking and handling on the storefront.

Some considerations:

• What if the order has already been shipped by the 3rd party OMS (picking process is active) while the user is still modifying it? In this case, the user should be able to discard the order change or/and move the order’s contents to a new pending order.
• How to handle the hierarchy of pending orders if the user decides to modify one of them, making it the most current order? We should offer the user the option to
• merge the contents of the current pending order with the about to be changed order
• discard the current pending order

Why storing order copies can be challenging

First of all, to manage order copies for order change purposes properly, all order references and statuses have to be considered. This, in turn, brings a certain level of complexity to the system that is demonstrated in the diagram below.

Copying an order introduces new issues to be handled, for example:

• promotions with redemption limit set. This must be handled by overriding the IBM WCS logic for exceeding redemption count for promotions in copied order.
• promotions with “use only once” promotion codes. Once an order is copied, its promotion code is also copied; this would basically mean that the same promotion code was applied to 2 orders, but from the user’s perspective it is only one order and should be applied only once. That is why we need to delete the entry in the PX_CDUSAGE table for the copied order.
• in the case of timeslots based delivery concept, we must handle the copied order so that it has the same shipping cost as the original order but in fact does not have a delivery slot (it has to use the delivery slot of the original order)
• When copying an order for the “Buyer story”, we handle the copied order as the current valid order, so we move all specific data to the new order. If this order (order being modified) is discarded, we need to move all the data back to the original order.But when copying an order for the “Picker story” (for example, as a result of Order Recalculation WS), we need to keep the specific data on both orders and make sure that the copy does not affect the business logic.

To wrap it up

Modifying a submitted order via a 3rd party OMS entails a series of modifications in theIBM Websphere Commerce order process. Here, business logic has to be paired with the solution design in order to meet the user requirements and develop a robust ordering scenario. I hope I have given you some ideas regarding what could be done on top of the IBM WCS 8.