Dears ,
Hope this finds you well .
One question regqrding the PIH . should i use the last submitted PIH or the last cleared PIH ?
in case if an invoice is submitted and rejected . should i use the invoice has for it for the next invoice or not .
@Hadi PIH value should be the ‘hash’ of immediately preceding document generated from a CSID irrespective of the type of document (Standard Invoice, Simplified Invoice, Debit Note, Credit Note etc) and irrespective of status (accepted / rejected / accepted with warning).
Thank you @Ankit_Tiwari for your reply .
Noted with thanks .
One last question , regarding the QR printe with the invoice . should it be decoded or not ? i should just put the QR coming in the response from the API , correct ?
Thanks
@Ankit_Tiwari We are facing an issue regarding ICV and PIH, as we have only one CSID. We send invoices through it, but I was previously counting the ICV based on the invoice type, whether simplified, tax, or credit note. Now, I want to change it based on the CSID.
My questions are:
- Are there any issues with the invoices we have already sent?
- Does the new ICV that I will generate need to start with sequence number 1, or should it start from the last number I sent to the authority?
@Hadi yes correct, you just display QR on human readable form which can be scanned using ZATCA’s Mobile App. ZATCA has not prescribed any specific size or position in layout where it should be displayed. So long as recipient can scan the QR Code using ZATCA’s Mobile App it is fine.
@MGawad for invoices already sent with incorrect ICV and PIH sequences, you can submit a failure notification using service https://zatca.gov.sa/en/E-Invoicing/FailureNotifications/Pages/VerifyTaxpayer.aspx . No action needed to go back and change ICV PIH values retrospectively. Every new CSID should have Invoice Counter Value (ICV) starting with 1 and incremented by 1 for every new document (irrespective of type of document Standard invoice, Simplified Invoice, Credit Note, Debit note and irrespective of status of invoice whether accepted / rejected / accepted with warning).
@Ankit_Tiwari
thanks , Should I create a new CSID and start the counter at 1, or should I continue working with the old one and reset it to start at 1 or the last ICV that I sent?
@MGawad you can continue using old one and increment ICV in continuation to the last ICV sent.
@Ankit_Tiwari ok thanks , i have other question sir ,
Is there an issue with printing the QR code for Phase One on simplified invoices? Sometimes, I need to review the invoice before sending it, and there is no internet in the branches, so I want to send it from the head office. However, I want to print a barcode on the invoice. Can I initially print the QR code for Phase One until the invoice is sent to the authority?
Are there any penalties for doing so?
@MGawad once you onboard devices for Phase 2, you must issue Phase 2 compliant invoices (QR Code on Simplified Invoices must have 9 tags). Issuing Phase 1 QR Code will be in violation of requirements and subject to applicable penalties.
@Ankit_Tiwari If I printed the second phase and issued an invoice to the customer, and then later reviewed the invoice and made adjustments to it, and wanted to send it afterward, there would be a discrepancy between the QR code that was provided to the customer and the QR code that was submitted to the authority.
@MGawad once you have sufficiently tested all business scenarios, the probability of Simplified Invoices getting rejected is very low. Most validation rules that could result in rejection have been relaxed to accept invoices with warning. This is working perfectly fine for all taxpayers since Wave 1 who integrated from 1 Jan 2023. We would suggest you do through testing of various business scenarios on Simulation Environment.
@Ankit_Tiwari If I modify the date or make any notes on the invoice before sending it, there will be a discrepancy between the QR code printed for the customer and the QR code submitted to the authority.
@Ankit_Tiwari and if i want to sent it to authority with new UUID or New ICV but the invoice QR that was issued to customer with other UUID and ICV
Is there a problem?
@MGawad for Simplified Invoices (B2C) since the transaction with customer is already completed, you should not modify the date or content in XML.
@MGawad if for any reason Simplified Invoice is rejected, you have to fix error and send XML again for reporting. This implies the technical fields such as ICV, UUID, PIH, QR Code and hash will change on fixed XML. The data that customer sees on human readable form of Simplified Invoice doesn’t change.
@Ankit_Tiwari "Thank you very much for this clarification. Let’s assume that I won’t change the date or the fixed fields that the client sees, such as the invoice amount, tax, and date. However, the UUID and ICV are changed when sending. Is there a problem if I generate the XML upon sending and sign it again but with the same previous data?
The idea is that the five tags won’t change, but the signature, ICV, PIH, and UUID will be changed. Is there a problem if I generate the XML upon sending and sign it again with the same previous data?
@Ankit_Tiwari Is there a problem when printing the QR in simplified invoices, but when actually sending it to the authority, I create the XML again, but with the same data but with a difference UUID , ICV and Pih ?
Hi @MGawad ,
Just to answer your question, the QR code will not be valid on ZATCA side (when scanning with their application) in your case. Because the data (encoded in QR code) which you generated will not be submitted to ZATCA, it will be submitted with other values.
I am talking about tag 6 (invoice hash) and tag 7 (signature of invoice hash) will be different. Why? Because UUID, ICV and PIH are all included in invoice hash and all included in signature.
Best regards,
Sergei
Dear @Ankit_Tiwari ,I am also facing an issue with PIH. As you mentioned, from the CSID API response, we only receive the requestID, dispositionMessage, binarySecurityToken, and secret. We do not receive any hash from the CSID API. Your help would be greatly appreciated.