Storage and tracking dimensions decide how precisely stock is described; the item model group decides how it is valued and when it posts. Plus the two-stage physical and financial lifecycle, and why the inventory close exists at all.
Most mid-market ERPs answer these with fields. A warehouse field, a lot number field, a costing method field on the item. The fields work, and they are why the model feels simple.
An inventory dimension is a declared part of the stock identity. On-hand is not one number per product — it is a number per combination of the dimensions you switched on.
The item model group is where an item's behaviour is declared. It bundles several decisions that are genuinely related.
An inventory movement is not one event. It has a status that moves through stages, and both a physical and a financial dimension.
When you issue stock, the system needs a cost for it. But at the moment of issue it may not yet know which receipt that issue consumed, and it may not even know the final cost of the receipts — the vendor invoice might not have arrived, or a landed-cost charge might still be coming.
Transfer orders move stock between warehouses and carry in-transit quantity. That matters more than it sounds: a transfer modelled as an issue in one place and a receipt in another makes the goods vanish for however long the journey takes. A transfer order keeps them visible and owned.
Some inventory choices can be revisited cheaply. These cannot, once transactions exist:
Inventory in D365 replaces fields with declared structures, and that is what buys real traceability and correctable cost.