Retiring Oracle Retail means preserving agreed historical records and usable access before removing the source application dependency. For this scenario, prioritise stock-ledger periods, store-day audit records and invoice matching. 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.

The cost of keeping legacy Oracle Retail up

  • Oracle Database and middleware licences, sized for peak-season transaction volumes, still running for a handful of inquiries.
  • Batch and integration infrastructure that was built to run nightly and now has to be kept stable, or at least kept from failing noisily.
  • Application server and operating system patching on a stack that is no longer moving forward.
  • Specialist knowledge. The people who understand the stock ledger, deal income, the ReSA audit rules and ReIM tolerances are hard to replace, and the questions they get from finance rarely look like a standard screen.
  • Audit access. Every supplier claim or sales tax audit means finding someone who can still log on and navigate it.

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 Oracle Retail

ArchiveHub preserves the Oracle Retail data model with its native table names, joined the way the suite joins them.

Merchandise and organisational hierarchy. DIVISION, GROUPS, DEPS, CLASS and SUBCLASS; CHAIN, AREA, REGION, DISTRICT, STORE and WH. ITEM_MASTER carries every item with its parent, level and hierarchy, ITEM_SUPPLIER and ITEM_SUPP_COUNTRY the sourcing and pack sizes, ITEM_LOC the ranging and retail per location, PRICE_HIST the price history.

Orders, receipts and movements. ORDHEAD, ORDSKU and ORDLOC for purchase orders; SHIPMENT and SHIPSKU for receipts; TSFHEAD and TSFDETAIL for transfers; ALLOC_HEADER and ALLOC_DETAIL for allocations; RTV_HEAD and RTV_DETAIL for returns to vendor; INV_ADJ with its reason codes; STAKE_HEAD, STAKE_LOCATION and STAKE_SKU_LOC for stock counts; ITEM_LOC_SOH for stock on hand.

Stock ledger. MONTH_DATA with TRAN_DATA_CODES, the monthly position by location and department that retail accounting is built on.

Sales Audit. SA_STORE_DAY, SA_TRAN_HEAD, SA_TRAN_ITEM, SA_TRAN_TENDER, SA_TRAN_TAX and SA_TRAN_DISC, SA_TOTAL and SA_ERROR with the error codes and balance groups.

Invoice Matching. IM_DOC_HEAD and IM_INVOICE_DETAIL for invoices, debit and credit memos; IM_COST_DISCREPANCY, IM_QTY_DISCREPANCY and IM_RESOLUTION_ACTION for how every discrepancy was settled.

Deals and promotions. DEAL_HEAD, DEAL_DETAIL, DEAL_THRESHOLD and DEAL_ACTUALS_FORECAST for vendor deals and rebate income; RPM_PROMO and RPM_PROMO_COMP for promotions.

Financial integration. STG_FIF_GL_DATA for the GL journal lines sent to the ledger, FIF_GL_ACCT, FIF_GL_CROSS_REF and FIF_GL_SETUP for account mapping and sets of books, FIF_GL_RECON for the month-end reconciliation, plus SUPS, ADDR, TERMS_HEAD, VAT_CODES and CURRENCY_RATES.

Columns keep their Oracle Retail names, such as ITEM, DEPT, CLASS and SUBCLASS, each with a description, so merchandise planners and finance analysts can query the archive in the vocabulary they already use.

Explore the demonstration

GL Journal Lines list in ArchiveHub GL Journal Lines: journal lines the financial integration sent to the general ledger, by set of books, period and account. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

GL Journal Lines detail page GL Journal Lines detail: one interfaced line with its source transaction and account mapping. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Subledger to GL Reconciliation in ArchiveHub Subledger to GL Reconciliation: stock ledger, ReIM and receipts against the GL at each month end. 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

  • Open Supplier Invoices (Aged): reference workflow: ReIM posted invoices awaiting payment at the archive date, aged by due date.
  • Supplier Payment Runs: reference workflow: Retail Financial Integration supplier payment runs posted from Payables.
  • Vendor Debit Memos: reference workflow: ReIM Document Maintenance for debit memos.
  • Discrepancy Review List: reference workflow: the ReIM Discrepancy Review List and its resolution history.
  • GL Interface Batches: reference workflow: Financial Integration GL interface batch control (STG_FIF_GL_DATA).
  • GL Journal Lines: reference workflow: Financial Integration GL journal lines sent to the general ledger.
  • Subledger to GL Reconciliation: reference workflow: the stock ledger, ReIM and receipts reconciled to the GL at each month end.
  • Invoice Match Inquiry: reference workflow: ReIM Summary Match results, invoice against receipts.
  • Sales Tax and VAT by Store: reference workflow: ReSA sales tax / VAT collected per store and month, with remittance.
  • Stock Ledger: reference workflow: the Merchandising monthly stock ledger by location and department.
  • Supplier Invoices: reference workflow: ReIM merchandise invoices, matching and payment.
  • Trial Balance: reference workflow: Financial Integration trial balance by set of books and period.

Inventory

  • Allocations: reference workflow: Oracle Retail Allocation maintenance, store split of peak season stock.
  • Inventory Adjustments: reference workflow: Inventory Adjustment by Item and the Inventory Adjustments report.
  • Shipments and Receipts: reference workflow: Shipment search and receiving (Inventory > Shipments).
  • Stock Count Results: reference workflow: Stock Count Results and variance review (Inventory > Stock Counts).
  • Stock on Hand by Location: reference workflow: Item Location Inventory (stock on hand at the archive date).
  • Transfers: reference workflow: Transfer search and view (Inventory > Transfers).

Merchandising

  • Item Supplier Country: reference workflow: Item Supplier Country (sourcing, costs, pack sizes).
  • Price History: reference workflow: Item Price History by location.
  • Promotions: reference workflow: Price Management promotion search and POS discount results.

Purchasing

  • Deals: reference workflow: Merchandising deal maintenance and deal income (vendor rebates).
  • Purchase Orders: reference workflow: purchase orders with receipts and invoices.
  • Return to Vendor: reference workflow: Return to Vendor (RTV) search and view.
  • Suppliers: reference workflow: suppliers with orders, invoices and open balance.

Sales

  • Sales Audit Error List: reference workflow: the ReSA Error List: audit rule hits and how they were cleared.
  • Sales Audit Transactions: reference workflow: ReSA audited POS transactions.
  • Store Day Summary: reference workflow: the ReSA Store Day Summary: audit status, over/short, errors and totals.
  • Stores: reference workflow: store locations with sales, stock and replenishment.
  • Store Sales Summary: reference workflow: ReSA audited store day totals.
  • Tender Summary: reference workflow: the ReSA Tender Summary: net tender by type per store and business day.

Sales & Purchasing

  • Item Master: reference workflow: Merchandising items with locations, suppliers and price history.

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.

Supplier invoices and purchase orders keep their documents, as do vendor debit memos, returns to vendor, stock counts and deals. Supplier and store records carry theirs too. When a supplier disputes a chargeback or a deal claim years later, the debit memo or deal agreement opens next to the archived record.

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 all archived tables, with Oracle Retail column descriptions and suggested joins (ORDSKU to ITEM_MASTER, SA_TRAN_ITEM to SA_TRAN_HEAD, IM_DOC_HEAD to SUPS).
  • Retention rules and purge with approval. Point-of-sale detail and supplier documents can have different retention periods, and nothing is purged without sign-off.
  • Legal hold for disputed supplier claims or investigations.
  • 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 for multi-year sales and margin analysis.

How the decommissioning project runs

  1. Extract the Merchandising, Sales Audit, Invoice Matching, Price Management and financial integration tables with their native structure.
  2. Validate row counts table by table, then the numbers that matter in retail: stock ledger months against the GL inventory accounts, ReIM against the supplier liability, ReSA store totals against the sales postings, and the trial balance per set of books.
  3. Parallel read access for merchandising, store audit, finance and loss prevention users while the old environment is still up.
  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.

Close the old suite for good

If a legacy Oracle Retail environment is still running mainly to answer questions about the past, let us show you the same stock ledger, sales audit and invoice matching history in ArchiveHub.

Questions about Oracle Retail retirement

Is retail history covered by a general-ledger export?

Not on its own. A supplier dispute or stock investigation may need merchandising transactions, sales-audit context and matching records in addition to finance totals. Define those business questions before extraction.

How should retail reconciliation be scoped?

Select the stores, inventory periods, currencies and transactions in scope. Compare archived stock, matching and sales-audit results with agreed source outputs and document timing or integration differences.

What does this ArchiveHub demonstration prove?

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

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

Related retirement resources

For the broader project approach, see Legacy application retirement planning. To evaluate how users will find transactions, follow relationships and retrieve documents, explore archived data reporting. These resources complement this Oracle Retail-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 Oracle application 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 Oracle Retail retirement engagement

ArchiveHub offers a fixed-price engagement for Oracle Retail 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 Oracle Retail retirement requirements with ArchiveHub

Oracle Retail is a trademark of its respective owner. ArchiveHub is not affiliated with or endorsed by Oracle.