FBDI loads move data through three stages: a spreadsheet template generates a CSV, the file is uploaded and loaded to interface tables, then an import process validates and moves it into application tables. Failures at each stage report in different places, and the most common mistake is checking the upload result rather than the import process output where validation errors actually appear.
What problem does this solve?
A load reported as successful that produced no records is the classic confusion. The file loaded to the interface tables correctly, but the import process rejected every row on validation.
Partial loads are worse, because some records import and others reject, leaving an inconsistent state that is easy to miss without reconciling counts.
Template version mismatches cause failures that look like data problems. Templates are release-specific, and a template from a previous release can produce columns the current import does not expect.
How the solution works
We reconcile counts at every stage — rows in the file, rows in the interface, rows imported, rows rejected — so a partial load is visible immediately rather than at reconciliation.
Errors are read from the import process output, which names the row and validation, rather than inferred from the upload confirmation.
- 1Download the FBDI template for your current release rather than reusing an older one.
- 2Check required columns, date formats and code values against the target setup before generating the CSV.
- 3Record how many rows entered the interface tables.
- 4The import process output names rejected rows and the validation that failed.
- 5Compare file rows, interface rows and imported rows; any difference is rejections to work.
- 6Fix the rejected subset and reload it rather than reloading the whole file.
Limitations & prerequisites
- Reloading a full file after a partial success creates duplicates unless the import handles them, so reload only the rejected subset.
- FBDI templates are release-specific and change between updates; retaining old templates causes failures that appear to be data problems.
- Interface tables retain rejected rows until purged, and old rejects can be picked up unexpectedly by later runs.
- ADFdi depends on a desktop Excel integration that is sensitive to Office versions and macro settings, which makes it fragile for large or repeated loads.
- Large volumes may need to be split into batches; a single very large file can time out without a clear error.
FAQ
Most often a validation failure on data referencing setup — an invalid code, a date format the import does not accept, a missing required column, or a template from a different release. The import process output names the failing row and reason.
In the output of the import process, not the file upload confirmation. The upload only reports that the file reached the interface tables; validation happens afterwards, and that is where rows are actually rejected.
The upload succeeded and the import rejected every row. These are separate stages with separate outputs. Always reconcile the imported row count against the file row count rather than trusting the upload message.
Only the rejected subset. Reloading the full file after a partial success creates duplicates unless the import specifically prevents them, and cleaning up duplicated master data is considerably harder than reloading rejects.
For every release, yes. Templates are release-specific, and using an old one produces column mismatches that look like data errors and waste a lot of diagnostic time.
FBDI for volume and repeatable loads; ADFdi for smaller interactive corrections. ADFdi depends on a desktop Excel integration that is sensitive to Office configuration, which makes it unsuitable as a bulk migration mechanism.
Tell us the module, the release and the exact symptom.
Send the module in scope, your Fusion release or EBS version, and the exact error text or symptom with a screenshot where you have one. We reply with a written assessment: the likely cause, what we would check first, and whether it is a configuration fix, a data fix, or a defect that needs an Oracle service request. When Swedish Technology can help, we scope the remediation with effort and sequence before you commit to anything.
Request an Oracle AssessmentSources & evidence
- Oracle Help Center — Cloud Applications documentation — module setup, subledger accounting and period-close reference
- Oracle Help Center — all product documentation — database, middleware and infrastructure reference used for error diagnosis
- My Oracle Support — patches, known-issue notes and service requests; Oracle account required
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.