JD Edwards EnterpriseOne loads purchase orders through its Z files, the unedited transaction tables F4301Z1 and F4311Z1, which the Inbound Purchase Order program R4311Z1I then turns into real orders in F4301 and F4311. Those staging tables want structured rows. They do not read a PDF. PurchaseOrders reads the purchase order PDF, scan, or photo and returns the header fields and the full line-item table as Excel, CSV, or JSON, so the file feeding your Z-file load is typed by a machine instead of a person. Upload a real purchase order below.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
JD Edwards has a genuinely good bulk-load path for purchase orders. Interoperability gives you staging tables, an inquiry screen to fix bad rows, a processor that applies your real P4310 business rules, and a purge to clean up afterwards. None of that helps with the step before it. The Z files take structured data, and the orders arrive as documents.
F4301Z1 and F4311Z1 are database tables. Whether you populate them with the Inbound Flat File Conversion program R47002C or write to them from your own integration, something upstream has to produce clean columns. When the source is a customer PO emailed as a PDF, that something is usually a person reading one window and typing into another.
A purchase order does not load as a single row. The header goes to F4301Z1, every line goes to F4311Z1, and the two have to agree on the keys that tie them together. Keying one order by hand means keeping both files consistent, and a mismatch does not surface until the processor runs.
The Inbound Purchase Order program is built for creating orders, not amending existing ones. Teams who discover this after loading a batch with a typo end up correcting orders by hand in P4310 anyway, which is exactly the work the load was meant to avoid.
R4311Z1I runs through a version of P.O. Entry (P4310) that you specify in its processing options, so the same edits, branch plant rules, and item validations that apply on the screen apply to the load. A date in the wrong format or an item number that does not match your item master bounces the row.
When rows fail you review them in Inbound Purchase Order Inquiry, revise them, and re-run the processor. That loop is fine for a handful of genuine data problems. It is miserable when most of the failures are transcription mistakes that never should have entered the staging table.
A cutover from a legacy purchasing system, a quarter of accumulated customer POs, or a newly acquired division all arrive at once. The Z-file side of that load takes minutes. The data-entry side takes weeks of somebody's time.
PurchaseOrders is the capture step in front of the Z files. It is not a JD Edwards connector and it does not run inside EnterpriseOne. You give it a purchase order document. It gives back clean, field-level data that you map to the F4301Z1 and F4311Z1 columns JDE already expects, then you load it with the interoperability tooling you use today.
A digital PDF from a customer ERP, a scan of a mailed order, or a phone photo of a paper PO. All go through the same extraction, with no per-supplier template to build first and nothing to configure per layout.
PO number, buyer and supplier, bill-to and ship-to, order date, promise date, payment terms, currency, and the line grid: item number, supplier item number, description, quantity, unit of measure, unit price, and extended amount, captured across page breaks.
Output is one row per line item with consistent headers, which is the shape R47002C wants once your flat file cross-reference is defined. Map your columns once to the header and detail Z files, and every later batch drops into the same mapping.
Pull the same extraction as JSON through our API and feed whatever already writes to your interface tables, whether that is an orchestration, a middleware job, or a script that inserts into F4301Z1 and F4311Z1 directly. Clean fields in, no document parsing on your side.
Upload a stack of orders at once rather than one at a time. That is what turns an initial load from a legacy purchasing system into a same-day job instead of a staffing problem.
Captured fields are shown on screen so you can correct an odd value before you export. Catching it here is a great deal cheaper than finding it in P4311Z1 after the processor has already rejected the row.
The standard route is interoperability. Your data lands in the two unedited transaction tables, F4301Z1 for the header and F4311Z1 for the detail, either through the Inbound Flat File Conversion program R47002C if you are starting from a flat file, or through a direct write from your own integration. You then run R4311Z1I, the Inbound Purchase Order program, from the Purchasing Interoperability menu. It validates the staged rows and creates the real orders in F4301 and F4311. The system ships transaction type JDEPOIN for these inbound transactions. Either way the question is the same: where does the structured data come from? If the answer today is a person reading a PDF, this tool replaces that step.
R4311Z1I does not create orders with its own private logic. Its first processing option asks which version of P.O. Entry (P4310) to use, and that version is what actually writes to F4301 and F4311. This is good news and bad news. The good news is that your branch plant defaults, tax rules, and item edits behave exactly as they do on screen, so a loaded order is a normal order. The bad news is that anything P4310 would reject from a user will also reject from a file, which is why the quality of the data going into the Z files matters so much.
Rows that fail are reviewed in P4311Z1, Inbound Purchase Order Inquiry, where you revise the header on the Unedited Transaction Header Revision form and reach the lines through Detail Revisions on the Row menu. Fix the data, re-run the processor. Once records are successfully processed, the purge program R47018 clears them out. Worth knowing before you go looking for missing data: the purge deletes transactions from F4301Z1 and F4311Z1 for records flagged as processed in the Processing Log table F0046, and it deliberately leaves unprocessed records alone.
To be plain about the boundary: PurchaseOrders extracts purchase order data from documents into a structured file. It is not a JD Edwards connector, it does not run R47002C or R4311Z1I for you, it does not write to F4301Z1, F4311Z1, or any other JDE table, and it does not create, approve, receive, or match purchase orders. Those all stay in EnterpriseOne. We remove the typing that happens before the load, and nothing else.
JD Edwards shops running a cutover from a legacy purchasing system use it to build the migration file. Manufacturers and distributors whose customers send POs as PDFs use it so those orders reach EnterpriseOne the same day they arrive. Integration teams wiring an orders mailbox to an orchestration use the purchase order API so the middleware gets JSON rather than an attachment. The purchase order PDF to Excel converter is the quickest way to see the output shape, and row-level accuracy on long orders is covered in purchase order line item extraction. A backlog clears through bulk purchase order upload, the general load path is in how to import purchase orders to an ERP, and teams on other Oracle-owned or mid-market systems can compare Oracle purchase order import, purchase order to SAP, and purchase order to Epicor.
All three end at the same place, an order sitting in F4301 and F4311. They differ in what happens before the load.
| What matters | Manual keying into P4310 | Template OCR tools | PurchaseOrders AI |
|---|---|---|---|
| Setup per supplier layout | None, but slow forever | Build a template each | None, any layout |
| Mixed PDF, scan, photo | Handled by a person | Often breaks | Handled automatically |
| Line-item capture | Error-prone by hand | Varies by template | Full line-item tables |
| Time per purchase order | 5 to 10 minutes | 1 to 3 minutes | Under 10 seconds |
| Output shape | Typed straight into the screen | Needs cleanup | Row per line, ready to map |
| Rows to revise in P4311Z1 | Typos drive most of them | Some | Fewer, data is reviewed first |
| Cost per PO at volume | High manual labor | Per-page plus setup | Under $2 |
PurchaseOrders.io extracts purchase order data into Excel, CSV, JSON, or an API response that you map to the JD Edwards interface table columns. It is not a JD Edwards connector, does not run R47002C or R4311Z1I, does not write to F4301Z1, F4311Z1, or any other JDE table, and does not create, approve, receive, or match purchase orders. JD Edwards and EnterpriseOne are trademarks of Oracle Corporation; this page is not affiliated with or endorsed by Oracle. Manual cost reflects published estimates of $15 to $40 to fully process a purchase order by hand.
No templates to build, no changes inside EnterpriseOne.
Drag in PDFs, scans, or photos, one at a time or a whole batch pulled from the orders mailbox.
Tip: Mixed suppliers and file types in the same upload are fine.
The AI reads each order and returns the header fields and the complete line-item table in seconds.
Tip: Check the captured values on screen before you export, not after the processor rejects the row.
Download Excel or CSV, map the columns to your F4301Z1 and F4311Z1 layout, and run your flat file conversion and R4311Z1I, or pull JSON via the API and write the staging rows from your own integration.
Through interoperability. You stage the data in the unedited transaction tables F4301Z1 for headers and F4311Z1 for detail lines, then run the Inbound Purchase Order program R4311Z1I from the Purchasing Interoperability menu. It validates the staged rows and creates the orders in F4301 and F4311. If you are starting from a flat file, R47002C loads the Z files first.
They are the purchase order unedited transaction tables, usually called the Z files. F4301Z1 holds inbound header records and F4311Z1 holds inbound detail lines. Nothing in them is a real purchase order yet. They are a staging area that R4311Z1I reads, validates, and copies into the live tables F4301 and F4311.
R4311Z1I is the Inbound Purchase Order program. It reads staged rows from F4301Z1 and F4311Z1, edits them, and creates purchase orders in F4301 and F4311. Its first processing option specifies which version of P.O. Entry (P4310) to run, so the order is built with your normal purchasing business rules rather than a separate import path.
No. The Inbound Purchase Order program is used for adding orders, not updating ones that already exist. This catches teams out on second loads. If you need to change an order that is already in F4301 and F4311, plan on doing it through P4310 or a purpose-built change process, not by re-staging the same order in the Z files.
R47002C is the Inbound Flat File Conversion program. It copies data from a flat file into the unedited transaction tables, including F4301Z1 and F4311Z1, provided you have set up a flat file cross-reference pointing at those tables. It runs before R4311Z1I. If your integration writes to the Z files directly, you do not need it.
Use P4311Z1, Inbound Purchase Order Inquiry. You locate the transaction on the Unedited Transaction Header Revision form, correct the header there, and reach the line data through Detail Revisions on the Row menu. After revising, re-run R4311Z1I against the corrected rows.
Most likely the purge ran. R47018, the EDI Purchase Order Inbound Purge, deletes transactions from F4301Z1 and F4311Z1 for records flagged as processed in the Processing Log table F0046. It leaves unprocessed records in place, so anything still sitting in the Z files after a purge is a record that never made it through.
No. The EDI tables and programs in the 47 system, including the inbound acknowledgment programs R47021 for the 855 and R47141 for the 865 change acknowledgment, handle trading-partner EDI documents. Interoperability through the Z files is the general-purpose route for data coming from any external source, which is what a PDF purchase order is once it has been extracted.
No, and we would rather say so plainly. It reads purchase order documents and returns structured data. It does not install in EnterpriseOne, does not run R47002C or R4311Z1I, does not write to any JDE table, and does not create, approve, receive, or match orders. You keep using JD Edwards interoperability; we just remove the typing in front of it.
Yes. The AI handles scans and phone photos, not only digital PDFs, and returns the same structured fields. That matters for JD Edwards shops because manufacturing, distribution, and construction customers still send a meaningful share of orders as scans, which template-based OCR tools tend to miss or mangle.
The same capture step for Oracle Fusion and EBS.
PO data shaped for SAP.
PO data shaped for Epicor Kinetic.
The general ERP load path.
Extract PO data to JSON via REST API.
How the line-item table is captured.
Clear a migration backlog in batches.
