wes4m / zatca-xml-js

An implementation of Saudi Arabia ZATCA's E-Invoicing requirements, processes, and standards in TypeScript.
MIT License
73 stars 59 forks source link

IRN Sequence incase of an EGS with both Standard and Simplified to be issued #33

Closed amexn-me closed 1 year ago

amexn-me commented 1 year ago

First of all, big thanks to @wes4m for publishing this repo.

I've a doubt regarding the sequence of Invoice reference numbers in case of an EGS which issues both Standard and simplified invoices from a same billing point. Invoice Reference Number or IRN need to be in sequence as per VAT regulations [mentioned in ZATCA resolutions]

Usecase: We issued a Simplified invoices in between 2 Standard Invoices which got cleared in real time, but the former was rejected during reporting process [which is done in batch after certain hours].

Possible answers:

  1. Just resubmit with same IRN?
  2. Issue as fresh B2C?
  3. We issue notes to cancel the same and reissue? But we haven't reported the invoice in the first place. So where to give reference to?

cant wrap my head around it. please explain me if am missing out something. thanks in advance

adriantoro26 commented 1 year ago

As far as I know we need to keep with the sequence of the invoice reference number, which is similar to what they mention regarding previous hash field where even though an invoice gets rejected its hash must be used as a previous hash for the next invoice

adriantoro26 commented 1 year ago

On another note, did zatca share its production URL and where can we be up-to-date with their news?

amexn-me commented 1 year ago

As far as I know we need to keep with the sequence of the invoice reference number, which is similar to what they mention regarding previous hash field where even though an invoice gets rejected its hash must be used as a previous hash for the next invoice

I think you’re referring to Invoice Counter Value (ICV), not Invoice Reference Number (IRN). ICV and hash need to be generated every time regardless of the clearance/reporting status. My doubt is about IRN in such specific scenarios

wes4m commented 1 year ago

I'm not sure about this specific case. Maybe they expect the every sequenced number including IRN to keep increasing even if rejected ? Maybe someone can verify by re-reading the docs

adriantoro26 commented 1 year ago

Maybe this might help, this was taken from Zatca documentation According to this document:

On page 12

Invoice Reference Number A unique and sequential number that identifies the issued invoice by the E-Invoice Solution, according to article 53 of the VAT Implementing Regulations. The VAT Implementing Regulations did not specify a specific format for the Invoice Reference Number, and the reference numbers may be different, for example, a different sequential reference number for each branch, provided that the Tax Invoice is clearly and distinctly defined and follows a sequence.

Page 66

What is the difference between Invoice Reference Number and Invoice sequence number? "As clearly mentioned in the Annex 2 of E Invoicing Resolution, Invoice Reference Number (IRN): A unique, sequential note number, issued by taxpayer, as per Article 53(5)(b) of the VAT Implementing Regulation. This implies IRN is just another name for Invoice Sequence Number. Again, as specified in E Invoicing Resolution, the Compliant E-Invoice solution must have a tamper-resistant Electronic Invoice counter that cannot be reset or reformatted. The counter must increment for each generated Electronic Invoice or associated note and the Compliant Solution must record the value of this counter in each Electronic Invoice or associated Notes. Example 1,2,3,4,5... “

wes4m commented 1 year ago

For me it makes sense to keep increasing it even if the invoice is rejected. There is no way to know before hand if it will be rejected or not if you're doing batch reporting and/or operating offline. Invoice will have already been generated to the customer. Also, since the IRN does not follow a specific format as long as it's sequential, this means that ZATCA won't verify IRN at their backend.

What I've been doing at Invoicen.io is to keep increasing and proceeding as usual even when reporting or compliance checks fail, while marking that failure in the db per invoice (failed_to_report: true, error: ...) to deal with later, (e.g running a cron or manual checking).