Returns

DotApparel collaborates with Loop Returns and AusPost to automatically generate return authorisations in your ERP when customers initiate returns through the returns portal online.

For Loop Returns, DotApparel Core enables merchants to preserve revenue in ERP through instant exchange orders and transfers refunded store credit to the ERP gift voucher seamlessly. AusPost does not currently have the capability to do instant exchanges or refund into a store credit.

Choosing between Loop and AusPost

Merchants can choose between AusPost Returns and Loop Returns, both of which integrate seamlessly with DotApparel Core. Here’s how they differ:

	Loop Returns	AusPost
Generate RANs once a customer triggers a return using the online returns portal	✅	✅
Assign identifiers to orders within Shopify, reflecting the status of returned item	✅	✅
Streamline instant exchange orders, especially in cases requiring refunds in the form of store credit	✅	-
When a return is sent to ERP, the revenue calculation and stock count are accurately recorded	✅	✅
Configure return reasons within the app, ensuring perfect alignment between Returns platform and ERP	✅	✅
Store credits (gift vouchers) can be represented as distinct line items on exchange orders in ERP	✅	-
Support refunding to the original payment method where an Apparel21 gift voucher was used	✅	-

Set up return reason mappings

DotApparel offers a flexible option to map return reasons between Loop Returns and the ERP, enabling enhanced return reason reporting in the ERP.

To configure the return reason mappings, follow these steps in your DotApparel admin:

1. Navigate to Returns > Mappings.

2. Under the Return Reasons section on the right-hand side, click "Add new return reason".

3. From the "ERP return reason type" dropdown, select a reason from the provided list.

4. In the "Source return reason pattern" input field, enter a relevant keyword that best corresponds to the Loop return reason.

Mappings for return reasons

The merchant perspective

Once the integration is fully set up and operational, it will function automatically. However, merchants may still wish to monitor the process and address any potential issues. To do so, they can access the Returns section in the DotApparel app.

This section serves as a comprehensive list of all returns known to DotApparel, including any return requests that existed before the implementation of DotApparel. This feature ensures smooth tracking of all returns, without any critical ones being overlooked.

The Returns section has four tabs:

Returns sections in the app

• All returns: Each line item represents an individual Return order received from the Loop webhook. By clicking on each line item, merchants can access detailed information about the return order.

• Return suspended: This tab displays a list view of all Return orders that were not created in the ERP due to API errors.

• Need review: This tab provides a list view of all Return orders that require issuing a gift voucher to the customer, but the voucher order has not yet been posted to the ERP. This might occur if the return was requested before the implementation of DotApparel. Merchants need to review the voucher information, including person ID, email, and amount, before manually triggering the voucher to the ERP. Merchants may also need to verify if the gift card refund has already been processed during the integration migration.

• Return not posted: This tab highlights any Return orders that DotApparel has not processed. These returns typically existed before DotApparel, and no further action is required for DotApparel to create the returns in the ERP.

Return order statuses

As return orders progress or change status, DotApparel will attach different tags to each order, indicating its current state. The following tags may be associated with a return order:

1. Return posted: This tag is applied immediately after a customer submits a return request to Loop, confirming that DotApparel has successfully created a return in the ERP. Applies to Loop, AusPost

2. Return suspended: This tag indicates that DotApparel encountered an issue and could not create a return in the ERP, often due to API errors or other reasons. Applies to Loop, AusPost

3. Return received: This tag indicates that the return might have been processed before the implementation of DotApparel, resulting in DotApparel logging the record without taking any further action. Applies to Loop, AusPost

4. Voucher posted: This tag denotes that DotApparel has successfully created a gift card refund in the ERP for the return order. Applies to Loop

5. Need review: This tag indicates that DotApparel has paused the process of posting a gift voucher in the ERP, requiring the team's review of the voucher request. This situation might arise when the return order was requested before the implementation of DotApparel. Applies to Loop

6. Return to store credit: This tag is applicable when the customer selects "refund to store credit" in Loop while the return is still in progress. No action is needed at this stage, but it serves as a future reference. Applies to Loop

7. Return to original voucher: This tag indicates that the customer selected "refund to original payment method" in Loop, but a gift card was used in the original payment. Consequently, a new gift voucher will be sent to the customer. Similar to "Return to Store Credit," no further action is required during the ongoing return process. Applies to Loop

---

FAQ

How can I resolve a return order when it’s labelled as “Return suspended“?

The "Return Suspended" status mainly occurs when DotApparel encounters issues while attempting to create a return in Apparel21 due to API errors. This situation is rare, and it can generally be easily resolved by retrying the task. However, if you come across this issue, please don't hesitate to contact us for further assistance.

What errors could lead to a return order showing “Need review“?

Several factors may result in a return order being marked as "Need Review":

1. The return order was processed before the implementation of DotApparel21 or was handled by a legacy integration during pre-migration.

2. Progress encountered an API error during the return process.

3. The order was previously or partially refunded to a gift voucher, and another gift card refund may be issued from other resources. In this case, DotApparel suspends the progress to avoid the risk of issuing a gift card twice to the customer.

What happens if the customer selects the option to refund to the original payment method where a gift card was used? Will they receive a new gift voucher? Applies to Loop only.

Yes, when a customer chooses the "refund to original payment method" option in Loop, but a gift card was used for the original payment, the customer will receive a new gift voucher from ERP. This is necessary since the previously used gift card is no longer available for the refund process.