From job activities and rate tables to released products
Understand what Maconomy actually has in place of a product catalogue — activities, amount types, expense types, price lists, and purchase items — then learn D365's full product data model from first principles, anchored in concepts a Maconomy practitioner already knows.
What you will be able to do
Describe what Maconomy provides in its job-costing structures and what it does not provide in terms of product management
Explain why Maconomy activity types and amount types are project-cost classifications, not product definitions
Design the shared product, product master, and released product structure for a Maconomy migration
Choose appropriate product dimension groups, item model groups, and storage dimension groups
Map Maconomy procurement categories and purchase items to D365 procurement categories and released products
Distinguish a procurement category (the natural landing zone for most Maconomy spend) from a released product
Introduction
Maconomy is a professional-services ERP. It does not have a product catalogue in the way that a manufacturing or distribution system does. There is no product master, no product variants, no item model groups, and no storage dimension hierarchy.
What Maconomy Has: Job-Costing Constructs
Maconomy's approach to classifying "what was bought" or "what was worked on" is built entirely around the project cost model. The constructs serve billing, reporting, and accounting — not inventory management.
The Project Category Landing Zone
For most Maconomy objects, the natural D365 landing zone is the project category — not the product master.
The Procurement Category Path
For non-stocked, non-tracked purchasing — which is the majority of Maconomy spend — D365 offers procurement categories as an alternative to released products.
D365 Product Data Model from First Principles
For the items that do require released products, the migration team must understand the full D365 product data model. This section teaches it from first principles.
Item Groups and Posting Profiles
D365 item groups (InventItemGroup) aggregate released products for financial posting. Each item group is assigned a posting profile that determines which ledger accounts are used for:
Trade Agreements and the Rate-Table Bridge
Maconomy rate tables resolve cost and sales prices through a precedence hierarchy. D365 uses trade agreements and project price records to achieve similar results, but through different mechanisms.
Migration Sequence and Dependencies
Product data sits in Wave 2 of the migration sequence, but for a Maconomy estate the work is primarily design rather than data extraction.
Knowledge check
Summary
Maconomy's product-data surface — activity types, amount types, expense types, price lists, and purchase items — is a set of job-costing constructs designed to classify project cost and revenue. It is not a product management system.