Reporting using the PCSID for production environments warning

Clearance and Reporting
1

After receiving the binarySecurityToken for the PCSID, we did a base 64 decode and replaced the result with cert.pem for the Fatoora Java (zatca-einvoicing-sdk-Java-238-R3.4.1)

as we change the private key to the genrated pk

now we have this issue when we use the binarySecurityToken and SECRET for the PCSID
and send the reporting request we are getting error 401 with null response (no response at all)

but if we use the binarySecurityToken and SECRET for the CCSID
We are getting this WARNING
{
“type”: “WARNING”,
“code”: “certificate-issuer-name”,
“category”: “CERTIFICATE_ERRORS”,
“message”: “X509Certificate (CCSID / PCSID) used for signing is not valid certificate (CCSID / PCSID) for this VAT Registration Number.”,
“status”: “WARNING”
}
what should we do with this case

2

Dear @malek_1

Thanks for reaching out,

To provide comprehensive support as usual, can I kindly ask you to check and confirm if you are using the same PCSID binarySecurityToken and secret in the Authorization part for /invoices/reporting/single endpoint?

Thanks,
Ibrahem Daoud.

3

Dear @idaoud,

We’ve been having the same issue for a long time now. To answer your questions:

  • We do not use fatoora’s sdk, we’ve built our own.
  • We’re using the binarySecurityToken and secret received during the onboarding process for authentication.
  • We’re also using the certificate attached to that token while signing the invoice.
  • Decoding the respective signed UBL shows the correct VAT Number in the certificate, the auth token and the cbc:CompanyID

Additional possibly useful information

  • The EGS VAT is a Group VAT.
  • This warning (certificate-issuer-name) is only on the reporting endpoint and not the clearance endpoint.

We appreciate your advice on the matter.

Regards,

4

Dear @omar

Thanks for reaching out, Welcome to our community.

To provide comprehensive support as usual, can I kindly ask you to elaborate with the below:

1- What are the invoiceType in the configuration file the facility are issuing? is it 1000 or 1100 or 0100?
2- What is the invoiceType that you are submitting is it standard B2B, or simplified B2C?

Thanks,
Ibrahem Daoud.

5

Thank you for your prompt response.

1- 1100
2- Simplified B2C

P.S. This is happening both in Simulation and Production, whereas Standard B2B invoice clearance is working perfectly fine in both Simulation and Production.

Regards,

6

Dear @omar

Thanks for your elaborate,

Can I kindly ask you to share your full concerns via below mail, to schedule one to one meeting with our technical team to provide comprehensive support as usual.

SP mail: sp_support@zatca.gov.sa

Thanks,
Ibrahem Daoud.

7

Dear @idaoud
yes When I use the PCSID binarySecurityToken and secret
In the auth, to the endpoint /invoices/reporting/single, i am getting the 401 error
Note that if I send the same request to the /compliance/invoices endpoint, it works fine with no issue

8

Morning @malek_1

Please share your full concerns via below mail, to schedule one to one meeting.

SP mail: sp_support@zatca.gov.sa

Thanks,
Ibrahem Daoud.

9

Thank you @idaoud.

It turned out our problem is precisely what others have mentioned in other threads. The ordering of DN/RDNs is important and must match the order in the certificate’s issuer name. While the certificate used mentioned the following order:

Issuer: DC=local, DC=gov, DC=extgazt, CN=PEZEINVOICESCA2-CA

We were passing the rfc4514 string (which is the reversed one). Once we matched the same order, the warning went away.

I’d like to suggest amending the warning text to indicate this. The actual title certificate-issuer-name is a good indication, the description however, pertaining to CCSID/PCSID/VAT Number could derail the developer from figuring it out.

Regards,

10

@idaoud
we have submitted the full details, looking forward to hearing from you

11

As per our experience, you’re using the compliance CSID instead of production CSID. Swap them, and the issue will be solved InShaAllah.

12

@Ankit_Tiwari , @idaoud , @Aturkistani
I have a few clarifications regarding the use of “Organization Unit Name (OU)” and Other Seller ID (CRN) in the context of onboarding clients and submitting invoices to ZATCA. Kindly help me confirm the correct approach in the following scenarios:

1. For a Tax Group client using the same invoicing software across all branches under the same TIN (with active CRNs):

  • In this case, should we use the TIN number as the Organization Unit Name (OU) in the onboarding configuration?
  • And include the respective branch CRN (of the issuing branch) in the invoice XML under “Other Seller ID”?

2. For a Tax Group client with multiple CRNs, but they are using this invoicing software only in one branch:

  • Should the Organization Unit Name (OU) in this case be the TIN number or the name of the branch using the software?
  • And in the invoice XML, we are including the CRN of the branch that is issuing the invoice – is that correct?

3. For a client that is not a Tax Group and does not have a TIN, only a single CRN (standalone branch):

  • In this case, should we use the Branch Name as the Organization Unit Name (OU) in the config file?
  • And continue using the same branch CRN in the invoice XML?

4. For a previously onboarded Tax Group client who is using the software in only one branch (but the OU was set as the TIN):
They received a notification from ZATCA stating:

“It has been noted that your invoices do not comply with the requirements of the second phase of electronic invoicing – linking and integration, which includes:
Commercial Records: When choosing the commercial record identifier and there are multiple commercial records, the supplier must enter the commercial record of the branch from which the tax invoice is issued. Therefore, all branches through which invoices are issued must be registered, and the correct entry of the identifier field for the commercial record must be verified, which is considered a violation of the provisions of the electronic invoicing regulations…”

In this case:

  • Do we need to revoke the existing Device and re-onboard it using the Branch Name as the OU?
  • Or can we continue using the current setup with OU as TIN without any technical or compliance issues, as they are issuing invoices only from one branch?

Please confirm if the above understanding is correct for these three onboarding scenarios, or let us know the appropriate guidelines as per ZATCA requirements…