How it Works NAV 2018 Wiki

Suggest Accounts on General Posting Setup

Since Microsoft Dynamics NAV 2018, there is an interesting new feature, Suggest Accounts on General Posting Setup page.

Suggest Accounts button on General Posting Setup page.

Unfortunately, there is no detail information on how this work. Even on official documentation from Microsoft:

A new smart algorithm suggests posting setup accounts on posting setup lists. Simply add combination of posting groups you want to set and click Suggest Accounts. The algorithm will analyze existing posting setup you already have and suggest G/L accounts from similar posting setup. You can however disagree with the suggestion and change it to fit your needs.

So, here I want to explain how it works and the logic behind it in a simple way.

Let’s say you create a new line, INTERCOMP x SERVICES, and then click the Suggest Accounts button.

It will analyses the accounts used in the falling category, then based on that, will choose the most used one as the suggestion.

First, it will collect all the records with the INTERCOMP in Gen. Bus. Posting Group, except the current Gen. Prod. Posting Group in question: SERVICES:

Second, it will collect all the records; this time with Gen. Prod. Posting Group of SERVICES, except the INTERCOMP in the Gen. Bus. Posting Group.

And then collect them all in one table:

Next, is to determine the most used Account No. in those category, using PivotTable:

From the PivotTable, we can see the winner is Account No. 6120 with 4 counts.

Let’s prove it in NAV:



So, what is it about?

By choosing the most used account, it means that the big probability that it will be used also in this setup in question.

Let’s revisit this image. From the image below, we learnt that the Sales Account is more based on Gen. Bus. Posting Group, instead of Gen. Prod. Posting Group. Hence, for our new setup of INTERCOMP x SERVICES, it will be likely the same as the other INTERCOMP: 6120.

But, what if the suggestion is incorrect?

You can just replace the account with yours. It yours to decide. In the end, it is just a suggestion. Cool, isn’t it?


Wait. What if the condition is like this?

Since it is coded to sort Ascending by the Count and it is draw, unfortunately it will take the last record as the winner. Yes, 6470 is chosen.

Pretty unfair guess, isn’t it?

That’s all about the choosing of only a single field, Sales Account. The system will continue to search for the other fields too, i.e. Purchase Account, Inventory Adjustment Account, etc.



Its smart algorithm can quite help us to do this tedious works, when the pattern is quite obvious. It means it has to be had enough data.


For the draw condition, it is still suggesting the last account as the chosen one; sort Ascending by the Account No. Kind of naive for me. I suggest if the condition is hard to see the winner, why don’t just pop up a message something like “This is a draw condition, hence there is no winner”, instead of “lucky winner”.

And because the algorithm is using the available data, hence if you start using the button from the scratch, it would not work, because there is no data to compare, right? And yet, there is no message to inform you about this. You can use this button to help you decide the account, some time in the future, when the setup is complete after gone live for some time. For the initial setup before going live, I prefer to use the Copy button to copy from the other known setup, with the same setup.

Reminder Tips & Tricks Wiki

Receipt Status of the Purchase Order

Hello! Welcome back to my blog.

We have a question: how do we know the receiving status of the Purchase Order, whether:

  • Not yet received at all
  • Partially received, or
  • Fully received

Actually, it is very simple, yet tricky.

You can filter on the Purchase Header like this:

  • Not yet received at all:
    • Completely Received: No
    • Receive: No
  • Partial receipt:
    • Completely Received: No
    • Receive: Yes
  • Full receipt:
    • Completely Received: Yes

Question is, what is field Receive?

How can we utilize that field to filter on partial receipt?

During posting routine, there is a code to activate that flag, to inform the system that we are going to post Receive. After the posting is done successfully, the flag is kept TRUE.

Hence, it means that after we successfully post receive once, the field Receive is TRUE. On the other hand, if Receive is TRUE, then it means that there is at least one receipt.

Furthermore, we can combine with Completely Received to know whether the receipt is already full.

See you at another post!

BC 14 Wiki

Qty. to Assemble (ATO)

When using Assemble-to-Order on Sales Order, the Qty. to Ship field on Sales Order will be transferred into Qty. to Assemble on Assembly Order header.

BC 14 Reminder

No Records When Purchase Invoice Get Receipt Lines

Have you ever experienced, create a new Purchase Invoice, then Get Receipt Lines, but no lines visible? In the other hand, you are very sure that they are not invoiced yet.

The filters are below:

That way, you should check that your:

  • Pay-to Vendor No.
  • Currency Code

Please make sure that they have the same values as the Purchase Order or Purchase Receipt.

BC 14 Tips & Tricks

More Informative Posting Date Error

There was a problem where the error message on ACIE was not mentioning the blocked Posting Date but for NAV 2018.

Since the function in BC is different, you can change the code here:

Code unit 5700 User Setup Management

[External] CheckAllowedPostingDate(PostingDate : Date)
IF NOT IsPostingDateValid(PostingDate) THEN
// ERROR(PostingDateRangeErr); //Remove
ERROR(InformativePostingDateRangeErr, PostingDate); //Add

NAV 2018 Tips & Tricks

“The Posting Date is not within your range of allowed posting dates” when Adjust Cost Item Entries

Have you experienced when posting, then you got this error?

The Posting Date is not within your range of allowed posting dates.

Usually, this is because the Posting Date in the transaction is falling outside of the Allowed Posting Date.

But in this case, we have checked and confirmed that the Posting Date is OK. So, what is the problem?

Please check the Inventory Setup, for Automatic Cost Adjustment. If it is other than “Never”, then we can be sure that the error message is coming from the Adjust Cost Item Entries (ACIE) process.

So, the solution is to run the ACIE process first, then back to post the transaction again.

But, wait. I don’t know, what Date should I open.

Let’s change some code to better inform that:

Codeunit 21 Item Jnl.-Check Line
LOCAL CheckAllowedPostingDate(ItemJnlLine : Record "Item Journal Line")
IF ("Posting Date" < AllowPostingFrom) OR ("Posting Date" > AllowPostingTo) THEN
ERROR(InformativePostingDateRangeErr, "Posting Date"); //Add this line
//FIELDERROR("Posting Date",Text001) //Remove this line

With Text Constant: InformativePostingDateRangeErr: The Posting Date %1 is not within your range of allowed posting dates.

This way, we get the better informative error message:

The Posting Date 28-01-21 is not within your range of allowed posting dates.

Better, isn’t it?

This code is intended for NAV 2018. If you are newer, you can read here.

Tips & Tricks

Precaution When Deleting Company

We must very often to use Copy Company feature. Usually, after some time, we want to delete the test company.

A special caution is must be used when you want to delete the company, otherwise you could accidentally deleting the production company.

Hence, one wise recommendation is to open first the production company, then do the deletion from that production company.


Let’s try it:

The company currently in use cannot be deleted. Switch to a different company before deleting the Production company.

Safer, isn’t it?


Error Messages that causing Deleted Document

Have you experienced the Deleted Documents?

We know that not all error messages are causing this Deleted Document.

Want to know what error messages are causing it?

Here is the list:

  • Purchase Invoice xxx already exists for this vendor.
    This is happened when you fill the duplicate Vendor Invoice No. upon posting receive and invoice on Purchase Order
BC 14

Code of Insert into Item Ledger Entry

Where is the code of inserting into Item Ledger Entry (32)?
Codeunit 22 Item Jnl.-Post Line
LOCAL ItemQtyPosting()

NAV 2018 Reminder

Automatic Expiration Calculation

If we want to use the automatic Expiration Date calculation, then on Item Tracking Code Card, don’t tick the Man. Expir. Date Entry Reqd. If you tick this, then NAV will force you to fill the Expiration Date manually on Item Tracking Lines.

Then, on Item card, on Expiration Calculation, fill it with date formula, like 1Y stands for 1 year.

Next, the question is what is the date used to calculate the Expiration Date?

For Purchase Order, the date used is the Document Date. Why Document Date? Don’t know.

Fortunately, if using Warehouse Receipt and Inventory Put-away, there is no Document Date, and the Document Date on the Purchase Order is defaulted to be the same as Posting Date. So when it is posted with Posting Date of 30 April 2018, then the Document Date will also be the same.

So, if we are using Warehouse Receipt or Inventory Put-away, this will not become a problem. But, if we use Purchase Order, then the problem may rise, if after change the Posting Date, the user override the Document Date.

The source code is here:

LOCAL SetupSplitJnlLine(VAR ItemJnlLine2 : Record "Item Journal Line";TrackingSpecExists : Boolean) : Boolean
 IF FORMAT(Item."Expiration Calculation") <> '' THEN
 CalcExpirationDate := CALCDATE(Item."Expiration Calculation",ItemJnlLine2."Document Date");
LOCAL PostItemJnlLine(PurchHeader : Record "Purchase Header";PurchLine : Record "Purchase Line";QtyToBeReceived : Decimal;QtyToBeReceivedBase : Decimal;QtyToBeInvoiced : Decimal;QtyToBeInvoicedBase : Decimal;ItemLedgShptEntryNo : Integer;ItemChargeNo 
[External] CopyFromPurchHeader(PurchHeader : Record "Purchase Header")
"Posting Date" := PurchHeader."Posting Date";
"Document Date" := PurchHeader."Document Date";