Nobrokerhood (RET10, RET11) - compliance check

[BLR-0118]

flow 1

1. /on_search - log here:

   • country of origin (item.tags.origin.country) should be ISO alpha-3 code, i.e. "IND", not "India";
   • for item (19746-ONDC-1-1), name shows "SAKTHI TURMERIC POWDER 50G" but item unitized qty shows "1 unit"; this should be fixed as: item.quantity.unitized.measure.unit should be "gram", value - "50";
   • for same item, category_id shows "Fruits and Vegetables"; shouldn't it be "Masala & Seasoning"?
   • for provider serviceability using new construct (bpp/providers.tags), why don't you use type "12" for pan-India, as shown here? @AbinayaM - for you to address;

2. /on_search (inc) - log here:

   • this looks like full catalog pull, not incremental;
   • incremental only supports item update, provider / location enable / disable / close; @ITCStore - for you to address;

3. Catalog is pulled for grocery but order created for F&B in flow 2:

   • bap_id in flow 2 (/select) is different from bap_id in flow 1 (/search);
   • Context.domain in flow 2 is incorrect but correct in flow 1;
   • to clear logs, we need the following:
   • 1 end-to-end customization flow (flow 1 to 5) for F&B;
   • 1 end-to-end non-customization flow (flow 1 to 5) for any other category;
   • /search & /on_search for other categories;
   • when will you enable flow 6 (scenario 1 & 3 reqd for all hyperlocal categories); @Rajkumar1994sof - for you to address

[quantummach14]

@BLR-0118 There was no change in the catalog. hence, we sent an empty items array in on_search(inc). Now, we have changed and not sending on_search if there is no change in the catalog.

[Rajkumar1994sof]

@BLR-0118 We have resubmitted all 5 flow logs again, Flow 6 we will submit shortly sellers yet to response for generating that logs

[BLR-0118]

Flow 1

1. /on_search (incremental):
   • is incremental push supported for item / merchant updates?
   • concurrent processing of full/inc updates?

Flow 2

1. /select, /init:

   • "display" is invalid key, pls remove;
   • any reason why bap_uri for flow 2 onwards is different from flow1?

2. /init:

   • fulfillment keys are invalid: atOndcorgcategory, atOndcorgTAT, atOndcorgproviderName; (correct keys are already in the payload);

3. /confirm:

   • following keys in quote.breakup are invalid: atOndcorgtitleType, atOndcorgitemId, atOndcorgitemQuantity;

[BLR-0118]

@Rajkumar1994sof - pls fix & resubmit only for issues above, Uengage issues reported here;

[Rajkumar1994sof]

1)any reason why bap_uri for flow 2 onwards is different from flow1? -- Search is handled by different team in my side --- display" is invalid key, pls remove; its coming from seller NP

[BLR-0118]

@Rajkumar1994sof - "display" is being sent in /select for 1st time in item (display for custom menu under bpp/providers.categories is ok);

[Rajkumar1994sof]

https://github.com/ONDC-Official/v1.2.0-logs/pull/646/files#

have uploaded the logs again @BLR-0118

[Rajkumar1994sof]

is incremental push supported for item / merchant updates? --- yes concurrent processing of full/inc updates? -- No

[BLR-0118]

Above issues are fixed; however, need clarification on the following:

1. why is bap_uri different for /search & subsequent APIs - you mentioned that different teams handle this, but this needs to be the same in prod;
2. Flow 3:
   • why is transaction_id changing between /select (unavailable) & /select - this needs to be the same as this is for the same buyer and seller NPs optimize based on transaction_id being same;
   • error message being sent by Uengage for item out of stock is invalid & I've mentioned to them; wanted to check if you have logic in place to process correct error message as per the format mentioned for this scenario?
3. Flow 4 & 5:
   • /on_cancel response from Uengage is invalid & I've raised to them; wanted to check if you have logic in place to process the correct response as mentioned in contract here & here?

[BLR-0118]

4. Concurrent processing of full & incremental catalog:
   • it's possible that you have full catalog & incremental catalog concurrently in queue;
   • to handle this scenario, there's versioning (using timestamp) for each catalog component, i.e. provider, provider.location, provider.location.item;
   • do you have logic in place to identify latest update for any catalog component, e.g. item, using the timestamp?

[BLR-0118]

@Rajkumar1994sof - pls respond to the above

[Rajkumar1994sof]

1. Our bap_uri will be same in pre-prod and prod also. this is just while capturing the logs we have routed it to different endpoint and storing the json as files (different people are generating logs for search and for rest of the flows). Wont happen in production.

2)why is transaction_id changing between /select (unavailable) & /select - this needs to be the same as this is for the same buyer and seller NPs optimize based on transaction_id being same; --- will correct this and resubmit , it just a mistake we have during log generation instead of using the existing transaction by mistake started a new transaction

3.Our side implementation is clear

[BLR-0118]

@Rajkumar1994sof - can you respond to the others (pt 2 - error message, pt 4)?

[BLR-0118]

@Rajkumar1994sof - all flows correct, except pt 4 above (for concurrent full & inc catalog updates) which needs to be fixed;

[BLR-0118]

logs cleared for v1.2.0 (RET11)

[BLR-0118]

@Rajkumar1994sof - request you to share /search & /on_search logs for grocery (RET10)

[BLR-0118]

logs cleared for v1.2.0 (RET10)