search

ONDC-Official / v1.2.0-logs

Retail and Logistics Logs for 1.2.0
9 stars 248 forks source link

ZRPL (Seller App)- Compliance check #211

Closed sahil-ondc closed 3 months ago

sahil-ondc commented 9 months ago

search_full_catalog_refresh

on_search_full_catalog_refresh

on_search_inc_refresh

on_select

init

on_init

confirm

on_confirm

on_status

@SudarshanSirsi

sahil-ondc commented 9 months ago

on_search_inc_refresh

on_init

on_confirm

sahil-ondc commented 8 months ago

Flow 1

on_search_full_catalog_refresh

Flow 2

on_confirm

Flow 3

on_select

@SudarshanSirsi

sahil-ondc commented 8 months ago

Flow 1

on_search_full_catalog_refresh

on_search_inc_catalog_refresh

Flow 2

on_select

on_status

Flow 3

on_select

Flow 4

on_cancel

@SudarshanSirsi

SudarshanSirsi commented 8 months ago

Hi @sahil-ondc Flow 1: on_search_full_catalog_refresh:

  1. remove formatting from /message/catalog/bpp/providers/items/descriptor -> Can you please tell more about this, what do you mean by remove formatting?
  2. /message/catalog/bpp/providers/items/time/timestamp cannot be greater than context/timestamp --> all the timestamps in
    /message/catalog/bpp/providers/items/time/timestamp are lesser then the context.timestamp only, can you please tell me which one you are poiniting to?

Flow 2: on_select

  1. available and maximum count should not change; the logic remains the same as in /on_search catalog --> So how do buyer_app get to know the actual stock of items present in seller app inventory
  2. /message/order/fulfillments/start/time/timestamp cannot match its range/end --> can you please explain more about this one?as I understood the by API contract is that /message/order/fulfillments/start/time/timestamp refers to the expected shipping timestamps and /message/order/fulfillments/end/time/timestamp refers to the expected delivery timestamp, can you please elaborate on what am I missing here and what needs to be done?

Flow 4: on_cancel :

  1. It is in compliance with the api contract as I checked, can you tell what exactly you are looking or what I have missed here?

    @sahil-ondc

sahil-ondc commented 8 months ago

on_search_full_catalog_refresh

  1. Just remove the extra spaces in between the text and /n as well
  2. Path is given for the timestamp which is greater then context/timestamp

on_select

  1. for item if you have given available and maximum 99, 99 then it should be same in other calls as well, and vice versa

on_status

  1. provided timestamp should be in the range as provided. either in start or end

    on_cancel

  2. message/order/tags/quote_trail is missing

@SudarshanSirsi

SudarshanSirsi commented 8 months ago

Hi @sahil-ondc on_search_full_catalog_refresh:

  1. currently the context.timestamp=2023-12-25T06:16:39.239Z and all the other message/catalog/bpp/providers/items/time/timestamp are lesser then the above context.timestamp can you please verify it once again?
sahil-ondc commented 8 months ago

Flow 2

on_init

SudarshanSirsi commented 8 months ago

Hi @sahil-ondc for the next log resubmission do we need to submit for the flow 1 as well? since there is no changes in flow 1 can we skip that for next submission and only submit for other flows?

sandeepshahi commented 8 months ago

Yes, pls fix all the issues as mentioned in the feedback above.

@SudarshanSirsi

sandeepshahi commented 8 months ago

Flow 1

/on_search

Flow 2

/on_confirm

/on_status

Flow 3

/on_select (OOS)

Flow 4

/cancel

Flow 5

Flow 6

@SudarshanSirsi

SudarshanSirsi commented 8 months ago

Hi @bluecypher Flow 1: on_search

  1. variants are not supported at this time,

Flow 5:

  1. we support only Accepted, In-progress, Completed. So once the order is picked up we try to deliver, but buyer was not available, hence attempted another time, so picked up 2 times. So If this implementation is not good can you tell us how we should proceed for this flow. can we do Order-picked-up (one time) and then seller cancels the product, is this enough?
  2. We have off network logistic service, and we are an ISN, Is this mandatory to submit RTO on_cancel flow?
  3. In our whole business model, we never support Return and refund and buyer cancel also. Suppose if we develop also, it will be of no use for us except for log verification. So is this really necessary for us?
Jagannath-wits commented 5 months ago

Flow 1

Full Catalog Refresh Errors

Incremental Refresh Errors

Ensure all mandatory fields are filled out correctly. Refer to the documentation for guidance.

Flow 2

on_select

on_init

confirm

on_confirm

Flow 4

on_cancel

Flow 5

on_cancel

Flow 6-a

on_update

Flow 6-b

Please provide reverse qc as well as yours is RET14 Domain

Flow 6-c

on_update_interim

on_update_liquidated

@SudarshanSirsi

SudarshanSirsi commented 5 months ago

Hi @Jagannath-wits expecting clarification for the following ASAP

Flow 1, Full catalog refresh

  1. In the api contract for electronics there is no mention of bpp/fulfillments in catalog, and also it is said to be deprecated previously, and marked as to be deprecated for other categories as well
  2. Items 0 through 15 mandatory tag fields are incorrect and should be exactly: Storage unit Storage Type Screen Size OS Type OS Version

here what I see is that only storage type is missing , but I dont understood what should be done with other fields you mentioned. We have added those fields according to the api documents for 1.2 only

Flow 6: on_update What about the reverse qc? because are registered as an ISN seller app with off network logistic we do not support returns and cancel in any time in our business in feature. In case of issue also, we provide replacement for the same product but not return. Since replacement flow is not there we took the liquidation flow, that too only for log validation purpose. So I dont understand where reverse qc part will come for liquidation and what is the necessity of the return considering above

Jagannath-wits commented 5 months ago

Hi @Jagannath-wits expecting clarification for the following ASAP

Flow 1, Full catalog refresh

  1. In the api contract for electronics there is no mention of bpp/fulfillments in catalog, and also it is said to be deprecated previously, and marked as to be deprecated for other categories as well
  2. Items 0 through 15 mandatory tag fields are incorrect and should be exactly: Storage unit Storage Type Screen Size OS Type OS Version

here what I see is that only storage type is missing , but I dont understood what should be done with other fields you mentioned. We have added those fields according to the api documents for 1.2 only

Flow 6: on_update What about the reverse qc? because are registered as an ISN seller app with off network logistic we do not support returns and cancel in any time in our business in feature. In case of issue also, we provide replacement for the same product but not return. Since replacement flow is not there we took the liquidation flow, that too only for log validation purpose. So I dont understand where reverse qc part will come for liquidation and what is the necessity of the return considering above

Hi @SudarshanSirsi ,

sahil-ondc commented 5 months ago

Flow 1

on_search_full_catalog_refresh

on_search_inc_refresh

Flow 2

on_init

confirm

on_confirm

on_status_pending

on_status_picked

on_status_out_for_delivery

on_status_delivered

Flow 4

on_cancel

Flow 5

on_cancel

Flow 6a

on_update

update

Flow 6b

on_update_interim

flow 6c

on_update_liquidated

Please provide complete Flow 6 for next iteration , you can refer to the contract

@SudarshanSirsi

SudarshanSirsi commented 5 months ago

@Jagannath-wits

Flow 2: On-confirm

  1. schemaErr6: /message/order/tags/1/list/0/value Value for tax_number must be a valid tax number i.e alphanumeric with 15 characters ---> The tax number provided is a alphanumeric with 15 characters long, and /message/order/tags/1/list/0/value is related to Bap_terms which the tax number is sent by the buyer NP, we are the seller NP. please cross verify it. { "code": "tax_number", "value": "GSTIN1234567890" }

  2. message.order.tags[1].list: np_type of on_search is not same to np_type of on_confirm ---> Please cross verify this,

    • In the API contract you shared, message.order.tags[1].list does not contain np_type
    • and the np_type i.e 'ISN' it is same as in on_search and on_confirm message.order.tags[0].list

flow 5: on_cancel rto flow . schemaErr1: /message/order/fulfillments/1/start/location must have required property 'id' schemaErr2: /message/order/fulfillments/1/start/location must have required property 'descriptor' schemaErr3: /message/order/fulfillments/1/end must have required property 'time' schemaErr4: /message/order/fulfillments/1/end must have required property 'person' schemaErr5: /message/order/fulfillments/1/end must have required property 'contact' schemaErr6: /message/order/fulfillments/1/end/location/address must have required property 'name' schemaErr7: /message/order/fulfillments/1/end/location/address must have required property 'building' schemaErr8: /message/order/fulfillments/1/end/location/address must have required property 'country'

Please cross verify this. It is same as in api contract. In api contract also for fulfillment[1] the above things are not there. and still if you feel it is not correct please provide more clarity on how to proceed with this test case. Please reply to the above queries ASAP

Thanks

Jagannath-wits commented 5 months ago

@Jagannath-wits

Flow 2: On-confirm

  1. schemaErr6: /message/order/tags/1/list/0/value Value for tax_number must be a valid tax number i.e alphanumeric with 15 characters ---> The tax number provided is a alphanumeric with 15 characters long, and /message/order/tags/1/list/0/value is related to Bap_terms which the tax number is sent by the buyer NP, we are the seller NP. please cross verify it. { "code": "tax_number", "value": "GSTIN1234567890" }

  2. message.order.tags[1].list: np_type of on_search is not same to np_type of on_confirm ---> Please cross verify this,

    • In the API contract you shared, message.order.tags[1].list does not contain np_type
    • and the np_type i.e 'ISN' it is same as in on_search and on_confirm message.order.tags[0].list

flow 5: on_cancel rto flow . schemaErr1: /message/order/fulfillments/1/start/location must have required property 'id' schemaErr2: /message/order/fulfillments/1/start/location must have required property 'descriptor' schemaErr3: /message/order/fulfillments/1/end must have required property 'time' schemaErr4: /message/order/fulfillments/1/end must have required property 'person' schemaErr5: /message/order/fulfillments/1/end must have required property 'contact' schemaErr6: /message/order/fulfillments/1/end/location/address must have required property 'name' schemaErr7: /message/order/fulfillments/1/end/location/address must have required property 'building' schemaErr8: /message/order/fulfillments/1/end/location/address must have required property 'country'

Please cross verify this. It is same as in api contract. In api contract also for fulfillment[1] the above things are not there. and still if you feel it is not correct please provide more clarity on how to proceed with this test case. Please reply to the above queries ASAP

Thanks

@SudarshanSirsi Please proceed with the other issues, and ignore these.

SudarshanSirsi commented 4 months ago

Hi @Jagannath-wits can you please review and give feedback on the above latest merge?

NishthaMonga commented 4 months ago

Flow 1

on_search_full_catalog_refresh

Flow 2, Flow 3

on_init

on_confirm

on_status_pending, on_status_picked, on_status_out_for_delivery, on_status_delivered

on_status_packed logs missing

Flow 4

on_cancel

Flow 5

on_cancel

@SudarshanSirsi

SudarshanSirsi commented 4 months ago

Hi @NishthaMonga on_init -Pan_id is different in tax_number and provider_tax_number in message.order.tags[0].list its because according to the API Contract tax number refers to the GST number of the seller and provider_tax number refers to Pan number of the provider (page 283, footnote 717) . So according to the feedback if we should keep 'tax_number' & 'provider_tax_number' same, then which one we should use? whether GST tax number of the PAN number. because they both are not same for a company.

on_confirm -List of bpp_terms mismatched in message/order/tags/bpp_terms for on_init and on_confirm here Code 'accept_bap_terms' present in first list but not in second list.

So for this should we remove accept_bap_terms from both the list of on_init and on_confirm or should I add 'accept_bap_terms' in on_init as well? Because according to api contract it is not there in on_init but it is present in on_confirm and it is mandatory according to api contract. ? what should we do ?

Flow 5 on_cancel -/message/order/fulfillments/1/start/location must have required property 'id' -/message/order/fulfillments/1/start/location must have required property 'descriptor' -/message/order/fulfillments/1/end must have required property 'time' -/message/order/fulfillments/1/end/location/address must have required property 'name', 'building', 'country'

above issues are not correct, I have developed as in API contract, please cross verify this

Please reply to this ASAP @Jagannath-wits @sandeepshahi you can also help here for 1st and 2nd one

Thank you

Jagannath-wits commented 4 months ago

So according to the feedback if we should keep 'tax_number' & 'provider_tax_number' same, then which one we should use? whether GST tax number of the PAN number. because they both are not same for a company.

on_cancel -/message/order/fulfillments/1/start/location must have required property 'id' -/message/order/fulfillments/1/start/location must have required property 'descriptor' -/message/order/fulfillments/1/end must have required property 'time' -/message/order/fulfillments/1/end/location/address must have required property 'name', 'building', 'country'

@SudarshanSirsi

SudarshanSirsi commented 4 months ago

Got it now @Jagannath-wits , this clarified many things. Thank you for ur feedback

sahil-ondc commented 4 months ago

Flow 1

on_search (full catalog)

Flow 2

on_status

Flow 3

on_select (out-of-stock)

Flow 5

on_cancel (rto)

on_status (rto-delivered, rto-disposed)

Flow 6

on_status (after cancellation)

on_update (return)

Note

on_search (full-catalog)

@SudarshanSirsi

SudarshanSirsi commented 4 months ago

Hi @sahil-ondc FLOW 1- On_search: -Variants should be provided We dont support varients. We only have simple products, thats the reason we are going without varients.

Flow 2 on_status: -routing and tracking information should be provided -may be provided, on or before fulfillment state of "Agent-assigned", if tracking = "true"; if tracking="true" & this is not provided, default routing.type will be "P2P";

FLOW 5 - on_cancel(rto) -in case of zero delivery it should not be provided in quote_trail Is this related to only to this flow or in every other flow, and all the othe API's as because in on_select, on_init, on_confirm, on_status, on_update in every api, delivery charge is 0, aprat from this which other locations we need to send like this?

FLOW 6 - on_update -return type fulfillment should have pickup and delivery ranges it is not there in api contract, should we go with this?

Please update these in API contract as well. Because what I observed is many issues you mention are not specified in API contract, we will not be able to get to know until we submit the logs. So can you guys please include these in api contract as well, this will help the other participants as well.

Please reply to this ASAP. Thank you

SudarshanSirsi commented 4 months ago

Hi @BLR-0118 @sandeepshahi help needed here,

We have been submitting logs from the past 5 months. I understand that we had the issues, but why don't give all the errors that should be fixed at the same time? it is taking too many iterations, every guy who reviews gives some issues now, and the other issue which already existed when we submitted the first time only will be given after months of time, that too after many iteration, which could be given first time only, we might have fixed that earlier. for example take these issue given yesterday

The above issues are there from the Dec 5 2023 that is when the first time the feedback is given, those issues were present from that time, but no one has raised these, and we have submitted the logs more then 10 times till now. The above are some of the example

So I will tell you what happens because of this, and this happened with us, so first you don't tell all the issues, then we submit it again fixing those issues, this happens multiple times, and in the mean time, you guys change the api contract, suddenly some fields becomes mandatory(which we not mandatory when we started), then he tells that, and we start to fix that issue, and in mean time when the logs are about to get verified you guys will add a new Flow for submitting logs, after that we start to implement that flow, and again some changes required by you, and again some field becomes mandatory, and we fix it, and in the last a new version ONDC will come, and you tell us to submit the logs for that new version and the loop continuous forever, there is no ending to it....

And also I observed many possible scenarios those come up while log submission are not specified in the API contract as well, and it will get verified in log validation utility as well, so what is happening is that, we see the API contract, we develop according to that, and we submit the log and then one guy comes and says some field should be there, but in contract it will not be there, for example look at below feedbacks we received previously

If these are not needed why don't remove these from the contract, other wise you could have specified in the contract. Otherwise, if those fields were present in contract why bring it up here as an issue? I feel this is not going in the right way

I request your input here @BLR-0118

sahil-ondc commented 4 months ago

Hi @sahil-ondc _FLOW 1- On_search:_ -Variants should be provided We dont support varients. We only have simple products, thats the reason we are going without varients.

_Flow 2 on_status:_ -routing and tracking information should be provided -may be provided, on or before fulfillment state of "Agent-assigned", if tracking = "true"; if tracking="true" & this is not provided, default routing.type will be "P2P"; - tracking attributes for fulfillment, may be provided, on or before fulfillment state of "Agent-assigned", if tracking = "true"; This is what is there in API contract. since we dont have tracking as we have off-network logistic partner, i.e we are sending tracking=false so I dont thing we need to send this. what do you think?....and if we should send please tell what we need to send

_FLOW 5 - on_cancel(rto)_ -in case of zero delivery it should not be provided in quote_trail Is this related to only to this flow or in every other flow, and all the othe API's as because in on_select, on_init, on_confirm, on_status, on_update in every api, delivery charge is 0, aprat from this which other locations we need to send like this?

_FLOW 6 - on_update_ -return type fulfillment should have pickup and delivery ranges it is not there in api contract, should we go with this?

Please update these in API contract as well. Because what I observed is many issues you mention are not specified in API contract, we will not be able to get to know until we submit the logs. So can you guys please include these in api contract as well, this will help the other participants as well.

Please reply to this ASAP. Thank you

@sandeepshahi Can you please provide clarity on these.

sandeepshahi commented 4 months ago

@SudarshanSirsi, please share the latest logs, let me check them.

Also, for the clarity of second part, there are certain features mentioned in the contract that are part of phase 2 i.e., static terms, offers, cancellation terms etc. and not yet enabled on the network. This information was already shared with all the network participants as part of roll-out plan which also included test case scenarios. However, that phase has already passed, and NPs have begun implementing phase 2 features as well. Let's get this sorted.

SudarshanSirsi commented 4 months ago

Hi @sandeepshahi before submitting the logs can you also please clear the doubts I mentioned above?

Hi @sahil-ondc _FLOW 1- On_search:_ -Variants should be provided We dont support varients. We only have simple products, thats the reason we are going without varients.

_Flow 2 on_status:_ -routing and tracking information should be provided -may be provided, on or before fulfillment state of "Agent-assigned", if tracking = "true"; if tracking="true" & this is not provided, default routing.type will be "P2P"; - tracking attributes for fulfillment, may be provided, on or before fulfillment state of "Agent-assigned", if tracking = "true"; This is what is there in API contract. since we dont have tracking as we have off-network logistic partner, i.e we are sending tracking=false so I dont thing we need to send this. what do you think?....and if we should send please tell what we need to send

_FLOW 5 - on_cancel(rto)_ -in case of zero delivery it should not be provided in quote_trail Is this related to only to this flow or in every other flow, and all the othe API's as because in on_select, on_init, on_confirm, on_status, on_update in every api, delivery charge is 0, aprat from this which other locations we need to send like this?

_FLOW 6 - on_update_ -return type fulfillment should have pickup and delivery ranges delivery range is not there in api contract, should we go with this?

Please update these in API contract as well. Because what I observed is many issues you mention are not specified in API contract, we will not be able to get to know until we submit the logs. So can you guys please include these in api contract as well, this will help the other participants as well.

Please reply to this ASAP. Thank you

sandeepshahi commented 4 months ago

Hi @sahil-ondc _FLOW 1- On_search:_ -Variants should be provided We dont support varients. We only have simple products, thats the reason we are going without varients.

_Flow 2 on_status:_ -routing and tracking information should be provided -may be provided, on or before fulfillment state of "Agent-assigned", if tracking = "true"; if tracking="true" & this is not provided, default routing.type will be "P2P"; - tracking attributes for fulfillment, may be provided, on or before fulfillment state of "Agent-assigned", if tracking = "true"; This is what is there in API contract. since we dont have tracking as we have off-network logistic partner, i.e we are sending tracking=false so I dont thing we need to send this. what do you think?....and if we should send please tell what we need to send

_FLOW 5 - on_cancel(rto)_ -in case of zero delivery it should not be provided in quote_trail Is this related to only to this flow or in every other flow, and all the othe API's as because in on_select, on_init, on_confirm, on_status, on_update in every api, delivery charge is 0, aprat from this which other locations we need to send like this?

_FLOW 6 - on_update_ -return type fulfillment should have pickup and delivery ranges it is not there in api contract, should we go with this?

Please update these in API contract as well. Because what I observed is many issues you mention are not specified in API contract, we will not be able to get to know until we submit the logs. So can you guys please include these in api contract as well, this will help the other participants as well.

@SudarshanSirsi

SudarshanSirsi commented 4 months ago

Hi @sahil-ondc _FLOW 1- On_search:_ -Variants should be provided We dont support varients. We only have simple products, thats the reason we are going without varients.

  • All the features are mandatory; Independent SKUs are fine, but handling of variants must also be supported.

_Flow 2 on_status:_ -routing and tracking information should be provided -may be provided, on or before fulfillment state of "Agent-assigned", if tracking = "true"; if tracking="true" & this is not provided, default routing.type will be "P2P"; - tracking attributes for fulfillment, may be provided, on or before fulfillment state of "Agent-assigned", if tracking = "true"; This is what is there in API contract. since we dont have tracking as we have off-network logistic partner, i.e we are sending tracking=false so I dont thing we need to send this. what do you think?....and if we should send please tell what we need to send

  • if tracking is false, then tracking info need not be provided but routing must be present, since electronics products are mostly routed via Hub

_FLOW 5 - on_cancel(rto)_ -in case of zero delivery it should not be provided in quote_trail Is this related to only to this flow or in every other flow, and all the othe API's as because in on_select, on_init, on_confirm, on_status, on_update in every api, delivery charge is 0, aprat from this which other locations we need to send like this?

  • quote_trail applies only when there is a price adjustment in the quote/breakup and the updated information is provided in the newly created logical fulfillment (applicable for on_cancel, on_status, or on_update). Some of the APIs mentioned in the query are not applicable.

_FLOW 6 - on_update_ -return type fulfillment should have pickup and delivery ranges it is not there in api contract, should we go with this?

  • must be provided for reverseqc; as mentioned in the contract as well; pls go through the contract

  • In API Cntract for return approved scenario only there is return pickup time range is there which is fulfillment.start.time.range , and I am not able to find the return deliver time ranges(fulfillment.end.time.range) in any of reverse qc flow. So shall we submit it like that as in contract or should we include delivery time range as well with next log

@sandeepshahi

SudarshanSirsi commented 4 months ago

@sandeepshahi

  • can you specify which observation is not present in the API contract? Also, please review the issue boards of other NPs to check the common issues being reported. These issue boards are open source and publicly available for a reason.

  • rto-delivered or rto-disposed fulfillment state should be provided, :- No where it is mentioned that we have to submit the logs for this, not in testcase scenario document, not in contract, and while verifying with log utility tool also, it did not asked these logs, for FYI I have seen the logs of some of the network participants who's logs are verified , they did not submitted logs for this, but their logs are verified already. That's why we did not submitted these logs,

on_status

on_update (return)

also I will tell you another issue below are 2 images of api contract for on_search for electronics, you can see the item.descriptor.code in both screenshot and foot note, you can see in first it was optional(footnote 496) that was taken around mid April, so before that is was optional, and suddenly it become mandatory for electronics which you can see in second image(footnote 497) that was taken in first week of may. so in the roll out plan you provided previously, these small things are not updated, one can not read a 500 page document line by line every time we submit the logs, Screenshot (216)_apr10

Screenshot (215)may5

sandeepshahi commented 4 months ago

Flow 1

/on_search

/on_search (inc)

Flow 2

/on_select

/on_confirm

/on_status

Flow 3,4

Flow 5

/on_cancel (rto)

Flow 6

/on_update (part cancel)

/on_status (picked)

/on_update (return approved)

@SudarshanSirsi

SudarshanSirsi commented 4 months ago

@sandeepshahi /on_status - No agent assigned is not supported. Since we are going with off network logistics.

SudarshanSirsi commented 3 months ago

@sandeepshahi any updates on latest merge?

sandeepshahi commented 3 months ago

Flow 1

Clarifications:

/on_search

/on_search (inc)

Flow 2

/on_status

Flow 5

/status (rto delivered)

Flow 6

/on_update (return picked)

@SudarshanSirsi

SudarshanSirsi commented 3 months ago

Flow 1

Clarifications:

  • Is ZRPL an ISN? Couldn't find any related entry on NP portal
  • Yes we are an ISN Seller app, we will update the info in the portal

/on_search

  • GTIN values seem to be placeholder values
  • GTIN Numbers are the actual GTIN numbers which are associated with the product. You can verify them in GS1 website
  • pls share the screenshot of "variants" being displayed on any buyer app and their handling through your seller app
  • avoid mentioning discounts or offers that cannot be applied, such as 'Use DISCOUNT2UPI to get an additional 2% off when paying by UPI,' since the prepaid payment is currently managed by BAP and this offer isn't available.

/on_search (inc)

  • Since buyer NPs use timestamp at provider / location / item level to handle the race condition; the timestamps should be updated accordingly
  • In on_search in for item level changes are there. there is only one timestamp as by the api contract. that is bpp/providers/item/time/timestamp which should be updated only when the item is enabled or disabled(this is the feedback I got above). So and apart from this and context.tiemstamp I am not able to find any other timestamp, can you please elaborate this issue?

Flow 2

/on_status

  • if the order is automatically accepted in the /on_confirm phase, there is no need to accept the order again through unsolicited /on_status
    1. So If I understood it correctly, do you mean to say, we don't need to send /on_status with orderstatus as 'Accepted' and fulfillment status as (Pending) ?
    2. But I am thinking it like, the logs should be submitted with on_status pending this is what instructed to us and the utility tool also asks for it, with on_status (pending). So do we not need to submit /on_status with accepted and pending? or do we need to send the confirm as 'created' and send the first status as 'accepted'?
      Too much confusion here. Need more clarification
  • Why is P2H2P being performed for hyperlocal delivery?

Flow 5

/status (rto delivered)

  • order/updated_at timestamp can't be future dated; must be <= context/timestamp

@sandeepshahi Need clarification regarding these ASAP. Thank you

SudarshanSirsi commented 3 months ago

Hi @sandeepshahi needed your inputs

SudarshanSirsi commented 3 months ago

Any updates of latest merge? @sandeepshahi

BLR-0118 commented 3 months ago

Flow 1

  1. full_catalog_on_search:
    • special_feature needs to be in the list of enum here;
    • colour_name should be added;

Flow 2

  1. /on_select:

    • quote doesn't have tax line item?

  2. /on_confirm:

    • curious how you can assign pickup & delivery slots when order isn't yet accepted?
BLR-0118 commented 3 months ago

@SudarshanSirsi - pls have the above issues fixed & make an update here; clearing logs for v1.2.0 (RET14), subject to above being fixed;

SudarshanSirsi commented 3 months ago

@BLR-0118

Flow 1

  1. full_catalog_on_search:
  • special_feature needs to be in the list of enum here; This is fixed.
  • colour_name should be added;

I Have a doubt regarding this, Since in the api contract, it says regarding colour_name as this -> optional - required for colours not in standard "colour hex to name" mapping libraries; (P. No - 156, footnote 503). So we did not included this. But now I have added this as well.

Flow 2

  1. /on_select:
  • quote doesn't have tax line item?

Is this mandatory? because according to API contract, we should not include tax line item, if tax value is '0' (P.No 199, footnote 570 -> tax on fulfillment level charges, to be included only if not 0). So we did not included this one. So do we need to add this as well even if the tax value is 0?

  1. /on_confirm:
  • curious how you can assign pickup & delivery slots when order isn't yet accepted? Have doubt here. need some clarification. This happened because of lack of understanding. In API contract This was not specified correctly, so I referred the logs of some other NP's who's logs are already verified and are live on network, all of those were using pickup and delivery slots in their /on_confirm call. Also for us, after getting the confirm, and once the order is created at our end sucessfully, then only we send this on_confirm response followed by /on_status with accepted. So we were able to add the slots in on_confirm only.
BLR-0118 commented 3 months ago

Flow 2

  1. /on_select: in electronics, there should be a non-zero tax, better to make it explicit;
  2. pickup & delivery slots can be assigned only after order is accepted by store;
SudarshanSirsi commented 2 months ago

Hi @BLR-0118 We have implemented above things and we have fixed those issues.

Thank you.