409 status code - Duplicate-Invoice error

[Maala]

@mkw
exactly, if you don’t need us to send multiple attempts against the same invoice then we need an api to check the invoice status/data/etc

[rudyzidan]

Hi Hadi, wanted to confirm the below info/questions.

• I Revisited our logs and found out it was related to the http client timeout up to 3 sec, does that mean it pass the ZATCA business rules / required validations. Can i treat 409 as reported already in my next attempt?

What is the recommended timeout from your perspective and max concurrent retries can be handled by your servers so i can check our end and configure it accordingly.

[pmohdameen]

@Hadi

I think timeout issues are there for a long time now and as you said we all have adjusted our timeouts accordingly considering each scenarios.

In this case, the response is never timedout at ZATCA’s end, but they do respond at the first request with same failed 409. So we will have retry obviously as the request was not a timedout one, but genuine rejection.

Still lets say they are rejecting same payload, then It will contradict what ZATCA Team has said here multiple times:

@Ankit_Tiwari

If everything remains same on both XMLs then you can disregard the same XML sent again as ZATCA will consider this as a single transaction.
Source: Credit Note with Same IRN submitted Multiple Times and Cleared - #3 by Ankit_Tiwari

also,

@Aturkistani

Our advice is always to re-submit such an invoices till got reported, so stick with your current process please and ignore it.

Source: Ocassionally Reporting API gives einvoice-kafka-publisher ERROR - #2 by Aturkistani

In this two cases, they talked about re-reporting same payload without any issue and it was working good till yesterday.

[rudyzidan]

@Aturkistani can you support us ?

[Hadi]

Actually , Yes it would make senese … what i can sugguest you in current situation (until ZATCA provides checks API) is to have an alternative data store(db) in case if it fails to save in your db . maybe local file .

[mkw]

But we still don’t know if zatca set status of this invoice to reported or not_reported

[Hadi]

in my situation , i found this to be good enough :
1- a retry machinsim . which will submit the same invoice again 3 times (in case if failures) with a delay of 1 second between each retry (mutliplies with each retry) . means first one is 1 second . second one is 2 and third is 3 .
2- http time out is 10 second

and have been submitting my invoices for more than 1 month now didn’t get any issues

[pmohdameen]

If anyone is waiting for a status checking API from ZATCA’s side, here’s what they have told in past [regarding discrepancies in statistics on fatoora portal]:

We have issue in statistics in zatca portal

Dear @Ammar each API call gets a response whether it is accepted, rejected or accepted with warnings. You can build your report based on API call responses and rely on it as the single source of truth.

It means that whatever we receive from ZATCA as API response is the single source of truth, at least for now. So lets say if we are getting 409 at first response and then again “Invoice Hash Previously Submitted” in subsequent requests, then I dont think we will be able to get a REPORTED status somehow for a valid & already issued/signed XML.

[Maala]

@Hadi
when can we expect the API to be ready? it would be really handful with that breaking change

[Hadi]

Wait @Maala , I’m not with ZATCA team . i’m an enduser only and developer like you . Just trying to help here with anythin i know

[Maala]

ah lmao - sorry I thought you work for them somehow but yeah anyways we need someone from zatca to support us on this

[Hadi]

No worries … happy to help with what i know

[mohdzeeshan5c0]

@Maala
@Hadi
There could be 3 ways:

1. They give the same response on each sub sequent call of reporting API
2. If they are giving the 409 status as a response in the sub sequent calls then along with it they should also provide the status of this invoice whether it was reported or not_reported(rejected)
3. Provide an api to check status of the submitted invoice

[Hadi]

One thing to keep in mind , 409 means reported always .
in case of rejection . it will not be saved in ZATCA which means it will never give you 409 .

[mohdzeeshan5c0]

@Hadi
if zatca doesn’t store it then why do we re-generate the xml for the same rejected invoice with different identifiers such as Invoice Hash,ICV,UUID, QR Code and PIH?

[Hadi]

Here is an example of a connection error happens at my integration but it was able to overcome it and everything is going smoothly .

[Hadi]

Hmmm … yes you are right . it can be eaither cleared or rejected invoice .

Just try to tweek your code to extarct all possible details on each step on the process . this is the only advice i can give you for now .

[mohdzeeshan5c0]

@idaoud
Appreciate if someone from zatca could guide us on this.

[Adithya_Raviraja]

We also have noticed the same issue in our system as well. And in our case, we received this response in the first attempt of sending the invoice. No amount of retries were able to fix the issue.

If this response is going to be norm from now. Then request to ZATCA team to provide the steps that need to done from to handle the affected documents or like the other users have mentioned, please provide a get API so that we can simple fetch the signed invoice from the ZATCA system and use that.

Finally, this change looks to be very recently implemented to the production systems, requesting the ZATCA team to please provide a public annoucement so that we are prepared with the necessary changes from our end before the actual deployment.

[Maala]

@idaoud @Ankit_Tiwari
seeking your urgent help here