Monday 8 August 2011

Websphere Commerce - Order Release flow

The following outlines about what should happen for an Order to get released for fulfillment. A schedular entry runs and invoks the following command for releasing Order for fulfillment.

ReleaseToFulfillmentCmd
This is used to release orders to a fulfillment center for a given store.
  • It identifies all the orders that needs to be released by executing Query.
  • For each order, 
    • if the current order is blocked, this order will not be further processed
    • Call ReleaseOrdersToFulfillmentCOCmd

ReleaseOrdersToFulfillmentCOCmd
Used for releasing an order for fulfillment.
  • The list of orders that are available for release are resolved by calling ResolveReleasesCmdImpl. This command updates ORDERREL table. This table holds the relationship between parent and child order. In an order, if an item is tied with "tieShip Code", this command will try to tie the item to 1. Future order or 2. Backorder or 3. Make the item available for release
  • For the list of orders ready for release, ReservePaymentCmd is called. Two things can happen,
    • If this command returns EDPResults.STATUS_SUCCESS_INT, and if all items are released for fulfillment, a storedProc is run to update the ORDER.STATUS to 'R'
    • For all other response from this command, items will not be released to fulfillment, they will be processed in the next scheduler job
    • Incase of an error in ReservePaymentCmd, a tickler is created withOrderConstants.TICKLER_FINANCIAL_TRANSACTION_ERROR

ReservePaymentCmd
This command is used to reserve payments in payment rules subcomponent and is associated with release to fulfillment.
The possible payment actions are: Approve, Deposit, ReverseApproval
E.g., A customer order is selected for fulfillment by the schedular. All the items are ready to be shipped, to the same location, thru same carrier at the same time. This command is called and
  • Payment rules are read
  • Payment actions are identified
  • Payment instructions are identified and are used in the order they are configured, based on the payment method configuration
Now, if the target state is approved, and was not previously approved, the payment will be approved now, else if it is already approved, re-approval will not happen, else if payment fails in the backend system, a tickler will be send to CSR.