Specialist ERPsIndustry

QAD + automotive suppliers

AI for QAD in Automotive: Schedules, Traceability and IATF Evidence From Your Own OpenEdge Data

Short answer

AI for QAD in automotive connects a private language model to QAD Adaptive ERP so supply chain, quality and plant teams can ask plain-English questions about customer schedule releases, MRP, lot and serial traceability, supplier performance and IATF 16949 evidence, with the underlying query shown. It reads through the OpenEdge SQL layer or QAD's integration services, stays read-only by default, and runs on-prem or in a private cloud tenancy.

ERP
QAD Adaptive ERP, QAD Enterprise Edition, QAD Cloud ERP
Industries
Automotive, Tier 1 and Tier 2 suppliers, Powertrain and components, Assembly
Written for
Supply Chain Manager or IT Director at an automotive supplier

QAD built its reputation serving global manufacturers, and automotive is its deepest vertical: multi-plant networks, schedule-driven demand from OEMs, multiple domains and currencies, and tight links to suppliers. Many Tier 1 and Tier 2 suppliers have run QAD for a decade or more, with years of accumulated configuration, custom programs on the Progress OpenEdge platform and plant-specific practices.

In that setting, the questions that matter are cross-cutting. Does the latest customer schedule release change what MRP planned last week? Which purchased components are short against the next four weeks of releases, and from which supplier? Which lots of a safety-critical part went to which customer, and what other lots share the same material? Answering any of these usually means a planner or analyst who knows the right screens, tables and filters.

Customers also expect a supplier to prove discipline: IATF 16949 process control, AIAG core tool records, traceability on demand, and rapid containment. The evidence exists in QAD and surrounding quality tools, but gathering it for an audit or a customer concern consumes hours from the same people who run the plant.

This page explains what AI on QAD looks like for an automotive supplier: how it reads OpenEdge data safely, which questions it handles well, how it respects QAD domains and security, and where the vendor's own reporting or a simpler tool is the better choice. It is written for a supply chain, quality or IT leader deciding on a pilot.

What usually gets in the way

The problems we hear most from supply chain manager or it director at an automotive supplier teams running QAD Adaptive ERP.

Schedule changes ripple through MRP faster than people can trace

Customer schedule releases change weekly or daily. Understanding which changes drive net requirements, which purchase orders to expedite and which are already covered requires reconciling schedules, MRP output and open orders across screens.

Traceability across plants and domains is slow to assemble

QAD often runs several plants and domains. A traceability question that crosses a plant, a lot and a customer shipment means joining inventory, transaction history and shipping records, which few people do confidently.

OpenEdge field names are not self-explanatory

Tables such as pt_mstr, wo_mstr, ld_det, tr_hist and sch_mstr hold the answers, but only people who know the schema, the domain field and the local customizations can query them correctly. That knowledge is concentrated and hard to replace.

Audit and customer evidence requests interrupt operations

IATF 16949 audits and OEM requests need specific records on a schedule outside the plant's control. Assembling them manually pulls quality and supply chain staff away from daily work.

Public AI tools are not an option for program data

Part numbers, pricing, schedules and drawings are covered by supply agreements and OEM security expectations. Teams that want AI help need an option that keeps data under company control.

Where AI earns its place in QAD Adaptive ERP

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Schedule release impact analysis

A planner asks "what changed in the latest releases for this customer and which components are now short" and gets a comparison against the prior release, the resulting MRP exceptions and the supplier on each shortage.

Touches: Customer scheduled orders and releases (sch_mstr and schedule detail), MRP output, purchase order lines, item master (pt_mstr)

Outcome: Shortage reviews start from a ranked list rather than a blank screen, which reduces late discovery and expediting.

Lot and serial traceability on demand

Quality asks which customers received a given component lot, which work orders consumed it, and where remaining stock sits, with the genealogy laid out step by step.

Touches: Lot and location inventory detail (ld_det), transaction history (tr_hist), work orders (wo_mstr), shipment records, receiving records

Outcome: A trace that used to take hours of joined queries becomes a reviewable answer in minutes, still confirmed by a quality engineer before external use.

Supplier delivery and quality questions

Buyers ask which suppliers have repeat late deliveries or rejects against current releases, and which open parts depend on them.

Touches: Purchase orders and receipts, supplier schedules, inspection and rejection records, item and supplier master

Outcome: Supplier reviews are grounded in specific history, which makes expediting and escalation conversations faster and more factual.

ASN and shipping exception review

Logistics asks which shipments today lack an ASN, mismatch a release quantity or carry a labeling exception.

Touches: Shipper and ASN records, customer schedule quantities, shipping and labeling records

Outcome: Exceptions are found before the truck leaves, not through a chargeback after.

Cost and variance narrative for plant finance

Finance asks why standard-to-actual variance moved on a product family, with a breakdown by material, labor, overhead and scrap and the work orders behind it.

Touches: Work order cost and variance records, standard cost data, inventory transaction history, routing and BOM structures

Outcome: Month-end variance explanations arrive faster, with the supporting transactions linked for review.

IATF evidence retrieval

Quality retrieves the records for an audit request, such as the inspection history, nonconformances and corrective actions linked to a part, along with the controlled documents that apply.

Touches: Inspection and nonconformance records, corrective action records, controlled document store, item and revision data

Outcome: Evidence assembly shrinks from a multi-day scramble to a reviewed package, with a person verifying completeness.

Multi-plant inventory and capacity questions

Planners ask which plant has spare capacity or surplus inventory for a constrained part, and what transfer it implies.

Touches: Inventory by site and location, routing and work center capacity, open work orders, domain and site master data

Outcome: Rebalancing between plants is decided on current data rather than on a call and a spreadsheet.

Reference architecture

QAD Adaptive ERP runs on the Progress OpenEdge database. The AI layer reads from it through a read-only SQL path (JDBC or ODBC to the OpenEdge SQL engine) where you host the database, or through QAD's integration services where the instance is vendor-hosted. A private open-weight model runs next to the data, so nothing leaves your boundary.

  1. 1

    Data access

    A read-only database user on the OpenEdge SQL-92 layer for self-hosted systems, or API and integration services for QAD Cloud. Replication to a reporting copy keeps analytic queries off the transactional system.

  2. 2

    Domain-aware semantic model

    QAD domains partition data, and most tables carry a domain key. The semantic layer maps business terms to tables and enforces the domain filter on every query so users only see the plants they are entitled to.

  3. 3

    Document retrieval

    Control plans, work instructions, supplier agreements, customer requirement documents and audit reports are indexed with revision and approval metadata so answers cite the current version.

  4. 4

    Private model serving

    An open-weight model (Llama, Qwen, Mistral, Gemma or gpt-oss class) runs under vLLM or Ollama on your GPUs or in a sovereign cloud. No prompt or record is sent to a public endpoint.

  5. 5

    Governance and interface

    Chat and dashboards with role mapping to QAD security, full query logging, and no write-back unless a defined action is approved by a named user.

Integration notes for your ERP team

  • Decide hosting first: direct OpenEdge SQL access is straightforward on self-hosted systems, while vendor-hosted instances usually require QAD's integration services, which changes the design.
  • Use a replica or reporting copy for analytic queries, and a read-only database role limited to the tables in scope.
  • Always apply the domain filter in the semantic layer rather than trusting the model to add it. Multi-domain mistakes are the most dangerous failure mode.
  • Document your customizations. Custom fields and local programs change what standard table names mean, and the semantic model must reflect them.
  • Index customer schedule data carefully, including release versions, so that "what changed since last release" is answerable.
  • Keep EDI and ASN transmission out of scope for write-back. The AI summarises; existing controlled processes transmit.

Deployment options

On-prem next to the OpenEdge database

Suppliers hosting QAD themselves, with data-handling restrictions from OEM contracts.

A GPU server and a read replica sit in your data center. The AI reads the replica, so the production database is not affected by analytic load.

Private cloud tenancy

Suppliers on QAD Cloud or self-hosting in a major cloud who want elastic GPU capacity.

Data and model serving run in your own subscription and region, with network rules limiting access to approved users.

Sovereign or regional private cloud

Suppliers with European, Indian or other regional data residency expectations.

A regional provider hosts the model and data store under your contract, with logging and access controls you audit.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

IATF 16949 and AIAG core tools

The assistant retrieves and summarises existing records. Ownership of control plans, PPAP approvals and corrective actions stays with your quality system and named people.

OEM customer-specific requirements

Customer requirement documents can be indexed so the assistant answers from your controlled copies rather than from general model knowledge.

TISAX and supply agreement confidentiality

Keeping data and model inside an environment you already assess avoids sending program data to an unvetted service. The customer remains responsible for their assessment results.

Access control and segregation

Role mapping to QAD security and domain filters on every query, with logs that show who asked what, support the segregation expected between plants and programs.

Change control for the AI layer

Model, prompt and semantic-model changes go through your normal IT change process, with a regression test set of known questions run before each change.

How an engagement runs

Phase 1 . 1 to 2 weeks

Discovery

  • -Hosting and access assessment (self-hosted OpenEdge or QAD Cloud)
  • -Domain and security model review
  • -Ranked list of 10 to 15 real questions
  • -Data classification and OEM contract constraints

Phase 2 . 4 to 6 weeks

Pilot build

  • -Read-only access and replica
  • -Domain-aware semantic model for schedules, inventory, work orders and suppliers
  • -Private model serving
  • -Test set of questions with verified answers

Phase 3 . 2 to 4 weeks

Validation

  • -Accuracy review with planners and quality
  • -Domain and role segregation tests
  • -Performance and load check
  • -Go or no-go summary with measured results

Phase 4 . 2 to 4 weeks

Rollout

  • -Production deployment and monitoring
  • -User training
  • -Runbook for upgrades, including QAD version changes
  • -Backlog of next use cases

Questions to ask any vendor, including us

A short list that separates real QAD Adaptive ERP AI work from a chatbot demo.

  1. How do you connect to our QAD instance, and does that differ for self-hosted versus QAD Cloud?
  2. How is the domain filter enforced, and what stops a user from seeing another plant's data?
  3. How do you handle our custom fields and local programs in the semantic model?
  4. Can you show the SQL behind each answer and the rows it used?
  5. What happens to the AI layer when we upgrade QAD to a new version?
  6. Where does the model run, and does any data reach a third-party service?
  7. How do you test accuracy before go-live and monitor after?
  8. Where is QAD's own reporting or analytics enough, so we do not over-buy?

Frequently asked questions

Can AI read QAD data directly from the OpenEdge database?

On self-hosted systems, yes, through a read-only SQL path to OpenEdge, preferably against a replica so analytic queries do not affect transactions. On QAD Cloud, direct database access is generally not available, so the design uses QAD's integration services instead. Confirm your hosting model and access rights before scoping.

How does it handle QAD domains?

The semantic layer applies the domain filter to every query, based on the user's role, rather than relying on the model to remember. This is tested explicitly during validation with users from different plants, because a missing domain filter is the most serious error a QAD-based AI system could make.

We already use QAD analytics. Is this needed?

If your recurring questions are served by existing dashboards, you may not need it. Private AI helps with ad hoc questions across schedules, inventory and quality, and with documents that sit outside tables. A short question inventory in discovery will show whether the gap justifies a pilot.

Does this replace our quality system for IATF audits?

No. It helps find and assemble records already in your systems. Control plans, PPAP approvals, corrective actions and management review remain your quality system's responsibility, with named owners. The assistant is a faster way to retrieve evidence, and a person confirms what is presented to an auditor or customer.

Can it create purchase orders or change schedules?

By default it cannot. Write-back is off, and we recommend leaving it off until accuracy is proven. Where a write action is justified, for example drafting an expedite request, it is limited to a defined action, shown to a named user and approved before anything reaches QAD.

What models run, and where?

Open-weight models from the Llama, Qwen, Mistral, Gemma, gpt-oss or DeepSeek families, served by vLLM or Ollama on your GPUs or private cloud. Choice depends on language needs and hardware. Prompts and retrieved records stay inside your boundary, and your data does not train a shared model.

How long does a pilot take?

Typically six to twelve weeks from discovery to a decision, depending on hosting, data quality and how many domains are in scope. Early results are strongest on structured questions about schedules, inventory and suppliers. Document-heavy use cases usually need more iteration on formatting and revision control.

Talk it through with an engineer who knows QAD Adaptive ERP

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.