@eCloud @Adithya_Raviraja @mkw @Malik @sameer @Maala @pmohdameen @mohdzeeshan5c0 @Hadi @rudyzidan @Arratech @BEX @plasker @y.khraishi @abin @m.alnoursi @sameer @mohammad.mt
Dear All,
If you have any concerns on the new front end duplication validation rules (208 for Clearance and 409 for Reporting), please share them on the main thread below or here.
Dear @eCloud @Adithya_Raviraja @mkw @Malik @sameer @Maala @pmohdameen @mohdzeeshan5c0 @Hadi @rudyzidan @Arratech @BEX @plasker @y.khraishi @abin @m.alnoursi @sameer @mohammad.mt
Please note that the new validation rules for front end duplication check (208 and 409 response codes) will be deployed to Production Environment by July 20. These validations were already deployed on Simulation Environment a month ago, please test different business scenarios on Simulation and if you have any concerns please revert asap.
Dear @Ankit.K.Tiwari ,
I have tested it thoroughly , Everything seems to be working smoothly so far .
Thank you for your efforts to make this possible .
Hi Ankit,
We have added the necessary changes in our system for the test and production environments. Until now we have not seen any any alerts on 409 and 208 in our systems in the test environment, so hopefully everything should be good for the production release.
Dear @eCloud @Adithya_Raviraja @mkw @Malik @sameer @Maala @pmohdameen @mohdzeeshan5c0 @Hadi @rudyzidan @Arratech @BEX @plasker @y.khraishi @abin @m.alnoursi @sameer @mohammad.mt @anusv
please note that 409 and 208 front-end duplication check validations are deployed to production, below announcement contains further details.
Hi Ankit,
Strangely, today one of my clients reported 409, which is B2C duplicate. To verify, we checked our database and found no duplicate, as we have a primary key, so a duplicate is not even possible in our table. So, how ZATCA marking/responding few invoices as duplicates?
select INVOICE_NUMBER, INVOICE_STATUS, INVOICE_HASH from JS_ZATCA_INVOICE_HEADER where INVOICE_HASH = ‘mAOAXmHjhEXywDkOsE/f/MaFlsnhp4OiMlUp4k2pUVY=’;
or
select INVOICE_NUMBER, INVOICE_STATUS, INVOICE_HASH from JS_ZATCA_INVOICE_HEADER where INVOICE_NUMBER = ‘EMD-D-014257-25’;
| INVOICE_NUMBER | INVOICE_STATUS | INVOICE_HASH |
|---|---|---|
| EMD-D-014257-25 | SIMPLIFIED: REPORTED409 | mAOAXmHjhEXywDkOsE/f/MaFlsnhp4OiMlUp4k2pUVY= |
When an invoice is sent to ZATCA we update its status, hence no chance of duplicate reporting while if you see above it is not duplicate even but it returned 409.
Totally 90 among 132 are reported in Reported:409 remaining in Reported as usual
So please suggest what kind of duplication is this which is not in our side but on ZATCA side it is duplicate.
Thanks
Hi All, Today, I also get 409 statusCode from the reporting API. The invoice was being sent for the first time — there was no duplicate attempt.
Could you please confirm: if I receive a 409 in any case, should I try sending it again with a different ICV, or is there no need to resend that bill?
Please help
Things will be clear on Sunday as seems Zatca team is off but this is abnormal once again like last year. Thanks
@Malik could you please some more hashes for investigation? just the hash values
@Abhishek no you should not change any value on the XML otherwise it will be treated as a different invoice by ZATCA as the hash will change. 409 message says that the hash is already reported successfully, this implies invoice is already received by ZATCA. Please share some sample hash values for investigation (just the hash values)
We received 409 for the below invoice hash.
wV3Uk6mKnVdiycQ5WRQ3/7l60JJ7pimxYO7PdeVuNT4=
Dear Mr. @Ankit.K.Tiwari could you please let us know what went wrong?
| 35dHc2yxzzdw1JC9jc3A7Vsy0Cm+1cUNPLaZLcb8c40= |
|---|
| Q3eLiFtt98ZMSR349CP5HhG/7h+kWy6aTnzvVmo/k5I= |
| ubDslrLXiv0fmMz118w2UR5pQX2YuttFxcrS+JVRxnU= |
| vfNaBtifc2kC8NrP7wisI7ODW9B8iOllTYHXS5plmmk= |
| FsNPQxsw4QYMsBsEA6oj5sy6pebgg3CHIGLpMOk8/dI= |
| Jy6YXpPWkRjSgfVyQ40PVqAEmTf/FQg6Re/q2cAl7U8= |
| GcQI2e5nNzmqC4htkTpp5/KhtZ5+uxNkZKtF7zDS8VQ= |
| 5YAz3IvTz5CYaZ8T1DFcLF93SeXx4igEa/6pZbQiymg= |
| L9/zMl/amHEJzIDGKeDz6umaz3Nem0m3a0lySTC44VM= |
| 1wghq8Z08kfr8geBLoVGMRD3cBX3+pZ7TcavSsiY2bs= |
| Biv5+0Q/nDUpaguoaOhLTS5Y79Pc2nuDyY7RHoWZHD8= |
| lOaQdJ+SUHZfvf5EzAyith9hMhNzL3w7G4BWQi9LhA4= |
| TTWQq19pj3eYwDlHPfqJlvMSSZfEPuJZo0jzbMq70Zo= |
| VlE/XJvEhslJ6V0UwYzQF9odgHh8NcKRpC8/f5FW3YQ= |
| 5+/tW8w2YAlqGA6v4HvY+718wNnZup7aOaoWSbQ5FCk= |
Dear @Malik
Team was able to find the each of your invoices reported successfully with 200 response codes. Therefore, 409 was correctly returned for subsequent submissions. Please consider below suggestions:
1 Check for any duplication in the invoice hash: Please adjust your query to check for duplicates based on the invoice hash instead of the invoice ID. Example query:
select count(INVOICE_HASH ) , count(distinct INVOICE_HASH) from JS_ZATCA_INVOICE_HEADER ;
if the count is different that means there are duplicated invoice hash in SP DB.
2 Review the submission mechanism to ensure that the original request is not being overwritten if it is submitted multiple times to the Reporting/Clearance APIs.
@mohdzeeshan5c0 team found the invoice submitted with 200 response code, subsequent submission must have received 409 as expected.
Hi Ankit,
Thanks for your response, and there is no duplication on our side.
select INVOICE_HASH, count() from JS_ZATCA_INVOICE_HEADER where INVOICE_STATUS like ‘SIMPLIFIED%’ group by INVOICE_HASH having count() > 1
No data found
So let me request your team to check the following,
now I need to know if the first attempt returned no response at all, so then what to do?
IF r_status = 'REPORTED' AND apex_web_service.g_status_code IN ( 200, 202)
r_status := apex_json.get_varchar2(p_path => 'reportingStatus');
IF r_status = 'REPORTED' AND apex_web_service.g_status_code IN ( 200, 202)THEN
v_clearedinvoice := apex_json.get_varchar2(p_path => 'reportingStatus');
UPDATE js_zatca_invoice_header
SET
invoice_status = 'SIMPLIFIED: ' || r_status,
api_response = l_clob
WHERE
id = p_invoice_id;
ELSif apex_web_service.g_status_code IN ( 409) THEN
UPDATE js_zatca_invoice_header
SET
invoice_status = 'SIMPLIFIED: REPORTED409',
api_response = l_clob
WHERE
id = p_invoice_id;
Else
UPDATE js_zatca_invoice_header
SET
invoice_status = 'REPORTING: ' || nvl(r_status, 'ERROR'),
api_response = l_clob
WHERE
id = p_invoice_id;
END IF;
thanks
Indeed, I expect you to get this result from the queries because you don’t guarantee a failure condition when the Zataca is 50x.
The scenario that happens is as follows:
Your system sends the invoice for sharing, for some reason you receive a 50X Response, while Zataka continues to process the transaction and saves the hash in cash.
You try again to send the same invoice for the purpose of sharing, logically you will receive a 409 response.
Try to keep records of the 50X transmissions so that the invoice hash is part of those records.
@psinclair request your input.
Thank You for the quick turn around.
Would be helpful if you could share the uuid of the invoice which we can match in our system just to make sure.
@mohdzeeshan5c0 529ecd74-b68d-4aab-bdcb-4bded1e68ea1