Open urakozz opened 2 days ago
Hi @urakozz! Really great to hear you've been testing this!
Right, so the issue you mention is actually a feature of GOBL that still needs a bit better documentation. The "rate": "standard"
property you mention is completely optional. In fact, for the 7% rate you probably want to use "rate": "reduced"
, although you can just as easily remove the rate completely and put in your own percentage.
The mapping should be happening automatically, but we're actually moving away from this "gobl.xinvoice" library at the moment and heading towards https://github.com/invopop/gobl.cii which provides a more generic two-way implementation for the underlying format supported by the XRechnung semantic definition, either CII or UBL. Any issues with the conversion between rates and correctly using the S
flag, should be defined there.
Hey @samlown thx for the quick response. We just run a research about the different libraries to generate ZUGFeRD /XRechnung and among Java/PHP/C# versions your Golang version looks the most promising.
Thank you for the hint about cii
library, but it looks like GitHub shows 404 on that page, maybe it's still a private repo.
We will address your tips regarding the tax rate for out MVP version and I'm looking forward checking CII
library and contributing there
Hello and thank you for the library.
We are currently exploring its functionality and have identified a bug in the tax calculation.
If in the German invoice example from tests you'd change percent from 19% to 7%, the result of parsing would be still 19%
It seems like
"rate": "standard"
takes priority over provided percent, however it's inaccurate.Source: Factur-X Documentation §7.3.3.3 THE BLOCK "RAM:APPLICABLEHEADERTRADESETTLEMENT"
I suspect this is probably automation on the gobl itself, but it probably would make sense if provided
percentage
would take a priority over therate
. It feels like it makes sense not only for German/French accounting, but as a generic behaviour