Transfer Order

chadharajan

Hi,

I am facing following problems in Transfer Order.

1.While ‘Receiving’ a transfer order, that is already ‘Shipped’, the system gives a message saying that "item is not in stock".On checking, we find that there is enough stock at the transit location. Further investigation reveals that in such situations the system is generating multiple entries of the said item while ‘Shipping’ it to the transit location.

2.In certain cases, while posting a transfer order, there is a message which says that the transaction would cause inconsistencies in GL, and does not post. This happens in both Attain and SQL database. This mostly happens when the number of lines in the transfer order is rather high.


We are using Navision 3.7/Sql Server

Regards

Rajan

kine

Have you customized object? (Codeunit 22, 5704, 5705)

If yes, may be there are some bugs...

chadharajan

HI Kane,

We have not customised anything in these code units.

Rajan

shepherd1970

I'm having the same problem in a 370/sql implementation.

There was a posting on the mbsonline.org forum about this problem. Unfortunately this site has been down for the last 10 days at least. But it did say to get around the problem receipt the problem line on the transfer in parts. I've ususally found that if you look at the ILE's on the problem line and transfer the first time with one of these quantities you can receipt the remaining amount in the next transfer.

I believe the forum answer on mbsonline said there was no known fix. I can't find anything on Microsoft service requests and was not keen to raise the service request because of the inevitable questions from MS about how to duplicate the problem, something which I'm not clear on. The nearest I can get is say it happens on transfers with more than 10 lines, on the receipt and the problem line has multiple ILE entries - but most of the time it works.

AbelBalbo

Hi,

we have got the same problem with different customers. They all have the SQL Server implemented. We acknowledged this phenomenon trying to post consumptions in the manufacturing module as well as trying to post transfer orders. By the way splitting the entries on account of the first open entry not having the needed quantity is absolutly correct. It seems to me that somewhere in the codeunit 22 the SQL Server changes the sorting of the variable ItemLedgEntry2 so that from time to time (not reproducable) a definetly existing item ledger entry is not found. We have found a workaround. On one hand the posting works correctly afterwards, on the other hand performance problems may occur on account of a large amount of item ledger entries. Please try this workaround on the databases of your customers and give me a feedback whether it works or not. Perhaps anybody has got another idea how to solve this problem without getting a performance problem.
Here a the original code line of codeunit 22 added with the workaround marked in bold letters.


END ELSE BEGIN
IF FirstApplication THEN BEGIN
FirstApplication := FALSE;
ItemLedgEntry2.SETCURRENTKEY(
"Item No.","Variant Code",Open,Positive,"Location Code","Posting Date");
ItemLedgEntry2.SETRANGE("Item No.",ItemLedgEntry."Item No.");
ItemLedgEntry2.SETRANGE("Variant Code",ItemLedgEntry."Variant Code");
ItemLedgEntry2.SETRANGE(Open,TRUE);
ItemLedgEntry2.SETRANGE(Positive,NOT ItemLedgEntry.Positive);
ItemLedgEntry2.SETRANGE("Location Code",ItemLedgEntry."Location Code");
IF ItemTrackingCode."SN Specific Tracking" THEN
ItemLedgEntry2.SETRANGE("Serial No.",ItemLedgEntry."Serial No.");
IF ItemTrackingCode."Lot Specific Tracking" THEN
ItemLedgEntry2.SETRANGE("Lot No.",ItemLedgEntry."Lot No.");

IF NOT ItemLedgEntry.Positive THEN BEGIN
IF Location.GET(ItemLedgEntry."Location Code") THEN
IF Location."Use As In-Transit" THEN
ItemLedgEntry2.SETRANGE("Transfer Order No.",ItemLedgEntry."Transfer Order No.");
END;

IF ItemJnlLine."Applies-from Entry" <> 0 THEN
ItemLedgEntry2.SETFILTER("Entry No.",'<>%1',ItemJnlLine."Applies-from Entry");

IF Item."Costing Method" = Item."Costing Method"::LIFO THEN
EntryFindMethod := '+'
ELSE
EntryFindMethod := '-';

//A/GOB-SAL/4.1.2005/KP3.70.01.12/Item Ledger Entry problems
IF ItemLedgEntry2.FIND('-') THEN
REPEAT
UNTIL ItemLedgEntry2.NEXT = 0;
//E/GOB-SAL/4.1.2005/KP3.70.01.12

IF NOT ItemLedgEntry2.FIND(EntryFindMethod) THEN
EXIT;
END ELSE
CASE EntryFindMethod OF
'-':
IF ItemLedgEntry2.NEXT = 0 THEN
EXIT;
'+':
IF ItemLedgEntry2.NEXT(-1) = 0 THEN
EXIT;
END;
OldItemLedgEntry.COPY(ItemLedgEntry2)
END;

Please let me know anything linked to that problem.

Sebastian

drooser

I too have a customer (only one from many using Transfer Orders) who is having this intermittant problem. The workaround is as previously suggested - drill through to the ledger entries then manually split the "Receive" into the quantities the system wants.

I'd love to fix this once and for all though. Abelbalbo - can you give me an insight into what made you change the code in Codeunit 22 the way you have? Looking at your change, all it will do is find the first record, then cycle to the last. The next line of standard code will then jump to the first or last entry depending on the costing method so your additional code would not appear to have any impact.

Thanks!

AbelBalbo

drooser wrote:

I too have a customer (only one from many using Transfer Orders) who is having this intermittant problem. The workaround is as previously suggested - drill through to the ledger entries then manually split the "Receive" into the quantities the system wants.

I'd love to fix this once and for all though. Abelbalbo - can you give me an insight into what made you change the code in Codeunit 22 the way you have? Looking at your change, all it will do is find the first record, then cycle to the last. The next line of standard code will then jump to the first or last entry depending on the costing method so your additional code would not appear to have any impact.

Thanks!

As I tried to explain it seems to me that under certain circumstances the SQL Server doesn´t have the right access to the variable ItemLedgEntry2. The additional code does nothing "useful" at all as you have mentioned above, except for the fact that the succeeding IF NOT ItemLedgEntry2.FIND(EntryFindMethod) does find the Item Ledger entry which is part of the result set. So the additional code makes the system "get a grip" on the variable "ItemLedgEntry2" so that the error "Item %1 is not on inventory" doesn´t appear anymore.

drooser

Thanks for that. I'll give it a try on our customers system.