How Epicor's single Part record — carrying site-level attributes, classification, costing method, UD fields and revision history — decomposes into D365's shared product, released product per legal entity, dimension groups, item model groups, product categories, and default order settings.
The Epicor Part record is deceptively simple on the surface. A single part number carries everything: classification (Part Class), sales grouping (Product Group), costing method, purchase and sales unit of measure, lot and serial tracking flags, revision history, and — critically — per-site parameters held on the PartPlant record.
Epicor holds one Part record per item. Whether the organisation has one company or many, the part exists once. Site-specific behaviour — lead times, preferred vendors, planning parameters — lives on the PartPlant record, a child of Part scoped to a site/plant.
GL account defaults — through GL Controls attached to the Part Class, determining which accounts receive inventory receipt, issue, COGS, and WIP postings. Default attributes — setting default tracking (lot/serial), costing method, and product type for new parts in the class. Classification — grouping parts for analysis and reporting.
Epicor's standard part record does not natively support product dimensions (size, colour, style). Variants are typically managed as separate part numbers or through the Product Configurator for configure-to-order scenarios.
Epicor groups units into UOM classes (e.g., Weight, Length, Volume, Count) and defines intra-class conversions. Each Part carries purchase, sales, and inventory UOM assignments, typically drawn from the same class.
Epicor flags parts as lot-tracked, serial-tracked, or both at the part level. Lot and serial numbers are assigned at receipt and carried through subsequent transactions.
Epicor assigns a costing method to each part individually. The documented methods include Standard, Average, FIFO, Last, Lot, and Serial — though the full enumeration requires confirmation against the client's specific release (this detail is EpicWeb-gated and classified as secondary evidence).
Epicor's PartPlant record holds per-site parameters: preferred vendor, lead time, minimum/maximum order quantities, planning parameters, MRP policy overrides, and sometimes a site-specific costing variant. A part with three sites in Epicor has three PartPlant records, each potentially carrying different values.
Epicor part numbers are alphanumeric and often encode meaning — a prefix for the Part Class, a segment for the site, a revision suffix. D365 allows alphanumeric item numbers of up to 20 characters (or more with configuration), so a direct carry-forward is technically possible.
Epicor's UD fields on Part and PartPlant are not free-standing data columns. They are consumed by the customisation surface: BAQs read them, BPM directives evaluate them, Application Studio layers display them, and SSRS reports print them.
After the product master load (Wave 2 in the site's eight-wave model), the team must prove that the D365 catalogue faithfully represents the Epicor source. This is not a row-count exercise alone — it requires functional validation:
The Epicor Part record maps to D365 with reasonable conceptual clarity, but the structural decomposition is non-trivial. One Epicor record becomes many D365 objects, each independently configured and each carrying migration-sequence dependencies.