JAMS — Oracle Financials Fixed Assets Migration & Multi-Org Implementation

Executive Summary

JAMS — the dispute resolution services company providing mediation and arbitration services through a national network of offices — undertook an Oracle Financials implementation in 1999 covering Fixed Assets, Accounts Payable, and General Ledger. The engagement involved a significant data conversion workstream: migrating existing fixed asset records into Oracle's FA module using Mass Additions, configuring Oracle's multi-org structure to support JAMS's multi-office operating model, and loading vendor and site master data from legacy sources.

This engagement represents one of the earliest in the portfolio — Oracle Financials 10.6/10.7 predates the 11i release and the Subledger Accounting framework entirely. The technical artifacts (ASSETS.DAT, CONVDATA.sql, FA Mapping.xls, mass additions SQL scripts) reflect the data conversion methodology of the era: extract data to flat files, map legacy fields to Oracle FA data elements, load through the FA Mass Additions interface, and validate using custom SQL queries. The parallel upgrade project plan (Upgrade.mpp) indicates the 10.6-to-10.7 upgrade was managed concurrently with the implementation work.

Engagement Context

JAMS operates through a network of regional offices providing mediation, arbitration, and dispute resolution services — a professional services model with a large fixed asset base relative to its revenue: office furnishings, technology equipment, and leasehold improvements distributed across dozens of locations. Managing this multi-location asset base required an Oracle FA configuration that could track assets by location, accumulate depreciation correctly across multiple tax and book depreciation methods, and provide the asset register required for insurance, tax, and financial reporting.

Oracle Financials 10.7 was the current release in 1999, representing Oracle's financials platform before the architectural overhaul that produced 11i. The 10.7 interface was character-mode or SmartClient (a Java thick client), before Oracle's HTML-based self-service interface became standard. Data conversion in this environment required direct SQL-level data loading — the APIs and interface tables that simplified 11i data migration were less developed in 10.7. This made the CONVDATA.sql approach — building conversion data directly in Oracle's FA interface tables — the standard practice of the era.

The Multi-Org setup for a professional services firm with multiple offices requires careful operating unit design: each office or region may need to be a separate operating unit if it has independent financial reporting, or offices may be consolidated under a single operating unit if financial reporting is centralized. The JAMS Multi-Org Set Up document reflects the design decisions made for this configuration — decisions that affect every downstream module and cannot easily be changed after data is loaded.

Oracle Implementation Scope

Fixed Assets — Mass Additions & Data Conversion

The core technical challenge of the engagement was migrating JAMS's existing asset register into Oracle FA. The conversion approach used Oracle's Mass Additions interface: legacy asset data was extracted and mapped to Oracle's FA_MASS_ADDITIONS table fields (asset number, description, category, book, cost, date placed in service, depreciation method, life), loaded via CONVDATA.sql, and then processed through the Mass Additions Post program that creates FA_ASSET_HISTORY and FA_BOOKS records. The FA Mapping.xls workbook documented the field-by-field mapping from the legacy asset register to Oracle FA data elements — the essential reference artifact for understanding what was converted and how.

The ERROR.DAT and ERROR.TXT artifacts from the conversion confirm that the migration required multiple load-and-correct cycles — the standard experience in any FA mass additions migration. Common conversion errors include invalid category codes, asset costs that don't reconcile to accumulated depreciation at the conversion date, and missing cost center values for the account generator. The wagmass.sql and mass_test SQL series reflect the iterative testing approach used to validate the conversion before final production load.

Multi-Org Configuration

Oracle Multi-Org configuration established the operating unit structure for JAMS's office network. The org.sql diagnostic script and the JAMS Multi-Org Set Up document reflect the configuration work: set of books (chart of accounts, calendar, functional currency), legal entities, and operating units. Vendor sites (vend_site.sql) were loaded against the configured operating unit structure, establishing the supplier master that AP invoice processing would use.

AP and GL Integration

The ccid function.sql and Distribution Function.sql artifacts reflect account coding configuration — the Code Combination ID functions that derive GL account distributions for AP invoices and FA transactions. In Oracle 10.7, account generator logic resided in these PL/SQL functions rather than the Oracle Workflow-based Account Generator introduced in later releases.

Key Deliverables

Consultant Insights

Related Engagements