Growthfalcons - compliance check

[BLR-0118]

Flow 1 (retail)

1. /on_search:

• bpp/providers.time.timestamp should match Context.timestamp;

2. /on_init:

• payment should only include what's in the contract i.e. finder fee type & percent, settlement details (payment.params is supposed to be filled by the buyer app as they're collecting payment);
• beneficiary_name in settlement_details is required;

3. /on_confirm:

• order.updated_at should be updated to Context.timestamp since default fulfillment state added;

4. /on_status_accepted:

• this seems to be the log for logistics, not retail;

5. /on_status_order_pickup:

• pickup time (fulfillment.start.time.timestamp) is mandatory;
• fulfillment.start.contact.phone should be 10 digits;
• order.updated_at should be updated to Context.timestamp (applies to other /on_status logs as well);

6. /on_status_delivered:

• pickup time (above) and delivery time (fulfillment.end.time.timestamp) are mandatory;
• other issues as in 5 above;

7. /on_update_liquidated:

• should have same message_id as /update;
• why is item.fulfillment_id changed (there's no reverse qc with liquidated state);

Flow 2

1. /on_select_1:

• fulfillment.state.code is invalid;

[BLR-0118]

@SandeepGF

[SandeepGF]

@BLR-0118 Flow-1:
point-5 and point-6: This is on_network flow what we received from logistic we have forwarded that to retail.

point-7.1: For the /update call, we send /on_update with "Return Initiated" with the same message_id. Once we validate the claim, we send unsolicited /on_update , with "Return Rejected" or "Liquidate", for the unsolicited call do we need to use the same message_id.

[BLR-0118]

@SandeepGF - flow 1 (5 & 6) - needs to comply with the contract; pt 7.1 - yes for now as the API has no way to track individual return requests, hence we're using the message_id to track it

[BLR-0118]

Flow 1

1. /on_init:

• buyer_app_finder_fee_type should be "percent" (lower "p");

2. /on_update_liquidated:

• use the same message_id as /update (as in this version, this is the only way to track individual return request);

[BLR-0118]

@SandeepGF

[BLR-0118]

Flow 1

1. /on_status_packed, /on_status_order_pickup, /on_status_out_for_delivery, /on_status_delivered have the same transaction_id & message_id which is incorrect. Every unsolicited call should have unique message_id (only exception is /on_update where we're asking participants to temporarily reuse the same message_id as there is no other way to track individual returns);
2. /on_status_out_for_delivery uses the same timestamp for pickup (fulfillment.start.time.timestamp) and delivery (fulfillment.end.time.timestamp). However, the fulfillment state is "Out-for-delivery" but hasn't been delivered yet. Why is the delivery time being updated?

[BLR-0118]

@SandeepGF

[SandeepGF]

@BLR-0118 since we use on-network logistics, we are forwarding the json we received (in this case from Dunzo). If we receive extra keys from Dunzo or any other logistic provider, should we ignore the extra keys or send an error to the logistic provider?

[SandeepGF]

@BLR-0118
For 1 - Waiting for fix from Dunzo , they have changed few things at their system which is causing schema validations.
For 2 - We are returning as obtained from on-network logistics. Blocked by both logistic providers, fix at logistic provider should solve the issue.
Please refer the jiras below:
https://ondc-issue-logging-cohort1.atlassian.net/browse/PREPROD-191
https://ondc-issue-logging-cohort1.atlassian.net/browse/PREPROD-192

[BLR-0118]

Flow 1

1. /on_select:

• "@ondc/org/item_quantity".count should be integer (shows correctly in /on_init);

2. /on_confirm:

• same issue as /on_select;

3. /on_status_out_for_delivery:

• shows delivery time when order isn't yet delivered;
  3 is because of PREPROD-192 linked above. Can you pls work with Dunzo to close this?

[BLR-0118]

@SandeepGF

[BLR-0118]

logs cleared for v1.1.0