How to automate email into JD Edwards World
Short answer
Read shared inboxes with IMAP or Microsoft Graph, extract the order data with rules plus a language model, validate against World master data, and drop approved records into a staging table that a World batch input job posts. Reviewers see low-confidence items before anything is written.
In many World shops, customer orders still arrive as email attachments and are re-keyed by order desk staff into the sales order entry screens. Supplier acknowledgments and invoices travel the same way. Each email involves finding the customer, matching item numbers or customer part numbers, checking prices and keying lines, which is slow and error prone.
The IBM i handles outbound mail well enough, but inbound mail parsing is not something World does. That makes email automation a pure add-on layer: read mail outside, make sense of it, and use the IBM i only for master data lookups and the final controlled post.
This page covers the architecture, the matching problems that dominate real projects, and the order of work that gets value without risking bad orders in the system.
What teams use it for
Customer purchase orders to sales order entry
Extract customer, PO number, lines, requested dates and ship-to from an emailed PO, match to the Address Book and item cross-references, and stage a sales order for review.
RFQ capture
Recognize an RFQ email, pull the part numbers and quantities, check existing items and last quoted prices, and open a quote worksheet for sales.
Supplier order acknowledgments
Read acknowledgments, extract promised dates per line and update the PO promise dates after buyer review.
Shipping notices (ASN-like emails)
Parse carrier and tracking details from supplier emails to prepare receipts and to alert receiving.
Change requests
Detect 'please change quantity' or 'cancel line 3' replies, attach them to the existing order and flag for the order desk instead of letting them sit in a mailbox.
JD Edwards World (IBM i) integration surface
- DB2 for i read access to customer, item, cross-reference and open-order data for matching and validation; exact file names depend on release and local modifications.
- World sales order and purchase order batch input facilities (for example an input transaction file processed by a batch program) as the hand-off for approved records; availability and layout vary by version, so confirm with your World administrator.
- Staging libraries and tables on the IBM i or an adjacent database for parsed results and review status.
- IFS folders for storing the original email and attachments as the audit source.
- IBM i job scheduler for the batch poster, and SNDSMTPEMM or the mail framework for outbound confirmations.
- On the mail side: IMAP, Microsoft Graph or Google Workspace APIs, with app-only credentials scoped to the shared mailboxes.
How it works
- 1
Start with one mailbox and one document type
Pick the shared orders inbox and customer POs only. Resist the urge to automate every message type at once.
- 2
Read and classify
Pull new messages, store the raw email and attachments on the IFS or in object storage, and classify as PO, RFQ, acknowledgment, change request or other.
- 3
Extract
Use rules for known customer templates and a language model for variable layouts; require the model to output structured JSON with a per-field confidence.
- 4
Match to master data
Resolve the sender to a customer through the Address Book, map customer part numbers to World items through cross-references, and check price and unit of measure.
- 5
Review queue
Show side-by-side the email, the extracted fields and the matched records. Auto-approve only above a threshold you have tested on historical mail.
- 6
Post through batch input
Write approved records to the staging or input table; a scheduled World job processes them with standard edits and returns errors for correction.
- 7
Close the loop
Send an order acknowledgment from World or the service and archive the email with the resulting order number.
Example flows
Emailed PO from a repeat customer
Trigger: A PDF purchase order arrives in orders@ from a known sender.
- The service stores the email and PDF, then extracts header and lines.
- Customer part numbers are mapped through the item cross-reference; two lines remain unmatched.
- The review screen highlights the two lines and offers likely matches.
- A clerk confirms, and the order is staged and posted by the batch input job.
- An acknowledgment goes to the customer with the World order number.
Result: Order desk time shifts from keying to checking exceptions.
Supplier acknowledgment with new dates
Trigger: A supplier replies to a PO email with a table of delivery dates.
- The service matches the PO number in the subject or body to an open order.
- It extracts a promised date per line and flags lines later than the need date.
- The buyer reviews the late lines and accepts the update.
- A batch job updates the promise dates and the planner sees revised supply.
Result: MRP uses real supplier dates rather than stale ones.
Keeping data on-prem
Inbound mail often contains customer pricing and drawings, so run extraction where you control it. A vision-capable open-weight model on a local GPU server can read PDFs and images without sending them to an outside API, and the IBM i plus a staging database can stay entirely on your network. If mail is in Microsoft 365, the connection to Graph is the only external dependency; the parsed data and attachments remain in your storage. Air-gapped environments can use an internal mail relay and local models only.
Security checklist
- Treat attachments as untrusted: scan for malware and never execute embedded content.
- Use app-only mail credentials limited to specific mailboxes and rotate them.
- Guard against prompt injection in email text by never letting the model call tools or write to World directly.
- Keep the raw email as evidence and link it to the staged and posted record.
- Separate duties: the person who approves a staged order is logged and, for high values, not the same as the extractor tuner.
Ways to get it done
Rules and templates per customer
Effort: Days per template, brittle when a customer changes layout.
Fits a small number of high-volume customers with stable PO formats.
Packaged intelligent document processing product
Effort: Weeks of setup, plus per-document licensing; check support for batch input to World.
Fits shops with budget and a vendor that already integrates with IBM i or generic REST and file hand-off.
Language model pipeline built with a partner such as Netray
Effort: A pilot on one mailbox, then expansion as accuracy is measured on your own historical mail.
Fits varied formats, on-prem or air-gapped needs and a desire to review exceptions only.
Pitfalls
- !Customer part number cross-references are usually incomplete; plan for a clean-up and a learning loop that stores confirmed matches.
- !Units of measure and pack sizes cause silent errors; validate quantity times unit against price.
- !Duplicates: the same PO sent twice or revised must be detected by customer plus PO number.
- !Auto-posting too early creates bad orders that are costly to unwind; start in review-all mode.
- !Email threads carry quoted history; make sure the extractor reads the latest message, not the quoted original.
Frequently asked questions
Can JD Edwards World read incoming email by itself?
Not in a useful way for order intake. World and the IBM i can send email, but parsing inbound mail and attachments is done by an external service that then hands clean transactions to World through a batch input path or staging table.
How do we post orders without screen scraping?
Use a batch input or interface file mechanism that your World version supports, or write a small RPG program that reads a staging table and calls the normal entry logic. Your World administrator can confirm what exists in your release. Avoid direct file inserts.
How accurate is AI extraction on PO PDFs?
It depends on layout quality and your master data. Clean digital PDFs from repeat customers extract very well, while scans and unusual formats need more review. Measure on a sample of your own historical orders before setting any auto-approve threshold.
Can this run without sending documents to the cloud?
Yes. Use a local OCR and an open-weight model on your own GPU server, with the staging database and IBM i inside your network. That suits customers with contract or export restrictions on where documents may be processed.
What is the fastest first step?
Pick one mailbox and one document type, collect a few hundred historical examples, and run extraction in shadow mode while clerks keep keying. Compare results for a few weeks, then move to review-before-post once the match rates are known.
Want Email automation working on your JD Edwards World (IBM i)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment