Skip to content
PlaidCloud

Oracle Fusion: Post Journal Entry

Description

Section titled “Description”

Posts general ledger journal batches to Oracle Fusion Cloud over your Oracle Fusion connection, routed through PlaidCloud’s shared ERP write pipeline. The step takes a header table (one row per batch) and a lines table (one or more rows per batch), writes each batch to Oracle’s GL_INTERFACE staging table as an FBDI file, and submits the Journal Import Launcher Enterprise Scheduler Service (ESS) job. Validate Only builds and checks every batch without a ledger claim and without posting; an optional result table records the outcome of each batch.

Configuration

Section titled “Configuration”

Connection

Section titled “Connection”
  • Fusion Connection — the Oracle Fusion connection to post through.

Data

Section titled “Data”
  • Header Table — one row per batch: batch_id (your batch identifier, required), ledger_id (required), journal_source, journal_category, accounting_date, description.
  • Lines Table — one or more rows per batch_id: account_combination (or its segment columns), entered_debit, entered_credit, currency_code.
  • Result Table — output table id: one row per batch with batch_id, natural_key, confirmation_id, status (posted/validated/error), message.
  • Validate Only — checked by default. Preflight only; no ledger claim, no post. A step configuration that omits this field entirely — for example one authored through the REST API, MCP, or a workflow bundle import — also defaults to Validate Only rather than a live post.
  • Continue On Error — checked by default. Keeps posting the remaining batches after one fails; unchecked stops the run at the first failure.

How Posting Works

Section titled “How Posting Works”

PlaidCloud loads each batch into Oracle’s GL_INTERFACE staging table via an FBDI file, then submits and polls the Journal Import Launcher ESS job until it reports a terminal state. A batch is only reported posted once that terminal state is confirmed — a batch that lands in the interface table but whose import job never resolves stays quarantined (not reported posted, not silently dropped) rather than being recorded as success on the strength of the staged data merely existing.

Correcting a Posted Entry

Section titled “Correcting a Posted Entry”

This step never deletes or rewrites a posted journal batch. To correct one, post a new batch with debits and credits swapped against the original — a posted reversing entry — rather than editing the original in place.

Capability Limits

Section titled “Capability Limits”

| Limitation | What it means | |—|—|| ESS job latency | The Journal Import Launcher runs as a scheduled job — expect a posting run to take materially longer than a direct API write. | | Reversal is a new batch, not an in-place edit | Corrections post a new debit/credit-swapped reversing batch. There is no void or delete of an already-posted batch. |

Section titled “Related”