# Epicor Eclipse AI Integration: A Private, On-Prem Architecture > Source: https://netray.co/erp-help/private-ai-layer-epicor-eclipse-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Eclipse is a distribution ERP whose integration surface is more constrained than SQL-based systems, so the safest design reads from scheduled extracts, vendor-supported interfaces and exported reports into a local reporting store, then indexes and serves an open-weight model on your own hardware. Confirm with Epicor which interfaces your Eclipse release and hosting arrangement allow. ## Kind advanced ## System epicor ## Erp Epicor Eclipse (distribution) ## Module Integration / Data export / Report access ## Query Epicor Eclipse AI integration on-prem ## Alternate Queries - how to add AI to Epicor Eclipse - Eclipse ERP chat with data - private LLM for Epicor Eclipse distribution - Eclipse ERP data export for AI ## Applies To Epicor Eclipse in customer-hosted or vendor-hosted deployments; available interfaces vary by release, licence and hosting, so verify before design ## Steps ### How to add a private AI layer to Epicor Eclipse **Items:** - Establish who hosts Eclipse and what access you are entitled to. Customer-hosted sites may have database or file-level access; vendor-hosted sites usually depend on exports and supported interfaces. - Ask Epicor which supported integration options your release provides (APIs, EDI and eCommerce interfaces, scheduled report output) and get the documentation for each in writing. - List the questions you want to answer: stock by branch, open orders, purchase orders and receipts, customer sales history, rebates, vendor performance. - Define scheduled extracts or report outputs for each domain into a landing area inside your network, in a stable format (CSV or fixed-width) with a versioned layout. - Load the extracts into a local reporting database with typed tables and keys you control, and keep load timestamps so every answer can state its freshness. - Index documents (price lists, product data sheets, contracts, branch procedures) locally with branch and sensitivity tags. - Serve an open-weight model with vLLM or Ollama on local GPUs, expose parameterised read actions through a tool server and log every call. - Stay read-only. Any write-back, such as a draft order, should go through an Epicor-supported interface after human approval. ## Sections ### Data access options and what to verify **Body:** Eclipse is built on a Progress-based architecture, and what you can reach depends on deployment. Where the customer has database access, standard OpenEdge SQL tools may be able to read tables, but table and field names are specific to the release and are best taken from your own data dictionary rather than a public list. Where Epicor hosts the system, expect to work through scheduled exports, reports to file and the integration interfaces Epicor documents for your release. Treat the first week as discovery. Ask for the data dictionary, the licensed interface list, the export formats and the permitted extract frequency. Do not guess table names, and do not rely on screen scraping, which breaks with every UI change and sits outside what Epicor supports. The aim is a stable, typed copy of the facts you need, with provenance. Everything the assistant later says should trace back to a dated extract. **Code:** # Example ingest job definition (generic; adapt to the extract layout Epicor provides) source: type: file_drop path: /data/landing/eclipse/open_orders/ format: csv layout_version: 3 schedule: "every 30 minutes, 06:00-20:00" target: database: reporting table: open_orders keys: [branch, order_number, line_number] freshness_field: extract_ts acl_tags: [branch] ### Reference architecture and air-gapped option **Body:** Components: a landing zone for extracts, a loader that validates layout and counts rows, a local reporting database, a retrieval index over documents and exported report text, a tool server with approved read actions, a model server running vLLM or Ollama on local GPUs, and an audit gateway. Every part lives on your network. Because the source is extract-based, freshness is a first-class concern. Show it in each answer ('as of 10:30 extract') and have the tool server refuse to answer stock-critical questions if the latest extract is older than a threshold you set. For an air-gapped branch network, copy models and containers in once, pin versions and run embeddings locally. The extract path can be one-way, from Eclipse to the reporting store, which also supports a strict data-flow policy. ### Permissions, branches and write-back **Body:** Eclipse users typically work within branches and roles that control what they can see and do. Since an extract has no per-user context, the reporting store must carry branch and sensitivity columns, and the tool server must filter every query by the asking user's branches. Maintain a mapping from user directory groups to branches and roles, and default unknown users to no access. Handle cost, margin and rebate data as a restricted class. Keep it in separate tables or columns that only authorised roles can reach, and test that the assistant refuses the question for others. Write-back should use only interfaces Epicor supports for your release. A sensible first target is a draft that a person completes in Eclipse, not an automated posting. If you have no supported write path, keep the assistant read-only and avoid workarounds. ### Sizing, rollout and honest limits **Body:** For 30 to 200 named users, one 24 GB GPU with a 7B to 14B parameter model usually suffices for a pilot, plus a modest reporting database. Peak concurrent requests, often around branch opening and order cut-off, determine whether you need a second GPU. Phase one is read-only questions on extracts and documents; phase two adds summaries and draft emails or quotes; phase three considers approved actions only if a supported write interface exists. Review the audit log before each step. Limits to state plainly: extract-based data is not real time; complex pricing, rebates and matrix logic live in Eclipse and cannot be recomputed from flat extracts; and a hosted deployment may limit what you can pull. If Epicor's own reporting or eCommerce tools answer your questions, use them first. ## Pitfalls - Guessing table or field names instead of using the data dictionary for your release. - Presenting extract data as live stock without showing its timestamp. - Recomputing price, rebate or matrix logic from flat extracts. - Screen scraping the Eclipse UI, which is unsupported and brittle. - Loading extracts without branch columns, which makes per-user filtering impossible. ## Ai Angle ERPray can sit on a local reporting store fed from Eclipse extracts and supported interfaces, answer branch, inventory and customer questions with the freshness stated, and run on your own GPUs. The extract design is the real work, and it is worth doing carefully because every later answer depends on it. ## Faq ### Can I use AI with Epicor Eclipse? **Answer:** Yes, with care. Depending on hosting and licence, you read through supported interfaces, scheduled extracts or database access, load a local reporting store, and run an open-weight model on your own GPUs. Confirm entitlements with Epicor first. ### Is the data real time? **Answer:** Usually not. Extract-based designs have a refresh interval, so each answer should state its as-of time. For stock-critical decisions, link the user back to the Eclipse screen to confirm before acting. ### How are branch permissions enforced? **Answer:** The reporting store carries branch and sensitivity columns, and the tool server filters every query and retrieval by the asking user's branches using a mapping from directory groups. Cost and rebate data sit in a restricted class. ### Should we pick Prophet 21 or Eclipse for AI readiness? **Answer:** Do not choose an ERP for AI alone. Prophet 21 on SQL Server is easier to read today, but Eclipse can still support a useful assistant through extracts. Weigh the whole business case, then see the comparison page for the distribution decision. ## Search terms Epicor Eclipse AI integration, Eclipse ERP chat with data, Epicor Eclipse data export, Epicor Eclipse reporting, private LLM Eclipse ERP, distribution ERP AI on-prem, Epicor Eclipse API, Eclipse ERP AI assistant --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json