web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

News and Announcements icon
Community site session details

Community site session details

Session Id :
Small and medium business | Business Central, N...
Suggested Answer

"In-Transit location TRANSIT for transfer orders only" &"Item is not in inventory" errors

(1) ShareShare
ReportReport
Posted on by 38

Hi everyone,

I am facing aNl issue in Microsoft Dynamics NAV 2018 when processing Transfer Orders.

The First Error: In-Transit Location Validation

On some items, when posting a Transfer Order, the system throws the classic error:
"You can use In-Transit location TRANSIT for transfer orders only."

Upon investigating the database, we found a clear pattern: All items throwing this error have historical entries in the Item Ledger Entry (Table 32) and Value Entry (Table 5802) tables where the Location Code is set to 'TRANSIT', but the Order Type field is completely BLANK (0 instead of 2 for Transfer).

 

The Second Error: "Item is not in inventory"

However, I tried to try another item that has order type blank in item ledger entries and see if the same in-transit location error would show. When trying to post a Transfer Order, we got this error: "Item [Item_No] is not in inventory."

We debugged the posting process and caught the exact standard code block where this is triggered:

CheckItemInInventory(TransLine : Record "Transfer Line")
WITH Item DO BEGIN
    GET(TransLine."Item No.");
    SETFILTER("Variant Filter",TransLine."Variant Code");
    SETFILTER("Location Filter",TransLine."Transfer-from Code");
    CALCFIELDS(Inventory);
    IF Inventory <= 0 THEN
      ERROR(Text009,TransLine."Item No.");
END;

 

The Conflict (Why Workarounds Fail):

To bypass this inventory block and push the code forward to test the In-Transit issue, we tried to post a Positive Adjustment via an Item Journal to add fresh stock.

Surprisingly, the system still blocks us. Even with a positive adjustment line, the system fails with the inventory error. It appears that during CALCFIELDS(Inventory) or the background Automatic Cost Adjustment routine (Adjust Cost - Item Entries), the system loops through the item's history. Because it hits those old entries with the blank Order Type, the calculation breaks in system memory, falsely evaluating the inventory as <= 0.

My Questions:

  1. Has anyone experienced a scenario where a blank Order Type on historical entries blocks both the In-Transit validation and  what has happened to these items that all of them have no inventory and can not be posted?

  2. Since these are posted historical entries, what is the safest best practice to fix the blank Order Type field? Should we proceed with a direct SQL Update statement on the Value Entry / Item Ledger Entry tables (setting Order Type = 2)?

Thanks in advance.

sc3.png
I have the same question (0)
  • Suggested answer
    Grigorios Mavrogeorgis Profile Picture
    2,116 Super User 2026 Season 1 on at
    Hi,
    I have seen something similar in NAV 2016, though I cannot say for sure without looking at your data. One thing worth checking first is the Order Type on those historical In-Transit entries. In some databases, especially after migrations or customisations, that field ends up blank where the transfer validation expects a Transfer value. If the entries cannot be classified, you can get both errors you describe.
    Your second error may be the same root cause, when CALCFIELDS reads those entries with a blank Order Type, the inventory flow can come out wrong and block the positive adjustment too. So maybe not two problems but one.

    On fixing, I would be very careful with direct SQL on Item Ledger Entry and Value Entry, these are sensitive for costing. Before touching anything, check the actual Order Type option definition in your own object, the index value is not the same in every database if there is customisation. And check both tables, not just one. Personally I prefer a small correction codeunit reading and rewriting through the record rather than raw SQL.

    Do you know if these entries came from a migration? That usually explains how many are affected.

    Hope this help, Best regards.
    ✅ Tick the checkbox below to mark the answer as verified, if it helped resolve your question.
     
    Regards
    Gregory Mavrogeorgis
     

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Season of Sharing Community Challenge Launch!

Jump in, show your community spirit, and win prizes!

Meet the Microsoft Dynamics 365 Contact Center Champions

We are thrilled to have these Champions in our Community!

Congratulations to the April Top 10 Community Leaders

These are the community rock stars!

Leaderboard > Small and medium business | Business Central, NAV, RMS

#1
OussamaSabbouh Profile Picture

OussamaSabbouh 2,273 Super User 2026 Season 1

#2
YUN ZHU Profile Picture

YUN ZHU 1,669 Super User 2026 Season 1

#3
AndrewThomas81 Profile Picture

AndrewThomas81 1,402

Last 30 days Overall leaderboard

Featured topics

Microsoft Training Manuals

Product updates

Dynamics 365 release plans