EkSecond (RET11) - compliance check

[BLR-0118]

Flow 1

1. /on_search (catalog full refresh):

   • item.quantity.available.count has values of "0" (out-of-stock) or "99" (in-stock);
   • item.quantity.maximum.count has values of "99" (default, means no cap per order) or any other non-default value identifying cap per order;
   • how to interprete values such as "10" in your logs?
   • fulfillment ids in bpp/providers.fulfillments & bpp/fulfillments should match;

2. difficult to correlate full & incremental catalog refresh as incremental refresh is for items which aren't in full catalog refresh; are all items in incremental refresh new?

Flow 2

1. /select:
   • can't match the items with the catalog e.g. item id 64ba6b25b21b773b4ff31a07 shows as custom_group in catalog while item 10469330 is not found in catalog;
   • may be the catalog log sent is incorrect as it has timestamp earlier (30/1/24 12:04) than /search (30/1/24 18:00);

[BLR-0118]

@NajeebMohammed - pls resubmit logs as whatever is shared can't be verified;

[BLR-0118]

Flow 1

1. /on_search (full refresh):

   • pls remove "accept_bap_terms" (will be enabled with static terms);
   • there are 37 custom menu items defined (in flat structure); it'll be difficult for a buyer app to render this in limited screen real-estate;
   • all items in F&B should have type defined (e.g. items without type - 64677c095b34453159581116, 64677c095b34453159581117, 64639b831527f9bdba11a619);
   • for items with price of 0 (e.g. 64ba6b25b21b773b4ff31a07), consider using either of the following (default_selection or upper/lower as defined here) to properly guide buyers in the provider listing page;

2. /on_search (incr):

   • for item 64677c095b34453159581116, max/avail qty is changed to 1000; means what?
   • in F&B, common scenarios such as store closure (definite duration), store closure (indefinite duration) + reopening need to be supported thru incremental refresh; hope this is supported?

[BLR-0118]

Flow 2

1. /on_select:

   • while quote is correct, items array is invalid & all items / customizations are shown as type "item"; (pls check here or /confirm log for exact format);
   • curious how you selected 10469329 twice?

2. /on_status (agent assigned):

   • what does fulfilment.start.time.duration indicate?
   • ready_to_ship, fulfillment.start.instructions (pickup code), fulfillment.end.instructions (delivery code) not reqd here (as seller NP is doing fulfillment);
   • add fulfillment.tags.routing.type to indicate whether P2P (hyperlocal) or P2H2P (inter-city);
   • tracking should be enabled for all hyperlocal orders;
   • either gps_enabled (for tracking by gps coords in hyperlocal) or (url_enabled & url) (for tracking by URL in inter-city) should be set to "yes";

3. /on_status (order delivered):

   • pickup time (fulfillment.start.time.timestamp) here is different from what's in /on_status (order picked up);

4. /track & /on_track are required for F&B;

Flow 3

1. /on_select (out of stock):
   • error.message format is wrong (needs to be in the format here);
   • dynamic_item_id should be added, "shortItems" removed;

Flow 4

1. /on_cancel:
   • items[] is invalid: new fulfillment is reqd for cancellation (1esd-C1 - already there), qty for items in forward shipment fulfillment ("1-esd") should become 0 & all qty assigned to the cancel fulfillment;
   • precancel_state is the fulfillment state just prior to becoming cancelled; hence, can't be "Cancelled";
   • cancellation was initiated by buyer app, hence cancelled_by should have the bap_id (not LSP);

Flow 5

1. /on_cancel (RTO initiated):
   • same issues as above;
   • if cancel is initiated by LSP, the subscriber id for LSP should be in cancelled_by;

[BLR-0118]

Hi @NajeebMohammed - pls fix the issues above & resubmit for flows 3, 4. 5; if you need any clarifications, let's connect; also, what are your plans on flow 6 (a, b) as doc here?

[NajeebMohammed]

Flow 1

1. /on_search (full refresh):

• pls remove "accept_bap_terms" (will be enabled with static terms);
• there are 37 custom menu items defined (in flat structure); it'll be difficult for a buyer app to render this in limited screen real-estate;
• all items in F&B should have type defined (e.g. items without type - 64677c095b34453159581116, 64677c095b34453159581117, 64639b831527f9bdba11a619);
• for items with price of 0 (e.g. 64ba6b25b21b773b4ff31a07), consider using either of the following (default_selection or upper/lower as defined here) to properly guide buyers in the provider listing page;

2. /on_search (incr):

• for item 64677c095b34453159581116, max/avail qty is changed to 1000; means what?
• in F&B, common scenarios such as store closure (definite duration), store closure (indefinite duration) + reopening need to be supported thru incremental refresh; hope this is supported?

1. Please ignore the 37 custom menus, this is our test data which we use for internal testing. In prod, we dont have as many custom menus.
2. Store close is already supported.

[BLR-0118]

Flow 1

1. /on_search (full catalog):
   • default_selection / upper & lower should only be used when base item price is 0 (for item 64677c095b34453159581116, price isn't 0);
   • "zomatoCatalog" is invalid key - pls remove;

Flow 2

1. /on_select:

   • for customization 10469329 & 10518831, why is the MRP used in the quote (as catalog shows price of 90 & max price of 100);
   • item available & max qty for items has become 1, while for customizations, it's 999; why can't we make it consistent with /on_search?

2. fulfillment.tracking is false in /on_select, /on_init but true in /on_confirm; can't we make it true everywhere as tracking is required for f&b orders;

3. /on_status (pending):

   • pls also add routing.type of P2P;
   • hyperlocal tracking is generally based on gps for P2P; hence, don't need to have gps_enabled, (url_enabled, url) all set to "yes";
   • tracking generally starts after fulfillment state of Agent-assigned; why's this starting at Pending?
   • you don't need to send pickup OTP unless fulfillment type is Buyer-Delivery;
   • to use OTP, use instructions.code for OTP & then use the authorization structure (as is already done);
   • start.location.descriptor.name has to be name of store; can't be "Manager";

4. /on_status (order picked up):

   • instructions.code values don't match for OTP for pickup & delivery;

5. /on_track:

   • tracking.id should match the fulfillment id (1-esd) for which tracking is enabled;
   • location.updated_at & time.timestamp are for 1/Aug/23 while on_track timestamp is 19/2/24 (can't be 6 months in the past);

Flow 3 - ok;

Flow 4

1. /on_cancel:
   • items array - 1st 4 entries are correct (with 0 qty); last 4 entries are wrong, e.g. item 64ba6b25b21b773b4ff31a07 with fulfillment id 1-esd-C1, qty 1 is correct (item 64ba6b25b21b773b4ff31a07-C is invalid item);
   • quote_trail should include refund of taxes as well;
   • quote_trail should also include refund of delivery charge, since cancellation happens when order isn't yet accepted (precancel_state is Pending);
   • quote is invalid, e.g. item 64ba6b25b21b773b4ff31a07 has qty 1, unit price of 100 (so total price should be 100, i.e. qty * unit price = 100);

Flow 5 - same issues as in flow 4;

[BLR-0118]

@NajeebMohammed - pls resubmit flow 2, 4,, 6b;

[BLR-0118]

Flow 1

1. /on_search (full catalog):
   • message.zomatoCatalog is invalid key, pls remove;

Flow 2

1. /on_select:

   • quote.breakup[] for item (10518835): unit price (decimals) is in 3 digits (can be up to 2 digits);
   • there are few other line items (including tax) that has the problem;

2. /on_init:

   • tax_number & provider_tax_number to be added;

3. /on_confirm:

   • fulfillment TAT is 1hr 49min but pickup slot is between 11:08 (when order placed) & 12:13 (gap of 1 hr 5min): how's this possible?
   • pls also add delivery slot;

4. /on_status_pending:

   • gps_enabled, url_enabled, url should be set only when the order can be tracked (i.e. either at Agent-assigned or Order-picked-up);
   • for hyperlocal F&B, only gps_enabled should be set to "yes" (not url_enabled, url);

5. /on_status_order_pickedup:

   • remove fulfillment.start.instructions (for order pickup code, etc.): this should only be sent here if fulfillment.type is "Buyer-Delivery", i.e. buyer app is providing logistics & seller NP forwards the pickup code to buyer app for forwarding to LSP;
   • above is provided for merchant to verify LSP collecting order; hence, even when it's being sent (as explained above), it should happen before order is picked up;

6. /on_track:

   • location.time.timestamp is the "as of" timestamp for gps coords;
   • location.updated_at is when the gps coords where updated in system;
   • hence, location.updated_at >= location.time.timestamp (this isn't the case, pls fix);

Flow 5

1. /on_cancelRTO_initiated:

   • remove ready_to_ship;
   • above only to be sent to buyer app when they're handling fulfillment;

2. /on_status_RTO_delivered:

   • rto_event.sub_reason_id is invalid key, pls remove;
   • for F&B, fulfillment state should be updated to RTO-Disposed (RTO-Delivered is only if items are returned back to store);
   • rto_id is invalid (/on_cancelRTO_initiated has correct rto_id);

Flow 6

• no flows for merchant part cancel (6a), return with liquidation (6b);

[BLR-0118]

@NajeebMohammed - pls fix the above & resubmit flows 2, 5 & 6 only;

[NajeebMohammed]

/on_confirm: fulfillment TAT is 1hr 49min but pickup slot is between 11:08 (when order placed) & 12:13 (gap of 1 hr 5min): how's this possible? ES> These are sample numbers calculated based on TAT provided by the LSP. In produciton these numbers will make more sense.

gps_enabled, url_enabled, url should be set only when the order can be tracked (i.e. either at Agent-assigned or Order-picked-up); ES> We are receiving this from loadshare and we are passing as is.

Flow 5: for F&B, fulfillment state should be updated to RTO-Disposed (RTO-Delivered is only if items are returned back to store); ES> Loadshare doesn't support RTO-Disposed. Although we are passing rto flag as no, they are still returning RTO-Delivered. We are passing in as is. Should work ok in production.

Flow 6. no flows for merchant part cancel (6a), return with liquidation (6b); ES> part cancel we dont support. Full cancel (merchant rejection) already submitted.

[BLR-0118]

Flow 2

1. pls remove item.quantity.available.count & item.quantity.maximum.count from /on_init & /on_confirm;
2. /on_status_pending:
   • fulfillment state "Pending" maps to order state "Created" or "Accepted" (not "In-progress"); should this fulfillment state actually be "Packed"?
3. pickup time (fulfillment.start.time.timestamp was 7:55:19 in /on_status_order_pickedup but changed to 7:55:20 in /on_status_outfor-delivery (no change between /on_status_outfor-delivery & /on_status_delivered);
4. /on_track:
   • Context.timestamp date is 2nd march 24 but location.updated_at & location.time.timestamp dates are 1st Aug 23?

Flow 5

1. /on_cancel_RTO_Initiated:
   • cancel_request.rto_id has to match the id for RTO fulfillment;
2. /on_status_RTO_delivered:
   • delivery time (fulfillment.end.time.timestamp) is also required;

[BLR-0118]

@NajeebMohammed - pls have the above fixed & resubmit for flows 2 & 5; also, has "zomatoCatalog" key been removed from /on_search?

[NajeebMohammed]

• Context.timestamp date is 2nd march 24 but location.updated_at & location.time.timestamp dates are 1st Aug 23?

This data is coming from loadshare. We have notified them and they said its sample data.

[NajeebMohammed]

@NajeebMohammed - pls have the above fixed & resubmit for flows 2 & 5; also, has "zomatoCatalog" key been removed from /on_search?

Yes, this is removed.

[BLR-0118]

Flow 2

1. /on_confirm:
   • provider_tax_number should be PAN (not GST);
2. /on_track:
   • /track is solicited request, so why is Context.timestmap for /on_track earlier than /track?

[BLR-0118]

@NajeebMohammed - clearing logs but pls make sure 1 above is fixed & 2 is checked