ToneTag - logistics BAP - compliance check

[abhinavv245]

All Flows

search

• Holiday date should not be past dated

/init

• /init/0/context/city must be equal to constant (std:040)
• billing details will be of the logistics buyer (not the end buyer)
• /init/0/message/order/billing/tax_number should be valid
• /init/0/message/order/payment/type should be same as in /search - "ON-FULFILLMENT"
• real values should be provided instead of dummy values (XXXXXXXXXXXXXXX)
• settlement details are not required in /init as they will be provided by seller NP (optional) in case payment is collected by BAP

/confirm

• /confirm/0/message/order/fulfillments/0/start/instructions must have required property 'code' (invalid schema error, NACK by LSP)
• /confirm/0/message/order/fulfillments/0/end/instructions must have required property 'code'
• /confirm/0/message/order/payment @ondc/org/collection_amount is required only for payment/type 'ON-FULFILLMENT'
• /confirm/0/message/order/payment/@ondc/org/collection_amount mismatches in /payment from /search
• quote object mismatches with the one provided in /on_init (tax breakup is missing) (should be NACK'd by LSP)
• Average Pickup Time mismatches from the one provided in /on_search (should be NACK'd by LSP)

/update

• deferred RTS (ready to ship) call is missing (should be handled in one of the flows)

/on_status

• tracking should be enabled (true) for hyperlocal (Immediate Delivery)
• All fulfillment state on_status calls should be provided (Agent-assigned,Order-picked-up,Out-for-delivery,Order-delivered,RTO-Delivered/Disposed)

/track

• /track/0/message/order_id must be equal to constant (d8faa255-7fd7-4593-8acb-e3ef91d843ea)

/on_track

• /on_track/0/message/tracking/status should be 'active' if tracking is enabled

/cancel

• context/action is incorrect
• invalid schema inside messge (order_id is missing, order, order/state are not required)

/on_cancel

• in /items rto item/time should be same as provided in /on_search
• average pickup time cannot change with the one provided in /on_search
• payment/status is not required

Note :Please run the utility before submitting the logs and attach the log_report.json along

Change location and category/id in each flow, also one of the flows should capture P2H2P Flow

[jagadeeswar577]

@abhinavv245

Our merchant's stores are located at Bengaluru and our flows (Retail and Logistic) are tested for the same location.

So the below feedback is looking not relevant in this case.

/init/0/context/city must be equal to constant (std:040)

And all the above feedbacks are looking like for logistic payloads , is that understanding correct?

Thanks

[abhinavv245]

@jagadeeswar577 the mentioned city code in context should match the city for fulfillment start location which in this case is Telangana as per the start/location/area_code: "500024 (Telangana) provided in Flow 1(Delivery). Kindly reverify all the logs.

Yes, this issue board is specifically for logistics logs.

[abhinavv245]

Flow 1

/init

• collected_by is not required in payment (refers to the collection of payment from the end buyer, for ON-ORDER payments it would be 'BAP')

/confirm

• Average Pickup Time (fulfillments/start/time/duration) mismatches from the one provided in /on_search
• message/order/id should be unique (cannot be equal to transaction_id)

/update

• fulfillments/0/tags/1 (rto_action is not required)

RTO Flow

• similar issues as above

/on_status

• All fulfillment state on_status calls should be provided (Agent-assigned,Order-picked-up,Out-for-delivery,Order-delivered,RTO-Delivered/Disposed)

Cancel Flow

• Incorrect Flow as per context/timestamps - (search,on_search,cancel,init,on_init,confirm,on_confirm,status,support,track,on_track,on_support,on_status,on_cancel)

/search

• @ondc/org/collection_amount is required only for payment/type 'ON-FULFILLMENT'

/confirm

• billing/created_at and updated_at mismatches in /billing in /init and /confirm
• payment/collected_by mismatches in /payment in /on_init and /confirm

@jagadeeswar577 All the previously identified issues should be rectified before resubmitting the logs along with log_report.json file generated from the log verification tool for each flow.

[jagadeeswar577]

As you can see in the attached screenshot, we have run the utility tool against all 3 flows and it reported zero issue.

Even the only one that we see "Message Id cannot be same for different sets of APIs" is appearing even though we are using different Message ID per API combo.

Can you let us know from where the above mentioned new issues are raised?

Is it from the same tool? If yes, why we didn't see them in our local machine??

@abhinavv245

Thanks

[abhinavv245]

Hi @jagadeeswar577 Did you use the updated version of the tool (updated on 11 Dec, 2023)

[jagadeeswar577]

@abhinavv245

No, we downloaded that utility on 7th December.

If we need to use updated one, we will check the same.

[jagadeeswar577]

@abhinavv245

I have the latest log-verification-utility running in my local machine now.

And when I run the Cancel flow logs against it like below

curl -X POST -d "logPath=/Users/jagadeeswardevalla/Downloads/Logistics/Flow-3-Cancel" http://localhost:5000/validate/logistics

{"logReport":{}}

I see no issues reported here.

But you have listed below issues. So how we can check and fix it if we don't see any issues here in local??

[abhinavv245]

@jagadeeswar577 please make sure the correct path is given, when I am running the utility using the cURL or Postman, it is generating the complete log report.

[abhinavv245]

Flow 1 (Order delivered)

/confirm

• order/id should be unique and not be equal to transaction_id: \"e2c3ec62-0f63-4a15-a120-61fba90f1b63\"
• tracking is not required in /fulfillments (as it is enabled/disabled by LSP)
• logistics buyer NP must accept LSP terms (in order/tags). If not accepted, LSP can NACK /confirm with error code 65002, incorrect placement of tags inside linked order

/update

• time is not required in /items (time/duration mismatches from the one provided by LSP in /on_search)
• message/order does not require state, provider, quote, billing, payment, created_at (also, quote price does not match the total breakup price)

/on_update

• why is fulfillment tracking disabled
• payment/status has changed to 'NOT-PAID' from 'PAID' in /on_confirm (payment/status is required in /on_status only)

Flow 2 (RTO)

• on_cancel file is missing
• all the on_status calls have the same timestamp
• fulfillment of type 'RTO' is missing
• RTO charges were not added after RTO was triggered

Flow 3 - (Cancel)

/on_cancel

• order/updated_at is not updated correctly

/on_status

• cancellation is required once the order is cancelled
• RTO item will also be added once the order is cancelled and RTO is initiated

@jagadeeswar577

[jagadeeswar577]

Hi @abhinavv245

For Flow 2 (RTO) ,

when customer wants to return the item(s) back to merchant due to some reason, we are creating a new service request to the logistic delivery to pick up from customer location(start) to the merchant location(end).

So why here on_cancel file comes ?

For Flow 3 - (Cancel),

We are cancelling the Logistic Service request as buyer cancel the order before the item is picked by logistic partner.

So why here RTO item will also be added once the order is cancelled and RTO is initiated comes?

[abhinavv245]

@jagadeeswar577

Flow 2 RTO (return to origin) needs to be tested, it means the buyer refused to accept the order or was not available, so the LSP cancelled the order (on_cancel) and initiated the RTO (backward shipment is added). It seems you are confusing it with another use case (return) which will be a new order altogether.

Flow 3 (Cancel) - As per the logs submitted, order was picked up at "2023-12-19T11:10:00.073Z" and was cancelled at "2023-12-19T11:10:05.373Z" , so backward shipment will be added.

[BLR-0118]

Flow 1 - Delivery

1. /search:

   • suggest you use payment.type as "POST-FULFILLMENT" as this is what's enabled for now;
   • also applies to other APIs like /init;

2. /init:

   • fulfillment.start.contact (for merchant / warehouse) & fulfillment.end.contact (for buyer) should show different contact nos & email IDs;
   • if payment.type is ON-ORDER, you also need payment.collected_by;

3. /confirm:

   • pls remove bpp_terms, bap_terms as this isn't enabled yet;
   • PCC (fulfillment.start.instructions.code & short_desc) are required when order ready_to_ship is "yes";
   • DCC may be set only after order is picked up;
   • PCC & DCC can't be the same;

4. /update:

   • linked order details may be sent only if there is a change in the weight / dim of the goods being shipped (from /confirm);

[BLR-0118]

pls resubmit logs only for flow 1 @jagadeeswar577

[jagadeeswar577]

@BLR-0118 We have been submitted the mentioned logs last month(https://github.com/jagadeeswar577/ToneTag/commit/a87869eec3415527be1d115a774367a7bd73de10) and the PR also has been merged.

Please can you let us know any updates here on the same ?

Thank you

[BLR-0118]

@jagadeeswar577 - ready_to_ship is being sent in /confirm & again in /update; this is incorrect; clearing logs for v1.2.0 subject to the above being fixed;