Define Scenarios for Allocating Invoices to Bank Statement Lines

The field indicates the type of scenario.

These are the valid alternatives:

• 1 = General Ledger (GL)
• 2 = Accounts Receivable (AR)
• 3 = Accounts Payable (AP)
• 4 = Accounts Receivable (AR) on account
• 5 = Accounts Payable (AP) on account
• 6 = Accounts Receivable (AR) based on bank remittance for payments by direct debiting
• 7 = General Ledger (GL) credit card settlement
• 8 = AR Prepayment.

When scenario 1 is specified, a general ledger transaction is automatically created. This is used for statement lines that do not refer to an invoice, such as bank interest or a bank fee.

When scenario 2 is specified, a customer invoice is retrieved and allocated to a statement line.

When scenario 3 is specified, a supplier invoice is retrieved and allocated to a statement line.

When alternative 4 or 5 are specified, an on-account payment is created in accounts receivable and accounts payable respectively.

When scenario 6 is specified, customer invoices that are included in a direct debiting proposal in 'Bank Remittance. Open' (ARS300) are retrieved and allocated to a statement line.

When scenario 7 is specified, a customer invoice that is connected to a payment reference number is retrieved and allocated to a statement line. The payment reference numbers are stored in table FIRCON, as well as in additional information number 032 in table FGLEDX.

When scenario 8 is specified, the bank statement line holds a reference to a payment document number in table OINVOH. For this scenario, an on-account payment with a number from number series C3 in 'Number Series. Open' (CRS165) is created for the statement line. The on-account payment is updated with the payment document number as additional information number 249 in table FSLEDX.

Scenario for Creating General Ledger Transactions (Scenario Type 1)

The field indicates how the accounting string for the transaction is found.

These are the valid alternatives:

• 1 = Fixed string. This means that a specific accounting string specified for the scenario on (ABS911/E) is always used during posting.
• 2 = Standard voucher. This means that a standard voucher is specified for the scenario on (ABS911/E). The account entry lines defined for the standard voucher are then used during posting.
• 3 = Text identifier field. This means that the text identifiers defined in (ABS940) are used to retrieve information from the additional information file and thus identify what the bank statement line refers to. The accounting rules specified for the text identifier are then used during posting.

Here are the tips:

• Alternative 2 is used if you want several account entry lines to be created.
• Alternative 3 is used when you need to retrieve additional information. An example of when this is useful is if the statement line refers to the leasing of a car and you need to know the car's registration number to post the transaction correctly.

The field indicates a VAT code, controlling what VAT method and VAT rate to apply when VAT is calculated for the transaction.

VAT codes are defined in (CRS030).

The field indicates the standard voucher that will be used to post the transaction.

If you use a type 3 standard voucher, you can create multiple account entries using the amount from the statement line and distributing it on the standard voucher lines, based on a percentage defined for every line.

This field is only used in case you have selected a standard voucher as the GL posting alternative for the scenario.

Standard vouchers are defined in (GLS015).

The field indicates which text is the voucher text for the transactions offsetting the bank transactions created during the allocation.

These are the valid alternatives:

• 1 = No voucher text
• 2 = Transaction description text. This means that the transaction text displayed for each statement line on (ABS101/F) is used.
• 3 = Name of bank. This means that the value specified in the 'Bank number' field for the bank account ID on (CRS692/E) is used. This value is usually the name of the bank.
• 4 = Built-up text. This means that the voucher text is built up by values from several fields in these order: The bank statement number (ABS100/B), the statement line's page number (ABS101/E), and the statement line's sequence number (ABS101/B).
• 5 = Description of company's bank account. This means that the description of your company's bank account, which is accounting dimension 1, on (CRS630/E) is used.
• 6 = Description from text identifier. This means that the description of the text identifier in (ABS940) used to retrieve additional information is used.

  Note:  Alternative 6 can only be used for a scenario that creates a voucher, which is scenario type 1, and uses a text identifier for posting the voucher, that is, have value 3 selected for the 'Retrieval of accounting string' field.
• 7 = Invoice voucher text. This means that the voucher text from the invoice that is paid during bank statement processing is used.

  Note:  When alternative 7 is used, the voucher text is retrieved from the invoice transaction for the invoice selected in payment processing. This is the transaction with TRCD 10 for customer invoices, and TRCD 40 for supplier invoices.

Scenario for Allocating Invoices (Scenario Types 2 and 3)

When the 'customer/supplier' is mentioned below, it refers to the account holder of the transaction. In most cases the account holder is a customer or a supplier, but it does not necessarily have to be the case. However, the term 'customer/supplier' is used for pedagogical purposes.

The field indicates how the customer/supplier, that is, the account holder, to use for the scenario is retrieved. The customer/supplier is primarily used to apply for the on-account payment that is created, which are scenario types 4 or 5. However, you can also use it to narrow the search of an invoice to allocate to a statement line, which are scenario types 2 or 3.

These are the valid alternatives:

• 1 = No customer/supplier needed.
• 2 = Use fixed customer/supplier. This means that a customer/supplier is specified for the scenario on (ABS911/E).
• 3 = Search path. This means that a customer/supplier search path is specified for the scenario on (ABS911/E).

Here are some tips:

• Alternative 1 is selected if you do not consider it essential to find the customer/supplier in order to retrieve the exact invoice to allocate. This might be the case if your company processes a limited number of invoices.
• When you select alternative 2 the same customer/supplier is always used to find the invoice or to create an on-account payment. However, if you select alternative 3 the search is performed every time the scenario is used. In other words, the customer/supplier might differ from time to time, depending on the result of the search.

The field indicates from where the customer/supplier, that is, the account holder, is to be retrieved.

These are the valid alternatives:

• 1 = Customer/supplier from bank statement line: This means that the payer or payee displayed for the statement line on (ABS101/E) is retrieved.
• 3 = Payer/Payee bank account number: This means that the payer or payee bank account number displayed for the statement line on (ABS101/E) is used to retrieve the customer/supplier that is connected to that bank account number in 'Bank Account. Connect Additional Field' (CRS693).
• 4 = Customer/supplier from text identifier: This means that the text identifiers defined in (ABS940) is used to identify the customer or supplier based on the additional information displayed for the statement line on 'Bank Statement. Open Line Details' (ABS102/B).
• 5 = Customer order number: This means that the payer is retrieved from the customer order number displayed as additional information number 231 for the detailed bank statement line on (ABS102/E). You can specify the customer order number in any of the five fields available for additional information numbers on (ABS102/E).

The field indicates the customer or supplier, that is, the account holder, to use when searching for and allocating invoices to bank statement lines, which are scenario types 2 or 3, or to use when creating on-account payments, which are scenario types 4 or 5. If used for allocation, the customer/supplier specified here narrows the search for finding the exact invoice to allocate to the line.

The field indicates how to automatically retrieve the invoices to allocate to the bank statement line.

These are the valid alternatives:

• 1 = Invoice from bank statement line
• 2 = Additional information file
• 3 = Information category
• 4 = Search by amount
• 5 = Invoice reference number
• 6 = Parallel invoice number.

Alternative 1 means that the invoice number specified for the statement line on (ABS102/E) is used to find the invoice in one of the transaction files.

Alternative 2 means that the invoice number displayed as additional information for the bank statement line is used to find the invoice in one of the transaction files. The additional information structure in (ABS930) controls how this is done.

Alternative 3 means that the information category specified for the scenario on (ABS911/E) is used to retrieve an information category number, such as a grouped invoice number, that is displayed as additional information for the bank statement line. The number found is then used to retrieve an invoice number in the transaction files. The additional information structure in (ABS930) controls how this is done.

Alternative 4 means that the amount specified on the statement line on (ABS101/F) is used to find an invoice with the same amount in one of the transaction files.

Alternative 6 means that the 'Parallel invoice number' is used to find the invoice number in one of the transaction files. The 'Parallel invoice number' for customer invoices is defined in 'Additional Payment Reference. Open' (CMS090) for reference number type 1, or issued by a government or authority, which is reference number type 2. The 'Parallel invoice number' for customer invoices is stored in table FSAPRN, and in table CINHED for reference number type 2. The 'Parallel invoice number' for supplier invoices is stored in table FPAPRN.

The field indicates the information category that is used to find a unique information category number, for example, a grouped invoice number, in the additional information for a statement line. The number is then used to automatically, in one of the transaction files, find an invoice to allocate to the line.

How the search is done in the additional information and transaction files respectively is defined in (ABS930).

Information categories are maintained in (ARS950) if they refer to transactions in accounts receivable and in (APS950) if they refer to transactions in accounts payable.

The field indicates whether there should exist only one invoice with the same amount as the bank statement line, for an invoice to be allocated to the line.

These are the valid alternatives:

• 1 = Yes
• 2 = No, select the oldest invoice
• 3 = No, select the newest invoice.

If alternative 1 is selected and several invoices with the same amount are found, no allocation is carried out.

Alternatives 2 and 3 mean that if several invoices with the same amount are found, the oldest or newest invoice with the specific amount, according to the invoice date, is the invoice that is allocated to the statement line.

Select the check box if you want to apply all structure information records in (ABS930), even if transactions have been created based on a structure information record with a lower priority.

You can select this field if information to find all invoice numbers must be divided into several records in (ABS930).

Select the check box if you want the allocation program to merge up to three consecutive fields that are separated by a blank space in the additional information file.

The number is then checked against (ABS930), where you have defined a structure for the additional information file so that invoice numbers and other numbers, such as check numbers, is identified automatically.

The reason for this function is to increase the hit rate when invoice numbers are split by delimiters or line breaks, carrier returns. A blank space is added automatically after each line break. If an invoice number was split due to a line break, the part that was transferred to the new line will be separated by a blank space from the first part of the number.

For example, the additional information file includes these strings:

Invoices 1200001,1200002,12?21000 03

The string refers to three invoices: 1200001, 1200002 and 1200003. '?21' is a delimiter. The last part of the last invoice number is separated by a blank space due to a line break. The program can identify the first two invoice numbers but not the third.

If you select the check box, the first two parts of the last invoice number is firstly merged into 12000 and checked against (ABS930). If the number still cannot be identified, the remaining digits are added as well, resulting in 1200003. The invoice can then be identified.

The field indicates whether it is possible to perform partial payments or not.

The functionality is only available for scenario types 2 and 3.

You can perform a partial payment when the 'Search path - invoice' is set to '1', allocation based on invoice number on bank statement line, and a customer invoice number, or a supplier invoice number, is specified in (ABS102) together with an amount.

You can also perform a partial payment when the 'Search path - invoice' is set to '6', allocation based on parallel invoice number on bank statement line, and a parallel invoice number for a customer invoice, or a supplier invoice, is specified in (ABS102) together with an amount.

In the situation where 'Search path – invoice' also includes other allocation methods, for instance if it is set to '123', the partial payment functionality only applies to allocations performed with method 1, not if the actual allocation is performed with any of the other methods, 2 or 3 in this example.

For customer payments, which are defined for scenario type 2 with 'Search path - invoice' set to '1' or '6', multiple partial payments are allowed for the same invoice during automatic allocation in (ABS100). Normally, when an invoice is already allocated to a bank statement, you cannot allocate it a second time to the same bank statement or a different bank statement until the first payment is updated in accounts receivable. However, if the 'Partial payment' field is activated, you can perform multiple partial payments for the same customer invoice in the same bank statement through automatic allocation if the total paid amount does not exceed the outstanding amount of the invoice.

For example, the invoice amount of a customer invoice is 100 USD. The customer pays 30 USD in cash and 70 USD through a check. These two payments are included in the same bank statement as two different bank statement lines.

If the automatic allocation of this bank statement is performed through a scenario defined in (ABS911) as scenario type 2 with 'Search path - invoice' set to '1' or '6', and the 'Partial payment' field is activated on (ABS911/E), both bank statement lines are then allocated against the same invoice with 30 USD and 70 USD, respectively, and both bank statement lines are then updated to status 6='Fully allocated'.

However, if the 'Partial payment' field is not activated on (ABS911/E), the full invoice amount of 100 USD is then allocated against the first bank statement line, and no allocation is performed for the second bank statement line. As a result, the first bank statement line is updated to status 5='Partly allocated' and the second bank statement line remains in status 4='Ready for allocation'.

Scenario for Creating On-Account Payments for Accounts Receivable (Scenario Type 4)

The field indicates the type of transaction created through the scenario number during automatic allocation. This field is only used for scenario numbers defined for scenario type 4.

These are the valid alternatives:

• 1 = On-account
• 2 = On-account with given number
• 3 = Debit note with given number.

Alternative 1 means that an on-account payment is automatically created. If an unidentified customer payment of 100 USD has been received, an on-account payment is created for 100 USD, using the next available number from number series 52-1 in (CRS165). This on-account payment is updated in accounts receivable with a negative amount, -100 USD.

Alternative 2 means that an on-account payment, with a number given by the payer, is automatically created. If a customer pays 100 USD, and referred to a given on-account number that does not exist in accounts receivable, an on-account payment can be created for 100 USD, using the given number. This on-account payment is updated in accounts receivable with a negative amount, -100 USD.

Alternative 3 means that a debit note, with a number given by the payer, is automatically created. If a customer has withdrawn 100 USD from the payment, and referred to a given debit note number that does not exist in accounts receivable, a debit note can be created for 100 USD, using the given number. This debit note is updated in accounts receivable with a positive amount, 100 USD.

On-account payments, and debit notes, created during allocation of bank statements in (ABS100), are updated in accounts receivable as new invoice transactions (TRCD 10). An invoice number in accounts receivable can only exist once per invoice year (INYR), which means that the number given by a payer for an on-account payment, or a debit note, must not exist already in accounts receivable for the year of the payment. If the invoice number already exists for that year, the on-account payment, or the debit note, is not created during automatic allocation of the bank statement. The on-account payment, or the debit note, can then be created through manual allocation of the bank statement line in (ARS110) using a different number, instead of the number given by the payer. For example, if the number given by the payer is 'DN1234567', the user could add a suffix to create a unique invoice number: 'DN1234567x'.

The field indicates how the payment method to be used for the scenario number is retrieved. The payment method is applied to the on-account payment, or the debit note, that is created through the scenario number.

These are the valid alternatives:

• 1 = From FAM function
• 2 = From payer
• 3 = Use fixed.

Alternative 1 means that the payment method is retrieved from the FAM function selected for AR payments for the bank account identifier on (ABS900/E). The payment method is defined for the FAM function (AR30) on (CRS406/G).

Alternative 2 means that the payment method is retrieved from the payer on (CRS610/J), and is applied to the transactions created through the scenario number.

Alternative 3 means that a fixed payment method is specified for the scenario number on (ABS911/E), which means that this payment method is used for all transactions created through the scenario number.

The field indicates the payment method to use when creating on-account payments, or debit notes, through a scenario defined for scenario type 4.

The field indicates how the amount is set for on-account payments created automatically through the scenario number.

This field is only used for scenario numbers defined for scenario type 4 with sub scenario type 1.

If this parameter is not activated, the full amount of the detailed line in (ABS102) is used for the on-account payment.

If this parameter is activated, the remaining amount after other allocations for the detailed line in (ABS102) is used for the on-account payment.

For example, the amount of a bank statement line in (ABS101) is 100 USD. For this bank statement line, there are three detailed lines in (ABS102) with amounts 10 USD, 30 USD, and 60 USD, respectively. For the first detailed line, an invoice has been allocated with amount 10 USD. For the second detailed line, there is no reference to any invoice. For the third detailed line, an invoice of 35 USD has been allocated, leaving 25 USD not allocated.

If a scenario is used for creation of on-account payments automatically, on-account payments is created for the second and the third detailed lines in (ABS102).

If the parameter 'On-acc rem am' has been activated on (ABS911/E), the amount for the on-account payments is set to the remaining amount for each detailed line in (ABS102), that is 30 USD, and 25 USD, respectively. As the total allocated amount for the bank statement line (10+35+30+25=100 USD) is equal to the line amount (100 USD), the status is set to 6='Completely allocated'.

If the parameter 'On-acc rem am' has been deactivated on (ABS911/E), the amount for the on-account payments will be the full amount for each detailed line in (ABS102), that is 30 USD, and 60 USD, respectively. As the total allocated amount for the bank statement line (10+35+30+60=135 USD) is not equal to the line amount (100 USD), the variance (35 USD) is checked against the limits for accepted variances defined in (ABS920), if variance handling is activated in (ABS900). If the variance is within the limits, the variance is posted on accounting rule AB10-185, and the status of the bank statement line is set to 6='Completely allocated'. However, if the variance exceeds the limits, the status of the bank statement line will be set to 5='Partly allocated'.

The field indicates the reason for creating the debit note through a scenario defined for scenario type 4.

The debit note reason code is stored for each debit note in accounts receivable, field DNRE. It can be displayed, and changed, for debit notes in 'Debit Note. Open' (ARS125).

Debit note reason codes are defined in 'Debit Reason. Open' (ARS016).

The field indicates how the responsible user is retrieved for debit notes that are created through the scenario number.

These are the valid alternatives:

• 1 = Current user
• 2 = From payer
• 3 = Use fixed.

Alternative 1 means that the current user who performs the automatic allocation in (ABS100), through which the scenario number is used for the creation of a debit note, is set as the responsible user for the debit note.

Alternative 2 means that the credit department reference is retrieved from the payer on (CRS610/K), and is set as the responsible user for the debit note created through the scenario number.

Alternative 3 means that a fixed responsible user is specified for the scenario number on (ABS911/E), which means that this user is set as the responsible user for all debit notes created through this scenario number.

The field indicates the responsible user to use when creating debit notes through a scenario defined for scenario type 4.

The field indicates the number of days that is used for calculation of follow-up dates for debit notes created through the scenario number.

The number of days specified in this field, with a value from 0 to 999, is added to the value date of the bank statement line, field CURD, displayed on (ABS101/E) to calculate the follow-up date.

For examples, if the value date is June 1, and the number of days is set to 5, the follow-up date is then set to June 6.

If the value date is June 1, and the number of days is set to 0, the follow-up date is then equal to the value date, June 1.

Scenario for Creating On-Account Payments for Accounts Payable (Scenario Type 5)

Scenario for Allocating Invoices based on Bank Remittance for Payments by Direct Debiting (Scenario Type 6)

This scenario type is used to search for invoices that are included in a bank remittance for direct debiting in 'Bank Remittance. Open' (ARS300), tables FARRED and FARREM. At least two scenarios with scenario type 6 must be defined in (ABS911): One for payments processed by the bank, and one for rejected payments.

The field indicates how the customer or supplier, that is, the account holder, to use for the scenario is retrieved. The customer or supplier is primarily used to apply for the on-account payment that is created, which are scenario types 4 or 5). However, you can also use it to narrow the search of an invoice to allocate to a statement line, which are scenario types 2 or 3.

This is the valid alternative:

• 3 = Search path: This means that a customer/supplier search path is specified for the scenario on (ABS911/E).

The field indicates from where the customer or supplier, that is, the account holder, is to be retrieved.

This is the valid alternatives:

• 1 = Customer/supplier from bank statement line. This means that the payer/payee displayed for the statement line on (ABS101/E) will be retrieved.

The field indicates whether the scenario is applied to payments processed by the bank, or payments rejected by the bank.

Bank statement lines that are linked to a scenario with the 'Completed' check box cleared, are considered to be payments rejected by the bank, and will therefore not be included in the automatic allocation of invoices to bank statement lines.

Scenario for Credit Card Settlement (Scenario Type 7)

This scenario type is used for reconciling credit card payments against customer invoices using payment reference numbers in the M3 Business Engine. When a payment is made by credit card, it is normally made against a payment reference number that was created when the payment was booked, not against a customer invoice number. The payment reference number is transferred to M3 Financial Management via the FIRCON table, either when the customer order is invoiced, or when the credit card payment is allocated to the invoice.

The field indicates how to automatically retrieve the invoices to allocate to the bank statement line.

This is the valid alternative:

• 3 = Information category.

The field indicates the information category that is used to find a unique information category number, for example, a grouped invoice number, in the additional information for a statement line. The number is then used to automatically in one of the transaction files find an invoice to allocate to the line.

How the search is done in the additional information and transaction files respectively is defined in (ABS930).

Information categories are maintained in (ARS950) if they refer to transactions in accounts receivable and in (APS950) if they refer to transactions in accounts payable.

This is the valid alternative:

• 32 = Credit card payment reference

Scenario for Prepayments for Accounts Receivable (Scenario Type 8)

This scenario type is used for allocation of bank statement lines against payment documents in table OINVOH, where IVTP is 05 or 06. If a payment document is allocated to the bank statement line, an on-account payment is created using an invoice number from number series C3 in 'Number Series. Open' (CRS165), with information about the payment document number updated in additional information number 249.

The field indicates how to automatically retrieve the invoices to allocate to the bank statement line.

These are the valid alternatives:

• 1 = Invoice from bank statement line
• 2 = Additional information file
• 4 = Search by amount.

Alternative 1 means that the invoice number specified for the statement line on (ABS102/E) is used to find the invoice in one of the transaction files.

Alternative 2 means that the invoice number displayed as additional information for the bank statement line is used to find the invoice in one of the transaction files. The additional information structure in (ABS930) controls how this is done.

Alternative 4 means that the amount specified on the statement line on (ABS101/F) is used to find an invoice with the same amount in one of the transaction files.