Item Is Active in the Master but Cannot Be Received in the Warehouse
Global Medical Devices has 12,000 items in its master organization. A warehouse user tries to receive 200 units of item SENSOR-X and gets the error that the item is not assigned to this inventory organization. The item shows Active in the item master, has the Inventory Item and Stockable attributes checked, and belongs to a lot-controlled item class. The item is also under revision control. An investigation finds that 4,800 of the 12,000 items are not assigned to the receiving warehouse. Some of those items were created from a legacy interface that applied an item template but never ran organization assignment. Others were assigned but have an organization-level status of Inactive because a prior data load set the status incorrectly. The warehouse also has 300 items with lot control enabled at the master level but no lot attributes at the organization level. The business wants to fix the receipt failure quickly without loosening controls on lot-controlled items.
1. List the validation points you would check, in order, to explain why SENSOR-X cannot be received, and identify the most likely cause from the evidence.
Read the worked answer
Check in this order: first, whether the item exists in the master organization and is not end-dated; second, whether it is assigned to the receiving inventory organization; third, whether the organization-level item status is active and permits receiving; fourth, whether the item attributes allow inventory and stockable transactions in that organization; fifth, whether lot, serial, or revision attributes are consistent with the transaction; and sixth, whether subinventory restrictions or item-subinventory exclusions block the destination.
The most likely cause is missing organization assignment or an organization-level inactive status, because the error explicitly says the item is not assigned. The master-level Active status and the Stockable attribute do not prove organization assignment. An item template can default attributes during item creation, but it does not assign the item to child inventory organizations. The fact that 4,800 items are unassigned and some assigned items have an incorrect organization-level status supports an assignment and status data issue rather than a lot-control issue. Lot-control inconsistencies would more likely produce a lot or revision error after the assignment check passes.
2. Recommend a remediation plan for the 4,800 unassigned items and the 300 lot-control mismatches. Include controls to prevent recurrence.
Read the worked answer
Segment the 4,800 items before mass assignment. Identify which items are actually stocked or transacted in the receiving warehouse, which are only master-level definitions, and which are obsolete. Assign only the required items to the organization, using a controlled item assignment process rather than a blanket update. For items that are assigned but inactive, review the organization-level status and correct only those that should be transactable; do not globally set every item active without a business owner's approval. Validate item attributes, item class defaults, and subinventory restrictions in a test organization before production load.
For the 300 lot-control mismatches, determine whether lot control is truly required at the organization level. If it is, set the organization-level lot attributes, define lot and shelf-life controls, and open or convert lots as appropriate. Do not toggle lot control casually after transactions exist, because historical transactions and on-hand lots may become inconsistent. Prevent recurrence by making organization assignment and status validation part of the item lifecycle workflow, using item templates for attribute defaults only, and running a weekly exception report for items that are active in the master but unassigned or inactive in a transacting organization.
3. How would you handle the 300 items with master-level lot control but no organization-level lot attributes?
Read the worked answer
Treat this as an attribute governance issue, not a simple data cleanup. First confirm whether the business requirement is lot control in that specific organization. If the item is manufactured or received in lots and traceability is required, set the organization-level lot attributes consistently with the master item class. If the item is not lot-controlled in that organization, correct the master or class default so the mismatch does not keep reappearing.
Before changing control, check whether any transactions or on-hand balances already exist. If there are no transactions, the change can be handled through a controlled item update and validation. If transactions exist, changing lot control can break historical lot traceability and may require a new item setup or a carefully approved conversion. Use a sandbox or test organization to validate receiving, lot entry, and reporting. Add a pre-assignment validation that compares master-level control attributes with organization-level attributes, and require item data stewards to resolve exceptions before the item is released for receiving.