Retiring Infor BPCS means preserving agreed historical records and usable access before removing the source application dependency. For this scenario, prioritise batch records, formula context and financial transactions. Compare required reports and documents with source evidence, test permissions and obtain business acceptance before scheduling shutdown.

This guide covers the retirement questions, a mock-data ArchiveHub demonstration and the validation work needed to define a project scope.

What keeping BPCS read-only really costs

Cost categories are a discovery checklist, not a guaranteed savings calculation. Verify support status, deployment, shared infrastructure and contract terms for the actual installation.

  • IBM i hardware and software. An IBM Power system, its operating system licence, hardware maintenance and eventually a forced refresh when the old box goes out of support, all for a machine that only answers inquiries.
  • RPG and IBM i skills. BPCS is RPG code on DB2 for i. The people who know how to keep it alive, apply PTFs, manage the backups and fix a broken job are retiring, and replacing them is expensive.
  • Site-custom programs. Most BPCS shops built their own files and programs over the years, often for payroll or EDI interfaces. They have to keep working, or the data they hold becomes unreachable.
  • Security. A 5250 green-screen system with old user profiles and shared passwords is hard to defend in a security audit, and it still holds employee, vendor and customer data.
  • Audit access. Every inspector or auditor needs a terminal emulator, a user profile and someone who remembers which inquiry shows what.

Scope, versions and evidence

This is an illustrative workflow, not a customer case study. Confirm the source release, deployment, modules, customisations and extraction permissions before using the mappings below. Tables and report labels describe the demonstration catalogue; native-report equivalence has not been independently certified. Use agreed source reports and representative records for acceptance testing.

An archive is not a replacement for every operational feature of the retired ERP. Document required historical tasks, excluded functions and any archive-derived calculations.

Historical data to scope for Infor BPCS

ArchiveHub archives BPCS files under their native names, with every field keeping its BPCS name and a description. The BPCS vocabulary of facilities, cost sets, cost buckets, transaction types and journal sources carries straight over into the archive and the ad-hoc query builder.

Representative files:

  • Inventory: IIM item master, IWI item warehouse balances, and ILI location and lot balances, where on hand is LOPB + LRCT − LISSU + LADJU. Lots are in ILN, with expiry and status. ITH holds inventory transaction history, typed by transaction type from ITE. Locations, warehouses and item classes are in ILM, IWM and IIC.
  • Costing: CMF item cost by facility, cost set and cost bucket.
  • Production: FSO shop orders (bulk batch and packaging orders), FMA material allocations and issues, FOD operations, MBM formulas and bills of material (ingredients per one stocking unit of the parent), FRT routings and LWK work centers.
  • Sales and billing: ECH and ECL customer orders, SIH and SIL billing invoice history, RCM customers and EST ship-tos.
  • Receivables: RAR, the receivables ledger of invoices, credit memos and payment applications, with RTM payment terms.
  • Purchasing and payables: HPH and HPO purchase orders, AVM vendors, APH and APL AP invoice headers and distributions, and APK check history.
  • General ledger: GJH journal headers and GLH posted journal lines, GJD journals entered but not posted at the cut-off, GBB budgets, GCR valid company-department-account combinations, GDP departments and GCO companies.
  • Fixed assets: FAM and FAD.
  • Site-custom payroll: ZEM and ZPH, fed from an outside payroll service, archived alongside the standard BPCS files.

Explore the demonstration

Journal Entry Inquiry list in ArchiveHub Journal Entry Inquiry: posted BPCS journals from GJH, by company, period, source and journal number. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Journal Entry Inquiry detail page in ArchiveHub Journal Entry Inquiry detail: one journal with its GLH lines, accounts, departments and amounts. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

AP Aging Report list in ArchiveHub AP Aging Report: open AP invoices from APH by vendor, aged by due date at the archive cut-off. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Explore the report reference catalogue

These mappings identify intended business workflows, not certified one-for-one equivalents. Confirm availability, source coverage, filters, currencies, dates and calculations for the selected release and implementation.

Finance

  • Journal Entry Inquiry: reference workflow: the General Ledger Journal Entry Inquiry (GJH, GLH).
  • Trial Balance: reference workflow: the Trial Balance by company, period and account, with period 13 as the year-end close (GLH, GCR).
  • Budget versus Actual Report: reference workflow: the Budget versus Actual Report by account and department, debit positive (GBB, GLH).

Audit

  • Journal Audit Trail: reference workflow: the GL Journal Audit Trail: every journal by source, user, entry time and posting status, including entries never posted at the cut-off (GJH, GJD).
  • Subledger to GL Reconciliation: reference workflow: the subledger to General Ledger reconciliation at the archive cut-off: RAR, APH, receipts, ILI x CMF, FSO, FAM, SIH and ZPH against GLH.

Accounts Payable

  • AP Aging Report: reference workflow: Accounts Payable Aging by due date at the archive cut-off (APH), tied to the AP control account.
  • AP Invoice Inquiry: reference workflow: the Accounts Payable Invoice Inquiry (APH, APL, APK).
  • AP Check Register: reference workflow: the Accounts Payable Check Register and check status (APK).

Accounts Receivable

  • AR Aging Report: reference workflow: Accounts Receivable Aging by due date at the archive cut-off (RAR), tied to the AR control account.
  • Customer Account Inquiry: reference workflow: the Receivables Ledger / Customer Account Inquiry: invoices, credit memos and cash applications (RAR).

Cash and Bank

  • Cash Account Activity: reference workflow: the cash account activity / bank reconciliation view of the GL cash account, with running balance and check clearing status (GLH, APK).

Sales

  • Customer Order Inquiry: reference workflow: the Customer Order Inquiry (ECH, ECL).
  • Invoice History Inquiry: reference workflow: the Billing Invoice History Inquiry (SIH, SIL).
  • Sales Analysis by Customer and Item: reference workflow: the Sales Analysis Report by customer, item and month from billing history (SIL); credit memos are not included.

Purchasing

  • Purchase Order Inquiry: reference workflow: the Purchase Order Inquiry (HPH, HPO), with receipts and invoice match.
  • Receipts Not Invoiced: reference workflow: the Received Not Invoiced / Receipt Accrual Report at the archive cut-off (ITH, HPO, APL), tied to the receipts accrual account.

Inventory

  • Inventory Transaction History: reference workflow: the Inventory Transaction History Inquiry (ITH, ITE).
  • Location and Lot Balances: reference workflow: the Location / Lot Balance Inquiry (ILI, ILN).
  • Lot Status and Trace: reference workflow: the Lot Status Inquiry and Lot Trace, forward and backward (ILN, ITH, FSO).
  • Lot Expiration Report: reference workflow: the Lot Expiration / Shelf Life Report at the archive cut-off (ILN, ILI).
  • Inventory Valuation Report: reference workflow: the Inventory Valuation Report at frozen standard (IWI, CMF), tied to the inventory accounts.
  • Item Cost Inquiry: reference workflow: the Item Cost Inquiry by facility, cost set and cost bucket (CMF).

Production

  • Shop Order Status Inquiry: reference workflow: the Shop Order Status Inquiry with material and operation detail (FSO, FMA, FOD).
  • Formula and Routing Inquiry: reference workflow: the Formula / Bill of Material Inquiry with routing (MBM, FRT).
  • Batch Yield and Variance Report: reference workflow: the Shop Order Variance Report: yield, material usage and labor variances of cost-closed orders (FSO, FMA, FOD), with variances posted to the GL.

Master Data

  • Item Master Inquiry: reference workflow: the Item Master Inquiry (IIM, IWI, CMF).
  • Customer Master Inquiry: reference workflow: the Customer Master Inquiry (RCM, EST).
  • Vendor Master Inquiry: reference workflow: the Vendor Master Inquiry (AVM).

Assets

  • Fixed Asset Inquiry: reference workflow: the Fixed Asset Inquiry and Depreciation History (FAM, FAD).

Tax

  • Sales and Purchase Tax Report: reference workflow: the Sales and Use Tax / VAT Report: output tax from billing (SIH) and input tax from AP (APH) by return period, with monthly returns posted under journal source TAX.

Payroll and HR

  • Employee and Payroll Register: reference workflow: the Employee Inquiry with payroll register history. Payroll ran outside BPCS and was interfaced to the site-custom files ZEM and ZPH (journal source PAY).

Source documents stay attached

Document types below illustrate the intended scope. Include source attachments and external repositories explicitly, and test retrieval and record linkage before decommissioning.

ArchiveHub keeps archived documents attached to the BPCS records they belong to: purchase orders, AP invoices, customer invoices, batch records for shop orders, certificates of analysis, fixed assets, employee records, vendors and customers. When a complaint comes in about a lot shipped years ago, quality can open the lot trace, the batch record and the certificate of analysis together.

Beyond the reports

Confirm these capabilities, configuration requirements and limits during the demonstration and scope review; the report catalogue alone does not validate them.

  • Ad-hoc query builder over the configured archived files, with BPCS field descriptions and suggested joins, for example ITH to ILN to FSO for a lot's history, or APH to APL to APK for a vendor invoice.
  • Retention rules and purge with approval, set by file and record age.
  • Legal hold on lots, products, customers or vendors involved in a recall, claim or tax audit.
  • Personal-data governance: agree the lawful retention, access and deletion requirements with the responsible privacy and records teams. Product features alone do not establish regulatory compliance.
  • Access controls: define and test permissions for the required companies, records and sensitive fields. Do not assume that system-level roles reproduce the original ERP permissions, particularly for payroll and HR data.
  • OData feeds to Excel, Power BI and SAP Analytics Cloud.

How the decommissioning project runs

  1. Extract the BPCS files, including the site-custom Z files, from DB2 for i on the IBM i.
  2. Validate. Row counts are checked per file. Balances must tie out: GLH must reproduce BPCS's own trial balance, and RAR, APH, receipts, ILI x CMF inventory value, open shop orders, fixed assets, billing and payroll must reconcile to their GL accounts.
  3. Parallel read access. Finance, quality, planning and HR users answer their usual questions in ArchiveHub while the IBM i is still running.
  4. Retire after acceptance. Obtain documented sign-off for data reconciliation, document retrieval, user access, retention and legal holds, recovery and remaining integrations. Retire only the approved components; shared infrastructure may still be needed. End or reduce subscriptions, licences and support only where the contract permits. Budget for archive operation and any residual costs.

Turn off the green screen

The BPCS history still matters. The IBM i that holds it does not have to keep running. ArchiveHub keeps the lots, formulas, journals and invoices readable under the BPCS names your people know.

Questions about Infor BPCS retirement

Does retiring BPCS require shutting down the whole IBM i?

Only if all other dependencies have also been cleared. Inventory shared applications, schedules, files and interfaces before including the platform in the retirement decision.

How should batch documents and COA files be mapped?

Confirm the document type and its link to the relevant batch or lot. Do not infer certificate-of-analysis coverage from a filename alone; test representative records and document missing links.

What does this ArchiveHub demonstration prove?

The screenshots illustrate how selected records can be presented using mock data. They do not prove production completeness, customer outcomes or parity with every Infor BPCS report. Request a demonstration against your own approved scope and acceptance cases.

Related retirement resources

For the broader project approach, see IBM i application decommissioning. To evaluate how users will find transactions, follow relationships and retrieve documents, explore archived data reporting. These resources complement this Infor BPCS-specific scope rather than replace source-system validation.

Evidence and further reading

The report catalogue and screenshots originate from an internal mock-data demonstration. They are not vendor certification or customer implementation evidence.

Use Infor documentation to locate the documentation for the installed release. This is a documentation entry point, not verification of every table or report mapping in this article.

Fixed-price Infor BPCS retirement engagement

ArchiveHub offers a fixed-price engagement for Infor BPCS retirement and historical data access, based on an agreed scope, deliverables and acceptance criteria. Request a scoped proposal covering your source systems, data, documents, reporting and validation requirements. The proposal should specify included services, exclusions, ongoing platform or hosting charges, and how scope changes will be handled.

Discuss your Infor BPCS retirement requirements with ArchiveHub

Infor BPCS is a trademark of its respective owner. ArchiveHub is not affiliated with or endorsed by Infor.