Draft 2.x Available for review

[92shreyansh]

Hi all, We have made draft 2.x version for multiple use cases is available for community to comment and we have a weekly community call for the same feel free to get yourself added for these by droping a email to balaje.r@ondc.org .

[kislayverma]

I wanted to note down the discussion we had on the previous community call (thanks for answering my many questions patiently) and thought I'll put down my thoughts just to be sure that I understand things correctly. Please correct wherever I'm not in any way.

On-Demand-vs-Scheduled

• IMO, There is no fundamental difference between on-demand and scheduled rides beyond the actual fulfilment of the request. In on-demand, inventory blocking and vehicle assignment happens back to back, and at a later point in scheduled rides. But there needn’t be any difference between the two in the discovery/booking path.
• The protocol should simply support a pickup time in the search phase with null standing in as "now" to support the on-demand use-case. Supply systems can respond with available inventory at "now" (null) time or whatever time is passed. This will help keep the protocol simple.
• The other suggestion on the call was also good. Supply side can respond with inventory available within +- x mins of the requested time and call this out clearly. Buyer apps can even provide permissible limits of the value of "x".

Semantics of the search API

• IIUC, this could be a bigger problem.
• On the call, it sounded like the expectation from search response was to declare that "I am a vendor/individual operator who does rental/scheduled/ondemand/..... type of service and from point A to B at time T1, it will cost Rs. Y” without any real correlation with whether the vendor has inventory for the request or not.
• Correct me if I am wrong, but this will lead to poor customer exp. because people will repeatedly click on some supply, and when the actual inventory check happens on "select", they will see "booked out"/"no inventory". Now they have to go back and select again. This is the equivalent of amazon showing all products whether or not they are in stock.
• I propose that a requirement (within a reasonable limit of edge case last-vehicle booked situations) of showing inventory in search API should be that the supplier actually has the inventory. Inventory not being available between search and select should be tracked as a quality metric. Otherwise, there is no incentive for me as a supplier to NOT return results on search.

On a side note, notice the "T1" in the request in the first point. For suppliers who price their service by time (e.g. surge in Uber), even price calculation requires pickup time, lending credence to the idea that you can't properly invoke supply side without it and hence making the behaviour of on demand and scheduled rides essentially the same.

[manickalai]

Hi Team

Thank you for the details on "Use Case Specification" for ONDC integration,

Swagger and Schema do not have the mandatory field information, and quite challenging to expand all the details in Schema to review to understand the details, Please assist

[kislayverma]

@92shreyansh Is there any ay to specific different types of Cars (e.g. Sedan, SUV etc.) in search or in on_search? I can't see any vehicle category like that in the spec

[olttwa]

@92shreyansh @Rishabh-ondc

Please rectify a spelling error in Mobility-Specification v2.0.1 build.yaml: cargo_volumne should be spelt cargo_volume.

If this is not the right thread, and I should post in a different thread, please point me to it 🙏 .