Have you ever seen a deleted document in the Posted Document, e.g. Posted Purchase Receipt?
That is because of this:
When you post the Purchase Order, at some point it will get the Purchase Receipt No. from the Receiving No. Series. It will increment from the Last Used No. in that Receiving No. Series. Once gotten, it will update the Last Used No in that No. Series. That no. will be used in the Receiving No. in Purchase Header.
At some point later, there is a COMMIT code, so that Receipt No. is already reserved. Once there is a COMMIT code and you get an error after the COMMIT, you can’t rollback to the initial state before the Purchase Receipt get the number. Hence the Receipt No. is already reserved.
Because of the audit trail requirement, Posted Document No. cannot be missing. But in this case, the Purchase Order has reserved the Receipt No. Hence, when somehow you must delete the Purchase Order, NAV will create (post) a Posted Document using that reserved number. But, with the line description as Deleted Document, to make it clear to the user, that this is created from a deleted document, instead of posting transaction.
There is a scenario where the Inventory Quantity is already 0, but the value is still there.
One of the cause is because of the Charge (Item).
Post Purchase Receipt with the cost of 1000.
Post Sales Shipment.
Post Purchase Invoice, Charge Item with the cost of 200 , assign it to the Purchase Receipt.
Run the Adjust Cost Item Entries.
Run the Inventory Valuation report.
It will show you on the Actual Cost line, that the Qty. is 0, but the Value is 200.
In NAV 2017, there is a Template feature, for example in Item card.
We can setup the Template, with the default value we want to fill the master card with. For example: for Retail items, the Gen. Prod. Posting Group is RETAIL, while for Manufactured items, must be MANUFACT.
Then, each time we create a new item card, we can fill those fields with the default values, based on the template card. Saves time, and reduce human error as well.
But, the fields are limited. Luckily, we can extend the functionality by adding the new fields we need.
As you may know, that Description in Item Ledger Entry is always blank, except if you change the Description in Journal Lines or Order Lines, so that it would be not exactly the same with the Item Description (Reference).
However, this is a standard design. But, if you want to alter this behaviour, you can change the code in:
Codeunit 22 Item Jnl.-Post Line
LOCAL InitItemLedgEntry(VAR ItemLedgEntry : Record "Item Ledger Entry")
IF ItemLedgEntry.Description = Item.Description THEN
ItemLedgEntry.Description := '';
Maybe all of you already know how to filter the Sales Orders that partially shipped. I will write it here just for a simple reminder.
When using Journal, if the Journal Batch Name contains any number, then if all the lines are posted, and none lines remaining, then NAV will automatically delete the Batch Name, and create a new Batch Name by incrementing the Batch Name, ie. BATCH-01A will be BATCH-02A.
Although this feature is not used publicly by the customers, this feature is existing and no setup to manage that.
However, the code responsible for that job lies in: Continue reading
NAV2015 introduced new object merge functionality to ease upgrading of NAV databases dramatically. For information about the cmdlets you could start here: I reported an issue to Microsoft back in t…
Source: Caution! The merge cmdlets might merge incorrectly!