Special rules for the currency HUF about einvoicing-en16931 HOT 14 CLOSED

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.