iThink Logistics - LSP - compliance check

[abhinavv245]

Delivered Flow

/on_search

• average time to pickup may be provided in /fulfillments/start for forward shipment
• for item id '29I1', time/timestamp refers to date (vis-a-vis Context.timestamp) for which this TAT (P2D2H) is provided
• order/serviceability is not a valid attribute

/on_confirm

• in /items, S2D TAT should be provided

/on_update

• shipping label link should be provided in /fulfillments/star/instructions (placeholder values to be avoided)

/on_status

• All on_status for intercity aren't provided (All P2H2P states need to be supported)
• items/time is missing

RTO Flow

• multiple past dates files provided, please submit updated files

/on_cancel

• cancellation/cancelled_by should have id of the LSP.
• items/fulfillment_id for RTO does not match the one provided in /on_search
• RTO should be initiated in /on_cancel (refer to /on_cancel RTO example in the contract document, backward shipment will be added in /fulfillments)
• in /fulfillments/tags rto_event, cancelled by should have value of the LSP as order has been cancelled by LSP.
• breakup for RTO(and its tax) is missing in /quote
• pre_cancel state can be provided in /fulfillments/tags

/on_status

• fulfillments/id for RTO does not match the one provided in /on_search
• RTO tax is missing in quote/breakup

@shubhamdepasser

[shubhamdepasser]

Could you please clarify the problem concerning item ID '29I1'? Specifically, I need an explanation regarding the discrepancy between the provided time or timestamp and the corresponding date referenced by the TAT (P2D2H) for this item.

@abhinavv245

[abhinavv245]

@shubhamdepasser In items, parent item has TAT P2D2H, context/timestamp is for 01/03, so w.r.t context, time/timestamp should be for 03/03, Like for RTO, TAT is P3DT5H, hence timestamp has a date 04/03.

[shubhamdepasser]

Okay

[shubhamdepasser]

@abhinavv245 We have completed V1.2 development for phase 1 and followed the instructions provided in the referenced sheet (https://docs.google.com/spreadsheets/d/11W5SZDqG6gYUU5Tel1gMJqxksipbh2fQYH5_W_SU14c/edit#gid=6221937). Could you suggest the appropriate steps to resolve the identified bugs? I am concerned that solely relying on the sheet might result in encountering the same issues again.

[abhinavv245]

@shubhamdepasser - can you please flag the points in which you have confusion? Phase 1 features are mandatory as per the roll out plan. The majority of the identified issues pertain to discrepancies, while a couple of them suggest features that other network participants have enabled and could enhance communication, however not obligatory.

[abhinavv245]

Delivered Flow

/on_search

• categories/time/timestamp is not correctly estimated

/on_status

• RTO item will be added in /items once the RTO is initiated

RTO Flow

• similar issues as above

/on_cancel

• Pickup timestamp (fulfillments/start/time/timestamp) is missing for fulfillment state - Cancelled",
• Pickup time range (fulfillments/start/time) is missing for fulfillment type - 'Delivery'",
• Delivery time range (fulfillments/end/time) is missing for fulfillment type - 'Delivery'",
• rto_id '3I2' in fulfillments/tags does not match with the one provided in on_search '2' in /fulfillments"
• Order is cancelled after it is picked up and the code used is for 'Buyer refused to accept delivery', why was out for delivery state not triggered?

/on_status

• status update for RTO-Initiated is not required as it was already provided in /on_cancel

@shubhamdepasser

[BLR-0118]

Delivered_flow

1. /on_search:

   • motorable_distance_type/motorable_distance reqd only for P2P (hyperlocal);

2. /on_confirm:

   • TAT was 4 days 8 hrs (/on_search), 122 hrs 19min (/confirm) & 4 days 2 hrs (/on_confirm); which is correct?
   • pls add average pickup time (fulfillment.start.time.duration in /on_search) to /on_confirm;

3. /on_status:

   • fulfillment states should be for intercity, as per this list;

[BLR-0118]

RTO flow

1. /on_cancel:
   • cancelled_by should be the bpp_id (i.e. LSP);

Pls also share logs for cancel initiated by logistics buyer for fulfillment TAT breach;

[BLR-0118]

@shubhamdepasser

[BLR-0118]

Delivered_flow

1. /on_search:

   • instead of giving TAT of 5D2H, why not make it 5D or 6D? that'll be more accurate, unless you're sure you'll meet the precise TAT of 5D2H;

2. /on_status_pending:

   • all post confirm callbacks update the order object & considering that these APIs are stateless, the entire order object is returned in callbacks;
   • /on_update at 05:39:32 has order object with pickup code / shipping label / delivery instructions / etc. but this is missing in /on_status_pending at 05:45:23;
   • payment.time.timestamp identifies time of payment for this order; since payment hasn't been made, this should be removed;

Cancel_flow

1. /on_cancel:
   • precancel_state.updated_at should have Context.timestamp for fulfillment state of Pending (06:29:45 in /on_confirm), not timestamp for /on_cancel;
   • reason code "003" is not valid for logistics buyer NP (LBNP); as per this list, the only valid reason code is "007" & you need to validate & NACK request for invalid reason codes;

RTO flow

1. /on_cancel:
   • cancelled_by should have the bpp_id;

[BLR-0118]

@shubhamdepasser:

• pls check & fix the above;
• I hope you're supporting all fulfillment states for P2H2P (logs have only a limited set);
• pls confirm for each point (above) that it's fixed, no need to resubmit logs;

[shubhamdepasser]

@BLR-0118 Thank you for your valuable feedback. I assure you that I will immediately incorporate your inputs and keep you informed updates.

[shubhamdepasser]

@BLR-0118 All problems have been resolved.

[BLR-0118]

clearing logs for v1..2.0