Open Jagannath-wits opened 3 months ago
Hi @Jagannath-wits ,
Can you please clarify our doubts about the below questions?
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?
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?
Hi @Jagannath-wits ,
Can you please clarify our doubts about the below questions?
- 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?
- 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
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 .
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 .
- 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 .
@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
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
Hi @Jagannath-wits ,
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 .
What should be the return_window value for non-returnable items?
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.
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 .
@Jagannath-wits we have fixed all the above issues and are changes have been merged. Can you please review our logs now?
Aurikatech
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)
Select multiple items for flow 3 as mentioned in rollout plan
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)
Invoice should’ve been updated after part-cancel (repeated)
@vanshraghav
@Jagannath-wits we have fixed all the above issues and are changes have been merged. Can you please review our logs now?
@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)@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)
@vanshraghav please fix repeated issues in next iteration
/on_search
/on_search (inc)
/on_init
/on_confirm
/on_status
/on_select
/on_cancel
/on_cancel
/on_status (pending)
/on_update (part cancel)
/on_update (approved)
/on_update (picked)
@vanshraghav
- @sandeepshahi regarding the last two errors you flagged in /on_update (picked), they make sense.
- 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
@Jagannath-wits @sandeepshahi can you please respond to the above?
@sandeepshahi @Jagannath-wits we have addressed these issues, and the logs were merged in this PR. Can you please review these?
cc: @MishraTanishq619
item.tags.attribute.base_metal
(repeated error).on_search
. If an attribute value is not available, please do not provide it as an empty string.back_image
should not be an empty string. If not available, please omit it.on_search_inc
is sent.https://aurika-seller-app.s3-ap-south-1.amazonaws.com/[object Object]
(repeated issue).fulfillments.end.contact.email
.fulfillments.start.location.id
.@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?
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
@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
/on_search
/on_search (inc)
/on_init
/on_status
Pending:
/on_cancel
/on_update (part cancel)
/on_update (approved)
/on_update (picked)
@pareenjain
_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.
_Flow 6 /onupdate (part cancel) Probably we miss something on Flow 6 after on_confirm. After on_confirm,
on_status_pending
(order state = "Accepted") with the initial order - correct?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"
on_update_part_cancel
, should the seller again accept the updated order to send another on_status_pending
(with order state again as "Accepted")?@pareenjain, also, make sure the fees and charges in quote/breakup are feasible and not placeholder values
Changes merged in this PR.
/on_search
/on_search (inc)
/on_status
@pareenjain, please resubmit logs for Flow 3 and answer the above mentioned queries
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.
@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.
/on_status
@pareenjain, Please resolve the above issue and complete the pending submissions on the NP Portal for QA.
/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), ANDfulfillments[0].start.time.range.end
and fulfillments[0].end.time.range.end
(16th Aug to 19th Aug).Isn't this correct?
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 inbpp/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 accessibleon_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
: Theerror.message
provided in theon_select_out_of_stock
should be in the form of an array with propererror_code
anditem_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_idFlow 5
on_cancel
rtoFFObj/end/time
: Fulfillment typerto end/time
should not be present in/on_cancel
whenstate/desc/code
isRTO-Initiated
.inititated_by
: This should be bpp_idFlow 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_cancelon_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
: Missingpayment/@ondc/org/settlement_details
compared toupdate_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 inon_update_approval
.returnFF/start/time/range/start
: Start/time/range/start time of return fulfillment should be greater than context/timestamp ofon_update_approval
.on_update_picked
status
: Why the payment status is'NOT-PAID'
.message/order.payment/@ondc/org/settlement_details/0
: Missingpayment/@ondc/org/settlement_details
compared toupdate_settlement_part_cancel
Return.start.location.id
: Return fulfillment start location ID is not required inon_update_picked
.invldQuoteTrailPrices
: Quote trail price and item quote price sum foron_update
should be equal to the price as inon_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
: Missingpayment/@ondc/org/settlement_details
compared toupdate_settlement_part_cancel
Return.start.location.id
: Return fulfillment start location ID is not required inon_update_delivered
.invldQuoteTrailPrices
: Quote trail price and item quote price sum foron_update
should be equal to the price as inon_confirm
. The fulfillment_id 6656f2cef274d6d7d7b293de has different price in quote_trail and quote. Why ?@vanshraghav