Skip to content

Flagship · Production automation · walkthrough

JDE Work Order Automation

A self-built pipeline that took a manual Oracle JD Edwards work-order process to 90% hands-off — deployed and running in production at BT Applied Technology. This is the write-up; the code is proprietary.

The problem

In a construction-operations role, work orders arrive as documents — BOQs, material submittals, supplier paperwork — and every one had to be keyed into Oracle JD Edwards EnterpriseOne by hand: create the work order, enter quantities, issue materials, file the documents. It's slow, repetitive, and error-prone at volume, and it scales only by adding people.

I taught myself enough to automate my own department's workflow end to end. Nobody assigned it; it started as a way to get my own work done faster and became a production system.

The pipeline

One combined PDF (or a stack of files) goes in; posted JD Edwards records come out. A Claude-API pass reads each document and extracts the fields; a mapping layer turns them into JDE inputs; and browser automation drives the ERP screens to create the work order, post quantities, issue materials, and archive the paperwork.

PDF packet scans · exports Claude extract + classify Field mapping Oracle JD Edwards › create work order › post quantities › issue materials › archive documents

The five components

The system is modular — five components, each with a single responsibility, so a failure or a format change is isolated to one stage instead of taking down the run:

  1. PDF processing — ingest a combined packet or several files; Claude reads each document and returns structured fields with the values it found.
  2. Work-order creation — map the extracted fields to JDE and create the work-order header.
  3. Material management — attach and reconcile the materials against the order.
  4. Inventory processing — post quantity entries and inventory adjustments.
  5. Document handling — archive the source paperwork against the created records for the audit trail.

Reliability

Because it drives a real ERP against real inventory, it's built to fail safe. Every stage carries validation, retry logic, and logging; the browser automation has explicit error handling so a flaky screen or an unexpected field is caught and retried rather than posting bad data. Low-confidence reads surface for a human instead of guessing.

Results & stack

Over roughly eleven months it processed 3,300+ work orders with a 90% reduction in manual handling time, and it still runs in production week to week. Built with Python and JavaScript for the pipeline and mapping, VBScript and AutoIt for desktop/ERP automation, the Claude API for extraction, and browser automation to drive JD Edwards.

Why it isn't public

It runs against a live enterprise system and its documents contain company data, so the repository is private. This page is the walkthrough; I'm glad to talk through the design, the mapping layer, and the reliability model on a call.