PIH, ICV building and sequence number and order

XML and business rules
1

Salam
i have some questions for the XML mainly related to the PIH

  1. for the previous invoice hash PIH if i submitted invoice 1, then credit note 1, then want to submit invoice 2 the PIH will be the credit note 1 or the invoice 1 ?
  2. the previous invoice hash PIH it is related to the sequence number order? if i create invoice 1 and submit it, then create invoice 2 and not submitted due to connection issue, then create invoice 3 it’s PIH is invoice 1 or invoice 2 even if not submitted yet?
  3. should we assign the ICV at the time we generate the invoice on device or when we want to submit the invoice to zatca? so they are order depend who created before on device or who submitted to zatca first
  4. in case of clearance is disabled, it is recommended to send the standard invoice to the reporting API, it will return the clearedInvoice or we must sign it on device and send it exactly like simplified, and no need to clear it again?
  5. for Compliance check enough to just send one type of document example just “Standard Invoice” for example or need to send 6 request with samples [Standard/Simplified + Invoice/Debit-Note/Credit-Note], note: Invoice type 1100 support both simplified and standard, and the submitted document is just for testing will not be recorded?

Thanks

2

Hi @bilal,

Welcome to our community portal.

please find the answers to your questions below:

Q1. PIH depends on the last generated invoice hash from the solution, if your solution generated invoice with ICV (1,2,3) then PIH of the invoice “3” should be the invoice hash of invoice “2”. Regardless of the submission order as there are no limitation on the submission order, sequence of invoices should be maintained on generation order. Let’s assume that your question was about the generation order, then invoice “2” should have a PIH value set as the hash of credit note1

Note: your solution should assign a new ICV value incrementally with each generated invoice/document.

Q2. PIH depends on the last generated invoice, taking your scenario in consideration, even if the invoice 2 is not submitted due to a connection issue, invoice 3 “PIH” should be the invoice hash of the invoice 2

Q3. ICV should be assigned on generation order not submission order, so the answer would be: ICV should be assigned incrementally on which invoice “was created be the EGS first” not which “was submitted to ZATCA first”

Q4. If the taxpayers is not able to clear their invoices for any failure/disaster reasons either by ZATCA side or taxpayer’s side, they shouldn’t use reporting API to send invoices, instead, they should follow ZATCA’s responding to failure approach, which is specified in the E-invoicing detailed guideline, please refer to the E-invoicing guideline 10th section “failure scenarios” for more information.

Q5. In case that the filed of the invoice type is “1100” in CSR configuration, then you should send all of the 6 documents which are standard & simplified tax invoices and their associated notes. All of the invoices on compliance checks phase will not be recorded as it’s just for testing the taxpayer’s solution capability to generate a valid invoices/notes before sending them to ZATCA through reporting & clearance APIs

**Should you require any further clarifications, please don’t hesitate to reach out, we are more than happy to help :slight_smile: **

3

Hi @Aturkistani
very thanks for your reply, i just want some clarifications:

my Q1 related PIH was that the PIH is not related to document type [invoice, debit note, credit note], if last created document was credit note and the current one to create is invoice it will take the last document regardless type so here in the example will take the credit note and not the last invoice that was before the credit note.

Q3 ICV assigned incrementally on which invoice is created, so in case of invoice rejected and want to send it again after submitting other invoices i will send it with the same ICV that i try to submit it first and failed as it is related to create time not submit time, right?

Q4 was because in the Sandbox Integration, for the clearance API there is a parameter called “Clearance-Status” specify when clearance is disable to send standard invoice using Reporting API so this not right in production, not applicable in case of reporting API return Response “303 clearance is deactivated” to submit the invoice to Reporting API.

4

my Q1 related PIH was that the PIH is not related to document type [invoice, debit note, credit note], if last created document was credit note and the current one to create is invoice it will take the last document regardless type so here in the example will take the credit note and not the last invoice that was before the credit note. >> True

Q3 ICV assigned incrementally on which invoice is created, so in case of invoice rejected and want to send it again after submitting other invoices i will send it with the same ICV that i try to submit it first and failed as it is related to create time not submit time, right? >> Rejected will have a new ICV and as it will be new so PIH will also change.

ICV
1
2
3 - Rejected invoice no INV-123 PIH of 2
4
5
6 - Resubmitted invoice no INV-123 PIH of 5

Q4 was because in the Sandbox Integration, for the clearance API there is a parameter called “Clearance-Status” specify when clearance is disable to send standard invoice using Reporting API so this not right in production, not applicable in case of reporting API return Response “303 clearance is deactivated” to submit the invoice to Reporting API.

Better do testing in Simulation instance as Sandbox is for public.

5

Dear @bilal,

Regarding your follow-up questions, please see the below:

Q1: Yes, PIH is not locked to the XML ducoment type generated before, when you want to generate a new invoice and the last generated document was credit note. Then the PIH will be releated to the credit note yes, not the last invoice.

Q3: No, when the invoice is rejected with “400” error, then you need to assign a new ICV, Hash, PIH, UUID. As the invoice (after correcting the error causing rejection) will be trated as a new invoice submission.

Q4: My response was for failure scenarios “500” code releated errors, it’s mandatory for taxpayers to follow responding to failure scenarios approach in case of any failure, which specefied by ZATCA in detials in section 10, E-invoicing detialed guideline, where you can find it in official ZATCA’s website.

Don’t hesitate to raise a new query if needed & our team will be happy to help