Self-serve Infor LX (BPCS) historical reporting on cloud object storage. Standard SQL, business-friendly semantic layer, Tableau / Power BI / Looker / OAS integration, FDA 21 CFR Part 11 and SOX compliance — without an IBM i licence, an Infor LX subscription or an RPG developer in the loop.
Once the live BPCS use case has moved to Oracle Fusion or another modern ERP, the historical reporting use case becomes a separate problem — and keeping a dormant IBM i alive purely to answer it is the most expensive answer.
Most BPCS customers underestimate how much historical reporting demand outlasts the active BPCS operational use. Tax audits arrive years after the fact; FDA inspections of pharma batch records can demand reconstruction of work orders processed a decade earlier; SOX 404 testing requires substantive evidence drilling back through the full 7-year retention; legal discovery requests and ex-employee data subject access requests can hit at any time. Each of those requests, in a poorly-planned migration, becomes a phone call to the one remaining RPG developer who still knows how to log into the AS/400 and run a Query/400 against GLT or MHAT.
A purpose-built Infor LX (BPCS) historical reporting solution flips that. Every BPCS file in scope is extracted once during migration to UTF-8 Parquet on cloud object storage, COMP-3 unpacked, EBCDIC translated, dates normalised, and stored with hash-signed audit evidence. A standard SQL query layer (Athena, BigQuery, Snowflake or Trino) plus a pre-built semantic layer that hides BPCS field-naming quirks (GLT becomes Finance.JournalLine, IIM becomes Item.Master) means finance, tax, audit and compliance analysts can self-serve via Tableau, Power BI, Looker or Oracle OAS — no AS/400 access, no Infor LX licence, no RPG developer required.
And critically: the IBM i Power LPAR can be powered down. The 5 TB BPCS database that costs $50K–$200K per year to keep alive on a Power LPAR with IBM Software Maintenance can be archived to S3 Glacier Deep Archive for $200–800 per year (a 50–500× cost reduction) — while Infor LX (BPCS) historical reporting access actually gets faster and more accessible than it ever was on the AS/400.
The translation rules that turn 1980s IBM midrange file names into something a self-serve analyst can actually use.
GLT → Finance.JournalLine, GLM → Finance.Account, APH → AP.InvoiceHeader, RAH → AR.InvoiceHeader, GLAT → Finance.AuditTrail — with CONO → CompanyCode and CYYMMDD dates → ISO 8601 timestamps.
PSM / PSC → Item.Structure, RTM / RTO → Item.Routing, MHM / MHD → WorkOrder.Header / WorkOrder.Detail, HRM → WorkOrder.LabourTransaction, MHAT → WorkOrder.AuditTrail.
IIM → Item.Master, IIH → Item.WarehouseBalance, ITH → Inventory.Transaction, WHM → Warehouse.Master, LOC → Warehouse.Location — multi-warehouse, lot / serial detail preserved.
ECH / ECL → SalesOrder.Header / SalesOrder.Line, HPO / HPL → PurchaseOrder.Header / PurchaseOrder.Line, SHP → Shipment.Header, PRH / PRL → Pricing.Header / Pricing.Line.
CIM → Customer.Master, ACL → Supplier.Master, CCM → Company.Master, MCM → Currency.Master — including UDFs preserved as named dimensional attributes.
BPCS audit-trail files (GLAT, APAT, RAAT, IIAT, MHAT) and IBM i database journals (QSQJRN entries) exposed as queryable evidence with user / terminal / timestamp.
From scoping to self-serve analyst access, typically 6–10 weeks for a 5–20 TB BPCS instance.
Inventory every Query/400 query, RPG report, BPCS standard report and SQL/400 stored query in production use. Classify by business value (regulatory, operational, ad-hoc, retired). Identify the historical-reporting consumer population (finance, tax, audit, compliance, legal).
Cloud warehouse target chosen (Athena / BigQuery / Snowflake / Trino), semantic layer modelled (entity names, dimensional attributes, time semantics), pre-built BI dashboards templated (trial balance, AP / AR aging, inventory aging, work-order traceability, sales / shipment history).
DB2 for i extractor pulls every BPCS file in retention scope to UTF-8 Parquet with COMP-3 unpacking and EBCDIC translation. Hash-signed manifests produced per partition. Multi-TB GLT and ITH extracts scheduled to off-peak.
Athena / BigQuery / Snowflake / Trino views deployed implementing the semantic layer. Pre-built BI dashboards published to Tableau / Power BI / Looker / OAS. Sample queries validated against BPCS-source results for byte-level correctness.
Finance, tax, audit and compliance analysts trained on the semantic layer, given read-only IAM access, and onboarded to the BI templates. Final delta capture from IBM i journal. AS/400 can move to read-only and ultimately power down.
The everyday queries the platform makes possible without an IBM i, an Infor LX licence, or an RPG developer in the loop.
Reproduce the BPCS trial balance for any company, any period back to 7–20 years in the original BPCS currency configuration. Drillable to journal line, source document and audit-trail record.
Reproduce AR aging per customer per company per period, AP aging per supplier per company per period — at any historical point-in-time. Tax-audit and legal-discovery ready.
Reconstruct every shop-floor transaction, every operation, every lot / serial movement on a named work order. FDA 21 CFR Part 11 inspection-ready.
Historical inventory aging per warehouse per item per period. Turnover analysis across 10+ years for due-diligence and divestiture preparation.
All invoices, shipments and transactions touching a named customer or supplier across the full retention window — in seconds, no IT request.
BI Publisher / SQL Server Reporting Services equivalents for regulatory submissions (state tax, FDA submissions, SEC filings) — preserving the original BPCS report shape.
Infor LX (BPCS) historical reporting is the ability to query, report on and audit 7+ years of legacy BPCS data — GL transactions, AP / AR history, work-order batch records, inventory transactions, sales / purchase history — after the live BPCS application has been retired or migrated to Oracle Fusion or another modern ERP. It matters because tax audits (IRS, state revenue authorities), regulator inspections (FDA for pharma batch records under 21 CFR Part 11, SEC for SOX-listed companies), internal audit, finance retro-questions, legal discovery and ex-employee data subject requests all need access to that history for years — sometimes decades — after the BPCS application is gone. Without a deliberate Infor LX (BPCS) historical reporting solution, organisations are forced to keep a dormant IBM i Power LPAR alive purely to satisfy occasional read requests, paying $50K–$200K per year for what amounts to a read-only archive.
After the AS/400 is decommissioned, the BPCS data lives as structured UTF-8 Parquet on cloud object storage (S3 / GCS / Azure Blob), with COMP-3 packed-decimal numerics unpacked, EBCDIC characters translated, CYYMMDD dates normalised, and the original BPCS field metadata preserved for round-trip reproducibility. A SQL query layer (Athena / BigQuery / Snowflake / Trino) sits over the Parquet, and a pre-built Infor LX (BPCS) historical reporting semantic layer hides the BPCS field-naming quirks behind business-friendly entities (Finance.JournalLine, Item.Master, WorkOrder.Header). Finance, tax, audit and compliance analysts query with standard SQL or BI tools (Tableau, Power BI, Looker, Oracle OAS) directly — no IBM i, no Infor LX licence, no RPG developer involved.
The common categories: tax-period reconstructions ('what was the AR balance per customer per company per period for the 2019 IRS audit'), batch-record traceability ('show every shop-floor transaction touching work order 12345 for the FDA inspector'), retro accounting investigations ('explain the variance between functional and reporting currency for this GL combo in Q3 2018'), supplier / customer audit ('all invoices to this supplier across 7 years for a legal discovery request'), ex-employee subject access requests (general data protection responses), inventory turnover and aging analytics for divestiture due diligence, and SOX 404 substantive testing of historical periods. Each query type is supported by the semantic layer with pre-built drill paths and standard BI templates.
BPCS field names follow 1980s IBM midrange conventions — six-character file names like GLT, GLM, IIM, ECH, MHM; six-character field names like CONO (company), WHSE (warehouse), CUSNO (customer number), VENNO (vendor number); CYYMMDD zoned-decimal dates; packed-decimal amounts in fields like GLAMT or GLDR / GLCR. The semantic layer translates: GLT becomes Finance.JournalLine, GLM becomes Finance.Account, CONO becomes CompanyCode, WHSE becomes WarehouseCode, CUSNO becomes CustomerNumber, CYYMMDD dates become standard ISO 8601 timestamps, and packed-decimal amounts become decimal numerics with proper precision. Self-serve analysts write queries in business terms without needing to know what BPCS GLT or IIH means.
Yes — that's the point of putting the archive in standard Parquet behind a SQL query layer. The semantic layer exposes business-friendly views that connect natively to Tableau (via Athena / BigQuery / Snowflake connectors), Power BI (via DirectQuery to Snowflake / BigQuery or Import to Parquet), Looker (via LookML on top of the warehouse), Oracle OAS (via JDBC) and any other tool that speaks ANSI SQL. Pre-built dashboards for the common Infor LX (BPCS) historical reporting use cases (trial balance, AP aging, AR aging, inventory aging, sales / shipment history, work-order batch traceability) ship with the platform so most customers get reporting parity with their old Query/400 reports within days of the archive going live.
Faithfully. BPCS multi-currency (held in MCM currency master plus the in-flight translation rate stamped on every GLT / APH / RAH transaction) and multi-company (CCM company master) are preserved in the archive with the original currency code, original translation rate and original company code on every row. Queries can be run in transaction currency, reporting currency, functional currency, or any combination. Reproducing the exact BPCS trial balance for a given company in a given period in the historical currency configuration that was in effect at the time is straightforward — the semantic layer surfaces the rate context as first-class dimensions.
Yes when configured to compliance mode. SOX compliance requires 7-year retention with auditable trace from any reported number back to its originating transaction; the archive preserves the full chain via BPCS audit-trail files (GLAT, APAT, RAAT) and IBM i database journals, with SHA-256 hash signatures on every Parquet file and KMS-controlled access logging. FDA 21 CFR Part 11 (pharma) requires longer retention (often 30+ years for batch records) plus electronic signature, audit trail and write-once-read-many properties; the archive supports S3 Object Lock / Azure Blob Immutability in compliance mode for WORM enforcement, captures every analyst query in the audit log, and preserves the RPG source-code snapshot alongside the data for batch-record forensic reconstruction.
Legacy Query/400 queries, RPG-based custom reports, SQL/400 stored queries and BPCS-bundled reports don't carry forward — they are IBM i platform-bound. The Syntra ETL assessment inventories every active Query/400 query, RPG report and BPCS standard report in production use, classifies by business value (in-use vs orphaned, critical vs nice-to-have, regulatory vs operational), and proposes a Fusion- or warehouse-equivalent rebuild: native Tableau / Power BI / OAS dashboard, BI Publisher pixel-perfect report, or self-serve SQL template. Approximately 40–60% of legacy BPCS reports are duplicates or low-value and get retired during the cleanup. The remaining critical reports are rebuilt on the Infor LX (BPCS) historical reporting platform as part of the cutover, so go-live includes the reporting layer — not just the data.
30-minute call. Walk through your reporting estate (Query/400, RPG reports, BPCS standard reports), retention horizon (SOX 7yr, FDA 30+yr) and analyst population — leave with a concrete Infor LX (BPCS) historical reporting plan and a business case for AS/400 decommissioning.