Quantcast
Channel: Microsoft Dynamics NAV
Viewing all articles
Browse latest Browse all 64865

Forum Post: RE: Bug Fix - Check Management NAV 2013

$
0
0

Hi,

thank you for the explanation, I agree it's a bug. This seems to be limited to the NA localization, however it got me thinking on a specialty we have in (german) payment processing by clearing file. Usually, you would suggest all due entries, wether invoice or credit memo. All of these will be filled into the payment journal, with document type "payment". On clearing file creation, the payment text will be generated out of all matching journal lines, so that the netting of the documents will be shown in the transfer text - so you can save an avis document as long as the payment text of the transfer isn't full. When you want to post the journal afterwards you will get an error that the sign of the credit memo line doesn't match with the document type (payment). To get the journal posted you have two options:

1. Remove the document type from the whole journal. But this also means that no payment discount and (probably) no payment tolerance will be posted.

2. Remove the "force document balance" flag from the gen. jnl. template, and the document type from all credit memo lines. This will let you post the journal. However, InitCodeunit() will also generate a new transaction no. if the balance of the journal line is zero and the document type has changed. Fortunately, this isn't the case in payment journals (the payment file creation will present an error for a net payment of <= 0), but it would be open for interesting transaction no. patterns when this flag is removed from the gen. jnl. template in other cases. To avoid it you would have to fix InitCodeunit() with a check of the gen. jnl. template, like it's done in CU 13.

with best regards

Jens


Viewing all articles
Browse latest Browse all 64865

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>