Define Bank Account Identifier

Valid alternatives are:

1 = According to bank

2 = Calendar days (year + day number)

3 = Last statement number + 1.

Alternative 1 means that the number is included in the file containing the bank statement. That is, in other words, the bank controls the numbering of the statements. In this case, an error message will be displayed when you validate the statement in (ABS100), if a bank statement without a number is received. You should then contact the bank, investigate why the number is missing, delete the received statement, and ask the bank to send it again.

Alternative 2 means that the number is automatically set when the bank statement is retrieved from the bank file and stored in M3. The number is set according to calendar days (that is YYYYNNN), where YYYY is the current year and NNN is the current day number of the year.

For example, if a statement is received on February 3, 2016, it will be assigned statement number 2016034. If required, you can easily find the day number for a specific day on the E panel in 'System Calendar. Open' (CRS900).

Alternative 3 means that the number is set automatically when the bank statement is retrieved from the bank file and stored in M3. The number is set as the last statement number received from the bank plus 1.

For example, the last statement was 201610. The new statement is 201611.

This field is updated automatically whenever a bank statement is received.

If you define a completely new bank account identifier and want to use the numbering principle that uses the last statement number, you must specify a value in this field. This is because this field is blank when no earlier statements have been received. Specify a value that makes it easy to identify the statements. The number can begin with the current year followed by a sequence number, for example.

This check box is activated if it is expected to occasionally receive bank statements printed on paper and not as bank files, or if you want to test the bank statement functionality when setting up the system.

If activated, statements can still be received in bank files.

If a partial update is not allowed, the bank statement can only be updated to the general ledger when it is fully allocated (status 6).

If a partial update is allowed, the bank statement can be updated to the general ledger when the bank statement is partly allocated (status 5) or fully allocated (status 6). When updating partly allocated bank statements, only fully allocated lines (status 6) are included. You can also update a single bank statement line that is fully allocated (status 6).

The check is activated to secure correct handling of cash discounts.

Valid alternatives are:

1 = Closing balance date

2 = Date of bank statement line

3 = Keep accounting date from bank statement line, if blank, use closing balance date

4 = Keep accounting date from bank statement line, if blank, use value date.

Alternative 1 means that the closing balance date on the bank statement on (ABS100/F) will be used. If you have specified that a voucher will be created per bank statement, this alternative is always selected.

Alternative 2 means that the value date on the bank statement line on 'Bank Statement. Open Lines' (ABS101/E) will be used. If you have specified that a voucher will be created per bank statement line, this alternative is usually selected.

Alternative 3 means that the accounting date on the bank statement line on (ABS101/E) will be used. If there is no accounting date on the bank statement line on (ABS101/E), the closing balance date on the bank statement on (ABS100/F) is used. If you have specified that a voucher will be created per bank statement line, this alternative can be selected.

Alternative 4 means that the accounting date on the bank statement line on (ABS101/E) will be used. If there is no accounting date on the bank statement line on (ABS101/E), the value date on the bank statement line on (ABS101/E) will be used. If you have specified that a voucher will be created per bank statement line, this alternative can be selected.

Valid alternatives are:

1 = Closing balance date

2 = Value date on statement line

3 = Accounting date on statement line.

Alternative 1 means that the closing balance date on the bank statement on (ABS100/F) will be used. If you have specified that a voucher will be created per bank statement, this alternative is always selected.

Alternative 2 means that the value date on the bank statement line on (ABS101/E) will be used.

Alternative 3 means that the accounting date on the bank statement line on (ABS101/E) will be used.

Valid alternatives are:

1 = Closing balance date

2 = Value date on statement line

3 = Accounting date on statement line

4 = No exchange rate date will be retrieved.

Alternative 1 means that the closing balance date on the bank statement on (ABS100/F) will be used. If you have specified that a voucher will be created per bank statement, this alternative is always selected.

Alternative 2 means that the value date on the bank statement line on (ABS101/E) will be used.

Alternative 3 means that the accounting date on the bank statement line on (ABS101/E) will be used.

Alternative 4 means that no exchange rate date will be retrieved. This alternative is selected if the date is already included in the bank statement when received from the bank, or if you do not want any exchange rate date to be valid for the line.

Valid alternatives are:

1 = No voucher text

2 = Transaction description text

3 = Name of bank

4 = Built-up text

5 = Name of the company's bank account

6 = Built-up text including bank account.

Alternative 2 means that the transaction text displayed for each statement line on (ABS101/F) will be used.

Alternative 3 means that the value specified in the 'Bank number' field for the bank account ID on (CRS692/E) will be used. This value is usually the name of the bank.

Alternative 4 means that the voucher text will be built up by values from several fields according to the following: bank statement number (ABS100/B) / page number of the statement line / sequence number of the statement line (ABS101/B).

Alternative 5 means that the description of your company's bank account (accounting dimension 1) on 'Accounting Identity. Open' (CRS630/E) will be used.

Alternative 6 means that the voucher text will be built up by values from several fields according to the following: bank account (ABS100/B) / bank statement number (ABS100/B) / page number of the statement line / sequence number of the statement line (ABS101/B).

Valid alternatives are:

0 = Not used.

2 = Allocation. This means that the execution of the API transaction ValidateStatmt will start validation only. Afterwards, you have to manually trigger the allocation of the bank statement on (ABS100/B).

3 = GL update. This means that the execution of the API transaction ValidateStatmt results in the bank statement being validated and allocated automatically. You must manually trigger an update of the general ledger.

4 = Completely automatic. This means that all the activities mentioned above will be carried out automatically when the API transaction ValidateStatmt is executed.

Selecting an automated flow speeds up the process and minimizes your effort. Selecting the least automated flow puts you in full control.

If an error occurs during the processing of the API transaction ValidateStatmt, the bank statement remains in the original status and an error message can be reviewed in the error log in 'Bank Statement. Display Error' (ABS103).

If this check box is activated, a log file is always created, whether a search was successful or not. The file displays detailed information about exactly how the search was performed. If the search failed, you can analyze the log file and use that information to correct the problem.

The log files are reviewed in 'Additional Information. Review Log' (ABS104), and can be accessed from (ABS100) or (ABS101).

For example, this may be used if you want several users to work with manual allocation of a line at the same time. If the field is not activated, the statement line receives a blocked status when another user starts working with it.

If this parameter is activated, customer payments and supplier payments can be processed for multiple divisions, but allocation of general ledger transactions is only handled for the division in which the bank statement is received. If the FAM function selected for GL on (ABS900/E) has been defined for cross-division vouchers on 'FAM Function. Open Details' (CRS406/E), an error message is displayed on (ABS900/E), even if the parameter for 'Multi-division payments' has been activated on (ABS900/E).

A bank account identifier that has been defined with this parameter activated on (ABS900/E) can only be used for bank statements that are created and processed on company level, that is from blank division. The bank statements as such, still belong to the division that has received the customer payments, or from which the supplier invoices have been paid.

When working with the bank statement lines for a bank statement with multi-division payments, the original division of the customer invoices, and supplier invoices, is displayed on 'Bank Statement. Open Line Details' (ABS102/E).

For processing of electronic bank confirmation for multi-division supplier payments, the bank statement must belong to the same division as the payment proposal.

This is performed automatically with a bank accrual voucher using accounting rules AB10-370/374 (Bank) and AB10-375 (Bank accrual). When the bank statement is fully allocated and updated to the general ledger, the normal voucher will offset AB10-375.

The voucher text used for the bank accrual voucher is the value specified in the 'Bank number' field for the bank account ID on (CRS692/E). This value is usually the name of the bank. If a bank accrual voucher is not created, the bank account is updated when the bank statement is fully allocated and updated to the general ledger.

Valid alternatives are:

10 = Preliminary

20 = Definite

90 = Blocked/expired.

Although these fields are only used for informational purposes, they enable you to control the content retrieved from the file to facilitate the processing of statements.

The fields you can select in between are the ones belonging to the field group ABUS1 (Auto bank statement – User-defined fields). The field group ABUS1 must be generated in 'Field Group. Open' (CRS108).

The basic data used are the valid from and to dates, voucher number series, voucher name, and exchange rate type. Other data used when the transactions are created is retrieved from the detail records for GL01, AR30, or AP20, depending on the type of transaction.

Valid alternatives are:

1 = Bank statement

2 = Payment specification

3 = Payments received.

Alternative 1 means that the bank statement can contain both supplier payments and customer receipts to be allocated to invoices in M3. When the general ledger is updated, you can reconcile the bank accounts. An account entry is created for the bank statement based on accounting rule AB10–370.

Alternative 2 means that the bank statement includes one line for all supplier payments or customer receipts, and a separate payment specification declares all the individual records of payments made by a supplier or customer and the corresponding invoices. The information enhances the allocation of invoices to bank statement lines. An account entry is created for the bank statement based on accounting rule AB10–374 (bank in transit).

Alternative 3 means that the bank statement includes customer receipts only. An account entry is created for the bank statement based on accounting rule AB10–370. This type of electronic bank file does not contain any opening or closing balances, so the fields for those balances are not displayed when working with the file header on (ABS100/F).

The field is used when a bank statement is loaded to M3 using Global Electronic Messages. One of the alternatives 1-3 must be selected to ensure correct processing when the bank statement is loaded. A detailed description can be found in the configuration guide. For bank statements loaded using Financial Business Messages (FBM), the bank statement types are handled in the mapping of each message.

The field is used when a bank statement is loaded to M3 using Global Electronic Messages. A detailed description can be found in the configuration guide. For bank statements loaded using Financial Business Messages (FBM), the reverse sign is handled in the mapping of each message.

If the balances do not correspond, the validation fails and an error message is displayed in (ABS103). The current bank account balance can, for example, be reviewed in 'General Ledger. Display Transactions' (GLS210).

Valid alternatives are:

1 = No

2 = Yes, manual update

3 = No, automatic update.

The check is performed automatically when the bank statement is validated. These conditions prevail:

• If a customer's/supplier's bank account on a bank statement line is not connected to a customer/supplier in (CRS693), the validation fails and an error message is displayed in (ABS103). You must then manually connect the customer/supplier to the bank account in (CRS693) using bank account value type 5.
• If a customer’s/supplier’s bank account on a bank statement line is connected to a customer/supplier in (CRS693), then the bank statement line is updated with the customer/supplier.

If alternative 3 is selected, the check mentioned above is not performed during validation. When the bank statements are fully allocated and the general ledger is updated, a check is performed to see whether the customer/supplier on the bank statement line is connected to the bank account of each statement line respectively in (CRS693). If no connection exists, it is created automatically according to the paragraph above.

Alternatives 2 and 3 are selected if such scenarios are used that retrieve the customer/supplier connected to the bank account of the line in order to facilitate the search for an invoice to allocate to the line. Either one of the two alternatives is dependent on your routine. When selecting alternative 2, you solve any potential problems at an early stage during validation. Thus, automatic allocation will run more smoothly. When selecting alternative 3, initially you will have to do more manual allocation of invoices to lines, since the scenarios will not find the customer/supplier to use in the search. On the other hand, you do not have to manually make connections in (CRS693).

A bank account indicator controls which fields are used when defining a bank account number to connect to the indicator. The indicator also controls the number of positions used for the different fields.

Bank account indicators are defined in 'Bank Account Indicator. Open' (CRS072).

The purpose of the check is to ensure that scenarios controlling how the bank statement line will be processed during allocation are defined for all possible transactions that may occur in the statement.

The check is performed automatically when the bank statement is validated. If a transaction type is found that does not exist in (ABS010), the validation fails and an error message is displayed in (ABS103).

The purpose of the check is to ensure that scenarios controlling how the bank statement line will be processed during allocation are defined for all possible transactions that may occur in the statement.

The check is performed automatically when the bank statement is validated. If a business transaction code is found that does not exist in (ABS020), the validation fails and an error message is displayed in (ABS103).

If you do not select this check box, the currency of the bank statement header in (ABS100/E) and the currency of the bank account identity on (CRS692/E) of the identifier must not differ.

The check is made automatically when the bank statement is validated. If the currency differs, the validation fails and an error message is displayed in (ABS103).

Selecting this parameter means that the imported currency rates from the bank statement file are ignored. Instead, a rate based on the values on the bank statement lines is calculated, or currency rates are fetched from 'Exchange Rate. Open per Date' (CRS058) when uploading bank statements through API ABS100MI (Bank statement interface).

… whether bank charges should be uploaded from the electronic file received when a bank statement is uploaded to M3.

Valid alternatives are:

0 = No

1 = Upload bank charges for entry transaction as bank statement line details in (ABS102)

The field is used when bank statements are created using global electronic messages (GEMS) and the bank statement BOD as described in the configuration guide.

For bank statements created using Financial Business Messages (FBM), the usage of the field depends on the messages and is described in the documentation for the message.

Which formats to use differ from country to country. The formats are defined when the bank statement application and Infor Enterprise Collaborator are set up. The formats can be named according to CODAXXXXX (used in Belgium) or MT940XXXXX (used in most other countries), where X indicates alphanumeric positions.

If you activate this field, the additional information is analyzed by Infor Enterprise Collaborator and different parts of the text in different fields in (ABS101) and (ABS102) for the statement line is specified.

This information is then retrieved: additional information text (20 to 29 and 60 to 63), transaction text (00), primanota (10), payer's/payee's bank account number (30 and 31), customer/supplier name (32 and 33), and business transaction code (34). The numbers within parentheses are defined by the bank and used in the additional information, enabling the different parts of the additional information text to be identified by Infor Enterprise Collaborator.

This field is only used if the 'Structured' field is activated. If the field is activated, you must specify the valid sign in this field for the additional information to be processed correctly by Infor Enterprise Collaborator.

The bank determines which sign is valid. Examples of signs that can be used are question mark (?), slash (/), and tilde (~).

… the number of characters to replace after a qualifier sign when a bank statement is uploaded to M3.

The field is used when bank statements are created using global electronic messages (GEMS) and the bank statement BOD as described in the configuration guide.

For bank statements created using Financial Business Messages (FBM), the usage of the field depends on the messages and is described in the documentation for the message.

If you do not select this check box or if payment details are not available in the message, the total payment amount is used for the bank statements details created in (ABS102).

The field is used when bank statements are created using Global Electronic Messages as described in the configuration guide.

For bank statements created using Financial Business Messages (FBM), the usage of the fields depends on the messages and is described in the documentation for the message.

The field is used when bank statements are created using Global Electronic Messages as described in the configuration guide.

For bank statements created using Financial Business Messages (FBM), the usage of the fields depends on the messages and is described in the documentation for the message.

The field is used when bank statements are created using Global Electronic Messages as described in the configuration guide.

For bank statements created using Financial Business Messages (FBM), the usage of the fields depends on the messages and is described in the documentation for the message.