ONDC-Official/v1.1.0-logs

Shopalyst - compliance checks

Closed this issue · 7 comments

Flow1

  1. /on_search:
  • "contact_details_consumer_care" should be in the same format as in the contract i.e. "name.email.contact#";
  • not sure why fulfillment_id is same as location.id. What happens if there are multiple fulfillments?
  • item.fulfillment_id here should identify fulfillment type (Delivery, Self-Pickup, etc.). In this case, it should be "1" which is what's mapped to delivery in bpp/fulfillments;
  1. /on_status:
  • timestamp > timestamp for /on_confirm; however, order.updated_at doesn't show the same updated_at as in /on_confirm;
  1. /on_status_pick has same order.updated_at as /on_status_pack even though it happened later;
  2. quote.ttl which was 15 min in pre-order APIs (/on_select, /on_init, /on_confirm) becomes 1 day in post-order APIs (/on_status*);
  3. return liquidated state should be thru /on_update (with same message_id as the original /update);

Flow 2

can't see payload for non serviceable (as per test case scenario)?

Flow 3

return rejected should be thru /on_update (as mentioned for flow 1 above);

Flow 5

  1. /on_select - for item "Hair Strengthening Shampoo", unit price is 499, qty is 2 but total price is 1000 (should be 499*2 = 998)

Hi @BLR-0118 all our sellers are Pan-India sellers and hence we do not have a scenario where serviceability is a concern. Hence for flow#2, we are not able to demonstrate this scenario. However, the other parts of the flow like un-solicited /on_cancel from seller are tested and logs are shared in the PR.

Flow 1

  1. /on_search: time.schedule.holidays is mandatory (empty array ok);
  2. /on_update_liquidated: should have same message_id as /update;

Flow 3

  1. /on_update_reject: suggest you use the same message_id as /update as currently there is no way to track every return request. This will be removed with the new version of the API which will handle this.

@kishorgandham - pls see comments above. Also, even though you handle pan-India serviceability, request you to provide sample payload for non-serviceable cases that may arise due to force majeure.

Hi @BLR-0118 we addressed the 3 issues from yesterday's review (time.schedule.holidays empty array, /on_update to use same message-id and serviceability check based on_select response). Kindly merge #77 and review

logs cleared for v1.1.0