Query: Correct PIH Selection After a Rejected Invoice

General
1

Scenario:

  1. Invoice 1: Submitted successfully to ZATCA and marked as “Reported.”
  2. Invoice 2: Submitted using the hash of Invoice 1 as the Previous Invoice Hash (PIH), but rejected by ZATCA and marked as “Not Reported” due to some mistakes.
  3. Invoice 3: Now being prepared.

Question:
For Invoice 3, which invoice hash should be used as the PIH:

  • The hash of Invoice 1 (Reported)?
  • Or the hash of Invoice 2 (Not Reported)?
2 Likes
2

it should be the hash of Invoice 2.

1 Like
3

@hnatividad Thank you

4

Hi @arjun_tech24

Do not think about it as reported/not-reported. Think about is as submissions. If submission reached Zatca, then the hash should be stored and then used as PIH.

Reported --> Failed --> Network Error --> Reported --> ...

In this example the document which end-up with network error, you have to RETRY without changing any payload. Why? because you do not know for sure if it was reported or not. It can happen that timout happened on client side but it was reported, it can happen that LoadBalancer on ZATCA side restarted (gateway) but the request was processed by the server etc…

We are following these rules:

  • reported, good nothing to do, store
  • failed, good nothing to do, store
  • error, bad we have to schedule the task to retry but as well store it

At the same time we are implementing our own validation of business rules to not submit “for sure” incorrect data, that’s why failed invoices in our case should happen very rare.

I hope my explanation can help you and someone else in future.

Best regards, Sergei

1 Like