Ola LSP - compliance check
Closed this issue · 8 comments
abhinavv245 commented
Delivered flow
- LSP should handle issues from buyer side appropriately
/search
- /search/0/message/intent/@ondc/org/payload_details must have required property 'category'
/on_search
- context/timestamp difference between on_search and search should be smaller than 1 sec
/init
- /init/0/context must have required property 'bpp_id'
- /init/0/message/order/provider/locations must be array (null value objects should be removed)
- /init/0/message/order/billing/address must have required property 'building'
/on_init
- delivery charge should be inclusive of tax
/confirm
- /confirm/0/context must have required property 'bpp_id'
- /confirm/0/message/order/fulfillments/0 must have required property 'tags'
- /confirm/0/message/order/billing/created_at mismatches in /billing in /init and /confirm
- /confirm/0/message/order/billing/updated_at mismatches in /billing in /init and /confirm
- /confirm/0/message/order/payment/collected_by mismatches in /payment in /on_init and /confirm (LSP should send NACK)
- /confirm/0/message/order/payment/type mismatches in /payment in /on_init and /confirm (LSP should send NACK)
- /confirm/0/message/order/@ondc/org/linked_order/items/0/category_id is an invalid category (Please refer category list)
/on_confirm
- /on_confirm/0/message/order/quote/price/value mismatches in /on_confirm and /confirm. (quote/breakup does not match to total price)
- /on_confirm/0/message/order/fulfillments/0/start and end empty objects should be removed
/update
- /update/0/context must have required property 'bpp_id'
/on_update
- order/state should be 'In-progress' for fulfillment/state 'Searching-for-agent'
- /on_update/0/message/order/fulfillments/state is not required
/on_status
- Message Id cannot be same for different sets of APIs (Out-for-delivery,Picked-up)
RTO flow
- similar issues as above
/on_cancel
- schema invalid for v1.1.0 (refer to API contract v1.1.0)
- In case of RTO, fulfillment with type 'Prepaid' needs to be 'Cancelled', and updates for fulfillment state changes
- RTO Pickup (fulfillments/start/time/timestamp) time cannot be future dated for fulfillment state - RTO-Initiated
- /on_cancel/0/message/order should not have additional properties (cancellation,provider,items,quote,billing,payment,@ondc/org/linked_order,updated_at)
- fulfillment state changes for the RTO, should be sent via on_status calls
abhinavv245 commented
Flow 1
/on_search
- /on_search/0/message/catalog/bpp~1providers/0/items/1/time/timestamp must match format "date-time" (RTO-item)
/confirm
- linked order item weight (950) not in sync with the order weight (475)
/on_confirm
- /on_confirm/0/message/order payment,@ondc/org/linked_order are not required
on_status
- /on_status/message/order/created_at mismatches in /confirm and /on_status
Flow 2
- similar issues as above2
- deferred RTS (ready_to_ship) needs to be supported through /update and /on_update calls
/on_cancel
- order needs to be cancelled via /on_cancel call first and then RTO will be initiated via /on_status calls
Please make sure null values are not provided in the complete flow
abhinavv245 commented
Flow 1
/on_init
- context/timestamp difference between on_init and init should be within 1 sec
/on_status
- Pickup timestamp (fulfillments/start/time/timestamp) cannot be provided for fulfillment state - Agent-assigned
- Pickup timestamp (fulfillments/start/time/timestamp) cannot change for fulfillment state - Order-delivered
Flow 2
/on_status
- RTO Delivery time (fulfillments/end/time/timestamp) cannot be future dated for fulfillment state - RTO-Delivered
mherle commented
These have been fixed and pushed now.
mherle commented
@abhinavv245 / @bluecypher Pls update the status of our v1.1.0 Orderflow logs
sandeepshahi commented
- Manual RTS through /update must be supported
- PCC in start/instructions need not be sent again in /on_status call
- Why are estimated pickup and delivery time ranges being revised later in /on_status call?
mherle commented
@bluecypher Sharing my comments
- Manual RTS through /update must be supported:
We're currently doing only Food and Immediate Delivery and as per the spec, for Food, rts will alway come as true at confirm (Channelier's behaviour is also same). But in code, we do have support for this, but this will kick on only when we exapand to provide other categories (as and when the business decides to do this) - PCC in start/instructions need not be sent again in /on_status call:
Sure. We'll not send this - Why are estimated pickup and delivery time ranges being revised later in /on_status call?
This was a bug in the async response payload creation and is fixed
mherle commented
- Manual RTS through /update must be supported
Changed Flow 1 to be deferred RTS - PCC in start/instructions need not be sent again in /on_status call
Corrected. Not sending PCC anymore in /on_status - Why are estimated pickup and delivery time ranges being revised later in /on_status call?
This bug is also fixed
New logs are submitted in PR 656
@bluecypher Please merge and review
cc: @Anoopsmohan
sandeepshahi commented