Aurikatech (SA: RET12) - Compliance Check

[Jagannath-wits]

Flow 1

on_search_full_catalog_refresh

• tmpstmp: Timestamp difference between /on_search and /search should be less than 5 seconds.
• prvdr0categories: Support for variants is mandatory; categories must be present in bpp/providers[0].
• prvdr0/tags/timing/Delivery: The timings object must be present for Delivery in the tags.
• desc: Short description (short_desc) and long description (long_desc) should be different.

search_inc_refresh

• tmpstmp: Timestamp for /on_search API cannot be greater than or equal to /inc_search API.

on_search_inc_refresh

• on_search_inc_refresh_msgId: Message ID should not be the same as previous calls since it's an incremental push-based call.
• tmpstmp: Context/timestamp difference between /on_search_inc and /inc_search should be less than 5 seconds.
• tmpstmp/: Timestamp for /on_search API cannot be greater than or equal to /on_search_inc API.

Flow 2

on_init

• message.order: 'cancellation_terms' in /message/order should not be provided as they are not enabled yet.
• invoice: invoice should be publically accessible

on_status_delivered

• payment/status: Why the payment status is 'NOT-PAID' even after the delivery and when the payment/type: "ON-FULFILLMENT"

Flow 3

on_select_out_of_stock

• error.message: The error.message provided in the on_select_out_of_stock should be in the form of an array with proper error_code and item_id. For example: [ {"item_id":"I1","error":"40002"}, {"item_id":"I2","error":"40002"}, {"item_id":"I3","error":"40002"} ]

Flow 4

on_cancel

• inititated_by: This should be bap_id

Flow 5

on_cancel

• rtoFFObj/end/time: Fulfillment type rto end/time should not be present in /on_cancel when state/desc/code is RTO-Initiated.
• inititated_by: This should be bpp_id

Flow 6

on_status_delivered

• payment/status: Why the payment status is 'NOT-PAID' even after the delivery and when the payment/type: "ON-FULFILLMENT"

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_part_cancel

• status: Why the payment status is 'NOT-PAID'.

on_update_interim_reverse_qc

• status: Why the payment status is 'NOT-PAID'.
• message/order.payment/@ondc/org/settlement_details/0: Missing payment/@ondc/org/settlement_details compared to update_settlement_part_cancel, i.e. { "settlement_counterparty":"buyer", "settlement_phase":"refund", "settlement_type":"upi", "settlement_amount":"472899.32", "settlement_timestamp":"2024-05-29T09:13:38.327Z" }
• provider/items/0 : Tags are not required in the item with id: a9fd801c-3673-4305-93fe-78bd7fa95cd2

on_update_approval- Same as above

• Return.start.location.id: Return fulfillment start location ID is not required in on_update_approval.
• returnFF/start/time/range/start: Start/time/range/start time of return fulfillment should be greater than context/timestamp of on_update_approval.

on_update_picked

• status: Why the payment status is 'NOT-PAID'.
• message/order.payment/@ondc/org/settlement_details/0: Missing payment/@ondc/org/settlement_details compared to update_settlement_part_cancel
• Return.start.location.id: Return fulfillment start location ID is not required in on_update_picked.
• invldQuoteTrailPrices: Quote trail price and item quote price sum for on_update should be equal to the price as in on_confirm. The fulfillment_id 6656f2cef274d6d7d7b293de has different price in quote_trail and quote. Why ?

on_update_delivered

• status: Why the payment status is 'NOT-PAID'.
• message/order.payment/@ondc/org/settlement_details/0: Missing payment/@ondc/org/settlement_details compared to update_settlement_part_cancel
• Return.start.location.id: Return fulfillment start location ID is not required in on_update_delivered.
• invldQuoteTrailPrices: Quote trail price and item quote price sum for on_update should be equal to the price as in on_confirm. The fulfillment_id 6656f2cef274d6d7d7b293de has different price in quote_trail and quote. Why ?

@vanshraghav

[vanshraghav]

Hi @Jagannath-wits ,

Can you please clarify our doubts about the below questions?

1. prvdr0/tags/timing/Delivery: The timings object must be present for Delivery in the tags.

   Regarding this issue, we already have a timing object inside the tags for bpp/providers with type = Order. Do you also want us to add a new timing object with type = Delivery in the API contract, the enums are not provided and in the example, the type is "ALL".Should we use "ALL" instead of type = "Order"? also, can you provide us with all the enums for the same?

2. Fulfillment type rto end/time should not be present in /on_cancel when state/desc/code is RTO-Initiated Also here we need to remove the end/time when the state is RTO-initiated but in the case of RTO-approved or any other state, do we have to keep this field?

[Jagannath-wits]

Hi @Jagannath-wits ,

Can you please clarify our doubts about the below questions?

1. prvdr0/tags/timing/Delivery: The timings object must be present for Delivery in the tags. Regarding this issue, we already have a timing object inside the tags for bpp/providers with type = Order. Do you also want us to add a new timing object with type = Delivery in the API contract, the enums are not provided and in the example, the type is "ALL".Should we use "ALL" instead of type = "Order"? also, can you provide us with all the enums for the same?

• You can use All if you have same timing for both order and delivery; but if there are different timings you should provide it separetely

2. Fulfillment type rto end/time should not be present in /on_cancel when state/desc/code is RTO-Initiated Also here we need to remove the end/time when the state is RTO-initiated but in the case of RTO-approved or any other state, do we have to keep this field?
   • You have to send an on_staus_rto_delivered after on_cancel_rto_initiated which will have the end.timestamp

@vanshraghav

[vanshraghav]

Hi @Jagannath-wits In on_update_interim_reverse_qc

provider/items/1 : Return fulfillment for the item_id a9fd801c-3673-4305-93fe-78bd7fa95cd2 should be created at on_update_picked

for the above issue the items array contains 2 items one is for the Delivery, another for the part_cancel . We don't add the item for returns in this request. In on_update_picked it was created, so you can also observe that the number of items in the items array increases to 3.

provider/items/0 : Tags are not required in the item with id: a9fd801c-3673-4305-93fe-78bd7fa95cd2

Also here the tags are only available for the Delivery item not for the cancelled item or return item .

[Jagannath-wits]

Hi @Jagannath-wits In on_update_interim_reverse_qc

provider/items/1 : Return fulfillment for the item_id a9fd801c-3673-4305-93fe-78bd7fa95cd2 should be created at on_update_picked

for the above issue the items array contains 2 items one is for the Delivery, another for the part_cancel . We don't add the item for returns in this request. In on_update_picked it was created, so you can also observe that the number of items in the items array increases to 3.

• This seems correct please disregard this error.

provider/items/0 : Tags are not required in the item with id: a9fd801c-3673-4305-93fe-78bd7fa95cd2

Also here the tags are only available for the Delivery item not for the cancelled item or return item .

• But it is not required i.e its only required when you have a customization along with it, but since this is just item from beginning it is not required here. So for standalone SKU's item.tag is not required .

[pareenjain]

@Jagannath-wits we have made all the above fixes and the changes have been merged in this PR. Can you please review and confirm if we can get Tech Log clearance for our retail flows? cc: @vanshraghav

[Jagannath-wits]

Flow 1

on_search_full_catalog_refresh

• Image: "Images links are not accessible for e.g. item_id :fb04a222-6875-41b5-a724-b51ec4ba3b18, https://test-ondc.s3-ap-south-1.amazonaws.com/9c5da599-6978-4fa4-9d33-b091f988af4d/product_image/021 (1).png"
• @ondc/org/return_window : "For the item_id 883893ad-b8aa-485c-af67-bdfecff9ba84, return_window can't be "@ondc/org/return_window": "P0D""

  Flow 2

on_status_picked

• Invoice: "Kindly provide an appropriate invoice related to your domain"

Flow 4

on_cancel

• item/tags: "Tags are not required in order/items"

Flow 5

on_cancel

• item/tags: "Tags are not required in order/items"

Flow 6

on_status_picked

• Invoice: "Kindly provide an appropriate invoice related to your domain"

on_init

• schemaErr0: "/context/action must be equal to constant (on_init)"
• schemaErr1: "/message/order must have required property 'quote'"
• schemaErr2: "/message/order must have required property 'payment'"
• schemaErr3: "/message/order must have required property 'tags'"

confirm

• sttlmntdtls: "Payment settlement_details mismatch in /on_init & /confirm"
• confirmTags: "Tags should have the same and valid gst_number as passed in /on_init"

on_update_part_cancel

• schemaErr0: "/context/action must be equal to constant (on_update)"
• schemaErr1: "/message/order/payment/params must have required property 'transaction_id'"
• on_update_part_cancel_msgId: "Message id should not be same with previous calls"
• message/order.fulfillments/Cancel: "Fulfillments/Cancel is missing in on_update_part_cancel"
• cancelRequest: "Cancel request is not present in the 'Cancel' fulfillment"

update_settlement_part_cancel

• fulfillmentID: "Cancel fulfillment ID should be the same as the one in /on_update API"

on_update_interim_reverse_qc

• schemaErr0: "/message/order/payment/params must have required property 'transaction_id'"

on_update_approval

• schemaErr0: "/message/order/payment/params must have required property 'transaction_id'"
• returnFF/start/time/range/: "start/time/range/start should not be greater than or equal to start/time/range/end in return fulfillment"
• returnFF/end/time/range/: "returnFF/end/time/range/ is not a required attribute as per the API contract"

on_update_picked

• schemaErr0: "/message/order/payment/params must have required property 'transaction_id'"
• returnFF/start/time/timestamp: "start/time/timestamp of return fulfillment should be in the valid time/range as in on_update_approval"
• returnFF/start/time/range/: "returnFF/start/time/range/ is not a required attribute as per the API contract"
• returnFF/start/person/name: "returnFF/start/person/name is not a required attribute as per the API contract"

on_update_delivered

• schemaErr0: "/message/order/payment/params must have required property 'transaction_id'"
• returnFF/start/person/name: "returnFF/start/person/name is not a required attribute as per the API contract"
• returnFF/start/time/range/: "returnFF/start/time/range/ is not a required attribute as per the API contract"
• returnFF/end/time/range/: "returnFF/end/time/range/ is not a required attribute as per the API contract"
• returnFF/start/time/timestamp: "start/time/timestamp of return fulfillment should be in the valid time/range as in on_update_approval"

rtoFFObj/end/time: Fulfillment type rto end/time should not be present in /on_cancel when state/desc/code is RTO-Initiated.

• Why hasn't this been resolved before submitting for reiteration ? Also please provide an on_status_rto-delivered or rto-disposed after on-cancel. Please refer to Contract for more clarification also submit the utility response and payload for each flow in next iteration.

@vanshraghav

[vanshraghav]

Hi @Jagannath-wits ,

1. The image url ( https://test-ondc.s3-ap-south-1.amazonaws.com/9c5da599-6978-4fa4-9d33-b091f988af4d/product_image/021 (1).png ) is accessible . You should try copy pasting the whole url .

2. What should be the return_window value for non-returnable items?

3. Also for item/tags: "Tags are not required in order/items" . Is the tags are also not required in the on_init,on_confirm or any other call or are they not only required in on_cancel.

4. Also For the below issues

returnFF/start/person/name: "returnFF/start/person/name is not a required attribute as per the API contract" returnFF/start/time/range/: "returnFF/start/time/range/ is not a required attribute as per the API contract" returnFF/end/time/range/: "returnFF/end/time/range/ is not a required attribute as per the API contract" returnFF/start/time/timestamp: "start/time/timestamp of return fulfillment should be in the valid time/range as in on_update_approval"

Why these were not flagged in the first iteration only ? we should have fixed them also in the first go only.

As for your question rtoFFObj/end/time: Fulfillment type rto end/time should not be present in /on_cancel when state/desc/code is RTO-Initiated.

We will resolve this issue surely in this iteration , we missed this in the previous one .

[pareenjain]

@Jagannath-wits we have fixed all the above issues and are changes have been merged. Can you please review our logs now?

[Jagannath-wits]

Aurikatech

Flow 1

on_search

• servicability for rings missing as serviceability is provided for each category_id

  on_search

• Incomplete payload, no updates present

Flow 2

On_init

Only @ondc/org/buyer_app_finder_fee_type, @ondc/org/buyer_app_finder_fee_amount,@ondc/org/settlement_details are required in payment object as only buyer is collecting payment currently. Incase seller wants to collect the payment then you can send it the way you sent but then it wont change in confirm call; right now payment is only accepted by buyer on network so the payment object in confirm is correct item/tags/type in items is not required for standalone SKUs (non-customizable)

Flow 3

on_select_oos

Select multiple items for flow 3 as mentioned in rollout plan

Flow 5

on_cancel

You can charge for delivery in this as the order was already out for delivery returnFF/start/person/name: "returnFF/start/person/name is not a required attribute as per the API contract"(repeated) returnFF/start/time/range/: "returnFF/start/time/range/ is not a required attribute as per the API contract"(repeated) returnFF/end/time/range/: "returnFF/end/time/range/ is not a required attribute as per the API contract"(repeated)

Flow 6

/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_status_picked

Invoice should’ve been updated after part-cancel (repeated)

@vanshraghav

[pareenjain]

@Jagannath-wits we have fixed all the above issues and are changes have been merged. Can you please review our logs now?

[Jagannath-wits]

Flow 1

On_search

• Attribute base_metal is repeated in items.

Flow 4

on_init

• Only @ondc/org/buyer_app_finder_fee_type, @ondc/org/buyer_app_finder_fee_amount, @ondc/org/settlement_details are required in payment object as only buyer is collecting payment currently(Repeated)

Flow 6

on_init

• Only @ondc/org/buyer_app_finder_fee_type, @ondc/org/buyer_app_finder_fee_amount, @ondc/org/settlement_details are required in payment object as only buyer is collecting payment currently(Repeated)

  on_confirm

• quote/breakup/items is not required for standalone SKUs (non-customizable) (repeated)

on_status_out_for_delivery

• quote/breakup/items is not required for standalone SKUs (non-customizable) (repeated)

@vanshraghav please fix repeated issues in next iteration

[sandeepshahi]

Flow 1

/on_search

• store timings provided in time/schedule is not in sync with the timings provided in /tags/timing; use time/range instead of "frequency" and "times"
• invalid attribute code "colour name"; should be "colour_name"
• attribute enum related values should be in lower case

/on_search (inc)

• invalid response; why is the callback response provided after incremental search is stopped by BNP?

Flow 2

/on_init

• bpp_terms should only include "np_type", "tax_number" and "provider_tax_number"; other tnCs are not yet enabled

/on_confirm

• how can estimated pickup/delivery time ranges be provided even before seller acceptance
• estimated pickup and delivery range should be feasible
• end can't be earlier than start for delivery range; estimated ranges should also be in sync with the time to ship and delivery TAT

/on_status

• why is routing p2h2p when delivery is in same city ?
• fulfillment/tags/rto_action is required only if fulfillment type is "Buyer-Delivery"
• Pan no. is not captured correctly in the invoice

Flow 3

• Invalid Flow; order flow must be continued with the remaining item in the cart
• similar issues as above

/on_select

• tags/type in quote/breakup is not required for standalone SKUs; why is this inconsistent in flow 2 and flow 3?

Flow 4

• similar issues as above

/on_cancel

• invalid schema of quote_trail; id is missing for "delivery" and "misc"

Flow 5

• similar issues as above

/on_cancel

• industry standard for delivery attempt is 3; is retry_count = "1" intended?

Flow 6

• similar issues as above
• why is there discrepancy in the value of "@ondc/org/provider_name"?

/on_status (pending)

• discrepancies in the order; How can items be part cancelled even before /on_update API is triggered?

/on_update (part cancel)

• order state can't move from "Accepted" to "Created"

/on_update (approved)

• time object is not required in fulfillments/end for Return fulfillment; schema might be rejected by BNP for empty object

/on_update (picked)

• items/quantity/count for returned item will become 0 since remaining quantity is mapped to the return shipment: "6667ee036dd482f43c364eb7"
• type should be "delivery" instead of "Delivery" in tags/quote_trail
• return delivery timestamp can't be provided in picked state
• fulfillments/end/person is invalid for Return shipment

@vanshraghav

[pareenjain]

1. @sandeepshahi regarding the last two errors you flagged in /on_update (picked), they make sense.
2. But that also means that the last two errors that @Jagannath-wits had flagged in this comment should have been returnFF/end/time and returnFF/end/person instead of /start. Can you please confirm if my understanding is correct?

[Jagannath-wits]

1. @sandeepshahi regarding the last two errors you flagged in /on_update (picked), they make sense.
2. But that also means that the last two errors that @Jagannath-wits had flagged in this comment should have been returnFF/end/time and returnFF/end/person instead of /start. Can you please confirm if my understanding is correct?

- No, in those logs details were provided in start which was not required as mentioned @pareenjain

[pareenjain]

1. @Jagannath-wits does that mean we need to remove returnFF/start/time/range, returnFF/end/time/timestamp, returnFF/start/person/name as well as returnFF/end/person?
2. Why isn't returnFF/start/person/name required in on_update (picked)? Shouldn't it contain the buyer name?

[pareenjain]

@Jagannath-wits @sandeepshahi can you please respond to the above?

[pareenjain]

@sandeepshahi @Jagannath-wits we have addressed these issues, and the logs were merged in this PR. Can you please review these?

cc: @MishraTanishq619

[Jagannath-wits]

Flow 1

on_search

• Variant Path: The path is incorrect. It should be item.tags.attribute.base_metal (repeated error).
• Timings Object: The timings object is for 5 days, but the location shows it's open all 7 days.
• Timestamp Update: The timestamp of the catalogue should be updated whenever there is a change at that level. For example, if there is a change at the item level, the timestamp should update accordingly and not at each on_search. If an attribute value is not available, please do not provide it as an empty string.
• Back Image: The back_image should not be an empty string. If not available, please omit it.

on_search_inc

• Item Update Timestamp: When there is an update in the item, the timestamp should also be updated at the item level before the on_search_inc is sent.
• Invalid Image URL: Invalid image URL https://aurika-seller-app.s3-ap-south-1.amazonaws.com/[object Object] (repeated issue).
• Common or Generic Name of Commodity: This should not be an empty string but “NA” if not available (repeated issue).
• Attribute Value: If an attribute value is not available, please do not provide it as an empty string.
• Net Quantity or Measure of Commodity in Package: This should be in string format, not an integer.

Flow 3

on_select_out_of_stock

• Item Count and Quantity: The item count and quantity are not updated.
• Error Object: The error object is missing.

Flow 5

on_cancel_rto

• Convenience Fee: Why is there no convenience fee being charged when a delivery fee is being charged?

on_status_rto_delivered

• Fulfillments End Contact Email: Missing fulfillments.end.contact.email.
• Fulfillments Start Location ID: Missing fulfillments.start.location.id.

Flow 6

on_update_part_cancel

• Item Object Update: The item object is not updated after a part cancel.

@pareenjain

[pareenjain]

Flow 6 on_update_part_cancel Item Object Update: The item object is not updated after a part cancel.

@Jagannath-wits @sandeepshahi I think our items is being updated correctly only; we're part cancelling 2 items of the 5 items - no?

[Jagannath-wits]

Flow 6 on_update_part_cancel Item Object Update: The item object is not updated after a part cancel.

• @Jagannath-wits @sandeepshahi I think our items is being updated correctly only; we're part cancelling 2 items of the 5 items - no?

Acknowledged

[pareenjain]

@sandeepshahi @Jagannath-wits we have addressed https://github.com/ONDC-Official/v1.2.0-logs/issues/1764#issuecomment-2252829616, and the logs were merged in the PR https://github.com/ONDC-Official/v1.2.0-logs/pull/2166. Can you please review our logs?

cc: @MishraTanishq619

[sandeepshahi]

Flow 1

/on_search

• variant groups should be defined on the basis of relevant attributes; eg: brand should not be used
• For the above point, all SKUs (variants) with different variant grouping attributes as defined in /categories must be provided for verification
• letter casing of attribute enums must be the same as defined here; check hex code of colour

/on_search (inc)

• are all the scenarios of incremental call supported as mentioned in the contract?

Flow 2

/on_init

• "np_type" may be provided in tags/bpp_terms as mentioned earlier

/on_status

• Pending:

  • pickup time range should be future dated; start/time/range/start can't be past dated
  • estimated pickup and delivery range should be feasible and as per the time_to_ship and delivery TAT provided
  • for above point, isn't delivery TAT being calculated dynamically? should be calculated as per the pickup and delivery location

Flow 3

• Invalid Flow; order flow must be continued with the remaining item in the cart instead of adding new item to the cart

Flow 5

/on_cancel

• industry standard for delivery attempt is 3; is retry_count = "1" intended?

Flow 6

/on_update (part cancel)

• How can order be part cancelled even before order is accepted?

/on_update (approved)

• why is the end time range changing for already delivered forward shipment
• from where is the info like end/person/name and name, building, country in end/location/address getting fetched; check return fulfillment: "66a89a54e89918a4a6cd4a95"

/on_update (picked)

• price should have atmost 2 digits of decimal precision in quote_trail; check the discrepancy in the delivery prices in quote and quote_trail
• return pickup timestamp can't be future dated; check start/time/timestamp in return fulfillment

@pareenjain

[pareenjain]

1. _Flow 5 /on_cancel industry standard for delivery attempt is 3; is retrycount = "1" intended? Yes this one is intended because our offline logistics partner will attempt the delivery only twice. So we've kept retry_count = 1.

2. _Flow 6 /onupdate (part cancel) Probably we miss something on Flow 6 after on_confirm. After on_confirm,

   • Should the seller first accept the order, and then part cancel the order?
   • If yes, we will be sending on_status_pending (order state = "Accepted") with the initial order - correct?
   • Then after that we should be sending on_update_part_cancel; what will be order state here? Will it not be "Created"? If not "Created", the order state will not be "Created" in the entire flow - correct? In your previous comment, you had mentioned - order state can't move from "Accepted" to "Created"
   • After on_update_part_cancel, should the seller again accept the updated order to send another on_status_pending (with order state again as "Accepted")?

[sandeepshahi]

1. Flow 5: Ok
2. Flow 6: The order state will remain "Accepted" in /on_update and no need to resend the "Accepted" /on_status call.

@pareenjain, also, make sure the fees and charges in quote/breakup are feasible and not placeholder values

[pareenjain]

Changes merged in this PR.

[sandeepshahi]

Flow 1

/on_search

• decimal precision of store's gps can be of 6 digits; 6 digits gps precision is already accurate upto 1.1cm

/on_search (inc)

• are all the scenarios of incremental call supported as mentioned in the contract?

Flow 2

/on_status

• Pending:
  • estimated pickup and delivery range should be feasible and as per the time_to_ship and delivery TAT provided
  • for above point, isn't delivery TAT being calculated dynamically? should be calculated as per the pickup and delivery location

Flow 3

• Invalid Flow; how can completely out of stock item be selected again?

common issues:

• time duration more than 24 hours should be converted into days

@pareenjain, please resubmit logs for Flow 3 and answer the above mentioned queries

[pareenjain]

Flow 1 /on_search (inc) are all the scenarios of incremental call supported as mentioned in the contract?

As of now, we are only supporting item updates in incremental search. We plan to extend support to Scenarios 2-5 as well (i.e., all scenarios except offers), but hopefully that doesn't become a blocker for us to roll-out our MVP in Prod because the remaining scenarios should be taken care of in the full catalog search requests.

Flow 2 /on_status Pending: for above point, isn't delivery TAT being calculated dynamically? should be calculated as per the pickup and delivery location

We are calculating delivery TAT dynamically based on the pickup and delivery pincodes.

[pareenjain]

@sandeepshahi - we raised this PR resubmitting logs for Flow 1, 2, 3 - fixing all the above issues you've highlighted.

If you can merge this and let us know if our logs can now be approved for preprod.

[sandeepshahi]

/on_status

• delivery TAT is mentioned as 3 days, but estimated ranges show 5 days to deliver the order (14th Aug to 19th Aug)

@pareenjain, Please resolve the above issue and complete the pending submissions on the NP Portal for QA.

[pareenjain]

/on_status delivery TAT is mentioned as 3 days, but estimated ranges show 5 days to deliver the order (14th Aug to 19th Aug)

@sandeepshahi on the above, we have ensured a 3-day TAT between:

• fulfillments[0].start.time.range.start and fulfillments[0].end.time.range.start (14th Aug to 17th Aug), AND
• fulfillments[0].start.time.range.end and fulfillments[0].end.time.range.end (16th Aug to 19th Aug).

Isn't this correct?