Hi @idaoud
Could you also let us know as to why a change was deployed to the production environment first and not to the simulation environment first, this way we could have experimented with the changes from our end? And also why wasnt there any prior intimation regarding this update so that we could be prepared for the changes?
I think this kind of breaking changes should first deployed in simulation and announced here before to give us some time to update our systems accordingly, or at least return a warning not an error until we have updated our systems.
ZATCA team could also use API versioning.
This is the basic rules of maintaining a widely used API.
We are suffering during last few days hundreds of calls from most of our clients complaining and blaming our software.
We normally do not submit the same invoice more than once.
But ZATCA Reporting API processed the invoice but due to some technical problem it failed to return the expected response. In that case, we resubmit the same invoice, but the second time the API throws the error message.
First time got response
504 Gateway Time-out
Re-submit the same invoice second time got error
“errorMessages”:[{“type”:“ERROR”,“code”:“Invoice-Errors”,“category”:“Duplicate-Invoice”,“message”:“Invoice Hash Previously Submitted”,“status”:“ERROR”}],“status”:“ERROR”},“reportingStatus”:“NOT_REPORTED”}
How will treat these invoices.
Do I consider these invoices as Reported or resubmit with different UUID and ICV
Please suggest an official solution
@All @BEX @Adithya_Raviraja @Malik @Maala @plasker we will be disabling the 409 check in Production in the next hour for a minimum of 1 week to understand the specific issues you face. The check with remian in Simulation so please use this to test your scenerios.
Additionally we will organize some specific developer sessions to walk through your scenerios. Please watch this space for announcements and meeting links.
Many Thanks,
in case of getting 409, will the response contain the final reportingStatus/clearanceStatus and clearedInvoice in case of accepted clearance?
@psinclair Thank you, that will buy us some time to update and deploy our software.
HI Philip,
Thanks and waiting for your confirmation of disabling this new check while on otherside still unable to understand the following so better if a document is released clarifying this new check. My confusion is when API was able to connect and get response means 200/202 means success while what we are facing is invoice is not duplicate but reporting first time is giving hash duplicate error such error 2nd time if by mistake reporting make sense but how and what to do if error on 1st attempt.
“In your assuming, you mentioned that the invoice has been reported successfully, this mean that the response code will be either 200, 202 (Reported), 409 only appeared when trying to hit the reporting end point with same invoice that already submitted.”
If I were you, I would check if the HTTP client you’re using has default retries enabled for connection errors. In our case, errors occur only after a connection failure (eg. socket timeout) during the retry process. I know that some HTTP clients, by default, will retry a request if they don’t receive a response within a certain timeframe."
@psinclair , what is the resolutions for the invoices that are effected ? how to submit the effected invoices ?
@psinclair
Dear Mr. Philip,
Thank you for such decision.
It created a lot of issues with our multiple companies.
My personal suggestion:-
Zatca should make enhancement in such a way, which won’t effect the existing users since any change from zatca further effects the existing user’s integration system and needs user to further enhance their system then you know we might need to follow agile methodology such as change in lower environment and standalone testing , user testing, user signoff and release in production.
If zatca wants to avoid the processing of same invoice in the sub-sequent api calls then zatca may give the same response as it is supposed to give in the first api call and internally it should process the invoice only in the first attempt.
Dear here challenge came due to some changes on the ZATCA side where it is not the retry but even first attempt saying duplicate so what to do in this case? System is not making any duplicate retry for sure. Hope this clarify the issue as this issue came due to a recent change in the ZATCA side which atleast we were not aware till errors. The response code 409 of duplicate is valid if 2nd attempt but here on 1st attempt error. thanks
@idaoud @psinclair We verified the enhancement you made, but we have one issue. In the case of B2B invoices, in the second request, we lose the cleared invoice.
If the invoice was cleared, but I wasn’t able to log this, then the next time, you will just give a 409 error, but you won’t return the cleared invoice. We need this to be returned or if there is a better approach to handle this
Dear @y.khraishi
Thanks for reaching out,
Please not that this is disabled for now in production env and it’s only now in Simulation env, you should start enhancing your system to comply with ZATCA regulations, since you can not submit the same invoice twice, you can try to enable handling 409 response from the simulation env in your solution to avoid any conflict when it published on production again.
Thanks,
Ibrahem Daoud.
@idaoud
what should we expect when we get 409 error? should we assume the document is reported/cleared and the current submission is duplicated or how are you going to communicate the correct status of the invoice?
another question please, can’t we provide an API to fetch the invoice status/data and by that the entire problem is solved?
Dear @Maala
Can I kindly ask you, when was the last time you try it?
Please note that 409 is disabled from production env now, it’s only on simulation.
Thanks,
Ibrahem Daoud.
@idaoud @Ankit_Tiwari @psinclair
We encountered a “409 - Duplicate-Invoice” error with some invoices after initially receiving a “504 Gateway Timeout” response once or twice for each affected invoice.
Below is the submission log for one of the invoices:
[2024-11-03 19:55:19.299 +03:00 INF] First submission attempt
[2024-11-03 19:56:19.437 +03:00 INF] Status code: GatewayTimeout
Response:
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx</center>
</body>
</html>
[2024-11-03 19:56:19.454 +03:00 INF] Second submission attempt
[2024-11-03 19:57:19.620 +03:00 INF] Status code: GatewayTimeout
Response:
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx</center>
</body>
</html>
[2024-11-03 19:57:19.637 +03:00 INF] Third submission attempt
[2024-11-03 19:57:19.983 +03:00 INF] Status code: Conflict
{
"validationResults": {
"infoMessages": [],
"warningMessages": [],
"errorMessages": [
{
"type": "ERROR",
"code": "Invoice-Errors",
"category": "Duplicate-Invoice",
"message": "Invoice Hash Previously Submitted",
"status": "ERROR"
}
],
"status": "ERROR"
},
"reportingStatus": "NOT_REPORTED"
}
In these cases, we do not receive a response indicating successful processing, so we’re unable to confirm the status of the invoices. Could you please advise on how we can track the status in such situations?
what is the resolutions for the invoices that are effected ? how to submit the effected invoices ?
Dear @idaoud @psinclair , We updated our system so that if we get error 409 we consider the B2C invoice reported, but as someone mention above what can we do about B2B invoices since it is singed by ZATCA API and error 409 does not return the signed invoice. I would suggest another API endpoint to check invoice status and return the singed invoice or return it with error 409.
Getting response from any API is not guaranteed always due to unavoidable technical issued that may happen between sending payload and getting and storing response.
@idaoud @psinclair I do understand what you’re saying, but again, if I send a request to Zatca for clearance, and response was delayed (time out) or an error occurred at my side when I try to update my system with the cleared invoice, what should I do?
In order to share this invoice with the customer, I need to get the cleared one from Zatca. If I make a second request, the cleared invoice is not returned. If this enhancement is a must, then there should be an API to inquire, or you should return the cleared invoice along with the 409 error
@BEX @y.khraishi thank you for this response, we are indeed concidering this however it will take time to develop, test and deploy.
Additionally we are concidering to release an API that will allow you to check if a hash exists, this should be deployed more quickly and should be used instead of relying on the 409 to the main endpoint.