EkSecond (retail) - compliance check
Closed this issue · 18 comments
Flow 1
- /on_search:
- why diff > 30 mins in Context.timestamp of /search & /on_search?
- either provide fixed timing (time.range.start & end) or split timing (time.schedule.frequency, time.schedule.times) but not both. In this case, it seems the store is open from 6AM to 11PM, so remove the split timing;
- contact_details_consumer_care should only have "name, email, contact no" as defined in the contract;
- serviceability construct: use category "F&B" for now;
- search was for "mutton biryani" but others are also being returned. You may want to use these item keys (matched, related, recommended) to distinguish between different results returned e.g. "mutton biryani" will have "matched":true but others may either have "related" or "recommended" set to true;
- /on_select:
- why is the response taking 11 secs (diff in Context.timestamp between /select & /on_select);
- why is this returning error 40002 when item_quantity in /on_select matches what was selected (in /select). What's out of stock in this case?
- /on_init:
- diff of 15 secs in timestamp between request & response;
- remove payment.collected_by;
- /on_confirm:
- diff of 15 secs in timestamp between request & response;
- all /on_status:
- all solicited & unsolicited /on_status responses seem to have the same message_id & timestamp as /on_confirm;
- order pickup time (fulfillment.start.time.timestamp) and delivery time (fulfillment.end.time.timestamp) can't be > Context.timestamp for that /on_status call;
- /on_update:
- message_id should be same as /update;
- Context.timestamp is same as /on_confirm;
- tags should only have "status" & nothing else;
Flow 2
- /on_init (serviceability): non-serviceable means no fulfillment possible, hence, no fulfillment level charges (delivery / packing / convenience fee, etc.);
- /on_status (post cancel):
- order.updated_at timestamp invalid;
- "cancellationTags" is invalid key;
- if order is cancelled, value of order becomes 0 (hence, quote.price and quote.breakup[].price should be 0);
Flow 3
- /on_update (return rejected): items struct is wrong (top most item should have count 1 and the one with tags 0) - check here
Responses:
why diff > 30 mins in Context.timestamp of /search & /on_search?
Our onsearch payload was huge due to which our log provider was stripping off the payload so we had to re-capture logs by replaying /search locally which was done 30mins after the initial /search. However, we've improved our searching algo and now the payload is not as big so the current logs should show accurate realtime logs from server.
search was for "mutton biryani" but others are also being returned. You may want to use these item keys (matched, related, recommended) to distinguish between different results returned e.g. "mutton biryani" will have "matched":true but others may either have "related" or "recommended" set to true;
Najeeb: Yes, thanks for pointing out, we've implemented better matching algorithm. The search responses will have better search score and will be closely related to the incoming search query.
why is the response taking 11 secs (diff in Context.timestamp between /select & /on_select);
Najeeb: We investigated this, turns out the LSP (LSN) was taking 15secs approx back then. We reported it to them. POssibly they corrected as in current logs we dont see this problem.
@BLR-0118 feedback implemented https://github.com/ONDC-Official/v1.1.0-logs/pull/70
Flow 1
- /on_search:
- provider.locations.address: still has the old format (street, city, area_code, state);
- circle.radius.value should be string;
- schedule.holidays is mandatory key (can be empty);
- /on_select:
- diff in Context.timestamp between this & /select is ~ 6 secs. That's not going to work as most buyer apps have set a timer at 3 secs;
- /on_init:
- fulfillment.end.location.address is different from what was sent in /init. How can this change?
- buyer finder fee type should be "percent" (smaller "p");
- /on_confirm:
- fulfillment.start.instructions.short_desc should have only the pickup code;
- fulfilment.end.instructions.short_desc should have only the delivery code;
- order.updated_at should be updated;
- /on_status (searching for agent):
- should have appropriate fulfillment state code;
- delivery time has changed between /on_status (order delivered) & /on_status (for get status after order being delivered);
Flow 2
on_init (serviceability error): type & code are mandatory as per API contract;
can't find log for out-of-stock usecase;
Flow 3
/on_update - doesn't have the forward shipment fulfillment details (state, etc.)
Flow 2
on_init (serviceability error): type & code are mandatory as per API contract; can't find log for out-of-stock usecase;
Flow 3
/on_update - doesn't have the forward shipment fulfillment details (state, etc.)
@BLR-0118 "can't find log for out-of-stock usecase" -> Out of stock is in flow 5 isn't it and there were no feedback comments on this flow. Hence we only re-submitted flow1,2,3. Flow 5 is in the PR with logs from original submission
"/on_update - doesn't have the forward shipment fulfillment details (state, etc.)" --> As discussed on whatsapp, since we liquidate the return, no forward shipment details required
@BLR-0118 you will notice some of our APIs are still responding on the borders of 4 seconds - this is because of LSNs responses coming late. Example below - you see the context.timestamp says 2023-03-17T14:27:15.217Z but it was actually delivered to us at 3/17/2023, 7:57:18.9699373.
{
"context": {
"domain": "nic2004:60232",
"country": "IND",
"city": "std:080",
"action": "on_init",
"core_version": "1.1.0",
"bap_id": "api3.eksecond.in",
"bap_uri": "https://api3.eksecond.in/ondc",
"bpp_id": "ondc-preprod.loadshare.net",
"bpp_uri": "https://ondc-preprod.loadshare.net/logistics/bpp",
"transaction_id": "632839af4bea4df42dfe336b|b75f5c92-f48f-4664-9472-90fcbb80a8be",
"message_id": "c705e650-c7c5-4ba6-97a3-9c4eed598846",
"timestamp": "2023-03-17T14:27:15.217Z"
},
Flow 1
- /on_status (for get status call):
- since order is delivered, delivery time (fulfillment.end.time.timestamp) is mandatory;
- /on_update (return accepted):
- 2nd & 3rd entry in items can be merged;
Flow 3
- /on_update (return rejected) should have same message_id as /update;
- 2nd & 3rd entry in items can be merged;
@BLR-0118 I think them staying un-merged is looking cleaner isn't it? the one with count 0 has a fullfillment_id while the one that is liquidated doesn't as there was no reverse shipment. Can we leave this as is please? this will be helpful for data analytics purpose
@BLR-0118 feedback changes implemented except "2nd & 3rd entry in items can be merged;".
Flow 1
- Response times (diff b/w callback response & request Context.timestamp) seems very high:
- /on_select: ~ 4 secs
- /on_init : ~8 secs
- /on_confirm: ~4 secs
- /on_status (Agent Assigned):
- fulfillment state of "Agent-assigned" is invalid for retail;
- In all /on_status calls, order.updated_at not getting updated;
- /on_update (return accepted):
- merge 2nd & 3rd item entries as the entire item is liquidated, i.e. entire item with forward shipment (denoted by fulfillment id) has now been liquidated (same with flow 3 return rejected). If an item is part returned, then splitting makes sense as it shows that one part is still valid and the remaining part liquidated;
Hi Supriyo, feedback changes implemented #137
With regards to timings of select, on_select, init, on_init, confirm, on_confirm - we are noticing the LSPs are taking about 2-3 seconds to respond. I've collated sample time logs below for your references indicating our request and response timings.
-
select, on_select
-
Init, on_init
-
confirm, on_confirm
logs cleared for v1.1.0