AdvancedSYSPRO (on-prem)AI integration / Private architecture

How to Add AI to SYSPRO On-Prem Without Moving Your Data

Question
how to add AI to SYSPRO on-prem

Also searched as

  • SYSPRO AI integration without cloud
  • SYSPRO private LLM on-prem
  • SYSPRO e.net business objects AI assistant
  • chat with SYSPRO data on premises

Short answer

SYSPRO runs on SQL Server with one database per company, and it exposes supported read and write paths through e.net Solutions business objects. A private AI layer reads from a read-only SQL Server copy, answers from a local open-weight model on your own GPUs, and writes back only through business objects after a human approves. Nothing has to leave your network.

Applies to: SYSPRO 7 Update 1 and SYSPRO 8 on-premises, SQL Server back end. Business object names and XML schemas vary by release, so check the e.net documentation for your version.

Add a private AI layer to SYSPRO in seven steps

  1. 1Inventory what SYSPRO holds today: which companies, which modules (inventory, sales orders, work in progress, purchasing, MRP), and which operators need which answers.
  2. 2Stand up a read-only copy of the company databases on SQL Server, using an Always On readable secondary, log shipping with a standby restore, or transactional replication.
  3. 3Create a dedicated schema of views over the tables the assistant may read (for example inventory, sales order and job views) and a login that can select only from that schema.
  4. 4Expose approved read actions as tools: parameterised SQL views for bulk questions, and e.net query business objects such as INVQRY and SORQRY for single-record lookups that honour SYSPRO logic.
  5. 5Build a retrieval index over documents and attachments (drawings, certificates, supplier PDFs, work instructions) with the permissions of the source folder carried into the index.
  6. 6Serve an open-weight model with vLLM or Ollama on local GPUs, behind an internal gateway that logs every prompt, tool call, SQL statement and answer.
  7. 7Roll out in phases: read-only questions first, then drafts of documents and transactions, then approved actions through business objects with a named human approver.

Data access paths in SYSPRO

SYSPRO stores each company in its own SQL Server database, with a separate system-wide database for operators, companies and setup. Core tables follow a readable naming pattern: InvMaster for stock codes, InvWarehouse for quantities by warehouse, SorMaster and SorDetail for sales orders, WipMaster for jobs, PorMasterHdr and PorMasterDetail for purchase orders, ArCustomer and ApSupplier for the sub-ledgers. Confirm column names against the data dictionary for your release before you freeze a view.

For reads that need SYSPRO business logic rather than raw rows, use the e.net Solutions business objects. Query objects such as INVQRY and SORQRY take an XML request and return XML, and they run under a SYSPRO operator so operator security applies. Posting objects such as SORTOI and PORTOI create transactions with full validation. The e.net layer is reachable through COM, .NET and the web services front end.

Bulk analytical questions ("which warehouses are below safety stock for stock codes in this category") belong on SQL views. Single-record questions ("what is the status of sales order 000123") are better served by a query business object, because the result matches what the operator would see on screen.

-- Read-only view over the replica (verify column names for your release)
CREATE VIEW ai_read.v_stock_by_warehouse AS
SELECT m.StockCode, m.Description, w.Warehouse, w.QtyOnHand
FROM dbo.InvMaster m
JOIN dbo.InvWarehouse w ON w.StockCode = m.StockCode;

SELECT TOP 50 StockCode, Warehouse, QtyOnHand
FROM ai_read.v_stock_by_warehouse
WHERE StockCode LIKE 'A1%' AND QtyOnHand <= 0;
<!-- INVQRY request shape: confirm against the XSD shipped with your version -->
<Query>
  <Key>
    <StockCode>A100</StockCode>
  </Key>
</Query>

Reference architecture, including the air-gapped option

The pattern has six parts: a read-only SQL Server replica, change data capture feeding the retrieval index, a document index, a tool server that exposes only approved read actions, a model server, and an audit log. SQL Server change tracking or CDC on the replica source tells the indexer which rows changed, so the index stays current without scanning the company database.

The tool server can speak the Model Context Protocol so any compliant client can call the same approved actions. Each tool has a fixed SQL view or a fixed business object call, a parameter schema, and a row limit. The model never receives a connection string and never composes arbitrary SQL against the live database.

For an air-gapped site, the entire stack runs inside the enclave: model weights are carried in on approved media, container images come from an internal registry, and the gateway has no outbound route. Updates to the model or index happen by controlled import, not by the internet.

# Tool definition exposed to the model (illustrative)
{
  "name": "syspro_stock_by_warehouse",
  "description": "On-hand quantity by warehouse for a stock code pattern",
  "source": "ai_read.v_stock_by_warehouse",
  "params": {"stock_code_like": "string", "warehouse": "string?"},
  "max_rows": 200,
  "mode": "read-only"
}

Permissions and write-back

SYSPRO secures access by operator, with operator groups, company access, warehouse and branch restrictions, and per-program permissions. The assistant should act as the asking user, not as a service account with broad rights. Practically: authenticate the user with the same directory the operators use, map the directory account to the SYSPRO operator code, and apply that operator's company and warehouse list as mandatory filters on every tool call. Where a view cannot express the restriction, route that question through the business object so SYSPRO itself enforces it.

Write-back goes only through supported business objects. The assistant prepares a draft (for example the XML for a sales order line change or a stock adjustment), shows the exact payload and the expected effect, and waits for a named approver. On approval the gateway submits the XML under that approver's operator code, so SYSPRO audit trails show a person, not an AI. Direct UPDATE statements against SYSPRO tables are out of bounds, because they skip validation, allocation and journal logic.

Sizing and phased rollout

For a typical SYSPRO site with 50 to 500 named users, expect 1 or 2 data center GPUs to be enough for an assistant serving a 14B to 32B class open-weight model, with a second GPU mainly for resilience. A 70B class model usually needs two 80 GB GPUs or aggressive quantization. The retrieval index is modest: tens of thousands of documents typically fit in a few tens of gigabytes including vectors. Treat these as planning ranges and measure with your own prompts.

Phase 1 (4 to 8 weeks): read-only questions on stock, orders, jobs and purchasing, with every answer showing the query used. Phase 2: drafts such as supplier emails, shortage summaries, job traveller notes and transaction payloads, all unsent. Phase 3: approved actions through business objects for a short list of low-risk transactions, each with an approver and rollback procedure.

Honest limits

If your questions are mostly "show me this report", SYSPRO Reporting Services, Analytics or a BI tool you already own may be enough, and cheaper. A language model adds value for questions that cross modules, need explanation, or involve documents. Custom forms, user-defined fields and heavy customisation need mapping work; the assistant only knows what the views and descriptions tell it.

Version constraints apply: business object availability, XML schemas and web service options differ between SYSPRO 7 and 8 releases. Companies with several sites on separate servers need one replica and one tool server per site or a federated design. Model answers on numeric aggregates should come from SQL, never from the model's own arithmetic.

Try it here, free

SYSPRO Private AI Layer Blueprint Generator

Open full tool

Generate a shareable architecture plan for adding a private, on-prem AI assistant to SYSPRO: read replica, e.net business objects, retrieval index, local model serving, permissions and audit.

Common pitfalls

  • !Pointing the model at the live production database with a broad login, which risks load spikes and exposes every company.
  • !Skipping operator-to-user mapping so every employee sees the same data through the assistant.
  • !Letting the model write SQL freely instead of calling fixed views and business objects.
  • !Indexing attachment folders without carrying their folder permissions into the index.
  • !Posting transactions with a shared service operator so the audit trail shows no human.
  • !Trusting model arithmetic for totals instead of returning SQL aggregates.

How an ERP-grounded AI assistant handles this

ERPray connects to SYSPRO as a grounded, read-only assistant: it shows the query behind each answer, respects operator rights, and can run on your own GPUs. For custom builds, Netray designs the tool server, retrieval index and approval workflow with your SYSPRO partner so the work fits how your operators already use the system.

See ERPray

Frequently asked questions

Can I run AI on SYSPRO without sending data to the cloud?

Yes. SYSPRO data sits in SQL Server on your servers. Replicate it read-only, serve an open-weight model with vLLM or Ollama on local GPUs, and keep the gateway inside your network. In an air-gapped design there is no outbound route at all.

Should the AI read SQL tables or use e.net business objects?

Use both for different jobs. SQL views suit bulk and analytical questions on a replica. Query business objects suit single-record lookups where SYSPRO logic and operator security should decide what is shown. Posting always goes through business objects.

How do operator permissions carry over?

Map each directory user to a SYSPRO operator, then apply that operator's company, warehouse and program rights as filters on every tool call, or route the call through a business object so SYSPRO enforces them.

How many GPUs does a SYSPRO assistant need?

Often one or two for 50 to 500 named users on a mid-size open-weight model, plus spare capacity for resilience. Peak concurrency, context length and model size drive the number, so measure with real prompts before buying.

Related

Advanced

SYSPRO SQL Query for Inventory On Hand by Warehouse

SYSPRO runs on SQL Server with one database per company, typically named like SysproCompanyA, and inventory is split between InvMaster for part-level data and InvWarehouse for quantities per warehouse. Join them on StockCode, filter, and read the quantity columns. Use a read-only login, never write to SYSPRO tables directly, and prefer e.net business objects for any change.

How-to

How to Create a SYSPRO Sales Order with the SORTOI Business Object

SORTOI is the SYSPRO e.net business object that enters sales orders from outside the SYSPRO client. You log on to get a session id, call the business object with a Parameter XML and a Document XML describing the order header and lines, then read the XML that comes back for warnings and the new sales order number. Always test in a non-production company first.

Advanced

Sage X3 AI Integration On-Prem: A Private Architecture

Sage X3 keeps data in SQL Server or Oracle, in a schema named after the X3 folder, and exposes supported access through the Syracuse server using SData REST and published SOAP web services. A private AI layer reads from a replica, answers with a local open-weight model, and writes back only through X3 web services after human approval, so data stays on your servers.

How-to

SYSPRO reporting API: e.net, SRS server-side reporting, Crystal Reports and SRS preview problems

SYSPRO gives you three reporting routes: the e.net Solutions business object API (XML in, XML out) for programmatic data, SYSPRO Reporting Services (SRS) for designed reports run on the server, and Crystal-based or SQL-based custom reports. If the SRS preview does not work, check the services, the runtime and bitness, the SQL permissions and the client and server versions in that order.

Error fix

Error validating SYSPRO online profile: what it means and how to fix it

A profile validation error means the SYSPRO client or service could not confirm the operator, company, licence or database connection it was handed at logon. Check the service and licence first, then the operator and company, then the database and disk, in that order. Storage errors are usually full disks, a locked SQL file or a tempdb problem rather than a SYSPRO bug.

How-to

How to update SYSPRO (and how to check the latest version)

SYSPRO 8 ships as named releases (for example 2022 R1 style names) plus later updates, and the current release is listed on the SYSPRO partner and customer portals, not on a fixed public page. To update, back up, test the new build on a copy of your data, then update the server, services and clients in a planned window.

AI for ERP

AI for SYSPRO, Grounded in Your Own Manufacturing Data

Add AI to SYSPRO without moving your manufacturing data to a public model. On-premise and private-cloud LLMs for SYSPRO in Australia, NA, and beyond.

AI for ERP

A Private LLM Grounded on Your ERP Data

How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.

Stuck on SYSPRO (on-prem)?

Talk to engineers who work inside SYSPRO (on-prem) every week, and who build private AI that answers these questions from your own ERP data.

Talk to an ERP engineerBrowse ERP Help
All ERP Help articles

Keep exploring

Free tools

ERP fixes and how-tos

AI on your ERP

Integrations

Software