# How to Add a Private AI Layer to E2 Shop System On-Prem > Source: https://netray.co/erp-help/private-ai-layer-e2-shop-system-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer E2 Shop System holds quotes, orders, jobs, routings, inventory and purchasing in a database you host yourself. A private AI layer reads a copy through a restricted account, exposes it through documented views, indexes quotes and job documents locally, runs an open-weight model on your own GPU, and leaves changes to E2's own screens or supported interfaces with a person approving. ## Kind advanced ## System job-shop-erp ## Erp E2 Shop System (Shoptech, on-prem) ## Module AI integration / database views and documents ## Query how to add AI to E2 Shop System on-prem ## Alternate Queries - E2 Shop System AI integration without cloud - Shoptech E2 database AI assistant - private LLM for E2 shop software ## Applies To On-premises E2 Shop System; confirm the version and database engine with your administrator, because the engine differs between older and current releases ## Steps ### Steps to add a private AI layer to E2 Shop System (on-prem) **Items:** - Confirm the E2 version and database engine and who administers the server; get the vendor's data dictionary or export documentation for your release. - Arrange a nightly restore or replicated copy of the E2 database on a separate instance for the assistant to read. - Create a restricted read-only account on that copy and deny access to payroll, user credential and similar sensitive tables. - Create an ai schema of views for quotes, orders, jobs, operations, inventory, purchasing and shipping, with plain-language column descriptions. - Index quote PDFs, customer POs, drawings and job packets into a local vector store tagged by customer and document type. - Serve an open-weight model on a local GPU and put a tool server between it and the views, with an audit log of every call. - Map E2 users to roles and apply role scope in the tool server; hide cost and margin from roles that should not see them. - Release in phases: read-only questions, then quote-assist drafts, then approved actions through E2's own screens or a supported import. ## Sections ### How E2 data can be reached **Body:** E2 Shop System is a job shop ERP covering quoting, order entry, job costing, scheduling, inventory, purchasing, shipping and accounting. On premises, its data lives in a database that your IT team hosts, and the engine depends on the release. Current E2 releases use Microsoft SQL Server; older releases used a different embedded engine, so verify before planning. The reliable pattern is to read a copy and expose views rather than raw tables. Views let you rename obscure column names, expand status and type codes into words, and exclude sensitive columns. They also make it possible to change the underlying schema after an E2 upgrade by editing the views rather than retraining anything. E2 enforces costing, scheduling and status logic in the application. Do not write to its tables with SQL; use E2's screens or a vendor-supported import. **Code:** -- Pattern for a read-only schema of views on the replica (placeholders are yours) CREATE SCHEMA ai; GO CREATE VIEW ai.OpenJobs AS SELECT AS JobNumber, AS Customer, AS DueDate, AS Status FROM dbo. WHERE NOT IN (); GO GRANT SELECT ON SCHEMA::ai TO ai_reader; ### Reference architecture **Body:** Keep the architecture small. A copy of the E2 database, a vector store, a GPU server and a tool server are enough. The tool server exposes parameterised reads such as open quotes for a customer, jobs due this week, material on order by part and last price paid, and returns rows with source references the model can cite. Quote assistance is a natural use. The assistant can retrieve similar past quotes and the actuals from completed jobs, then summarise them for the estimator. The estimator still sets the price, and nothing is written back automatically. In a controlled-data shop, run the full stack in an isolated network segment with no outbound access. Model files and updates are brought in on approved media, and the audit log stays on site. ### Permissions and data scope **Body:** E2 users have security rights inside the application, but the assistant reads through one database account. The tool server therefore carries the scope: identify the user, map them to a role such as estimator, planner, buyer, supervisor or finance, and allow only the views that role needs. Pricing, quoted margins and actual job costs belong to restricted roles. Apply the same rule to the document index: quotes and cost summaries are tagged and filtered at retrieval, so a supervisor never receives a chunk from a margin spreadsheet. Run a role test before go-live. The same question asked as supervisor and as owner should give different answers where cost is involved. ### Write-back, sizing and phased rollout **Body:** Start read-only. Later, the assistant can draft a quote line, a purchase request or a customer delay notice, and the user commits it in E2. If you want true write-back, use only routes the vendor supports for your release and keep a human approval step with the exact payload shown. For 20 to 100 named users a single 24 GB class GPU with a 7B to 14B model is a common fit, and a quote-heavy shop that wants long context over many PDFs may prefer 48 GB. Index size is driven by the number of quotes and drawings and typically stays small. Phase one: status, due date and inventory questions. Phase two: quote retrieval and drafts. Phase three: a short list of approved writes. ### Honest limits **Body:** Schema documentation for smaller ERPs can be thin, and customised fields are common, so the first weeks go into mapping. Embedded or older database engines may not support the replication options discussed here, in which case a nightly export to a modern engine is the fallback. If your need is a few dashboards, E2's own reports and a standard BI tool may be enough. The assistant pays off for ad hoc questions, quote history retrieval and document search that fixed reports cannot do. ## Pitfalls - Exposing raw tables instead of views, which leaks sensitive columns and breaks on upgrades. - Letting the model see quote margins when the user's role should not. - Assuming the database engine without confirming the E2 release. - Pointing at production instead of a copy. - Writing to E2 tables with SQL and skipping application logic. ## Ai Angle ERPray's pattern of read-only access, visible queries and role scope applies to E2. Netray's custom build service can produce the views, tool server and quote retrieval index with the model hosted on your own hardware. ## Faq ### Which database does E2 Shop System use? **Answer:** Current releases use Microsoft SQL Server; older releases used a different embedded engine. Confirm your release with your administrator or the vendor before choosing a replication method. ### Why use views instead of reading tables directly? **Answer:** Views let you rename columns, expand codes, hide sensitive fields and absorb schema changes after an upgrade. They also give the model a cleaner, documented surface to work with. ### Can the assistant create quotes in E2? **Answer:** It can draft quote content from past quotes and actuals. The estimator enters or imports the quote through E2 and approves the price. Automatic write-back is not recommended in the first release. ### How much GPU is needed? **Answer:** A single 24 GB class GPU with a 7B to 14B model often serves 20 to 100 named users. Use the sizing calculator with your own usage to refine the estimate. ## Search terms E2 Shop System AI, Shoptech E2 AI assistant, E2 shop software on-prem AI, private LLM E2 ERP, E2 quote history AI, job shop AI quoting, air-gapped job shop AI, E2 database views AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json