You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,11 @@
1
1
# Changelog
2
2
3
+
## 3.4.0
4
+
5
+
-[FEATURE] Allow for "untaxable" invoices. This is, for example the case when you deliver services to US states that don't tax these, or if you're falling below the registration threshold.
6
+
-[FEATURE] To support valid "untaxable" invoices, `:tax_id`, `:global_id` and `:global_id_scheme_id` are introduced on `TradeParty` as attributes. ZUGFeRD does not allow VAT ids on invoices that are untaxable, so you need a global id (and other validators want you to add the local tax id as well, but that's mandatory, I think). This could be a SWIFT id, for example, which would be an IBAN for EU folks. (IANAL!)
7
+
-[FEATURE] Introduce tax_calculation_method = :NONE, which skips collecting taxes from line items and just uses the global values. It also skips some of the validations. This is a hack-ish solution to a problem I ran into where the invoicing service calculated the VAT and net amounts backwards from a round gross amount, resulting in rounding errors when trying to calculate them the correct way round. This is easier to use when you only have one tax rate and all the values are already known.
8
+
3
9
## 3.3.0
4
10
5
11
-[FEATURE] Allow for vertical tax calculation. PR by @RST-J
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ See tests for examples.
7
7
1. This is an opinionated library optimised for my very specific usecase
8
8
2. While I did start to add some validations to make sure you can't input absolute garbage into this, I cannot guarantee factual (as in taxation law) correctness of the resulting XML.
9
9
1. The library, for ZUGFeRD 2.x, currently only supports the EN16931 variant. This is probably what you want as well. PRs welcome.
10
-
3. This does not contain any code to attach the XML to a PDF file, mainly because I have yet to find a ruby library to do that. For software that does this, take a look at [this python library](https://github.com/akretion/factur-x).
10
+
3. This does not contain any code to attach the XML to a PDF file, mainly because I have yet to find a ruby library to do that. For software that does this, take a look at [this python library](https://github.com/akretion/factur-x) or [this Java library which also does extended validation](https://mustangproject.org)
Copy file name to clipboardExpand all lines: lib/secretariat/constants.rb
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -66,7 +66,7 @@ module Secretariat
66
66
67
67
# For the background of vertical and horizontal tax calculation see https://hilfe.pacemo.de/de-form/articles/3489851-rundungsfehler-bei-rechnungen
68
68
# The idea of introducing an unknown value is that this could be inferred from the given invoice total and line items by probing both variants and selecting the matching one - or reporting a taxation error if neither matches.
0 commit comments