Saudi Arabia

Manager allows you to set automatic numbering as a form default. If any user purposely tries to override this and enter a number manually, neither the developer nor ZATCA can prevent this. In simple words such employees should not be trusted with permissions to create invoices in your business.

No, there is no such feature currently.
But I’m asking myself, how could they know that our program doesn’t have the full automatic referencing for invoice number.

I think if they really hate you and wanted to give you a penalty they will assign an expert to dig in your program : P

As you are aware all details of ZATCA are at ZATCA PDF. For Manager it may be useful to see how Tally.Erp . See VAT Invoice Format in Saudi Arabia | VAT Invoice in KSA and ZOHO Books (is on ZATCA approved list) also provides details about this E-Invoicing in KSA: How can Zoho Books help? and E-invoicing in Saudi Arabia: All you need to know about KSA VAT e-invoicing

It seems the key challenges for Manager are:

  1. Curb unauthorized access: ZATCA guidelines do not allow anonymous access to transactions and records. So one can not use the Desktop version as this does not have user logins, authorizations, and history by user.

  2. Transaction archive: Businesses are required to maintain records of all their transactions for a period of 5 years. This is no problem in Manager

  3. Protect your transactions and records. Altering invoices and their associated notes, or tampering with the timestamps or log entries, isn’t allowed. This is discussed earlier and Manager seems close to what Zoho does but needs to block users from altering or deleting transactions or tampering with their timestamps. The software’s activity logs (in Manager History) should show the sequential stage-by-stage evolution of each transaction, and this shouldn’t be editable either (as is currently the case in Manager).

  4. Unique Sequential Invoice numbers Although Manager has some autogeneration option this may require a redesign to enforce sequential numbering,

The following don’t should be noted

Avoid an e-invoicing system that:

  • Allows anonymous access. (Desktop version of Manager can thus not be used)
  • Has no user management capabilities.(Desktop version of Manager can thus not be used)
  • Permits e-invoices and associated notes to be edited or tampered with. (This is a challenge at the moment using Manager and the approach may require a redesign)
  • Allows multiple e-invoice sequences to be created. (This is a challenge at the moment using Manager and the approach may require a redesign)
  • Permits time changes or exporting the stamping key. (With some modifications of History this should be doable in Manager).
  • Avoid modifying invoices—instead, issue a debit/credit note and link it to the original invoice. Ensure that e-invoices can not be deleted once they’re issued, as they will be needed for future reference.

Other things such as QR codes, etc seem already to be dealt with.

2 Likes

As discussed previously in this post by other members, this can be split into three parts:

  1. User permissions part. Ability to set some administrators’ level of access to sales invoices to View and Create only.
  2. Permissions to batch create, Batch update and batch delete.
  3. History part. If a history entry is undone it’s not deleted, but rather it should create a new entry with its predecessor state.

Of course, in every well designed ERP there’s always going to be at least 1 user with access to absolutely everything so, my best bet to improving on all of those is to introduce a super admin user role only accessible by logging into https://cloud.manager.io/ or something like that. The super will be able to set permissions for admins like:

  • update and delete of invoices and credit notes
  • access to batch operations
  • access to undo button
  • ability to import and delete business

Also, admins cannot grant users with access rights higher than their own.

Another point that seems to be overlooked by most is the requirement of the invoices and credit notes to be a linked list. Each invoice must have the hash of the previous invoice (it’s not clear whether it’s the reference or UUID) but it should be there but not visibly, though.

3 Likes

Dear @lubos
Saudi Arabia have a new rule of QR code must be BASE64 Encoded
They have launched a mobile application to read the code where Manager QR is not readable!
Also please make sure below data need on QR code

  1. Customer Name
  2. Customer VAT Number
  3. Total Amount with VAT
  4. VAT Amount
  5. Supplier Name
  6. Supplier VAT number

Please find below app for reading QR code

Really appreciate if you could update in the Manager application

Expecting your kind support asap

Aneem

1 Like

@lubos looks like the requirements specify Base64 encoded TLV format QR code.

@Ehab can you please confirm the requirements.

This is not an official software from ZATCA.

All these requirements are done by the current QR generated from Manager.

@sharpdrivetek I remember that I’ve sent this guideline link for @lubos to read, this guidelines is created by ZATCA to help developers
So I’ve sent a link before for Lubos.
I can’t confirm that the manager’s QR code matches the ZATCA programmatically or not. But I can see all the mandatory information available in the QR created by Manager.

1 Like

i saw many invoices , when i scanned the QR code it was Base64 encoded TLV format QR code , so the QR code should Base64 encoded TLV format QR code . like the attached guide

What about the qr code generated in Manager? Have you checked the format of the same in Localizations file?

@sharpdrivetek Kindly, are there differences between the current QR and these specifications?

I thinks all these is related to the second phase.

you can say it is related to QR structure, the QR Code show like the attached photo when i scanned it by Mobile camera
WhatsApp Image 2021-11-23 at 7.40.52 PM

Then, where is the informations required, like seller’s name or VAT ID… etc
How can I get it from this code?

I saw many invoices from different suppliers contain QR code as same as we have too. Not like one you provided here.

I am not sure. Actually I am confused.

this is a screenshot from the document I linked in #post87
Manager presently shows the details similar to the second example which is incorrect as per the document.

@lubos and @Tut we need help. Could you explain for us?

No, I cannot. I have not participated in the Saudi Arabian localizations project or discussions at all.

Thanks

@Ealfardan do you have any suggestions here?