Refund imports technical scope (IN PROGRESS)

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)

The purpose of this document is to describe on how we want to handle a new functionality in Hemi - The refund imports. The general idea is for our clients/customers to be able to make refunds a lot easier and also do bulk refunds and this will be a huge step in improving Hemi which will have immediate impact.

As a whole in Hemi, we have two types of refunds - Full refunds and Partial refunds, therefore we want to have both types available for refund imports.

We want to add two new import types - Full refund import and Partial refund import. These should be available for both manual and automatic imports. We also would like to use our mapping/layout import functionality so the user should either map the imported file or use an existing layout when doing the import.

My suggestions is that we should separate refunds by Account due to the fact that for different accounts we need to use different reasons. So we need to have one more required field and this would be the Account. Since we will have different reasons for different accounts, and for some accounts we know the reasons are predefined (example eBay), we want to show all the possible reasons for the respective account when it is selected.This should make the user journey a lot easier and friendly and also hopefully avoid users inputting wrong reasons. We should also have the possibility to add an order prefix for removal.

We’d like to introduce a “download template” button which should simply download a csv or xlsx file template for the selected import type.

FullRefundTemplate.xlsx

PartialRefundTemplate.xlsx

We also want to introduce a default reason for the import too. By doing this we will give the freedom to the customer to either fill their file with reasons or just use one reason for all orders without the need of having the same reason on all records. The default reason should be a tickbox and once selected we can have a dropdown menu with the possible reasons for the selected account. Note! We still want to show the default reasons as a “tooltip” as shown in the below image, however they should not be selectable but only as a guidance. The selectable reasons will be only available/shown when the tickbox for default reason is ticked.

Example below :

Full refund imports

The full refund imports we want to keep as simple as possible. We want to be able to import a .csv or .xlsx or .txt file with as minimum information as possible. We will need to have 2 required fields in the file we are importing as a minimum. That would be Order ID and Reason headers in the file and these should be mapped in the layout specifics tab just like all of our imports. Since this is a full refund we don’t need to specify any SKU that is being refunded, we just mark all items (shipping?) on the order for refund.

Note! If we have selected a default refund reason, we don’t want to have the Reason as required field. We only want to have it if no default reason is selected.

We should be able to have additional fields like Internal note ,Refund note, ClaimID or any other information that could be mapped to a field in Hemi, however these should not be required.

Note! : Since this is a full order refund we should include the shipping cost too when creating the refund, if applicable.

Claims handling :

The way we want to handle claims is simple. We need to add a validation which will check if there is a claim for the given order and automatically link the refund with the claim. This is needed because if we have a claim for an order and we try to push a “normal” refund then it will not go through. We want to do the mapping based on the Order Item Line ID as this is the product identifier that we keep in the Order Claim table. So to sum it up : When doing a refund import, we need to check if there is a claim for the given order and if it is accepted. If there is a claim, then we need to check which product(s) are in the claim. This information is kept in the Order Claim Rows > Order Item Line ID. We then need to map it with Product On Order > Order Item Line ID and then create the refund for the given claim.

If there are errors we need to store them with the relevant errors in a Import Log > Result File . When we have error case we need to store the Order ID and the validation error that has occurred.

Possible errors are : Order is already refundedOrder amount is more than what we can refund

For the successfully imported records, we should create the Order Payment in Hemi with:

Order Payment > Type = Refund Order Payment > Status = Pending Order Payment > Process by MP = Yes Order Payment > Refund Type = Full Refund

All other fields, triggers and validations are as per our Refunds send general logic

After the import has been actioned we also should store a record in the Import log giving information about the date, finished time, status, imported records etc.

Partial refund imports

The partial refund imports will be more complicated than the full ones as we need to have richer information in order to successfully create and process a partial refund.

The partial refund import should be through a .csv or .xlsx or .txt file but we will need to have more information in it. We need to be able to specify a couple of things as required when doing a partial refund : Order ID, SKU, Quantity OR Amount, Reason. These should be the minimum requirements in order to create a partial refund.

Note! If we have selected a default refund reason, we don’t want to have the Reason as required field. We only want to have it if no default reason is selected.

We should be able to have additional fields like Internal note ,Refund note, ClaimID, Refund Full Shipping OR Shipping amount to refund or any other information that could be mapped to a field in Hemi, however these should not be required.

We want to add a logic where we pick either the Quantity OR the Amount. In the first case we specify the exact quantity we are refunding from a given SKU (this could be full line or partial line depending on how many quantities there are on order) and with the second case we can specify the Amount we are refunding from a line which could be again full line or part of the amount of the line.

2 3 | Refund line quantity specified. | | | Amount | 3.50 | Refund only the specified amount from the line. | Decimal symbol should be dot (.). If there is another decimal symbol, we need to store an error in a Import Log > Result File with the OrderID and SKU. Example error message : “Wrong decimal symbol in price” |

This is why we need to have validations and if we have specified Amount, then the Quantity field should not be taken into consideration and vice versa - if we have specified Quantity, then the Amount field should not be taken into consideration. Please note that it is expected to have mixture of both cases in a file.

If we have both filled, we need to take the Amount with priority.

If none of the two fields are filled, we need to store an error in a Import Log > Result File . When we have error case we need to store the Order ID AND SKU and the validation error that has occurred.

The same logic goes for Refnd Full shipping and Shipping amount to refund.We either refund the full shipping on order or we refund partial amount of the shipping.

No empty value | If Yes - refunds full shipping on the order If No - does not refund shipping If empty value - Will refund value from Refund Shipping Amount | | | Shipping amount to refund | 3.50 | Refunds only the specified amount from the shipping | If we have Refund Shipping record with Yes, we need to ignore this field. Decimal symbol should be dot (.). If there is another decimal symbol, we need to store an error in a Import Log > Result File with the OrderID and SKU. Example error message : “Wrong decimal symbol in price” |

If we have Refund Full Shipping = Yes, then the Refund Shipping amount field should not be taken into consideration.

If we have Refund Full Shipping = No, then we don’t refund shipping at all.

If we have Refund full shipping = empty, then we refund the specified amount in the Shipping amount to refund.

Since the refund of the shipping is optional, if none of the two fields are filled, we consider this as a No shipping refund and continue to create the refund only for the specified SKU(s).

Claims handling :

The way we want to handle claims is simple. We need to add a validation which will check if there is a claim for the given product and automatically link the refund with the claim. This is needed because if we have a claim for an order and we try to push a “normal” refund then it will not go through. We want to do the mapping based on the Order Item Line ID as this is the product identifier that we keep in the Order Claim table. So to sum it up : When doing a refund import, we need to check if there is a claim for the product we are trying to refund and if it is accepted. If there is a claim, then we need to check which product(s) are in the claim. This information is kept in the Order Claim Rows > Order Item Line ID. We then need to map it with Product On Order > Order Item Line ID and then create the refund for the given claim.

Discount handling:

We might have a case where we have two of the same SKUs with different prices due to discount.

The way we handle this is we simply put a validation and if we have such case we simply block such refunds from the imports as we wouldn’t know which item to refund. This should be an edge case anyways as in most of the cases we should not have different prices. So if we have such case, we should store an error in the Import Log > Result File with the OrderID saying that there are two of the same SKUs with different price.

If there are errors we need to store them with the relevant errors in a Import Log > Result File . When we have error case we need to store the Order ID and SKU and the validation error that has occurred.

Possible errors are :

Item is already refunded

Item refund is more than what we can refund

After we have successfully done the validations and records have been imported successfully, we need to create the Order Payment in Hemi with:

Order Payment > Type = Refund Order Payment > Status = Pending Order Payment > Process by MP = Yes Order Payment > Refund Type = Partial

All other fields, triggers and validations are as per our Refunds send general logic

After the import has been actioned we also should store a record in the Import log giving information about the date, finished time, status, imported records etc.