Page Comparison

Introduction : managing returns with Onestock

Onestock offers a versatile order returns management system that can be utilized through various methods to accommodate the needs of both customers and businesses. Our module ensures a seamless and efficient returns process via the following approaches:

• Self Service Return (SSR): an iframe provided by Onestock that can be embedded directly into an e-commerce site, enabling customers to independently declare their returns.

• Store App: by activating the customer_search page in the Store App, sales people can search for customer orders and declare in-store returns.

• Backoffice: used by the customer service team, the backoffice allows for the declaration of returns using multiple pre-configured delivery methods. All returns will also be displayed in the back office, regardless of how they were created.

• External systems: Any other external systems can connect to our public APIs to manage returns, ensuring flexibility and integration with various platforms. API documentation is available here : https://developers.onestock-retail.com/paths/return_parcels/post

Before starting any configuration on returns, it is necessary to enable the "Return Management" module in the Backoffice. Admin users can activate it by going to the Configuration > Modules section. If the module is displayed as "not available", please refer to your Onestock contact who will make it available.

Adapting the workflow

The workflow is the foundation of the returns configuration, serving as the starting point for all return declarations, regardless of the method used. Indeed, all returns must be declared via a POST/return_parcels, and then the workflow will decide which path to take.

The workflow can be adapted with a simplified or an advanced model for returns management.

Simplified model

The simplified model manages only a single final return step, indicating that the items have been successfully returned. Generally, this step is not compatible with declarative methods such as the Self Service Return (SSR) or returns declarated in the backoffice, as these methods involve returns that are not yet finalized. However, it can be compatible with in-store returns or returns sent to Onestock via an external system.

The workflow can be configured as shown below, with a single state for the return parcel and the return line item group.

The process goes like this:

1. The Store App or an external system creates a return parcel via API (POST/return_parcels). The reason, the condition, and potentially a comment can be given as parameters. The initial state of the workflow is automatically given to the return parcel: returned

2. When the return parcel is created, Onestock automatically creates the return line item groups associated with the corresponding index ranges. The initial state of the workflow is given to the return line item groups: returned

3. Thanks to the action after creation, the concerned line item groups are transited to the returned state

Advanced model

The advanced model allows for the order return process to be divided into two stages: declaration and validation. This model is compatible with the Self Service Return (SSR) and declarations made in the backoffice, as the return is considered 'in progress' but not yet validated. Subsequently, other systems can validate or invalidate the return, such as the Store App for in-store returns or any external system via API.

The workflow can be configured as shown below, with an initial returning state and a final state that depends on what has been declared by the validation system.

The return process generally involves two stages.

First: return declaration

1. The Self Service Return, the Store App, the Backoffice, or any external system creates a return parcel via API (POST/return_parcels). The reason, the condition, and potentially a comment can be given as parameters. The initial state of the workflow is automatically given to the return parcel: returning

2. When the return parcel is created, Onestock automatically creates the return line item groups associated with the corresponding index ranges. The initial state of the workflow is given to the return line item groups: returning

Then: several scenarios are possible

1. The return is accepted. A PATCH/return_parcel/{return_parcel_id} API call from the Store App or an external system is received in order to change the return parcel state to returned. The condition sent validates the return, and the return line item groups change their state to returned. Because of the action after, the concerned line item groups are transited to the returned state

2. The return is received but refused (for example, if the items are damaged). As in the previous scenario, a PATCH/return_parcel/{return_parcel_id} API call from the Store App or an external system is received in order to change the return parcel state to returned. But this time, the condition sent invalidates the return, and the return line item groups change their state to returne_refused. Finally, the concerned line item groups can be passed again to the fulfilled state.

3. The return is cancelled (for example, the customer has called customer service to cancel). A PATCH/return_parcel/{return_parcel_id} API call from the Store App or an external system is received in order to change the return parcel state to return_aborted. A condition on the transition of the line item group causes it to transit to the return_aborted state. Finally, the concerned line item groups can be passed again to the fulfilled state.

General configuration

If the “Return Management” module is activated, the Returns tab will appear in the configuration section.

Reasons and conditions

The first two configurations allow you to offer reasons and conditions options in the interfaces (Store App, Backoffice, SSR).

Returnability perimeter

Other configurations can be used to establish the perimeter of what can and cannot be returned.

Return methods (for Backoffice)

These methods are used to display choices in the Backoffice.

Configuration must be done by sales channels. For each of them, an in_store method can be declared, as well as one or more postal methods

This configuration is in JSON format, so we advise you to copy and paste the example below to serve as a template

{
  "sc_1": {
    "carriers": [
      {
        "name": "colissimov2",
        "option": "DOM",
        "destination_endpoint": "001",
        "notifications": [
          "return_with_colissimo"
        ],
        "documents": [
          "return_note"
        ]
      }
    ],
    "
    ": {
      "endpoint_request": "stores_sc_1",
      "notifications": [
        "in_store_return"
      ],
      "documents": [
        "return_note"
      ]
    }
  },
  "sc_2": {
    "carriers": [
      {
        "name": "ups",
        "option": "ST",
        "destination_endpoint": "001",
        "notifications": [
          "return_with_ups"
        ],
        "documents": [
          "return_note"
        ]
      }
    ],
    "in_store": {
      "endpoint_request": "stores_sc_2",
      "notifications": [
        "in_store_return"
      ],
      "documents": [
        "return_note"
      ]
    }
  }
}

Here's what each field does.

Store App configuration

As returns are managed from the customer_search tab in the Store App, the configuration can be found via the path Configuration > Store App > Pages settings > Customer search > Specific settings. A redirect link has been also added from the returns configuration page.

Here are more details on the configurable elements.

⚠️ Two configurations are currently missing from DIY (but will soon be added):

• Return parcel states from which you can validate a return.

• The state to which the return parcel should be transited after validation

To override these configurations, you need to make a PATCH/configurations by API by putting the following object in the keys field

"vendor_interface.page_state_params": {
    "return_parcel": {
        "to": "returned",
        "initial_states": [
            "returning"
        ]
    }
}