Oracle JD Edwards Orchestrator integration

What the integration does

Core Invoice pushes each reviewed supplier invoice into JD Edwards EnterpriseOne as an AP voucher by calling one Orchestrator orchestration, CI_AddSupplierInvoice, over the AIS REST API. JDE stays the system of record: it validates the supplier, company, currency and dates, assigns the voucher number and writes F0411 and F0911; Core Invoice stores that voucher number against the invoice.

• Core Invoice side. Supplier invoices arrive by upload, email or API, OCR extracts vendor, totals and lines, and a reviewer confirms them with a GL coding and an optional cost centre. A reviewed invoice is pushed to the ERP by hand or automatically.
• JD Edwards side. An Orchestrator Studio form request drives Standard Voucher Entry (P0411) exactly as a clerk would, so every JDE edit, default and AAI applies to the voucher.
• In scope. Purchase invoices as unposted vouchers of document type PV. Credit notes, receipts and sales invoices are never pushed (see Responses & errors).
• Next. Suppliers, accounts and business units read from JDE so reviewers code against JDE's own master data, tax codes on the voucher, and an optional batch path through the Z-files.

Architecture

Core Invoice makes one outbound HTTPS call per invoice. The AIS server runs the orchestration, which drives the two Voucher Entry forms on the HTML server, and the voucher number comes back in the same response. Orchestrator Studio is used only at design time, by the administrator who builds the objects.

Authentication

Core Invoice signs in to the AIS server with a JDE user and password, uses the returned AIS token for the orchestration call, and keeps nothing between pushes.

1. A token request with the user, password, the device name core-invoice, and the environment and role set on the connection. The token is userInfo.token in the response.
2. The orchestration call carries two headers, jde-AIS-Auth with the token and jde-AIS-Auth-Device with the same device name. The device header is mandatory because the token was requested with a device name. Authorization: Bearer is reserved by AIS for JWTs and is not sent.
3. "Test connection" in Core Invoice is the token request alone; success means the credentials, environment and role are accepted.

POST /jderest/v2/tokenrequest
Content-Type: application/json

{
  "username": "COREINV",
  "password": "********",
  "deviceName": "core-invoice",
  "environment": "JPD920",
  "role": "*ALL"
}

POST /jderest/v3/orchestrator/CI_AddSupplierInvoice
Content-Type: application/json
jde-AIS-Auth: <userInfo.token from the token request>
jde-AIS-Auth-Device: core-invoice

Connection settings

One token per push is well inside any usual AIS token lifetime, and no session is kept open between pushes. AIS also accepts HTTP Basic on the orchestration call itself, which would remove the token step; environment and role then come from the AIS defaults, so it stays a fallback rather than the default.

Invoice push flow

A push is one synchronous HTTPS call that ends with either a voucher number or an error message on the invoice; nothing is left half-done on the Core Invoice side.

1. A reviewer sets the invoice to Reviewed. The push starts from the "Push to ERP" action with the JDE connection selected, or automatically on review when the connection has auto-push on.
2. Core Invoice refuses before calling JDE when the document is a credit note, a receipt or a sales invoice, when the invoice is not in Reviewed, or when 3-way matching is set to block and the purchase order did not reconcile.
3. It writes a sync log row in status pending, builds the payload (next section), requests a token and calls the orchestration with a 60-second timeout.
4. The orchestration runs the two voucher-entry forms inside JDE. JDE validates every field, assigns the next voucher number and writes F0411 and F0911 in one unposted batch of type V.
5. The orchestration answers with the voucher number. Core Invoice stores it as the sync log's external id, marks the log success and sets the invoice to Pushed; the voucher number shows on the invoice page.
6. On an HTTP 4xx or 5xx the AIS error message is stored on the sync log and shown on the invoice; the invoice stays Reviewed and can be pushed again once the cause is fixed.

Payload and field mapping

Core Invoice sends one stable JSON body per invoice, and the orchestration's inputs are named after these keys, so no field mapping lives in Core Invoice.

{
  "vendorName": "Acme Supplies Ltd",
  "vendorTaxId": "123456-789",
  "invoiceNumber": "INV-84139",
  "invoiceDate": "2026-10-27",
  "dueDate": "2026-11-26",
  "currency": "USD",
  "subtotal": "46.40",
  "taxTotal": "5.10",
  "grandTotal": "51.50",
  "lines": [
    {
      "lineNumber": 1,
      "itemNumber": "GW44217",
      "description": "Junction box 190x140x140 IP56",
      "quantity": "1.0000",
      "unitPrice": "16.2000",
      "discountPct": null,
      "taxRate": "11.0000",
      "lineTotal": "17.98",
      "lineCurrency": "USD"
    }
  ]
}

Amounts travel as strings to avoid floating-point loss and any optional field may be null. Dates are ISO yyyy-MM-dd; the orchestration inputs are typed Date with that format and the amounts Numeric.

Inside JDE: the orchestration

CI_AddSupplierInvoice is a version 3 orchestration with one step, the form request CI_FR_Voucher, which walks Standard Voucher Entry through its two forms and returns the voucher number.

What JDE does between the two OKs:

• On the first OK it validates the supplier (Address Book and Supplier Master), company, currency, dates and amounts, assigns the voucher number from Next Numbers (system 04) with document type PV, and opens the G/L Distribution form with the amount to distribute.
• On the second OK it checks that the distribution lines equal the amount to distribute, writes the voucher and its pay item to F0411 and the expense line to F0911. The batch is type V and stays unposted; the normal G/L post (R09801) creates the AP trade offset from AAI item PC.
• The orchestration maps the returned Document No/Typ/Co to the output voucherNumber and Document Type to documentType.

Give company, supplierNumber and glAccount default values inside the orchestration (your company, a fallback supplier and a default expense account): any value Core Invoice sends overrides its default, so the same orchestration serves the first test and production. Share the orchestration once it works and grant the Core Invoice service account run rights on it, plus application security for P0411.

Responses, errors and what never gets pushed

Success is HTTP 200 with the orchestration's named outputs; any failure is a JSON error whose message Core Invoice shows on the invoice verbatim.

HTTP/1.1 200 OK

{
  "voucherNumber": "12345",
  "documentType": "PV"
}

Core Invoice accepts the number under voucherNumber, DocNumber, docNumber or documentNumber, at the top level or inside ServiceRequest1; a 200 without any of them is treated as an error that quotes the raw response.

The AIS error body has this shape; Core Invoice reads message, then error, then exception.

HTTP/1.1 500 Internal Server Error

{
  "message": "<the EnterpriseOne error text, for example an invalid supplier number>",
  "exception": "<exception class, when one was thrown>",
  "timeStamp": "2026-10-27T10:15:02.114+0200",
  "userDefinedErrorText": "",
  "status": "ERROR"
}

Never pushed, with the reason stated on screen and no sync row written:

• Returns and credit notes: the push only expresses a positive payable, so a credit would book as another bill.
• Receipts: they settle an obligation and would double-count the invoice they pay.
• Sales invoices: they would raise a payable to the tenant's own customer.

Expense receipts and payments have no JDE implementation yet; the connector answers "not implemented" if one is attempted.

Master data from JDE

Reviewers should code against JDE's own suppliers, accounts and business units, so Core Invoice reads them from JDE on a schedule through read-only Data Request orchestrations; this sync writes nothing to JDE.

How it runs: hourly per active JDE connection, plus once immediately when the connection is created. Each sync creates or updates on the external id and never deletes, so a supplier retired in JDE stays but is marked inactive. The push then sends supplierNumber from the vendor's external id and glAccount from the reviewer's GL coding, which replaces the defaults set inside the orchestration.

Why Data Requests: they are plain table reads under the user's row security, they page (maxPageSize plus next-page calls), and they need no application security beyond the tables.

Alternative path: batch vouchers through the Z-files

JDE's documented interface for vouchers from outside is the batch pair F0411Z1 (voucher header and pay items) and F0911Z1 (distribution lines), processed by the Batch Voucher Processor R04110ZA. It is the right choice when volumes are high, when AP wants to review a batch before it becomes vouchers, or if the form-driven flow proves fragile across Tools updates.

1. The orchestration writes one F0411Z1 row and one or more F0911Z1 rows, through a form request on Batch Voucher Revisions (P0411Z1) or with Logic Extension table inserts.
2. R04110ZA runs in proof mode to validate and in final mode to create F0411 and F0911; errors go to the work center and the rows stay in the Z-tables for correction in P0411Z1. R0411Z1P purges processed rows.
3. The processor assigns the voucher number, so the orchestration can only return the transaction number; Core Invoice reads the voucher number later from F0411Z1 (processed flag 1, VLDOC) with a second orchestration.

Core Invoice supports this shape as push method Z-file: it sends F0411Z1-style keys plus the same lines[] and stores the returned EDI batch number. Columns the header row must carry:

Every F0911Z1 row repeats the header keys (user, batch, transaction, line) and names its account as VNANI, or VNMCU, VNOBJ and VNSUB with the account mode VNAM. A Report Request inside the orchestration can submit R04110ZA right after the insert, but it may return before the job finishes, which is why the voucher number is read back rather than returned.

Security and network

The integration is outbound only, from the Core Invoice backend to the JDE AIS server over HTTPS; JDE never calls Core Invoice.

• Credentials. The JDE user and password live on the Core Invoice connection, Fernet-encrypted at rest, never logged, decrypted only for the duration of a call. Only a company admin can create or edit a connection.
• Service account. Run pushes under a dedicated JDE user (for example COREINV) with application security limited to P0411, read access to the master-data tables above and run rights on the CI_* objects. Never a person's account.
• UDO security. An orchestration is callable only by users who may view and run it, so the service account must be granted the orchestrations explicitly once they are shared.
• Transport. TLS to your AIS server. Only /jderest needs to be reachable from Core Invoice; the HTML server and Orchestrator Studio can stay internal.
• Source address. Core Invoice calls out from a fixed address; ask Core Invoice support for the address to whitelist if your AIS server filters by source.
• Rate limits on the Core Invoice side: 20 pushes and 5 connection tests per minute per source address.
• Data sent to JDE. Vendor name and tax id, invoice number, dates, currency, amounts and line descriptions. No PDF or scan is sent in this version; the AIS media object service can attach the scanned invoice to the voucher later.

Implementation checklist

Going live takes one orchestration on the JD Edwards side and one connection on the Core Invoice side. The steps are listed in the order they are usually done.

JD Edwards administrator

1. Create the service account and grant it P0411, the master-data tables and, later, the CI_* objects.
2. Build the form request and orchestration described above in Orchestrator Studio, with defaults for company, supplier and expense account.
3. Run it once from Run Orchestrations and check the voucher in Supplier Ledger Inquiry (P0411).
4. Share the orchestration and grant the service account run rights on it.
5. Set the A/P constant "Duplicate Invoice Number Edit" to error, so a retried push can never create a second voucher.
6. Optional: build the Data Request orchestrations for suppliers, accounts and business units.

Core Invoice administrator

1. Add an ERP connection of type Oracle JD Edwards EnterpriseOne with the AIS URL, environment, service account, role and orchestration name from the authentication section, and click Test connection.
2. Push one reviewed supplier invoice by hand and confirm the voucher number appears on it.
3. Switch on auto-push on review once a few manual pushes have gone through.

Go-live checks

• Test connection succeeds with the service account.
• A manual push returns a voucher number and the voucher is visible in P0411.
• A deliberately wrong supplier number comes back as a readable error on the invoice.
• Auto-push is on and the first automatic push has been checked.

Appendix: endpoints and smoke tests

All calls are standard AIS services on Tools 9.2; nothing custom is installed on the AIS server, only the orchestration.

Smoke test from any machine that can reach the AIS server; replace the placeholders and let curl prompt for the password.

# 1. token (the device header must match step 3)
curl -u <user> -X POST https://<ais-server>/jderest/v2/tokenrequest \
  -H "Content-Type: application/json" -H "jde-AIS-Auth-Environment: <environment>" \
  -H "jde-AIS-Auth-Role: *ALL" -H "jde-AIS-Auth-Device: core-invoice"

# 2. the orchestration's contract, once it is saved
curl -u <user> https://<ais-server>/jderest/v3/open-api-catalog3/CI_AddSupplierInvoice

# 3. one voucher (TOKEN = userInfo.token from step 1)
curl -X POST https://<ais-server>/jderest/v3/orchestrator/CI_AddSupplierInvoice \
  -H "jde-AIS-Auth: $TOKEN" -H "jde-AIS-Auth-Device: core-invoice" \
  -H "Content-Type: application/json" \
  -d '{"invoiceNumber":"TEST-001","invoiceDate":"2026-10-27","currency":"USD","grandTotal":"100"}'

Sources

• AIS REST endpoints
• AIS authentication
• Token request v2
• Run an orchestration v3
• Discovering orchestrations
• F0411Z1 required fields
• F0911Z1 required fields
• Batch voucher process
• Accounts Payable orchestrations

Setting this up for a specific JDE environment? Talk to us and we will walk through the orchestration with your administrator.