GRAB LSP (IGM) - compliance check
Opened this issue · 5 comments
/lsp_issue
- Organization's Name for /issue api mismatched with bap id
/lsp_on_issue
- Seller app's subscriber id should be bap_id in the context of /issue api when on_issue comes from logistics provider
- Seller app's subscriber uri should be bap_uri in the context of /issue api when on_issue comes from logistics provider
/lsp_issue_status
- Timestamp not in RFC 3339 (YYYY-MM-DDTHH:MN:SS.MSSZ) Format
- Seller app's subscriber id should be bap_id in the context of /issue_status api when on_issue comes from logistics provider
- Seller app's subscriber uri should be bap_uri in the context of /issue_status api when on_issue comes from logistics provider
- /lsp_issue
Organization's Name for /issue api mismatched with bap id
as we are LSP , we received /issue call from the seller, what changes you are expecting here.
Organization's means, issue_actions.issue_actions.updated_by.org.name
-
/lsp_on_issue
Seller app's subscriber id should be bap_id in the context of /issue api when on_issue comes from logistics provider
Seller app's subscriber uri should be bap_uri in the context of /issue api when on_issue comes from logistics providercan you please define Seller app's subscriber id ?
while sending \on_issue bap_id and bap_uri we keep as same as \issue call, as it is a seller info. In our case its
"bap_id": "logistics.ondc.digiledge.in",
"bap_uri": "https://logistics.ondc.digiledge.in", so we send same info in \on_issue call -
/lsp_issue_status
Timestamp not in RFC 3339 (YYYY-MM-DDTHH:MN:SS.MSSZ) Format
we have added check , if its not in format then will send async response with error code
code : IGM005
call : /on_issue
msg : Type of time object should be aligned with beckn standardsSeller app's subscriber id should be bap_id in the context of /issue_status api when on_issue comes from logistics provider
Seller app's subscriber uri should be bap_uri in the context of /issue_status api when on_issue comes from logistics provider
as we are LSP , we received /issue_status call from the seller, what changes you are expecting here.
@RupalSingla
lsp_issue_status
- Timestamp not in RFC 3339 (YYYY-MM-DDTHH:MN:SS.MSSZ) Format
- Timestamp for issue_status call must be greater than on_issue call
lsp_on_issue_status
- updated_at of last respondent_action should be the same in the message/issue/update_at in the on_issue_status
- Organization's Name for /on_issue_status api in message/issue/issue_actions/respondent_actions/[2] mismatched with BAP ID
- Domain of organization for /on_issue_status api in message/issue/issue_actions/respondent_actions/[0] mismatched with domain in context
We have done the testing for IGM with Digiledge , also we have gone back to Seller App to identify the correct information for
As per them the information is correct , further we are only passing the information that is percolated from UPSSTEAM in this case it’s the SELLER APP.
Please find the status of lsp_on_issue_status
• updated_at of last respondent_action should be the same in the message/issue/update_at in the on_issue_status – Rectified by Grab
• Organization's Name for /on_issue_status api in message/issue/issue_actions/respondent_actions/[2] mismatched with BAP ID – Information passed from Upstream – Grab cannot modify
• Domain of organization for /on_issue_status api in message/issue/issue_actions/respondent_actions/[0] mismatched with domain in context - Information passed from Upstream – Grab cannot modify
Let us know if we can resubmit the logs again with corrected ON_ISSUE for “updated_at of last respondent_action should be the same in the message/issue/update_at in the on_issue_status”
on_issue_status
- rsepondent_actions.updated_at has changed between on_issue and on_issue_status for "PROCESSING" action.
- issue.updated_at has changed with no change to the action trail
Logs cleared