Oracle JD Edwards and TaxJar integration

What moves between them

Sales orders and line items flow from JD Edwards into TaxJar. After each order is confirmed in JD Edwards, ml-connector polls the F4301 and F4311 tables, extracts the ship-to customer address and line-item amounts, and sends the complete transaction to TaxJar's POST /transactions endpoint, including nexus state and customer exemption status. TaxJar responds with the calculated tax amount for that order. If an order is updated or cancelled in JD Edwards, ml-connector detects the change on the next poll and updates the transaction in TaxJar via PUT. Customer and item master data is synced from JD Edwards to TaxJar on a configurable schedule so tax categories in TaxJar match the product codes and customer exemption flags in JD Edwards.

How ml-connector handles it

ml-connector stores the JD Edwards AIS Server host URL and credentials encrypted, obtains a session token before each data service call, and re-authenticates if a 444 (invalid token) response is received. For TaxJar, it stores the API key encrypted and sends it in every request header. The connector polls JD Edwards F4301 and F4311 tables on a cron schedule you define, tracking the last-polled timestamp to avoid re-processing. It maps JD Edwards customer addresses and exemption flags to TaxJar transaction fields, then submits to TaxJar's /transactions endpoint. If TaxJar returns 422 (transaction exists), ml-connector falls back to PUT to update it. JD Edwards token timeouts trigger re-authentication on the next request. AIS Server pagination is handled by checking the moreRecords flag and calling /jderest/v2/dataservice/next for continuation. TaxJar rate limits are not strict on transaction endpoints, but the connector includes exponential backoff on any 429 response. Every record carries source ID, timestamp, and sync status in an encrypted audit log.

A real-world example

A regional e-commerce business runs JD Edwards EnterpriseOne for order management and GL accounting, and operates in nine states with varying sales tax rates and nexus rules. Before integration, the finance team exported order summaries from JD Edwards weekly, manually looked up tax rates in each state, then posted the liability totals to the GL. During peak seasons this process lagged, and reconciliation between JD Edwards revenue and the tax filing became a month-end nightmare. With JD Edwards and TaxJar connected, every order is transmitted to TaxJar in real time, tax is calculated by state, and the GL liability is updated automatically. The finance team now publishes tax filings in half the time, with zero manual lookups.

What you can do

• •Send completed sales orders and line items from JD Edwards to TaxJar for real-time tax rate calculation and state nexus validation.
• •Sync customer master records and exemption status from JD Edwards to TaxJar so that exempt customers are reported correctly.
• •Automatically detect and report order updates or cancellations in JD Edwards back to TaxJar to keep transaction status in sync.
• •Bridge JD Edwards session tokens and TaxJar API keys, re-authenticate on token timeout, and handle both platforms' pagination.
• •Poll JD Edwards on a schedule you control, with automatic retry on network failure and a full audit trail on every transaction.

Questions

Does the integration send real-time tax calculations back to JD Edwards?

No. ml-connector reads orders from JD Edwards and sends them to TaxJar for tax calculation and reporting, but does not write tax amounts back into JD Edwards. The connector maintains an audit log of what was sent and what TaxJar calculated, so you can review and post adjustments manually if needed. This design keeps JD Edwards as the source of truth for revenue and avoids re-keying.

How does ml-connector handle JD Edwards session tokens that expire after 30-60 minutes?

ml-connector caches the JD Edwards session token and monitors for 444 (invalid token) responses from the API. On token expiry, the next API call fails with 444, and ml-connector immediately re-authenticates using the stored username and password to obtain a new token and retry the request. This happens transparently; no manual intervention is needed.

What happens if TaxJar says an order already exists when ml-connector tries to POST it?

TaxJar returns 422 (unprocessable entity) if a transaction with the same ID already exists. ml-connector detects this and falls back to a PUT request to update the transaction instead. If the PUT returns 404 (not found), the connector falls back to POST to create it. This pattern ensures the transaction is created or updated without failure.