MedPay - compliance check
Closed this issue · 18 comments
Flow 1
-
/on_search
- bpp/providers/descriptor/ images and symbol can't be empty.
- /message/catalog/bpp/providers/0/items/quantity: maximum/count and available/count must be string
- /message/catalog/bpp/providers/0/items/3/descriptor/images must NOT have fewer than 1 items
- /message/catalog/bpp/providers/0/tags/0 must be object
- context/timestamp difference between /on_search and /search should be smaller than 5 sec
- available count of item should be smaller or equal to the maximum count (/bpp/providers[0]/items/quantity)
- bpp/providers/locations gps coordinates must be specified with a minimum precision of six decimal places.
-
/on_select
- /quote/breakup/item/quantity/maximum/count must be string
- /quote/breakup/item/quantity/available/count must be string
- /quote/breakup/4 must have required property '@ondc/org/item_id'
- available count can't be greater than maximum count for item id: 1002-3810-3036-9631_384348
- available count can't be greater than maximum count for item id: 1002-3810-3036-9631_384255
- quote.price.value 3173.0 does not match with the net price breakup 3553.76 (if items are tax inclusive, then tax line item should not be present)
- "packing" line item should not be present if value is 0
-
/on_init
- must have required property 'provider_location' (instead of provider/locations)
- /items/ must have required property 'quantity'
- /quote/breakup/4 must have required property '@ondc/org/item_id'
- Quoted Price 3173 does not match with Net Breakup Price 3553.76 in /on_init
- quote/breakup/item/quantity is not required
- settlement_status is invalid in /payment/@ondc/org/settlement_details
-
/on_confirm
- /fulfillments/state/descriptor/name is invalid attribute
- /fulfillments/0/start/location must have required property 'id'
- /fulfillments/0/start/location must have required property 'descriptor'
- similar issues for quote object as mentioned above
- context/timestamp difference between /on_confirm and /confirm should be smaller than 5 sec
- order.updated_at timestamp should be updated as per the context.timestamp (since default fulfillment state is added)
-
/on_status (order_delivered)
- /documents/0/label must be equal to constant (Invoice)
- order/updated_at must match context/timestamp
-
/on_update (return flows)
- many invalid attributes in /items[1]/tags (only status should be present)
- ReverseQC fulfillment should not be created in "Return_Initiated" state (created only when return is approved)
- ReverseQC fulfillment in case of "Return_Approved" and thereafter should have fulfilment state as Pending , Order-picked-up and Order-delivered (/fulfillments/1)
- How is buyer refund settlement trail appended to /payment/@ondc/org/settlement_details (Return_Picked state ) even before refund is initiated?
- item's unit price in quote/breakup should not be removed (in return picked and delivered states)
Flow 2
- similar issues as Flow 1
- "delivery" line item should not be present when location is Non-serviceable (in on_select and thereafter)
Flow 3,5
- similar issues as Flow 1
Flow 4
- similar issues as Flow 1
/on_select
- "item quantity unavailable" domain error is invalid when quantity is available in the inventory (quantity/available/count)
@bluecypher, we have made the changes and fixes mentioned above. Please find it here: #252
Please check and confirm. Thank you!
/on_search
- /message/catalog/bpp/providers/items/descriptor/images should not have more than 3 images (buyer apps can process only 3)
- tracking is not required in bpp/fulfillments/ and bpp/providers
/on_init
- 'provider_location' must be a part of /order instead of /order/provider
/on_confirm
- /fulfillments/start/location/address is not required
/on_status (unsolicited)
- The order/updated_at timestamp is usually the same as context/timestamp in other APIs, except in this case where it equals the delivery time. How?
- all fulfillment states should be updated through unsolicited calls
/on_update
- All unsolicited calls for a particular /update request should have the same message_id
- Return_Approved - Why is return pickup timestamp provided? (ReverseQC fulfillment is still "Pending")
@bluecypher thanks for the feedback. Let us fix these also. I have few questions below:
/on_status (unsolicited)
- So in on_status the context_timestamp should match the order.updated_at value? Please correct me if i am wrong.
- Also since there is no status_call, in unsolicited_on_status call, what
message_idshould we use? - We are making all the update through unsolicited_status_calls. Is it that we will have to put it in the logs? or something else we are missing.
/on_update
- So this means all the unsolicited on_update after an update request should contain the same
message_id. Please correct me if i am wrong.
- In case of unsolicited on_cancel what message_id should be used?
Please clear these points.
/on_status (unsolicited)
- So in on_status the context_timestamp should match the order.updated_at value? Please correct me if i am wrong.
Understanding is correct
- Also since there is no status_call, in unsolicited_on_status call, what message_id should we use?
You have to generate a new message_id for every unsolicited /on_status call
- We are making all the update through unsolicited_status_calls. Is it that we will have to put it in the logs? or something else we are missing.
The fulfillment state updates through various unsolicited /on_status call should be shared for verification
/on_update
- So this means all the unsolicited on_update after an update request should contain the same message_id. Please correct me if i am wrong.
Correct understanding (This is to track that particular /update request)
- In case of unsolicited on_cancel what message_id should be used?
A new unique message_id should be generated
@bluecypher, Thank you for the clarification.
@bluecypher, one more confusion:
- on_confirm location address is not required. So i should stop sending that in further responses also or just in on_confirm?
@bluecypher, one more confusion:
* on_confirm location address is not required. So i should stop sending that in further responses also or just in on_confirm?
For all responses thereafter, please refer to API Contract for further clarification.
@bluecypher, changes done as required. Please find it here: #263
Please merge and review.
/on_search
- Is the geocoded GPS and address of store location correct? (Reverse geocoding shows different pincode)
/on_confirm
- estimated pickup and delivery time ranges are incorrectly mapped (must align with the specified time_to_ship and TAT)
/on_status (out-for-delivery)
- Pickup time is not correctly recorded. The timestamp must align with the fulfillment state of "Order-picked-up"
@bluecypher, Need help, please find the points below.
/on_search
- since this data is in uat environment. The reverse geocoding could be off.
/on_confirm
-
time_to_ship in our case is 1D and out timestamp range is on the same day, saying it will be picked up somewhere around that day only.
example:
order_confirm_timestamp: 2023-06-01T09:58:24.688Z
start_tme_range_start: 2023-06-01T15:58:24.743Z
start_time_range_end: 2023-06-01T16:28:24.743Z -
TAT in our case is 2D and out timestamp range is for the same day, saying it will be delivered next day.
example:
order_confirm_timestamp: 2023-06-01T09:58:24.688Z
start_tme_range_start: 2023-06-02T09:58:24.743Z
start_time_range_end: 2023-06-02T10:28:24.743Z
I could not understand what i am doing wrong here. If you can please explain, that will be very helpful.
/on_status (out-for-delivery)
- I could not understand this point, we do not have Order-picked-up date, It directly gets picked for Out-for-delivery and that timestamp gets updated there.
Please let me know what to do in this point.
- Ensure accurate GPS and address mapping.
- Then instead of using standard delivery, you could utilize SDD/NDD options with the relevant TAT, otherwise ensure that timestamps are mapped accordingly (1D represents 24 hours and 2D represents 48 hours).
- Use correct fulfillment state as defined in the API contract. The buyer NPs will fetch the timestamps from there.
@bluecypher, when you say timestamp are mapped accordingly, what do you mean?
2. Given that:
-
Order got confirmed at timestamp: T1
-
time_to_ship: 1Day
-
TAT: 2Day
2.1. Does it mean that the range should be between T1 - T1+24hour, in case of start
2.2. In case of end this should be in between: T1+24hour - T1+48 hourI could not get any info related to this in the doc: https://docs.google.com/document/d/1fefHfMoYIouN-QJTDJFFZm46dqHmFvwY-6ICoISJcUY/edit#
- So I will have to have the
Order-picked-upfulfilment status. So that correct timestamp for this state can be picked up.
The "start" time represents the estimated shipment time, while the "end" time indicates the expected delivery time. The "time_to_ship" provides an approximate duration for shipment, also known as O2S (Order to Shipment), and the TAT represents the overall delivery time, known as O2D (Order to Delivery).
These timestamps can be used to determine the corresponding time ranges for shipment and delivery.
/on_select
- quote/breakup/item/id is optional
/on_status (Order-picked-up)
- must have required property 'documents' (for Invoice)
/on_status (OFD/OD)
- pickup time (/start/time/timestamp) can't change (should remain same as in "Order-picked-up" state)
/on_update
- Invoice is optional
Fixed and updated. Please find the PR here: #281
@bluecypher
@BLR-0118, the MedPay Seller App logs (v1.1.0) seem fine, please proceed with your review.
@medpay-vishal-kumar, the on_select async response is taking longer than expected (>5s) in Flow 1
@bluecypher, that happened because of lambda cold start. Rest assured this will not happen in prod environment.
@BLR-0118, any update please?