Bol Order Refund
Summary of Changes: (The purpose of this table is to keep traceability and Product team to highlight the things that were changed into the scope, based on comments or discussions)
Date | Version | Created / Updated | Notes |
---|---|---|---|
10/05/2023 | v1.0 | Bogomil Pavlov | First publish |
17/07/2023 | v1.1 | Danail Deltchev | Clean up and additional explanations |
19.07.2023 | v1.2 | Bogomil Pavlov | Order Item Id per request |
15/08/2023 | v1.4 | Bogomil Pavlov | Response mapping changes |
The purpose of this document is to describe how we get refund orders on Bol.
<v1.1>Bol do not have the concept of “Refund” (money transaction) that we can use. Everything is handled by a “return” functionality working on a quantity by quantity basis. As for the cancellation we might have a return request initiated by the buyer OR even without any such a return request created by the seller. As there is no other way to “refund” a customer the below flow explains what we want to do when there is nothing initiated by the buyer but the seller still wants to send money back - hence “Refund”
This flow is to be treated as Hemi Post Shipment Refund flow</v1.1>
If we would like to refund a Shipped or Partially Shipped order without the buyer to request a return we simply have to create a refund in Hemi which will create an automatically processed return request on Bol (as if the buyer requested it but directly fully processed) Please note only full quantity refunds are allowed. We should add additional validation if we try to refund a part of a line to return an error. We want all triggers, status, error handling, etc. to be as per the Refunds send general logic and should be selected only for orders with status Shipped or Partially Shipped.
</v1.2>Please note we can refund one orderItemId per request which means for each refund row we will have to make separate request. Thus we want to make additional validation and if we have more than one refund rows in a refund to return an error. However with the story for the Refund UI we will add logic there when we are creating refund from the UI to split them by refund rows</v1.2>
Create Return
API Call: POST https://api.bol.com/retailer/returns
API Doc: https://api.bol.com/retailer/public/redoc/v9/retailer.html#operation/create-return
*Sample Request Body:*Please note we can have only one order item id per request
{
"orderItemId": "2012345678",
"quantityReturned": 1,
"handlingResult": "RETURN_RECEIVED"
}
Mapping:
Bol Field | Hemi Field | Comment |
---|---|---|
orderItemId |
Product In Order > Item Order Line ID | |
quantityReturned |
Based on the Refund Row > Amount we have to calculate the quantity | |
handlingResult |
“RETURN_RECEIVED “ |
Hardcoded |
Because of the way the request is generated we will have to incorporate additional logic and validation when we have refund with more than one row in Hemi because we will have to make two separate requests.
Once we make all the refund request we need to check the feeds if they are completed
Sample Request:POST https://api.bol.com/retailer/returns
{
"orderItemId": "2012345678",
"quantityReturned": 1,
"handlingResult": "RETURN_RECEIVED"
}
Sample Response:
{
"processStatusId": "1234567",
"entityId": "987654321",
"eventType": "CONFIRM_SHIPMENT",
"description": "Example process status description for processing 987654321.",
"status": "SUCCESS",
"errorMessage": "Example process status error message.",
"createTimestamp": "2018-11-14T09:34:41+01:00",
"links": [
{
"rel": "self",
"href": "https://api.bol.com/shared/process-status/1234567",
"method": "GET"
}
]
}
The acceptance is asynchronous and we will have to create a new feed in Marketplace Feeds table.
After each successfully send feed for order refund we will receive the entityId
from the response and need to store it in Marketplace Feeds table with the rest of the details as follows.
Bol Field | Hemi Field | Comment |
---|---|---|
<v1.4>processStatusId</v1.4> |
Marketplace Feed > External ID | |
Marketplace Feed > Account | For which account is the feed generated. | |
eventType |
Marketplace Feed > External Type | |
Marketplace Feed > Type | Hardcoded as “Order Refund“ | |
createTimestamp |
Marketplace Feed > Submitted Date | When the feed is submitted |
Marketplace Feed > Sent Objects Count | How many products we have pushed in the feed | |
Marketplace Feed > Status | If the external status is “PENDING“ we want to set the status as “Processing“. | |
If the external status is “SUCCESS“ or “FAILURE” or “TIMEOUT” we want to set the status as “Completed“. | ||
status |
Marketplace Feed > External Status |
Based on the response reader afterwards we need to mark the order as “Cancelled“ or leave it with the current status if not fully cancelled. If any errors are returned we want to store them in Order Errors table after the Bol Order Response Reader
Please note we will also add the feed objects which after processing need to be removed.