Create Finance Interface Template
This document describes how to create an interface template in 'FIM Interface. Open' (GLS850) for importing financial transactions in M3 Business Engine (BE). The interface solution allows General Ledger, Accounts Payable, and Accounts Receivable transactions to be imported into the general ledger.
The interface is used as a tool to transfer initial balances or open items (AR/AP) or, periodically, GL transactions such as payroll transactions. Also, customer invoices issued by another system can be imported using this function. The interface is not meant to be used for processing AR payment transactions, except in special cases with some limitations. Nor is it meant to be used to transfer supplier invoices on a regular basis.
For processing customer payments, we recommend that 'Bank Statement. Open' (ABS100) is used instead. For processing supplier invoices, we recommend that 'Supplier Invoice Batch. Open' (APS450) with line type 8=’Accounting line’, is used when possible.
A usage type must be selected for each interface that is set up in (GLS850). The usage type controls how the transactions are uploaded and processed in M3 BE, as well as the type of transactions that can be imported through the interface (interface type). Three usage types are available for the interface templates in (GLS850).
Usage type | Interface type | Method to import the transactions |
---|---|---|
0-MvxFileTransfer |
General ledger vouchers Customer invoices Customer payments (not recommended, see explanation above) Supplier invoices (not recommended, see explanation above |
The transactions are uploaded through (GLS850) and a positioned based text file located in the folder used for file transfer. |
1-Positioned-based API |
General ledger vouchers Customer invoices Customer payments (not recommended, see explanation above) Supplier invoices (not recommended, see explanation above) |
The transactions are uploaded in (GLS840)/(GLS841) through the positioned based API transaction GLS840MI/AddBatchLine. |
2-Field-based API | General ledger vouchers | The transactions are uploaded in (GLS840)/(GLS842) through the field based API transaction, GLS840MI/AddBatchLineFld. |
Usage type 0 and 1 are using a positioned based solution. This requires that from and to positions are defined for each type of input data in the interface template. The data for each voucher line is then entered as a long string in the text file or one 900-character input field in the API transaction. Usage type 2 does not require any from and to positions to be defined in the template since the API transaction has an assigned input field for each type of data.
Create an interface template for usage type 2-'Field-based API'
Usage type 2-'Field-based API' is used for uploading general ledger (GL) vouchers through GLS840MI (Generic GL interface). The API transaction used to upload the lines for this usage type has an assigned input field for each type of data, compared to usage type 1 where the data for each line is entered in one 900-long input field.
Before you start
- Define the interface requirements.
- The financial system must be configured. For details, see Enabling Financial Management.
- Journal number series are defined for the current year in 'Journal Number Series. Open' (CRS400).
- FAM function GL01 with at least one detail record is defined in
'FAM Function. Open' (CRS405). The detail record
controls these entry functions for usage type 2 interfaces:
- From date/To date when posting are allowed
- Voucher number series and voucher name
- Auto-reverse, whether the journal voucher is a temporary voucher, that is reversed automatically on a specified reversal date
- Exchange rate type
- Panel layout, for layout 20 and 21 a currency can be defined.
Follow these steps
-
Specify an interface name and select option 1-'Create' in (GLS850/B) and press Enter.
-
Specify a description and select usage type 2-'Field-based API' in the E-panel. Then the 'Interface type' will be set to 01-'General Ledger vouchers', which is the only type of transactions that are available for this usage type. Enter FAM function 'GL01' and a detailed FAM function record. Press Enter to create the template header.
-
After the header has been created in (GLS850), a standard template for the fields is generated automatically. The field template header is created with 'Input record ID' set to 'I1' in 'FIM Interface. Define Input Records' (GLS855). Only the output fields need to be defined for usage type 2, as the input fields only exist in the background.
-
In 'FIM Interface. Define Output Records' (GLS857) the output field header is created. For usage type 2 only FCR040 is valid as an output table and can only be declared once.
-
In 'FIM Interface. Define Output Fields' (GLS858) the output fields are defined. Every output field is connected to an input field in the API transaction. The selection field, 'Population mtd', displays different output fields depending on the selected population method. This method controls how output records will be generated in the interface and may be changed for the fields as appropriate, to correspond to the applicable interface.
This table shows the available population methods and how they are used:
Population method Description 0-'Not populated' Fields not used in the interface 1-'Populated from input file' Fields that should be entered through the API transaction 2-'Populated using default value' Fields that should be populated with a hardcoded value for all accounting lines in the interface. The value is entered in field 'Dflt output fld' on (GLS858/E). 3-'Interface batch job populates fld' Fields that should be populated with a value from the system. This is handled in the program during the update of the general ledger. Population method 3 can only be used for fields indicated with an asterisk (*) in column 'Fld' on (GLS858/B).
Default output fields template in (GLS858)
The table below shows the default output fields template for usage type 2 and the default population method defined for each field.
The column 'Population mtd' in this table indicates the applicable population methods that can be selected for each output field. The 'Comments' column indicates any additional rules or logic around the field.
Output fields for population method 0-'Not populated':
Seq no. | Field name | Description | Population mtd | Comments |
---|---|---|---|---|
007 | EICD | External/internal transaction | 0-2 | This field needs to be set for internal transactions only. Value 1='internal transaction'. |
023 | ACQT | Quantity | 0-2 | |
033 | VTCD | VAT Code | 0-2 | Must be a valid VAT code from 'VAT Code. Open' (CRS030). |
049 | VRNO | VAT registration number | 0-2 | |
050 | EXN1 | GL information number | 0-2 | The fields for GL information are used to generate extra information in the general ledger extension table FGLEDX (GLS250). See the functions in 'General Ledger. Update Additional Info' (GLS950) for available information numbers. |
051 | EXI1 | GL additional number | 0-2 | |
052 | EXN2 | GL information number | 0-2 | |
053 | EXI2 | GL information number | 0-2 |
Output fields for population method 1-'Populated from input file' (API transaction):
Seq no. | Field name | Description | Population mtd | Comments |
---|---|---|---|---|
013 | AIT1 | Accounting dimension 1 | 1-2 | |
014 | AIT2 | Accounting dimension 2 | 0-2 | |
015 | AIT3 | Accounting dimension 3 | 0-2 | |
016 | AIT4 | Accounting dimension 4 | 0-2 | |
017 | AIT5 | Accounting dimension 5 | 0-2 | |
018 | AIT6 | Accounting dimension 6 | 0-2 | |
019 | AIT7 | Accounting dimension 7 | 0-2 | |
020 | VTXT | Voucher text | 0-2 | |
025 | CUCD | Currency | 1-3 | Population method 3 can only be selected for CUCD if a FAM function with a currency (panel layout 20/21) is selected on (GLS850/E). The currency from the FAM function will be retrieved during creation of the voucher line and can be displayed in (GLS840)/(GLS842). |
028 | CUAM | Foreign currency amount | 1 | Negative amounts should have the minus sign '-' placed before the figures in the API transaction, for example, -2500.00 |
029 | DBCR | Debit/credit code | 1 or 3 | The population method (PMET) for DBCR is set based on the setting of debit/credit code (DCNY) for the division in 'Settings - General Ledger' (CRS750). If DCNY=0 then PMET will be set to 3 and if DCNY=1 then PMET will be set to 1 and needs to be entered through the API transaction. This setting cannot be changed. |
030 | ACDT | Accounting date | 1-2 | Only one accounting date can exist per group number (GRNR). |
054 | SHDT | Reversal date | 1 | SHDT is only created as an output field if the FAM function entered on (GLS850/E) has parameter 'Auto-reverse' selected. See more information about auto-reverse voucher below. |
Output fields for population method 3-'Interface batch job populates fld':
Seq no. | Field name | Description | Population mtd | Comments |
---|---|---|---|---|
024 | ACAM | Recorded amount | 1 or 3 | Negative amounts should have the minus sign '-' placed before the figures in the API transaction, for example, -2500.00 |
026 | CRTP | Exchange rate type | 1-3 | |
027 | ARAT | Exchange rate | 1-3 | |
041 | BSCD | Base country | 1-3 | |
042 | FTCO | From/to country | 1-3 |
Set-up interface for auto-reverse voucher
The same auto-reverse functionality that exists for vouchers through 'Journal Voucher. Enter' (GLS100) can be used for usage type 2 interfaces. The voucher lines entered in 'FIM Interface. Open' (GLS840) or 'FIM Interface. Open Lines (GLS842) will be reversed automatically during entry in the general ledger on a specified reversal date. This date must be greater than the current accounting date of the voucher. The reversal date must be unique per group number (voucher).
To set this up, FAM function GL01 with a detail record that has parameter 'Auto-reverse' selected, must be defined in 'FAM Function. Open' (CRS405). An interface template needs to be created in (GLS850) for usage type 2 and the FAM function for auto-reverse must be selected in (GLS850/E). Then the field 'Reversal date' (SHDT) will be created as an output field for population method 1 (from input file) in (GLS858) and possible to input through the API transaction.