Addble - compliance check

[sandeepshahi]

Flow 1

/on_search

• context/timestamp difference between /on_search and /search should be smaller than 5 sec
• @ondc/org/contact_details_consumer_care should be in the format "name,email,contactno" in /bpp/providers/items

/on_init

• /payment/@ondc/org/buyer_app_finder_fee_type must be percent (p should be in lower case)
• item.quantity.available and item.quantity.maximum not required in quote.breakup

/on_status

• context.timestamp in /on_confirm and /on_status can't be same
• fulfillments/start/time/timestamp cannot be future dated and should match the context.timestamp (fulfillment state as "Order-picked-up")
• fulfillments/end/time/timestamp cannot be future dated and should match the context.timestamp (fulfillment state as "Order-delivered")
• order.updated_at timestamp should be updated as per the context.timestamp for every change in fulfillment state

/on_update

• order must have required property 'created_at'
• order must have required property 'updated_at'
• liquidated item should be present in quote.breakup with item count = 0
• /quote must have required property 'ttl'

Flow 2

/on_select

• why is transaction_id changing for different /on_select?

Flow 3

/on_status

• pickup (fulfillments/start/time/timestamp) and delivery (fulfillments/end/time/timestamp) time cannot be same (fulfillment state = "Order-delivered")
• pickup time (fulfillments/start/time/timstamp) is mandatory for fulfillment state "Order-picked-up"

/on_update

• context.timestamp for /update and /on_update can't be same

/on_update (return rejected)

• message_id should be same for unsolicited /on_update calls and /update (temporarily)

Flow 4

/on_status

• context.timestamp cannot be equal to /on_confirm context.timestamp
• Similar issues as Flow 3

@yaikhomba

[yaikhomba]

@bluecypher - for Flow 2, Plotch (Indiastack buyer app) is sending different transaction_id with every SELECT call.

[yaikhomba]

@BLR-0118 & @bluecypher - there is no "ttl" in quote in on_update as per the API specification. Could you please confirm if "ttl" needs to be added in quote in on_update?

[yaikhomba]

@BLR-0118, @bluecypher - why do we need to keep message_id for an unsolicited /on_update same with a previous /update call? These introduces chances of mismatch.
Can we just pick the message_id of any previous /update?

[sandeepshahi]

@yaikhomba
quote/ttl need not be removed from the APIs, it should remain the same as in /confirm
message id for the unsolicited /on_update should be same as in /update to track that particular part return/part cancel request

[sandeepshahi]

Flow 1

/on_status

• Order pickup time (/fulfillments/start/time/timestamp) should remain same as in Order-picked-up fulfillment state
• Order pickup time (/fulfillments/start/time/timestamp) and order delivery time (/fulfillments/end/time/timestamp) can't be same when order is delivered (fulfillment state is Order-delivered)

/on_update

• /on_update must return the same information trail as in /on_status (order created_at, updated_at, payment etc.)

Flow 2

/on_select

• invalid payload /select1 (different txn)
• time_to_ship (O2S) in /on_search can't be equal to @ondc/org/TAT (O2D) in /on_select

Flow 3, 4

• similar issues as Flow 1

@yaikhomba

[yaikhomba]

@BLR-0118 @bluecypher
Flow 1
/on_update - payload is as per the API spec.
Flow 2
Could you elaborate this - "invalid payload /select1 (different txn)". I see that transactions ids are same across.

[sandeepshahi]

• As per the API spec, it is mentioned that /on_update must return the same information as /on_status (all the required attributes must be present).
• check f2_select_1.json in Flow 2. (which is an invalid payload)

@yaikhomba

[yaikhomba]

@bluecypher - for the /on_update was following the payload listed in the spec. Will include the others attributes.
The json payload f2_select_1.json you are referring for select was from the previous submission and not part of the latest submission.