Skip to main content

Functional Flow

Inventory Integration​

After the seller uploads the Raw inventory data, job rules will be applied and then Fynd will consume that inventory.

The Inventory API sends the sellable quantity and the committed quantity to Myntra (happens at the backend)

The Buffer logic works as follows:

  • If the inventory is greater than the buffer amount, actual inventory will be pushed.
  • If the inventory is less than or equal to the buffer amount, then 0 inventory will be pushed.

This inventory consumed data is then stored in Fynd Database. This is the data that will be reflected at marketplace level.

These updates will be stored in the Fynd system for 30 days.

QG1

Figure 1: Inventory Integration

Full Sync Scenario​

  1. Full sync can be triggered automatically or manually as shown in the figure
  2. A Cron is scheduled for every night to check if there any issues with the inventory updates
  3. The Fynd system checks the Inventory API if there is need for inventory update
  4. This can be triggered manually from the front end as well
  5. In the manual trigger, a data range can be specified for the system to check for inventory updates
  6. After searching the inventory API, if there is a need for reconciliation for inventory status then it will fetch the list of SKU x location mappings where the correction is required and update the inventory
  7. This will be stored in the inventory database

QG2

Figure 2: Full Sync Scenario

Order Integration​

Forward Flow​

  1. After the order is placed by the customer, Myntra will push that information to Fynd
  2. Fynd system will check if the SKU mappings and store mappings are available and then move the order to placed
  3. Fynd will then push the order to the seller system and let them know of the placed order
  4. Here seller can either accept or reject/partially reject the order
  5. If the order is open for more than 3 days, the order will be cancelled (VFS)
  6. If the order is partially rejected then Myntra will check if other stores are available to fulfill the order, it will be in Bag not confirmed state
  7. If another store is found then Fynd system will reassign the order to the new store after performing the same checks
  8. IF the order is confirmed by the seller, it is moved to Bag confirmed state.
  9. All these order details are stored in the Order Database at Myntra
  10. Once the Bag is confirmed, Myntra will push the the courier details and package ID to Fynd system.
  11. Fynd can then download the order invoice and ship label to be printed from the Myntra system and store them as PDF
  12. After the delivery partner is assigned, the order will be moved to the Bag Picked stage
  13. Once the delivery is complete by the delivery partner, Myntra will push that data to Fynd system and it will be marked as Delivery Done

QG2

Figure 3: Forward Flow

Return/RTO Flow​

Understanding the Return/RTO Flow​

  1. Fynd System will create the Return/RTO request after it receives the details from Myntra
  2. This can be seen on the Fynd OMS system
  3. Once the Return/RTO is picked up cancelled or delivered, Myntra system will push those details to Fynd System
  4. Fynd will then update that details and then they can be seen on the Fynd OMS

QG2

Figure 4: Return/RTO Flow

Cancellation Flow​

Customer can cancel an order if it hasn’t been marked as Shipped. Seller can’t cancel once it has been placed, they can only accept or reject it. If an order is in open status for more than 3 days then Myntra will mark it as cancelled with the reason code ‘Vendor failed to supply’.