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 
...
WITH ItemJnlLine DO BEGIN
 INIT;
 CopyFromPurchHeader(PurchHeader);
...
[External] CopyFromPurchHeader(PurchHeader : Record "Purchase Header")
"Posting Date" := PurchHeader."Posting Date";
"Document Date" := PurchHeader."Document Date";
Advertisements

Deleted Document

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.

Inventory Value is not Zero when the Quantity is

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).

Repro steps:
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.

Add new fields on Item Template Card

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.

Continue reading

Description in Item Ledger Entry

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 := '';
...

Incrementing Batch Name in Journal Batch Name

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