Bank Data Conversion Service for NAV 2015

Few months ago, when I wrote about Posting Groups and Payment Posting, I got a few comments about some related topic. This topic was a Bank Data Conversion Service for Microsoft Dynamics NAV 2015 as part of the improved reconciliation capabilities. This service hosted on Microsoft Azure is delivered by AMC Consult A/S and provides automatic processes fro electronic payments, payment reconciliation and bank account reconciliation in NAV.

I didn’t have enough time to write about this topic, but now Microsoft has published article about this topic. Sorry to my followers because I didn’t finish it faster then Microsoft, but I can help them with relations to information. You can find a lot of information and additional documents (pptx and videos) on Partner Source: https://mbs.microsoft.com/partnersource/global/readiness-training/readiness-training-news/BankDataConversionServicebyAMCConsult.

Advertisement

Posting Groups #14 – Payment Discounts

One of features in Microsoft Dynamics NAV is using of payment discount. You can configure conditions of using this functionality on General Ledger Setup. With this configuration, I mean on Appln. Rounding Precision and Payment Tolerance and types of Payment Accounts from Customer Posting Groups. More about this configuration, you can find using Help for these fields.

We can use payment tolerances and discounts in few different situations. You can see how it generally works on following flowchart:

##1

In my first example, I have configured only payment tolerance without discounts. When we post payment some less from original amount on invoice (e.g. 2.395 instead 2.400), we will get following G/L entries:

##2

If our payment is greater than Invoice Amount reduced by discount, we will get following entries. System will post full payment as original invoice amount plus tolerance and discount, as well:

##3

If payment is less than Invoice Amount reduced by discount, we will get following entries. System will post full payment as original invoice amount, discount and tolerance:

##4

Posting Groups #12 – Payment Posting

When we post payments, we usually have payments for customers and from vendors. In the same time, we should have bank account posting as balance accounts. Bank account is not necessary, but it is the best practice.

When we post payments from bank statement, we will get the same G/L entries, regardless we have payment in local currency or in some other. These are entries as following:

1PaymStat

If we use non-local currency in payment process, after running Adjust Exchange Rate batch job, we will get the following G/L entries:

2PaymAdjustER

In previous example, you could see result if used currency exchange rate was increased. But, if exchange rate was decreased, the posting results in G/L entries would be as following:

3PaymAdjustER

All previous results were unrealized exchange rates gains or losses, but when we apply these payments, we will get realized exchange rates as on following table:

4PaymApply

All postings, based on difference currency code, use posting groups and accounts as on following flow chart:

AdjFlowChart

Posting Groups #9 –Item Sale Posting with Payment Method

I have already showed item sale process posting here in Posting Group #2 post. But, we can have some specific variants of this posting. One of them is when we use Payment Method.

If you choose Payment Method code on sales document header, and this Payment Method has configured Bal. Account Type and Bal. Account No., NAV will automatically create the balancing journal line. This functionality is great when we are being paid in full at the time of sale, but we can use this feature in some other specific process.

You can see how system works with Payment Method on following flow-chart:

SalesPMC

When we finish with this Sales Order posting, we can find following G/L entries navigated to Posted Sales Invoice. You can see standard G/L entries about invoice and the last two of them, connected with Payment:

SI_PyM_GLe