Maconomy tracks project cost, not physical inventory. For most Maconomy estates, inventory management in D365 is a new capability rather than migrated capability. This module teaches D365's inventory model from first principles and frames the scoping decision that precedes all design work.
Maconomy is a project-accounting system. It tracks cost against jobs — what was spent, by whom, for which client — but it does not manage physical inventory. There are no warehouses, no stock locations, no batch or serial tracking, no valuation models, and no inventory transactions in the sense that D365 uses the term.
Before designing sites, warehouses, dimension groups, and costing methods, hold a structured workshop to answer one question: which items, if any, require physical inventory tracking in D365?
If the scoping gate determines that inventory is needed, the first structural concept is the storage hierarchy: the physical topology in which D365 tracks stock.
The dimension group is the product-level configuration that determines how inventory is tracked for a released product.
The item model group (InventModelGroup) determines how inventory cost is calculated and carried on the balance sheet. This is a finance decision with direct ledger consequences.
Every movement of stocked inventory in D365 creates a record in the InventTrans table. This is the core inventory transaction — it records what moved, where, when, and at what cost.
Inventory counting journals compare physical counts to system on-hand and post adjustments. They can be:
D365 supports inventory reservation: the ability to earmark on-hand or ordered stock for a specific demand (sales order, project requirement, production order).
Site + warehouse (+ optional fixed location) Receipt posts directly to inventory on-hand Issue posts directly from inventory on-hand Movement journals transfer between warehouses No directed work, no wave processing, no licence plates
If the scoping gate determines that inventory is in scope, opening balances are loaded in Wave 4 of the migration sequence. For most Maconomy migrations, this is a small exercise because there is little or no source inventory data.
Maconomy tracks project cost, not physical inventory. For most Maconomy estates, D365 inventory management is a new discipline, not a migrated one. The migration consequence is not a data-mapping exercise — it is a scoping decision that determines whether the inventory module, with all its irreversible design choices, is activated at all.