Online Invoicing Processing

Online invoicing is performed in 'Online Invoicing Transactions. Open' (AAS390), through which XML files are created for customer invoice transactions for transfer to the tax authorities.

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. The functionality for online invoicing has been developed to fulfill this requirement, as well as similar requirements from other countries in the future.

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

Limitations

This functionality is currently only available for reporting to the tax authorities in Hungary.
The Local.ly tool, the "Tax Connector", is needed for data transfer from M3 Business Engine to the tax authorities. This tool is currently only available for Hungary.
In M3 Business Engine releases 15.1.3 and 15.1.4, an FBM is available for data transfer from the Hungarian tax authorities to M3 BE, for update of the status of the invoice based on the result of the authorities' validation of the XML file. Currently, there is no corresponding solution for M3 Business Engine Cloud Edition for handling of such responses from the authorities. However, a manual update of the invoice status can be done using the API AAS390MI, transaction UpdInvStatus.
Only customer invoices created in the following functions are included in online invoicing:
- 'CO Invoice. Print' (OIS180) (FAM function OI20)
- 'Customer Invoice. Enter' (ARS100) (FAM function AR10)
- 'Customer Invoice. Enter Manual' (ARS120) (FAM function AR20)
- 'Fixed Asset. Sell' (FAS130) (FAM function FA50)
- 'Internal Invoice. Create' (MFS100) (FAM function MF01)
- 'Maint Invoice. Print' (COS180) (FAM function CO20)
- 'Project Invoice. Print' (POS180) (FAM function PO20)
- 'SO Invoice. Print' (SOS180) (FAM function SO20)
Other customer invoice records, created through other functions, are not included in online invoicing to the tax authorities.
Only one customer invoice per voucher number can be handled in online invoicing. Customers using the functionality for online invoicing should therefore avoid using the following functionality:
Corrective method 2='Credit all lines' for corrective invoices in 'Customer Invoice. Enter Manual' (ARS120), through which both a credit note and a new debit invoice are created using the same voucher number.
Invoices cancelled through 'Voucher. Reverse' (GLS900) are not included in online invoicing.
Rental invoices in a scenario where a deposit has been paid, are accepted by the authorities but with a warning. The collected deposit is used when paying rental invoices, meaning that the rental charge amount is deducted from the collected deposit. The warning given is because the collected deposit is always without VAT and the rental amount deducted from the deposit will charge for VAT. The total amount of the rental invoice is 0.

Outcome

An invoice that fulfills the prerequisites for online invoicing is reported to the tax authorities through an XML file that is created directly when the invoice is issued. Invoices that do not fulfill the prerequisites for online invoicing are not reported to the tax authorities.
The XML file is validated against the schema published by the tax authorities.
The XML file is sent to the tax authorities by Local.ly.
Invoices that fulfill the prerequisites for online invoicing are listed in 'Online Invoicing Transactions. Open' (AAS390).
Invoices that have been processed for online invoicing through (GLS040), get status 20='XML file created automatically' in (AAS390).
Invoices that have been manually added in (AAS390), get status 15='Validated manually' in (AAS390).
Invoices for which an XML file has been manually created through related option 9='Create XML-file' in (AAS390), get status 25='XML file created manually' in (AAS390).
When Local.ly has sent the XML file to the tax authorities, the status of the invoice can be set to 30='XML file sent' in (AAS390).
When the tax authorities have validated the XML file, the status of the invoice can be set to 90='XML file accepted' in (AAS390), if the validation is successful. If an error is found in the XML file content, the status of the invoice can be set to 40='XML file rejected'. If the XML file is accepted, but with warnings, the status of the invoice can be set to 80='XML file accepted with warnings'.
If an XML file has been technically annulled on the tax authority's portal, the status of the invoice can be set to 50='XML file annulled' in (AAS390).

Before you start

The most important settings used for online invoicing are described in this section.

Settings for online invoicing

In 'Settings – Online Invoicing' (AAS900), settings are defined for online invoicing. The setup is made per country code, referring to the country in which the online invoicing is to be reported to the tax authorities.

The settings for online invoicing are stored in the FONINS table (Online invoicing settings).

Note: Currently, it is only possible to do this setup for Hungary (for country codes defined with ISO code 'HU' or 'HUN' in 'Country. Open' (CRS045)). Further information about the settings in (AAS900) for Hungary are available.

See Online Invoicing Processing for Hungary.

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.

Settings for customer order invoicing

Each invoice must have a separate voucher number in the general ledger. To achieve this, the parameter 'Sep voucher no' must be enabled in 'Settings – Customer Order Invoicing' (CRS722).

As online invoicing reports should be created immediately at the issuing of the invoice, it is recommended that the parameter 'Direct to FIM' is enabled in (CRS722) instead of using 'CO Invoice. Post-Process' (OIS196) for the update of the general ledger and accounts receivable.

AR Additional Information

In 'AR Additional Information. Update' (ARS950) use F14='Standard' to regenerate the standard list of available additional information numbers. Thereby, new additional information numbers will be displayed in the list.

Follow these steps

Define settings for online invoicing in 'Settings – Online Invoicing' (AAS900) for the country code defined for the country for which online invoicing is to be used.
Issue a customer invoice through one of the FAM functions enabled in (AAS900), for example, through 'CO Invoice. Print' (OIS180) (FAM function OI20). If the invoice fulfills the prerequisites for online invoicing, an XML file is created in the MvxFileTransfer folder (or the sub folder defined in (AAS900)), and the invoice displayed in 'Online Invoicing Transactions. Open' (AAS390).
Use option 5='Display' in (AAS390) to display the details of an invoice, for example, the customer, the invoice date, the invoice amount, the total VAT amount expressed in the base country currency, the file name of the XML file, and the status of the invoice, which reflects the processing of the XML file.
If needed, the API AAS390MI, transaction UpdTransID, can be used manually, or by the FBM, to update field 'Transaction ID' (TRNI) for the invoice in (AAS390), based on feedback from the tax authorities. The 'Transaction ID' can be an identification number that is used when communicating with the tax authorities.
To create an XML file for an invoice that has already been issued, the invoice is first added in (AAS390) using option 1='Create', and then related option 9='Create XML-file' is used to create the XML file.
Through using the API AAS390MI, transaction UpdInvStatus, the status of the invoice in (AAS390) can be updated as follows:
- When Local.ly has sent the XML file to the tax authorities, the status of the invoice is set to 30='XML file sent' in (AAS390) by setting the 'Message indicator' (input field BSBF) to 'RECEIVED' or 'PROCESSING'.
- When the tax authorities have validated the XML file, the status of the invoice can be set to 90='XML file accepted' in (AAS390), if the validation is successful, by setting the 'Message indicator' (input field BSBF) to 'DONE'.
- If an error is found in the XML file content, the status of the invoice can be set to 40='XML file rejected' by setting the 'Message indicator' (input field BSBF) to 'ABORTED', and by entering the error code in 'Blocking Validation Error Code' (input field BVEC).
- If the XML file is accepted, but with warnings, the status of the invoice can be set to 80='XML file accepted with warnings' by setting the 'Message indicator' (input field BSBF) to 'DONE', and by entering the warning code in 'Blocking Validation Error Code' (input field BVEC).
If needed, related option 9='Create XML-file' can also be used in (AAS390) to recreate the XML file for an invoice for which the XML file has been rejected by the tax authorities, or accepted with warnings.
If needed, related option 8='Raise status to XML file accepted' can be used in (AAS390) to change status of an invoice from 80='XML file accepted with warnings' to 90='XML file accepted', when the cause of the warning has been settled with the authorities.
In case of a technical annulment of an XML file on the tax authority's portal, related option 7='Set status to XML file annulled' can be used in (AAS390) to change status of an invoice to 50='XML file annulled'.
If needed, option 4='Delete' can be used to delete a selected invoice in (AAS390). This is only allowed for:
- Invoices that have been manually added in (AAS390), but for which the XML file has not yet been created.
- Invoices for which the XML file has been rejected.
- Invoices for which the XML file has been technically annulled
- Invoices for which the XML file has been accepted, or accepted with warnings.

Solution overview

The illustration shows an overview of the processing of the XML files created for online invoicing and of the programs and tables used in the functionality for online invoicing.

Processing batch jobs for invoice data

As the invoice data is required to be reported immediately (not in batches on a daily, weekly, or monthly basis), the job in (GLS040) is used to trigger this reporting for all jobs that process customer invoice records (with TRCD=10).

The (GLS040) job creates a record in work table FONINW (Online invoicing work table) for each customer invoice that is being processed if the following are fulfilled:

Settings are found in (AAS900) for the base country code of the invoice
The voucher number is not equal to zero
The program name is not 'GLS900' (used for reversal of vouchers)
The FAM function of the customer invoice is one of the FAM functions selected in (AAS900) for the base country code.

If a record has been added to work table FONINW, (GLS040) submits a separate batch job (AAS395) for further processing. The batch job validates the customer invoice against the prerequisites, for example, that the VAT amount is equal to, or exceeds, the VAT amount limit defined in (AAS900). If the invoice meets the prerequisites, a new record is created in transaction table FONINT (Online invoicing transactions), an XML file name is created, and (AAS391) is called for the creation of the XML file content.

The XML file name consists of company number (CONO), division number (DIVI), base country code (BSCD), job number (BJNO), transaction number (TRNO), and ends with '.xml'. For example,136510HU_1234567890123456780000001.xml

(AAS391) is used to retrieve the content of the XML file from different tables in M3 BE, depending on the origin of the customer invoice. See Online Invoicing Processing XML Structure for Hungary for further details on the structure of the XML file. One XML file is created per customer invoice and the XML file is placed in the MvxFileTransfer folder selected in (AAS900).

Local.ly continuously monitors the MvxFileTransfer folder, and when an XML file is found in the folder, it is automatically sent to the tax authorities.

Online invoicing transactions in (AAS390)

The invoices that meet the prerequisites for online invoicing, and have been added to transaction table FONINT, are listed in 'Online Invoicing Transactions. Open' (AAS390). In (AAS390), option 5='Display' can be used to display the details of an invoice, for example, the customer, the invoice date, the invoice amount, the total VAT amount expressed in the base country currency, the file name of the XML file, and the status of the invoice, which reflects the processing of the XML file. The status of the invoices is automatically updated during the online invoicing processing, or updated via the API AAS390MI, transaction UpdInvStatus. The statuses set during the process flow are further described below.

In (AAS390), the user can also use related option 11='Display invoices' to open 'Customer Invoice. Display Separate' (ARS215), where all transactions for the selected invoice are displayed, both the invoice transaction, and payment transactions, if any.

The invoices in (AAS390) can have the following statuses:

10 – Validated automatically

15 – Validated manually

20 – XML file created automatically

25 – XML file created manually

30 – XML file sent

40 – XML file rejected

50 - XML file annulled

80 – XML file accepted with warnings

90 – XML file accepted

When an invoice has been found to meet the prerequisites and is written to transaction table FONINT by (AAS395), the status is set to 10='Validated automatically'. After that, the XML file is created automatically by (AAS391), and then the status is set to 20='XML file created automatically' and the XML file name is added to the invoice record in transaction table FONINT. The statuses 30='XML file sent', 40='XML file rejected', 80='XML file accepted with warnings', and 90='XML file accepted' can be updated via the API AAS390MI, transaction UpdInvStatus, during the communication between Local.ly and the tax authorities.

When Local.ly has sent the XML file to the tax authorities, the authorities send a response saying that the XML file has been received. At this stage, the API AAS390MI, transaction UpdInvStatus, can be used to update the invoice in transaction table FONINT to status 30='XML file sent'.

If needed, the API AAS390MI, transaction UpdTransID, can be used manually, or by the FBM, to update field 'Transaction ID' (TRNI) for the invoice in (AAS390), based on feedback from the tax authorities. The 'Transaction ID' can be an identification number that is used when communicating with the tax authorities.

When the contents of the XML file have been validated by the authorities, they send another response. Also, at this stage, the API AAS390MI, transaction UpdInvStatus, can be used to update the invoice in transaction table FONINT. If the contents of the XML file are correct, the status of the invoice is raised to 90='XML file accepted'. If an error has been found in the contents, the status is set to 40='XML file rejected', and the field 'Block error cde' (BVEC) updated with a 'blocking validation error code' that informs the user of the cause of the rejection. If the XML file is accepted by the authorities, but with warnings, the status is set to 80='XML file accepted with warnings' and the field 'Block error cde' (BVEC) updated with a warning code that informs the user the cause of the warning. When the cause of the warning has been settled with the authorities, the user can manually raise the status of the invoice to 90='XML file accepted' by using option 8='Raise status to XML file accepted' in (AAS390).

In case of a technical annulment of an XML file on the tax authority's portal, related option 7='Set status to XML file annulled' can be used in (AAS390) to change status of an invoice to 50='XML file annulled'.

In (AAS390), the user can use option 1='Create' to manually add an invoice for online invoicing processing. This can be useful, for example, if the invoice was created before this functionality was implemented, but the user would still like to report the invoice to the tax authorities. When an invoice is manually added in (AAS390), the same validations are made, as if the invoice would have been automatically added through the workflow in (GLS040). In this situation, the status of the invoice is set to 15='Validated manually'. The validations made to decide whether an invoice should be included in online invoicing or not, are further described in chapter 'Validation of invoices'.

If needed, the user can use related option 9='Create XML-file' in (AAS390) to manually start the creation of the XML file for a selected invoice. This can be used for the creation of an XML file for a manually added invoice. It can also be used to recreate the XML file for an invoice for which the XML file has been rejected by the tax authorities or accepted with warnings. If the XML file creation has been started manually in (AAS390), the status of the invoice is set to 25='XML file created manually'.

If a problem occurs when the XML file is being sent to the authorities, for example during processing in the Local.ly tool, then the invoice record will be stuck in status 20, or 25, in (AAS390). As it is not allowed to recreate the XML file, with related option 9='Create XML file', in (AAS390) when the invoice record is in status 20, or 25, the invoice cannot be processed any further. In this situation, related option 23='Reset status' can be used to reset the status of the invoice record to 15='Validated manually', which will then allow the user to recreate the XML file for the invoice. Related option 23='Reset status' is allowed for invoice records in status 20, 25, and 50.

The user can use option 4='Delete' to delete a selected invoice in (AAS390). However, you can only delete an invoice that is in status 15='Validated manually', 40='XML file rejected', 50='XML file annulled', 80='XML file accepted with warnings', or 90='XML file accepted', as an invoice that is being processed for online invoicing must exist in transaction table FONINT. Otherwise, the XML file cannot be created, and the file name cannot be added to the invoice record.

Validation of invoices

Only invoices that meet the prerequisites for online invoicing, are included in the online invoicing processing. The validations made, 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, are listed below.

Settings must exist for the current division in the settings program (AAS900). If not, online invoicing is not used in the current division.
Settings must exist in the settings program (AAS900) for the base country code of the customer invoice. If not, online invoicing is not used for that country in the current division.
Voucher number must not be 0. Voucher number 0 indicates cancellation of the voucher in (GLS120), and such vouchers are not included in online invoicing.
Program name (PGNM) must not be 'GLS900'. Program name 'GLS900' indicates reversal of the voucher in (GLS900), and reversed invoices are not included in online invoicing.
Batch number (BCHN) must not be 0. Each voucher number (each invoice number) gets a separate batch number in work table FCR040 during processing of the job in (GLS040). The batch number is later used as transaction number (TRNO) in tables FONINW and FONINT. The batch number is also included in the file name to make the XML files unique, even in the situation where there is more than one customer invoice included in the job in (GLS040).
FAM function must be one of the supported FAM functions for online invoicing. Only FAM functions AR10, AR20, CO20, FA50, MF01, OI20, PO20 and SO20 are supported for online invoicing.
The invoice must not already exist in transaction table FONINT for the current job number. This control is needed when a job is restarted from 'Trans Work File. Restart Interrupted Jobs' (GLS047) or 'Trans Work File. Restart Erroneous Jobs' (GLS037).
The invoice must exist in the general ledger and in accounts receivable. The invoice is updated in tables FGLEDG and FSLEDG first by (GLS040), before (AAS395) is called. (AAS395) retrieves information from both these tables, when the invoice is added to transaction table FONINT and when the XML file is created.
VAT information must exist for the invoice in the general ledger.
(AAS395) and (AAS391) retrieves VAT information from the voucher in the FGLEDG table. This information is used both for the validation of the invoice against the setup in (AAS900), and for the population of the elements in the XML file. This information concerns VAT amounts, VAT percentages, VAT base amounts, VAT registration numbers etcetera. Primarily, the VAT information is retrieved from the VAT transactions, identified by having transaction code (TRCD) 11 and VAT account types (AT04) 1 or 2. If no such VAT transaction can be found for the voucher in the general ledger, the VAT information is retrieved from the revenue transactions, identified by having transaction code (TRCD) 11 and VAT account types (AT04) 3-9.

If a customer invoice is manually added on (AAS390/B), all the validations above are made, just as for an invoice that is automatically added through (GLS040). However, there are the following differences:

To determine if the invoice has been reversed or not, additional information in table FGLEDX is checked for the invoice transaction with transaction code (TRCD) 10. If GL additional information categories 025 or 036 are found, this indicates that the invoice has been reversed.
If the invoice already exists in transaction table FONINT, it is still possible to add it manually in (AAS390), but a warning message is displayed on (AAS390/E).

Corrective invoices

A corrective invoice can be created in, for example, CO Invoice. Correct or Credit' (OIS380) reached through related option 14='Corr/Credit' in 'Invoice. Display' (OIS350), and in 'Customer Invoice. Enter Manual' (ARS120). If corrective method 1 is used, only one corrective invoice is created, containing the correction of the original invoice. If corrective method 2 is used, two corrective invoices are created: a credit note reversing the original invoice, and a new debit invoice.

For corrective invoices created through corrective method 1, AR additional information category 235 holds information about the original invoice number and original invoice year. Similarly, for the original invoice, AR additional information category 236 holds information about the corrective invoice number and corrective invoice year.

For corrective invoices created through corrective method 2, both the credit note and the new debit invoice hold information about the original invoice number and original invoice year in AR additional information category 235. The original invoice is updated with a reference to both the credit note, which has reversed the original invoice, and the new debit invoice, in AR additional information category 236. This means that there will be two occurrences of this additional information category for the original invoice.

Note: If corrective method 2 is used in (ARS120), both the credit note and the new debit invoice are posted on the same voucher number, which is not supported by the functionality for online invoicing. Therefore, this method should not be used in (ARS120) by customers using the functionality for online invoicing. However, in (OIS380), corrective method 2 creates two voucher numbers, so this function can be used by all customers.

A credit note can for example be created in (ARS120), or through a credit order in 'Customer Order. Open' (OIS100). By referring to the original invoice number and year on, for example (ARS120/E) or (OIS100/G), a reference to the original invoice can be created for the credit note in AR additional information category 255. In that case, the original invoice holds information about the credit note, and year of the credit note, in AR additional information category 256.

To find 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 corrective invoice is included in online invoicing, information about the original invoice number, and original invoice year, is updated in fields OIVR and OINY in transaction table FONINT, and is displayed on panel (AAS390/E).

Split due date

If the payment term used has been set up for split due date, more than one invoice is created in accounts receivable when the invoice is issued in, for example, 'CO Invoice. Print' (OIS180). In this situation, those invoices should be reported together, as one invoice, in the XML file. To identify the initial invoice number, AR additional information category 228 in (ARS216) is used.

Example: The payment term has been defined for split due date in 'Payment Term. Open' (CRS075) by enabling the parameter 'Split due date'.

Per the setup in 'Payment Term. Open Details' (CRS074), the invoices are divided into two parts, with 70 and 30 percent of the invoice amount, respectively. The first part is due on 15 days after the invoice date, and the second part is due 30 days after the invoice date.

A customer order is invoiced in (OIS180), using this payment term, and invoice 2018100000021 can then be found in 'Invoice. Display' (OIS350).

When updated in accounts receivable, two invoices have been created, with invoice numbers retrieved from invoice number series 4 in 'Internal Invoice Series. Open' (MFS165): 9999999900040 and 9999999900041, in accordance with the setup of the payment term in (CRS075).

Both these invoices refer to the initial invoice number in AR additional information category 228.

In the XML file, the total of these two invoices should be reported, and the invoice number used for reporting, should be the initial invoice number 2018100000021 displayed in (OIS350).

Note: Both these invoices are posted on the same voucher number. That, and the fact that the initial invoice number does not exist in accounts receivable, makes it impossible to manually add an invoice with split due date in (AAS390). Therefore, the original invoice record for such an invoice in (AAS390) should not be removed. Instead, if an XML file for an invoice with split due date needs to be recreated, the status of the invoice should first be reset to 15='Validated manually' with related option 23='Reset status' in (AAS390), and then the XML file can be recreated with related option 9='Create XML file'.

Reversed invoices

In accounts receivable, only invoice transactions with transaction code (TRCD) 10 are read by (AAS395). In case more than one transaction with TRCD=10 is found for an invoice number, the invoice is cancelled and is not be included in the XML report.

If the invoice is processed via (GLS040), reversed invoices can be identified through program name 'GLS900' in field PGNM in table FCR040.

If the invoice is processed via option 1='Create' in (AAS390), GL additional information categories 025 and 036 are checked. The original invoice record (TRCD=10) holds GL additional information category 025, with a reference to the reversal voucher number. The reversal invoice record (TRCD=10) holds GL additional information category 036, with a reference to the original voucher number. If either of these GL additional information categories exist, it is not possible to add the invoice in (AAS390).