Add Sweden regime

[BoscoDomingo]

ℹ️ This PR comes with a sister PR in this repo, #519, which has multiple QoL changes unrelated to this task I made whilst developing it.

I'm still missing documentation in gobl.docs and the out dir in examples. However, functionality is ready to be checked.

First time contribution, feedback is highly welcome!

---

• Added the Swedish regime, including a README, tax identities, org identities and the corresponding tests.
• Added the Luhn algorithm from https://github.com/luhnmod10/go
• Improved the way we can find a country and its data (using CountryMap)

Pre-Review Checklist

• I have performed a self-review of my code.
• I have added thorough tests with at least 90% code coverage.
• I've modified or created example GOBL documents to show my changes in use, if appropriate.
• When adding or modifying a tax regime or addon, I've added links to the source of the changes, either structured or in the comments.
• I've run go generate . to ensure that the Schemas and Regime data are up to date.
• All linter warnings have been reviewed and fixed.
• I've been obsessive with pointer nil checks to avoid panics.
• The CHANGELOG.md has been updated with an overview of my changes.
• Requested a review from @samlown.

[samlown]

Great first attempt and especially documentation! Also good to see validations for some of the more local identities.

[samlown]

We generally try to avoid sweeping assumptions about the presence of data. I'd expect the address to be required in a specific format and circumstance, rather than in all invoices and contexts for Swedish invoices.

[BoscoDomingo]

If I understood the specs correctly, they do not give any requirements for the format of the address itself, but it must be present for all invoices and parties involved.
Additionally, neither party need be located in Sweden, only (at least one of them) registered for tax. I may be mistaken, however, so I'll double check and come back to you on that

[samlown]

The question is which specs you're looking at. Tax regimes should reflect what is defined in the law as opposed to any specific format, its very unlikely that the law requires customer address details, but if it does, a comment that links to that requirement would be very useful.

[BoscoDomingo]

For regular invoices, yes, both customer and supplier addresses are necessary. They explicitly ruled it, it seems (both in Swedish).

For simplified invoices, however, customer is omitted and supplier can be identified exclusively by VAT ID (in Swedish)

Update: I've been working on adding support for simplified invoices and currently the bill.Invoice itself has a check for Supplier.Name that impedes Tax ID-only simplified invoices. For now, I'll add a Name to the example I'm using, but we should allow overriding that rule for cases like this.

[BoscoDomingo]

@samlown How can I get the out directory in examples? I thought it was autogenerated

[samlown]

@samlown How can I get the out directory in examples? I thought it was autogenerated

Out directories are generated with the go generate . command.

[BoscoDomingo]

@samlown How can I get the out directory in examples? I thought it was autogenerated

Out directories are generated with the go generate . command.

I may be missing something. I also tried in main and it didn't work for any other regime either (I deleted all out directories and they weren't regenerated).

rm ./examples/*/out
go generate .

[samlown]

out folders are not created: https://github.com/invopop/gobl/blob/main/examples_test.go#L114

[BoscoDomingo]

out folders are not created: https://github.com/invopop/gobl/blob/main/examples_test.go#L114

Even when the out directory is there, files aren't generated, even in main with go generate ..

Running go test ./examples_test.go --update however, did create them. Is that the correct way? And obviously this must be added to the contribution guide and probably the README too

[BoscoDomingo]

@samlown What's left for this to be merged?

[codecov]

Codecov Report

❌ Patch coverage is 97.92746% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.24%. Comparing base (529bd41) to head (ad229c6).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
regimes/se/bill_invoice.go	96.42%	1 Missing and 1 partial ⚠️
regimes/se/org_identities.go	96.15%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #518      +/-   ##
==========================================
+ Coverage   92.17%   92.24%   +0.07%     
==========================================
  Files         297      302       +5     
  Lines       14555    14742     +187     
==========================================
+ Hits        13416    13599     +183     
- Misses        819      821       +2     
- Partials      320      322       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[BoscoDomingo]

@samlown This should be ready to merge now. Lmk if you have any feedback!

[samlown]

Thanks for updating this one @BoscoDomingo! It'd be great to get this into GOBL. I've added a set of comments on details that I think should be fixed before merging.

[samlown]

I see your point, I think the main issue however is polluting the internal package with utility functions. Until we have more use-cases of this, I'd suggest sticking with the current common package associated with Regimes.

An alternative approach would be to create a package in pkg called checksum or similar that provides these utility methods.

Another approach would be to incorporate a validation Rule inside the cbc package alongside the Code type to specifically check the luhn check digit.

[samlown]

I'd split this validation into its own function for clarity and an appropriate name.

[BoscoDomingo]

The main problem is that 2 fields in this struct (Code and Type) are intertwined. Without an inlined anonymous function, I'm not sure I can access both at once (at least not from what I've seen in the validation package)

[BoscoDomingo]

It results in something like this:

return validation.ValidateStruct(id,
	validation.Field(&id.Code,
		validation.By(func(value any) error {
			return validateOrgIdentityCode(value, id)
		}),
		validation.Skip,
	),
)

[samlown]

Finally ready to merge this one! Many thanks @BoscoDomingo!

[BoscoDomingo]

Finally ready to merge this one! Many thanks @BoscoDomingo!

Love to see it!! Glad I could be of help <3