our assumption is that we can send the same request over and over again and the result should be idempotent, is that correct?
since the transaction is distributed, we might need to send the same request again if we failed to reflect the response from the first attempt in our datastore.
We have the same issue. But we did not find duplicate invoices with the same invoice hash in our system.
Still we are receiving the 409 response from around yesterday mid night.
And our system is re-trying to re-report these invoices.
We were asked to submit the same XML if anything is wrong in the response. And it used to work. now that we egtting this error and while resubmitting, it again goes on a failure loop saying as this hash is already reported.
Please consider this as a priority issue. We are pretty sure that this hash is unique of its own and it might have taken it to your system while we reported first time. But since we got a failure, we are trying to resubmit, which again goes on the loop.
Otherwise, please tell a way out, newly issued invoices are reporting good, but this happend in between midnight yestreday and today morning.
@idaoud
as stated in the thread our assumption is the opposite actually. we expect an idempotent response if we send the same payload over and over again.
I agree with the part of not booking the same invoice twice, but the having idempotent response in place is inevitably needed and this issue popped up just yesterday and the 409 is not mentioned anywhere in e-invoicing documentation as far as I can tell
@Maala
Agree with you
We shouldn’t submit the same invoice more than once.
But incase zatca reporting API processed the invoice but due to any technical issue it couldn’t give the expected response such as 200,202,400
OR
our own system couldn’t store the API response then
In such case our system would re-try to send the same invoice
and zatca reporting API SHOULD return the same response as it was supposed to give in the first attempt no matter it was rejected or accepted or accepted with warning.
We faced the same issue, and it has caused a lot of problems. How can we check if an interrupted transmission finished correctly? There is no API to verify if a previously uploaded invoice was reported successfully.
Does anyone have any ideas or know if someone has resolved this?
We are submitting all our invoices with no problems at all .
I beleieve it’s something with your code/integration . we re submitting an invoice . you should change (ICV / UUID ) . invoice hash will be changed accordighly at generation .
if you can provide me with xml / code i might be able to help
@Hadi
This isn’t an issue with all the invoices. Randomly certain B2C invoices [percentage is low but count is huge for someone processing high volume B2C transactions] which are signed at our end seems to be rejected, saying:
I beleieve it’s something with your code/integration . we re submitting an invoice . you should change (ICV / UUID ) . invoice hash will be changed accordighly at generation .
If this was the case, ZATCA shouldn’t accept whatever came before or after such rejected invoices. But they are perfectly fine with invoices generated just before such failed invoices and after such invoices. [Scenario am referring here: EGS within POS devices that are physicaly distributed across locations and XMLs are pooled for reporting].
So now lets say when we tried to mitigate this random error by resending the same invoice, which is suggested by ZATCA in here [in older threads], we are again greeted with this same error.
Am not sure but this could be that they might have accepted it at the first request itself and now its a loop of failures as its already reported and its in their DB.
First thing i would suggest you is to look at you logs data and see where exactly this happenes . i don’t know how your system is designed . but we had one similar situation . our system have a retry mechanism in case if connectoin is dropped . the problem was that the http time out period was very short to the point that i cuts the connection in the middle of the process . which means that the invoice was submitted but the connection was cut before we get the response . we increased the timeout period and everything working perfectly now .
i would suggest you review your software logs and if possible send me screenshot to try to help you .
in our side the issue is as following:
1- we submit the invoice payload and waiting for response, we receive the response from zatca but fail to save it in our db.
2- some other pod picks the exact same payload and submits it again attempting to store it in our db. the second attemp gets 409 error code from zatca side that it’s a “duplicate-invoice”.
technically it’s not a duplicate invoice, it’s more we are expecting idempotent response if we send the exact same payload again
@Hadi
we inevitably need to submit the exact same payload again in some occasions so we need to understand what is expected from zatca side when we send the exact payload multiple times. shouldn’t we expect the same response? i.e, invoice reported…etc
Yes , you should receive the same response “Invoice Hash Previously Submitted” . i tried this and we always get the same resposnse . you can try this in simulatoin on Postman
You cannot resubmit the same payload again . This is for sure .
Also , submitting the same invoice twice to ZATCA could lead to legal issues when ZATCA reviews your submissions .
So , you should try to fix the database issues and create queue/protection mechanism if needed .
@Hadi
in that case, if we fail to save the response in our db from the first attempt then we will never be able to do it, as any extra attempt will raise 409 error.
I disagree. There could also be connection issues or other unavoidable infrastructure problems. What should we do in such situations? It’s clear that this reporting service should be idempotent, or there should be an API to check if an invoice has already been reported and to verify its status.