Posted quantity incorrect

ramon_nav

Hi all,

I a customers database, there are a few occasions where the posted quantities of a shipment are not equal to the shipped quantity; for instance 5 items are shipped to a client but 7 are posted to the item ledger!

The problem starts in the registered picks. There are a few picks in the table "registered whse. activity line", where the "quantity"does not match the "qty (base)". When the shipment for such a pick is posted, the sales order line will show that 5 items are shipped (as well as the posted sales shipment). As said above, the item ledger entry will show 7!

The sales line still holds an open quantity. Let's say, the client ordered 20 pieces. In that case the sales line will show an open quantity of 15.

The problem seems to be caused by the difference in quantity and quantity (base). But all the items in the customers database have the same UOM for sales/purchasing/inventory. I have checked the code on the "wharehouse activity line" table: both columns are validated correctly. I have tried to create a pick with a different figure in the quantity/quantity(base), but NAV updates the other field as soon as you change either of the fields in the pick.

Does anyone have an idea about the cause of this problem?

Rgds,
Ramon

ara3n

When you pick an Order, it does not update the sales order. When you post the warehouse shipment, that is when navision updates the Sales Line and ships the good. See if there have been any modification on sales line and warehouse posting process.

rocatis

ramon_nav wrote:

I a customers database, there are a few occasions where the posted quantities of a shipment are not equal to the shipped quantity; for instance 5 items are shipped to a client but 7 are posted to the item ledger!

This may or may not be the same problem, but I've used an awful lot of time uncovering it (Microsoft Support sadly hasn't contributed) so it should be of use to somebody - at least if you're using locations with "Directed Put-away and Pick".

The problem in a nutshell is that the fields "Quantity" and "Qty. (Base)" in the "Warehouse Entry" table differs. Sometimes wildly, like 4 vs -17. The error exists in both v4 and v5.

Here's how you reproduce the error (the rest of this post is more or less copy/paste from my exchange with Microsoft):

In a standard CRONUS database do the following:

1) Create a Purchase Order for Item LS-120, Location Code WHITE, Quantity 100. 2) Release it. 3) Create Warehouse Receipt. 4) Post the Receipt. 5) The second and last line of the Put-away is disastrously wrong.

From this point on no checks/recalculation of "Quantity" and "Qty. (Base)" takes place which means the Warehouse Entries end up a complete mess.

Consider this code from codeunit 7313:

        //Calc Availability per Bin Content
        (...)
              BinContent.CALCFIELDS(Quantity,"Put-away Qty.","Pos. Adjmt. Qty.");
              BinContentQty :=
                BinContent.Quantity + BinContent."Put-away Qty." + BinContent."Pos. Adjmt. Qty.";
              BinContentQtyBase := BinContent.CalcQtyBase;

In the reproducible example shown above, the first Place line yields the following result:

BinContentQty = 8
BinContentQtyBase = 10

Obviously wrong. The error stems from the fact that the two values are calculated in wildly different ways probably due to bad database design.

[Original code fix removed. See the Microsoft approved code fix here: http://www.mibuso.com/forum/viewtopic.php?p=122270#122270]

In addition, we've investigated what could be done with the f**ked up Warehouse Entries. We're currently leaning towards a very basic solution which is to simply copy the "Quantity" fields to the "Quantity Base" fields.


So, there you go. This took forever and a day to unearth so I hope somebody can use it. Please note that I'm basically a developer that knows nothing about Warehouse so please don't ask any complicated questions

Brian Rocatis
Senior NAV Developer
Tectura (Denmark)

Alex_Chow

Yep, we've encountered the same problem in our customer's database where the Quantity and the Qty. (Base) is different even though no additional unit of measure was used.

The database we're using is SQL2005 in version 5.0.

Brian,
Thanks a lot for sharing your findings. We ended up writing a process that finds these entries instead of changing the code because I'm afraid it may f**k up something else. So the users are trained to run the process whenever the quantity is wierd.

This is definately a huge problem with WHM in 5.0. I hope MSFT fixes this in 5.1...

Alex_Chow

Just an update.

After an analysis of the problem entries, I noticed that the errors were happening on the receicing side as Brian described. We've implemented the code Brian provided to see how it will work out.

Will keep you guys posted, but I do believe Brian has solved this problem. =D> =D> =D>

rocatis

Alex Chow wrote:

We ended up writing a process that finds these entries instead of changing the code because I'm afraid it may f**k up something else. So the users are trained to run the process whenever the quantity is wierd.

I'm assuming that you're repopulating "Qty.(Base)" from "Quantity" in the "Warehouse Entry" table?

BTW, Microsoft has awoken (apparently my postings weren't added to the case #-o ) and I expect to have my resolution validated shortly along with my suggestion of how to fix the problem.

This is definately a huge problem with WHM in 5.0. I hope MSFT fixes this in 5.1...

The problem is that it's so elusive. I mean, it's existed since v4 apparently without anybody reacting to it. Anyways, I'm pretty certain it won't be in SP1 (too close to shipping) but it definately should be made available as a hotfix.

Brian Rocatis
Senior NAV Developer
Tectura (Denmark)

Alex_Chow

rocatis wrote:

I'm assuming that you're repopulating "Qty.(Base)" from "Quantity" in the "Warehouse Entry" table?

Yep, that's exactly what I'm doing. But I've put in your code and hopefully, that will address the problem.

rocatis

Alex Chow wrote:

rocatis wrote:

I'm assuming that you're repopulating "Qty.(Base)" from "Quantity" in the "Warehouse Entry" table?

Yep, that's exactly what I'm doing. But I've put in your code and hopefully, that will address the problem.

I hope so too, but in the meanwhile we have a couple of thousand f**ked up Warehouse Entries which we would like to correct...

You're just confirming my hunch that the fix is to repopulate "Qty.(Base)" from "Quantity".

Brian Rocatis
Senior NAV Developer
Tectura (Denmark)

Alex_Chow

Yes, but you have to do it in one shot.

Also, make sure they're all using the Base UOM for the entries.

rocatis

Microsoft have now investigated the case and come up with a solution. It differs from my original suggestion which I have now removed.

The approved solution is this:

Table 7302:

WhseActivLine.SETRANGE("Variant Code","Variant Code");
WhseActivLine.SETRANGE("Unit of Measure Code","Unit of Measure Code");
// >> TEC BR 07-05-2008 // Missing filter added.
// Microsoft Support Case Number SRZ080215000194
WhseActivLine.SETRANGE("Action Type",WhseActivLine."Action Type"::Place);
// << TEC
COPYFILTER("Lot No. Filter",WhseActivLine."Lot No.");

Codeunit 7313:

IF (NOT PutAwayTemplLine."Find Bin w. Less than Min. Qty" OR
                  (BinContentQty < BinContent."Min. Qty.")) AND
                 (NOT PutAwayTemplLine."Find Empty Bin" OR (BinContentQty <= 0))
              THEN BEGIN
// >> TEC BR 07-05-2008
// Microsoft Support Case Number SRZ080215000194
// Replacement Code BEGIN
                IF (BinContent."Max. Qty." <> 0) AND
                   (BinContent."Max. Qty." * BinContent."Qty. per Unit of Measure" >=
                   BinContentQty * BinContent."Qty. per Unit of Measure")
                THEN BEGIN
                  QtyToPutAwayBase :=
                    BinContent."Max. Qty." * BinContent."Qty. per Unit of Measure" - BinContentQtyBase;
                  QtyToPutAway := QtyToPutAwayBase / PutAwayItemUOM."Qty. per Unit of Measure";

                  IF QtyToPutAwayBase > RemQtyToPutAwayBase THEN
                    QtyToPutAwayBase := RemQtyToPutAwayBase;
                  IF QtyToPutAway > RemQtyToPutAway THEN
                    QtyToPutAway := RemQtyToPutAway;
                END;
// Replacement Code END

// Original Code BEGIN
{
                IF (BinContent."Max. Qty." <> 0) AND (BinContent."Max. Qty." >= BinContentQty) THEN BEGIN
                  QtyToPutAway := BinContent."Max. Qty." - BinContentQty;
                  IF QtyToPutAway > RemQtyToPutAway THEN
                    QtyToPutAway := RemQtyToPutAway;
                END;
                IF (BinContent."Max. Qty." <> 0) AND
                   (BinContent."Max. Qty." * BinContent."Qty. per Unit of Measure" >= BinContentQty)
                THEN BEGIN
                  QtyToPutAwayBase :=
                    BinContent."Max. Qty." * BinContent."Qty. per Unit of Measure" - BinContentQtyBase;
                  IF QtyToPutAwayBase > RemQtyToPutAwayBase THEN
                    QtyToPutAwayBase := RemQtyToPutAwayBase;
                END;
}
// Original Code END
// << TEC

                GetBin("Location Code",BinContent."Bin Code");

I've tested it and it seems to do the trick \:D/

ramon_nav

Hi guys,

This is what our developper found out:

Solution:
The problem was caused by the calling the function CheckReservation in Procedure CreateTempLine of Codeunit 7312 Create Pick. The function reduces the TotalQtytoPick with the Quantity reserved on non "Item Ledger Entry". Obviously after modifying the TotalQtytoPick the TotalQtyPickBase should also be modified! The issue is solved by adding one line of code as illustrated in the code snippet below:

CreateTempLine(LocationCode : Code[10];ItemNo : Code[20];VariantCode : Code[10];UnitofMeasureCode : Code[10];FromBinCode : Code[20];ToB CheckReservation(
LocationCode,SourceType,SourceSubType,SourceNo,SourceLineNo,SourceSubLineNo,
QtyPerUnitofMeasure,TotalQtytoPick);

TotalQtytoPickBase:=TotalQtytoPick*QtyPerUnitofMeasure; //FIX-007B.ns

RemQtyToPick := TotalQtytoPick;
RemQtyToPickBase := TotalQtytoPickBase;

klavin

FYI, we just upgraded to 5 SP1 :bug: ... still exists. Same code as posted.

Will be fun fixing these entries... \:D/

Alex_Chow

Sorry to disappoint you guys. This is still a bug in NAV2012 R2!

Implement the fix for your clients if you plan to use WHM!!!

klavin

Greaaaaat.... I'll have to keep that in mind. Thanks

Alex_Chow

The code in 2013R2 has minor changes, so implement with care!

rocatis

Alex Chow wrote:

Sorry to disappoint you guys. This is still a bug in NAV2013 R2!

Are you kidding me? :shock:

And if they've actually modified the code without fixing the bug, they're simply adding insult to injury. We are not amused.

Alex_Chow

I really don't want to turn this thread into a rant against MSFT, but I'm not very pleased as well.

Things that are fundamental problems that causes number discrepancies I'd assume would be top priority and addressed in new versions.

Here's a blog on it:
http://www.dynamicsnavconsultant.com/20 ... -away-nav/