Teaching AI Agents Your ERP: JD Edwards Data, CData Drivers and Reusable Skills

AI agents are moving from answering general questions to doing real work inside the business, and much of that work depends on ERP data. What do we owe our suppliers? Which invoices are coming due? Which customers are past their credit limit? In many organizations, the answers live in Oracle JD Edwards EnterpriseOne.

JD Edwards exposes its data through the Application Interface Services (AIS) Server, and its data model spans thousands of tables and business views organized by system code. The new CData Driver for JD Edwards turns that into relational views that you can query with standard SQL from any tool that speaks JDBC, ODBC, ADO.NET or Python, with friendly column names and real date types. That gives an AI agent a direct, standard way to reach the data.

Every JD Edwards installation is also its own. Companies choose which modules they run, how they use user defined codes, how their companies and currencies are set up, and which reports matter to their teams. An agent can work much of that out by exploring, but there's no reason to repeat that work in every conversation. One convenient way to keep it is an agent skill: a short, reusable file where the agent records the context it learned about your instance, such as the views that answer your questions, the codes your team uses and the queries that worked, so the next session can start from there.

In this article we introduce the JD Edwards driver and what it exposes, then walk through an example: an agent explores JD Edwards with the CData JD Edwards JDBC Driver (through the CData CLI), captures what it learned about accounts payable as a skill, and uses that skill to answer a finance question.

Why connect ERP data to AI agents

Enterprises are rolling out AI assistants across the business, and the first request from finance and operations teams is usually the same: let it see our ERP. The requests we hear take a few common forms:

• Finance teams copying data by hand. Analysts export ERP data into spreadsheets, then paste it into an AI assistant to ask questions about it. They want a live, governed connection instead.
• Software vendors building agents into their products. Procurement and supply chain platforms want their agents to read customers' ERP data, such as purchase orders, suppliers and invoices, without building and maintaining a separate integration for every ERP.
• IT teams standardizing access. Organizations that have rolled out AI assistants widely want one governed way for agents to reach business systems, with the ERP's own permissions applied.

JD Edwards adds its own challenges on top of these:

• Scale of the model. JD Edwards groups its tables and business views into hundreds of system codes. Even the financial modules alone can contain more than a thousand views, and many of them are worktables, print drivers and purge files that no business user should query.
• Meaning stored in codes. Status values, document types and many other fields are short codes whose meaning lives in user defined code (UDC) tables.

Introducing the CData Driver for JD Edwards

What you need to connect

The driver connects through your JD Edwards AIS Server with a JD Edwards user ID and password:

jdbc:jdedwards:URL=https://jde-ais.example.com:8300;User=<user>;Password=<password>;

On the first connection, the driver exchanges your credentials for an AIS session token and caches it. It requests a new token automatically as the session nears its timeout. Because every request goes through AIS with your JD Edwards user and role, JD Edwards' own permissions apply to the session.

The data model

JD Edwards organizes tables and business views into System Codes (also called Product Codes), such as 04 for Accounts Payable or 09 for General Accounting. The driver exposes each system code as its own SQL schema, so a fully qualified name reads like AccountsPayable.AccountsPayableLedger.

Because the full model is so large, two connection properties control which schemas you see:

With the default FinancialManagement data model, our demo environment exposed 13 schemas:

SELECT * FROM sys_schemas

That's about 1,250 views for finance alone.

A few things make these views much easier to work with than raw JD Edwards tables:

• Readable names. Columns carry names such as DocumentNumber, InvoiceDate, OpenAmount and PayStat rather than JD Edwards data dictionary aliases.
• Real dates. Date columns are returned as SQL DATE values. There's no Julian date conversion to write.
• Server-side filtering. The driver translates WHERE conditions into JD Edwards Query By Example (QBE) filters, so they run on the AIS Server. Text columns support =, !=, LIKE and IN; numeric and date columns also support <, <=, > and >=, and two conditions on the same date column express a range.
• Read-only views. Tables and business views are exposed as read-only views, which makes the driver a safe way to give an agent access to ERP data.
• Operations go through stored procedures. For example, AddressBook.GetContactData returns the Who's Who contact details for an address book entry. Setting ExposeBusinessFunctions=true also exposes JD Edwards Business Functions (BSFNs) as stored procedures. It's best used with a specific DataModel, because the number of business functions can be very large.

From discovery to a reusable skill

To show the driver in action, we gave an AI agent a finance question that comes up every week:

"Which suppliers do we owe the most on approved vouchers, and what's coming due in the next 30 days?"

We used the CData JDBC Driver for JD Edwards with the CData CLI, against an Oracle JD Edwards demo environment. The same driver is available in CData's other editions.

Letting a coding agent drive

We didn't hand-write the queries. We used Claude Code with the CData CLI skills, which teach a coding agent how to install, connect to and query CData drivers from the command line.

Instructions for downloading the CData CLI and associated skills can be found here: CData CLI: Use CData Drivers with Claude Code, Cursor, and Copilot

We started with a plain-language goal:

"Use the /cdata-cli to explore our JD Edwards accounts payable data, then save what you learn as a skill that another agent can use to answer our AP questions."

From there, the agent discovered the schemas, read the driver documentation, ran sample queries, and wrote down what it learned. Our role was to supply the JD Edwards credentials (in our own terminal, so they never entered the agent session) and to choose the question.

Step 1: Connect and explore with the CData CLI

# Confirm the driver is installed
cdatacli drivers list

# Save an encrypted connection (run this in your own terminal so the
# password stays private)
cdatacli connection create --driver "JD Edwards" --name jde \
  --connectionstring "URL='https://<ais-server>';User='<user>';Password='<password>';ReadOnly=true"

# Explore the schema
cdatacli query sql --connection jde --sql "SELECT * FROM sys_schemas"
cdatacli metadata tables --connection jde --schema AccountsPayable
cdatacli metadata columns --connection jde --schema AccountsPayable --table AccountsPayableLedger

Step 2: What the agent learned

The AccountsPayable schema alone has 230 views, including 1099APWorktable, PurgeAccountsPayableLedger and PrintAutomaticPaymentsStandardFormat. The agent narrowed it down to the view that matters for open balances, AccountsPayableLedger (JD Edwards table F0411), and sampled it:

SELECT [DocumentNumber], [DoTy], [AddressNumber], [InvoiceNumber],
       [DueDate], [PayStat], [OpenAmount], [CurCod], [Co]
FROM [AccountsPayable].[AccountsPayableLedger]
WHERE [OpenAmount] > 0
LIMIT 3

The data was readable, but this first result raised the questions the agent needed to answer before it could respond to the finance team. Each voucher points to a supplier by number, so where do the names live? Status fields hold short codes, so what do they mean? And how should amounts be totaled when they come from different companies?

The agent worked through each question the same way: it read the driver documentation, added the system codes it needed to the connection, and ran small queries to confirm what it found. Along the way it learned which of the hundreds of views actually answer accounts payable questions, how to decode JD Edwards codes, and how to total amounts correctly. Those findings, together with the queries that worked, became the skill.

Step 3: Store it as a skill

Rather than leave those findings in one conversation, the agent saved them as a skill: a Markdown file with a short description that tells future agents when to load it. In Claude Code, skills live under .claude/skills/<name>/SKILL.md for a project or ~/.claude/skills/<name>/SKILL.md for a user. Other agents have their own equivalent.

The skill is short. It names the connection settings, the three views to use, the rules the agent learned in Step 2, and the queries that were validated:

---
name: cdata-jdedwards-ap
description: Answer accounts payable questions (open vouchers, supplier balances,
  upcoming payments) from JD Edwards EnterpriseOne through the CData JD Edwards
  driver and the CData CLI.
---

## Connection
DataModel=FinancialManagement;SystemCodes=00,01

## Where the data lives
| Need | View |
|---|---|
| Vouchers and open balances (F0411) | [AccountsPayable].[AccountsPayableLedger] |
| Supplier names (F0101)             | [AddressBook].[AddressBookMaster] |
| Code descriptions (F0005)          | [FoundationEnvironment].[UserDefinedCodesSYRTKYDL01DL02] |

## Rules
1. Open items: OpenAmount > 0
2. PayStat 'A' = Approved for Payment, 'H' = Held, '#' = Payment In Process
3. OpenAmount is in the company's base currency. Never total across companies.
4. UDC values are right-justified. Compare with TRIM([UserDefCode]).
5. Dates are real DATE values; WHERE filters run on the JD Edwards server.

The skill holds what an agent can't easily guess and what's expensive to rediscover: which views matter, how to decode them and how to total them correctly. It doesn't repeat what the driver already provides, such as connection handling, pagination and the column list.

Step 4: Ask the question

With the skill loaded, the agent can go straight to the right views. The first half of the question becomes one cross-schema join:

SELECT l.[Co], a.[AlphaName], COUNT(*) AS items, SUM(l.[OpenAmount]) AS openAmt
FROM [AccountsPayable].[AccountsPayableLedger] l
INNER JOIN [AddressBook].[AddressBookMaster] a ON l.[AddressNumber] = a.[AddressNumber]
WHERE l.[OpenAmount] > 0 AND l.[PayStat] = 'A'
GROUP BY l.[Co], a.[AlphaName]
ORDER BY openAmt DESC
LIMIT 5

Both companies in this result use USD as their base currency. The amounts come from Oracle's demo data.

The second half is a date range on the same join:

SELECT l.[Co], a.[AlphaName], l.[InvoiceNumber], l.[DueDate], l.[OpenAmount], l.[CurCod]
FROM [AccountsPayable].[AccountsPayableLedger] l
INNER JOIN [AddressBook].[AddressBookMaster] a ON l.[AddressNumber] = a.[AddressNumber]
WHERE l.[OpenAmount] > 0 AND l.[PayStat] = 'A'
  AND l.[DueDate] >= '2026-10-06' AND l.[DueDate] <= '2026-11-05'
ORDER BY l.[DueDate]

Each query returned in under ten seconds. Following the skill's rules, the answer names suppliers rather than address numbers, reports totals per company with the currency, and says that only vouchers approved for payment were counted.

The agent's answer:

Largest open balances on approved vouchers (Pay Status A – Approved for Payment, open amount greater than zero). Amounts are in each company's base currency; both companies below use USD.

Company	Supplier	Open vouchers	Open amount (USD)
00022	Supplier A	7	113,786,705.00
00022	Supplier B	27	102,716,302.00
00001	Supplier C	38	79,016,979.57
00022	Supplier D	9	68,211,197.00
00001	Supplier E	84	54,767,506.32

Coming due in the next 30 days (October 6 to November 5, 2026): two approved vouchers, both in company 00001, totaling 12,100.00 USD.

Due date	Supplier	Invoice	Open amount (USD)
Oct 10, 2026	Supplier F	FACT 0001	12,000.00
Oct 11, 2026	Supplier G	MK789	100.00

Totals are reported per company and aren't combined across companies, because each company's amounts are in its own base currency.

The tech stack, in plain terms

Wrapping up

ERP data is some of the most valuable context an AI agent can have, and JD Edwards holds a lot of it: suppliers, vouchers, ledgers, assets and more. The CData Driver for JD Edwards makes that data available through standard SQL without any AIS API code. You connect through your AIS Server with your JD Edwards credentials, choose the modules you need with DataModel and SystemCodes, and query read-only views with readable names, real dates and filters that run on the JD Edwards server.

A driver gives an agent access; a skill gives it judgment. In our example, an agent spent one session learning where accounts payable data lives and how to read it, then saved that knowledge as a few dozen lines of Markdown. Every session after that starts with the right views, the right codes and the right way to total amounts. The same pattern works for any JD Edwards module, and for any of the hundreds of other sources CData connects to.

Get started: download the CData Driver for JD Edwards