Phase 2 Support

[obahareth]

• [x] #8
• [x] #9
• [x] #10
• [x] #11
• [x] #16

[Nimesh-Arselor]

• [ ] Schema and simple wrappers for XML #8
• [ ] Cryptographic stamp and signature #9
• [ ] Hashing #10
• [ ] API integration #11

Need a help

[obahareth]

Hey @Nimesh-Arselor, this is still being worked on. Once it's done the wiki will have sample requests for different invoice types.

[AbdelrahmanManz]

Hey @obahareth, is this still being worked on? I can participate if so.

[obahareth]

@AbdelrahmanManz Yes in #15. I already have test cases and generation of standard/simplified invoices done, as well as a simple HTTP client for their API. There is one point that I am currently stuck at that I have spoken to ZATCA about and waiting for their reply.

Right now the hash of the XML is very whitespace-dependent and if you look at the samples ZATCA has for simplified invoice, standard invoice, debit notes, credit notes, etc.

They all have different indentation sizes and different spacing between elements even. A simple change in the whitespace results in your hash being invalid unless you match ZATCA's whitespace per file and per case. You can test this by trying ZATCA's validator against their own signed invoice sample, then just adding/removing any single whitespace and then rehash/regenerate the QR code with the new hash and see that it becomes invalid on their validator.

I went with an approach of dynamically generating the XML based on the input (which is really great for supporting all of the different cases), assuming that ZATCA has a whitespace standard, I am asking them to also support a minified version of the XML to avoid whitespace issues.

If I have no luck there, then it may be a better idea to either:

1. Use an approach where we just copy their files as is and swap in our values (similar to what @wes4m did in his NodeJS version)
2. Create custom subclasses of Invoice for each case and manually adjust the whitespace to match ZATCA's after generating the XML.

Since the library already uses an approach of generating XML and we are short on time, I will probably go for option 2 unless ZATCA allows minified XML.

[obahareth]

This is mostly complete now, invoices generated by this SDK have passed all the onboarding checks on simulation and successfully generated the production CSID.

Will merge the PR after some final testing.

[AbdelrahmanManz]

@obahareth Great stuff!!! 🔥