Field-level sap business one data mapping for every B1 table — OCRD → Customers + Vendors split, OITM → Items, OINV → AR Invoices, OPCH → AP Invoices, OJDT → GL Journals, OACT → 6-segment COA. UDF/UDO routing built in.
B1 and Fusion solve the same business problem with completely different data shapes. The mapping is where most B1-to-Fusion projects spend three months of bespoke development.
SAP Business One stores customers, vendors, and leads in a single OCRD table. Oracle Fusion stores them as separate Trading Community Architecture entities — customers in HZ_CUST_ACCOUNTS, suppliers in POZ_SUPPLIERS_ALL_M. B1's OACT is a flat hierarchical chart of accounts whose implicit segmentation lives in account-code naming convention. Fusion's COA is six explicit segments with value sets. B1's UDFs are partner-named extensions in CUFD. Fusion's equivalents are DFFs or Application Composer custom fields. The sap business one data mapping work is to bridge every one of these shape differences — and there are dozens, not just six.
Without a purpose-built crosswalk engine, every shape difference becomes a multi-week negotiation: which OCRD CardTypes should be customers vs vendors vs both, how OACT codes should resolve into 6-segment COA, which UDFs should become DFFs vs Application Composer fields vs retire, how OJDT TransType should map to Fusion sub-ledger source, which OITM item groups should become Fusion item classes. Syntra ETL replaces that with versioned, signed-off crosswalks refined across dozens of B1-to-Fusion migrations. Each crosswalk is a YAML artefact that finance, operations, and IT can review and version-control.
The crosswalks are also data-driven: every OACT-to-6-segment mapping is cross-validated against OJDT/JDT1 posting patterns (postings that share segment positions should share business meaning). Every UDF disposition is cross-validated against frequency-of-use telemetry. Every OCRD de-duplication candidate is surfaced with similarity score and supporting evidence. The result is a sap business one data mapping that's defensible to internal audit, to the SAP Partner Edge partner being retired, and to the Oracle Fusion implementation team.
Pre-built crosswalks for every B1 → Fusion mapping. Configurable, version-controlled, audit-defensible.
CardType split (C/S/L), fuzzy-match de-duplication on tax ID + normalised name + address, FBDI Customer Import + FBDI Supplier Import in parallel, preserved cross-reference for consolidated trading-partner reporting post-migration.
Item-class mapping from OITB, costing-method preservation (Moving Average / FIFO / Standard), per-warehouse organisation assignment from OITW, UDF routing to DFFs, lifecycle inferred from OITM frozen/inactive flags.
Journal header + lines merged into Fusion GL_INTERFACE FBDI, OACT-to-6-segment COA crosswalk applied per line, TransType preserved as source category, BaseRef preserved as reference for sub-ledger drill-back.
AR invoice header + lines merged into AutoInvoice FBDI, customer linked to migrated HZ_CUST_ACCOUNTS, revenue-account routing through new 6-segment COA, full lifecycle preserved (open + closed periods).
AP invoice header + lines merged into AP Invoice Import FBDI, vendor linked to migrated POZ_SUPPLIERS_ALL_M, expense-account routing through new COA, PO match logic preserved where applicable.
Implicit segmentation analysis from account codes, cross-validated against OJDT/JDT1 posting patterns. Fusion 6-segment design proposal with explicit segment value sets and account-by-account mapping table signed off by finance.
A 2–3 week structured design process that produces versioned, signed-off crosswalks for every B1 → Fusion mapping.
Extractor profiles OCRD, OITM, OACT, OJDT/JDT1, OINV, OPCH, ORDR, OPOR, OINM. Row counts per table, distinct-value cardinality per column, UDF inventory from CUFD, UDO inventory from OUDO. Output: source profile report.
OACT account codes parsed for implicit segmentation. Cross-validated against OJDT/JDT1 posting patterns. Fusion 6-segment COA design proposed. Account-by-account mapping table drafted. Reviewed by controller for sign-off.
OCRD analysed by CardType. De-duplication candidates surfaced with similarity scores. Split rules drafted. Cross-reference design for trading partners appearing as both customer and vendor. Reviewed by sales + AP for sign-off.
Every CUFD UDF and OUDO UDO classified by frequency of use, business owner, dependent reports/Formatted Searches. DFF, Application Composer, OIC, or retire disposition assigned. Reviewed by business owners per UDF cluster.
All mappings codified as versioned YAML crosswalk artefacts. Item-class mapping, costing-method preservation, sub-ledger source mapping. Stored in source control. Validated by dry-run extract + transform without load.
Workshop with finance, operations, IT (4–6 hours). Crosswalks walked through field-by-field. Sign-off pack issued. SAP Business One data mapping locked. Execution phase begins with locked, audited mappings.
Every customer-specific extension has a Fusion destination. The disposition matrix is data-driven, not bespoke.
UDFs touched by daily user workflows or referenced by month-end reports. Default disposition: Fusion DFF on the corresponding entity. Preserves user behaviour without rebuild cost.
UDFs read or written by external systems via Service Layer or DI API. Default disposition: OIC-managed external attribute so the integration surface stays consistent during external-system rewire.
UDFs whose values gate approval routing, document statuses, or other workflow logic. Default disposition: Application Composer custom field plus BPM rule rebuild — too constraining for a plain DFF.
UDFs read only by Crystal/OTBI reporting. If the corresponding report is being retired, the UDF retires too. If the report is being rebuilt in OTBI/BI Publisher, the UDF lands as a DFF feeding the new report.
UDFs created at some point but never populated, or populated by a single departed employee. Default disposition: retire. Surfaces typically 20–40% of CUFD entries.
UDFs storing tax IDs, regulatory codes, or jurisdiction-specific attributes (e.g. SDI codes for Italian e-invoicing). Default disposition: DFF or native Fusion regulatory field, preserved across the migration with explicit audit annotation.
SAP Business One data mapping to Oracle Fusion is the field-level translation of B1's SMB-shaped tables into Fusion's enterprise-shaped entities. The most material mappings: OCRD (combined customer/vendor) splits into Fusion HZ_CUST_ACCOUNTS (customers) and POZ_SUPPLIERS_ALL_M (suppliers) by CardType. OITM (Item Master) maps to Fusion EGP_ITEMS_INTERFACE. OJDT (Journal Entries) header + JDT1 (Journal lines) merges into Fusion GL_INTERFACE. OINV (AR Invoices) + INV1 (lines) maps to Fusion's AutoInvoice tables. OPCH (AP Invoices) + PCH1 (lines) maps to Fusion AP Invoice Import. OACT (flat COA) collapses to Fusion's 6-segment COA. UDFs from CUFD route to Fusion DFFs or Application Composer custom fields. UDOs from OUDO route to OIC-managed external attributes. Each mapping is governed by a versioned crosswalk reviewed and signed off by finance and operations.
SAP Business One stores customers, vendors, and leads in a single OCRD table differentiated by CardType (C=customer, S=supplier/vendor, L=lead). Oracle Fusion separates these into HZ_PARTIES + HZ_CUST_ACCOUNTS for customers and POZ_SUPPLIERS_ALL_M for suppliers. The SAP Business One data mapping engine splits OCRD by CardType, then runs fuzzy-match de-duplication where the same legal entity (matching on tax ID, normalised name, address) appears as both customer and vendor — common in services and manufacturing SMBs. The result is two FBDI payloads (Customer Import and Supplier Import) emitted in parallel with a preserved cross-reference table so consolidated reporting on the same trading partner still works post-migration. Addresses from CRD1, contacts from OCPR, and payment terms from OCRD link consistently across both sides.
B1's OITM (Item Master) is a single table with denormalised attributes — item code, item name, item group (OITB), price list reference, costing method, default warehouse, dozens of UDFs. Oracle Fusion's item model is more normalised: items live in EGP_SYSTEM_ITEMS_B with item classes, primary unit of measure, lifecycle phases, item categories, and item-organisation assignments. The SAP Business One data mapping engine converts OITM to FBDI Item Import payloads with item-class mappings derived from OITB (Item Groups), unit-of-measure normalisation, costing-method preservation (Moving Average, FIFO, Standard), per-warehouse organisation assignment from OITW, and full UDF routing into DFFs or Application Composer custom fields. Item categories are derived from OITB plus configurable rules, and item lifecycle is set based on OITM frozen/inactive flags.
B1's OJDT (Journal Entry header) + JDT1 (Journal Entry lines) carry the GL posting record with full sub-ledger source tracing (TransType identifies the source — AR invoice, AP invoice, AR receipt, AP payment, etc., and BaseRef points back to the source document). Oracle Fusion's GL_INTERFACE is the FBDI Journal Import staging table that accepts header + line journal data with ledger, accounting date, source, category, and 6-segment account code. The SAP Business One data mapping engine merges OJDT/JDT1 into GL_INTERFACE format, applies the OACT-to-6-segment COA crosswalk per line, preserves TransType as the Fusion source category (so AP invoices land as 'Payables' source, AR receipts as 'Receivables' source, etc.), preserves BaseRef as the Fusion reference field for sub-ledger drill-back, and emits FBDI ZIPs ready for ESS submission.
B1's UDFs (User-Defined Fields) live in CUFD with a naming convention defined per-customer by the SAP Partner Edge partner. Typical patterns: U_VendorPrimaryContact, U_DiscountCategory, U_ProjectCode, U_RegionalSalesManager. Each UDF has a table reference (which delivered table it extends — typically OITM, OCRD, OINV, OPCH, OJDT, ORDR, OPOR), data type, validation list, and default value. The SAP Business One data mapping engine enumerates every CUFD UDF, joins to actual usage data to classify by frequency of read/update, and routes to one of: Fusion DFF on the corresponding entity (default for most UDFs), Application Composer custom field (when a DFF would be too constraining), OIC-managed external attribute (when the UDF is consumed by external systems that will remain), or retire (when the UDF is unused or duplicates native Fusion functionality).
B1's OACT is a single hierarchical table — typically 200–2,000 accounts — that uses a segment-style account code (e.g. 5100000000000001) but stores the segmentation implicitly rather than explicitly. Oracle Fusion's COA is a fixed 6-segment structure, commonly: Company, Cost Centre, Account, Product, Project, Intercompany. The SAP Business One data mapping engine parses OACT account codes to detect the implicit segmentation pattern, cross-validates against OJDT/JDT1 posting patterns to confirm the analysis (postings that share segment positions should share business meaning), proposes a Fusion 6-segment COA design with explicit segment value sets, and produces an account-by-account mapping table. Accounts that don't fit cleanly route to DFFs (rare) or analytical-only archive (occasional). The output is reviewed and signed off by finance before any FBDI load runs.
Yes — sub-ledger drill-back is preserved through Fusion's reference field. Every OJDT/JDT1 line carries TransType (identifying the sub-ledger source — 13=AR Invoice, 18=AP Invoice, 24=Incoming Payment, 46=Outgoing Payment, etc.) and BaseRef (pointing back to the source document — OINV.DocEntry, OPCH.DocEntry, ORCT.DocEntry). The SAP Business One data mapping engine preserves both fields in the Fusion-loaded journal: TransType becomes the Fusion source category, BaseRef becomes the Fusion reference field. Auditors clicking through a journal line in Fusion can trace back to the source document in archived B1 (via Syntra's archive query interface) for full retention-window audit support. For the AR/AP open invoices migrated forward into Fusion, the drill-back is to the migrated invoice in Fusion AR/AP directly.
Yes — multi-company consolidations (often M&A roll-ups where each acquired SMB ran its own partner-customised B1) are a first-class scenario. Each B1 company gets its own OACT analysis, its own OCRD split with cross-company de-duplication (the same vendor appearing in multiple acquired B1 instances de-duplicated to a single Fusion supplier with multiple BU assignments), and its own UDF/UDO inventory. A master consolidation crosswalk maps each company's OACT to a unified Fusion 6-segment COA, harmonises item codes (often each acquired B1 had its own item-coding scheme), and consolidates customer/vendor masters with controlled de-duplication. The output is a single coherent Fusion tenant with multiple BUs, each traceable back to the originating B1 company through preserved BU codes and reference fields.
Book a 60-minute walkthrough. We'll review your B1 OCRD/OITM/OACT/OJDT shapes against Fusion's enterprise model and produce a sap business one data mapping draft tailored to your modules, your UDF/UDO inventory, and your target Fusion COA design.