eSamudaay - Logistics BAP - compliance check
Closed this issue · 18 comments
Happy-Flow
/search
- fullfillment/end/location/address/area_code must be a valid area code (instead of gps)
- How is buyer's and seller's location same? (same building?)
- Avoid copying test data from the contract
- value of payload should be included within "@ondc/org/payload_details" object
/init
- share the /search request for this txn
- "building" attribute should be used in start and end /location/address (instead of the deprecated "door")
- /fulfillments/start/person object is not required for seller's location
- payment settlement details should not be sent in case of Prepaid orders (since seller-app will be the settlement counterparty, it will be received in /on_init)
/confirm
- billing timestamps (created_at and updated_at) should remain the same as in /init
RTS support through /update should be present in the logs
Cancel-Flow
- similar issues as above flow
- "004" is a deprecated cancellation_reason_id (use "006" instead)
@bluecypher
/search fixed all the mentioned issues in both flows
/init fixed fixed all the mentioned issues in both flows
/confirm fixed all the mentioned issues in both flows
/update submitted logs for this in happy flow
/cancel fixed all the mentioned issues in cancel flow
Happy Flow
/search
- Either one of fixed timings (range) or split timings (both frequency and times) should be provided in /provider/time
- Incorrect mapping of gps and address of store location. (reverse geocding shows different pincode)
/init
- billing.created_at should match context.timestamp
- billing.updated_at should match context.timestamp
/confirm
- /message/order/@ondc/org/linked_order/items/quantity/count must be integer
/update
- @ondc/org/order_ready_to_ship should be 'yes' (lowercase)
- order.created_at cannot change in /update
Cancel Flow
- similar issues as above Flow
@abhinavv245 fixed all the issues..please have a look
Happy Flow
- Avoid replicating test data from the contract
/search
- holidays cannot be past dated in /schedule
/init
- fulfillments/id should correspond to the one returned in /on_search
- /message/order/billing must have required property 'tax_number'
- /message/order/fulfillments/start/location/address must have required property 'building'
- /message/order/fulfillments/end/location/address must have required property 'building'
- /message/order/billing/address must have required property 'building'
- door is an optional/to be depracted attribute in /billing/address
- end/location/gps should not change (precision should be minimum 6 decimal places)
/confirm
- /message/order/fulfillments/end must have required property 'person'
- @ondc/org/order_ready_to_ship should be 'no' (lowercase)
/update
- start attribute required for ready to ship fulfillment in update api
Cancel Flow
- similar issues as above
@abhinavv245 raised a PR with all fixes
Both Flows
/confirm
- payment object is missing in /order
Please remove all previous versions of logs and resubmit only the revised version
If the order is prepaid, the logistics buyer should not include "@ondc/org/settlement_details" in the payment. When making the confirm call, if we receive "@ondc/org/settlement_details": null during on_init, what action should be taken?
@abhinavv245
@Namratha102000 you can send the type of payment and who is collecting it. '@ondc/org/settlement_details' is an optional attribute and can be omitted in case it is null or empty.
@abhinavv245 raised a PR with fix
Happy Flow
/confirm
- order/created_at and order/updated_at cannot be future dated w.r.t context/timestamp
Cancel Flow
/cancel
- LSP needs to cancel the order through unsolicited on_cancel. /cancel is not required
@abhinavv245 fixed in PR
/update
- pickup confirmation code is mandatory for P2P
- Auto-RTS should be supported in /confirm
- unsolicited calls for /on_status should also be supported
Cancel-Flow
- How is this cancel flow processed? LSP has cancelled the order with reason code 012, without picking the package from store (no pickup timestamp)
@bluecypher @abhinavv245
Happy flow -
- Added pickup confirmation code
- Auto-RTS should be supported in /confirm - It is supported
- unsolicited calls for /on_status should also be supported it is supported and added the logs for these calls
Cancel - flow
- In the new logs order is moved to picked status ....and then cancelled
- RTO charges are not provided in /on_search. Should be handled accordingly.
/on_status
- message_id mismatch with /status (seems like unsolicited call)
- Order has been delivered, but the delivery timestamp is still missing; Pickup timestamp does not match with timestamp provided in unsolicited call for "Order-picked-up" state.
- This call should have been rejected with a NACK
Cancel-Flow
- After the RTO initiation, are the RTO charges correctly handled?
@bluecypher
- RTO charges are 1.2 update..right?
- The on_status issue was a fault by the Loadshare team, which they have now fixed. Therefore, I am raising a PR again, but this time, it is only for the happy flow.
- RTO charges are part of v1.1.0 as well
- Why is logistics procurement limited to P2P deliveries and not for P2H2P?
@bluecypher @abhinavv245
As of now, we have only enabled P2P (Point-to-Point) logistics to ensure efficient and direct communication between buyers and sellers.
@BLR-0118, eSamudaay Logistics BAP logs (v1.1.0) seem fine, Please proceed with your review.