DTDC - LSP - compliance check

[abhinavv245]

Forward Flow

/search

• fulfillment/end/location/gps cannot be equal to start/location/gps '\"12.9999855,77.73903849999999\"'

/on_search

• start and end location is same, is this a P2H2P order?
• all supported delivery categories should be provided in catalog

/init

• billing/tax_number should be valid

/on_init

• context/timestamp difference between on_init and init should be within 1 seconds
• quote/breakup/0/price/value precision for all prices in quote can be maximum of 2 decimal digits
• dummy values to be avoided (in settlement details)

/confirm

• when order prep time is PT1H, howcome the order is marked ready to ship at confirmation, update call should be used to mark order ready to ship in that case

/on_confirm

• correlate pickup & delivery slots, avg pickup time, TAT:
• /on_confirm timestamp is 13:12:40, avg pickup time is 12 hrs but pickup slot is 13:17:00-17:30:00 (means min pickup time is 5 min, max is 2 hrs 18 min & avg for this sample is 1 hrs 6 min) - it is inconsistent
• S2D is 48 hrs (P2D) which means delivery slot should be after the pickup end range timestamp to 13:17:00 (on 24th);

/on_update (missing)

• Shipping label is required for P2H2P shipments, how is that sent?

/on_status

• Order state should be 'In-progress' for fulfillment state - Searching-for-Agent
• fulfillments/start/time/timestamp (empty string) is not required for fulfillment state 'Agent-assigned/Searching-for-Agent'

RTO Flow

• similar issues

/update

• Pickup code is not required for P2H2P shipments as shipping label is provided by LSP
• PCC code 4 is used for OTP based authorization

/on_status

• start/time/timestamp or end/time/timestamp cannot be provided in /fulfillments when fulfillment state is Agent-assigned

/on_cancel

• provider/time is not required
• Pickup timestamp (fulfillments/start/time/timestamp) is missing for fulfillment state - Cancelled
• Delivery time range (fulfillments/end/time) is missing for fulfillment type - 'Delivery'
• "rto_id '1-RTO' in fulfillments/tags does not match with the one provided in on_search '2' in /fulfillments
• "RTO id - '1-RTO' of fulfillment type 'RTO' does not match with the one provided in on_search '2' in /fulfillments
• rto tax line item is missing in quote
• pre cancel state tag is required for the 'Delivery' fulfillment
• retry_count is missing from rto_event tag in /fulfillments

/on_status

• fulfillment delay is communicated after initiating RTO? In case of delivery delay, end time slot (end.time.range.start, end.time.range.end) needs to be updated and the delivery delay reason code and timestamp (when recorded) may be provided here; Also, fulfillment_delay/updated_at is not correctly recorded

• In RTO_Delivered, cancellation/reason/id cannot be an empty string

• fulfillment_delay/reason_id cannot be null

Cancellation flow

/on_cancel

• pre cancel state needs to be provided in fulfillment/tags
• The quoted price must be adjusted if there are no charges incurred for cancellation before the order is packed

@aditya-sharma2-shipsy

[abhinavv245]

Flow 1

/on_update

• fulfillments/0/state/descriptor/code is invalid (use correct enum)

/on_status (out for delivery)

• order/payment must have required property 'status' (for all on_status calls)
• fulfullments object cannot be empty (complete order trail needs to be maintained)

Cancellation Flow

/on_cancel

• quote/breakup cannot be an empty array
• order must have required property 'created_at'

/on_status(unsolcited)

• why is this response sent as /on_cancel is already provided.
• cancellation/reason/id cannot be an empty string

RTO Flow

/on_cancel

• retry_count is missing from rto_event tag in /fulfillments
• start and end locations to be provided for RTO fulfillment

Kindly use the log verification tool to verify at your end and make sure all the previous issues are resolved before resubmitting the logs

@aditya-sharma2-shipsy

[aditya-sharma2-shipsy]

Flow 1

/on_update

• noted

/on_status (out for delivery)

• can you please share valid enum for payment status, it is not mentioned in v1.2 contract pdf - Q1
• noted, this was a mistake while adding logs in the file

Cancellation Flow

/on_cancel

• It is an empty array because total price is 0, what breakup should i provide for price 0 ? This is intentional - Q2
• noted

/on_status(unsolcited)

• This is an unsolicited from our end as consignment status has changed to rto initiated, This is just to make sure that status is duly updated at the buyer end, if they do not require this, they can NACK
• noted

RTO Flow

/on_cancel

• shouldn't the retry count be present when there has been a delivery attempt, this consignment was cancelled after pickup and the consignment never reached the destination hub, so there is no delivery attempt that was made. Thus we had not passed retry count - Q3
• This is not mentioned in the contract - Q4

@abhinavv245 request your help on the four points Q1, Q2, Q3 and Q4 so we can make the changes accordingly and re-create the logs

[abhinavv245]

• valid enums for payment status: 'PAID','NOT-PAID'
• quote object schema needs to be maintained, delivery and tax charges would be adjusted to zero
• Kindly use the cancellation code which allows you to retry
• start and end locations will be required for RTO fulfillment. Please add it.

@aditya-sharma2-shipsy

[abhinavv245]

All Flows

/on_cancel

• quote/breakup does not add up to quote/price
• billing/created_at and updated_at mismatches in /billing from /confirm
• fulfillments/tags precancel_state/updated_at is not correctly recorded (it refers to the timestamp when this 'Searching-for-agent' state was recorded in the system) (in TAT breach flow)

/on_status

• quote/breakup does not add up to quote/price (Post cancellation calls)
• why is shipping label removed from images array in fulfillments/start/instructions(complete order audit trail to be maintained)

/on_update

• fulfillments/0 must have required property 'tracking'

Is tracking supported by DTDC? In case yes, then track/on_track to be provided (url based tracking), else fulfillments/tracking value should be false in all APIs starting /on_confirm

Note: Please run the log verification tool before submitting logs

@aditya-sharma2-shipsy

[aditya-sharma2-shipsy]

/ on_cancel :

• I could not find any discrepancy in the quote price and breakup summation in both the cancellation flows, (for flow without rto the price is 0) - Q1
• noted
• this is because there was a update which was done at our end, the agent was assigned at our end, there is no status trigger which we are doing for that but the consignment was updated (this can be seen in tracking as well) - Q2

/on_status :

• quote/breakup does not add up to quote/price (Post cancellation calls) - noted
• why is shipping label removed from images array in fulfillments/start/instructions(complete order audit trail to be maintained) :- how can we maintain this value, as instructions is a object and we have to pass proof of pickup in instructions and we attach the instructions image there. as per current architecture of API it is not possible to have complete trail of instructions - Q3

/on_update:

• fulfillments/0 must have required property 'tracking' - noted

We do provide tracking that was a miss from our end in the logs

@abhinavv245 request your response for these 3 points Q1, Q2 and Q3

[abhinavv245]

• In the RTO flow, quote breakup total is 154, however the quote/price is 144
• As mentioned, it is the time at which the state before cancellation was recorded in the system. So if you updated the state to Agent-assigned, then the state as well as updated_at should be also updated. In your case, you kept the precancel_state as Searching for agent, however you updated the timestamp of Agent assigned
• Shipping label was sent in the images array, so you can maintain the trail in that. You can add the proof of pickup in the images array and keep the shipping label as it is.

@aditya-sharma2-shipsy

[BLR-0118]

@aditya-sharma2-shipsy:

• logs shared can't be reviewed as they aren't for a realistic scenario: 2 pincodes in same city is actually hyperlocal;
• pls share logs with LBNP who're actually into intercity deliveries e.g. Bizom / SellerApp & others;

[aditya-sharma2-shipsy]

@BLR-0118 Thank you for your inputs

• currently as well we accept orders which are in same city, irrespective of if it is from same city or different cities the model followed by us is P2H2P and minimum TAT for any order with us is 1 day. We catered to multiple similar orders in v1.1.0 as well (same city)
• Would it work if we create logs with the same NP (with which we created these logs) for different origin and destination cities

[BLR-0118]

Forward Flow

1. average pickup time (fulfillment.start.time.duration) wasn't provided by LSP in /on_search (ok) but LBNP quoted 24 hrs for this in /confirm which was accepted by LSP (as it's part of /on_confirm): why?
2. LBNP is sending pickup & delivery code type for OTP, with incorrect details ("authorization" not provided) & without requesting for pickup/delivery authorization (using OTP) in /search; how's this being processed?
3. LSP quoted S2D TAT of 2 days but status request was sent after 6 days and order was actually delivered after 6 days: why?
4. tracking is enabled & /on_track response provided; however, "tracking"."url_enabled" and "url" aren't enabled in /on_status to notify buyer app;
5. are all fulfillment states defined here supported?

[BLR-0118]

RTO flow

1. /on_cancel (unsolicited) seems correct but /on_status (unsolicited RTO initiated) is wrong as it's not showing the latest copy of the order as shown in /on_cancel, e.g.: a. cancelled_by should have the bpp_id; b. precancel_state and rto_event are missing;

[BLR-0118]

@aditya-sharma2-shipsy - pls fix & resubmit;

[aditya-sharma2-shipsy]

@BLR-0118

Forward Flow :

1. will fix this
2. we have not integrated the pickup and delivery otp change as it is part of phase 2, this was passed back in on_confirm as we just picked up the instructions that we received in confirm and passed in on_confirm We can do this that we validate and not directly pass the instructions if it's not relevant field as per phase1, but we cannot throw an error based on this field.
3. Actually there were availability delay from LBNP end thus there was delay in creating logs thus there was a delay
4. this is a optional field as mentioned in contract, that is why we have not passed this
5. Not all fulfillments are supported, We support below fulfillments: "Pending" "Searching-for-Agent" "Agent-assigned" "Order-picked-up" "At-destination-hub" "Out-for-delivery" "Order-delivered" "Cancelled"

Request for your views on these points.