Crofarm (Otipy) BA - compliance check

sahil-ondc commented 7 months ago

Transaction logs should be submitted with some other counterparty NP, whose logs has been approved.

@harshitCrofarm

naveencrofarm commented 7 months ago

Hi @sahil-ondc Your reference seller app is not working . We have already raised this issue week before but still no response. We were wasting our time and resource and waited your seller app to work. How we can submit log from your seller app if it is not working. Please provide us solution.

vipul-jn commented 7 months ago

Dear @jainneerajnj , we mentioend the reason of the reference seller app issues inthe testing. Kindly provide your approval here.

sahil-ondc commented 7 months ago

Flow 1

search_inc

static_terms, static_terms_new should not be provided as empty string
effective_date should be provided once terms has been published publically

Flow 2

init

/message/order/billing created_at and updated_at should be in correct format

confirm

/message/order/tags/bap_terms/tax_number should be correct
/message/order/id cannot be equal to /context/transaction_id
/message/order/payment/params/transaction_id should be unique in every transaction

status

Transaction call should be provided

Flow 6

update (return request)

reason_desc, images should be provided (should not be "")

@harshitCrofarm

vipul-jn commented 7 months ago

@sahil-ondc @sandeepshahi can you please explain the comment for the flow 2 status Transaction call should be provided

Seller app is already providing the updates of the order status.

vipul-jn commented 7 months ago

@sahil-ondc @sandeepshahi pls review the logs again!!

sandeepshahi commented 7 months ago

/search (inc)

bap_terms (static terms) need not be provided now; avoid using placeholder values in the payloads
time ranges for one time incremental should be feasbile;
is push based incremental supported?

/init

timestamps in /billling can't be future dated

/confirm

"tags" in /items is only required for customized item
settlement_basis is mentioned as delivery. is this correct?

Flow 3

/select (success)

transaction_id should not change for the session; must be the same as in /select (OOS)

Flow 4

/cancel

/descriptor should only be used for fulfillment cancellation in case of TAT breach

Flow 6

/update FYI refund call for part cancellation is missing

@vipul-jn @naveencrofarm

sandeepshahi commented 6 months ago

/search (inc)

txn id and mssg id can't be the same as in full search pull

/confirm

uri should be the P/G link of BNP. uri and tl_method in /payment are optional

/status

no callback response

@vipul-jn @harshitCrofarm @naveencrofarm

BLR-0118 commented 6 months ago

pls clarify the following:

are you supporting incremental catalog push (logs are submitted for pull only)?
while processing concurrent catalog updates (full, incremental), are you using the timestamp at provider / item level for correct versioning?
is /select being called for every change in cart, with same transaction_id?
how are you processing callbacks (e.g. /on_select) received out of sequence?
while processing unsolicited callbacks, are you ensuring that each such callback response has unique message_id for a specific transaction_id?
have you enabled the /confirm & /on_confirm process flow as doc here?
validation of cancellation reason codes when initiated by SNP?
processing hyperlocal vs intercity fulfillment states using routing.type of "P2P" or "P2H2P";

@harshitCrofarm:

pls clarify the above;
would be great if you can share a recorded demo;
if you need clarifications, we can have a call where you can also show the demo?

vipul-jn commented 6 months ago

Hi Supriyo,

Pls find our response on your open questions:

we are supporting both pull & push incremental search. All search cases were checked in the QA testing (with Praman app).
Yes, we do update the product/provider info based on the timestamp of the previous update.
Yes, /select is being called for any change in the cart (item update, location update, ttl exceed).
Flow is synchronous. /init api will be called only when "/on_select" api response is received without any error (ACK). Similarly for other flows as well.
All the api payload are captured against a unique txn_id. So dup check is being done.
/confirm & /on_confirm api impl ensure that both BNP & SNP maintain the same state. We have implemented retry mechanism in case we don't receive ACK/NACK or /on_confirm call.
Cancellation reason is validated against the defined codes.
We are processing hyperlocal fulfilment states as mentioned in the API Doc.

BLR-0118 commented 6 months ago

@vipul-jn - thanks, can you pls share a recorded demo to check the UX?

BLR-0118 commented 6 months ago

@naveencrofarm - wanted to check how the UX looks for a complete order & post-order flow; it's also ok if you want to show over a call

naveencrofarm commented 6 months ago

Hi @BLR-0118 PFA the demo video urls

https://storage.googleapis.com/crofarm/crofarmweb/RPReplay_Final1713426625.MP4

https://storage.googleapis.com/crofarm/crofarmweb/demo.MP4

BLR-0118 commented 6 months ago

@naveencrofarm - thanks for sharing the demo. Couple of UX suggestions:

Next to store name, also add locality (part of /on_search), so if multiple stores of same name are shown, it doesn't confuse the buyer e.g. instead of showing "Hopcoms Bangalore" multiple times, you can show "Hopcoms Jayanagar", "Hopcoms JP Nagar", "Hopcoms Indiranagar", etc.;
For items, instead of showing "1 unit", you can display as "1 piece" e.g. for coconut, show "1 piece";
Any plans to show store distance from buyer location?

BLR-0118 commented 6 months ago

clearing logs for v1.2.0 (RET10)

ONDC-Official / v1.2.0-logs