Define Scenarios for Allocating Invoices to Bank Statement Lines

… the type of scenario.

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.

Explanations of alternatives

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)

… how the accounting string for the transaction will be found.

Valid alternatives

1 = Fixed string. This means that a specific accounting string specified for the scenario on (ABS911/E) will always be 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 will then be used during posting.

3 = Text identifier field. This means that the text identifiers defined in (ABS940) will be 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 will then be used during posting.

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

… 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 standard voucher that will be used to post the transaction.

If you use a type 3 standard voucher, multiple account entries can be created, 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).

… which text will be the voucher text for the transactions offsetting the bank transactions created during the allocation.

Program ID/PanelValid alternatives

1 = No voucher text

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

3 = Name of bank. This 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.

4 = Built-up text. This means that the voucher text will be built up by values from several fields in the following order: The bank statement number (ABS100/B)/the statement line's page number (ABS101/E)/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 (accounting dimension 1) on (CRS630/E) will be used.

6 = Description from text identifier. This means that the description of the text identifier in (ABS940) that was used to retrieve additional information will be used.

7 = Invoice voucher text. This means that the voucher text from the invoice that is paid during bank statement processing will be used.

Scenario for Allocating Invoices (Scenario Types 2 and 3)

… 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 will be created (scenario types 4 or 5). However, it can also be used to narrow the search of an invoice to allocate to a statement line (scenario types 2 or 3).

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

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 can for example be the case if your company processes a limited number of invoices.

When you select alternative 2 the same customer/supplier will always be 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.

… from where the customer/supplier (that is, the account holder) is to be retrieved.

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.

3 = Payer/Payee bank account number. This means that the payer/payee bank account number displayed for the statement line on (ABS101/E) will be 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) will be used to identify the customer/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). The customer order number can be entered in any of the five fields available for additional information numbers on (ABS102/E).

… the customer/supplier (that is, the account holder) to use when searching for and allocating invoices to bank statement lines (scenario types 2 or 3) or to use when creating on-account payments (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.

… how to automatically retrieve the invoice(s) to allocate to the bank statement line.

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.

Explanation of alternatives

Alternative 1 means that the invoice number specified for the statement line on (ABS102/E) will be 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 will be used to find the invoice in one of the transaction files. The additional information structure in (ABS930) controls how this will be done.

Alternative 3 means that the information category specified for the scenario on (ABS911/E) will be 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 will be done.

Alternative 4 means that the amount specified on the statement line on (ABS101/F) will be 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 (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 information category that will be 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.

… whether there should exist only one invoice with the same amount as the bank statement line, in order for an invoice to be allocated to the line.

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

Alternatives 2 and 3 mean that if several invoices with the same amount are found, the oldest/newest invoice with the specific amount (according to the invoice date) is the invoice that will be 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.

This field can be selected 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, can be 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.

Example

The additional information file includes the following string:

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

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

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

… the type of transaction that will be created through the scenario number during automatic allocation. This field is only used for scenario numbers defined for scenario type 4.

Valid alternatives

1 = On-account

2 = On-account with given number

3 = Debit note with given number.

Explanation of alternatives

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 can be created for 100 USD, using the next available number from number series 52-1 in (CRS165). This on-account payment will be 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 has paid 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 will be 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 will be 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, will not be 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'.

… 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 will be created through the scenario number.

Valid alternatives

1 = From FAM function

2 = From payer

3 = Use fixed.

Explanation of alternatives

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 will be used for all transactions created through the scenario number.

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

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

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 will be 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 will be 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 will be 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) will be 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 will be posted on accounting rule AB10-185, and the status of the bank statement line will be 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 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).

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

Valid alternatives

1 = Current user

2 = From payer

3 = Use fixed.

Explanation of alternatives

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, will be 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 will be set as the responsible user for all debit notes created through this scenario number.

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

… the number of days that will be 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.

Examples

If the value date is June 1, and the number of days is set to 5, the follow-up date will be set to June 6.

If the value date is June 1, and the number of days is set to 0, the follow-up date will be 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.

… 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 will be created (scenario types 4 or 5). However, it can also be used to narrow the search of an invoice to allocate to a statement line (scenario types 2 or 3).

Valid alternatives

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

… from where the customer/supplier (that is, the account holder) is to be retrieved.

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.

… whether the scenario will be 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.

… how to automatically retrieve the invoice(s) to allocate to the bank statement line.

Valid alternatives

3 = Information category.

… the information category that will be 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.

Valid alternatives

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.

… how to automatically retrieve the invoice(s) to allocate to the bank statement line.

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) will be 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 will be used to find the invoice in one of the transaction files. The additional information structure in (ABS930) controls how this will be done.

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