Before production, all the process (onboarding, clearance, generating production CSID) were successfully working on simulation environment.
However:
After successful onboarding for production, when trying to send a standard invoice for clearance, we get 401 Unauthorized Access.
For the login, we used binarySecurityToken and Secret for the user name and password which are generated from compliance onboarding.
We tried the entire process in the simulation: generating the compliance CSID, clearance invoice, credit note, and debit note. All returned with a “pass” and “cleared” status. Then, we generated the production CSID and created all document types again, which worked fine.
The validation results returned the following:
Validation Result: Complied with UBL 2.1 standards in line with ZATCA specifications.
Validation Status: PASS
Clearance Status: CLEARED
Error Messages: None
Warning Messages: None
Do we need to follow the same workflow in production mode as we did in the simulation: onboarding → create invoices and clearance → generate production CSID?
If this is the workflow for production, we used the Compliance CSID request response BinarySecurityToken and Secret as the username and password. However, it’s throwing an Unauthorized error (401) because we can’t request the production CSID (production CSID BinarySecurityToken and secret response) before the clearance invoice.
@mubarkoot for the compliance checks to get the pcsid you have to use the ccsid . if you getting the message in this step , you probably have an error in your code somewhere .
@mubarkoot after getting the ccsid you need to check all types of invoices in order to get the pcsid . it’s a procedure to prove your solution can indeed clear invoices to zatca .
after getting the pcsid you can use the compliance endpoint to verify your invoices will be approved or not (a test) .
This error may appear for the following reasons:
You receive four keys:
CCSIDBinaryToken
CCSIDSecret
PCSIDBinaryToken
PCSIDSecret
The first two keys (CCSIDBinaryToken and CCSIDSecret) are used only for compliance checking. These keys are required to sign the XML invoice for compliance verification.
If the compliance check passes, you must then use the third and fourth keys (PCSIDBinaryToken and PCSIDSecret) to sign the same XML invoice data for reporting and clearance.
The Compliance API requires “Basic Auth” authentication using the first and second keys.
The Reporting and Clearance APIs require “Basic Auth” authentication using the third and fourth keys.