Your efforts are truly remarkable.
Thank you for your cooperation, and we remain genuinely interested in this topic.
I believe thatβs true. but the first question here is: Who is using MAnager as a POS in Saudi Arabia? Even if there are some users, I donβt believe it is widely used in this manner.
I also think the Manager currently does not differentiate between simplified and standard tax invoices. Therefore, we can consider all tax invoices issued by the software as standard tax invoices, not simplified ones. This is essential for creating a custom code or extension to address the current systemβs deficiencies and comply with one of the key governmental requirements for system usage. Every effort made here is a positive step forward, and we hope this goal will be attained soon.
This point requires further clarification. According to the Authority, if the invoice amount exceeds 1,000 riyals, the terms of a tax invoice must be followed rather than those of a simplified invoice. This implies that customer (buyer) data must be recorded whether the invoice is B2B or even B2C.
As you are aware, for B2B transactions, it is mandatory to comply with tax invoice requirements and avoid using simplified invoices.
In conclusion, as previously mentioned, we should consider all invoices issued by the Manager as tax invoices. The main determining factors are the invoice amount and the buyerβs details. Currently, the program does not have a separate feature for simplified billing.
@Mabaega great effort. Iβm also looking into this. However, my approach would be a bit different. It looks like eventually all countries will have some kind of e-invoicing regulation in place.
And in some cases, it wonβt be possible to implement in pure javascript. There will need to be some kind of backend infrastructure in place. So what Iβm thinking is to abandon javascript and simply have backend infrastructure in place for everything that needs outside integration.
Therefore e-invoicing could be a web-service that accepts JSON representation of sales invoice in Manager. And responds with JSON representation of sales invoice. This way invoice can be furnished with more information after submission.
This means when someone wants to enable e-invoicing in Manager in any country, all they need is to enter URL of the web-service into Manager (somewhere in Settings tab). If URL of web-service is entered, there can be a button (similar to yours in top-right corner). When button is clicked, Manager will send invoice data to web-service. The web-service will respond with modifications that should be made to the invoice.
Iβm considering similar mechanism for bank feeds, tax submission, exchage rate updates etc.
But in the end, I really donβt know which solution is the best. I will have a go at my approach and see how it turns out. In the end, there can be multiple implementations for the same problem.
Thatβs right, I tried to create a script for this need, but it felt very difficult and I canceled it. Currently I am trying to learn C# and Minimal Api to create a Gateway that is responsible for converting Invoice Data from the Manager into Zatca Signed Invoice and sending it to the Zatca SDK Portal. So far it has worked, although it is still far from expected.
Would you be able to host your code on Github? I think the best course of action would be open source C# library that anyone can use, not just Manager.io. But Iβm happy to fund this library on Github for everyoneβs benefit. Iβm already funding a few open source developers there.
I think we donβt even need that much. Just C# library with a few functions that handle communication with ZATCA servers. No need to figure out how to convert Manager.io data to ZATCA data. I will do that.
@Mabaega Iβm glad you got working system. Have a look at Relay which is new concept.
This should simplify a lot of things for you but also for end-users. If your e-invocing integration is working as a relay service, all Manager users have to do is to copy URL of your web-service into Manager.
I am pleased to inform you that the ZATCA web service is now ready for testing. I hope you can take some time to check its functionality and provide your feedback.
To assist you, I have included a video tutorial that guides you through the process of testing the service. Additionally, you can download the necessary files from our GitHub repository.
Thank you
If you encounter any difficulties while running the web service, please feel free to download the .NET SDK from the provided link.
@Mabaega great progress. We should improve the user experience so there is nothing to download.
For example, Manager.io can host Relay service for those who donβt want to self-host it. This means Relay service should be generic without business specific configuration as it could be used by many businesses at the same time.
Setting up ZATCA integration should be as easy as copy and pasting Relay URL to Form Defaults of sales invoices and credit notes.
Youβve done a good job on instructions however we will need to find a way how to automate this.
Iβve noticed your project contains SQLite database. What is this database used for?
User need adding some Customfields to meet the data requirements.
Users do not need to add custom fields themselves if these fields are already provided in localization.
The webservice needs to store Invoice data that has been successfully reported to Zatca. Store ICV as Invoice Counter and PIH (Previous Invoice Hash) will be used in subsequent Invoice reporting. Stores original data from managers that have been reported to prevent repeated reporting and to restore Manager data if data changes occur accidentally to the Manager. Webservice also stores all responses obtained from the server during reporting. Sometimes invoices that do not meet the requirements will also be accepted with certain Warnings, perhaps this will be useful in the future.
And we also need relays for Payment, Receipts, Purchase and Debit Notes.
Iβm not really sure, it seems like one business can use more than one device for reporting. Each device will have a different certificate but with the same Business Tax Info. Each device will have its own ICV and PIH number.
What if the tool is lost, we have to register a new tool by creating a new CSR and registering (oboarding). The new device will have a new ICV and PIH with the ICV starting at 1, and the PIH starting at SHA256 from the number 0 encoded with Base64.
I just drew conclusions from the forum. Maybe @ehab understands more about this.
I understand better now. ICV and PIH cannot be lost because they are generated from your data. Itβs not a secret parameter from ZATCA.
Actually, now that Iβm thinking about this. Relay should be able to update/create multiple objects at once. This way you will be able to create/update custom fields, footersβ¦ and also ICV and PIH number can be continuously updated in some hidden custom field under Business Details. This would eliminate need for database in your backend.
But that brings me to another issue. There is a chance that multiple users could be submitting new invoice to ZATCA at the same time. This could mean two users will attempt to submit new invoice with the same PIH number.
