How to Add a Private AI Layer to QAD Enterprise Edition On-Prem

QAD EE stores everything in Progress OpenEdge databases. The application is written in the Progress 4GL, but the database also has a SQL-92 engine, so any JDBC or ODBC client can query tables without going through application code. Tables are exposed in the pub schema with the familiar QAD names: pt_mstr for items, so_mstr and sod_det for sales orders, po_mstr and pod_det for purchase orders, wo_mstr for work orders, ld_det for inventory by location and lot, tr_hist for inventory transactions, cm_mstr and vd_mstr for customers and suppliers.

Almost every table carries a domain column (pt_domain, ld_domain and so on) because QAD EE is multi-domain. A query without a domain predicate returns rows from every domain the account can see, which is exactly what you must prevent for a per-user assistant. Treat the domain predicate as non-optional in the semantic layer.

For anything that changes data, QAD provides QXtend, its service layer for inbound and outbound business transactions. Writing to the OpenEdge tables directly with SQL bypasses 4GL validation, triggers and audit logic, so it is not an acceptable write-back path.

QAD controls access by menu function, domain and site, and many shops add their own restrictions in custom 4GL. The assistant has to enforce the data part of that model itself, because the SQL account sees everything it was granted. Sign users in through your identity provider, resolve their QAD user ID, and look up the domains and sites they are allowed to work in.

Inject those domains and sites into every query as bound parameters, and store the same values as metadata on every document chunk so retrieval filters on them before the model sees any text. Field-level restrictions, such as hiding cost or margin from some roles, need explicit rules in the semantic layer because they live in application logic, not in the database.

Test with deliberately restricted users. A question like 'what is our cost on part A-1042' must return nothing for a user without cost visibility.

Custom tables and heavily customised 4GL logic are the main accuracy risk: the model can only reason about what the semantic layer describes. Budget time to document custom fields and status codes. Version matters too: very old OpenEdge releases and unlicensed SQL brokers can make SQL access impractical, in which case a replication-based extract is the fallback.

If your questions are all standard reports, QAD's own reporting and browse tools may be enough. And if you are moving to QAD Adaptive ERP, plan the AI layer against that platform's interfaces rather than investing deeply in EE table-level access.