"You have not received all that was ordered" on WR Post

Fisherman

Getting the above message when posting the warehouse receipt.

We have Lanham Shipping & Receiving + ADCS installed. It would appear that Lanham modified CU 90 to embed calls to their own CU 14000601, which is where the error has occurred.

I've traced it down to a filter that was set on the Warehouse Receipt Line. The Lanham code is looking for a Source Type of 38 (Purchase Header) on the Receipt Line, while the line actually has a Source Type of 39 (Purchase Line). The line was created through the Functions --> Get Src. Documents menu button on the Warehouse Receipt, which calls Codeunit 5751, which is MS with no Lanham changes.

My first thought is that the Lanham code should be looking for Source Type 39, since Receipt Lines would map to Purchase Lines, not Headers, but I'm not sure what else might be impacted by making a change one way or another.

Has anyone else encountered this?

David_Singleton

What version of Navision?

There was an "issue" that started around version 4 and eShip specific to SQL.

Eship added a new key in T37 and 39 which changed the sort order used by the Completely Shipped and Completely Received fields in T36 and 38. The fields calculate on Min, and in Native DB Navision filters the set according to the key then finds the minimum, but in SQL it filters the set, then finds the first record in the set and considers that as min. Oddly this is how Native used to work, but at some time it changed. Since eShip was designed around Native it didn't always work in SQL now because it added Line No. as a factor in MIN.

Anyway if this is your issue, then in T37 and 39 find the key that Eship adds and right before it add a new key:

Document Type,Document No.,Type,Location Code,Completely Received

and it should work.

It was fixed in later versions in different way, but if you have upgraded eShip, it will probably still have the old key in the wrong position.
<edit> urrrgghhh just looked at 2009 and still field 5752 is based on MIN. The code should have been changed to work on EXISTS.

David_Singleton

Oh and you can imagine how many hours in debugger it took to figure that out. Especially with Navision saying it was an eShip issue and eShip saying it was a Navision issue.

This I think is the bad key by the way:

Document Type,Document No.,Type,No.,Variant Code,Drop Shipment,Location Code

Fisherman

David-

This is in a NAV 5.0 SP1 database.

The Lanham codeunit involved (14000601) is version SE0.53.21.

I've traced the code in the debugger. This is what I'm seeing....

In the CheckPurchHeader() trigger, the following lines set a filter on the "Receive Line" record, Table No. 14000602

...
Receive.RESET;
Receive.SETCURRENTKEY("Source Type","Source Subtype","Source ID");
Receive.SETRANGE("Source Type",DATABASE::"Purchase Header");
Receive.SETRANGE("Source Subtype",PurchHeader."Document Type");
Receive.SETRANGE("Source ID",PurchHeader."No.");
...


IF NOT ReceiveSetup.ReceiveDetail(
         DATABASE::"Purchase Header",PurchHeader."Document Type") AND
   NOT ReceiveLine.FIND('-') 

...

A little further down is where the actual error message is occurring. The codeunit calls CALCSUMS(ReceiveLine."Quantity (Base)") and compares the results against the quantity on the purchase line. It doesn't match (in fact, ReceiveLine."Quantity (Base)" is 0 after the call to CALCSUMS), so it throws the error

// Additional code required in Attain
LineQtyToReceiveBase := PurchLine."Qty. to Receive (Base)";

....


ReceiveLine.CALCSUMS(ReceiveLine."Quantity (Base)");
IF LineQtyToReceiveBase <> ReceiveLine."Quantity (Base)" THEN BEGIN
  IF LineQtyToReceiveBase > ReceiveLine."Quantity (Base)" THEN
    ERROR(Text004); // <-- ERROR THROWN HERE
  IF ReceiveLine."Quantity (Base)" > LineQtyToReceiveBase THEN
    ERROR(Text005);
END;

When I watched this run through, I noted that the ReceiveLine actually had a Source Type of 39 (Purchase Line), which is what is created by MS Codeunit 5751 when you run "Get Src. Documents", but the code above is looking for a Source Type of 38. This, to me, explains why the call to CALCSUMS returns 0.... there's nothing in the filter.

Am I thinking incorrectly?

If not, then I'm left with the question... who's right here? Is MS right to use Purchase Line as the Source Type (I would think so... given that it's receipt lines we're talking about), or is Lanham right to use Purch. Header?

[edit] I'm also doubting the effectiveness of the ReceiveLine.FIND() in the first code segment... I've seen compound IF statements that don't work as designed due to the way that NAV handles them (not like C++ or other languages). I'm thinking that if I changed that IF block to be nested IF statements, I might find that it is, indeed, not finding records within the filter...

David_Singleton

This might be changed, or a different issue, the error was in SE 0.51, and was related to a CALCSUMS("Completely Received"); May be in your version they don't even use that field.

Fisherman

Thanks.

I'm looking into your first post as well. Will let you know what I find.

Fisherman

Interestingly... I did find this...

The following key was being set on PurchLine:

PurchLine.SETCURRENTKEY(
  "Document Type","Document No.",Type,"No.","Variant Code","Drop Shipment");

And then filters were applied

PurchLine.SETRANGE("Document Type",PurchHeader."Document Type");
PurchLine.SETRANGE("Document No.",PurchHeader."No.");
PurchLine.SETRANGE(Type,PurchLine.Type::Item);
PurchLine.SETRANGE("Drop Shipment",FALSE);
IF ReceiveSetup."Location Receiving" THEN
  PurchLine.SETRANGE("Location Code",ReceiveStation."Location Code"); //<<< HMMMMMM

So I looked in the table... lo and behold... there was no such Key. The key in the table included Location Code, so I changed the set filter to this

PurchLine.SETCURRENTKEY(
  "Document Type","Document No.",Type,"No.","Variant Code","Drop Shipment","Location Code");

Still no dice, though... same error message.

Fisherman

OK... found something more.

The compound IF statement is as follows:

IF NOT ReceiveSetup.ReceiveDetail(
         DATABASE::"Purchase Header",PurchHeader."Document Type") AND
   NOT ReceiveLine.FIND('-')
THEN
  EXIT;

Inside of "ReceiveDetail()", it checks the value of the "Purchase Order Receive Detail" field in "Receive Setup" when the document type is a purchase order. If that flag is set to Yes, then the FIND('-') will never execute because the first of the statement has returned FALSE (IF NOT TRUE = FALSE). It short circuits the logic because the second condition can never cause the statement to be true.

So... when it goes to calcsum, there are no records, because FIND was never called.

"Purchase Order Receive Detail" is set to Yes in our installation, but I'm not sure what this field actually DOES.... any clue?