Comments (14)
Could you please provide some example files?
from einvoicing-en16931.
Here you go: huf_example_cii.xml.txt
from einvoicing-en16931.
The sample file does not fire any rule. Can you please send an invoice with this problem @phax ? What are the affected rules?
from einvoicing-en16931.
Why isn't BT-114 (rounding amount) used to solve this? It is the intended field to correct this kind of currency-dependent rounding issues…
from einvoicing-en16931.
Well, in my understanding the reason of the "Slack" was to handle different calculation and rounding models.
If the currency clearly states "you have to round for the total amount", it is a different semantic.
The same logic needs to be applied to prepaid amounts and all other external amounts that are inside an invoice, so I am convincedm that slack is not the way to go here.
from einvoicing-en16931.
I see your point regarding external amounts. But the original requirements for the corresponding field in the CEFACT data models linked to the respective field in the CII and for UBL as well (talking about pre 2010) is exactly currency rounding of total amounts. This is the intended semantic definition of this field in EN16931. The other cases to use it as a slack for different calculations was added later during the implementation phase. This is not the original semantic meaning and was chosen as there is currently no other solution available. You can find the definition for instance in the original CEN Workshop agreements, that were used as a basis for EN16931.
from einvoicing-en16931.
Hello everyone,
I'm the one who placed the topic.
BT-114 (rounding amount) is only used here:
- [BR-CO-16] - The content of the element "Amount due for payment" (BT-115) must match the content of the element "Invoice total amount with VAT" (BT-112) minus the content of the element "Paid amount" ( BT-113) plus the content of the item "Rounding amount" (BT-114).
However, our accounting is based on this:
-
[BR-CO-17] - The content of the element "VAT category tax amount" (BT-117) must match the content of the element "VAT category taxable amount" (BT-116) multiplied by the content of the element "VAT category rate ' (BT-119) divided by 100, rounded to two decimal places
-
But there is no corresponding field "Rounding amount"
from einvoicing-en16931.
Hi @VWeber1965, I think that we need some examples and maybe a discussion in the TC434 as this can be a major change on a business rule.
Could you please send us some sample invoices?
Thanks a lot
from einvoicing-en16931.
Hi
@AndreasPvd is correct that the purpose of BT-114 is to support rounding of the invoice totals. The slack was not intended to replace this business term but only to prevente unitentional error from VAT validation within the invoice, specially when VAT inclusive priced items need to be entered as VAT exclusive priced.
@phax the title of this ticket is misleading. This is not an issue specific to HUF but any currency where totals are commonly rounded off.
from einvoicing-en16931.
p_21620198615006.xml.txt
P_21620198615006-report.html.txt
Hi,
we do not have cross-border payment transactions, but what is known as multinational accounting.
It's true that it's not just a HUF problem. However, we only noticed it with the HUF invoices, because in Hungary they calculate with full amounts without decimal places.
[BR-CO-17] - VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals.
18679 = 69180 x (27.00 / 100) - But the validator calculates 18678.60 and says our calculations are wrong.
Attached is the xInvoice with the error report
from einvoicing-en16931.
@VWeber1965 I tested your provided test files with the current version and the invoice passed without any error, thus I think the problem is solved now.
from einvoicing-en16931.
That means there is now a new version of the KoSIT validator that can deal with the fact that in Hungary there are only full HUF without decimal places? What's the new version? Has the new version already been stored on ZRE and OZGRE during the initial check?
from einvoicing-en16931.
The error for the "slack" in CII was fixed in the CEN rules v1.3.5 (see #303 (comment)) - this means, that (to my understanding) starting from rule release 1.6.0 for XRechnung 2.1.1 the problem should have been resolved
from einvoicing-en16931.
I close the issue as it seems to be solved.
from einvoicing-en16931.
Related Issues (20)
- UBL-SR-32 HOT 9
- missing cardinality check for Value added tax point date (BT-7) and Value added tax point date code (BT-8) in CII HOT 1
- Undocumented and missing changes in v.1.3.11 release HOT 3
- BR-33 / BR-CO-21 rules validation doesn't work on CII files (OK on UBL files) HOT 1
- [BR-63] fails if multiple URIUniversalCommunication are present HOT 5
- Tolerance of 1 € on BR-S-09 HOT 2
- BT-32 path check missing in BR-AE-02, BR-AE-03, and BR-AE-04 in CII HOT 1
- Code list changes
- ISO 4217 VEF/VES
- Commit did overwrite PR changes
- CII special ID elements without attributes - not handled correctly
- VAT Category "B" supported even though it is not in the EN
- Contradicting message
- ISO 4217 HRK / Kuna
- Artefacts v1.3.12 (CII) do not check BR-62 / BR-63 correct any more HOT 2
- Allow code 106 (Withheld taxes and social security contributions) on Allowance code list 5189
- BR-CO-15 for correct amounts HOT 1
- Invoice Content: Romania Commercial Registaration No. of the Customer (Legal requirment)
- Error with a validation with xsl HOT 1
- br-co-25 check does not match description HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from einvoicing-en16931.