Online Invoicing Processing for Hungary

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:

• Settings must exist in the settings program (AAS900) for a country code defined with ISO code 'HU' or 'HUN' on (CRS045/E). If not, online invoicing is not used for Hungary in the current division.
• FAM function must be one of the enabled FAM functions in the settings program (AAS900). You decide which of the supported FAM functions should be included in online invoicing, by selecting the check boxes on (AAS900/E).
• The country code used as base country code (BSCD) and from/to country code (FTCO) for the invoice must be defined with ISO code 'HU' or 'HUN' on (CRS045/E). This indicates that the invoice has been sent from Hungary to Hungary, indicating a domestic sale.
• Tax number must exist for the customer. Primarily, organization number 2 (COR2) is verified. If COR2 is not populated on 'Customer. Open' (CRS610/J), the VAT registration number (VRNO) is verified. VRNO is retrieved from the VAT transaction for the invoice in FGLEDG. If VRNO starts with 'HU', then that indicates that it is a Hungarian VAT registration number, which is accepted. If that is not the case, and COR2 is not populated, the invoice is not qualified to be included in online invoicing for Hungary.
• Total VAT amount in HUF for the invoice must be equal to, or exceed, the VAT amount limit defined on (AAS900/E). The total VAT amount in HUF is calculated based on all VAT transactions (with TRCD=11 and AT04 = 1 or 2) for the voucher in the FGLEDG table. If the total VAT amount in HUF is equal to, or exceeds, the VAT amount limit defined in (AAS900), then the invoice is included in online invoicing for Hungary. If the invoice is a corrective invoice, the total VAT amount in HUF considers not only the corrective invoice, but also the original invoice and any other corrective invoice that has affected the original invoice before. If the original invoice has previously been included in online invoicing, and thus can be found in (AAS390), the corrective invoice is also included in online invoicing, regardless of the total VAT amount in HUF.
• If a customer invoice is manually added on (AAS390/B), all the validations are carried out just as for an invoice that is automatically added through (GLS040). However, there is one difference: If the VAT amount of the invoice is not equal to, or exceeds, the VAT amount limit defined in (AAS900), you can still add it manually in (AAS390), but a warning message is displayed on (AAS390/E).

Corrective invoices and validation of VAT amount

Original invoice:

• If the VAT amount is less than the amount limit defined in (AAS900), the XML file is not created.
• If the VAT amount is equal to, or greater than, the amount limit defined in (AAS900), the XML file is created.

Corrective invoice:

• If the original invoice has been reported before (it exists in FONINT transaction table), the XML file is created for the corrective invoice, regardless of the accumulated VAT amount.
• If the original invoice has not been reported before (it does not exist in FONINT transaction table), the accumulated VAT amount of the original invoice and the corrective invoice must be verified. If that amount is equal to, or greater than, the amount limit defined in (AAS900), the XML file is created for the 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:

• Original invoice: 2018100000015
• Corrective invoice 1: 9999999900033
• Corrective invoice 2: 9999999900039

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:

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).

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:

• Information about the issuer of the invoice is included under 'supplierInfo', and retrieved from 'Company. Connect Division' (MNS100).
• Information about the receiver of the invoice is included under 'customerInfo', and retrieved from 'Customer. Open' (CRS610).
• Information about the fiscal representative (if any) is included under 'fiscalRepresentativeInfo', and retrieved from 'Supplier. Connect Address' (CRS622).

  Primarily, address type 01 is used. If this does not exist, address type 02 is used instead. If none of these address types exist in (CRS622), the supplier name is retrieved from field 'SUNM' in 'Supplier. Open' (CRS620) and no address information is included in the XML file for the fiscal representative.

This table shows how the information is retrieved by default:

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:

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:

• 'COMP' for a translation of the name of the company
• 'CUST' for a translation of the name of the customers
• 'SUPP' for a translation of the name of the fiscal representative.

Message data is set to:

• 1 to include address field 1
• 2 to include address field 2
• 3 to include address field 3
• 4 to include address field 4

This table shows how the setup can be specified:

This table shows an example of a setup:

• When no company translation is defined for 'COMP', 'supplierName' is retrieved from field CONM in (MNS100), which is the default.
• When the message data for 'CUST' is set to include address field 1, 'customerName' is retrieved from fields CUNM and CUA1 in (CRS610).
• When the message data for 'SUPP' is set to include address field 1, 'fiscalRepresentativeName' is retrieved from fields SUNM and ADR1 in (CRS622).

'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:

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:

• 'COMP' for a translation of the city of the company
• 'CUST' for a translation of the city of the customers
• 'SUPP' for a translation of the city of the fiscal representative.

Message data is set to:

• 1 to include address field 1
• 2 to include address field 2
• 3 to include address field 3
• 4 to include address field 4

This table shows how the setup can be specified:

This table shows an example of a setup:

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

• When the message data for 'COMP' is set to include address field 2, 'city' is retrieved from field COA2 in (MNS100).
• When the message data for 'CUST' is set to include address field 4, 'city' is retrieved from field CUA4 in (CRS610).
• When the message data for 'SUPP' is set to include address field 3, 'city' is retrieved from field ADR3 in (CRS622).

'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:

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:

• 'COMP' for a translation of the address details of the company
• 'CUST' for a translation of the address details of the customers
• 'SUPP' for a translation of the address details of the fiscal representative.

Message data is set to:

• 1 to include address field 1
• 2 to include address field 2
• 3 to include address field 3
• 4 to include address field 4

This table shows how the setup can be specified:

This table shows an example of a setup:

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

• When the message data for 'COMP' is set to include address field 1, 'additionalAddressDetail' is retrieved from field COA1 in (MNS100).
• When the message data for 'CUST' is set to include address field 2 and 3, 'additionalAddressDetail' is retrieved from fields CUA2 and CUA3 in (CRS610).
• When the message data for 'SUPP' is set to include address field 2, 'additionalAddressDetail' is retrieved from field ADR2 in (CRS622).

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:

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:

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:

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:

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:

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:

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:

This table shows an example of a setup:

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:

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:

This table shows an example of a setup:

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:

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:

This table shows an example of a setup:

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:

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:

This table shows an example of a setup:

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.

• Item description

  If the item name and description exist for language 'HU' in 'Item. Enter Names/Language' (MMS030), these are retrieved as the item description for the invoice line in element 'lineDescription' in the XML file. Otherwise, the item description is retrieved as follows:

  • For customer order invoices the item description is retrieved from the item name on the customer order line in 'Customer Order. Open Line' (OIS101)
  • For internal invoices and maintenance order invoices the item description is retrieved from the item master in 'Item. Open' (MMS001)
  • For service order invoices the item description is retrieved from the item name on the service order line in 'Service Order. Open Line' (SOS120)
  • For project order invoices the item description is retrieved from the item name on the project order invoice line in 'Project Invoice. Update Line' (POS481).
• Header charge description

  If the header charge description of the customer order exists for language 'HU' in 'CO Charge. Enter Names/Language' (OIS029), this is retrieved as the description for the invoice line in element 'lineDescription' in the XML file. Otherwise, the header charge description is retrieved as follows:

  • For customer order invoices and maintenance order invoices the description is retrieved from 'CO Charge. Open' (OIS030)
  • For rental invoices the description is retrieved from 'Rental Agreement. Connect Charges' (STS113)
  • For service order invoices the description is retrieved from 'Service Order. Connect Charges' (SOS103)
  • For project order invoices the description is retrieved from 'Project Invoice. Connect Charges' (POS487)
• Service charge description

  If the service charge description of the customer order exists for language 'HU' in 'Service Charge. Enter Names/Lang' (OIS033), this is retrieved as the description for the invoice line in element 'lineDescription' in the XML file. Otherwise the description is retrieved from 'Service Charge. Open' (OIS031).

• Line charge description

  If the order line charge description of the customer order exists for language 'HU' in 'Order Line Charge. Enter Names/Language' (CRS276), this is retrieved as the description for the invoice line in element 'lineDescription' in the XML file. Otherwise the description is retrieved from 'Order Line Charge. Open' (CRS275).