Turning SQL Into a JD Edwards UBE Using Claude Code

The problem with the SQL-in-a-drawer report

It works — until the one person who understands it doesn't.

SQL against the F-tables is fast to write and easy to iterate on, which is exactly why it never gets "properly" built. It runs from someone's laptop, with no JDE security applied, no scheduling, and no audit trail. A UBE built through Report Design Aid gets all of that — at the cost of needing table and business view knowledge most business analysts don't have. That gap is what Claude Code closes.

Before → after

A real one: open sales orders past promised ship date, by branch.

The ad hoc SQL someone's been running

SELECT SDMCU AS branch_plant, SDDOCO AS order_number, SDAN8 AS customer_no, SDPPDJ AS promised_ship_date, SDUORG AS qty_ordered FROM F4211 SD WHERE SDNXTR = '540' -- next status: pending ship confirm AND SDPPDJ < @TODAY_JULIAN AND SDLNST != '999' -- exclude cancelled lines ORDER BY SDMCU, SDPPDJ;

What Claude Code hands to Report Design Aid

Report: Custom UBE, clone base from R42565 (Open Sales Order report family) Primary table: F4211 (Sales Order Detail) — same table the SQL already used Business view: V4211E or equivalent exposing SDMCU/SDDOCO/SDAN8/SDPPDJ/SDUORG Data selection: Next Status (SDNXTR) = '540' Line Status (SDLNST) ≠ '999' Promised Ship Date (SDPPDJ) < system date (event rule, not hardcoded) Data sequencing: 1. Branch/Plant ascending 2. Promised Ship Date ascending Event rule: Populate "Days Late" = system date − SDPPDJ (SQL had no equivalent — free business value) Section/group: Group break + subtotal on Branch/Plant (SQL had no subtotal) Version security: Restrict to Distribution role — SQL had none

What actually changed

Same answer, now an asset instead of a liability.

Ad hoc SQL	UBE via RDA
Runs from one person's laptop	Runs on the Enterprise Server, on a schedule if needed
No security — anyone with DB access sees everything	Version-level security tied to JDE roles
Hardcoded date logic (`@TODAY_JULIAN`)	Event rule using live system date — correct every run
No subtotals, no formatting	Group breaks, subtotals, and standard JDE report formatting
Undocumented — lost if the author leaves	Registered in OMW with a named owner and change history

How the handoff works

Claude Code never touches RDA. It writes the spec RDA needs.

Give it the SQL, or describe the report in plain language.
Either input works — the F-table names are usually already in the SQL's FROM/WHERE clauses.

Claude Code maps columns to business views and UDCs.
Where read access to the data dictionary exists, it confirms the business view actually exposes the fields the SQL used — the single most common reason a first RDA attempt fails.

It drafts data selection, sequencing, and event rules.
Including logic the SQL never had — days-late calculations, subtotals, security — because a properly-built report is the right moment to add them.

A JDE developer builds it in RDA and moves it through proof to production.
The spec removes the requirements-gathering step; it doesn't remove the build, test, and change-control steps.

Why this is the highest-leverage piece of the series

Every JDE shop has a drawer full of these.

It's a known pain, not a hypothetical

Ask any JDE analyst if they have an ad hoc query that "really should be a real report" — the answer is always yes.

The conversion is mechanical once mapped

Most of the work is knowing which business view exposes which fields — exactly the lookup an agent does well.

Security and audit trail alone justify it

An unsecured SQL report against live production data is a compliance conversation waiting to happen.

Have a SQL-in-a-drawer report

Send it over — I'll map it to a real UBE spec.

No obligation to build it with me — you'll walk away with the business view mapping either way.

Hire me on Fiverr↗

The SQL query someone runs
every Monday should be a UBE.