KNS Retail (SA : RET16) - Compliance Check

[Jagannath-wits]

KNS Retail

Flow 1 - On_search

• Coordinates: Please don't give space in between coordinates. Eg: "gps": "19.1129587, 72.8656954"

• Timestamp: How is the timestamp for search and on_search the same?

• URL Formatting: Formatting (such as "\") should not be present in the URLs. Eg:

  "images": [
      "https://ds-kas-bucket.s3.amazonaws.com/content-generation/51/gdg674g/27_03_24_06_21_15/secondary_image_1_photoroom_white_bg_output.png?AWSAccessKeyId=AKIA4P2YCRVLAA3JFCE6&Signature=2ru7G%2FYqOE16%2BrpaCD4hHgnc3zs%3D&Expires=1715575474"
  ]

• Maximum Value: Please provide a reasonable maximum value, i.e., 99 for no limit or some other reasonable value and not 194.

  "available": {
      "count": "99"
  },
  "maximum": {
      "count": "194"
  }

• Categories: Categories must be present in bpp/providers so we can check support for variants.

• Description: Short and long descriptions should not be the same.

• Image URLs: Image URLs should be publicly available. Error e.g., example URL

Flow 2 - On_confirm

• State: How can the state be Mumbai? Eg:

  "address": {
      "locality": "JB Nagar Chakala",
      "city": "Mumbai",
      "area_code": "400069",
      "state": "Mumbai"
  }

Flow 3 - on_select_oos

• Error Message: error.message in the response should have the list of corresponding item IDs referenced in stringified object notation.

  For example, if items "I1", "I2", "I3" are out of stock, error.message would be encoded as:

  "[{\"item_id\":\"I1\",\"error\":\"40002\"},{\"item_id\":\"I2\",\"error\":\"40002\"},{\"item_id\":\"I3\",\"error\":\"40002\"}]"

Flow 5 - On_cancel

• Timestamp: rto-fulfillment.end.timestamp should not be present as the state is rto_initiated and should only be provided in on_status-rto-delivered or on_status-rto-disposed.

Flow 6

• Update: update_settlement_liquidated is missing.

@VirajjKAS

[Jagannath-wits]

Flow 1

On Search Full Catalog Refresh

• bpp/providers[0]/items[0]/descriptor/code: Code should have 1:EAN as a value in /message/catalog/bpp/providers[0]/items[0]/descriptor/code.
• desc: Long desc and short desc code should not be the same. Example: For bpp/providers/descriptor, bpp/providers/items/0.
• prvdr0/tags/timing/Self-Pickup: The timings object must be present for Self-Pickup in the tags.
• prvdr0/tags/timing/order: The timings object must be present for Order in the tags.

Flow 2

On Init

• message.order: 'cancellation_terms' in /message/order should not be provided as those are not enabled yet.

Flow 4

• inititated_by: This should be bap_id

Flow 6

On Status Picked

• invoice: invoice should be publically accessible, please remove any expiration from the urls; It should also be update after part_cancel

On Update Reverse_Qc

• provider/items/1 : Tags are not required in the item with id: 614"
• provider/items/1 : Return fulfillment for the item_id 614 should be created at on_update_picked

On Update Approval

• ReturnFulfillment.end: Return fulfillment end object is missing in on_update_approval.
• ReturnFulfillment.start: Return fulfillment start object is missing in on_update_approval.

On Update Picked

• ReturnFulfillment.end: Return fulfillment end object is missing in on_update_picked.
• ReturnFulfillment.start: Return fulfillment start object is missing in on_update_picked.

On Update Delivered

• ReturnFulfillment.end: Return fulfillment end object is missing in on_update_delivered.
• ReturnFulfillment.start: Return fulfillment start object is missing in on_update_delivered.

Update Settlement Reverse QC

• context/timestamp/: Context timestamp of /update_settlement_reverse_qc should be greater than context timestamp of /on_update_delivered.

@VirajjKAS

[aniketmishra13122]

@Jagannath-wits hey jagannathan here Update Settlement Reverse QC context/timestamp/: Context timestamp of /update_settlement_reverse_qc should be greater than context timestamp of /on_update_delivered.

how can be update_settlement_reverse_qc can be greater then on_update_delivered becuse we get update_settlment_reverse_qc when item is picked up

[aniketmishra13122]

bpp/providers[0]/items[0]/descriptor/code: Code should have 1:EAN as a value in /message/catalog/bpp/providers[0]/items[0]/descriptor/code

for this i am passing the GTIN number 3:GTIN as mention on the log validation utility i am putting 1:EAN number it throws error in utilty

[Jagannath-wits]

@Jagannath-wits hey jagannathan here Update Settlement Reverse QC context/timestamp/: Context timestamp of /update_settlement_reverse_qc should be greater than context timestamp of /on_update_delivered.

how can be update_settlement_reverse_qc can be greater then on_update_delivered becuse we get update_settlment_reverse_qc when item is picked up

@aniketmishra13122 Please Disregard this error

[Jagannath-wits]

bpp/providers[0]/items[0]/descriptor/code: Code should have 1:EAN as a value in /message/catalog/bpp/providers[0]/items[0]/descriptor/code

for this i am passing the GTIN number 3:GTIN as mention on the log validation utility i am putting 1:EAN number it throws error in utilty

@aniketmishra13122 Utility hasn't been merged yet please proceed with EAN.

[Jagannath-wits]

Flow 1

on_search

• desc: short_desc and long_desc shouldn’t be the same. For example:
  • "short_desc": "KAS Store"
  • "long_desc": "KAS Store"

Flow 2

• Tags are not required in the items.item as there are no customizations here.

  on_status_picked

• invoiceErr: Invoice should be publicly accessible.

on_status_picked:

• { "code":"state", "list": [ { "code":"ready_to_ship", "value":"yes" } ] } This is required only if fulfillment.type="Buyer-Delivery", indicates whether fulfillment is ready to ship.

Flow 5

• Please flow 5 as well in next iteration.

  on_cancel

  • retry_count : retry_count is missing in cancel_request
  • on_status_rto-delivered or disposed should also be provided after on_cancel with updated end.timestamp in return fulfillment as mentioned before .

Flow 6

on_update_interim_reverse_qc

on_status_picked

• invoiceErr: Invoice should be publicly accessible, please remove any expiration from the URLs. It should also be updated after part_cancel.

@aniketmishra13122,

[sandeepshahi]

Flow 1

/on_search

• Why is the fulfillment ID different in bpp/fulfillments and fulfillments? Both IDs should be the same if the type is the same.
• is the geocoding of gps and address correct? reverse geocoding shows different area code
• EAN code seems to be invalid; EAN code is mostly provided for packaged branded products. For sofa and other products, you may use other codes
• Why is return window for products like Sofa set as 2 hours? Pls provide realistic and feasible values
• country of origin (items/tags/origin/country) should be in ISO 3166-1 alpha-3 code format
• back_image is optional and only required if details in "@ondc/org/statutory_reqs_packaged_commodities" are not present
• attribute value of material should be lower case as defined here
• serviceability for all item categories must be defined; It's not defined for categories like "Bathroom and Kitchen fixtures" etc.

/on_search (inc)

• similar issues as above
• as mentioned in the contract, are all the scenarios of incremental refresh supported?
• items mapped to new categories should not be provided in incremental refresh; since, serviceability is defined in the full catalog

Flow 2

/on_select

• Is the delivery TAT hardcoded as 8 days, or is it dynamically calculated? 8 days seems like a large TAT given the delivery and pickup locations provided
• why is the value of maximum/count changed in quote/breakup? value was 3 in the catalog
• why is the pricing of item changed? any change in the item's record should be updated via incremental refresh call
• prices must be tax inclusive for RET16 and separate line item for tax need not be provided
• tags/type in quote/breakup is not required for standalone SKUs (non-customizable)

/on_init

• context/timestamp can't be the same as in /init
• type, collected_by, uri, status, settlement_basis, settlement_window, withholding_amount in /payment should only be provided if seller NP is collecting prepaid payment
• time and tags in /payment should not be provided
• seller T&Cs need not be provided in bpp_terms; only tax_number, provider_tax_number and np_type should be provided
• ttl in /quote should not change

/on_confirm

• why is tracking property switched to true?
• delivery TAT in "@ondc/org/TAT" should not change

/on_status

• billing object should not change; must remain the same as in /init
• why is the address in /fulfillments/start changed?
• pcc/dcc in start/instructions and end/instructions should not be provided if not available; otherwise proper values should be provided
• when the estimated pickup time range is given for the first time, it should always be a future time.
• tracking in /tags should not be provided if tracking = "false"
• invoice should only be provided once the order is picked and thereafter;

Flow 3

• similar issues as above

/select

• item: "616" was completely out of stock as per on_select (OOS) call; how can this OOS item be selected again?
• why is the buyer's location changing in the second /select call

Flow 4

• similar issues as above

/on_cancel

• igm_request in /tags should only be provided if IGM was initiated before cancellation; placeholder values should not be provided in any of the APIs
• Why are delivery fees being charged even when the cancellation is done before shipment?
• order/updated_at can't be future dated

Flow 5

• similar issues as above

/on_cancel

• industry standard for delivery attempt is 3 retries; "retry_count" should be "3"
• quote_trail should only include prices with delta changes; delivery charges should not be part of quote_trail if amount is not being refunded

Flow 6

• similar issues as above

/on_update (part cancel)

• how can item be part cancelled even before accepting the order? /on_status (accepted) call is sent after the part cancellation

/on_update (return approved)

• estimated return pickup time range must be future dated

/on_update (liquidated)

• estimated time ranges for return fulfillment: "6662a1610f81911306b6b342" should not change; audit trail must be maintained

@VirajjKAS

[aniketmishra13122]

Hey @sandeepshahi ,

Thanks for your input. We have a few concerns regarding your checks. Could you please clarify the following:

EAN Code: The EAN code seems to be invalid. EAN codes are mostly provided for packaged branded products. For sofas and other similar products, we may need to use other codes. Jagannathan mentioned using EAN, which we are currently using, but previously, we were using GTIN. Could you suggest an appropriate code for unpacked items?

Serviceability for All Item Categories: Serviceability is not defined for categories like "Bathroom and Kitchen fixtures." Since these are subcategories under the parent category "Home and Kitchen," should we add serviceability for each subcategory individually, or should we define it once for the parent category "Home and Kitchen" (RET:16)?

Incremental Refresh Scenarios: As mentioned in the contract, are all scenarios of incremental refresh supported? We do handle store status and changes in items.

Delivery TAT: Is the delivery TAT hardcoded as 8 days, or is it dynamically calculated? Eight days seems like a long TAT given the delivery and pickup locations provided. This is dynamic, as our merchant receives orders from across India, so we asked them what the standard time to deliver an order should be.

Payment Fields: Fields such as type, collected_by, uri, status, settlement_basis, settlement_window, and withholding_amount in /payment should only be provided if the seller NP is collecting prepaid payment. Are you referring to the buyer's side payment while making the order?

Please review and let us know your thoughts

[sandeepshahi]

Flow 1

/on_search

• timestamp at providers, locations and items should be captured correctly; indicate when the record was updated in the system
• is the geocoding of gps and address correct? reverse geocoding shows different area code
• colour_name should be added to the attributes along with the colour;
• casing of attribute enums must be correct as mentioned in the list here
• please share the screenshot of the onboarding journey where information like EAN/HSN etc are being captured
• realistic and feasible values of return_window must be provided
• back_image is optional and only required if details in "@ondc/org/statutory_reqs_packaged_commodities" are not present
• unicode formatting should not be provided in the string values

/on_search (inc)

• search request seems mocked

Flow 2

/on_status

• billing object should not change; must remain the same as in /init
• when the estimated pickup time range is given for the first time, it should always be a future time
• pickup/delivery time ranges must be in sync with time to ship and delivery TAT
• From where is the tags/type in quote/breakup sourced? should not be provided for standalone SKUs

Flow 4

• similar issues as above

/on_cancel

• why are estimated pickup/delivery time ranges being provided when the order is getting cancelled? wasn't provided in /on_confirm earlier

Flow 5

• similar issues as above

/on_cancel

• start/address/name for RTO shipment is not captured correctly; check for other similar issues, if any

/on_status (delivered)

• actual pickup timestamp for cancelled forward shipment and RTO shipment should not change

Flow 6

• similar issues as above

/on_status

• why tags are added in /items?
• why is part cancelled item included in the invoice?

/on_update (return approved)

• start/address/name for Return shipment is not captured correctly; check for other similar issues, if any
• invalid quote_trail provided in Return shipment; should not be provided until quote is updated

@VirajjKAS

[aniketmishra13122]

Hey @sandeepshahi , thanks for the Suggestion we have few queries regarding your validation

1.back_image is optional and only required if details in "@ondc/org/statutory_reqs_packaged_commodities" are not present : in this case we are providing @ondc/org/statutory_reqs_packaged_commodities therefore we have shared the back image

2.billing object should not change; must remain the same as in /init : billing object seems same in both of the api

3>when the estimated pickup time range is given for the first time, it should always be a future time: these are future date only 4>pickup/delivery time ranges must be in sync with time to ship and delivery TAT: these are syn with TAT Only 4 days 5>why are estimated pickup/delivery time ranges being provided when the order is getting cancelled? wasn't provided in /on_confirm earlier : these is done as per contract in on_cancel api for forward shipment it is provieded

for FLow 5 also we have some issue

Hey Sandeep could we connect over call to discuss everything