Understanding Logistics Extension

User / Seller - Discovery and Setup

There are three main stages where sellers interact with the logistics module or configuration on the platform. By going through these stages, you will understand how logistics work on Fynd Commerce, enabling partners to comprehend how logistics extensions are built on Fynd Commerce.

High-Level Design

• Various Delivery Partners (DP) integrated with Fynd Commerce are available for sellers to configure and install the extension and use it for shipping.
• Sellers can navigate to Logistics (in the sidebar) → Delivery Setup → Delivery Partners. On the Delivery Partners page, users can install, enable, and start using their preferred DP 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 DP's services.
• This provision can be broadly done in three ways recommended below:
  • Option 1:
    • DP offers standard services such as air, surface, and heavy.
    • Sellers subscribe to these services through the respective DP'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 DP, and those details need not be exposed or sent to the platform.
    • These services are known as schemes on the platform. Each scheme is unique to a DP, and many sellers can utilize 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 the 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.
    • Refer to Account Creation Steps for the Scheme and Account creation process.
    • Note that a scheme is unique to a DP, 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 DP 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 DP, 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 a contract between Fynd and DP.
    • In this case, Fynd provides schemes 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 the Fynd Commerce support team if necessary.
• Flow Diagram

• Platform Video

Additional Configuration (Optional)

• Once a seller has set up their DP, it is 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 DP they wish to use or prioritize for assignment.
• Fynd Commerce offers a rule engine configuration that allows sellers to customize DP 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 DP extension's account will continue unless updated information is provided.
  

• Platform Video

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 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 DP 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 .

• Refer to OMS States, which contains a list of possible states a DP can send for reference.