Summary of enhancements:

  1. Multi-location order allocation for single order line item
  2. API to retrieve orders that are on hold
  3. Delivery Mode as an Evaluation Criteria for Order Allocation Rules.
  4. Channel as an Evaluation Criteria for Order Allocation Rules .
  5. Adding activity log for auto refunds.
  6. DevAPI to support only modification of refund status



Multi-location order allocation for single order line item

Context:

  • Currently, a single order line item cannot be fulfilled by multiple locations. 

Use case:

  • Product A has total 10 stock available with the following split amongst stores:

    • Store 1: 2 Qty

    • Store 2: 2 Qty

    • Store 3: 3 Qty

  • When an order gets placed for the above ‘Product A’ with quantity more than 6, it will get allocated to default location as no store can fulfill this individually. 

  • Due to this if an order is placed with quantity more than the stock that is available in each location, then the order will get assigned to the default location.

Solution:

  • A new merchant level config has been added to the Control Panel: ‘Settings’ -> ‘Application Settings’ -> ‘Order Settings’ -> ‘Order Settings’ -> ‘Split/Cumulate Order Line Items during allocation’

  • If this config is enabled, the ordered item will be split into multiple line items and fulfilled individually if it cannot be fulfilled by a single location according to the existing order allocation rules

CP Snapshot: Configuration in CP

  • When the ‘Split Order Line Items’ config is enabled, the following flow will be followed:

    • When an order gets placed, ‘AllocationWithoutCommit’ API (not exposed) gets called. This API will check the existing rules one by one and if it can be fulfilled by the existing rules, it won’t split the ordered item into individual line items and the regular flow is followed. 

    • If it is not, while the creation of order itself, the ordered item gets split into multiple line items. 

    • For the ordered item that has been split, all entities such as shipping amount, tax, discount will also be split. 

    • Now, each of these items will run through the order allocation rules and will be fulfilled as individual line items.

    • The use case for ‘Product A’ that has been explained above will now get fulfilled by a combination of 3 locations instead of getting allocated to the default location.

  • Note: The split line item flow will only be followed if the allocation rule is one of the following:

    • Transfer to store which has more stock

    • Transfer to nearest warehouse

CP Snapshot: One order item with 2 quantities has been split into two line items and has been allocated to two locations since a single location cannot fulfill it. 



API to retrieve orders that are on hold

Context:

  • Currently, we have the provision to hold or unhold an order. Clients use this provision to hold an order if they don’t intend to process it for a while and they unhold and process it once they want to process that order. 
  • The orders in hold for more than a specific duration needs to be canceled. For example, a merchant might want to cancel orders which are on hold for more than 15 days.
  • There is no way to fetch all orders that are in hold and make a decision on whether to unhold and proceed or to cancel it. 

Solution:

  • An API “getOrdersOnHold” has been exposed which will take the following parameters as input:

    • Merchant ID

    • From Date

    • To Date

  • The API returns the following details as output for the orders that are created in the from and to date passed and are in hold state.

    • orderld

    • orderDate

    • orderStatus

    • orderSubStatus

    • merchantId

    • referenceNo

    • channeld 

    • channelOrdrderld

    • orderItemList

    • itemld

    • onHoldstatus

    • totalPrice

    • amountPayable

Sample Request: 

https://qa-gateway.ecom.capillary.in/oms/v1/order/getOrdersOnHold/{{Merchantid}}?oauth_consumer_key=DTEBBUBR&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1588666636&oauth_nonce=tEhklT&oauth_version=1.0&oauth_signature=HcR/c/u0745sCRZ+umMHT1kLCRg=&FromDate=2020-04-05&ToDate=2020-05-05

Sample Response:

{

"entity": 

[

'orderld: 9792123, 

'orderDate': '2020-05-28T15:28:13-, 

'orderStatus': “A”,

'orderSubStatus’: null, 

'merchantId': “ ”,

‘referenceNo’: “ “, 

"channeld": 0, 

'channelOrdrderld': null, 

'orderItemList': 

    {

'itemld': “ “, 

'onHoldstatus’: true

}

]

"totalPrice”: 549,

“amountPayable”: 549

],

"uniqueId": null,

"warnings": [],

"errors": []

}


Delivery Mode as an Evaluation Criteria for Order Allocation Rules

Context:

  • Currently, the system supports order allocation rules based on ‘Delivery areas’.

  • A new filter to only select orders that are Pickup at Store or Home Delivery orders. This will help keep order allocation of home delivery and pickup at store orders separate.

Solution:

  • A new option ‘Delivery Mode’ has been added to the drop-down in the ‘Create Rule’ pop up (‘Orders & Leads’ -> ‘Order Allocation’ -> ‘Create Rule’).

  • When the ‘Delivery Mode’ option is chosen, the user gets to choose between ‘Home Delivery’ or ‘Store pickup’.


CP Snapshot: 



Channel as an Evaluation Criteria for Order Allocation Rules

Context:

  • Currently, the system supports order allocation rules based on 2 evaluation parameters namely ‘Delivery areas’ and ‘Delivery mode’. 

  • Merchants handle orders flowing through multiple pre-configured channels and hence require allocation based on the ‘Channel ID’ as well.

Solution:

  • A new option ‘Channel ID’ has been added to the drop-down in the ‘Create Rule’ pop up (‘Orders & Leads’ -> ‘Order Allocation’ -> ‘Create Rule’).

  • When the ‘Channel ID’ option is chosen, the user gets the option to choose amongst the multiple predefined channels.

  • Channels can be defined from the ‘Control Panel -> Settings -> Store Information -> Channel Management’ page. 

  • One allocation rule could have more than one channel selected using the AND/OR functionalities in the ‘Create Rule’ pop-up.


Adding activity log for auto refunds

Context: 

  • Currently, the activity log records ‘Refund Initiated’ status update, but does not log activity for ’Refund Completed’. Since there is no ‘Refund Completed’ status update that is being displayed in the activity logs, the clients cannot monitor who processed the refund and when the refund got completed.

  • Because of activity logs not recording ‘Refund Completed’ status, the activity logs seem to be inconsistent and might cause confusion. 

Solution:

  • Provision to log ‘Refund Complete’ status update in activity logs has been added by means of an internal API. Now the user will be able to monitor both refund initiated and refund completed activities. 

CP Snapshot:


DevAPI to support only modification of refund status

Context: 

  • Currently, we have a UpdateReturnRequestStatus dev API which updates the status of the return request, but a DevAPI that will change only the refund status for a particular order does not exist. Due to this, the status has to be updated manually via CP.

Solution:

  • An API has been exposed to allow updation of refund complete status. 

  • Input parameters:

    • Merchant ID

    • Return Request ID

    • Order ID

    • Refunded Amount

    • Close return (True/False)

      • True: Will close the return along with the RC (refund complete) status update.

      • False: Will just update RC (refund complete) status. 

  • Note: Holds true only for Customer Return and not for RTO. 

Sample Request:

http://omsjava.martjack.internal/v1/refunds/update/{{merchant_ID}}?orderId={}&RefundedAmount={}&RefundStatus={}&closeReturn={true/false}

Sample Response:

{

    “entity” = “REFUND_STATUS_UPDATED_SUCCESSFULLY <Return Request ID>”,

    “uniqueId” = “955777”,

“warnings” = [],

“errors” = []

}