QWQER - LSP - compliance check

[abhinavv245]

Delivered Flow

/on_search

• "Backward shipment is missing in fulfillments in on_search api
• 'Same Day Delivery' can be used for TAT above 60 min within the same day
• RTO items to be provided for each parent item

/init

• pickup and delivery contact information (fulfillments/start and end/contact) cannot be same

/on_init

• cancellation terms and bpp_terms are not enabled yet, please remove it for now
• time, price, descriptor, category_id, parent_item_id are not required in /items

/on_confirm

• Average Pickup Time PT26M (fulfillments/start/time/duration) mismatches from the one provided in /on_search (PT25M)"

/on_status

• price, parent_item_id are not required in /items
• may add tracking optimization params such as gps_enabled, url_enabled, url to fulfillment.tags.tracking in /on_status;

RTO Flow

• similar issues as above

/on_cancel

• "rto_id '1-RTO' in fulfillments/tags does not match with the one provided in on_search 'undefined' in /fulfillments",
• "Cancellation reason id in /fulfillments/tags does not match with order/cancellation/reason/id",
• "RTO id - '1' of fulfillment type 'RTO' does not match with the one provided in on_search 'undefined' in /fulfillments"
• why is fulfillments/time/range/end removed for fuflillment type 'Delivery'?
• pre cancel state to be provided in fulfillments/tags

@sajithjayaram

[abhinavv245]

Delivered Flow

/on_confirm

• fulfillments/end/time/duration is not required (on_confirm and onwards)
• fulfillments/start/instructions are missing
• fulfillments/start and end/time/timestamp will be provided when order is picked up or delivered

Cancelled Flow

• similar issues as above

/on_cancel

• RTO item will be added in items
• @ondc/org/item_id for RTO line item in quote/breakup does not match in /on_search(F1-RTO)
• There will be two fulfillments in case of RTO, forward shipment will be cancelled and RTO shipment will be added
• retry_count is missing from fulfillments/tags (rto_event)
• pre cancel state to be provided in fulfillments/tags

TAT Breach Flow

• similar issues as above

/on_cancel

• fulfillments/tags - rto_event will be added in case of rto only
• quote should reflect the updated value of logistics order which has to be paid by logistics buyer NP

@sajithjayaram

[iamsajith]

We resolved the issue and submitted the changes as a new PR

@abhinavv245 @sandeepshahi

[abhinavv245]

Delivered Flow

/on_status

• why is pickup and delivery range (fulfillments/start and end/time/range) changing in every call

Cancelled Flow

/on_cancel

• precancel_state is the fulfillment state prior to cancellation (cannot be 'Cancelled'), should be 'Order-picked-up' in this case, and updated_at is the time at which this state was recorded
• fulfillment state for RTO fulfillment with id '2' should be RTO-Initiated

/on_status

• unsolcited on_status call for 'RTO-Disposed' should be sent

TAT breach

/on_cancel

• precancel_state/updated_at is not recorded correctly
• in cancellation_terms, you are charging zero as cancellation fee, then why is the logistics buyer being charged the complete delivery fee? (should be zero in that case)

@sajithjayaram

[iamsajith]

We fixed the issues highlighted and submitted the updated as new PR. We've verified using the utility you provided and didn't find any problems. If you come across any, could you tell us which utility you're using?

@abhinavv245 @sandeepshahi @RupalSingla

[BLR-0118]

Group A

Flow 2:

1. /on_update:

   • trying to correlate pickup & delivery slots, avg pickup time, TAT:
   • /on_update timestamp is 15:07:03, avg pickup time is 27 min but pickup slot is 15:07:03-15:36:03 (means min pickup time is 0, max is 29 min & avg for this sample is 15 min) - is this correct?
   • S2D is 29 min which means delivery slot should be 15:36:03-16:05:03 (correct);

2. /on_track:

   • pls send the complete payload as per contract;

Group B

1. TAT breach - on_cancel:

   • precancel_state.updated_at should be when fulfillment state was updated to "Pending", not the timestamp for on_cancel;

2. RTO cancel - on_cancel:

   • same issue as for TAT breach;
   • suggest you not use slot itself for RTO fulfillment, instead of only range.start;

[BLR-0118]

@iamsajith - pls fix the above & share only relevant logs when done;

[BLR-0118]

Group A - flow 2

1. /on_update:

   • order.state & fulfillment state not in sync (/on_status_agent_assigned has correct sync);
   • not clear what fulfillment.end.time.duration of PT6M means?

2. /on_status*:

   • all /on_status have invalid key message.order_id;

Group B - TAT breach

1. /cancel:
   • reason code 006 is not valid for LBNP (should be 007); in this case, LSP should NACK /cancel as per contract;

[BLR-0118]

@iamsajith

[sajithjayaram]

issues mentioned above are fixed @BLR-0118 @abhinavv245 @sandeepshahi

[sajithjayaram]

updated logs are submitted as a new PR @BLR-0118 @abhinavv245 @sandeepshahi

[BLR-0118]

Group A (flow 2) - ok; Group B (TAT breach) - ok;

[BLR-0118]

Group B (Cancel - RTO) issues:

1. /on_cancel:

   • start & end locations for fulfillment "2" required;

2. /on_status (rto disposed):

   • fulfillment structure different from /on_cancel above;
   • order audit trail is created for every post-confirm event and the same returned in any post-confirm call (on_status, on_cancel, on_update);

[BLR-0118]

@iamsajith - pls resubmit Group B (cancel - RTO) flow;

[abhinavv245]

@iamsajith As per the discussion on call, elaborating on the points above.

/on_status

• both the fulfillments need to be present (structure to remain same)
• quote object should not be changed (complete audit trail to be maintained)

/on_cancel

• start and end location for RTO fulfillment needs to be provided.

[iamsajith]

issues highlighted above are fixed @BLR-0118 @abhinavv245 @sandeepshahi

[BLR-0118]

Group B - Cancel (RTO-No)

1. /on_confirm:

   • pickup timestamp provided, even though fulfillment state is Pending;
   • pickup & delivery timeslots don't align with average pickup time (25 min) & TAT (26 min): pickup timeslot is 11:29:36-11:54:36, assuming the worst case i.e. pickup happens at 11:54:36, delivery will happen between 11:54:36-11:55:36 (i.e. 0-1 min S2D TAT)?

2. /track:

   • called with order id 927616 which gets changed to 369313 in /on_track?

3. /on_cancel_rto_dispose:

   • /on_confirm shows fulfillment start/end address as 560001 (Vasant Nagar) / 560051 (Raj Bhavan Road) & this was changed to something else here?
   • for RTO fulfillment, since RTO happens after order is picked up, the correct start address should be somewhere between the start & end address above, right?

4. not sure if correct order trail is being maintained e.g.

   • quote.ttl shows in /on_init & /on_status APIs, but not in /on_confirm;
   • fulfillment.tracking, for forward shipment, is true everywhere, but false in /on_cancel?

[BLR-0118]

@sajithjayaram - pls fix above & resubmit;

[iamsajith]

Group B - Cancel (RTO-No) - Clarification

1. /on_confirm:

The delivery time we have provided is the estimated time provided by Google and calculated using GPS locations. However, we are now planning to add buffer time specific to each region.

2. /on_cancel_rto_dispose:

In the case of an RTO scenario, the delivery agent can cancel the order upon reaching the location. Only if the order remains undelivered, can the delivery agent cancel it, and at that point, the correct start address would be the buyer's location.

@BLR-0118 @abhinavv245

[sajithjayaram]

Below are the fixes we have made in this pull request

/on_confirm

• Removed the pickup timestamp provided, even though the fulfillment state is Pending.

• Fixed: Pickup and delivery timeslots didn't align with the average pickup time (25 min) and TAT (26 min). Pickup timeslot was set from 11:29:36 to 11:54:36. Assuming the worst case, i.e., pickup happening at 11:54:36, delivery would occur between 11:54:36 and 11:55:36 (i.e., 0-1 min S2D TAT). The delivery time provided is the estimated time from Google, calculated using GPS locations. We plan to add buffer time specific to each region.

/track

• Fixed a typo error where the order ID 927616 was changed to 369313 in /on_track.

/on_cancel_rto_dispose

• Fixed addresses in /on_confirm to show the correct start/end locations.

• For RTO fulfillment, the correct start address should be somewhere between the start and end addresses mentioned above. In the case of an RTO scenario, the delivery agent can cancel the order upon reaching the location. Only if the order remains undelivered can the delivery agent cancel it. At that point, the correct start address would be the buyer's location.

Order Trail Maintenance

• The problem is that "quote.ttl" was missing in the /on_confirm API while it was present in the /on_init and /on_status APIs. Even though it wasn't needed in /on_confirm according to the API contract, we added it there to make things consistent, as you asked.

• Fixed fulfillment.tracking to be true in the /on_cancel API for forward shipment, as it was previously false.

@BLR-0118 @abhinavv245 @sandeepshahi

[abhinavv245]

/on_cancel (RTO)

• why are start and end locations in RTO fulfillment same.

@sajithjayaram Kindly update here once fixed.

[sajithjayaram]

updated pull request is here

@BLR-0118 @abhinavv245 @sandeepshahi