Online Invoicing Processing for Hungary

This document describes the process for online invoicing for Hungary performed in 'Online Invoicing Transactions. Open' (AAS390), through which XML files are created for customer invoice transactions for transfer to the Hungarian tax authorities.

Background

The Hungarian tax authority requires that the invoicing software used by Hungarian tax payers has a direct data transfer with the authority, in which sales invoice data must be reported in XML format in real-time, without human intervention, immediately after the preparation of the invoice. This liability applies to Hungarian business to business transactions between domestic tax payers, currently for invoices having a VAT amount of at least 100.000 Hungarian Forints (HUF). Also, changes to existing customer invoices containing Hungarian VAT must be included in the reporting.

The report is in XML format and validated against the invoiceData.xsd schema published by the National Tax and Customs Administration of Hungary (NTCA).

Solution overview

M3 BE creates an XML file for each customer invoice that meets the prerequisites for online invoicing for Hungary. This XML file is placed in an MvxFileTransfer folder, which is monitored by the Local.ly connection tool that transfers the XML file to the Hungarian tax authority, NAV. NAV sends a response file to indicate whether the XML file has been accepted or not. Based on this response, the IEC server uses a Financial Business Message (FBM) to update the status of the invoice record in M3 BE through the API AAS390MI, transaction UpdInvStatus.

Validation of invoices in Hungary

Only invoices that meet the prerequisites for online invoicing, are included in the online invoicing processing. In addition to the validations referenced in Online Invoicing Processing, there are some additional validations for Hungary to decide whether a customer invoice that is being processed through (GLS040), or added manually in (AAS390), should be included in online invoicing, or not. These additional validations are:

Corrective invoices and validation of VAT amount

When a normal invoice is created, the VAT amount determines if it is to be included in online invoicing, if all other prerequisites are fulfilled. If this invoice is later changed through a corrective invoice, two parameters need to be considered to decide whether the corrective invoice should be included in online invoicing or not:
  • If the original invoice has been reported before, and
  • the accumulated VAT amount of the original invoice plus the corrective invoice.

Original invoice:

Corrective invoice:

To find out if an invoice is correcting an earlier invoice, AR additional information categories 235 (for corrective invoices) and 255 (for credit notes) are used. If such an additional information category exists for the invoice in 'Customer Invoice. Display Add Info' (ARS216), the original invoice number and original invoice year is found in field AR additional info.

For the original invoice, AR additional information category 236 holds information about the corrective invoice number and the corrective invoice year. Similarly, if the original invoice has been changed through a credit note, AR additional information category 256 holds information about the credit note and year of the credit note.

If the original invoice has been changed by more than one corrective invoice, or credit note, several occurrences of AR additional information 236 and/or 256 could be found for the original invoice. If that is the case, the VAT amount of the original invoice, as well as the VAT amount of all invoices referring to this original invoice, should be accumulated and compared to the amount limit defined in (AAS900), to decide whether an XML file should be created for the processed corrective invoice or not.

Reference to original invoice when reporting corrective invoices

As described in the section 'Corrective invoices and validation of VAT amount', if the report concerns a corrective invoice, or a credit note, the original invoice must also be considered when it is decided whether the corrective invoice should be included in online invoicing or not.

If the corrective invoice should be reported, then the elements under tag 'invoiceReference' must be included in the XML file. These elements contain information about the original invoice number, and if there are also later corrective invoices that refer to the same original invoice.

The elements under the tag 'lineModificationReference' should also be included in the report, if it concerns a corrective invoice.

For example:

For the original invoice there is just one item line with net amount 7.000.000 HUF and VAT amount 350.000 HUF, as well as one line for a header charge of 1.000.000 HUF (not subject to VAT). In total, there are two invoice lines to be included in the XML file for this invoice.

Next, the original invoice is corrected, with corrective method 1 in (OIS380), whereas the line amount is changed from 7.000.000 HUF to 8.000.000 HUF. As a result, two item lines with amounts -7.000.000 HUF and 8.000.000 HUF, respectively, are included in this corrective invoice, as well as VAT -350.000 HUF and 400.000 HUF (net amount 50.000 HUF). In total, there are two invoice lines to be included in the XML file for this corrective invoice.

Next, the original invoice is corrected again, with corrective method 1 in (OIS380), whereas the invoice is reversed. As a result, one item line with amount -8.000.000 HUF and VAT amount -400.000 HUF is included in the corrective invoice, as well as one line for the reversal of the header charge with -1.000.000 HUF. In total, there are two invoice lines to be included in the XML file for this corrective invoice.

This table shows the invoices and the line amounts:

Invoice number Invoice type Line amount VAT amount
2018100000015 Original

Item +7.000.000 HUF

Header charge 1.000.000 HUF

350.000 HUF

N/A

9999999900033 Corrective 1

Item - 7.000.000 HUF

Item +8.000.000 HUF

- 350.000 HUF

+400.000 HUF

9999999900039 Corrective 2

Item -8.000.000 HUF

Header charge -1.000.000 HUF

-400.000 HUF

N/A

The first corrective invoice 9999999900033 is processed for online invoicing. To find if this invoice is correcting an earlier invoice, AR additional information categories 235 (for corrective invoices) and 255 (for credit notes) are used. If such an additional information category exists for the invoice, the original invoice number and original invoice year can be found in (ARS216). For this corrective invoice, we find the original invoice number 2018100000015 and original invoice year 2018 in AR additional information category 235.

To identify if any other corrective invoices have changed the original invoice, AR additional information category 236 (for corrective invoices) can be searched for the original invoice in (ARS216). Similarly, if the original invoice has been changed through a credit note, AR additional information category 256 is used for information about the credit note and year. For this original invoice, corrective invoice number 9999999900039 has also changed this invoice.

Invoice header level:

On the invoice header level for corrective invoices, information about the original invoice number, the invoice date of the corrective invoice, the invoice number of the latest corrective invoice for the original invoice (if any), and information if the original invoice has been reported before, is listed in the elements under the 'invoiceReference' tag in the XML file.

In the example, we cannot find the original invoice in (AAS390), which means that it has not been reported to the Hungarian tax authority before. This results in the 'modifyWithoutMaster' element being set to 'true'. If the original invoice would have been reported before, this element had been set to 'false'.

Invoice line level:

On invoice line level for corrective invoices, information about the continuing line number of the original invoice is listed in the elements under the 'lineModificationReference' tag in the XML file.

In the example, the original invoice 2018100000015 contains 2 invoice lines and the corrective invoice 9999999900033 also contains 2 invoice lines. This means that the 1st line for corrective invoice 9999999900033 corresponds to the 3rd line of the original invoice, whereas the 2nd invoice line for corrective invoice 9999999900033 corresponds to the 4th line of the original invoice. Similarly, if the second corrective invoice 9999999900039 would be reported, which also contains 2 invoice lines, the 1st invoice line for corrective invoice 9999999900039 would correspond to the 5th line of the original invoice and the 2nd invoice line for corrective invoice 9999999900039 would correspond to the 6th line of the original invoice. This continuing line number of the original invoice is listed in the 'lineNumberReference' element.

The 'lineOperation' element always holds the value 'CREATE', as all changes made to an original invoice within M3 Business Engine result in new transactions being created. In the example with corrective invoice 9999999900033 the line amount is changed from 7.000.000 HUF to 8.000.000 HUF. Two new invoice lines are then created with -7.000.000 HUF and 8.000.000 HUF.

For customer order invoices, each invoice line of line types (IVTP) 31, 60, 65, 50, 51, and 67 except for 'csk' charges in 'Invoice. Display Lines' (OIS351), are reported as separate lines in the XML file. Consequently, those are the invoice line types that are also considered when calculating number of lines for the 'lineNumberReference' element.

Advance invoices and 'final invoices' – validation of VAT amount

For a customer order, an advance invoice can be created in 'Customer Order. Invoice in Advance' (OIS105), and a payment request can be created in 'Payment Request. Open' (OIS125). When the delivery of the goods has been made to the customer, a so called final invoice is issued. When such a final invoice is validated for online invoicing, the total VAT amount in HUF of the advance invoice (or pre-payment invoice), and the final invoice, must be calculated for validation against the VAT amount limit defined in 'Settings – Online Invoicing' (AAS900). The reason for this, is that the VAT amount of the final invoice might not meet the VAT amount limit, if the VAT amount of the advance invoice is not considered as well.

For example:

An advance invoice is created for 400.000 HUF plus 108.000 HUF in VAT. This invoice is reported to the Hungarian tax authority (NAV), as the VAT amount exceeds the VAT amount limit defined in (AAS900) for 100.000 HUF.

When the delivery has been made to the customer, a final invoice is issued for 500.000 HUF plus VAT 135.000 HUF. As the customer has already paid 400.000 HUF plus 108.000 HUF in VAT, these amounts are withdrawn from the final invoice. This means that the customer will only have to pay 100.000 HUF (500.000 – 400.000) plus 27.000 HUF in VAT (135.000 – 108.000) for the final delivery. When this invoice is validated for online invoicing, the VAT amount of 27.000 HUF is validated against the settings in (AAS900), and as it does not meet the VAT amount limit, the invoice will not be reported to NAV.

However, this would not be correct. As the total VAT amount (135.000 HUF) of the advance invoice (108.000 HUF) and final invoice (27.000 HUF) exceeds the VAT amount limit in (AAS900), the final invoice should be included in online invoicing. Note that the reported VAT amount for this final invoice will still be 27.000 HUF, as 108.000 HUF has been reported earlier, for the advance invoice.

When a final invoice is issued for a customer order, for which an advance invoice (or a pre-payment invoice) has been issued earlier, the final invoice is updated with AR additional information category 294 in table FSLEDX with a reference to the advance invoice number. This update is made through programs (OIS195) and (OIS197). This information is displayed in 'Customer Invoice. Display Add Info' (ARS216).

If more than one advance invoice (or pre-payment invoice) has been issued for the customer order, the final invoice will be updated with a reference to each one of these earlier invoices, which means that there could be more than one occurrence of AR additional information category 294 for a final invoice.

When a final invoice is validated for online invoicing, the total VAT amount in HUF of the advance invoice(s) (or pre-payment invoice(s)), and the final invoice, is calculated for validation against the VAT amount limit defined in (AAS900). The total VAT amount in HUF is calculated based on all VAT transactions (with TRCD=11 and AT04 = 1 or 2) for the voucher(s) in table FGLEDG. If the total VAT amount in HUF is equal to, or exceeds, the VAT amount limit defined in (AAS900), then the final invoice will be included in online invoicing for Hungary.

To determine if an invoice is a final invoice or not, table FSLEDX is checked for AR additional information category 294. If this additional information category exists for the invoice in table FSLEDX, the invoice is considered a final invoice.

Reporting advance invoices and final invoices

When an advance invoice, or a pre-payment invoice, is issued for a customer order, the invoice line of line type (IVTP) 50 should be reported with element 'advanceIndicator' set to 'true'. This element is created under start tag 'invoiceLines', before element 'lineDescription'.

Apart from this element that is specifically created for advance invoices, the XML files created for advance invoices and final invoices are not different from the XML files created for ordinary customer order invoices.

General settings for online invoicing in Hungary

Define settings for online invoicing in 'Settings – Online Invoicing' (AAS900) for the country code used for Hungary (defined with ISO code 'HU' or 'HUN' in 'Country. Open' (CRS045)).

For Hungary, you define the minimum VAT amount that needs to be reported, the FAM functions that should be considered for online invoicing and the MvxFileTransfer folder in which the XML files should be created.

The VAT amount limit defined on (AAS900/E) is expressed in the currency linked to the country code in (CRS045), for which the settings apply. For Hungary, the VAT amount limit is expressed in HUF. The field for VAT amount limit cannot be left blank on (AAS900/E). If all customer invoices should be included in the online invoicing reporting, you should set this value to zero.

Only invoices created through specified FAM functions are considered for online invoicing. On (AAS900/E), you select which FAM functions should be included. At least one FAM function must be selected. Currently, only customer invoices created through FAM functions AR10, AR20, CO20, FA50, MF01, OI20, PO20, and SO20 are supported.

Folder name can be left blank on (AAS900/E), and in that case the XML files will be stored in the MvxFileTransfer folder without a sub folder. If a folder name is specified, the XML files will be stored in that sub folder within the MvxFileTransfer folder. The specified sub folder must exist, and must therefore be manually created, before it can be selected on (AAS900/E).

Note: We do not recommend working in blank division when issuing invoices, but if that is done, XML files for online invoicing reporting should still be created. To be able to process online invoicing for invoices that are issued when working from blank division, the user must define a "dummy record" in (AAS900) for blank division. This record could be defined for any base country code, as it is only used for the initial control of that setup exists for online invoicing in (AAS900). The actual setup for the base country code of the invoice for the invoicing division is still being controlled later in the workflow, to assure that the online invoicing reporting is made in accordance with the setup.

Currency Hungarian Forints (HUF)

If the functionality for online invoicing is to be used in a division that is not situated in Hungary, but involving a fiscal representative in Hungary, currency HUF (Hungarian Forints) must be defined in 'Currency. Open' (CRS055) and the current exchange rate must be defined, for the rate type used, in 'Exchange Rate. Open per Date' (CRS058). This exchange rate is retrieved to element <exchangeRate> for invoices issued in other currencies than HUF, when a fiscal representative is involved.

Name and address information

Name and address information is retrieved to the applicable elements in the XML file. This information is included under these tags:

This table shows how the information is retrieved by default:

Element Company (MNS100/E) Customer (CRS610/E) Supplier (CRS622/E)
name CONM CUNM SUNM
countryCode CSCD CSCD CSCD
postalCode PONO PONO PONO
city TOWN TOWN TOWN
additionalAddressDetail COA1, COA2, COA3, COA4 CUA1, CUA2, CUA3, CUA4 ADR1, ADR2, ADR3, ADR4

If the name and address information has been specified in another way, a translation can be defined in 'Business Message Data Translation. Displ' (CRS881) and 'Business Message Data. Translate' (CRS882). This setup is made per division.

Run online invoicing once through (AAS395) to automatically create the header records for translation in (CRS881). After this first run, select the applicable record in (CRS881) and use related option 11='Translate' in (CRS881) to open (CRS882) to specify the translation.

'name' element

The 'name' element is populated, by default, by retrieving information from the field used for name in (MNS100), (CRS610), and (CRS622)/(CRS620), but to indicate that information from one of the address fields should also be included, a translation is defined in (CRS882). This could be useful if the name is longer than the field allows (for example, CUNM in (CRS610)).

Run online invoicing once through (AAS395) to automatically create the header records for translation in (CRS881). After this first run, identify the 'name' element in (CRS881), which holds the following values:

Description Field Value
Message standard MSTD M3BE
Version MVRS 1
Message BMSG HU-TaxAuthAuditData
I/O IBOB O
Parent element(s) ELMP name
Data element ELMD name

To define the translation of the name information, use related option 11='Translate' in (CRS881) to open (CRS882). In (CRS882) you specify the setup.

M3 data is set to:

Message data is set to:

This table shows how the setup can be specified:

Description Field Value
External partner EXTP Blank
M3 data MVXD COMP, CUST or SUPP
Message data MBMD 1,2,3 and/or 4

This table shows an example of a setup:

Line in (CRS882) M3 data Message data
1 CUST 1
2 SUPP 1

'city' element

The 'city' element is populated, by default, by retrieving information from the field used for city (TOWN) in (MNS100), (CRS610), and (CRS622)/(CRS620), respectively, but to indicate that information from one of the address fields should be used instead, a translation is defined in (CRS882). This could be useful if the name of the city is longer than the field TOWN allows.

Run online invoicing once through (AAS395) to automatically create the header records for translation in (CRS881). After this first run, identify the 'city' element in (CRS881), which holds the following values:

Description Field Value
Message standard MSTD M3BE
Version MVRS 1
Message BMSG HU-TaxAuthAuditData
I/O IBOB O
Parent element(s) ELMP simpleAddress
Data element ELMD city

To define the translation of the city information, use related option 11='Translate' in (CRS881) to open (CRS882). In (CRS882) you specify the setup.

M3 data is set to:

Message data is set to:

This table shows how the setup can be specified:

Description Field Value
External partner EXTP Blank
M3 data MVXD COMP, CUST or SUPP
Message data MBMD 1,2,3 and/or 4

This table shows an example of a setup:

Line in (CRS882) M3 data Message data
1 COMP 2
2 CUST 4
3 SUPP 3

In this example, the information will not be retrieved from the 'TOWN' field to populate the 'city' element.

'additionalAddressDetail' element

The element 'additionalAddressDetail' is populated, by default, by retrieving information from all four address fields. If only one, or a few, of these address fields should be included in this element, a translation can be defined in (CRS882).

Run online invoicing once through (AAS395) to automatically create the header records for translation in (CRS881). After this first run, identify the 'additionalAddressDetail' element in (CRS881), which holds the following values:

Description Field Value
Message standard MSTD M3BE
Version MVRS 1
Message BMSG HU-TaxAuthAuditData
I/O IBOB O
Parent element(s) ELMP simpleAddress
Data element ELMD additionalAddressDetail

To define the translation of the address information, use related option 11='Translate' in (CRS881) to open (CRS882). In (CRS882) you specify the setup.

M3 data is set to:

Message data is set to:

This table shows how the setup can be specified:

Description Field Value
External partner EXTP Blank
M3 data MVXD COMP, CUST or SUPP
Message data MBMD 1,2,3 and/or 4

This table shows an example of a setup:

Line in (CRS882) M3 data Message data
1 COMP 1
2 CUST 23
3 SUPP 2

In this example, the information will not be retrieved from all four address fields to populate the 'additionalAddressDetail' element.

VAT registration numbers

VAT registration numbers have prefix 'HU' for Hungarian companies. The VAT registration numbers should be specified as 11 digits without any dashes.

VAT registration numbers populate the 'communityVatNumber' element in the XML file. If the VAT registration number contains blanks, dashes, or any other restricted character, those are removed before populating the 'communityVatNumber' element.

This table shows how VAT registration numbers are defined:

Party Setup Element in XML file
Company Field VRNO on (MNS100/G) communityVatNumber
Customer Field VRNO on (CRS610/J) communityVatNumber
Fiscal representative Field VRNO on (CRS620/E) N/A

Tax numbers

All Hungarian companies are assigned a tax number. Normally this is specified in the 'Organization number 2' field (COR2), but it could also be specified in the 'VAT registration number' field (VRNO). If specified as a VAT registration number, it might have prefix 'HU' for Hungary, but this prefix is not included when populating the 'taxNumber' element in the XML file.

Tax numbers should be specified as 11 digits without any dashes. If the tax number contains blanks, dashes, or any other restricted character, those are removed before populating the elements in the XML file. The information is divided among three elements: taxpayerId (first 8 positions), vatCode (9th position), and countyCode (10th and 11th positions).

This table shows how tax numbers are defined:

Party Setup Element in XML file
Company Field COR2 on (MNS100/G) supplierTaxNumber
Customer Field COR2 on (CRS610/J) customerTaxNumber
Fiscal representative Field COR2 on (CRS620/E) fiscalRepresentativeTaxNumber

Some customers are members of a group, and under those circumstances the 'groupMemberTaxNumber' element should also be included in the XML file, in addition to the 'customerTaxNumber' element. To populate these two elements, information should be specified in the 'Organization number' (CORG), and 'Organization number 2' (COR2) fields.

This table shows how the information should be specified on (CRS610/J) if the customer is a member of a group:

Information Setup Element in XML file
Tax number of group member (individual tax number of customer) Field CORG on (CRS610/J) groupMemberTaxNumber
Group identification number Field COR2 on (CRS610/J) customerTaxNumber
Note: If the customer is not a member of a group, the individual tax number of the customer should be specified in the 'Organization number 2' field (COR2), to populate the 'customerTaxNumber' element. This element is always populated with the information in the COR2 field, regardless of whether the customer is a member of a group.

To indicate that a certain customer number is a member of a group, and should be reported accordingly, setup is made in 'Business Message Data Translation. Displ' (CRS881) and 'Business Message Data. Translate' (CRS882). This setup is made per division.

Run online invoicing once through (AAS395) to automatically create the header record for translation in (CRS881). After this first run, identify the 'groupMemberTaxNumber' element in (CRS881), which holds the following values:

Description Field Value
Message standard MSTD M3BE
Version MVRS 1
Message BMSG HU-TaxAuthAuditData
I/O IBOB O
Parent element(s) ELMP groupMemberTaxNumber
Data element ELMD customer

To define the customer numbers for which this should apply, use related option 11='Translate' in (CRS881) to open (CRS882). In (CRS882) you specify the setup.

This table shows how the setup can be specified:

Description Field Value
External partner EXTP Blank
M3 data MVXD Applicable customer number
Message data MBMD Blank

If the customer number is found as M3 data in (CRS882), this indicates that the customer is a member of a group, and that 'customerTaxNumber', as well as 'groupMemberTaxNumber', elements should be populated for this specific customer number.

VAT codes

The tag 'lineVatRate', contains four different elements, but only one of them should be created. The setup for different VAT codes in (CRS881) and (CRS882) for three of the four elements determines which one to populate based on the VAT code of the transaction. This setup is made per division.

If a translation exists for the current VAT code in (CRS882) for any of those three elements, that element is included in the XML file.

If no translation exists for the VAT code under any of these three elements in (CRS882), the 'vatPercentage' element is included in the XML file.

'vatExemption' element

If the VAT code for the VAT transaction for the voucher in the general ledger exists in (CRS881) and (CRS882) for this element, this indicates VAT exemption. Then the VAT exemption text is retrieved from (CRS882). If this does not exist, this element is not created.

Run online invoicing once through (AAS395) to automatically create the header records for translation in (CRS881). After this first run, identify the 'vatExemption' element in (CRS881), which holds the following values:

Description Field Value
Message standard MSTD M3BE
Version MVRS 1
Message BMSG HU-TaxAuthAuditData
I/O IBOB O
Parent element(s) ELMP zaradekok
Data element ELMD adoment_hiv

To define the translation for the applicable VAT codes, use related option 11='Translate' in (CRS881) to open (CRS882). In (CRS882) you specify the setup.

This table shows how the setup can be specified:

Description Field Value
External partner EXTP Blank
M3 data MVXD VAT code
Message data MBMD VAT exemption text (40 characters)
Note: The VAT codes should be specified without leading zeros. For example, if VAT code 02 is used, specify 2.

This table shows an example of a setup:

Line in (CRS882) M3 data Message data
1 99 VAT exemption text in CRS882

In this example, a VAT transaction for VAT code 99 results in the 'vatExemption' element being created under the tag 'lineVatRate'. The element is populated with the text 'VAT exemption text in CRS882'.

'vatOutOfScope' element

If the VAT code for the VAT transaction for the voucher in the general ledger exists in (CRS881) and (CRS882) for this element, this indicates VAT out of scope. The element is then specified as 'true'. If this does not exist, this element is not created.

Run online invoicing once through (AAS395) to automatically create the header records for translation in (CRS881). After this first run, identify the 'vatOutOfScope' element in (CRS881), which holds the following values:

Description Field Value
Message standard MSTD M3BE
Version MVRS 1
Message BMSG HU-TaxAuthAuditData
I/O IBOB O
Parent element(s) ELMP vatOutOfScope
Data element ELMD vatCode

To define the translation for the applicable VAT codes, use related option 11='Translate' in (CRS881) to open (CRS882). In (CRS882) you specify the setup.

This table shows how the setup can be specified:

Description Field Value
External partner EXTP Blank
M3 data MVXD VAT code
Message data MBMD Blank
Note: The VAT codes should be specified without leading zeros. For example, if VAT code 02 is used, specify 2.

This table shows an example of a setup:

Line in (CRS882) M3 data Message data
1 98 Blank

In this example, a VAT transaction for VAT code 98 results in the 'vatOutOfScope' element being created under the tag 'lineVatRate'. The element is specified as 'true'.

'vatDomesticReverseCharge' element

If the VAT code for the VAT transaction for the voucher in the general ledger exists in (CRS881) and (CRS882) for this element, this indicates VAT domestic reverse charge. The element is then specified as 'true'. If this does not exist, this element is not created.

Run online invoicing once through (AAS395) to automatically create the header records for translation in (CRS881). After this first run, identify the 'vatDomesticReverseCharge' element in (CRS881), which holds the following values:

Description Field Value
Message standard MSTD M3BE
Version MVRS 1
Message BMSG HU-TaxAuthAuditData
I/O IBOB O
Parent element(s) ELMP zaradekok
Data element ELMD ford_ado

To define the translation for the applicable VAT codes, use related option 11='Translate' in (CRS881) to open (CRS882). In (CRS882) you specify the setup.

This table shows how the setup can be specified:

Description Field Value
External partner EXTP Blank
M3 data MVXD VAT code
Message data MBMD Blank
Note: The VAT codes should be specified without leading zeros. For example, if VAT code 02 is used, specify 2.

This table shows an example of a setup:

Line in (CRS882) M3 data Message data
1 97 Blank

In this example, a VAT transaction for VAT code 97 results in the 'vatDomesticReverseCharge' element being created under the tag 'lineVatRate'. The element is specified as 'true'.

CsK codes

Invoice lines in 'Invoice. Display Lines' (OIS351) for external line charges (IVTP 67) are normally included in the invoice line reported for the item line (IVTP 31), to which the line charge is connected. This only applies to eco charges, not for other line charges. Eco charges can be identified by being defined as 'csk' in (CRS881) and (CRS882). Other external line charges should be reported separately as separate lines in the XML file.

This is applicable to customer order invoices (OIS350), and internal invoices (MFS100), if linked to a customer order invoice with such charges. Translations are defined per division.

Run online invoicing once through (AAS395) to automatically create the header record for translation in (CRS881). After this first run, identify the 'vissz_igenytetel' element in (CRS881), which holds the following values:

Description Field Value
Message standard MSTD M3BE
Version MVRS 1
Message BMSG HU-TaxAuthAuditData
I/O IBOB O
Parent element(s) ELMP vissz_igenytetel
Data element ELMD csk

To define the translation for the applicable external line charge IDs, use related option 11='Translate' in (CRS881) to open (CRS882). In (CRS882) you specify the setup.

This table shows how the setup can be specified:

Description Field Value
External partner EXTP Blank
M3 data MVXD ID of external line charge (defined in CRS275)
Message data MBMD Could contain 'csk' code defined by Hungarian tax authority

This table shows an example of a setup:

Line in (CRS882) M3 data Message data
1 CVB2 E112297
2 MBLN1 E112233

In this example, the two external line charges (defined as 'csk' in (CRS882)) are included in the amounts reported for the item line (IVTP 31) (elements 'lineNetAmount', 'lineVatAmount', and 'lineGrossAmountNormal'). All other external line charges (not defined as 'csk' in (CRS882)) are reported separately, with separate line numbers in the report.

Translation of line description

For each line in the XML file, a line description is included in element 'lineDescription'. If there is a translation available for language 'HU', that translation is retrieved. Otherwise the standard description is retrieved to the XML file.

Related topics