# How to add an AI chatbot to abas ERP > Source: https://netray.co/integrations/abas-ai-chatbot > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Integrations ## Short answer Add an AI chatbot to abas ERP by connecting a language model to a retrieval and tool layer over abas data, then embedding the chat in an intranet page, a customer portal or the tool your staff already use. It can run fully on-prem with open models, answering only from records the user is allowed to see. ## System abas ERP ## Capability ai-chatbot ## Intro A chatbot for abas serves two quite different audiences. Internal staff want faster answers than navigating infosystems, and external parties such as customers and suppliers want status without calling someone. The technology is similar, the risk is not. For internal staff, the main value is reducing interruptions to the few people who know where everything is in abas. For external users, the main value is order status and document retrieval at any hour, provided identity and scoping are airtight. Either way the chatbot must be grounded: answers come from returned records and indexed documents, with references shown, not from the model's memory. ## Use Cases ### Internal order desk assistant **Description:** Customer service asks about order lines, shipping dates and invoices, and the bot answers with links to the abas record. ### Customer portal order status **Description:** Authenticated customers ask where their delivery is and receive status for their own orders only. ### Supplier self-service **Description:** Suppliers confirm or ask about purchase order dates through a chat on a portal, with changes sent as proposals for the buyer. ### Work instruction and policy Q and A **Description:** Staff ask procedural questions answered from indexed manuals and quality documents, with source citations. ### New user help for abas itself **Description:** A bot indexed on your internal abas how-to notes guides new staff through common tasks and screens. ## System Surface - EDP or REST read access through a gateway, supplying live record data to the bot. - abas user and role mapping: internal bots should act with the asking user's rights where possible, not a super user. - Document attachments and file shares: manuals, drawings and certificates can be indexed for retrieval, with access rules copied from the source. - abas eBusiness or portal components, where licensed, can host or link the chat for external users. Confirm your edition. - Single sign-on: the chat front end usually authenticates through your identity provider, then the gateway maps the user to an abas identity. ## How It Works ### Scope the audience **Detail:** Decide internal, customer or supplier first. External audiences need stronger identity checks and narrower tools. ### Build the retrieval and tool layer **Detail:** Index documents into a vector store and expose live data through read-only tools, so the bot can answer from fresh abas records. ### Add permission checks **Detail:** Resolve the user to allowed customers, suppliers or departments, and apply the filter inside the tool, not in the prompt. ### Choose the model **Detail:** Select an open-weight chat model that handles your languages. Serve it with vLLM or Ollama on local GPUs if data must stay on-prem. ### Embed the interface **Detail:** Provide a web widget for the intranet or portal, or integrate with Teams or email if staff prefer them. ### Evaluate and tune **Detail:** Build a test set of real questions with expected answers, track unanswered ones, and add content or tools where it fails. ## Example Flows ### Customer asks about a delivery **Trigger:** Authenticated customer opens the portal chat **Steps:** - Bot resolves the customer account from the login - It calls the order tool filtered to that customer - It reads shipping status and expected date - It replies with the status and a link to the delivery note **Result:** The customer gets an answer outside office hours and the sales team avoids a call. ### Staff policy question **Trigger:** Employee asks about incoming inspection rules **Steps:** - Bot searches indexed quality procedures - It retrieves the relevant sections with revision numbers - It answers with citations to the documents **Result:** Staff receive the current procedure rather than an outdated memory of it. ## On Prem The entire chatbot can live inside your network: abas, the gateway, the vector store, the open-weight model and the chat front end. For external portals, place only a hardened web tier in a DMZ and keep the model and abas access internal. Use a smaller, quantised model for lower hardware cost if question types are simple, and measure latency under realistic concurrency. Keep chat logs on-prem and define retention, since they can contain business data and personal data. ## Security - Enforce user and customer scoping inside the tools, never only in the prompt - Strong authentication for external users with SSO or portal login - Show source references so users can verify answers - Block write actions in the chatbot, or route them as approval proposals - Define retention and access rules for chat logs under GDPR ## Options ### Extend an existing portal or abas web component **Fit:** You already run a portal and want a simple status assistant. **Effort:** Moderate, depends on portal extensibility. ### Build on an open-source chat framework **Fit:** You have developers and want control over data and models. **Effort:** Weeks for a useful internal pilot. ### Netray private chatbot **Fit:** You need on-prem models, role-aware retrieval and evaluation handled together. **Effort:** A scoped pilot on one audience first. ## Pitfalls - Letting the prompt decide which customer's data to show invites leaks. Enforce scoping in code. - Stale document indexes lead to confident answers from superseded procedures. Re-index on change. - Overpromising: a bot that answers everything badly is worse than one that answers a few things reliably and says when it does not know. - Multilingual users need testing in each language, including technical terms and abbreviations. - No fallback to a human leaves frustrated users with no path forward. ## Faq ### Can the chatbot show live abas data? **Answer:** Yes, through read-only tools backed by EDP, the object layer or REST. The model calls a tool with structured parameters, receives current records and phrases the answer. Show references so users can open the source record. ### Is it safe to let customers use it? **Answer:** It can be, with strong authentication, per-customer filtering inside the tools, narrow tool sets and logging. Start internal, prove accuracy, then open a limited external pilot. Never rely on prompt instructions alone for access control. ### Can we run it without any cloud? **Answer:** Yes. Host an open-weight model on your own GPUs, keep the vector store and gateway local, and serve the chat from your own web tier. Hardware sizing depends on user count, model size and response time targets. ### Which languages does it support? **Answer:** That depends on the model. Many open-weight models handle German and English well, others less so. Test with your own terminology, and consider a glossary to map local abbreviations and field names. ### How is this different from abas infosystems? **Answer:** Infosystems give fixed reports that users must know to open. A chatbot lets users ask in plain language and combines several sources. Infosystems remain the trusted logic underneath, and the bot can call them as tools. ## Search terms abas erp chatbot, ai chatbot for abas erp, abas erp virtual assistant, chat with abas erp data, abas customer portal chatbot, on-prem chatbot abas erp, abas erp natural language, abas erp ai assistant --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json