# How to integrate Ignition with your ERP

> Source: https://netray.co/erp-help/mes-ignition-to-erp-integration-sql-bridge-named-queries
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

Do not let Ignition write straight into ERP tables. Put a staging layer between them: Ignition writes production events to a staging table or calls an ERP API through a gateway script, and a controlled poster validates and posts them to the ERP. Pull work orders the other way with a scheduled gateway script or Named Query against a read-only view or API.

## Kind

how-to

## System

mfg-systems

## Erp

Ignition (Inductive Automation) with any ERP

## Module

Ignition / Production reporting to ERP

## Query

how to integrate Ignition with ERP

## Alternate Queries

- Ignition SCADA to ERP integration
- Ignition send production counts to ERP database
- Ignition MES work order download from ERP
- Ignition Transaction Groups ERP staging table

## Applies To

Ignition 8.1 and 8.3 gateways with Perspective or Vision, SQL Bridge (Transaction Groups) and Web Dev modules; any ERP that exposes a database view, REST, SOAP or file interface.

## Steps

### Build a safe Ignition to ERP integration

**Items:**

- Decide direction and ownership first: the ERP owns work orders, routings, items and BOMs; Ignition owns machine states, counts, cycle times and operator inputs. Write that down per data element.
- Create a dedicated database connection in the Ignition Gateway (Config, Databases, Connections) pointing at a staging schema, not the ERP production schema.
- Create a staging table such as mes_event with a GUID event_id, work_order, operation, event_type, qty_good, qty_scrap, reason_code, event_ts, status and error_text columns.
- Write events from Ignition with a Named Query (system.db.runNamedQuery) or a Transaction Group, with a unique event_id so a retry cannot double-post.
- Pull open work orders into a local cache table on a gateway timer script, reading from an ERP view or REST endpoint through a read-only account.
- Run a poster outside Ignition (ERP API call, stored procedure, or integration platform) that reads status = 'NEW' rows, posts them, and marks them 'POSTED' or 'ERROR' with the message.
- Add a Perspective or Vision screen for supervisors showing ERROR rows with a retry button, so failures are visible and not buried in a log.
- Test the failure cases: ERP down, work order closed, quantity over-report, duplicate event, and gateway restart in the middle of a post.

## Sections

### Why a staging table beats a direct write

**Body:**

A direct insert from Ignition into ERP tables bypasses the ERP's business logic: costing, inventory transactions, lot and serial control and period checks. Even when it appears to work, you end up with transactions the ERP cannot explain, and a vendor upgrade can change the schema under you. Support teams for most ERPs will not support direct table writes.

A staging table gives you three things. It decouples uptime: if the ERP is down for maintenance, plant-floor events queue instead of being lost. It gives you an audit trail of what the floor reported versus what the ERP accepted. And it gives you one place to apply validation rules such as maximum quantity per event or required reason codes.

The poster can be anything that speaks to the ERP properly: the vendor's API, a documented import program, a message queue, or an integration platform. The point is that the ERP's own posting logic runs, not that you picked a specific tool.

### Ignition-side mechanics

**Body:**

Use Named Queries for anything a script or screen calls, because they are parameterised, centrally managed and avoid SQL string building. In scripts you call system.db.runNamedQuery with a path and a parameter dictionary. Transaction Groups from the SQL Bridge module are good for simple tag-to-table logging on a schedule or on trigger, such as writing a cycle record when a part-complete tag goes true.

For REST-style ERPs, gateway scripts can call out with system.net.httpClient (8.1 and later) or the older system.net.httpPost. Keep credentials in a secure place such as Gateway tag providers or secrets management, never hard-coded in a script. Run calls from a gateway timer or tag-change script, not from a client session, so an operator closing a browser cannot interrupt a post.

If you expose Ignition data to the ERP instead, the Web Dev module lets the gateway serve endpoints, but a staging table the ERP side reads is usually simpler to secure and monitor.

**Code:**

# Gateway script: queue a production event with an idempotent key
import uuid
params = {'eid': str(uuid.uuid4()), 'wo': wo, 'op': op, 'good': good, 'scrap': scrap, 'ts': system.date.now()}
system.db.runNamedQuery('MES/insertProductionEvent', params)

-- Staging table (SQL Server flavour)
CREATE TABLE mes_event (
  event_id UNIQUEIDENTIFIER PRIMARY KEY,
  work_order NVARCHAR(30) NOT NULL,
  operation INT NOT NULL,
  event_type NVARCHAR(20) NOT NULL,
  qty_good DECIMAL(18,4) NULL,
  qty_scrap DECIMAL(18,4) NULL,
  reason_code NVARCHAR(20) NULL,
  event_ts DATETIME2 NOT NULL,
  status NVARCHAR(10) NOT NULL DEFAULT 'NEW',
  error_text NVARCHAR(500) NULL
);

### Pulling work orders and master data

**Body:**

The cleanest pattern is a read-only database view in the ERP, or a read API, exposing only what the floor needs: work order number, item, description, quantity ordered, quantity completed, current operation, work center, planned dates and status. A gateway timer script copies this to a local table every minute or so, and Perspective screens read the local copy, so screens stay fast even if the ERP is slow.

Do not copy the whole routing and BOM unless you need them on screen. Smaller data means fewer sync bugs. Always carry a last-updated timestamp so you can detect a work order that was released, changed or closed in the ERP after the operator loaded it.

If the ERP is on-premises behind a firewall and Ignition is on a plant network, place the staging database in the DMZ or on the ERP side and let both systems connect outbound to it, rather than opening plant network ports inbound.

### Error handling and reconciliation

**Body:**

The most common production failures are not network failures. They are business rejections: the work order was closed, the operation was already completed in the ERP, the lot number is missing, or the quantity would exceed the order. Your poster must write the ERP's message back to error_text so a supervisor can fix the cause.

Build a daily reconciliation: for each work order and operation, compare the sum of POSTED good quantity in staging against the ERP's reported completed quantity. Differences point to manual ERP adjustments or lost events and should be reviewed, not silently corrected.

Keep time handling explicit. Store event timestamps in UTC and convert at the edges, since plant, gateway and ERP clocks and time zones often differ and daylight saving changes cause duplicate or missing hours in shift reports.

## Pitfalls

- Writing directly into ERP tables from Ignition, which skips costing, inventory and audit logic and can break on upgrade.
- Posting without a unique event ID, so a gateway retry or restart double-counts production.
- Running ERP calls inside client or Perspective session scope, so closing a browser aborts the transaction.
- Hard-coding ERP credentials in scripts, or using an ERP admin account for the integration.
- Using one huge polling query against the ERP every few seconds instead of a cached read-only view on a sensible interval.
- Having no reconciliation, so drift between floor quantities and ERP quantities is found at month-end.

## Ai Angle

An assistant grounded in your ERP and staging database can answer the questions supervisors actually ask: which production events failed to post today and why, which work orders have floor counts that do not match ERP completions, and what changed in the ERP after a job was loaded on the floor. With a tool like ERPray it runs read-only against the ERP and staging schema, shows the query it used, and respects ERP roles. It does not post transactions on its own; any correction still goes through your normal poster or a human approval.

## Faq

### Does Ignition have a native ERP connector?

**Answer:** Ignition is a platform, not an ERP product, so integration is built with its database connections, Named Queries, Transaction Groups, gateway scripts and modules. Some ERP vendors and integrators publish Ignition-based accelerators, but in most plants you build the interface yourself or with a partner. Check with your ERP vendor for supported interfaces before designing.

### Should Ignition or the ERP be the system of record for production quantities?

**Answer:** The ERP is normally the financial system of record, because inventory and cost depend on it. Ignition is the source of the raw events. Treat staging as the buffer: floor events are captured there, validated, and posted into the ERP, and reconciliation proves they agree.

### Can I use MQTT instead of SQL for this?

**Answer:** Yes, MQTT with a broker is a valid transport, often used with Sparkplug B for tag data. For ERP posting you still need a consumer that validates and calls the ERP API. SQL staging is simpler to audit for many plants, while MQTT suits multi-site and event-driven designs.

### How often should Ignition poll the ERP for work orders?

**Answer:** Every one to five minutes is typical for released work orders, using a read-only view or API. Poll more often only for specific high-priority screens. Frequent heavy queries against the ERP can hurt user performance, so cache locally and keep the query narrow.

## Search terms

Ignition ERP integration, Ignition SCADA to ERP, Ignition Named Queries ERP, Ignition Transaction Groups, Ignition MES production reporting, Ignition staging table, Perspective work order screen, post production counts to ERP, Ignition work order download, Inductive Automation ERP

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json