Order TAT and handling breach of TAT

[BLR-0118]

Should we define TAT for different order (& fulfillment states)? If so, should these TATs be specified at network level or can be specified by buyer apps as they own the buyer experience? How can order TAT breach be handled?

[BLR-0118]

@aakasjayaraj @abaweja @batramanuj @mahoriR @mherle @ravi-kumar-yadav @EkanshKr @VidyaGF

[BLR-0118]

@ONDC-Official/participants

[BLR-0118]

Initial thoughts:

1. Fulfillment (forward shipment) has the following states - Pending, Packed, Order-picked-up, Out-for-delivery, Order-delivered;
2. Seller provides time to ship in the catalog - this is the time from Pending to Packed. Fulfilment state is set to "Pending" when order is accepted by seller;
3. Fulfillment TAT provided in on_select is (time to ship) + (time from Packed to Order-delivered), i.e. Pending->Order-delivered;
4. Buyer app has the following options for setting order state TATs:
   a. TAT for (Pending -> Packed) = (time to ship) + buffer as decided by buyer app;
   b. TAT for (Packed -> Order-delivered) = (fulfillment TAT - time to ship) + buffer as decided by the buyer app;
5. Buyer app communicates the order state TATs to seller app in /confirm;

@aakasjayaraj @abaweja @batramanuj @mahoriR @mherle @EkanshKr @VidyaGF - your comments?

[aakasjayaraj]

Some thoughts- Since time to ship is a non-mandatory field in some categories, will the TAT for Pending -> Packed be entirely under the control of the buyer app?

Time to ship is an item-level attribute as of now and TAT is at an order level. We will have to think of fulfilment level action &TATs since multiple fulfillments are also possible

[aanay1]

Hi Folks,
I am receiving notifications from GitHub about the updates.
Am I required to participate, or is it by mistake?

1 thought - We may want to consider orders delivered across multiple cities, which may include multiple hops between delivery centers.

[BLR-0118]

We're planning to add these clauses to the standard reference terms (which will be referred to in the API contract) as part of this solution:

1. In the event of breach of order-to-delivery (O2D) for retail and ship-to-delivery (S2D) for logistics, the corresponding seller apps have to accept cancel requests;
2. In case of S2D breach, logistics buyer app will not be responsible for forward shipment or RTO costs;