Governed Infor LX (BPCS) to Oracle Fusion data mapping. Field-level crosswalks for every BPCS file (GLM, IIM, ECH, MHM, ACL, CIM, PSM, RTM and 100+ more), every UDF, every reference table — refined across dozens of conversions. EBCDIC, COMP-3 and CYYMMDD handled natively.
Most BPCS migrations don't slip in the extract or load. They slip in the field-by-field crosswalk where a 1980s IBM midrange data model has to be translated into Fusion's modern shape — one UDF, one BPCS file, one COMP-3 decimal-precision rule at a time.
Infor LX (BPCS) has accumulated 30+ years of layered data-model evolution since SSA shipped the original Business Planning and Control System for the IBM System/38 in the 1980s. The data model is wide — over 200 production files in active use across Financials, Manufacturing, Inventory, Order Management, Procurement and Fixed Assets — and deep, with every customer adding UDFs on the high-traffic files and shadow tables to capture local business context. Every field needs to be classified, every UDF needs to be reviewed, every reference table (CCM companies, MCM currencies, WHM warehouses, LOC locations, UOM units, AVL approved-vendor list) needs to be reconciled against the Fusion target.
On a consultant-led BPCS migration, the data-mapping exercise is a multi-month spreadsheet effort. Functional consultants interview BPCS power users to discover what each field actually means in business terms, technical consultants chase down which RPG programs read and write each field, compliance leads re-validate the mappings against retention policy, and the resulting mapping spreadsheets are rebuilt three times as new exceptions are discovered. The Infor LX (BPCS) to Oracle Fusion data mapping consistently consumes 4–6 months and 20–35% of the total project budget — most of which is rediscovery of crosswalks that have already been refined on every previous BPCS-to-Fusion conversion in the industry.
Syntra ETL fixes the rediscovery problem. The Infor LX (BPCS) to Oracle Fusion data mapping engine ships pre-built crosswalks for every standard BPCS file, every standard UDF pattern, every BPCS multi-company / multi-currency / multi-warehouse design pattern, and every BPCS module's specific decimal-precision and date-format conventions — refined across dozens of BPCS conversions. Your team validates the business-specific UDF mappings (typically 1–2 weeks per BPCS module) and confirms the Chart-of-Accounts target shape. The remaining 80% of the field-by-field crosswalk is delivered out of the box.
What Syntra ETL ships pre-built so your team only validates business-specific UDF mappings and the COA target.
BPCS Company (CCM) + ChartFields (GLM segments) → Fusion Legal Entity + 6–8-segment COA. Historical segment values preserved for retro-reporting on closed GL history. Inactive-segment rationalisation as part of mapping sign-off.
MCM currency master → Fusion Currencies. Historical translation rates on GLT/APH/RAH preserved through to Fusion Conversion Rate Type so retro-reporting reproduces the exact functional-currency amount BPCS originally posted, per-currency, per-period.
BPCS PSM/PSC → Fusion Item Structures; RTM/RTO → Fusion Work Definitions; MHM/MHD → Fusion Work Orders. Effectivity-date and engineering-change history preserved. Lot / serial traceability through BOM → work order → finished-good chain.
BPCS WHM warehouses → Fusion Inventory Organizations with consolidation logic (20–50 BPCS warehouses → 8–15 Fusion Inventory Orgs is typical). Historical IIH item-balance references both original BPCS warehouse and target Fusion Inventory Org.
Every UDF walked, scored on reporting-materiality, and routed to Fusion COA segments, Fusion DFFs on the matching entity (Item / Supplier / Customer / Project), or OTBI dimensions. Orphaned UDFs retired.
BPCS ACL supplier master → TCA Party / Supplier / Supplier Site hierarchy with deduplication (typical 30–50% duplicate suppliers consolidated). BPCS CIM customer master → TCA Party / Customer Account / Site Use hierarchy with address normalisation.
A repeatable, governed cadence. Typical full-scope mapping completes in 4–8 weeks for a customer who has done the assessment up-front.
Field-level crosswalk seeded from the Infor LX (BPCS) migration assessment output. Every BPCS file, every UDF, every reference table already inventoried — mapping engine consumes the assessment to produce a baseline crosswalk.
Finance, controlling and tax leads validate the target Fusion 6–8-segment COA shape. BPCS Company → Fusion Legal Entity + Ledger mapping locked. BPCS ChartFields → Fusion COA segments locked. Historical-segment-value file generated for retro-reporting.
Functional leads (supply chain for item master, procurement for supplier master, sales for customer master, manufacturing for BOM / routing) validate the master-data crosswalks. UDF reporting-materiality classification confirmed and signed off.
Functional leads validate the transactional crosswalks (GL transactions, AP vouchers, AR invoices, sales orders, purchase orders, work orders). Open-vs-closed cutover line for each transactional domain locked.
Full end-to-end mapping run on a representative scope (typically one company, one warehouse, one fiscal year). FBDI / HDL payloads generated, validated against Fusion 26x schemas, loaded to Fusion test environment, reconciled to the cent.
Mapping signed off by finance, manufacturing ops, supply chain, IT and compliance. Crosswalks locked in version-controlled repo. Ready for bulk migration runs against the locked mapping.
The Infor LX (BPCS) to Oracle Fusion data mapping produces auditable evidence at every step. No black-box transformations.
Every BPCS field on every BPCS file paired with target Fusion field, with transformation rule, decimal-precision handling and CCSID handling annotated. Signed off by functional leads per domain.
CCM companies → Fusion Legal Entities; MCM currencies → Fusion Currencies; WHM warehouses → Fusion Inventory Orgs; UOM units → Fusion UOM; AVL approved-vendor list → Fusion approved-vendor list. Each crosswalk versioned.
Every UDF with reporting-materiality score, routing decision (COA segment / DFF / OTBI dimension / retire) and sign-off owner. Routed UDFs traced to specific Fusion field. Retired UDFs traced to BPCS files where they will no longer be queried.
Inactive BPCS COA segment values preserved for retro-reporting on closed GL history. Mapped to historical Fusion segment values so closed BPCS periods can be queried in Fusion OTBI without losing the original segment shape.
End-to-end dry run reconciliation: BPCS trial balance vs Fusion trial balance to the cent, per-currency, per-period. AP aging vs aging. AR aging vs aging. Inventory value vs value per warehouse. Variance threshold zero.
Signed-off mapping spreadsheets per domain (Financials / Manufacturing / Inventory / Order Management / Procurement / Fixed Assets) plus version-controlled transformation rule repo ready for bulk migration.
Infor LX (BPCS) to Oracle Fusion data mapping is the field-by-field translation layer between the 1980s BPCS DB2-for-i data model and Fusion's modern Cloud ERP schema. It covers every BPCS file in scope (GLM, GLT, IIM, IIH, ECH, MHM, ACL, CIM, PSM, RTM and 100+ more), every field on every file, every BPCS reference table (CCM companies, MCM currencies, WHM warehouses, LOC locations), every UDF added since 1995, and every business rule embedded in RPG IV / III or COBOL programs that touches those files. The mapping output is a governed crosswalk spreadsheet plus executable transformation rules that turn EBCDIC-encoded, COMP-3 packed-decimal, CYYMMDD-zoned-decimal BPCS records into Fusion-ready FBDI / HDL / REST payloads. Syntra ETL ships the Infor LX (BPCS) to Oracle Fusion data mapping engine pre-built with field-level crosswalks refined across dozens of BPCS conversions — what's left for your team is validating business-specific UDF mappings and confirming the Chart-of-Accounts target shape.
BPCS Company (held in the CCM file) maps to Fusion Legal Entity + Primary Ledger (typically 1:1, though consolidations are common). BPCS ChartFields are held across GLM (chart master) and the segment values inside GLT, with BPCS supporting up to 8 segments depending on customer configuration. The Infor LX (BPCS) to Oracle Fusion data mapping engine produces a side-by-side ChartField-to-COA crosswalk: BPCS 'Company' segment → Fusion Legal Entity dimension or Company segment, BPCS 'Department / Cost Centre' → Fusion Cost Center segment, BPCS 'Account' → Fusion Natural Account, BPCS 'Product / Project' → Fusion Project or Product segment, BPCS 'Region / Geography' → Fusion Intercompany or geographic segment. Customers typically take the migration as an opportunity to rationalise the COA — collapsing inactive segment values, retiring orphaned cost centres and re-shaping the segment design for global consolidated reporting in Fusion. The crosswalk produces both the active-segment-value file (for Fusion FSM setup) and the historical-segment-value file (for retro reporting on closed BPCS history).
BPCS Warehouse (WHM file) maps to Fusion Inventory Organization. BPCS Location within a warehouse (LOC file, with location-type, aisle, bay, shelf, bin attributes) maps to Fusion Subinventory + Locator. Customers running 20–50+ warehouses across multiple legal entities in BPCS routinely consolidate to 8–15 Fusion Inventory Organizations during the migration without losing transaction-level traceability — the consolidation is captured in the Infor LX (BPCS) to Oracle Fusion data mapping rules so historical IIH item-balance records reference both the original BPCS warehouse code and the target Fusion Inventory Organization. Lot and serial detail is preserved on the IIM item master and IIH balance records through to Fusion's lot / serial control structures. Cycle-count and physical-inventory history is migrated where Fusion has equivalent native audit, archived otherwise.
BPCS IIM holds 200+ fields per item across costing, planning, manufacturing, purchasing, sales and accounting facets. The Infor LX (BPCS) to Oracle Fusion data mapping engine routes IIM fields to the Fusion Item Master across multiple specifications: Inventory specification (UOM, lot / serial control, cycle-count class), Purchasing specification (default supplier, list price, lead time), Costing specification (standard cost, average cost, costing method per Inventory Org), Sales specification (sellable flag, price list assignment), Planning specification (MRP planning method, safety stock, lead times), Manufacturing specification (BOM type, routing assignment). BPCS UDFs on IIM (custom fields added through the LX customisation framework — typically 5–30 per customer) route to Fusion Item DFFs or to OTBI dimensions per the materiality classification done in the assessment. The mapping handles the BPCS UOM file (UOM) including conversion factors and class-of-trade alternates.
BPCS multi-currency is held in three places: MCM currency master (currency codes, decimal precision, rate-type definitions), the in-flight translation rate stamped on each GLT, APH and RAH transaction (so each historical transaction carries its own original functional-currency amount), and the period-end rate tables used for revaluation. The Infor LX (BPCS) to Oracle Fusion data mapping engine preserves all three. MCM currency codes map to Fusion Currencies (with the ISO 4217 normalisation applied where BPCS used non-standard codes). The transaction-level historical rates carry through to Fusion's Conversion Rate Type structure so retro-reporting on closed BPCS GL history reproduces the exact functional-currency amount BPCS originally posted. Period-end rate tables migrate to Fusion's daily rate tables. Customers with 10+ currencies and 20+ years of history routinely complete the Infor LX (BPCS) to Oracle Fusion data mapping with full per-currency, per-period trial balance reconciliation to the cent.
BPCS Supplier Master (ACL file) maps to Fusion Trading Community Architecture (TCA) Supplier + Supplier Site model, with the BPCS one-flat-file structure expanded into TCA's Party / Supplier / Supplier Site / Site Assignment hierarchy. BPCS Customer Master (CIM file) maps to TCA Party / Customer Account / Customer Account Site / Site Use model. The Infor LX (BPCS) to Oracle Fusion data mapping engine handles the structural expansion (one BPCS ACL row → one Party + one Supplier + one or many Supplier Sites depending on remit-to / ship-from variants), the deduplication (BPCS often has 30–50% duplicate suppliers / customers accumulated over decades that the migration is the right moment to consolidate), the address normalisation (BPCS free-text address fields → Fusion validated address components with country / state / postal validation), and the contact-and-banking detail migration (with EFT / ACH / wire-transfer banking detail brought across to Fusion Payments).
BPCS Manufacturing uses a distinct data model from Fusion's. BPCS BOMs are held in PSM (bill master) and PSC (component) with the BOM keyed by parent-item + effectivity-date. BPCS Routings are held in RTM (routing master) and RTO (operation), with each routing keyed by item + alternate + effectivity-date. BPCS Work Orders are held in MHM (header) and MHD (detail), with shop-floor hours posted to HRM. Fusion Manufacturing uses Item Structures (replacing PSM/PSC), Work Definitions (replacing RTM/RTO/PSM combined), and Work Orders with operation transactions. The Infor LX (BPCS) to Oracle Fusion data mapping engine translates BPCS PSM/PSC → Fusion Item Structure with effectivity-date preserved, BPCS RTM/RTO → Fusion Work Definition operations with resource and overhead mapping, BPCS MHM/MHD → Fusion Work Order with operation transactions and component issues. Engineering-change history (BPCS ECN files) is preserved. Lot / serial traceability is maintained through the full BOM → work order → finished-good chain.
BPCS UDFs (User-Defined Fields added through the LX customisation framework) are the BPCS equivalent of Oracle EBS DFFs or PeopleSoft ChartFields — extra fields bolted onto core BPCS files to capture business-specific context. Customers typically have 5–30 UDFs per file on the high-traffic files (GLM, IIM, MHM, ECH, APH, RAH, ACL, CIM). The Infor LX (BPCS) to Oracle Fusion data mapping engine walks every active UDF, scores it on reporting-materiality (does it drive a material split in any report finance signs off on?), and routes accordingly: material UDFs collapse into Fusion COA segments (if it's a GL UDF driving a reporting split), Fusion DFFs on the matching entity (if it's an item / supplier / customer / project attribute), or OTBI dimensions if it's an analytical-only attribute. Orphaned UDFs (no data, never queried) get retired. The mapping is signed off by finance and analytics before any data flows.
30-minute call. We'll walk through your BPCS modules, UDF design, multi-company / multi-warehouse layout, target COA shape and historical retro-reporting needs — and have a baseline crosswalk ready for your functional leads within a week. No RPG developer required on your side.