AdvancedExact Macola 10 (ECI Macola)SQL Server data access / AI architecture

How to Add AI to Macola ERP On-Prem Without Sending Data to a Cloud

Question
how to add AI to Macola ERP on-prem

Also searched as

  • Macola AI integration without cloud
  • Macola 10 ChatGPT alternative on-premise
  • Exact Macola SQL Server read-only AI assistant
  • private LLM for Macola ERP

Short answer

Macola 10 runs on SQL Server, so the safest pattern is a read-only reporting copy of the Macola company database, a small set of approved views, a retrieval index over attached documents, and an open-weight model served on a local GPU. Writes stay out of the first phases and, when added, go through Macola's supported import or SDK routes with a person approving each one.

Applies to: Exact Macola 10.x on Microsoft SQL Server. Older Progress-based Macola ES releases need a different data path and are covered under limits below.

Reference build for a private AI layer on Macola

  1. 1Confirm the Macola release and that the company databases are on SQL Server. List every company database the assistant must cover, because Macola keeps each company in its own database.
  2. 2Create a reporting copy: an Always On readable secondary, log shipping with a restored standby, or a nightly restore. Pick based on how fresh answers must be. Never point the model at the production database.
  3. 3On the copy, create a dedicated schema (for example ai) and expose only views over the tables you approve, such as the item master, item location, customer order header and lines, purchase order header and lines, customer and vendor masters.
  4. 4Create a SQL login with SELECT on that schema only. No access to payroll, bank or credential tables, and no EXECUTE rights.
  5. 5Build a retrieval index over documents tied to Macola records: drawings, PO PDFs, certs, quotes and SOPs on the file share. Store the Macola key (item number, order number) as metadata on every chunk.
  6. 6Stand up a tool server (MCP or a plain REST wrapper) that offers a handful of parameterised read actions, for example order status, item availability, open POs by vendor. The model calls tools; it does not write free SQL against base tables.
  7. 7Serve an open-weight model with vLLM or Ollama on a local GPU server. Put the tool server, retrieval index and model on the same network segment with no outbound route.
  8. 8Log every question, the tool calls made, the SQL or view used, the rows returned and the user. Review the log weekly in phase 1.

Where Macola keeps its data and how to read it safely

Macola 10 stores business data in SQL Server tables whose names carry a module prefix and an _sql suffix, for example imitmidx_sql for the item master, oeordhdr_sql and oeordlin_sql for customer orders, poordhdr_sql and poordlin_sql for purchase orders, arcusfil_sql for customers and apvenfil_sql for vendors. Your exact column set depends on release and customisations, so verify names against your own database before writing views.

Do not let a language model generate free SQL against these tables. Wrap them in views with friendly column names and fixed filters (open orders only, current year, active items), then expose the views through tool functions with typed parameters. This keeps answers explainable and stops a hallucinated join from scanning a hundred million rows.

Macola also has its own integration and import options that differ by version. Treat them as the write path, and confirm with your reseller or the vendor documentation which ones your licence and release support.

-- Illustrative only. Verify table and column names in your Macola database.
CREATE SCHEMA ai;
GO
CREATE VIEW ai.open_order_lines AS
SELECT h.ord_no, h.cus_no, l.item_no, l.qty_ordered, l.request_dt
FROM dbo.oeordhdr_sql h
JOIN dbo.oeordlin_sql l ON l.ord_no = h.ord_no
WHERE h.status NOT IN ('C','X');
GO
CREATE USER ai_reader FOR LOGIN ai_reader;
GRANT SELECT ON SCHEMA::ai TO ai_reader;

Reference architecture and the air-gapped option

The layers are: the SQL Server reporting copy, the ai views, a change feed or scheduled refresh, a vector index for documents, a tool server, the model server and an audit store. Everything sits inside your network. For a fully air-gapped site the model weights, embedding model and Python packages are carried in on approved media and updated on a schedule you control.

Freshness depends on the copy method. A readable secondary is near real time, log shipping is minutes, a nightly restore is a day old. Most shop-floor and purchasing questions tolerate a few minutes; say clearly in the answer when the data was last refreshed.

Hardware is modest for a Macola-sized user base. One 24 to 48 GB class GPU serves a quantised mid-size model for a few dozen active users, and a second card gives a standby. Retrieval and the tool server run comfortably on a normal virtual machine.

Permissions: making the assistant respect Macola security

Macola security is enforced in the application, not in SQL Server, so a database login sees more than any single Macola user does. Mirror the rules in the tool layer: map each person's Macola user and company access to the assistant session and filter every tool call accordingly. For finance, cost and margin fields, default to deny and open them to named groups.

SQL Server row-level security on the reporting copy is a useful second fence, for instance restricting rows by company or site code. Document retrieval needs the same treatment: each chunk carries an access label inherited from its folder or record, and the retriever filters on the caller's groups before the model sees any text.

Write-back, when you reach it, goes through supported Macola import or API routes only, never by updating tables directly, and every proposed change appears as a draft the user approves.

Sizing, rollout and honest limits

Plan for roughly 10 to 25 percent of named users active on a given day and a handful of questions each. That load fits one GPU for most Macola sites; the harder sizing question is the document index, which grows with the number of PDFs, not users.

Roll out in three phases: read-only questions over approved views (weeks 1 to 6), drafts such as an email to a vendor or a PO change suggestion the user copies (weeks 6 to 12), then approved actions through supported import routes with a named approver.

Limits: custom tables and heavily modified screens need their own views; Progress-based Macola ES releases lack the SQL path described here; and if you only need standard reports, Macola's own reporting tools may be enough. A language model adds value where people ask free-form questions across orders, stock and documents.

Try it here, free

Macola AI Assistant Sizing and Value Calculator

Open full tool

Estimate GPU count, token volume, index size, hours saved and payback for a private on-prem AI assistant on Macola.

Common pitfalls

  • !Pointing the assistant at the production database and letting it run free SQL, which risks slow queries during order entry.
  • !Forgetting that Macola holds each company in a separate database, so answers silently cover only one entity.
  • !Relying on SQL logins alone and exposing cost or margin columns to people who cannot see them in Macola.
  • !Indexing documents without the Macola key, so retrieval cannot be filtered by customer or order.
  • !Letting the model write back through direct table updates instead of supported routes.
  • !Skipping an audit log, which makes later security reviews impossible.

How an ERP-grounded AI assistant handles this

ERPray can sit on this reporting copy to answer questions such as which open orders are past their request date for a customer, showing the view and filter it used and respecting the mirrored roles. Netray builds the tool server, retrieval index and local model serving inside your network, and your Macola reseller or consultants remain the experts on your configuration.

Frequently asked questions

Can we run AI on Macola without any cloud service?

Yes. Macola 10 data lives in SQL Server on your servers, so a reporting copy, a retrieval index and an open-weight model on a local GPU can all run inside your network. Even model updates can be carried in manually for an air-gapped site.

Does the AI write to Macola?

Not at first. Phase 1 is read-only. Later phases produce drafts, and any real change goes through a supported Macola route with a person approving it. Direct updates to tables are not recommended.

How big a GPU do we need?

For a few dozen active users, one 24 to 48 GB class GPU running a quantised open-weight model is a typical starting point, with a second card for resilience. Document volume affects storage and indexing time more than GPU count.

Is this possible on older Macola versions?

Releases not on SQL Server need a different extraction path, often scheduled exports into a reporting database. It is possible but slower and less fresh. Check your release first.

Related

Advanced

Made2Manage AI Integration Without Cloud: A Private On-Prem Architecture

Made2Manage stores jobs, sales orders, purchasing and inventory in SQL Server tables that a reporting copy can expose through approved views. Pair that with a retrieval index over job travelers and quality documents and an open-weight model on a local GPU, and users can ask about jobs, shortages and orders without any data leaving the plant.

Advanced

Self-Hosted Odoo AI Assistant: Private Architecture With a Local Model

Self-hosted Odoo already exposes its data through an authenticated external API that enforces access rights and record rules, so a private assistant can call it as the signed-in user. Add a retrieval index over attachments and a local open-weight model, and nothing leaves your servers. Direct PostgreSQL access is for aggregates only, because it bypasses record rules.

Advanced

AI for abas ERP and proALPHA On-Prem: A Private, GDPR-Conscious Architecture

abas ERP and proALPHA are typically run on a company's own servers in the DACH region, so a private AI layer fits: read through each product's documented interfaces or a database reporting copy, index documents locally, and serve a German-capable open-weight model on your own GPU. Data does not need to leave your premises.

How-to

How to Create a Generic Inquiry in Acumatica

Generic Inquiries (GI) are Acumatica's no-code query builder for joining tables, adding filters, and exposing the result as an inquiry screen, dashboard data source, or API endpoint. Open System > Customization > Generic Inquiry, add your base table, define joins and conditions, then run and save. No SQL or customization project is required.

Error fix

Fix Odoo AccessError: You Are Not Allowed to Access Records

Odoo raises AccessError when a user's security groups do not grant a CRUD right on a model through ir.model.access.csv, or when an ir.rule record rule filters the specific record out for that user or company. Fix it by adding the user to the group named in the error, editing the model's access rights, or reviewing the record rule's domain under Settings > Technical > Security.

How-to

How to Void a Check in Sage 100

Sage 100 voids checks through Accounts Payable > Main > Check and Payment Voiding. Select the bank code, choose the check number, and Sage reverses the Cash Disbursements Journal entry and reopens the invoice it paid. A check that already cleared in Bank Reconciliation or falls in a closed period needs an extra step before it can be voided cleanly.

AI for ERP

AI for ECI Macola, from Progression Series to Macola 10

Add private AI to ECI Macola, including legacy Progress OpenEdge Progression Series: query orders and inventory in plain English, triage Visual Integrator jobs.

AI for ERP

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

Stuck on Exact Macola 10 (ECI Macola)?

Talk to engineers who work inside Exact Macola 10 (ECI Macola) every week, and who build private AI that answers these questions from your own ERP data.

Keep exploring

Free tools

ERP fixes and how-tos

Guides

AI on your ERP

Integrations

Software