# How to Add a Private AI Layer to Global Shop Solutions On-Prem

> Source: https://netray.co/erp-help/private-ai-layer-global-shop-solutions-on-prem-architecture
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

Global Shop Solutions keeps jobs, routings, inventory, purchasing and quality data in one database that can be read through ODBC or the vendor's report and export tools. A private AI layer works from a read-only copy, builds a documented semantic layer over the tables you actually use, serves an open-weight model locally, and writes back only through vendor-supported import or API routes with approval.

## Kind

advanced

## System

job-shop-erp

## Erp

Global Shop Solutions ERP

## Module

AI integration / ODBC and vendor interfaces

## Query

how to add AI to Global Shop Solutions on-prem

## Alternate Queries

- Global Shop Solutions AI integration without cloud
- Global Shop ERP private LLM
- AI assistant for Global Shop Solutions shop floor data

## Applies To

Global Shop Solutions ERP on-premises installations; confirm the database engine and release with your administrator, because it varies by version

## Steps

### Steps to add a private AI layer to Global Shop Solutions

**Items:**

- Confirm your release and database engine with your Global Shop administrator or the vendor; do not assume, because engine and schema differ across versions.
- Obtain the vendor data dictionary and agree which modules matter first: typically jobs and routings, scheduling, inventory, purchasing, quality and shipping.
- Create a read-only ODBC data source and database account, and test it against a restored backup before touching production.
- Establish a reporting copy refreshed nightly or by log shipping, so analytical questions never compete with shop-floor transactions.
- Define a semantic layer: named views for open jobs, operations by work center, material shortages, supplier delivery performance and quality nonconformances, with every column described in plain language.
- Index job travelers, drawings, certificates and inspection records into a local vector store, tagged with customer, job and document class.
- Serve an open-weight model with vLLM or Ollama on local GPUs behind a tool server that exposes only approved read actions and logs every call.
- Roll out in phases and enable any write-back only through vendor-supported import or API routes after a named user approves the exact change.

## Sections

### How Global Shop data can be reached

**Body:**

Global Shop Solutions is a single-database ERP for job shops and make-to-order manufacturers, with modules for estimating, order entry, shop floor control, scheduling, inventory, purchasing, quality and accounting. Data is accessible through ODBC to the underlying database, through the vendor's report writer and export features, and through whatever integration interfaces your release documents.

Because the engine and the table layout vary by release, the safe approach is to work from the vendor's data dictionary rather than assumed table names. Treat this as a discovery step: list the tables behind jobs, operations, inventory and purchasing, record the key columns and status codes, and have the vendor or a consultant confirm them.

Direct SQL writes are off the table. Shop floor, costing and scheduling logic live in the application, and bypassing it can corrupt job costs or the schedule.

**Code:**

# Approved read action exposed by the tool server (MCP style)
{
  "name": "open_jobs_by_customer",
  "description": "List open jobs for a customer with due dates and status",
  "inputSchema": {
    "type": "object",
    "properties": { "customer": { "type": "string" }, "limit": { "type": "integer", "maximum": 100 } },
    "required": ["customer"]
  }
}

# ODBC data source for the reporting copy (names are yours)
DSN=GSS_REPORTING;UID=ai_reader;PWD=<from vault>

### Reference architecture

**Body:**

Run the assistant against a reporting copy, not production. A nightly restore or log-shipped copy is enough for most planning and status questions. If people need same-hour answers on shop floor status, shorten the refresh interval and measure the load it adds.

The semantic layer is where accuracy is won. Each view carries column descriptions, units and status code meanings so the model can write correct filters. The tool server exposes a short list of parameterised reads, and an optional guarded SQL route for analysts, restricted to the views and a row limit. An audit log records the user, question, tool calls and rows returned.

In an air-gapped plant the whole stack, including the embedding model and vector store, sits inside the network boundary. This suits shops handling controlled technical data, where the architecture lets the customer keep that data inside its own boundary.

### Permissions and data scope

**Body:**

Global Shop has its own user and group security that controls which screens and functions people can use. The database account used by the assistant sees far more than any one user, so the assistant must apply scope itself. Resolve each person's Global Shop user, map them to a short list of roles such as estimator, planner, buyer, quality and finance, and define which views and columns each role may use.

Cost, margin and pricing columns deserve explicit rules: expose them only to finance and management roles, and exclude them from the document index for everyone else. For customers with contractual data restrictions, tag documents by customer and filter retrieval on that tag.

Test with a shop-floor supervisor account and confirm that costs, rates and customer pricing never appear in answers or citations.

### Write-back, sizing and phased rollout

**Body:**

Write-back should use whichever import, API or transaction route the vendor documents for your release. The assistant drafts the change, displays it, and a named user approves. If your release offers no supported route for a given action, keep that action manual and let the assistant prepare the data entry.

A job shop with 50 to 150 named users and moderate daily use generally fits on a single 24 to 48 GB GPU with a 7B to 14B class model; larger quoting or document-heavy workloads may justify a second GPU. Index size depends on traveler and drawing volume and is usually modest.

Start with read-only status and shortage questions, add document Q and A on travelers and certificates, then draft purchase and expedite messages. Enable write-back last.

### Honest limits

**Body:**

The biggest uncertainty is schema discovery. Without a reliable data dictionary the first weeks go into documenting tables, and the assistant will be only as good as that documentation. Live scheduling data may also be computed in the application, so a database read can show a stored date rather than what the scheduler would produce now.

If the questions are simple lookups, Global Shop's own reports and search tools may be enough. The case for a private AI layer is cross-module questions, document retrieval and drafts that those tools do not offer.

## Pitfalls

- Assuming table names without the vendor data dictionary for your release.
- Running analytical queries against production during a shift.
- Treating stored schedule dates as the live scheduler output.
- Letting cost and pricing columns into the shared document index.
- Enabling write-back before a supported route has been confirmed for each action.

## Ai Angle

ERPray can connect to Global Shop data through a read-only ODBC path, show the query it ran and respect role scope. Netray's custom build service covers the discovery, semantic layer and tool server, with the model and index running on your own hardware.

## Faq

### Which database does Global Shop Solutions use?

**Answer:** It depends on the release. Historically it used a Pervasive-family engine, and newer releases may offer SQL Server. Confirm with your administrator or the vendor before designing the data path.

### Can the assistant change jobs or purchase orders?

**Answer:** Only through routes the vendor supports, and only after a named user approves the drafted change. Direct SQL writes are not acceptable because they skip application logic and costing.

### Will it understand our shop's status codes?

**Answer:** Only if they are documented in the semantic layer. Plan to describe each status code, work center and custom field in plain language during the first phase.

### Can this run without internet access?

**Answer:** Yes. The model, embeddings, vector store and tool server can all run inside the plant network, with updates delivered on approved media.

## Search terms

Global Shop Solutions AI, Global Shop ERP on-prem AI, Global Shop ODBC, private LLM job shop ERP, AI assistant Global Shop, air-gapped job shop AI, Global Shop data dictionary, AI scheduling questions Global Shop

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