Oracle EBS and Fusion¶
Applies to: e-Invoice · e-Way Bill · Which modules do I have?
Purpose¶
Connect Oracle E-Business Suite or Oracle Fusion to Complifly: where to trigger, which Oracle structures supply the required fields, the traps specific to Oracle's organisation model, and how outcomes return.
Audience¶
Oracle integration developers and implementation consultants.
Prerequisites¶
- The Integration Pattern — read first
- Oracle developer effort allocated
- Sandbox credentials
- Raw sample output per transaction type
Verify: Whether Complifly supplies an Oracle connector or this is a pattern you implement is not established here. Recorded as assumption F1 in the Assumptions Register.
Steps¶
1. Choose the trigger¶
| Option | Suits | Note |
|---|---|---|
| On completion of the receivables transaction | Most implementations | Fires when the transaction is final |
| Through the integration cloud service | Fusion, and EBS landscapes with it | Retry and monitoring already provided |
| Scheduled extract | Lower volume or batch-oriented operations | Rejections discovered later |
Trigger on completed transactions only. An incomplete transaction can still change; a registered document cannot.
2. Source the required fields¶
| Complifly needs | Typically from |
|---|---|
| Document number and date | Transaction number and date |
| Document type | Transaction type, through a lookup |
| Supplier registration | The legal entity or operating unit's tax registration |
| Buyer registration and address | Customer account and site tax profile |
| Place of supply | Determined in Oracle; a tax position |
| Values | Transaction totals |
| Line details | Transaction lines |
| Classification codes | Item master or a transaction descriptive flexfield |
Once you know where each value lives, build the translation in the product rather than in ERP code: Build a Mapping Template walks through creating the template, loading these fields from a sample, and dragging them onto their NIC counterparts with the right direct, date or lookup rule.
3. Handle the Oracle traps¶
| Trap | Symptom | Fix |
|---|---|---|
| Legal entity versus operating unit | Wrong supplier registration | Establish which carries the tax registration in this configuration. Oracle allows both patterns |
| Multi-organisation access control | The extract returns nothing, or too much | Confirm the extract runs in the correct organisation context |
| Transaction type variety | Documents route wrongly | Map every transaction type explicitly; avoid a permissive default |
| Descriptive flexfields | Required data absent | Classification codes and similar frequently live in flexfields. Include them |
| Tax lines separate from item lines | Line totals wrong | Map item lines and their tax correctly; do not treat a tax line as an item |
| Adjustments and credit memos | Wrong document type | Map to credit or debit notes explicitly |
| Numbering per transaction source | Duplicate rejections | Confirm uniqueness per registration per financial year across all sources |
The organisation-model trap is the one that costs most time. Two Oracle implementations of the same size can carry the registration in different places, so it must be established for this configuration rather than assumed.
4. Return the outcome¶
Store the reference number and acknowledgement against the transaction — commonly in a descriptive flexfield or a companion table. Store the signed QR where printing happens in Oracle.
Consume the write-back feed on a schedule. Do not block transaction completion on an external call.
5. Handle rejections visibly¶
Provide a report or notification a person reviews daily. Oracle has no built-in queue for this, and a rejection stored in a flexfield nobody opens is a document that never becomes compliant.
Validation¶
| Check | Method | Pass condition |
|---|---|---|
| Correct registration | Send from each legal entity or operating unit | Correct supplier registration each time |
| Organisation context correct | Run the extract | Returns exactly the intended transactions |
| Transaction types map | Send one of each in use | Each routes correctly |
| Flexfield data carried | Inspect the mapped payload | Present |
| Line and tax handling correct | Compare against the Oracle transaction | Exact match |
| Credit memos map correctly | Send one | Routes as a credit note |
| Incomplete transactions excluded | Create one | Not sent |
| Numbering safe | Review sources across years | No possibility of collision |
| Outcome reaches Oracle | Complete one end to end | Reference number against the transaction |
| Printing works | Print, if printing in Oracle | Signed QR scans from paper |
| Rejections visible | Force one | A person sees it the same day |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| Wrong supplier registration | Sourced from the wrong organisation object | Confirm whether the legal entity or operating unit carries it here |
| Extract returns nothing | Organisation access context wrong | Set the correct context for the extract |
| Extract returns other organisations' transactions | Context too broad | Narrow it. This is also a data-segregation concern |
| Documents route wrongly | Transaction type unmapped, default guessed | Map every type explicitly |
| Required field empty | It lives in a flexfield not included | Include the flexfield |
| Line totals wrong | Tax lines treated as item lines | Correct the mapping |
| Duplicate rejections | Numbering overlaps across transaction sources | Make numbering unique per registration per year |
| Incomplete transactions registered | Trigger fires too early | Trigger on completion only |
| Reference number never returns | Write-back not consumed | Check the flag, subscription, then the consumer |
| Rejections accumulate unseen | No report or notification | Build one and assign an owner |
Related Articles¶
- Build a Mapping Template — the field mapping, screen by screen
- The Integration Pattern — everything common
- Mapping Templates API
- Custom ERP
- Ingest Failures