I am having a problem with erroneous reservation entry records of “Source Subtype” = 83 for a given 3.70 implementation which uses item tracking. After stepping through the posting routine for sales order picks (beginning with codeunit 80) I have arrived at the following question regarding the sample of code below which can be found in the RetriveItemTracking function of codeunit 6500: IF ItemJnlLine.Subcontracting THEN EXIT(RetrieveSubcontrItemTracking(ItemJnlLine,TempHandlingSpecification)); T337.SETCURRENTKEY(“Source Type”,“Source Subtype”); T337.SETRANGE(“Source Type”,DATABASE::“Item Journal Line”); T337.SETRANGE(“Source Subtype”,ItemJnlLine.“Entry Type”); T337.SETRANGE(“Source ID”,ItemJnlLine.“Journal Template Name”); T337.SETRANGE(“Source Batch Name”,ItemJnlLine.“Journal Batch Name”); T337.SETRANGE(“Source Prod. Order Line”,0); T337.SETRANGE(“Source Ref. No.”,ItemJnlLine.“Line No.”); T337.SETFILTER(“Qty. to Handle (Base)”,’<>0’); IF (SumUpItemTracking(T337,TempHandlingSpecification,FALSE,TRUE)) THEN BEGIN T337.SETRANGE(“Reservation Status”,T337.“Reservation Status”::Prospect); IF NOT T337.ISEMPTY THEN T337.DELETEALL; EXIT(TRUE); END ELSE EXIT(FALSE); Why would we want to setrange on a reservation status of prospect? Typically, the reservation entry record sould have a reservation status of reservation or possible tracking. Any insight would be appriciated.
The Prospect type is used on tracking entries, when u post throug journals (Table 83 Item Journal) with Item Tracking. Ex. When you create a negative line in a Item Journal, the system needs to know which lot no. to make the changes to. To do that the system creates a Prospect Entry to hold the information about the lot No. 
Hello Pablo, we have the same problem but we do not know the conclusion at which your you have arrived. You know some way to correct this? Thanks[:D]
Has anyone been able to solve this?? I have a client that has the same issue. I’m not 100% sure, but it may be caused by something in the transfer order process but for the life of me, I cannot find out what it is. One thing that “may” work (if the client’s setup permits it) is to add a filter on global dimension 1 & 2. In our case, the “erroneous” records never have these 2 fields populated so filtering for those would cause these records to fall out of scope. that is of course a band-aid solution and will not stop these records from appearing in the first place…