Skip to main content

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

hld

  • 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.
  • Flow Diagram

flow-diagram

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

additional-config-flow

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 Forward Happy Flow
    • RTO - Happy Flow RTO_happy_flow
    • Reverse - 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.

StateJourneyMeaning
dp_assignedForwardA delivery partner has been assigned to the order.
dp_not_assignedForwardNo delivery partner has been assigned to the order yet.
bag_pickedForwardThe delivery partner has picked up the package from the origin location.
handed_over_to_dgForwardThe package has been handed over to a delivery group (DG) or third-party logistics provider.
bag_not_pickedForwardThe delivery partner failed to pick up the package.
out_for_deliveryForwardThe package is out for delivery to the customer's location.
delivery_attempt_failedForwardAn attempt to deliver the package was made, but it was not successful.
rejected_by_customerForwardThe customer has rejected the package upon delivery attempt.
bag_lostForwardThe package has been lost during the delivery process.
delivery_doneForwardThe package has been successfully delivered to the customer.
rto_initiatedReturn to Origin (RTO)The process for Return to Origin (RTO) has been initiated.
rto_in_transitReturn to Origin (RTO)The package is in transit for Return to Origin (RTO).
rto_bag_out_for_deliveryReturn to Origin (RTO)The package is out for delivery for Return to Origin (RTO).
rto_bag_deliveredReturn to Origin (RTO)The RTO package has been delivered back to the origin.
return_dp_assignedReturnA delivery partner has been assigned for the return pickup of the package.
return_dp_not_assignedReturnNo delivery partner has been assigned for the return pickup of the package yet.
return_bag_not_pickedReturnThe return package was not picked up by the assigned delivery partner.
return_cancelled_at_dpReturnThe return process has been canceled by the delivery partner.
return_dp_out_for_pickupReturnThe delivery partner is out to pick up the return package.
return_bag_pickedReturnThe return package has been picked up by the delivery partner.
return_bag_in_transitReturnThe returned package is currently being transported back to the origin or a return center.
return_bag_not_deliveredReturnThe returned package has not been delivered back to the origin or return center.
return_bag_lostReturnThe returned package has been lost during the return process.
return_bag_out_for_deliveryReturnThe return package is out for delivery to the return center.
return_bag_deliveredReturnThe returned package has been delivered back to the origin or return center.

Was this section helpful?