ERP and PLM reference architecture - ION Manual

Overview

ION integrates with two adjacent system classes in every hardware-manufacturing stack: PLM (Product Lifecycle Management) upstream and ERP (Enterprise Resource Planning) downstream. This page is the reference for those integrations: what flows where, what doesn’t, and the recommended deployment sequence. Read this before scoping an integration with Arena, NetSuite, Teamcenter, Duro, Onshape, or any other ERP or PLM system. The per-vendor pages cover how a specific connector works; this page covers why the architecture is shaped the way it is.

Diagrams in this doc are authored in Mermaid and render natively in the manual.

ION in the factory stack

ION Factory OS is a Manufacturing Execution System (MES) at Level 3 of the ISA-95 enterprise-control hierarchy, with native production planning extending into Level 4. ION’s job is to track and document the transformation of raw materials into finished goods on the production floor, and to be the closed-loop bridge between the engineering systems that define what gets built (PLM) and the financial systems that transact what gets bought, sold, and counted (ERP).

Plans, intent,

transactions

Setpoints,

process data

Level 0: Physical Process

Sensors · Actuators · Machines

Level 1: Direct Control

PLC · DCS

Level 2: Supervisory Control

SCADA · HMI · Historians

Level 3: Manufacturing Operations Management

ION Factory OS

MES + native production planning

Runs · Procedures · Quality · Labor · Traceability · As-built · Inventory (shop-floor)

Adjacent L3 systems

LIMS · WMS · CMMS

Level 4: Business Planning & Logistics

ERP

NetSuite · Dynamics 365 · SAP · Epicor

PLM

Teamcenter · Arena · Windchill · Onshape · Duro · SolidWorks PDM

CRM · HRM

Every integration question reduces to which level owns this data, and who else needs a copy? The rules below fall out of this picture.

Why integrate at all: the business goals

Every ERP and PLM integration ION ships should trace back to one or more of these outcomes. If a proposed integration scope does not advance one of these, it is not the right scope.

These are the goals to lead with on the first slide of any integration scoping conversation. Everything below is the architecture that makes them deliverable.

The triad: PLM, MES (ION), ERP

These three systems are the operational triad of any modern hardware manufacturer. Each owns a distinct part of the product’s life. Trouble starts when one tries to do another’s job.

ERP: Financial Transactions

ION: Production Reality

PLM: Product Intent

Parts · eBOM · routings · ECNs

As-built · NCRs · test results

POs · suppliers · terms

Receipts · completions · consumption

What the product

should be

Engineering BOM (eBOM)

Parts · Revisions · Drawings

ECN / ECR

Routings (engineering)

Product hierarchy

What the product

actually became

Runs · Procedures

As-built BOM (aBOM)

Quality / NCRs / MRBs

Labor · Traceability

Shop-floor inventory

Issues · Deviations

What the product

cost and earned

Suppliers (financial)

Purchase Orders

Item Receipts

Item master (financial)

GL · AP · AR · Costing

One-line summary:

• PLM = the intent (engineering definition).
• MES (ION) = the reality (what actually happened on the floor).
• ERP = the accounting (what was bought, what was received, what was paid).

The rest of this document is precision around what flows between them.

PLM ↔ ION reference architecture

PLM is the system of record for the engineering definition of the product. ION is the system of record for what the production floor does with that definition.

The BOM lifecycle: eBOM → mBOM → aBOM

The BOM is not a single object. It evolves across the manufacturing lifecycle, and each stage has a different owner. Conflating them is the most common source of integration scope confusion.

The flow is eBOM (PLM) → mBOM (ION) → aBOM (ION) → optional feedback to PLM.

When there is no PLM: Many small or mid-stage manufacturers have no formal PLM. In that case, ION holds what is functionally an mBOM (sometimes informally called “the BOM”), and there is no upstream eBOM. This is acceptable for Phase 1 deployments. As soon as PLM is introduced (often Phase 3), eBOM authority moves to PLM, and ION’s BOM becomes explicitly the mBOM. The “BOM lives in ION” state is transitional, not a permanent architectural commitment.

Canonical data flows: PLM → ION

Canonical data flows: ION → PLM

What does NOT cross the PLM ↔ ION line

• eBOM authoring in ION. PLM owns the engineering BOM when PLM exists. ION derives an mBOM from it; ION does not modify the eBOM.
• Drawings / CAD in ION. ION holds reference links, not drawings. PLM is the source.
• Engineering revisions in ION. Revision authority lives in PLM. ION shows the released revision in production context.
• Real-time CAD round-trip. No live CAD editing from ION. If the operator finds a problem, that becomes an NCR or MRB, which feeds an ECR back to PLM, where the engineer makes the change.

ION’s PLM connector posture

• Production today: Arena (multiple A&D customers), Onshape (selected customers), Duro (in deployment).
• Partner-built: Teamcenter (via a PLM systems-integrator partner). Teamcenter integration sits at the PLM customization edge: most customers engage their PLM consultant for the Teamcenter side, and ION owns the ION side.
• Verify before scope: PLM systems often have major version differences (Duro vs. Duro Hub, Windchill versions, on-prem vs. cloud Teamcenter). Verify the customer’s actual deployment before signing scope.

ERP ↔ ION reference architecture

ERP is the system of record for financial transactions. ION is the system of record for production execution. They share a small, well-defined set of objects.

Canonical data flows: ERP → ION

Canonical data flows: ION → ERP

Syncing to ERP

Prefer event-driven sync over scheduled polling. ION emits webhooks the moment an event occurs, such as a run completing or a receipt posting, so the ERP stays current and failures surface in context instead of on the next poll. If your ERP doesn’t need updates that often, have your integration queue ION’s events and batch them into the ERP on a schedule. ION has supported integrations with NetSuite, Epicor, Dynamics 365, Business Central, Odoo, and Infor.

To sync as-built consumption to the ERP, query the aBOM installations on the part inventory produced by completed runs:

query ($filters: RunsInputFilters) {
  runs(filters: $filters) {
    edges {
      node {
        title
        partInventory {
          part { partNumber }
          quantity
          buildRequirements {
            abomInstallations {
              quantityInstalledPerParentPartInventory
              partInventory {
                location { id }
                part { partNumber }
              }
            }
          }
        }
      }
    }
  }
}

For each installed part inventory, multiply the quantity produced by quantityInstalledPerParentPartInventory to get total consumption. The same component can appear more than once when it’s installed from different inventory locations. For a run that produced three of Assembly Part One, that gives 15 of Component Part One (2.4 × 3 + 2.6 × 3) and 9 of Component Part Two (3 × 3).

What does NOT cross the ERP ↔ ION line

• Bidirectional inventory sync. ION owns shop-floor inventory in real time. ERP owns financial inventory at posting cadence. They reconcile periodically. They do not bidirectionally mirror. This is the single most damaging anti-pattern in MES/ERP integration. (See Rule 5 below.)
• Production scheduling in ERP. Work order release and floor scheduling live in ION. ERP can hold high-level demand or master schedule, but the dispatch happens in MES.
• GL postings authored by ION. ION emits the events (receipt, completion, labor). ERP posts to GL according to its own rules.
• Vendor bills, invoices, AP, AR. ERP-only. Out of any normal ION integration scope.
• Items master authored by ION. If PLM is in the picture, PLM authors. If ERP is the only product-data system (rare for hardware companies that build), ERP authors. ION never authors.

ION’s ERP connector posture

• Production today: NetSuite (multiple deployments), Dynamics 365 (electric aviation customer).
• In-flight: SAP (early scoping; pattern not yet certified).
• Customer-side configuration is the customer’s responsibility: custom forms, scripts, saved searches, OAuth, role permissions, sandbox provisioning. Either the customer’s internal ERP admin or the customer’s ERP consulting partner.

The 3-way match: the canonical AP control loop

The single most-asked-for outcome from any ERP integration is 3-way match: the financial control that prevents an invoice from being paid unless three documents agree.

ERP (3-way match)

ION (production)

Receipt in ION

creates Item Receipt

All three agree

(qty, price, item)

Run / Receipt event

on the floor

Purchase Order

What was authorized

Item Receipt

What physically arrived

Vendor Bill

What the vendor invoiced

3-way

match

AP releases

payment

ION’s role in 3-way match: ION’s job is to make the Item Receipt real, automatic, and accurate by recording what physically arrived at the receiving dock and triggering the matching ERP record. Without a connected ION, the Item Receipt is a manual data-entry step in the ERP that operators forget, mis-key, or batch up. This is where most “phantom payments” and “missed receipts” come from.

Why this is the lead outcome: every CFO understands 3-way match. It is the easiest integration goal to socialize internally and the most defensible ROI story.

What 3-way match needs from each side:

Multi-location and inter-location transfers

Customers with multiple physical sites introduce a class of integration questions that single-site customers do not face:

• Where does inter-location inventory transfer get recorded? ION owns the operational transfer (parts physically move site-to-site under custody chain). ERP owns the financial reclassification (inventory by location for tax / GL).
• Granularity question: does the ERP need site-level inventory tracking, or is location-level handled entirely in ION? Most customers benefit from site-level rollups in ERP and bin/cell-level granularity in ION.
• Planning question: does demand at one site automatically trigger procurement at another, or are sites planned independently? This is a planning-system question more than a strict integration question, but it shapes how much of MRP / Autoplan to expose across sites.

These are scoping questions for the Phase 2 / Phase 3 conversation. Surface them early when the customer has more than one site.

PO setup attributes

ERP POs typically carry attributes that ION needs but doesn’t author: department, location, cost center, project code, GL account override, tax code. These need to flow with the PO so that ION can route receipts to the correct location and so that downstream financial events (consumption, completion) carry the right tags. The ION NetSuite connector handles this via configurable PO Header and PO Line attribute data maps. For non-NetSuite ERPs, equivalent mappings need to be defined per integration. This is configuration, not code, but it is non-trivial work that should not be skipped at scoping time.

The combined picture: ION as the execution spine

In a fully-instrumented A&D or hardware manufacturer, the three systems form a closed loop. Engineering defines (PLM), production executes (ION), finance accounts (ERP). Each cycle of build → release → ship → invoice closes through ION.

Granular entity flow

The triad above is the executive view. Below is the entity-level flow used in scoping. Each circle is a real object that exists in one of the three systems; each arrow is a real integration touchpoint.

ERP

ION Factory OS

PLM

Engineering

identity

Released

revision

Change

notification

Engineering →

financial identity

PO sync

Supplier ref

PO line attributes

Optional financial

lookup

Triggers

Item Receipt

Consumption

posting

Cost-plus labor

Reconciliation

(NOT bidir sync)

NCR → ECR

As-built

Items

(engineering)

eBOMs

ECNs / ECRs

Sales order /

demand

Plans

mBOMs

Procedures

Parts

(operational)

Work order

Run

aBOM

(material consumption)

Receipt

(shop floor)

Granular Inventory

(bin / cell level)

NCRs / MRBs

Labor

Scrap

Items

(financial)

Vendors

Purchase Order

PO Setup Attributes

(dept · location · GL)

Vendor Bill

Item Receipt

Inventory

(financial valuation)

GL · AP · AR

3-way

match

How to read this diagram:

• Solid arrows are first-class integration flows that ship in certified connectors.
• Dotted arrows are reconciliation / posting flows that happen on a cadence rather than per-event (consumption postings, financial inventory reconciliation, as-built feedback to PLM).
• The 3-way match cluster is the canonical AP control described above.
• Sales order / demand is the entry point. Demand into ION can come from ERP sales orders, internal Autoplan / MRP, or both.
• Run is the unit of execution in ION. Everything downstream (aBOM, receipts, quality, labor, scrap) is keyed to a run.

Reference deployments

ION is in production across the following ERP and PLM combinations. New customers can scope against these patterns rather than starting from scratch.

The recommended sequence for a new customer

The following deployment sequence is recommended. Each phase is useful on its own, so you can adopt them in order without waiting to finish the rest.

Phase 1: Foundation

ION standalone

Runs · Procedures · Quality

Inventory (shop-floor)

Operator workflows

Traceability

Phase 2: Connect

ERP integration

POs · Receipts · Suppliers

(via certified connector)

Phase 3: Engineering loop

PLM integration

Parts · eBOM · ECNs · Routings

As-built feedback

Phase 4: Orchestrate

Forward-deployed scope:

ION-driven PO creation

(Autoplan)

Cost roll-ups

Outside processing

Phase 1, Foundation. ION is deployed standalone as the production system of record. Procedures, runs, quality, kitting, traceability, and shop-floor inventory live in ION. ERP and PLM continue to operate as today. No integration dependency for go-live. This pattern protects margin and de-risks the launch.

Phase 2, Connect (ERP). A pre-built, certified connector links ION to the ERP. POs flow into ION, receipts flow back. The customer’s ERP admin or consultant configures the ERP-side; ION’s team configures the ION-side. Configuration, not custom development.

Phase 3, Engineering loop (PLM). PLM integration brings part master, eBOM, and engineering change notifications into ION; sends as-built and NCR data back. Often phased: parts + eBOM first; ECNs and as-built second.

Phase 4, Orchestrate. Forward-deployed engineering work that goes beyond the certified connectors: ION-driven PO creation via Autoplan, financial cost roll-ups, outside processing flows, cost-plus labor reporting. Scoped per engagement, not assumed.

Canonical rules

The following rules apply to every ION integration. They are the distillation of canonical MES/ERP/PLM literature (ISA-95, MESA) and the accumulated experience across 20+ customer deployments. They exist to keep integration scope aligned with what actually works, and to prevent the failure patterns that are easy to fall into during early scoping conversations.

Source documents

• ISA-95 standard: ANSI/ISA-95.00.01 Enterprise-Control System Integration
• MESA model: Manufacturing Enterprise Solutions Association, MESA-11 functional areas