You can set up a payment tolerance to close an invoice when the payment does not fully cover the amount on the invoice. You can set up a payment discount tolerance to grant a payment discount after the payment discount date has passed.
You can use payment tolerances so that every outstanding amount has a set maximum allowed payment tolerance. If the payment tolerance is met, then the payment amount is analyzed. If the payment amount is an underpayment, then the outstanding amount is fully closed by the underpayment. A detailed ledger entry is posted to the payment entry so that no remaining amount is left on the applied invoice entry. If the payment amount is an overpayment, then a new detailed ledger entry is posted to the payment entry so that no remaining amount is left on the payment entry.
You can use payment discount tolerances so that if you accept a payment discount after the payment discount date, then it is always posted to either the payment discount account or a payment tolerance account.
A single document has the same payment tolerance whether it is applied on its own or with other documents. Acceptance of a late payment discount when you are applying payment tolerance to multiple documents automatically occurs for each document where the following rule is true:
payment discount date < payment date on the selected entry <= payment tolerance date
This rule also applies to determine whether to display warnings when you apply payment tolerance to multiple documents. The payment discount tolerance warning is displayed for each entry that meets the date criteria. For more information, see the "Example 2 - Tolerance Calculations for Multiple Documents" section.
You can choose to display a warning that is based on different tolerance situations.
For more information, see the "To enable or disable payment tolerance warning" section.
Tolerance on days and amounts allows you to close an invoice even though the payment does not fully cover the amount on the invoice, whether this is because the due date for the payment discount has been exceeded, goods have been deducted or because of a minor error. This also applies to refunds and credit memos.
To set up tolerance you have to set up various tolerance accounts, specify both payment discount tolerance and payment tolerance posting methods and then run the Change Payment Tolerance batch job.
You have now set up tolerance for local currency only. If you want Dynamics NAV to handle tolerance on payments, credit memos, and refunds in a foreign currency, you must run the Change Payment Tolerance batch job with a value in the Currency Code field.
If you want to get a payment tolerance warning every time that you post an application in the tolerance, you must activate the payment tolerance warning. For more information, see the "To enable or disable payment tolerance warning" section.
To deactivate tolerance for a customer or vendor, you must block tolerances on the relevant customer or vendor card. For more information, see the "To block payment tolerance for customers" section.
When you set up tolerance, Dynamics NAV also checks if there are any open entries and calculates the tolerance for these entries.
The payment tolerance warning appears when you post an application that has a balance in the allowed tolerance. You can then choose how you want to post and document the balance.
The default option for the Payment Tolerance Warning window is Leave the Balance as Remaining Amount. The default option for the Pmt. Disc. Tolerance Warning window the is Do Not Accept the Late Payment Discount.
The default setting for payment tolerance is allowed. To disallow a certain customer or vendor payment tolerance you need to block tolerance on the respective customer or vendor card. The following describes how to do it for a customer. The steps are similar for a vendor.
If the customer or vendor has open entries, you must first remove payment tolerance from entries that are currently open.
The following are some example scenarios showing the expected tolerance calculations and postings occurring in different situations.
The G/L Setup window contains the following setup:
Scenarios with alternative A or B represent the following:
— | Inv. | Pmt. Disc. | Max Pmt. Tol. |
Pmt. Disc. Date | Pmt. Disc. Tol. Date | Payment Date | Pmt. | Tolerance Type | All Entries closed | Pmt. Disc. Tol. GL/CL |
Pmt. Tol. G/L |
---|---|---|---|---|---|---|---|---|---|---|---|
1 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | <=01/15/03 | 985 | Pmt.Tol. | Yes | 0 | -5 |
2 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | <=01/15/03 | 980 | None | Yes | 0 | 0 |
3 | 1,000 | 20 | 5 | 01/15/03 | c | <=01/15/03 | 975 | Pmt.Tol. | Yes | 0 | 5 |
4A | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | 01/16/03 01/20/03 | 1005 | Pmt.Disc.Tol. | No, 25 on the Pmt. | 20/-20 | 0 |
5A | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | 01/16/03 01/20/03 | 1000 | Pmt.Disc.Tol. | No, 20 on the Pmt. | 20/-20 | 0 |
6A | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | 01/16/03 01/20/03 | 995 | Pmt.Disc.Tol. | No, 15 on the Pmt. | 20/-20 | 0 |
4B | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | 01/16/03 01/20/03 | 1005 | Pmt.Tol. | Yes | 0 | -5 |
5B | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | 01/16/03 01/20/03 | 1000 | None | Yes | 0 | 0 |
6B | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | 01/16/03 01/20/03 | 995 | Pmt.Tol. | Yes | 0 | 5 |
7 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | 01/16/03 01/20/03 | 985 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 20/-20 | -5 |
8 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | 01/16/03 01/20/03 | 980 | Pmt.Disc.Tol. | Yes | 20/-20 | 0 |
9 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | 01/16/03 01/20/03 | 975 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 20/-20 | 5 |
10 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | >01/20/03 | 1005 | Pmt.Tol. | Yes | 0 | -5 |
11 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | >01/20/03 | 1000 | None | Yes | 0 | 0 |
12 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | >01/20/03 | 995 | Pmt.Tol. | Yes | 0 | 5 |
13 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | >01/20/03 | 985 | None | No, 15 on the invoice | 0 | 0 |
14 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | >01/20/03 | 980 | None | No, 20 on the invoice | 0 | 0 |
15 | 1,000 | 20 | 5 | 01/15/03 | 01/20/03 | >01/20/03 | 975 | None | No, 25 on the invoice | 0 | 0 |
In relation to the scenario above, the diagrams of payment ranges are as follows:
Remaining Amount per
Normal Application Rules
(1) If payment falls in these ranges, all application entries can be closed with or without tolerance.
(2) If payment falls in these ranges, all application entries cannot be closed even with tolerance.
Remaining Amount per
Normal Application Rules
(1) If payment falls in these ranges, all application entries can be closed with or without tolerance.
(2) If payment falls in these ranges, all application entries cannot be closed even with tolerance.
Remaining Amount per
Normal Application Rules
(1) If payment falls in these ranges, all application entries can be closed with or without tolerance.
(2) If payment falls in these ranges, all application entries cannot be closed even with tolerance.
The following are some example scenarios showing the expected tolerance calculations and postings occurring in different situations. The examples are limited to being only those scenarios that result in all entries in the application being closed.
The G/L Setup window contains the following setup:
Scenarios with alternative A, B, C, or D represent the following:
— | Inv. | Pmt Disc. | Max Pmt. Tol. | Pmt. Disc. Date | Pmt. Disc. Tol. Date | Payment Date | Pmt | Tolerance Type | All Entries closed | Pmt. Disc. Tol. GL/CL |
Pmt. Tol. G/L |
---|---|---|---|---|---|---|---|---|---|---|---|
1 | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
<=01/15/03 | 1920 | Pmt.Tol. | Yes | 0 0 |
-5 -5 |
2 | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
<=01/15/03 | 1910 | None | Yes | 0 0 |
0 0 |
3 | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
<=01/15/03 | 1900 | Pmt.Tol. | Yes | 0 0 |
5 5 |
4B | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/16/03 01/17/03 | 1980 | Pmt.Tol. | Yes | 0 0 |
-5 -5 |
5B | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/16/03 01/17/03 | 1970 | None | Yes | 0 0 |
0 0 |
6B | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/16/03 01/17/03 | 1960 | Pmt.Tol. | Yes | 0 0 |
5 5 |
7A | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/16/03 01/17/03 | 1920 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 60/60 0/0 |
-5 -5 |
8A | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/16/03 01/17/03 | 1910 | Pmt.Disc.Tol. | Yes | 60/60 0/0 |
0 0 |
9A | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/16/03 01/17/03 | 1900 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 60/60 | 5 5 |
10B | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 2010 | Pmt.Tol. | Yes | 0 0 |
-5 -5 |
11B | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 2000 | None | Yes | 0 0 |
0 0 |
12B | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1990 | Pmt.Tol. | Yes | 0 0 |
5 5 |
13D | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1980 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 0/0 30/-30 |
-5 -5 |
14D | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1970 | Pmt.Disc.Tol. | Yes | 0/0 30/-30 |
0 0 |
15D | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1960 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 0/0 30/-30 |
5 5 |
16D | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1950 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 60/-60 0/0 |
-5 -5 |
17D | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1940 | Pmt.Disc.Tol. | Yes | 60/-60 0/0 |
0 0 |
18D | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1930 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 60/-60 0/0 |
5 5 |
19A | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1920 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 60/-60 30/-30 |
-5 -5 |
20A | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1910 | Pmt.Disc.Tol. | Yes | 60/-60 30/-30 |
0 0 |
21A | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/18/03 01/20/03 | 1900 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 60/-60 30/-30 |
5 5 |
22B | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/21/03 01/22/03 | 2010 | Pmt.Tol. | Yes | 0 0 |
-5 -5 |
23B | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/21/03 01/22/03 | 2000 | None | Yes | 0 0 |
0 0 |
24B | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/21/03 01/22/03 | 1990 | Pmt.Tol. | Yes | 0 0 |
5 5 |
25A | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/21/03 01/22/03 | 1980 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 0/0 30/30 |
-5 -5 |
26A | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/21/03 01/22/03 | 1970 | Pmt.Disc.Tol. | Yes | 0/0 30/30 |
0 0 |
27A | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
01/21/03 01/22/03 | 1960 | Pmt.Disc.Tol. & Pmt.Tol. | Yes | 0/0 30/30 |
5 5 |
28 | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
>01/22/03 | 2010 | Pmt.Tol. | Yes | 0 | -5 |
29 | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
>01/22/03 | 2000 | None | Yes | 0 | 0 |
30 | 1,000 1,000 |
60 30 |
5 5 |
01/15/03 01/17/03 |
01/20/03 01/22/03 |
>01/22/03 | 1990 | Pmt.Tol. | Yes | 0 | 5 |
In relation to the scenario above, the diagrams of payment ranges are as follows:
Remaining Amount per
Normal Application Rules
(1) If payment falls in these ranges, all application entries can be closed with or without tolerance.
(2) If payment falls in these ranges, all application entries cannot be closed even with tolerance.
Remaining Amount per
Normal Application Rules
(1) If payment falls in these ranges, all application entries can be closed with or without tolerance.
(2) If payment falls in these ranges, all application entries cannot be closed even with tolerance.
Remaining Amount per
Normal Application Rules
(1) If payment falls in these ranges, all application entries can be closed with or without tolerance.
(2) If payment falls in these ranges, all application entries cannot be closed even with tolerance.
Remaining Amount per
Normal Application Rules
(1) If payment falls in these ranges, all application entries can be closed with or without tolerance.
(2) If payment falls in these ranges, all application entries cannot be closed even with tolerance.
Remaining Amount per
Normal Application Rules
(1) If payment falls in these ranges, all application entries can be closed with or without tolerance.
(2) If payment falls in these ranges, all application entries cannot be closed even with tolerance.
Finance
Setting Up Finance
Managing Receivables
Working with Dynamics NAV
© 2017 Microsoft. All rights reserved.