Singapore #451
Singapore #451
Conversation
There was a problem hiding this comment.
This is a great first attempt! Nice one! I'd question if the concept of "receipt" should be there, it feels like something that would be used with a payment device rather than for invoicing.
I'm also unsure about the identity code handling given so many options.
|
|
||
| ### Simplified Tax Invoice | ||
|
|
||
| This invoice is referenced by the tax tag "simplified". This invoice can only be used when the total amount (inclusive of GST) is less than $1000. This invoice has less requirements: |
There was a problem hiding this comment.
It'd be useful to add the currency code of $1000 here.
| ### Reciept | ||
|
|
||
| This type of invoice can be issued to a non-GST registered costumer. This invoice requires the following: | ||
|
|
||
| 1. Suplier name, address and GST registration number; | ||
| 2. The date of issue of the invoice. | ||
| 3. The total amount payable including tax. | ||
| 4. The word “Price Payable includes GST”. |
There was a problem hiding this comment.
Based on this description, it feels like the receipt is probably not needed in GOBL, the "simplified" version will cover most cases.
| } | ||
|
|
||
| // Validate checks the document type and determines if it can be validated. | ||
| func Validate(doc interface{}) error { |
There was a problem hiding this comment.
tiny observation:
| func Validate(doc interface{}) error { | |
| func Validate(doc any) error { |
| }, | ||
| Values: []*tax.RateValueDef{ | ||
| { | ||
| Since: cal.NewDate(2024, 1, 1), |
There was a problem hiding this comment.
This is very recent. It wouldn't hurt to include the last standard rate if available for the sake of backwards compatibility.
| ) | ||
| } | ||
|
|
||
| func validateTaxCode(value interface{}) error { |
There was a problem hiding this comment.
Is there no checksum validation in SG for any of the codes?
| regexp.MustCompile(`^(19[0-9]{2}|20[0-9]{2})\d{5}[A-Z]$`), // UEN (ROC) | ||
| regexp.MustCompile(`^\d{9}[A-Z]$`), // UEN (ROB) | ||
| regexp.MustCompile(`^[TS]\d{2}[A-Z]\w{1}\d{4}[A-Z]$`), // UEN (Others) | ||
| regexp.MustCompile(`^[STFGM]\d{7}[A-Z]$`), // NIRC/FIN | ||
| regexp.MustCompile(`^\w{2}\d{7}[A-Z]$`), // GST |
There was a problem hiding this comment.
With so many to choose from, I get the impression that maybe some companies choose to use multiple numbers at the same time on their invoices, suggesting that only one should be used for the main tax identity.
It could be that the GST makes the most sense in the tax identity, and everything else should be moved to the org.Identity. An additional (not obvious) option here is to switch to using the identities array instead of the tax.Identity.
Describe your changes
Implemented the regime for Singapore following the documentation provided by IRAS
Checklist before requesting a review
go generate .to ensure that Schemas and Regime data are up to date.Considerations
I am not sure if receipts need to be added as an invoice. IRAS states that they are a valid form of invoicing in certain situations. I followed the format used in Portugal as they have a similar type of invoice.
I did not divide the different type of GST registration numbers as different Identities as they are all GST reg. numbers even if they are also used elsewhere.
Please check the examples as I had to set a tag in my local branch to build using mage and I am not sure if that caused any issues when validating my examples.