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

• Platform Video
  • https://drive.google.com/file/d/1Cw3775n1onaJYjaC3jWp37D3sUEjUdWO/view?usp=drive_link

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

• Platform Video
  • https://drive.google.com/file/d/18BxEwrZzPRd3g28NBE8OMvFxjy8OD7Zx/preview

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

  • https://drive.google.com/file/d/1PpZJOuctaSZ5hfwlhdG_Hm6Zc0mce_sU/view?usp=drive_link

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