Hi, I have a question regarding an upgrade what I did recently. One of our customers have been converted to Attain 3.60 (from Financials 2.60 Mfg). They are using Lot nos. The conversion went fine. Prior to the conversion they have posted all the Sales documents. However not all of the Purchase Orders have been posted. They now try to post some of their Purchase Orders which have been received, but not invoiced but they can’t because of error messages (like: ‘Tracking Specification Entry No.1 already exist’. I realize that they should have posted all of the documents before conversion but it is hard sometimes for a company to do so. Is there any way to fix this posting problem (fix in CodeUnits 90,22 or 99000834)? Any suggestions are welcome! Thanks. Roelof de Jong.
I am assuming that the errors are related to Purcase Receipts not Invoiced, or are you also getting this with Receiving? I think you are going to need to remove all the lot tracking from the Purchase Orders, then recreate these manually. Something like pushing all the lot numbers into a temporaty table somewhere, then createing a function to allow the user to recreate the Lots number in the Item Ledger entries and Tracking Tables. The procedure would be that after posting, the user goes to the temporary table, and runs a function that would then create the required lot details. Since this is a “one off”, I would not recommend modifying the posting CodeUnits.
If you look at the Item Tracking Lines against the Purchase Order Line, do they look correct? I would probably try to get these entries corrected first (might be manual updating) rather than play with the Posting Routine. I have been lucky enough not to encounter this issue, so this is just an educated guess.
HI, I already reported error like this maybe this can help you. Here is the fix that I got from Navision. I have gotten the fix for this error from our Development team in HQ. This fix will be part of tha next release. If number of itemtracking lines being posted exceed the number of item ledger entries in the database prior to posting the insertion of the tempitemtracking record would fail and give a run-time error. Insertion has been changed so that the conflicting record will be moved to a free space in the row of entries. Changes in Codeunit 22: Procedure SplitJnlLine: … IF TempTrackingSpecification.FIND(’-’) THEN BEGIN * FreeEntryNo := TempTrackingSpecification.“Entry No.”; // Added TempTrackingSpecification.DELETE; ItemJnlLine2.TESTFIELD(“Serial No.”,TempTrackingSpecification.“Serial No.”); ItemJnlLine2.TESTFIELD(“Lot No.”,TempTrackingSpecification.“Lot No.”); TempTrackingSpecification.“Quantity (Base)” := SignFactor * ItemJnlLine2.“Quantity (Base)”; TempTrackingSpecification.“Quantity Handled (Base)” := SignFactor * ItemJnlLine2.“Quantity (Base)”; TempTrackingSpecification.“Quantity actual Handled (Base)” := SignFactor * ItemJnlLine2.“Quantity (Base)”; TempTrackingSpecification.“Quantity Invoiced (Base)” := SignFactor * ItemJnlLine2.“Invoiced Qty. (Base)”; TempTrackingSpecification.“Qty. to Invoice (Base)” := SignFactor * (ItemJnlLine2.“Quantity (Base)” - ItemJnlLine2.“Invoiced Qty. (Base)”); TempTrackingSpecification.“Qty. to Handle (Base)” := 0; TempTrackingSpecification.“Qty. to Handle” := 0; TempTrackingSpecification.“Qty. to Invoice” := SignFactor * (ItemJnlLine2.Quantity - ItemJnlLine2.“Invoiced Quantity”); TempTrackingSpecification.“Appl.-to Item Entry” := GlobalItemLedgEntry.“Entry No.”; TempTrackingSpecification.“Transfer Item Entry No.” := TempItemEntryRelation.“Item Entry No.”; IF PostItemJnlLine THEN TempTrackingSpecification.“Entry No.” := TempTrackingSpecification.“Appl.-to Item Entry”; * TempTrackingSpecification.INSERT; // Removed * InsertTempTrkgSpecification(FreeEntryNo); // Added … Procedure added: LOCAL PROCEDURE InsertTempTrkgSpecification@46(FreeEntryNo@1000 : Integer); VAR TempTrackingSpecification2@1001 : TEMPORARY Record 336; BEGIN IF NOT TempTrackingSpecification.INSERT THEN BEGIN TempTrackingSpecification2 := TempTrackingSpecification; TempTrackingSpecification.GET(TempTrackingSpecification2.“Appl.-to Item Entry”); TempTrackingSpecification.DELETE; TempTrackingSpecification.“Entry No.” := FreeEntryNo; TempTrackingSpecification.INSERT; TempTrackingSpecification := TempTrackingSpecification2; TempTrackingSpecification.INSERT; END; END; I hope that the above helps
Hi Aloi, I think you are very close with my problem. But I still get an error in CodeUnit 90. Was there any fix for CodeUnit 90 (or maybe CodeUnit 99000834)? Let me know. Thanks! Roelof.
Well, I fixed the problem. What happens is that in the Tracking Specification table, the ‘Apply to Item Entry No’ is missing (read 0) after a conversion to 3.60. I created a spinfix to populate these entry nos from the Item Entry Relation table. I ran that and the problem was solved. But thanks for anyones help! I like this website. Roelof.