JD Edwards · Versions & OMW

I don't let Claude Code
touch Object Management Workbench.

A "version" in JD Edwards is a specific configuration of an application or report — its own processing option values, its own data selection and sequencing. Building one by hand means a requirements meeting, a JDE developer, and a day or two of back-and-forth. Claude Code collapses that to a spec I can hand straight to Object Management Workbench.

Get your next version scoped in an hour
OMW · Interactive & Batch Versions · Processing Options · Data Selection
Where the line actually is

Claude Code drafts the spec. A JDE developer still creates the object.

This isn't "AI builds your JDE version unattended" — that would be a lie, and a dangerous one in a production ERP. Orchestrator can call an existing version; it can't create a new one inside OMW. What changes is the distance between "what the business actually needs" and "a version a developer can implement without three follow-up questions."

Before → after

From a Slack message to an implementable spec.

The ask: "I need a version of the sales order report that only shows Delhaize orders, grouped by branch/plant, sorted by promised ship date, excluding cancelled lines." Here's what Claude Code turns that into — ready to key into OMW without a clarifying meeting:

Application: P42101 (Sales Order Entry) reporting variant, batch print Version: XJDE0006 → clone to ZJDE9001 "Delhaize Ship Sched" Processing options: Tab 1 Display → Order Type default: SO Tab 2 Defaults → Line Status: exclude 999 (cancelled) Data selection: Customer (AN8) = BC (address book category code for Delhaize, per UDC 01/W1) Line Status (LNST) ≠ 999 Data sequencing: 1. Branch/Plant (MCU) ascending 2. Promised Ship Date (PPDJ) ascending UDC dependency: confirm 01/W1 "Delhaize" category code value exists before go-live
How it runs

Same four steps, every time.

Business user describes the need in plain language.
No JDE vocabulary required — "only Delhaize orders, sorted by ship date" is enough input.
Claude Code drafts the version spec.
Base application/version to clone, processing option values, data selection logic, sequencing — checked against the live UDC and business view definitions where read access exists.
Denis (or your JDE developer) keys it into OMW.
Minutes of data entry against a finished spec, not a discovery meeting followed by a first draft that misses a requirement.
Version is tested in a proof environment before it ever reaches production.
Non-negotiable — the spec speeds up drafting, it doesn't replace the change-control process.
Why bother, if a human still keys it in

The bottleneck was never typing. It was translation.

Fewer round-trips

Most version rework happens because the first draft missed a data-selection edge case. A complete spec up front catches that before it's built.

Business users self-serve the ask

They describe the outcome, not the UDC codes and processing option tabs — Claude Code is the translation layer.

Consistent naming and documentation

Every version spec follows the same format, which means every version is documented the moment it's requested, not reconstructed later from memory.

More in this series

Going deeper on JDE + Claude Code.

Have a version backlog piling up

Send me the ask in plain language.

I'll turn it into a version spec your JDE team can key in the same day — no discovery meeting required.

Hire me on Fiverr