SAP Business One Load Automation for Oracle Fusion

SAP Business One load automation is the end-to-end pipeline that takes data extracted from B1 — via Service Layer REST, DI API, or direct HANA/SQL Server JDBC — applies all governed crosswalks (OCRD split, OACT-to-6-segment COA, UDF routing, OITM normalisation), emits FBDI ZIPs and REST payloads validated against the current Oracle Fusion 26x release schema, submits them to Fusion ESS, monitors completion, captures errors with row-level diagnostics, and reconciles loaded data to source at row, sum, and hash level. Load automation removes the bespoke scripting that consultant-led B1-to-Fusion projects spend weeks writing for every module. Each load runs from a configuration file, is repeatable, and produces signed audit evidence.

Extraction is multi-path and configurable per table. For master data (OCRD, OITM, OACT) — moderate row counts, frequent change — the default path is B1 Service Layer REST/OData, hitting endpoints like /BusinessPartners, /Items, /ChartOfAccounts with pagination and UpdateDate filtering for incremental delta. For high-volume historical tables (OJDT/JDT1, OINV/INV1, OPCH/PCH1, OINM) — millions of rows, append-mostly — the default path is direct HANA SQL or SQL Server JDBC against the company schema, parallelised by date partition. For tables where Service Layer has functional gaps, DI API (.NET COM) fills the gap. The same logical extractor abstracts the path; configuration chooses per-table strategy based on volume, currency of data, and customer's preferred read interface.

After extraction and transformation, the load automation pipeline emits FBDI ZIPs in the exact format Oracle Fusion ESS expects: CSV files with column ordering matching the current Fusion 26x template, ZIP packaging with manifest, file names matching the FBDI process name (SupplierImportTemplate.csv inside SupplierImport.zip, etc.). Every FBDI ZIP is validated against the current Fusion release schema before submission — column count, column ordering, mandatory field presence, value-set membership, foreign-key references to already-loaded master data. Validation errors are caught locally with row-level diagnostics, not at the Fusion ESS runtime 90 minutes into a 4-hour load. Each ZIP carries a SHA-256 hash signature and a manifest documenting source rows, transformation steps, and FBDI mapping.

Submission uses Fusion's ERP Integrations Service (the documented integration entry point that accepts FBDI ZIPs and triggers the corresponding ESS process — Load Interface File for Import, then the module-specific Import process). The load automation pipeline calls the ERP Integrations Service REST endpoint with the FBDI ZIP, polls the ESS process status until completion (Success, Warning, or Error), retrieves the ESS output log for any error rows, and triggers either the next FBDI in the dependency sequence (on success) or the error-triage workflow (on failure). Each submission is logged with submitter, timestamp, FBDI manifest, ESS process ID, completion status, and output log. The audit log is preserved for the lifetime of the migration.

Partner-built add-on data — values stored in UDFs, rows in UDOs, references in Formatted Searches, attributes in custom add-on tables — gets routed during load automation based on the disposition decisions made during data mapping. UDF values land in Fusion DFFs via FBDI DFF context segments (every FBDI template supports DFF columns), or in Application Composer custom fields via REST. UDO rows land as Fusion custom objects via Application Composer plus REST, or as OIC-managed external attributes if the UDO is being externalised. Formatted Search-driven attributes get computed at load time using the same rule definitions ported into a transformation step. Each routing decision is configuration-driven so add-on data flows through the same load automation pipeline as core data.

FBDI load failures fall into three categories, each with a documented recovery path. Validation failures (column count, mandatory field missing, value-set violation) are caught pre-submission so they never reach ESS — the row is logged with diagnostics and held back, the rest of the file submits, the failed rows are corrected via crosswalk refinement and re-emitted. ESS-time failures (foreign-key violations, accounting validation errors, business-rule violations) surface in the ESS output log; the load automation pipeline parses the output log, identifies failed rows by error code, routes them to a triage queue with named owners (finance for accounting errors, master data team for FK violations, etc.). Transient failures (network, ESS service unavailable) trigger automatic retry with exponential backoff. Every failure mode has a documented playbook.

Yes — multi-company consolidations are first-class. Each B1 company runs through its own extraction job with its own backend (HANA or SQL Server, sometimes mixed across companies in M&A roll-ups). Per-company crosswalks apply (each company's OACT mapped to the unified Fusion COA, each company's OCRD de-duplicated against the consolidated supplier/customer master). Per-company FBDI ZIPs are emitted with the target Fusion BU stamped on every row. Submissions are sequenced: master data for all companies loaded before transactions, intercompany trading partners de-duplicated across companies before AP/AR loads, balances loaded per-company per-BU. The unified Fusion tenant ends up with one BU per source B1 company, traceable back to the originating B1 via preserved reference fields.

Every load run produces a complete audit-evidence pack: source extract manifest with SHA-256 hashes per table per row, crosswalk version applied (UDF disposition, OACT mapping, OCRD split rules, item-class mapping), FBDI ZIP manifest with row counts and column-level checksums, ESS submission log with process IDs and completion timestamps, post-load reconciliation pack confirming row counts, sum totals, and hash signatures match across B1 source and Fusion target. The audit pack is structured to align with IRS, HMRC, German GoBD, French CGI, and Italian SDI retention requirements. Auditors examining a Fusion journal line can trace back through the FBDI manifest to the crosswalk, to the B1 source extract, to the OJDT/JDT1 source row — a full chain of custody for the lifetime of the retention window.