Proxtera | B2B | BAP | Compliance Check

[tanya-ondc]

/search:

• fulfillments.stops.location.gps is showing bangalore location. The buyer should be in Singapore for Exports?
• Reverse geo coding does not match the gps and area code mentioned.
• Please use valid data while testing. For example a valid GST number of buyer in buyer_id.

/select:

• As per the buyer flow discussed so far, init is used for RFQ. And in such a case, how Item customization and packaging customization is being sent in /select.
• If /init is used for RFQ, Buyer_terms, Delivery_terms and provider.ttl will not be sent in /select.
• Buyer_id_no is visible in /search. How it is coming as xxxxxx in /select?

/init:

• Buyer_terms is having test in customizations. Please test a valid and realtime flow.
• Billing location shows USA address, is this expected?
• /search having delivery location of Bangalore and /init having delivery location of USA? How is serviceability checked here?
• /init/0/message/order/billing must NOT have additional properties (created_at)
• /init/0/message/order/billing must NOT have additional properties (updated_at)

/confirm:

• /confirm/0/message/order/billing must NOT have additional properties (created_at)
• /confirm/0/message/order/billing must NOT have additional properties (updated_at)

/update:

• If payments.collected_by is BPP and payments.type is POST-FULFILLMENT, how /update can update payment status as PAID.
• What is the difference between two update calls, one with message_id = 8f578fc8-4045-42c9-a562-c1add831d8a0 and other with message_id = 0caea8f4-8b60-4744-bfc0-d60cd75e60cf.

[tanya-ondc]

@ashok-ai

[ashok-ai]

For test purposes, we have used the Bangalore location but this has been changed to the Singapore location now.

@tanya-ondc All the Mentioned issue has been fixed and raised a PR. Kindly check it once.

https://github.com/ONDC-Official/verification-logs/pull/1021

[tanya-ondc]

/search:

• /search intent has payment object as well, where buyer can search based on payment option they want to avail. Please use payment object in /search.

/init:

• customer.person.creds does not have a valid link for creds. Please use valid links.

/on_init:

• items.quantity.count is not a valid schema. Buyer app should send NACK in case of schema failure.
• /on_init/0/message/order/quote/breakup/0/item must have required property 'quantity'

/confirm:

• confirm cannot have context.ttl more than PT30S.

/update:

• /update/0/context/ttl must be equal to constant (PT30S)
• Kindly help me understand the use of this update call? What is buyer app trying to do here.

/status:

• status/0/context/ttl must be equal to constant (PT30S)

** Kindly implement schema checks at your end, while buyer app receives async responses from seller app. Buyer app can send NACK in case schema check fails.

[tanya-ondc]

@ashok-ai

[tanya-ondc]

/init

• creds.id is same as the one in examples. Is this customizable?

/status

• There is a status call post which the proforma invoice is being shared as part of /on_status. Is there a link at buyer app for buyer to be able to request for status update? Also, there is no mandate for status API call for getting the proforma invoice. Can you confirm when is /status API called?

@ashok-ai

[ashok-ai]

@tanya-ondc

/initcreds.id is same as the one in examples. Is this customizable?

Yes, this will be customizable. /status

There is a status call post which the proforma invoice is being shared as part of /on_status. Is there a link at buyer app for buyer to be able to request for status update? Also, there is no mandate for status API call for getting the proforma invoice. Can you confirm when is /status API called?

Yes, we do have a "Get transaction status" button in the application. And this is not mandatory, the button will be enabled only after the confirmation of the purchase order.

[ashok-ai]

@tanya-ondc

As discussed, we won't be sending creds detail in the payloads.

[tanya-ondc]

/select:

• items.tags is empty. Do not need to send attribute, if empty.
• fulfillments.customer.person.creds - Do not send attribute, if empty.
• fulfillments.tags - Do not send attribute, if empty.

/init:

• billing.phone is mandatory
• fulfillments.stops.contact.phone is mandatory.
• fulfillments.customer.person.creds - Do not send attribute, if empty.
• Please use correct named place of destination for different incoterms.

Flow 4

• No status or on_status calls to happen when PO is cancelled and no order is created.

RFQ rejection flow to be tested.

@ashok-ai

[tanya-ondc]

/search:

• fulfillments.stops.end - gps and area_code does not match.

[ashok-ai]

@tanya-ondc The GPS and area_code issue has been resolved.