PepStores - compliance check
Closed this issue · 12 comments
Flow 1
/on_search
- /message/catalog/bpp/providers/items/@ondc/org/statutory_reqs_prepackaged_food must have atleast one of the 'importer_FSSAI_license_no', 'brand_owner_FSSAI_license_no', 'other_FSSAI_license_no'
- statutory_reqs_prepackaged_food must have required property 'imported_product_country_of_origin'. Also check the correct statutory mapping here
- /message/catalog/bpp/providers/items/descriptor/images should not have more than 3 images (buyer apps can process only 3)
- Reverse geocoding of store location shows different pincode and address. How is it mapped? Also, the gps coordinates are same for different locations(/providers). Why?
- @ondc/org/contact_details_consumer_care should be in the format "name, email, contactno" in /bpp/providers/items
- location in serviceability construct should be one of the location ids bpp/providers/locations (serviceability must not be mapped incorrectly for different providers/locations )
- serviceability constructs (defined in /locations/circle and /tags) are conflicting with 3km and 50km radius.
/on_init
- invalid value of /fulfillments/provider_id (is an optional property)
- quote validity is 1 Day whereas it was 1 hour in /on_select. Why?
/on_confirm
- /quote must have required property 'ttl'
- estimated pickup and delivery time ranges should be present if RTS is triggered
/on_status
- Invoice should be present when order is picked (Order-picked-up) and thereafter ("documents" object should not be present before that)
- max(time_to_ship) is 1 day in /on_search, then why estimated pickup is taking the same amount of time as the delivery time (2 Days)
- Out-for-delivery: pickup time should be present (same as in Order-picked-up state)
- /quote must have required property 'ttl'
- /payment/@ondc/org/settlement_details/0/settlement_type should not change
/on_update
- must have required property 'payment'
- must have required property 'created_at'
- must have required property 'updated_at'
- /quote must have required property 'ttl'
- /quote/breakup/0 must have required property 'title'
- /quote/breakup/0/@ondc/org/item_quantity/count must be integer
- liquidated item should be present in quote/breakup with count=0
- /payment/@ondc/org/settlement_details/0/settlement_type should not change
Flow 2
- please follow the flow as per the test case scenario without initiating a new search request (txn id for select and select_non_serviceable should not change).
- make sure non-serviceable location is not falling in the serviceability construct range. (can't be checked due to invalid geocoding of gps and address)
Flow 4
/on_update
- /update payload for return initiation is missing (/update for refund is shared)
- Is the return getting initiated again after refund (FYI /update call) is processed?
check Flow 2,3,4,5 for similar issues in Flow 1
Flow 1
/confirm
- settlement_bank_account_no mismatches in payment/settlement_details. How is it handled at seller app's side?
/on_confirm
- incorrect unit price of items in quote/breakup
- time/gps is invalid attribute
- start/location/descriptor/name should be the provider name (instead of location id)
- start/time/range should be future dated
/on_status
- order.updated_at timestamp should match context timestamp
/on_update
- /quote/breakup/0 must have required property 'title'
- /quote/breakup/1 must have required property 'title'
Flow 2
/on_select (Non-serviceable)
- Isn't the fulfillment/end/location within the serviceability radius. If yes, how is it non-serviceable?
check Flow 2,3,4,5 for similar issues raised in Flow 1
/on_confirm
- delivery start time range precedes the pickup range start time. What is the logic used here?
- /fulfillments/0/start/location must have required property 'gps'
@BLR-0118, The PepStores logs seem fine, please review.
@quantummach14, In the revised logs, what is the reason for the extended response time of /on_select?
@bluecypher, Due to slow network issue file updation on server took little longer. Hence, you are seeing this delay in on_select.
Pls provide latest logs (for all flows) in one folder. Currently, it is scattered across multiple folders and it's difficult to find out which are the latest logs
- Why is it taking 2 days to deliver at a distance of 5 km? Should be Immediate delivery/SDD instead of Standard delivery in such cases
Flow 2:
/on_select
- context/message_id should be same as in /select
Flow 2,4
/init
- fulfillment_id created in /on_select is getting changed. How is this possible? How is it handled at seller app's end?
@bluecypher @BLR-0118 Delivery TAT is seller's decision which we shall decide as per our supply chain capability.
Point No.2: We are sending correct message ids. Here, in flow2, We always get 2 select request (on change of address)from buyer app. Hence, uploaded incorrect select file against on_select. Attached is the correct select request(serviceable). Updating correct select request in our logs.
Point No3: We are creating new fulfilment id every time we receive any new select request and this was never highlighted earlier and it is not breaking any flow.
Request you to kindly give your approval on our logs.
-
Delivery TAT should be realistic and feasible, even though it is seller's decision.
-
A new fulfillment ID getting created in /on_select is fine, but I haven't encountered a situation where the fulfillment ID changes in "/init" without any action being performed by the seller app. This is different from what I have observed in your previous logs and from other NP logs. I'm curious to understand how this can happen.
@bluecypher We have submitted fresh logs. PR: #292.
Request you please review.
PS: As explained over the call, buyer app is showing quantity 4 instead of revised qty, hence, in earlier logs we reduced the quantity manually(from buyer app) to 2. Which resulted in new select request.
While creating fresh logs, we checked the api request for "/init" and it is sending correct qty. It is a UI issue. Request you to get it rectified.