CSC - compliance check

[BLR-0118]

Buyer App:

1. /support - no bpp_id/bpp_uri in Context;
2. No /update, /status, /track APIs
3. Pls submit logs for end-to-end order flow with a different seller app (not CSC)

[BLR-0118]

@Ashish0120

[BLR-0118]

Seller App:

1. /on_search - the coordinates provided "15.00000000,17.00000000" are showing a location in Chad. Pls provide valid gps coordinates;
2. /on_search - what does the fulfillment_id provided here "storeking/35/ab60c009-9738-46c7-91e3-78c7ba0ffec5" map to? It should be linked to an entry in Catalog.bpp/fulfillment;
3. /on_init - fulfillments.end.location.Address.areacode is invalid;
4. fulfillment.id is in /on_select but not in /on_init and in /on_confirm & /on_status it's null - this isn't correct;
5. /on_cancel - pls update as per the updated contract;
6. /on_update - needs to be supported;

[BLR-0118]

@Ashish0120

[insphere-ashish]

Seller App:

1. /on_search - the coordinates provided "15.00000000,17.00000000" are showing a location in Chad. Pls provide valid gps coordinates;
2. /on_search - what does the fulfillment_id provided here "storeking/35/ab60c009-9738-46c7-91e3-78c7ba0ffec5" map to? It should be linked to an entry in Catalog.bpp/fulfillment;
3. /on_init - fulfillments.end.location.Address.areacode is invalid;
4. fulfillment.id is in /on_select but not in /on_init and in /on_confirm & /on_status it's null - this isn't correct;
5. /on_cancel - pls update as per the updated contract;
6. /on_update - needs to be supported;

On the Seller Apps points mentioned above.

1. It is staging data, the entries are default coming from DB, on production the coordinates will be the ones saved for the provider as provided or captured by gps.
2. /on_search contract shows fulfillment_id in item, "It should be linked to an entry in Catalog.bpp/fulfillment" - Please elaborate on this.
3. "/on_init - fulfillments.end.location.Address.areacode is invalid" - - it is being sent by reference app and hence being forwarded by the seller.
4. For "fulfillment.id is in /on_select but not in /on_init and on_confirm & /on_init being null" - it seems reference app is not passing any fulfillment id in the fulfillments array object, which seems to me mentioned in the contract of init and confirm
5. "/on_cancel - pls update as per the updated contract" - Will do
6. "/on_update - needs to be supported" - we are not supporting cancellation/return on seller level.

PS: The git handle is @insphere-ashish and not @Ashish0120 , please use @insphere-ashish for further communications on git.

[insphere-ashish]

Buyer App:

1. /support - no bpp_id/bpp_uri in Context;
2. No /update, /status, /track APIs
3. Pls submit logs for end-to-end order flow with a different seller app (not CSC)

1. "/support - no bpp_id/bpp_uri in Context" - okay, we'll fix that
2. "No /update, /status, /track APIs"- we shall get /update implemented in buyer(for other sellers) and we'll look into /status & /track as well.
3. "Pls submit logs for end-to-end order flow with a different seller app (not CSC)" - we are not able to do that with other sellers, on search we have had responses but flow isn't being able to progress forward due to various reasons, that we have already mentioned on slack regarding lookup and authorization for stagingapigateway.bizom.in/ondc(https://ondc.slack.com/archives/C03CB47859Q/p1660381523630589) and beta.mystore.in(https://ondc.slack.com/archives/C03CB47859Q/p1660660176521099) and the issue still persists. We are able to get a catalog shown in our buyer app from "ondc.uengage.in" but on doing a /select request the /on_select is not as per the contract, orders.fulfillments is missing from /on_select callback response, hence the flow is broken. If there is a seller that has the search-to-confirm endpoints as per contract please provide with a search item name from the seller so we can get that seller in /on_search responses.

[BLR-0118]

Buyer App:

1. How is the timestamp for /select before /search, even though both use the same transaction_id?
2. why is there a mismatch between the timestamp for /on_select and /select?
3. What payment is used for this use-case? pre-paid or COD?
4. No /status API?
5. /update - return refund is initiated only after seller approves return request. In this case, seller returns NACK (means return isn't supported). How is then amount refunded?
6. /update - images are also required for return
7. /support - what is the ref_id here - transaction_id or order id?
8. what searches are supported - by item (yes - as per the use case), by category?

[BLR-0118]

@Ashish0120 - also pls share an updated APK

[insphere-ashish]

Buyer App:

1. How is the timestamp for /select before /search, even though both use the same transaction_id?
2. why is there a mismatch between the timestamp for /on_select and /select?
3. What payment is used for this use-case? pre-paid or COD?
4. No /status API?
5. /update - return refund is initiated only after seller approves return request. In this case, seller returns NACK (means return isn't supported). How is then amount refunded?
6. /update - images are also required for return
7. /support - what is the ref_id here - transaction_id or order id?
8. what searches are supported - by item (yes - as per the use case), by category?

1.How is the timestamp for /select before /search, even though both use the same transaction_id?

• We have changed the timestamp timezone to UTC now, it wasn't UTC when the request was made, probably why there was such a difference, we'll update the logs.

2.why is there a mismatch between the timestamp for /on_select and /select?

• Same as above, we'll test on the app and update the logs.

3.What payment is used for this use-case? pre-paid or COD?

• COD, POST-FULFILLMENT was passed as payment type.

4.No /status API?

• We have it implemented and will update the logs.

5./update - return refund is initiated only after the seller approves the return request. In this case, the seller returns NACK (means return isn't supported). How is then amount refunded?

• Okay, so is the /update request made without "payment" details ?? or with "payment" but having separate settlement_phase ( sale-amount, withholding-amount ) ? The item were already non-returnable from this seller hence the on_update NACK. We create the request as shown in the contract doc. Please do guide as to how the /update request should have been.

  We have looked into the process flow - return, and as far as can be understood, it says that the seller is expected to send /on_update with the status within the ttl, whatever communication the seller then has with the logistics is upto seller itself without any buyer influence, upon which whatever is decided (if the item is going to be picked or not) the logistics will update to seller, upon which the seller still being within the ttl will send the /on_update to the buyer notifying as to the status of the return request ( if it's accepted or not ) and if accepted the buyer can then request an /update to update the order's status upon which, the seller will then ask logistics for the status and will callback /on_status to buyer after logistics responds.

6./update - images are also required for return

• Okay, we shall make the required app changes.

7./support - what is the ref_id here - transaction_id or order id?

• it is a transaction id.

8.what searches are supported - by item (yes - as per the use case), by category?

• yes by category is also supported. We'll put that in the log as well if required.

[BLR-0118]

Buyer App (sellerapp - Bizom):

1. If /update is receiving a NACK for return/cancel, you can't initiate a refund for buyer. Hence, the update json is wrong;
2. Pls share the updated APK; Seller App (buyerapp - firstforwardondc):
3. /on_search - time to ship ("D1D") is wrong ISO8601 duration format;
4. /select is selecting item 694 which isn't returned in /on_search. Also, gps coordinates shown for store here is different from what's shown in /on_search;
5. /on_init - payment collected_by="BAP" is wrong. If payment is collected by buyer app prepaid (collected_by = "BAP", type="ON_ORDER"), it will come in /confirm and if collected COD (collected_by="BPP", type="POST-FULFILLMENT");
6. How does payment type and collected_by change between /on_init & /confirm?
7. /on_track - tracking is false in /on_confirm but shows as active here?
8. No /on_status, /on_update API?

[BLR-0118]

@insphere-ashish

[insphere-ashish]

@BLR-0118 Point 4. /select is selecting item 694 which isn't returned in /on_search. Also, gps coordinates shown for store here is different from what's shown in /on_search;

Please do tell which logs are you referring to ? which seller and buyer ??

[BLR-0118]

Seller App (with firstforwardondc):

1. /search specifies the fulfillment end location gps coords (12.971,77.594) whereas /on_search responds with provider with gps coords (15.000, 17.000). How's this possible?
2. /on_search shows value as 1.03 for items 644, 692 whereas /on_select shows value as 1.06. Why? Pls check the other points 5-8 above.

[BLR-0118]

@insphere-ashish

[BLR-0118]

Buyer App - search performance is very slow & takes about 20s to render a small catalog in pre-prod. In Prod where the catalogs will be much larger, this will not work. @insphere-ashish

[BLR-0118]

Pls fix issues above & resubmit logs for buyer & seller apps for verification