This document explains how you can pre-define to which banks and bank accounts specific supplier payments should be remitted when creating a payment proposal in 'Payment Proposal. Open' (APS130). The definitions are saved as so-called bank quotas.
Bank quotas are mainly used in Latin countries.
A bank quota table with definitions for how payments with certain values should be allocated to specific bank accounts is defined, based on the company policy.
The table can be reviewed in 'Bank Quota. Open' (APS030).
If you select the 'Use quotas' check box in 'Supplier Payment Proposal. Create' (APS131/E), the bank quota table is automatically applied to identify and allocate payments with the same values as in the bank quota keys.
The bank quota table is saved in the parameter file (CSYTAB).
The purpose of using bank quotas is to
You use bank quotas
Alternative Ways of Allocating Payments
There are actually three ways of allocating a supplier payment to a specific bank and bank account in M3:
The main difference between the first two alternatives is that with the bank quota table you can allocate payments with the same currency (and payment method) to several bank accounts. In the bank account connection table you can only enter one bank account for such a combination.
This means that using bank quotas give you more flexibility when managing your bank accounts.
By defining that bank quotas should be used when creating a payment proposal, payments matching the bank quota table are automatically identified. The corresponding banks are then specified in the final payment documents.
The bank quota table consists of one or several lines or keys. You can have several tables in 'Bank Quota. Open' (APS030). Only the table matching the payment proposal date will be used.
Bank Quota Keys
Each key consists of a combination of year, month, payment method, currency, priority level, and bank account. Some of these values are required, others are optional.
For each key a quota is entered, either as a percentage or as a fixed amount. This quota controls that only payments up to a certain amount are allocated to the particular bank account.
How the Bank Quota Table Is Applied
When you create the proposal, the following happens:
1. A table is identified in (APS030) based on this search path: 1) year, 2) month, 3) currency, and 4) payment method. If a table with all these four values does not exist, a table with the first three is selected, and so on. These values function like a magnet to select payments with corresponding values.
2. The key with the highest priority level is applied first. Payments matching the key are identified and allocated to the bank account.
3. When the quota does not allow for more payments to that bank account, the key with the second highest priority level is applied, and so on.
4. If any payments could not be allocated due to the table settings, these are included in an error list printed when creating the payment proposal.
5. When you confirm the proposal in 'Payment Proposal. Open' (APS130), the final payment documents are created. In each document the bank account to which the payment is allocated is stated.
To Consider When Defining a Bank Quota Table
The following examples illustrate this. Here tables with quota percentages are used but the same principle applies to tables with quota amounts.
|Invoice Amount||Quota Percentage||Actual Maximum Amount||Actual Amount Not Used|
|1,000||40%||2,500 x 0.40 = 1,000||0|
|600||30%||2,500 x 0.30 = 750||250|
|500||30%||2,500 x 0.30 = 750||150|
|= 2,500||100 %||= 2,500||= 400|
In this example, the total payment amount to be remitted is 2,500. The table consists of three keys in priority order with a quota defined as a percentage. The percentages are matched against the total payment amount. The result is here shown in the Actual maximum payment amount column, for the sake of clarity.
The first payment is allocated without any problem. The second and third as well, with the difference that only a part of the maximum amount for the respective key was used. However, the fourth payment is not allocated at all. Instead it is included with error status 8 (for quota amounts, status 4) in the error report that is printed together with the payment proposal. Although the remaining total amount allowed to allocate according to the table is 400, no single key has this amount left to allocate.
|Invoice Amount||Quota Percentage||Actual Maximum Amount||Actual Amount not Used|
|6,000||50%||10,000 x 0.50 = 5,000||1,000|
|3,000||30%||10,000 x 0.30 = 3,000||3,000|
|1,000||15%||10,000 x 0.15 = 1,500||1,500|
|5%||10,000 x 0.05 = 500||500|
|= 10,000||100%||= 10,000||= 6,000|
In this example, the first invoice cannot be allocated. The reason is that the first key can only be used for 50% of the total payment amount, that is 5,000. The following two invoices, however, are allocated to the bank account entered for the first key – their combined payment amount does not exceed these 50%. Since all invoices then are allocated, the other keys are not used.
Total Amount to Allocate
The allocation is based on the total payment amount of the proposal. This means that:
Note, however, that the allocation amount is not affected if you adjust the payment amount of a separate invoice in the proposal.
"Full" Bank Quota Keys
Keys with quota percentages can be used without limitation throughout the validity year or month. If you wish to have a more strict control of the exact amounts allocated, you can use keys with quota amounts instead.
For each new proposal created, the accumulated amount that has been allocated using a specific key is displayed. When this amount is the same as the quota amount, the key is "full" and you create a new, replacing key.
If you create a table with quota amounts, you need to have a realistic picture of the size of the company's payments to be able to define the quota keys in an optimal way.