Post-load Infor LX (BPCS) data validation that proves every BPCS record extracted from IBM i made it into Oracle Fusion correctly. Counts, sums, hashes, business rules and audit-trail continuity — reconciled per company, per period, per currency, signed for internal audit and SOX.
A BPCS migration that ships with silent data corruption is discovered three months later when year-end audit fails. By then it's a re-implementation, not a fix.
BPCS has spent 30+ years storing data in formats that don't survive translation cleanly without rigorous validation. COMP-3 packed-decimal numerics encode each digit in half a byte and rely on precision metadata held in the BPCS file's record-format definition — get the precision wrong by one place and a multi-million-dollar GL balance is off by orders of magnitude. EBCDIC character data depends on the CCSID configured at the IBM i job, file or field level — confuse 037 (US English) with 1140 (US English Euro-enabled) and a euro-symbol in a customer name becomes a control character. CYYMMDD zoned-decimal dates use a century-flag in the leading digit that no modern parser handles by default — read it wrong and dates jump 100 years. None of these issues throw runtime errors; they just produce subtly wrong data that ships to production.
Add the layered complexity of BPCS multi-currency (with historical translation rates stamped on each transaction so retro-reporting reproduces the exact functional-currency amount BPCS originally posted), multi-company intercompany balances that must net to zero per pair per period, lot / serial traceability that must carry through unbroken from manufacturing to inventory to shipment, and the SOX / FDA audit-trail chain that links every Fusion GL journal back to the originating RPG program execution on the AS/400 — and the validation surface area expands rapidly. Doing it manually in Excel is impractical at any non-trivial scale.
Syntra ETL's Infor LX (BPCS) data validation engine runs every reconciliation class — counts, sums, hashes, business rules, audit-trail continuity — automatically in parallel with the FBDI / HDL load. Variances surface at row-level within 5–15 minutes of load completion. Internal audit signs off the reconciliation pack directly. The pattern is the same whether the customer is doing a big-bang full-scope cutover, a Financials-first phased migration, or a long parallel-run window where BPCS continues taking transactions for 1–2 month-end close cycles while Fusion is validated to the cent.
Every reconciliation class runs automatically in parallel with the FBDI / HDL load. Variances surface at row-level within minutes.
Source BPCS GLT row count, APH voucher count, RAH invoice count, IIM item count, PSM BOM count, MHM work-order count, ECH order count, HPO PO line count vs Fusion-loaded counts per company per period. Variance threshold zero.
Functional-currency debits / credits, AP balance, AR balance, inventory value per warehouse, work-order WIP balance, multi-currency historical-rate-translated amounts — reconciled per company per period. Variance flags surface before any subsequent load is allowed.
Every BPCS record content-hashed at source (SHA-256 over canonical UTF-8 representation with COMP-3 unpacked, CYYMMDD normalised, EBCDIC translated) and re-hashed post-Fusion-load. Mismatch surfaced with row-level byte-diff.
Multi-company intercompany balance to zero. Period-closure consistency. Lot / serial traceability unbroken. AP three-way-match status preserved. Work-order WIP balanced. Each check produces a sign-off line on the reconciliation pack.
BPCS GLAT / APAT / RAAT / IIAT / MHAT audit-trail record counts reconciled between source and BPCS long-term archive. IBM i journal entry counts per period reconciled between source IBM i journals and migration evidence pack.
Per-currency, per-period functional-currency amount reconciled between BPCS GLT and Fusion equivalent. Historical translation rates verified. Period-end revaluation amounts confirmed. Customers with 10+ currencies routinely pass to the cent.
Every load run, every phase, every cutover. Same workflow, same evidence pack, same sign-off cadence.
BPCS extract from DB2 for i produces a signed manifest with record counts, sum totals and hash signatures per BPCS file per partition. IBM i journal sequence number stamped on manifest for delta-replay reconciliation.
Crosswalks applied, FBDI / HDL payloads generated, validated against current Fusion 26x release schemas. Pre-load count / sum / hash projection generated for comparison against post-load actuals.
FBDI ZIPs submitted to Fusion ESS, monitored to completion. Load-result reports captured. Fusion-side counts captured directly from Fusion's underlying tables via REST API or SQL.
Validation engine runs all six reconciliation classes in parallel: counts, sums, hashes, business rules, audit-trail continuity, multi-currency. Typically completes within 5–15 minutes of load completion.
Any variance surfaced at row-level with specific BPCS source record, specific Fusion validation error, suggested fix, and bulk-fix queue. Re-runs are scoped to the variance set — no full reload required.
Signed timestamped reconciliation pack issued: trial balance BPCS vs Fusion to the cent, AP aging vs aging, AR aging vs aging, inventory value vs value per warehouse, audit-trail continuity proof. Internal audit signs off directly.
Signed evidence that satisfies finance, internal audit, external audit, SOX testers and FDA Part 11 reviewers.
BPCS trial balance per period per company per currency vs Fusion trial balance, drillable to GL line, AP voucher, AR invoice and originating BPCS audit-trail record. Variance threshold zero.
BPCS AP aging vs Fusion AP aging per supplier per currency. BPCS AR aging vs Fusion AR aging per customer per currency. Open-item-level reconciliation with supplier / customer drill-down.
Inventory value per warehouse per item per period reconciled between BPCS IIH and Fusion Inventory. Lot / serial detail spot-checked at item level. Cycle-count and physical-inventory history reconciled where carried through.
BPCS work-order WIP vs Fusion work-order WIP per Inventory Org. BOM / routing structure spot-checked per item. Engineering-change history continuity verified.
Per-currency, per-period functional-currency amount with historical translation rate preserved. BPCS multi-company intercompany balance net-to-zero verified.
Per-record hash signature pairs (source BPCS hash, post-Fusion-load hash) for spot-audit verification. Hash drift flagged at row-level with byte-diff. Provably complete sample.
Infor LX (BPCS) data validation is the post-load reconciliation layer that proves every BPCS record extracted from IBM i / DB2 for i made it into Oracle Fusion correctly, completely and with full audit-trail context preserved. It covers four reconciliation classes: record counts (every GL line, AP voucher, AR invoice, item, BOM, work order, sales order, PO line, inventory balance row), sum totals (functional-currency debits / credits, AP balance, AR balance, inventory value per warehouse, work-order WIP balance), hash signatures (every BPCS record content-hashed at source, re-hashed post-Fusion-load to catch EBCDIC mistranslation or COMP-3 precision loss) and business-rule consistency (multi-currency historical-rate carry-over, lot / serial traceability, multi-company intercompany balance, period closure status). Without rigorous Infor LX (BPCS) data validation, the migration ships with silent data corruption — typically discovered three months later when the year-end audit fails. With it, internal audit signs off the cutover.
Every BPCS file in scope has its record count captured at source extract time (with the IBM i journal sequence number stamped on the extract manifest), captured again post-Fusion-load (from Fusion's standard load-result reports plus direct query of Fusion's underlying tables), and compared per-company, per-period, per-warehouse partition. The Infor LX (BPCS) data validation engine produces a variance report showing source-count, target-count, variance count and variance percentage per partition. Variance threshold is zero for production loads — any variance triggers a row-level diagnostic showing which BPCS records failed to load and the specific Fusion validation error. Typical BPCS files reconciled: GLT, APH/APT, RAH/RAT, IIM, IIH, ITH, ECH/ECL, MHM/MHD, HPO/HPL, ACL, CIM, PSM/PSC, RTM/RTO. Total reconciliation cadence: every load run produces a signed reconciliation manifest captured for SOX / FDA audit.
BPCS holds multi-currency in three places (MCM currency master, in-flight historical rate on each transaction, period-end rate tables) and Fusion holds it in a different structure (Currencies setup, Conversion Rate Types, Daily Rates). The Infor LX (BPCS) data validation engine reconciles per-currency, per-period: BPCS functional-currency-amount sum on GLT for company X, period Y, currency Z vs Fusion functional-currency-amount sum for the equivalent Legal Entity + Ledger + period + currency. Variance threshold is zero to the cent. The same reconciliation runs on AP and AR aging (per-supplier-currency open balance vs per-supplier-currency Fusion open balance) and on inventory value (per-warehouse-currency stock value vs per-Inventory-Org-currency stock value). Customers with 10+ currencies and 20+ years of history routinely pass the validation to the cent on the first parallel-run month-end.
Every BPCS record extracted is content-hashed at source — header hash plus line hashes plus audit-trail hash — using a deterministic hash (SHA-256) computed over the canonical UTF-8 representation of the record (with COMP-3 packed-decimal unpacked to standard decimal, CYYMMDD zoned-decimal normalised to ISO 8601 date, and EBCDIC translated to UTF-8 with the correct CCSID). Every record post-Fusion-load is re-hashed using the same canonical representation, computed from Fusion's stored data. The hashes should match exactly. Mismatch indicates an EBCDIC mistranslation (CCSID 037 vs 285 vs 1140 confusion), a COMP-3 precision loss (rare but possible if the precision is misconfigured on a customer-added UDF), a date-format error (CYYMMDD vs YYYYMMDD), or a transformation bug in a crosswalk. Hash drift is surfaced at row-level with the specific field showing the byte-level diff — typically within 60 seconds of load completion.
Beyond counts, sums and hashes, the Infor LX (BPCS) data validation engine runs business-rule checks that catch issues counts and sums miss. Multi-company intercompany balance: every intercompany journal in BPCS should net to zero per intercompany pair per period; same check on Fusion. Period closure consistency: every BPCS period closed at the GL level should map to a closed Fusion period, with no open Fusion journals against a closed BPCS period. Lot / serial traceability: every lot-controlled item with a non-zero IIH balance should have a traceable lot record carried through to Fusion's lot/serial control. AP three-way-match: every BPCS AP voucher matched against a PO and receipt should have the same matching status in Fusion (or a documented exception). Work-order WIP: every open BPCS work order should have a matching open Fusion work order with the same WIP balance. Any business-rule failure surfaces in the reconciliation pack alongside counts and sums.
BPCS audit-trail files (GLAT, APAT, RAAT, IIAT, MHAT) and IBM i database journals carry the SOX / FDA-relevant evidence chain — from a GL journal line back through the originating RPG program execution timestamp on the AS/400, by user profile and terminal. The Infor LX (BPCS) data validation engine preserves and proves the continuity. Every BPCS audit-trail record count is reconciled between source and the long-term BPCS archive (where audit-trail records route in the migration). Every IBM i journal entry count per period is reconciled between source IBM i journals and the migration evidence pack. Any drill from a Fusion GL journal back to its originating BPCS transaction is provably complete — the validation pack contains the row-level trace from Fusion GL line → Fusion Journal → BPCS GLT row → BPCS GLAT audit-trail record → IBM i journal entry → original RPG program execution. SOX auditors and FDA Part 11 reviewers sign off the chain in the validation pack directly.
Yes. For phased migrations (Financials first, Manufacturing next quarter, Order Management after that) the Infor LX (BPCS) data validation engine runs per-phase reconciliation packs. Phase 1 (Financials): GL trial balance, AP aging, AR aging, supplier master count, customer master count — all reconciled per company, per period, per currency. Phase 2 (Manufacturing): item master count, BOM count, routing count, work-order count and WIP balance reconciled per Inventory Org. Phase 3 (Order Management): sales-order count, open-order value, pricing reconciliation. Each phase produces its own signed reconciliation pack — and the final consolidated pack at end of all phases proves the cumulative cutover is complete and reconciled. The phased pattern is especially common for customers running BPCS shop-floor for 12–18 months after BPCS Financials has already moved to Fusion.
Same load run. The validation engine runs in parallel with the FBDI / HDL load — as each FBDI ZIP completes its Fusion ESS submission, the validation engine pulls the result, runs the count / sum / hash / business-rule checks, and produces the variance report typically within 5–15 minutes of load completion. Row-level diagnostics for any failed validation surface with the specific BPCS source record, the specific Fusion validation error, the suggested fix (CCSID adjustment, decimal-precision adjustment, transformation rule patch) and the bulk-fix queue. Total turnaround from load run to signed reconciliation pack: typically 30–60 minutes for a full-scope production load. No multi-day wait for an off-shore team to manually rebuild reconciliation in Excel.
30-minute call. We'll walk through your BPCS volumes, multi-company / multi-currency design, customisation footprint and audit-trail requirements — and have a sample reconciliation pack ready for your internal audit team within a week. No silent data corruption, no year-end audit failure.