# JD Edwards EDI Integration: EnterpriseOne Order Flow > How JD Edwards EnterpriseOne EDI works. Map inbound EDI 850 through the system 47 interface tables into F4201/F4211 sales orders. Oracle JD Edwards EnterpriseOne processes EDI through its "system 47" interface tables (the F47xxx family). An inbound EDI 850 lands in F47011 and F47012, then converts into a sales order header and detail in F4201 and F4211. Sales Order Entry is program P4210, and the order's movement is driven by Order Activity Rules per document type and line type. The inbound 850 and outbound 855, 856, and 810 follow the [ASC X12](https://x12.org/) standard. Your trading partner sends a routing guide. It wants EDI 850 purchase orders in, 855 acknowledgments back, 856 ship notices at shipment, and 810 invoices for payment. You run JD Edwards EnterpriseOne. The mechanics of how JDE ingests that 850 are specific, and knowing them up front saves weeks of confusion during onboarding. JD Edwards EnterpriseOne is Oracle's ERP for manufacturing, distribution, and asset-heavy industries. It has a defined EDI framework built around interface tables and a status-driven order engine. This guide covers that framework, how an inbound 850 becomes a sales order, and the ways you can connect EDI to JDE. ## What JD Edwards EnterpriseOne Is **JD Edwards EnterpriseOne is Oracle's on-premise and cloud-hosted ERP for distribution and manufacturing.** Oracle acquired JD Edwards through PeopleSoft in 2005 and continues to release and support EnterpriseOne. It sits alongside Oracle's other ERP lines, E-Business Suite and Oracle Fusion Cloud, as a distinct product with its own data model and tools. JDE organizes functionality into numbered systems. Sales Order Management is system 42. EDI is system 47. That numbering shows up in table names and program IDs throughout the application, so it helps to think in those terms. Oracle's JD Edwards documentation at [docs.oracle.com](https://docs.oracle.com) is the authoritative reference for the tables, programs, and setup described below. ## The System 47 EDI Interface Tables **EDI in JD Edwards runs through the system 47 interface tables, the F47xxx family.** These are staging tables that sit between an external translator and the live JDE order tables. Nothing goes straight from an X12 file into a sales order; it passes through system 47 first. For inbound sales orders, the relevant tables are: - **F47011** stores the EDI purchase order header (the inbound 850 header). - **F47012** stores the EDI purchase order detail (the 850 line items). A translator or middleware layer parses the X12 850 and writes it into F47011 and F47012. A JDE inbound edit and update process then reads those staging records, validates them, and converts them into a live sales order. The conversion writes the order into the sales tables described next. This staging design means you can inspect and correct inbound data in system 47 before it becomes a real order. Our [EDI 850 purchase order guide](/guides/edi/850-purchase-order) breaks down the segments the translator reads before writing to F47011, and the [free EDI Inspector](/edi-inspector) lets you paste a partner's 850 and see the parsed structure without signing up. ## From F47011 to a Sales Order in F4201 and F4211 **The inbound edit/update process converts F47011 and F47012 into a sales order header in F4201 and detail in F4211.** These are the same tables a manually keyed order uses, so an EDI order behaves like any other order once it lands. - **F4201** is the Sales Order Header table. - **F4211** is the Sales Order Detail table. Sales Order Entry itself is program **P4210**. It is the interactive program a user runs to enter or maintain an order, and it operates on F4201 and F4211. EDI orders arrive in those same tables through the system 47 conversion rather than through a person typing into P4210. Two setup objects control how the order behaves. The **document type** (from UDC table 00/DT) categorizes the order; the default sales order document type is **SO**, and the default purchase order type is **OP**. The **line type** controls how each line affects inventory, the general ledger, and other systems. Together with the document type, the line type determines the processing path. ## Order Activity Rules Drive the Flow **Order Activity Rules define the status sequence an order moves through, set per document type and line type.** This is the engine that advances a JDE order from entry to shipment to invoicing. Each step in the order's life has a status. Order Activity Rules define the **Last Status** and **Next Status** for a given document type and line type combination. When an order completes a step, JDE checks the rules to determine the allowed next status. An EDI order and a manual order can follow the same rules, or you can define a separate document type for EDI orders so they route through their own status path. Getting Order Activity Rules right for your EDI document type matters as much as the field mapping. If the statuses are wrong, orders stall at the wrong step or skip a step they should not, and the outbound 856 or 810 fires at the wrong time. ## The 810 and 856 Flow Back Out **Outbound 856 ship notices and 810 invoices are generated from JDE shipment and invoice data, back through system 47.** The return path uses the outbound side of the F47xxx tables. When you confirm shipment in JDE, the outbound extraction populates the system 47 outbound tables, and a translator builds the EDI 856 advance ship notice with the carton hierarchy and SSCC-18 labels the retailer requires. Most retailers require the ASN within 24 hours of shipment, and a late ASN triggers a chargeback. See our [EDI 856 ship notice guide](/guides/edi/856-ship-notice). For invoicing, the sales update process produces invoice data that the outbound extraction turns into an EDI 810. The 810 must reconcile to the original 850, including allowances and freight. Our [EDI 810 invoice guide](/guides/edi/810-invoice) covers the reconciliation. Partners that require order confirmation also expect an 855, and a 997 functional acknowledgment on each inbound document. ## Integration Methods for JD Edwards EDI **JD Edwards EDI connects through an EDI provider, custom middleware to system 47, or a managed service.** Each path has a distinct cost and maintenance profile. | Approach | Setup Time | Who Maintains Mapping | Non-EDI Orders | Best Fit | |---|---|---|---|---| | **EDI provider with JDE connector** | 3-6 months | Vendor (ticket queue) | No | Suppliers with many retail partners | | **Custom middleware to F47xxx** | 3-6 months | Your team or SI | No | Shops with JDE technical staff | | **Managed service (OrderSync)** | 1-3 weeks | OrderSync | Yes (EDI + PDF + email) | Distributors at realistic scale | The provider route brings a trading-partner network and compliance monitoring at a higher monthly cost. The custom route gives full control over the system 47 mappings if you have the internal JDE expertise. Both assume orders arrive as clean EDI, which is often not the case. ## How OrderSync Brings Orders Into JD Edwards **OrderSync creates JD Edwards sales orders from any order format, writing through the system 47 interface.** The inbound 850 becomes an order in F4201 and F4211. Shipment and invoice data flow back out as 856 and 810 documents. When a retailer changes their spec, we update the mapping. To connect orders to EnterpriseOne with OrderSync, see the [JD Edwards integration page](/integrations/jd-edwards). The reason distributors choose a service over a translator is the orders that never arrive as EDI. Independent accounts email PDF purchase orders, send spreadsheets, or use buyer portals. A translator alone leaves those for your team to key into P4210 by hand. OrderSync reads EDI 850s, PDF POs, and email orders through one pipeline and writes them all into JD Edwards, which fits distributors with a mix of large EDI partners and smaller manual accounts. See [multi-format order processing](/multi-format-orders), how the [ERP integration](/erp-integration) connects to JDE, and our overview of [ERP EDI integration](/guides/edi/erp-edi-integration). Running other Oracle or non-Oracle systems? Our related guides cover [Oracle EDI integration](/blog/edi-oracle-integration) for E-Business Suite and Fusion, plus [EDI NetSuite integration](/blog/edi-netsuite-integration), [Infor EDI integration](/blog/edi-infor-integration), and [Sage EDI integration](/blog/edi-sage-integration). > Define a dedicated document type for EDI orders and set its Order Activity Rules deliberately. It is the cleanest way to keep EDI orders on their own status path without disturbing how manually keyed orders flow. ## Frequently Asked Questions ### Does JD Edwards have native EDI? JD Edwards EnterpriseOne includes an EDI framework, system 47, with interface tables and inbound/outbound processes. It does not translate raw X12 files on its own; a translator or service parses the EDI and writes it into the F47xxx staging tables, from which JDE converts it into live orders. ### What are the system 47 tables in JD Edwards? System 47 is the JDE EDI system. Its F47xxx interface tables stage EDI data between an external translator and the live application tables. For inbound sales orders, F47011 holds the 850 header and F47012 the detail. The inbound edit/update process converts these into sales orders. ### How does an EDI 850 become a sales order in JDE? A translator writes the parsed 850 into F47011 and F47012. JDE's inbound edit and update process validates those records and converts them into a sales order header in F4201 and detail in F4211, the same tables that Sales Order Entry (P4210) uses. Document type and line type control the processing path. ### What controls order status in JD Edwards? Order Activity Rules define the Last Status and Next Status an order moves through, configured per document type (UDC 00/DT, default SO for sales) and line type. They advance the order from entry through shipment and invoicing, and they determine when outbound documents like the 856 and 810 are generated. ### Can OrderSync handle non-EDI orders for JD Edwards? Yes. OrderSync reads EDI 850s alongside PDF, email, and spreadsheet purchase orders and writes all of them into JD Edwards through the system 47 interface. Accounts that do not send EDI do not require a separate system or manual entry into P4210.