Understanding the system - Logistics extension
User / Merchant / Seller - discovery and setup
There are three main stages where sellers or merchants interact with the logistics module or configuration on the platform. By going through these stages, you will gain an understanding of how logistics work on Fynd Commerce, which will, in turn, enable partners to comprehend how logistics extensions are built on Fynd Commerce.
High-Level Design
- Various delivery partners integrated with Fynd Commerce are available for sellers to configure, install the extension, and use for shipping.
- Sellers can access the Logistics section from the home page and click on the Delivery Partner section. Here, they have the option to install, enable, and start using their preferred delivery partner services.
- Once an extension is installed, the platform redirects them to the extension's URL, and all subsequent user interfaces are managed by the extension.
- Within the extension, users should be able to enable the services of the delivery partner.
- This provision can be broadly done in three ways recommended below:
- Option 1:
- Delivery partners offer standard services such as air, surface, and heavy.
- Sellers subscribe to these services through the respective delivery partner's panel or portal, which may vary in process.
- The extension should provide an interface for sellers to view the list of services and input their credentials to enable these services.
- This credential data input or form is specific to the respective delivery partner, and those details need not be exposed or sent to platform.
- On the platform, these services are known as schemes. Each scheme is unique to a delivery partner, and many sellers can utilise these services. When a seller subscribes to a scheme, it is called an account on the platform.
- The extension must ensure these schemes are created beforehand, informed to platform and loaded when the seller tries to install the extension.
- It is the extension’s responsibility to inform the platform whenever a seller enables a service by creating an account.
- A scheme requires data on serviceability, TAT, and capabilities such as MPS, NDR, and Doorstep QC. More details can be found here.
- When a seller subscribes to a standard service/scheme, all related data or capabilities are automatically inherited into that account.
- For the Scheme and Account creation process, refer here.
- Note that a scheme is unique to a delivery partner, and an account is the combination of the scheme and the seller or company ID. An account serves as a placeholder for the company ID, and all data related to serviceability, TAT, rate card, capabilities, etc., are stored against the scheme only.
- In this scenario, the scheme-to-account relationship is one-to-many.
- Option 2:
- Large enterprises may create private contracts with delivery partners for customized services.
- For these sellers, the extension interface should enable a user experience where they can create a service or scheme on the platform and automatically create an account behind the scenes by hitting platform APIs.
- In this model, the scheme-to-account relationship is one-to-one.
- Partners can enhance the user experience by validating credentials or fetching data on serviceability and TAT based on the credentials provided by the seller, rather than making the seller fill all the scheme API’s data points. This can be done by accessing these data points from their servers through internal APIs, especially in the case of Option 2.
- Option 3:
- Fynd has partnerships with some of the delivery partners, providing services to sellers as an aggregator. Fynd Commerce handles the contracting and offers these services out of the box as a platform provider.
- The extension should display the list of services that Fynd offers on behalf of Fynd Commerce, allowing sellers to simply enable these services without any credential inputs, as credentials would be of contract between Fynd and Delivery partner
- In this case, there are schemes provided by Fynd as an aggregator, and sellers subscribing to these schemes become their individual accounts on the platform.
- This functionality or logic needs to be built into the extension.
- Note that this option typically requires approval processes and undergoes stringent review.
- These recommendations are based on various use cases. Extension partners can make solution decisions and validate them with Fynd Commerce support team if necessary.
- Option 1:
- Flow Diagram
- Platform Video
Additional Configuration (Optional)
- Once a seller has set up their delivery partners, they are automatically enabled for the seller's company.
- Since Fynd Commerce is an omnichannel platform, a seller might operate one or multiple sales channels for their business.
- In some cases, sellers may want to configure individual sales channels with customized preferences for which delivery partners they wish to use or prioritize for assignment.
- Fynd Commerce offers a rule engine configuration that allows sellers to customize delivery partner assignment preferences and priorities for shipments. In this section, sellers can access all accounts they have enabled through an extension. It is crucial for the extension to inform the platform of all create, update, and disable events in real-time, as sellers will be accessing these accounts through this configuration. Additionally, shipment creation calls from OMS to the respective delivery partner extension's account will continue unless updated information is provided.
- Flow Diagram
Order Journey
-
Orders on Fynd Commerce come through various applications or storefronts into the Order Management System (OMS). Sellers process these orders through the following states:
-
Orders placed by customers land on the Fynd OMS.
-
Sellers confirm and invoice these orders.
-
Once invoiced, the OMS indicates that the order is ready for delivery partner (DP) assignment.
-
The OMS emits an Assign DP event to the respective DP extension, which needs to acknowledge in turn as DP assignment by sending status
dp_assigned
. This event applies to both forward and reverse shipments.- This event specifies various shipment variations, such as Forward, Reverse, Multi-Piece Shipments (MPS), Cash on Delivery (COD)/Prepaid, and whether Quality Check (QC) is required. More about Assign DP here.
- Sellers then confirm, invoice, and pack the shipment for the delivery partner to pick up.
- From this point, DP status updates need to be synced by the extension to the OMS. The extension must map their status codes to the Fynd OMS statuses to reflect the current status of the shipment.
- If the seller or end-customer wants to cancel the shipment or mark it as Return to Origin (RTO), the OMS sends a Cancel DP event. More about Cancel DP here.
-
Prerequisite: When a new logistics extension is added, it needs to understand the types of messages it should receive. Currently, there are two main types: Assign shipment and Cancel shipment. Whenever the OMS sends one of these messages, it includes two important IDs: Extension ID and Scheme ID. To ensure the extension receives the correct messages, it needs to set up and configure a webhook to subscribe to the relevant events. This setup tells the OMS, "I'm interested in these types of messages, please send them to me!" More details will be provided below.
-
Below, three major flows and their successful scenarios illustrate how the process works and how status updates need to be provided by the DP
-
Flow Diagram
- Forward - Happy Flow
- RTO - Happy Flow
- Reverse - Happy Flow
-
Platform Video
-
Fynd OMS recognizes various shipment statuses as valid transitions, determining the next appropriate state in the shipment journey.
-
The following FDK method provides a consolidated list of states and their allowed next states, which can be stored at the extension side if needed: State Transition Map.
-
This FDK method helps in identifying the next allowed state for a particular current state, which is useful for validating state transitions before updating the status on Fynd OMS: Allowed State Transition.
-
Below is a table providing sample details of possible states that a delivery partner can send for reference.
State | Journey | Meaning |
---|---|---|
dp_assigned | Forward | A delivery partner has been assigned to the order. |
dp_not_assigned | Forward | No delivery partner has been assigned to the order yet. |
bag_picked | Forward | The delivery partner has picked up the package from the origin location. |
handed_over_to_dg | Forward | The package has been handed over to a delivery group (DG) or third-party logistics provider. |
bag_not_picked | Forward | The delivery partner failed to pick up the package. |
out_for_delivery | Forward | The package is out for delivery to the customer's location. |
delivery_attempt_failed | Forward | An attempt to deliver the package was made, but it was not successful. |
rejected_by_customer | Forward | The customer has rejected the package upon delivery attempt. |
bag_lost | Forward | The package has been lost during the delivery process. |
delivery_done | Forward | The package has been successfully delivered to the customer. |
rto_initiated | Return to Origin (RTO) | The process for Return to Origin (RTO) has been initiated. |
rto_in_transit | Return to Origin (RTO) | The package is in transit for Return to Origin (RTO). |
rto_bag_out_for_delivery | Return to Origin (RTO) | The package is out for delivery for Return to Origin (RTO). |
rto_bag_delivered | Return to Origin (RTO) | The RTO package has been delivered back to the origin. |
return_dp_assigned | Return | A delivery partner has been assigned for the return pickup of the package. |
return_dp_not_assigned | Return | No delivery partner has been assigned for the return pickup of the package yet. |
return_bag_not_picked | Return | The return package was not picked up by the assigned delivery partner. |
return_cancelled_at_dp | Return | The return process has been canceled by the delivery partner. |
return_dp_out_for_pickup | Return | The delivery partner is out to pick up the return package. |
return_bag_picked | Return | The return package has been picked up by the delivery partner. |
return_bag_in_transit | Return | The returned package is currently being transported back to the origin or a return center. |
return_bag_not_delivered | Return | The returned package has not been delivered back to the origin or return center. |
return_bag_lost | Return | The returned package has been lost during the return process. |
return_bag_out_for_delivery | Return | The return package is out for delivery to the return center. |
return_bag_delivered | Return | The returned package has been delivered back to the origin or return center. |