[main] - Serial and Lot number mismatch when item is produced via Production Order and moved to inventory through an Internal Put-away - #10072
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| Cust.CheckBlockedCustOnDocs(Cust, GlobalWhseActivHeader."Source Document", false, false); | ||
| end; | ||
|
|
||
| local procedure CheckItemTrackingRequiredForPutAway(WhseActivLine: Record "Warehouse Activity Line") |
There was a problem hiding this comment.
This change introduces a new runtime contract in published codeunit 7307 "Whse.-Activity-Register": registering a Put-away for a serial+lot tracked item now fails with a TestField error when the line's Lot No. is blank while the matching Item Ledger Entry carries a Lot No., where the same flow previously completed successfully (the new test RegisterPutAwayWithBlankLotForSerialAndLotItemIsBlocked demonstrates exactly this). No public AL signature changed, but existing extensions, integrations, or already-open Put-away activity lines created before this change carry no compatibility or migration path — on upgrade they will start failing registration with no accompanying data fix-up. Treat this as a breaking behavioral change: provide a migration/backfill for existing open lines, an opt-in/feature-flag gate, or at minimum a clear release-note callout, and document the new OnBeforeCheckItemTrackingRequiredForPutAway event as the supported way for subscribers to preserve legacy behavior if needed.
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.31.4
| if Location."Bin Mandatory" then | ||
| CheckBinRelatedFields(GlobalWhseActivLine); | ||
|
|
||
| CheckItemTrackingRequiredForPutAway(GlobalWhseActivLine); |
There was a problem hiding this comment.
RegisterActivityLines now calls the new CheckItemTrackingRequiredForPutAway inside the warehouse-line repeat/until loop, and that helper performs a persistent Item Ledger Entry lookup (FindLast) for every qualifying Put-away line. This is an N+1 database-access pattern on a hot registration path; SetLoadFields reduces the payload per row but does not remove the per-line lookup. Consider preloading/caching the required Item Ledger Entry data by item/variant/location/serial key once before iterating the activity lines, rather than issuing one lookup per line.
Knowledge:
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.31.4
| if WhseActivLine."Serial No." = '' then | ||
| exit; | ||
|
|
||
| ItemLedgerEntry.SetCurrentKey("Item No.", "Variant Code", "Location Code", "Serial No."); |
There was a problem hiding this comment.
The new Item Ledger Entry lookup uses SetCurrentKey("Item No.", "Variant Code", "Location Code", "Serial No."), but the W1 Item Ledger Entry table defines no key with that leading field order (verified in ItemLedgerEntry.Table.al: the closest candidates are Key20 = "Serial No.", "Item No.", Open, "Variant Code", Positive, "Location Code", "Posting Date" and Key17 = "Item No.", Open, "Variant Code", Positive, "Lot No.", "Serial No.", "Package No."). Because the selected key does not align with the actual filters (Item No., Variant Code, Location Code, Serial No., Open) applied before FindLast, the engine falls back to a less selective scan, and — since ordering is not guaranteed to match intent — if more than one open entry ever satisfies the same Item/Variant/Location/Serial combination, FindLast can pick an entry other than the one the caller intends, comparing the Put-away line's Lot No. against the wrong ledger entry. Use an existing key that actually leads with the applied filters (for example Key20, which starts with Serial No./Item No./Open) so the lookup is both efficient and deterministic.
Knowledge:
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.31.4
| [Test] | ||
| [HandlerFunctions('ItemTrackingPageHandler,EnterQuantityToCreatePageHandler')] | ||
| [Scope('OnPrem')] | ||
| procedure RegisterPutAwayWithBlankLotForSerialAndLotItemIsBlocked() |
There was a problem hiding this comment.
The new test RegisterPutAwayWithBlankLotForSerialAndLotItemIsBlocked verifies only the failure path after clearing the Lot No. It does not add a companion success-path case that keeps the matching Lot No. and proves RegisterWarehouseActivity still succeeds, so an implementation that blocked every serial-and-lot Put-away (not just mismatched ones) would still satisfy this coverage. Add a positive-path test (or extend this one) that registers the Put-away with the unchanged, matching Lot No. and asserts success.
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.31.4
1 participant
Bug 642316: [ALL-E] Serial and Lot number mismatch when item is produced via Production Order and moved to inventory through an Internal Put-away
Fixes AB#642316
Issue - Serial and Lot number mismatch when item is produced via Production Order and moved to inventory through an Internal Put-away
Cause - The put-away validation was skipped as time of registration.As a result, the lot requirement was never enforced at registration time and a blank lot slipped through.
Solution - Added a data-driven check in WhseActivityRegister.CheckLines → CheckItemTrackingRequiredForPutAway that compares the put-away line against the actual posted Item Ledger Entry instead of the configuration flags. For each Put-away line carrying a Serial No., it resolves the open Item Ledger Entry by Item / Variant / Location / Serial No.; if that entry has a Lot No., the line's Lot No. must match it: