DTA Suggest Vendor Payments Batch Job
Transfers overdue invoices into the journal. On the Vendor FastTab, you can select the individual vendors.
Options
| Option | Description |
|---|---|
Posting Date |
Enter the credit date for the payment. This is important for payment discounts. |
Due Date from |
Enter the start date for the open invoices. |
Due Date to |
Enter the end date for the open invoices. |
Process Cash Discounts |
Specify if you want cash discount payments outside the due date range. |
Cash Disc. Date from |
Enter the start date for the cash discount. |
Cash Disc. Date to |
Enter the end date for the cash discount. |
Available Amount (LCY) |
Enter the maximum value of the sum of all payments. Entries are transferred until the amount is reached. Set a filter on the Priority field so that the payments for your most important vendors are processed first. |
First Doc. No. |
Enter the payment suggestion document number. |
Debit to Bank |
Specify the bank code, if this is independent of other default settings, the debit only goes to one bank. |
Auto. Debit Bank |
Select the debit bank depending on the currency code. |
For more information about debit bank, see the Debit Bank field.
Additional Information
Adjust Currency
When batch processing DTA payment suggestions, the FCY amount is converted to LCY at the current rate for FCY payments and transferred into the payment journal.
This can be different from bank debit, which occurs a few days later. Typically, the user overwrites the debited LCY amount over the LCY amount when the bank debit comes in, then the exchange rate (exchange factor) is recalculated.
If there many payments are in FCY, the rate correction can be copied from one line to all other lines with the same currency code. This is accomplished using the following procedure:
Place the cursor on a line with the currency of interest.
Choose the Currency Code field.
Correct the rate.
When you close the window, Microsoft Dynamics NAV checks if additional postings in the journal exist with the same currency code and displays a message about it.
Confirm that the rate will be automatically adjusted for the other postings.
When posting the payment, the difference between invoice and payment rate is automatically posted as realized exchange rate adjustment.
Invoice, Payment, and Debit Currency
There are three different types of currency for invoicing and posting the payment debit: invoice currency, payment currency, and debit currency. The following options provide example combinations of how you can apply the currency types:
Invoice in EUR, payment in EUR, debit in LCY,
Invoice in EUR, payment in USD, debit in LCY
For the payment suggestion, the payment currency is transferred from the invoice currency into the journal.
Debit Not Equal to Payment Currency
If a separate bank account does not exist for all payment currencies, payment and debit currencies are different. The bank uses the current exchange rate for the payment. For the payment suggestion, the debit rate is therefore not yet known, unless the rate is fixed with the bank.
Payment Not Equal to Invoice Currency
If the payment currency is different from the invoice currency, then the user must define the exchange.
The following example is based on an invoice of 100 DKK, which will be paid in euro.
Rate 100 LCY = DKK 500.00, 100 DKK = LCY 20.00, 100 LCY = EUR 150.
The user also has to define how many euro he should pay for the 100 DKK.
The payment suggestion has transferred 100 DKK in the journal. Amount 100, Amount (LCY) 20.00
The currency code is corrected for euro. Microsoft Dynamics NAV obtains the euro rate and calculates the current amount in LCY. Amount 100, Rate 1.50 Amount (LCY) 150.00
The amount must be redefined by the user. For the 100 DKK, only 13.00 euro should be paid. Microsoft Dynamics NAV recalculates the amount (LCY). Amount 13.00, Rate 1.65 Amount (LCY) 21.45.
For the payment suggestion, the balance account is used according to the debit bank.
Balance Account in the Journal
In the first phase, batch processing for the DTA payment suggestion enters the payment lines in the journal without the balance account.
At the end of batch processing, a payment is made for all lines with type vendor, and a balance account line is generated for each debit bank and currency code.
If the payment suggestion is edited (postings added, deleted, amount changed, rate changed, and so on), the amounts in the balance account lines no longer match the total of the changed payment lines. The journal could not be posted, because the balance of the debit and credit postings is no longer 0.
If payments are made in foreign currencies, the debit rate is often different from the provisionally specified rate. The amount (LCY) is corrected for each line as the debit comes in, so that it matches the debit. It is also possible to adjust the rate and update all other lines with the same currency. For rounding differences and bank charges, additional posting may be required. If the balance account lines are regenerated, the amount and amount (LCY) in all lines are added and the average rate is calculated.
Note
You can make payments at different rates with a balancing entry.
Check Open Credits for Payment Suggestion
Generally, the application method for open entries is used for the vendor general ledger. Credits and payments are applied by the user with invoices. For credits and payments that cannot be applied immediately with an open invoice, such as advertising credit, or returns, it is possible to forget that a credit memo still exists when you post a later invoice. Paying the whole amount instead of offsetting the credit should be avoided.
During the payment suggestion, a check is made to determine whether open payments or credits exist for a vendor, for whom an invoice must be paid. In this case, these vendor numbers are saved temporarily and a message is given at the end of the payment suggestion. The users can then apply the credit with an open entry, reduce the payment, or clear the payment suggestion and repeat the process.
The payment display lists, by their payment line, credits, and payments that result in a partial payment, which is payment of remaining amount.
Get or Create Bank when Importing the Coding Line
A missing vendor bank can be partially or fully created by Microsoft Dynamics NAV. If, when importing the ESR using the ESR, Giro, or bank account number, the vendor is not recognized, Microsoft Dynamics NAV requests to define the vendor and import the payment slip again. The next time this is read, a bank record is filled in that can be added to by the user: Doc.No. StartPos, BankAccount for EZ Bank, and possibly General Ledger Bal.Acc.
During automatic creation, the payment type, such as ESR or EZ Post, is used as the bank code, which is derived from the length of the coding line when reading.
Tip
For more information on how to work with batch jobs, see How to: Run Batch Jobs and How to: Set Filters. For assistance in finding specific pages, see Search.