Oracle JD Edwards and Dayforce integration

What moves between them

The main flow runs from Dayforce into JD Edwards. After each payroll run, ml-connector reads Dayforce employees and payroll journals, transforms them into JD Edwards batch GL entry format, and imports the batches into the F0911Z1 Journal Entry Batch table, where they land in the GL posting queue. Employee records flow from Dayforce into the JD Edwards Address Book (F0101) so headcount counts, hire dates, and termination dates stay aligned. Cost allocation and GL account mappings are configured per customer, so each payroll line maps to the correct GL account and cost center in JD Edwards. The sync runs on a cadence tied to your payroll schedule, typically weekly or bi-weekly.

How ml-connector handles it

ml-connector maintains separate credential sets for JD Edwards and Dayforce. For JD Edwards, it acquires a session token at the start of each sync and caches it for the duration, then requests a fresh token before the 30-60 minute window expires or if the API returns HTTP 444 (invalid token). Pagination is handled transparently using the moreRecords flag and POST /jderest/v2/dataservice/next for record continuation. For Dayforce, ml-connector requests an OAuth 2.0 Bearer token at the start of each sync and refreshes it proactively before the one-hour expiry, checking the token payload claim (exp) to avoid HTTP 401 on the last few API calls. The client-specific API URL is fetched from /V1/ClientMetadata and cached overnight, reducing redirect overhead. Payroll GL journals read from Dayforce are mapped against a master GL account concordance table configured per customer, and only records matching valid GL accounts and cost centers in JD Edwards are included in the batch. Invalid records are logged and skipped with an alert so the customer can resolve the mapping and retry. The Journal Entry batch is submitted to JD Edwards as-is without field-level validation; JD Edwards' own batch posting process applies its business rules on import. Every record carries an audit trail with sync timestamp, source record ID, and any validation errors, so a failed batch can be rerun once the blocking issue is fixed. IP allowlists at JD Edwards customer sites are whitelisted during deployment setup. For test deployments, Dayforce sandbox (DDN) is used, with full awareness that PATCH and POST calls return 200 but do not persist data.

A real-world example

A mid-sized manufacturing company with two plants and a head office runs JD Edwards EnterpriseOne on-premises for all financials, GL, and procurement. They use Dayforce Workforce Now for payroll and benefits administration across 500 employees. Before the integration, the accounting team exported a payroll GL register from Dayforce every two weeks, then manually re-entered the labor cost lines into JD Edwards' GL batch entry system, a process that took 4-6 hours and introduced transcription errors that were caught during month-end close. With Oracle JD Edwards and Dayforce connected, the payroll GL journal posts into JD Edwards automatically on payday, allocated to the correct cost centers for each plant, and the accounting team runs month-end close knowing the labor accounts are complete and correct from the start.

What you can do

• •Post Dayforce payroll GL journals into JD Edwards' journal entry batch table (F0911Z1), allocated to the correct GL accounts and cost centers.
• •Keep JD Edwards employee records in the Address Book (F0101) synchronized with Dayforce hires, terminations, and status changes.
• •Authenticate JD Edwards with session tokens against a customer-hosted AIS Server, with automatic re-authentication before token expiry.
• •Authenticate Dayforce with OAuth 2.0 Resource Owner Password Credentials, refreshing hourly, and fetch the client-specific API URL daily to minimize redirect overhead.
• •Poll both systems on a payroll schedule with a full audit trail on every record, so failed batches can be investigated and replayed.

Questions

How does ml-connector handle JD Edwards session tokens and pagination?

ml-connector acquires a session token at the start of each sync by posting to the /tokenrequest endpoint with credentials, then caches the token and reuses it until the API returns HTTP 444 (invalid token) or the default 30-60 minute window is about to expire. For pagination, it uses the moreRecords flag returned by the API and calls POST /jderest/v2/dataservice/next to fetch continuation pages, handling all pagination transparently.

Does the integration work with on-premises JD Edwards behind an IP allowlist?

Yes. ml-connector can operate behind customer firewalls as long as the connector egress IPs are whitelisted at the customer JD Edwards site during deployment setup. The AIS Server URL is provided as a customer credential, and the connector connects directly to that URL using the session token flow.

What happens if a Dayforce payroll line does not map to a valid JD Edwards GL account or cost center?

ml-connector skips the unmapped line, logs it with the source GL account and reason, and alerts the customer so they can update the GL account concordance mapping in the connector configuration. Once the mapping is corrected, the sync can be re-run to include the previously skipped records.