Small and medium business | Business Central, N...

Production Order consumption error - Item tracking is signed wrongly

(6) Share

Report

Posted on by HS-18110301-0

Hi - Since the latest minor update from Microsoft to our Business Central environment, we have come across an issue when attempting to post consumption for a production order with the production journal.

This is happening sporadically, with different items at different times and so far no noticeable pattern.

Scenario -

We are posting partial consumption for an item i.e. Qty picked = 5.25 units but we want to post 0.75 units at a time.

Process followed is to open the production journal, click on item line, navigate to item tracking lines, change qty to 0.75 units and then change qty in Production journal line to match. When attempting to post we get an error message I have never seen before - Item Tracking signed wrongly.

What I have noticed is that BC does not seem to be keeping up with consumption and there is then a mismatch in the quantities somewhere.

e.g for the above example,

We have picked 5.25 units

We have consumed 2.25 units in total in the following entries

Logic states that 5.25 - 2.25 = 3 units remaining, however on our components line we have a remaining qty of 3.074, which is the exact qty of the most recent consumption.

It therefore seems quite clear that the system has not quite registered the most recent consumption in some places but it has in others.

Has anyone else come across this before?

We attempted to debug and got the following;

RemQtyToPost = 0.7
RemQtyToPostThisLine = 3.704

if RemQtyToPostThisLine > RemQtyToPost then
RemQtyToPostThisLine := RemQtyToPost

RemQtyToPostThisLine = 0.7

QtyToPost := RemQtyToPostThisLine;
QtyToPost := 0.7

NewRemainingQty := ProdOrderComp."Expected Qty. (Base)" - ProdOrderComp."Act. Consumption (Qty)" - QtyToPost;
NewRemainingQty := 5.25 - 2.25 - 0.7
NewRemainingQty := 2.3

QtyToPost := ProdOrderComp."Remaining Qty. (Base)" - NewRemainingQty
QtyToPost := 3.704 - 2.3
QtyToPost := 1.404

ProdOrderComp."Remaining Qty. (Base)" := NewRemainingQty;
ProdOrderComp."Remaining Qty. (Base)" := 2.3

if QtyToPost <> 0 then

RemQtyToPost := RemQtyToPost - QtyToPost;

RemQtyToPost := 0.7 - 1.404
RemQtyToPost := -0.704

RemQtyToPostThisLine := ProdOrderComp."Remaining Qty. (Base)";
RemQtyToPostThisLine := 2.3

if RemQtyToPostThisLine * RemQtyToPost < 0 then

Error(Text001);

if 2.3 * -0.704 < 0 then ERROR

Additional points that may be important.

- BC Version =25.5.30849.32457

- Location uses Directed Pick Putaway

- All items have item tracking using Lot numbers.

Any help would be appreciated!

Categories:

Dynamics 365 Business Central

I have the same question (0)

All responses (12)

Answers (0)

Suggested answer

Holly Huffman 6,530 Super User 2025 Season 2 on at

Like (1)

Report
Good morning, afternoon, or evening :) depending on your location!
I see this was posted a while back - hoping you've resolved by now :) incase not, here are a few thoughts:

It looks like you're encountering a mismatch in item tracking quantities when posting partial consumption in the production journal. Based on your debugging output and the sporadic nature of the issue, here are some possible causes and solutions:
Possible Causes:

Item Tracking Discrepancy

Business Central may not be correctly updating the remaining quantity after each consumption entry, leading to inconsistencies in expected vs. actual values.

The system might be rounding values differently in different areas, causing slight mismatches.

Directed Pick and Putaway Complexity

Since your location uses Directed Pick and Putaway, Business Central enforces stricter tracking rules. If the system expects a specific sequence of consumption, deviations might trigger errors.

Lot Tracking Issues

If lot tracking is enabled, Business Central may require exact matches between expected and consumed quantities. Any rounding or manual adjustments could cause discrepancies.

Recent Update Impact

Given that this issue started after a minor update, it’s possible that Microsoft introduced a change affecting how item tracking is validated during consumption posting.

Potential Solutions:

Manually Adjust Remaining Quantity

Before posting, verify the Remaining Qty. (Base) field and manually adjust it to match expected values.

Check Item Tracking Setup

Ensure that item tracking settings align with your consumption process. If necessary, adjust tracking policies to allow more flexibility.

Test with Whole Units

Try posting consumption in whole units instead of fractional values (e.g., 1 instead of 0.75) to see if the issue persists.

Recreate the Issue in a Test Environment

If possible, replicate the issue in a sandbox environment without extensions to confirm whether it’s a system bug.

Hope this helps!

Was this reply helpful? Yes No
Suggested answer

YUN ZHU 95,329 Super User 2025 Season 2 on at

Like (1)

Report

What is the error message in Show Details?
It is hard to tell if this is a standard issue, so I suggest asking the developer to debug it.

Thanks.

ZHU

Was this reply helpful? Yes No
Suggested answer

Suresh Kulla 50,243 Super User 2025 Season 2 on at

Like (2)

Report

It seems like the quantity you have on the consumption journal is more than what you have defined on the Item Tracking. It looks like the a standard error message and the logic is same even in 25.2 version

Was this reply helpful? Yes No
HS-18110301-0 34 on at

Like (1)

Report

Thank you all for your responses, I will add some further discoveries and then reply to your questions below;

We have since discovered the likely cause of the issue, however, we now have a brand new issue to investigate.

In the above example where a user posted two entries, one of 0.704 and one of 0.046, the user in fact only created one entry in the production journal of 0.75. The system seems to have split the one consumption posting into two separate Item ledger entries. The Lot numbers are the same, there are no variants or any other differences between the items that should create separate entries. I have exported the item ledger entry lines and the only difference in the data is the quantity and Entry number.

We have no idea what would make the system split this one consumption posting into two entries and it seems like its this that causes the system to ignore the second posting in the remaining qty calculation in the components table.

Answers to below questions;

The item tracking does match the consumption journal quantity. At the users consume in 'batches' they may post partial consumption entries. To do this, they first need to adjust the item tracking line quantities from the production journal and then adjust the consumption qty in the production journal to match. After posting and closing the journal, the users can reopen the production journal and both consumption qty and item tracking lines will reset to the remaining quantity from the original warehouse pick. This process has been followed for over 3 years now with no issues until now.

'Show Details' message;

If requesting support, please provide the following details to help troubleshooting:

Error message:
Item Tracking is signed wrongly.

Internal session ID:
c40e1fe6-9683-4e63-8466-29f52b446904

Application Insights session ID:
691de421-47a2-4317-8988-7a24c1d87283

Client activity id:
39b64dcd-85b9-41a3-846e-45626cbb25f2

Time stamp on error:
2025-04-07T21:39:05.9217000Z

User telemetry id:
aba73883-9106-4f9f-866d-8344b89e90b2

AL call stack:
"Item Jnl.-Post Line"(CodeUnit 22).PostConsumption line 60 - Base Application by Microsoft
"Item Jnl.-Post Line"(CodeUnit 22).Code line 130 - Base Application by Microsoft
"Item Jnl.-Post Line"(CodeUnit 22).PostSplitJnlLine line 12 - Base Application by Microsoft
"Item Jnl.-Post Line"(CodeUnit 22).RunWithCheck line 16 - Base Application by Microsoft
"Item Jnl.-Post Batch"(CodeUnit 23).PostLines line 51 - Base Application by Microsoft
"Item Jnl.-Post Batch"(CodeUnit 23).Code line 56 - Base Application by Microsoft
"Item Jnl.-Post Batch"(CodeUnit 23).OnRun(Trigger) line 6 - Base Application by Microsoft
"Item Jnl.-Post"(CodeUnit 241).Code line 25 - Base Application by Microsoft
"Item Jnl.-Post"(CodeUnit 241).OnRun(Trigger) line 3 - Base Application by Microsoft
"Item Journal Line"(Table 83).PostingItemJnlFromProduction line 16 - Base Application by Microsoft
"Production Journal"(Page 5510)."Post - OnAction"(Trigger) line 4 - Base Application by Microsoft

From our debugging we think the issue could also be related to the section in bold;

The system correctly identifies the NewRemainingQty as 2.3 (Qty picked =5.25, qty consumed =2.25, Qty to consume on current production journal line that matches item tracking = 0.7) 5.25-2.25-0.7 = 2.3.

It fails when calculating the RemQtyToPostThisLine which i believe gives us the final error.

QtyToPost should = 3 -2.3 = 0.7

Then RemQtyToPost should = 0.7-0.7 = 0.

Then 2.3 * 0 = 0 which is NOT < 0 and therefore would not error as it mentions at the bottom if <0 then ERROR.

Very confusing but this is where I am upto now!

RemQtyToPost = 0.7
RemQtyToPostThisLine = 3.704

if RemQtyToPostThisLine > RemQtyToPost then
RemQtyToPostThisLine := RemQtyToPost

RemQtyToPostThisLine = 0.7

QtyToPost := RemQtyToPostThisLine;
QtyToPost := 0.7

NewRemainingQty := ProdOrderComp."Expected Qty. (Base)" - ProdOrderComp."Act. Consumption (Qty)" - QtyToPost;
NewRemainingQty := 5.25 - 2.25 - 0.7
NewRemainingQty := 2.3

QtyToPost := ProdOrderComp."Remaining Qty. (Base)" - NewRemainingQty
QtyToPost := 3.704 - 2.3
QtyToPost := 1.404

ProdOrderComp."Remaining Qty. (Base)" := NewRemainingQty;
ProdOrderComp."Remaining Qty. (Base)" := 2.3

if QtyToPost <> 0 then
RemQtyToPost := RemQtyToPost - QtyToPost;

RemQtyToPost := 0.7 - 1.404
RemQtyToPost := -0.704

RemQtyToPostThisLine := ProdOrderComp."Remaining Qty. (Base)";
RemQtyToPostThisLine := 2.3

if RemQtyToPostThisLine * RemQtyToPost < 0 then
Error(Text001);

if 2.3 * -0.704 < 0 then ERROR

Was this reply helpful? Yes No
Suggested answer

Khushbu Rajvi. 20,275 Super User 2025 Season 2 on at

Like (2)

Report

Check this: https://community.dynamics.com/forums/thread/details/?threadid=c4a75fb2-2800-44d6-8d6e-090ef968637f

https://community.dynamics.com/forums/thread/details/?threadid=4f2cd226-009f-420a-bc9e-541589905a8f

Was this reply helpful? Yes No
Suggested answer

YUN ZHU 95,329 Super User 2025 Season 2 on at

Like (1)

Report

Hi, If you have upgraded to Business Central 2025 wave 1 (BC26), you can try the following method to cancel the order.

Cancel production orders that have consumption

https://learn.microsoft.com/en-us/dynamics365/release-plan/2025wave1/smb/dynamics365-business-central/cancel-production-orders-that-have-consumption?wt.mc_id=DX-MVP-5004336

Hope this helps.

Thanks.

ZHU

Was this reply helpful? Yes No
HS-18110301-0 34 on at

Like (1)

Report

Hi @Khushbu Rajvi.

Thanks but neither of these are related.

Thanks @YUN ZHU this will be helpful for other activities but it is not feasible to expect users to run this function every time they face this error. We want to resolve the cause of the issue.

Was this reply helpful? Yes No
AV-01051438-0 4 on at

Like (1)

Report

So we have just come across the same error today and also never seen this before (recently updated to BC 25.5)

Item has UOM: EACH (1) and is LOT tracked , which we picked for a production order.

Originally picked 1000 and consumed 1000 but 4 were consumed with a reason code (scrap)

qty 1 * 996 (each consumption line is qty 1, as we have to record a SN for each LOT incase of a recall.

qty 2 * 2 - scrapped

We then picked another 5 and are trying to post 3 of the 5 but we see the error now.

So we are unsure what is causing this error as we have other items which we have also excess picked and these seem to have posted.

Is this an error we have seen before but has now been re-worded - we have no idea .

We will copy company tonight, pick an excess qty of 1 with a diff LOT and see it we can post that LOT (same item)

Then pick an excess qty of 1 with the same LOT as the original and see if we can post.

If we can, there could be an issue with these 5 that we have picked.

Was this reply helpful? Yes No
Suggested answer

Tech-Lucky 1,267 Super User 2025 Season 2 on at

Like (3)

Report
After reviewing your inputs and the explanation of the issue, I understand that the same process has been followed by the company for the past three years without any problems.

I have a few suggestions to help you identify the root cause. I previously encountered a reservation-related bug introduced in Microsoft Update Version 25.4. Although it was different from your case, I was able to trace it through debugging and reported it to Microsoft—they later released a fix for it.

Check on an older version: Do you have a sandbox environment running a version older than 25.5? If so, try to replicate the issue there. This will help determine whether the problem is related to a recent update.

Review customizations: Check if there have been any recent customizations involving the production journal or item tracking. If possible, try uninstalling all custom apps and see if the issue still persists. This can help isolate whether a customization is causing the problem.

If the issue is reproducible and confirmed to be caused by a Microsoft update or cannot be resolved internally, you should raise a support ticket with Microsoft. Be sure to include a detailed case explanation document. If the issue is a showstopper affecting business operations, Microsoft has a provision for high-priority tickets and can assign 24/7 support to assist you.

Was this reply helpful? Yes No
TB-02051403-0 4 on at

Like (1)

Report

Hi,

We are running into the same issue, have you been able to figure out the root cause yet?

Was this reply helpful? Yes No