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

Outcome

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

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

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

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

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

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

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

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

  9. 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'.

  10. 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:

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.

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:

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

Related topics