Define Bank Account Identifier

This document describes how to define information about a bank account. The information controls how the bank statements of the bank account will be processed.

Outcome

The settings for a bank account identifier are defined. This includes determining values such as how vouchers will be created and which checks will be performed when the statements are automatically validated.

The information is used when processing bank statements in 'Bank Statement. Open' (ABS100).

The FABIDE table is updated.

Before you start

Note:  Using the four user-defined fields displayed in 'Bank Account Identifier. Open' (ABS900), you can use a functionality that does not exist in the standard solution. In this case, the customer-unique functionality for these fields must be developed and implemented during customer installation.

Parameters to set

Program ID/Panel Field The field indicates…
(ABS900/B) Bank account identifier … the company's unabbreviated bank account ID.
(ABS900/E) Bank account ID … the company's bank account ID and related general bank information, as defined in (CRS692).
(ABS900/E) Bank statement number

… how the number that identifies an individual bank statement is created.

These are the valid alternatives:

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

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.

Example: The last statement was 201610. The new statement is 201611.

(ABS900/E) Last bank statement number used

… the number of the bank statement last received.

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.

(ABS900/E) Enter statement manually

… whether you can manually specify bank statements in (ABS100).

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.

Note that when you manually enter a bank statement, you must press F14 or select the A panel as the start panel in (ABS100/P).

(ABS900/E) Separate vouchers per statement line

… whether a voucher, and thus also one bank transaction, will be created per bank statement line. If you do not activate the check box, one single voucher will be created instead for the entire bank statement.

Tips:

  • If the bank account identifier refers to bank statements that are received only once a week or the similar, you may want to create a voucher for every statement line, since different accounting dates can then be set on the vouchers.
  • Creating a voucher for every statement line (as is the case in Germany) will save you time if the allocation of a statement line turns out to be incorrect, since you only have to correct the voucher referring to that specific line. Creating a voucher for the entire statement (as is the case in Belgium) will save you time since the number of created transactions is decreased.
(ABS900/E) Partial update

… whether partial updates of a bank statement to the general ledger should be allowed.

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

(ABS900/E) Variance check

… whether a check should be performed automatically when allocating invoices to statement lines. 'Check' means that any possible variances in amounts and percentage between the invoice(s) and the statement line are checked against the allowed variances defined in 'Payment Variance Limit. Define' (ABS920) together with the allowed cash discount terms.

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

(ABS900/E) Accounting date used

… which accounting date(s) that will be set to the bank transactions created during the bank statement allocation.

These are the valid alternatives:

  • 1 = Closing balance date
  • 2 = Value date on statement line

Alternative 1 means that the closing balance date on the bank statement in (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 in (ABS101/E) will be used. If you have specified that a voucher will be created per bank statement line, this alternative is usually selected.

(ABS900/E) Payment date used

… which payment date that will be set to the bank transactions are created during the bank statement allocation.

These are the valid alternatives:

  • 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 in (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 in (ABS101/E) will be used.

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

(ABS900/E) Exchange rate date used

… which exchange rate date will be retrieved and be valid for each bank statement line. The exchange rate date determines the exchange rate that will apply for the statement line.

These are the valid alternatives:

  • 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 in (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 in (ABS101/E) will be used.

Alternative 3 means that the accounting date on the bank statement line in (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.

(ABS900/E) Voucher text for bank transaction

… which text that will be the voucher text for the bank transactions are created during the allocation of a bank statement.

These are the valid alternatives:

  • 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 in (ABS101/F) will be used.

Alternative 3 means that the value specified in the 'Bank number' field for the bank account ID in (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: The bank statement number (ABS100/B) / The page number of the statement line / The sequence number of the statement line (ABS101/B).

Alternative 5 means that the description of your company's bank account (accounting dimension 1) in (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: The bank account (ABS100/B) / The bank statement number (ABS100/B) / The page number of the statement line / The sequence number of the statement line (ABS101/B).

Note that you can only use alternatives 2, 4, and 6 if vouchers are created per bank statement line.

(ABS900/E) Next manual step - bank statement

… how automated the processing of bank statements will be when the validation step is executed through (ABS100MI), transaction ValidateStatmt. This MI transaction can either be executed manually, or through a Financial Business Message (FBM) or a Business Object Document (BOD) after the bank statement has been uploaded to (ABS100) through Infor Enterprise Collaborator.

These are the valid alternatives:

  • 0 = Not used
  • 2 = Allocation. This means that the execution of the MI transaction ValidateStatmt will start validation only. Afterwards, you have to manually trigger the allocation of the bank statement in (ABS100/B).
  • 3 = GL update. This means that the execution of the MI transaction ValidateStatmt results in that the bank statement will be 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 MI 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 MI transaction ValidateStatmt, the bank statement will remain in the original status and an error message can be reviewed in the error log in (ABS103).

Note that a later step in the process will only be started if the previous step is successful. If an error occurs in the validation, the process halts. Similarly, if not all statement lines are allocated, there will be no update of the general ledger.

Also note that the next manual step functionality exists in (ABS100) as well. In (ABS100), it controls how automated the processing of bank statements will be when you start the validation step manually with Related option 21='Validate bank statement'.

(ABS900/E) Create log file

… whether a log file will be created if a search is performed in the additional information for statement lines during the allocation, in order to find identities (usually invoice numbers) that enable invoices to be allocated to the lines.

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 the information you gain to correct the problem.

The log files are reviewed in (ABS104), and can be accessed from (ABS100) or (ABS101).

(ABS900/E) Multiple users

… whether more than one user will be able to work with a bank statement line at the same time.

The field can, for example, be activated 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 a user starts working with it.

(ABS900/E) Customer receipts from multiple divisions

… whether customer receipts for multiple divisions should be accepted for bank statements of type 3 (Customer receipts).

The check box can only be selected on a company level, that is, by the central division. When working with the bank statement lines, the original division that incurred the customer receipt is displayed in (ABS102/E).

Note that central management of customer receipts from several divisions requires that FAM functions AR30 and AB10 exist in all divisions to be included and that they are identical.

(ABS900/E) Bank accrual voucher

… whether the bank account in the general ledger should be updated as soon as the bank statement is validated (status 4).

This will be 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 in (CRS692/E) used. 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.

(ABS900/E) Status

… the status of the bank account identifier.

These are the valid alternatives:

  • 10 = Preliminary
  • 20 = Definite
  • 90 = Blocked/expired

Note that you can perform statement allocation to statements that belong to a bank account identifier in status 20='Definite'. If the bank identifier has another status, an error message is displayed when you validate the received bank statement in (ABS100).

(ABS900/E) User-defined field 1–7 – Bank statement line

… a field specified by the user. If specified, the field's value will be retrieved from the bank file including the bank statement and displayed for each statement line in (ABS101/E).

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

(ABS900/E) FAM function

… the detail record under FAM function AB10, in which basic data is used when transactions are created during the allocation of bank statements.

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.

(ABS900/E) FAM function GL

… the detail record under FAM function GL01 that is used during allocation when a general ledger transaction or voucher is created. This can be the case if the statement line refers to an interest, a fee, or another sum that cannot be matched to an existing transaction in M3.

Note that some basic data from the detail record for AB10 specified in the 'FAM function' field is also used.

(ABS900/E) FAM function AR

… the detail record under FAM function AR30 that is used during allocation when transactions are created in the accounts receivable. This can be the case if customer invoices are allocated to statement lines or if an on-account payment is created, since there is no customer invoice that matches the bank statement line.

Note that some basic data from the detail record for AB10 specified in the 'FAM function' field is also used.

(ABS900/E) FAM function AP

… the detail record under FAM function AP20 that is used during allocation when transactions are created in accounts payable. This might be the case if supplier invoices are allocated to statement lines or if an on-account payment for is created for the accounts payable, since there is no supplier invoice that matches the bank statement line.

Note that some basic data from the detail record for AB10 that has been specified in the 'FAM function' field is also used.

(ABS900/E) Bank statement type

… the type of bank statement to process.

These are the valid alternatives:

  • 1 = Regular bank statement
  • 2 = Payment specification
  • 3 = Customer receipts

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/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 in (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.

(ABS900/E) Reverse sign

… whether the value on the line should be reversed and a reverse sign used.

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.

(ABS900/F) Bank account balance

… whether a check will be performed to ensure that the opening balance on the bank statement corresponds to the current balance of the bank account in M3. The check is performed automatically when the bank statement is validated.

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

Note that if the bank statement is not in a local currency, the check can only be performed if the 'Currency connection' field in (CRS630/F) for the bank account is set to 2.

(ABS900/F) Supplier bank account

… whether a check should be performed to ensure that the payer's/payee's (from now on named customer/supplier) bank account on each bank statement line is connected to a customer/supplier in (CRS693).

These are the valid alternatives:

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

(ABS900/F) Customer bank account See above.
(ABS900/F) Bank account indicator

… the identity of a bank account indicator.

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.

Note that this field is only used if alternative 3 is selected for the 'Supplier bank account' field, mentioned above.

Bank account indicators are defined in (CRS072).

(ABS900/F) Transaction type

… whether a check will be performed to ensure that all transaction types in the received bank statement exist in (ABS010).

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

(ABS900/F) Business transaction code

… whether a check will be performed to ensure that all business transaction codes in the received bank statement exist in (ABS020).

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

(ABS900/F) Different currencies allowed

… whether it should be allowed for different bank statements to have different currencies for the same bank account identifier.

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

Note: When using a company bank account defined for local currency on (CRS692/E), bank statements in any currency will be allowed if this parameter has been activated. When using a company bank account for foreign currency on (CRS692/E), only bank statements in that foreign currency and in the local currency will be allowed, even if this parameter has been activated.
(ABS900/F) Message indicator

… a protocol that controls the creation of the file layout for the bank file containing the statement. The protocol controls how the information in the file is selected and sorted in Infor Enterprise Collaborator.

Which formats to use differs 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.

(ABS900/F) Structured

… whether the additional information of the statement lines should already be processed when the bank statement file is received and processed by Infor Enterprise Collaborator.

If you activate this field, Infor Enterprise Collaborator will analyze the additional information and specify different parts of the text in different fields in (ABS101) and (ABS102) for the statement line.

These 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 Infor Enterprise Collaborator to identify the different parts of the additional information text.

Note that this field can only be used in Germany and Austria and when the internal bank format is DTAUS.

(ABS900/F) Qualifier sign

… the sign used in front of numbers that identify the different parts of the additional information text.

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

(ABS900/F) User-defined field 1–4 … a field that can be used for functionality developed during customer installation of the system.
(ABS900/F) Payment details

… whether upload of payment details, if available as structured information in the message input file, should be performed. Payment details are invoice number and amount. If you activate this field, one record per structured information available is created for the bank statements details in (ABS102).

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 will be 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.

(ABS900/F) End-to-end ID

… whether upload of End-to-end ID (also called Transaction ID), if available in the message input file, should be performed. If you activate this field, the ID is saved with additional information category 266 and 466 in (ABS102) and can be used for allocation of all invoices and credit notes connected to the ID as indicated on the APL payment method in (CRS071).

The field will be 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.

(ABS900/F) Instruction ID

… whether upload of Instruction ID if available in the message input file should be performed. If you activate this field, the ID is saved with additional information category 267 and 467 in (ABS102) and can be used for allocation of all invoices and credit notes connected to the ID as indicated on the APL payment method in (CRS071).

The field will be 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.

Follow these steps

  1. Open 'Bank Account Identifier. Open' (ABS900/B). Set the panel sequence to EF and the sorting order to 1='Bank account identifier.'

  2. Specify the identity of the bank account identifier to create (usually the unabbreviated bank account ID) and select New.

    Define basic data

  3. On the E panel, specify the bank account ID as indicated in (CRS692) to connect the general bank account information specified there to the bank account identifier.

  4. Define how the bank statement numbers will be numbered and, if necessary, a number in the 'Last bank statement number' field to function as a start number.

  5. Specify whether you can enter bank statements manually in (ABS100).

  6. Specify whether a separate voucher will be created per bank statement line or if one voucher will be created for the entire statement.

  7. Specify whether a check against allowed variances will be performed during statement allocation.

  8. Specify how to set the accounting date, payment date, and exchange rate date. Also, specify how the voucher text should be retrieved.

  9. Specify to what degree the processing of bank statements will be automated when the statements are received through Infor Enterprise Collaborator.

  10. Specify whether a log file will be created during statement allocation.

  11. If required, specify up to six user-defined fields for the bank statement lines.

  12. Specify the detail record to use for FAM function AB10 (in the 'FAM function' field). Also, specify the detail records to use for the FAM functions in GL, AR, and AP.

  13. Set the status for the bank account identifier to 20='Definite' or to 10='Preliminary' (if the identifier will be reviewed before use, for example). Press Enter.

    Check the statement validation and mapping in Infor Enterprise Collaborator

  14. Specify whether a bank account balance check will be performed during statement validation.

  15. Specify whether a check will be performed during validation to ensure that bank accounts are connected to customers and suppliers, respectively.

  16. Specify whether a check will be performed during validation to ensure that the transaction types and/or business transaction codes in the statement exist in M3.

  17. Specify the bank format to use during the mapping performed by Infor Enterprise Collaborator.

  18. If necessary, specify whether the additional information should be processed during the mapping performed by Infor Enterprise Collaborator. If so, specify the qualifier sign used in the additional information.

  19. If necessary, specify values in the user-defined fields displayed. Press Enter.

  20. If required, specify whether payment details should be created in (ABS102) during the process performed by Infor Enterprise Collaborator.

  21. If required, specify whether end-to-end ID or instruction ID, or both, should be created, in (ABS102), during the process performed by Infor Enterprise Collaborator.

Related topics