How IFS's site/warehouse/bay-row-tier/bin location model, Inventory Part in Stock, availability control, inventory transactions, and valuation methods translate into D365 storage and tracking dimensions, on-hand inventory, warehouse management, and the inventory close.
IFS organises its physical inventory world in a strict hierarchy: Site → Warehouse → Bay → Row → Tier → Bin Location. Each level carries attributes that control how inventory is received, stored, and issued.
The IFS location hierarchy forms the addressing system for every inventory transaction:
INVENTORY_PART_IN_STOCK is the IFS table recording the actual stock position: part number, site, warehouse, location, lot/batch, serial number, quantity, and inventory value. Each row represents a homogeneous stock position — the same part, same location, same batch.
Every physical movement in IFS posts an INVENTORY_TRANSACTION record, tagged by transaction type (Receipt, Issue, Transfer, Adjustment) and carrying quantity, cost, and location. Transaction types control whether the movement is financially valued (financial inventory update) and whether it requires a lot/batch or serial number.
D365's storage dimension model gives precise control over the granularity at which inventory is tracked. The storage dimension group assigned to a released product activates or deactivates tracking at each level:
Cycle counting in IFS uses count triggers (ABC class frequency, manual cycle) to generate count tasks for specific locations and items. Results are entered and posted as inventory adjustments.
IFS's inventory model is rich and site-centric. The key translation challenge is the IFS Site's dual operational and financial meaning, which splits across D365 constructs and must be explicitly designed rather than assumed.