# Private AI for SAP Business One: Service Layer, a read replica and a local model

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

## Short answer

Business One is small enough that a private AI layer can be simple: read through the Service Layer for live lookups, use a read replica of the SQL Server or HANA company database for analytics, index attachments and SOPs, and run an open-weight model on one or two local GPUs. Writes go through the Service Layer with a human approving first, never straight into the database.

## Kind

advanced

## System

sap

## Erp

SAP Business One

## Module

Service Layer / Private AI

## Query

how to add AI to SAP Business One on-premise

## Alternate Queries

- SAP Business One Service Layer AI assistant
- SAP Business One local LLM SQL Server
- SAP Business One chatbot without cloud
- SAP B1 HANA private AI

## Applies To

SAP Business One 9.3 and 10.0 on SQL Server or SAP HANA, on-premise or in your own hosting. Service Layer availability depends on version and database, so check the release notes for your patch level.

## Steps

### Build the layer on SAP Business One

**Items:**

Confirm your version, database and whether Service Layer is installed and reachable (the /b1s/v1 endpoint). Note the session timeout and per-company configuration; the Service Layer login takes CompanyDB, UserName and Password.

Create a read-only reporting path: a SQL Server readable secondary, log-shipped copy or HANA system replication target for analytical queries, so heavy questions never hit the live company database.

Create dedicated B1 users for the AI layer with the minimum general authorizations, and decide whether queries run as that user plus an application-level filter, or as the asker through their own Service Layer session.

List the objects you want to expose: sales orders (ORDR/RDR1), purchase orders (OPOR/POR1), items and stock (OITM, OITW), business partners (OCRD), production orders (OWOR/WOR1), journal entries (OJDT/JDT1).

Index attachments and external documents: B1 stores attachment records (table ATC1/OATC) pointing to files in the attachments folder, plus SOPs, drawings and certificates on file shares.

Wrap approved queries as named tools in an MCP or internal tool server, and serve the model with Ollama or vLLM on a local GPU.

Add an approval queue for drafted documents, then post through the Service Layer. Log all calls and review the first weeks of questions with the users.

## Sections

### How Business One exposes its data

**Body:**

Business One has three integration surfaces. The Service Layer is a REST and OData service (path /b1s/v1, with a v2 on recent builds) that sits on the same business logic as the client, so business rules and validations run on writes. The DI API is the older COM interface used by add-ons and still behind many integrations. And the database itself, which is readable with SQL but not a supported write path.

The schema uses compact table names. Sales documents are ORDR (header) with RDR1 (rows); purchase orders OPOR with POR1; deliveries ODLN with DLN1; invoices OINV with INV1; items OITM, with warehouse stock in OITW; business partners OCRD; production orders OWOR with WOR1; journal entries OJDT with JDT1. Line status is 'O' for open and 'C' for closed. Always read the document structure for your version in the SDK help rather than trusting memory for less common columns.

For AI, use the Service Layer for single-document lookups and small lists, and the replica with SQL for aggregates. Service Layer queries support $filter, $select, $top and paging; use server-side paging so large lists do not time out.

**Code:**

-- Open sales order lines (SQL Server or HANA, run on the replica)
SELECT T0.DocNum, T0.CardCode, T0.CardName, T1.ItemCode, T1.OpenQty, T1.ShipDate
FROM   ORDR T0
JOIN   RDR1 T1 ON T1.DocEntry = T0.DocEntry
WHERE  T0.DocStatus = 'O' AND T1.LineStatus = 'O'
ORDER  BY T1.ShipDate;

# Service Layer lookup (after POST /b1s/v1/Login with CompanyDB, UserName, Password)
GET /b1s/v1/Orders?$select=DocEntry,DocNum,CardCode,DocTotal,DocumentStatus
    &$filter=DocumentStatus eq 'bost_Open'&$top=50
Prefer: odata.maxpagesize=50

### Reference architecture for a small server room

**Body:**

Most Business One sites have a handful of servers, so keep the design light. One application host runs the tool server, retrieval index and audit log. One GPU host (a single workstation-class or data-centre card for a small user base) serves the model. A readable copy of the company database serves analytics, refreshed by log shipping, replication or a nightly restore depending on how fresh answers must be.

A request flows from the chat UI to an orchestrator that selects a tool, for example stock_by_warehouse or open_orders_by_customer. The tool runs a parameterised SQL query on the replica or a Service Layer call, returns rows with document numbers, and the model summarises with citations. No data leaves your network, and for an air-gapped shop the model weights are imported on removable media.

Because Business One deployments often serve several company databases, make CompanyDB an explicit tool parameter bound to the user's allowed companies rather than something the model can choose.

**Code:**

B1 company DB (SQL Server / HANA) --replica--> read-only copy --> tool server (parameterised SQL)
B1 Service Layer (/b1s/v1) -------------------> tool server (live lookups)
Attachments folder + file shares -> parser -> retrieval index
Chat UI -> orchestrator -> Ollama/vLLM (local GPU) -> tool server -> cited answer
Audit log: user, company, tool, parameters, document numbers returned

### Permissions, data ownership and write-back

**Body:**

Business One authorizations are set per user in the general authorizations window, and Data Ownership lets you restrict who sees which documents (by owner, department, branch or sales employee) when enabled. Direct SQL on the replica ignores all of this, so you must reproduce it: export each user's authorizations and ownership scope and apply them as mandatory filters in the tool code, or make Service Layer calls under the asker's own session so B1 enforces it.

For many small deployments, the simplest honest model is: broad analytics tools only for roles allowed to see all data, and per-user Service Layer sessions for everyone else. Document which tools are available to which roles and review that list with the business owner.

Writes use the Service Layer so validations, posting rules and approval procedures run. The assistant drafts a document, a person reviews the exact payload, and an approved POST creates it, for example a draft sales order or purchase request. Use documents saved as drafts where the object supports them, so a person can finish them in the client. Never update tables directly; B1's own integrity and the SAP support terms depend on that.

### Sizing, rollout and limits

**Body:**

As ranges: for 10 to 60 named users, a 7B to 14B open-weight model on one 24 to 48 GB GPU is often enough for Q and A over structured data, and a 30B-class model on one 80 GB card handles more complex document reasoning. The document index for a few tens of thousands of attachments is usually single-digit to tens of gigabytes.

Phase one: read-only questions on stock, orders, customers and open items. Phase two: drafted emails, quotation text and supplier follow-ups. Phase three: approved document creation through the Service Layer.

Limits. Business One has user-defined fields and tables (U_ and @ prefixed) that are different in every company, so mapping them is real work. Version differences matter: confirm which Service Layer features your patch level has. If your needs are mostly standard reports, B1's own query manager, Crystal reports and dashboards may already be enough, and an AI layer adds value mainly for questions that cross documents, notes and attachments.

## Pitfalls

- Running analytical SQL on the live company database during business hours and slowing every user.
- Ignoring Data Ownership and authorization settings when reading through SQL, so the assistant shows documents a user cannot open in B1.
- Letting the model pick the CompanyDB freely in a multi-company install.
- Writing to tables directly instead of the Service Layer, which skips validations and risks support issues.
- Overlooking user-defined fields (U_ columns) so answers miss data the business treats as essential.
- Hitting Service Layer session timeouts without a re-login and retry path.

## Ai Angle

ERPray can connect to Business One over the Service Layer and a replica, show the SQL or request behind each answer, and run entirely on a local server. For small teams the usual start is stock, open orders and customer history with a handful of SOPs indexed, then drafted documents with approval.

## Faq

### Is the Service Layer or SQL better for an AI assistant?

**Answer:** Use both for different jobs. The Service Layer suits single-document lookups and writes because business rules run. SQL on a read replica suits aggregates and cross-table analytics. Keep SQL read-only, parameterised and on the replica, and never write through it.

### Can we run this on a single server?

**Answer:** For a small pilot, yes: a modest GPU host plus an application host, or both roles on one machine, is workable. For production, separate the model host from the ERP database so inference load never competes with posting and reporting.

### How do we handle Business One user permissions?

**Answer:** Either call the Service Layer under the asker's own session so B1 enforces authorizations and data ownership, or export those rules and apply them as mandatory filters in your SQL tools. Test with restricted users and log every query.

### Does this work with SAP Business One on HANA?

**Answer:** Yes. The object names are the same, and you can read from a system replication target or a copy of the company schema. Service Layer is available on HANA, and the model and retrieval parts are independent of the database.

## Search terms

SAP Business One AI, SAP Business One Service Layer AI, SAP Business One local LLM, SAP B1 chatbot on-premise, SAP Business One SQL Server AI, SAP Business One HANA AI, SAP B1 private AI, SAP Business One data ownership AI

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