Inventory Adjustment codeunit (5895) InsertAdjmtEntry 3.10?

Hi!

A little while ago, one of our clients, who run 3.70, asked us to put in a negative stock check into their system, which we did. As part of this I put in an exception in, in codeunit 21, so that in the event that the transaction was an adjust costs one, then the check would be over looked.

To get this to work I added an extra Boolean field to the Item Journal table to indicate that this was an adjust costs transaction & put in an extra line of code in the InsertAdjmtEntry function of the ‘Inventory Adjustment’ codeunit to mark this as true.

Another of our clients has asked us for the same feature and I am looking for the relevant function that creates the journal lines to create the adjustment entries in the ‘Inventory Adjustment’ codeunit. However in this case the client runs a 3.10 database and the InsertAdjmtEntry function does not exist there and I do not seem to be able to find a corresponding function that does this.

Please could someone point me in the right direction?

Many thanks

This process was dramatically cahnged from 2.60 > 3.00 > 3.01 > 3.10 > 3.60 then cleaned up and finalized (sort of) in 3.70.

(needed to re-read that)

I think the function you are looking for is “InsertValueEntry” But in reality, I am not sure if I follow. The adjust cost routine creates VALUE entries, not Item ledger entries, or am I missing something here? I assume your mod in CU22 only prevents the insertion of Negative Item Ledger entries, so it should not really affect this.

I assume you have line in CU22 that looks something like:

If Location.“Block Negative Inventory” AND (ItemLedgEntry.“Remaining Quantity” < 0) THEN

FIELDERROR( …

Reading it a third time, I am pretty sure that the issue is that you have written the original Inventory check mod incorrectly. [;)] it should be in CU22 on insert or modify ILE, but maybe you did it in CU 21 based on the Item Journal Line Table.

Hello David,

I added my stock check code to Codeunit 21 to trap the quantities early on. I prefer to trap these things early on.

The following has been added to the RunCheck function - Please note that this is not the finished version (Lot Nos. need addressing etc):

// Negative stock check…

IF (InvtSetup.“Check for Negative Stock”) AND // Ensure that Neg Stock check is required…
NOT (“Drop Shipment”) AND // Skip Drop shipments…
(“Value Entry Type” <> “Value Entry Type”::Rounding) AND // Skip rounding…
(ItemJnlLine.“Adjust Costs Only” = FALSE) THEN BEGIN // Skip Adjust Costs routine…

IF “Entry Type” IN [“Entry Type”::Sale,“Entry Type”::“Negative Adjmt.”,“Entry Type”::Transfer] THEN

QtyToPost := -“Quantity (Base)”
ELSE
QtyToPost := “Quantity (Base)”;

IF QtyToPost < 0 THEN BEGIN
ItemLedgEntry2.RESET;
ItemLedgEntry2.SETCURRENTKEY(“Item No.”,“Variant Code”,“Drop Shipment”,“Location Code”,“Posting Date”);
ItemLedgEntry2.SETRANGE(“Item No.”,“Item No.”);
ItemLedgEntry2.SETRANGE(“Variant Code”,“Variant Code”);
ItemLedgEntry2.SETRANGE(“Drop Shipment”,FALSE);
ItemLedgEntry2.SETRANGE(“Location Code”,“Location Code”);
IF “Bin Code” <> ‘’ THEN
ItemLedgEntry2.SETRANGE(“Bin Code”,“Bin Code”);
ItemLedgEntry2.CALCSUMS(“Remaining Quantity”);

IF (ItemLedgEntry2.“Remaining Quantity” + QtyToPost +
“Reserved Quantity”) < 0
THEN
FIELDERROR(Quantity,
STRSUBSTNO(COSLStockOutText,“Item No.”,“Location Code”,“Bin Code”,“Variant Code”));
END;
END;

The client uses an extended version of 3.10 where Bins on the ILE were re-introduced.

I will go and look again at codeunit 5895.

Thanks

Perhaps I should be looking at blocking this at the point of creating the ILEs, rather than in the pre-checing…

Thanks David!

I am guessing that you did the proper NAV training when they used to teach the “Check Near” “Check Far”, in in that case I can see why you designed the code this way.

But the reason for that logic is flawed here.

The idea is that you should be checking as quickly as possible, so that the process has minimal server impact before an error is found and a commit is aborted. But in this case, the CACSUMS will be putting substantially more load on the server during the CHECKING process, than the time needed to get to the point of creating the error and aborting the commit. So in fact its actually faster to do the Two lines I suggested in CU22 than the code you have in CU21.