Infor BaaN to Oracle Fusion Data Mapping — Field-Level, Signed, Reconciled

Infor baan to oracle fusion data mapping is the field-level translation of every BaaN data element into its Oracle Fusion equivalent. For finance: tfgld GL columns (t$company, t$ledger, t$period, t$cacc, t$debt, t$cred, t$dim1–6) mapped to FBDI Journal Import GL_JE columns (LEDGER_NAME, ACCOUNTING_DATE, ENTERED_DR, ENTERED_CR, SEGMENT1–6). For AP: tfacp columns mapped to AP_INVOICES_INTERFACE. For items: tcibd mapped to ITEM Import. For suppliers: tccom (supplier flavour) with VAT-ID/IBAN routing into POZ_SUPPLIERS_INT. Every mapping is versioned, signed, and reconciled at row level. Syntra ETL's infor baan to oracle fusion data mapping ships pre-built crosswalks tested across BaaN IV / IVc4 / V deployments in EU manufacturing, ME industrial, and global aerospace/defence — saving 4–6 months of bespoke field-by-field mapping development.

BaaN's distinguishing feature is its dimension model: in addition to the GL account, every posting carries up to 6 dimension values (typically Cost Centre, Project, Reason, Item, Origin, plus a customer-defined slot). Oracle Fusion's COA is a fixed-segment structure — typically 6 segments (Company, BU, Cost Centre, Account, Product, Future). The Syntra ETL infor baan to oracle fusion data mapping engine walks BaaN dimension hierarchies, classifies values by frequency-of-use and analytical-importance, and maps them into Fusion segments without analytical-granularity loss. Where BaaN has more meaningful dimension values than Fusion segments can hold, Syntra recommends a DFF (descriptive flexfield) extension on the journal line to preserve the additional context. The mapping is workshopped with finance and signed off as part of the COA harmonization stage.

BaaN segregates data by t_fcom (financial company — a legal entity) and t_lcom (logical company — typically a consolidation grouping). A European manufacturer with 8 legal entities might run 8 t_fcom companies consolidated into 1–3 t_lcom groupings, with intercompany trade running through paired Sales/Purchase orders. The infor baan to oracle fusion data mapping engine translates this to Fusion's BU + Ledger architecture: each t_fcom becomes one Fusion legal entity with its own BU, mapped to one of (typically) 2–4 Fusion ledgers — a primary IFRS ledger for consolidation, a German HGB secondary ledger for statutory filing, plus optional country-specific local-GAAP ledgers. The mapping respects parallel ledger streams: every BaaN posting that flowed to both HGB and IFRS lands in both Fusion ledgers.

BaaN — for historical reasons rooted in Informix tradition — stores numeric fields in packed-decimal format with implicit decimal-place encoding defined in the table-column dictionary. A field declared as numeric(12,2) stores a different bit pattern than the Oracle/MS-SQL equivalent. The Syntra ETL infor baan to oracle fusion data mapping engine reads the BaaN column dictionary, decodes the packed-decimal storage natively, and re-encodes as IEEE float (or NUMBER with explicit precision) for FBDI loading into Fusion. Rounding rules are explicit and signed — typically banker's rounding (round-half-to-even) for currency amounts, preserving the BaaN total to the cent. Sum reconciliation per ledger per period vs the BaaN trial balance confirms no rounding loss.

BaaN item master (tcibd) carries product structure — item code, description, item type (manufactured, purchased, end-item, sub-assembly), unit of measure, classification group, costing method (FIFO, LIFO, standard, average), make-or-buy code, and the full set of dimension defaults. BaaN BOMs (tibom) carry the parent-child relationships with effective-from/to dates, position numbers, scrap percentages, alternate item codes. The infor baan to oracle fusion data mapping crosswalk translates tcibd into Fusion Item Import (INV_ITEMS_INTERFACE) with item categories preserved, costing method translated to Fusion's costing organization, lifecycle phase mapped, and DFFs carrying any BaaN-specific extensions. tibom translates to Fusion BOM Import with effective dates preserved, alternate items routed into Substitute Items, and quantity/scrap maths re-verified.

Yes — and for European customers this is non-trivial. BaaN sites in Germany run with HGB-compliant tax codes (Umsatzsteuer / Vorsteuer), reverse-charge handling for intra-EU B2B (§13b UStG), French TVA, Italian IVA, Dutch BTW, Spanish IVA — each with their own rates, ledger postings and statutory return implications. The Syntra ETL infor baan to oracle fusion data mapping engine catalogs every BaaN tax code in use, maps to Fusion tax regime / tax / tax status / tax rate / tax jurisdiction architecture, preserves the original BaaN tax code as a reference DFF for audit trace, and validates reverse-charge handling at the invoice level. The mapping is signed off by the finance and tax leads per country before any AP/AR data flows into Fusion.

Most BaaN customers have customized the GL posting layer with 4GL hooks — custom GL distribution logic, custom allocation rules, custom intercompany routing, custom currency revaluation. None of this 4GL code ports to Fusion. The Syntra ETL infor baan to oracle fusion data mapping engine reads every custom GL posting hook from the ttadv session catalog, classifies the business intent (special allocation, intercompany routing, statutory adjustment), and produces a rebuild recommendation: Fusion Distribution Sets for fixed-allocation rules, Subledger Accounting Rules (SLA) for derived posting logic, Allocations Manager for complex period-end allocations. The historical journal entries posted via those custom 4GL hooks load into Fusion as the final landed journals; the logic is rebuilt for the go-forward state.

Every Syntra ETL infor baan to oracle fusion data mapping engagement produces a versioned mapping book: one Excel workbook per business object (Journal, AP Invoice, AR Invoice, Supplier, Customer, Item, BOM, Production Order, Fixed Asset), with one row per source-target field pair. Each row shows: BaaN source table.column, sample values, business meaning, target Fusion FBDI/HDL column, transformation rule (direct, lookup, formula, default), validation rule, owner sign-off. The workbook is generated automatically from the executable crosswalks — so it never drifts from the actual transformation code. Auditor reviews the workbook and signs off; the workbook then becomes the contractual record of how every field was migrated, archived alongside the reconciliation pack.