MPHA — Oracle EBS R12 Upgrade: SLA Validation, QA Testing & Functional Configuration

Client	MPHA (Public Sector Health Authority)
Industry	Public Sector — Health Authority / Government
Oracle Version	Oracle E-Business Suite R12 (Upgrade from 11i)
Modules	PO AP GL
Engagement Period	2014
Project Type	Oracle EBS R12 Upgrade — SLA Validation, QA Testing & Functional Remediation
Complexity	Medium · R12 Upgrade · SLA Payment Analysis · Customization Inventory · FITGAP Retesting

Executive Summary

MPHA — a public sector health authority — undertook an Oracle EBS upgrade from 11i to R12 with CherryRoad Technologies as the prime implementation partner. William Delaney Consulting was engaged to provide specialized functional expertise in Oracle R12 Subledger Accounting (SLA), QA testing, and functional configuration remediation. The engagement ran May–June 2014 through the final testing phases of the upgrade project, addressing the most technically sensitive aspects of the 11i-to-R12 transition: SLA accounting behavior differences, customization compatibility, E-Business Tax configuration, and the verification of concurrent program outputs before go-live.

The SLA subfolder artifacts — payment-specific accounting analysis documents examining six specific payments under multiple upgrade scenarios — represent the deepest technical work of the engagement: validating that Oracle R12's Subledger Accounting engine produced correct accounting entries for historical and new payments under a range of void, upgrade, and no-action scenarios. This kind of payment-level SLA forensics is essential in R12 upgrades where AP payment accounting differs fundamentally from 11i.

Engagement Context

Public sector Oracle EBS upgrades present distinctive challenges beyond those of commercial implementations. Government entities operate under additional compliance constraints: audit requirements, public accountability for financial accuracy, and often less flexibility to accept "close enough" accounting approximations that private sector clients might accept during an upgrade transition. For MPHA, a health authority, the accuracy of payment accounting and the integrity of subledger-to-GL reconciliation were not negotiable — every payment needed to account correctly before the upgrade could be certified production-ready.

CherryRoad Technologies — a consulting firm specializing in Oracle EBS for public sector organizations — engaged William Delaney Consulting as a specialist resource for the SLA and functional testing dimensions of the upgrade. This subcontractor model is common on large Oracle upgrade projects where the prime integrator has broad program management and technical capabilities but benefits from specialist depth in areas like SLA accounting that require deep Oracle internals knowledge.

The 11i-to-R12 upgrade is architecturally significant for AP: Oracle replaced the 11i AP accounting model (account generator functions) with R12's Subledger Accounting (XLA) framework — a rules-based accounting engine that operates fundamentally differently. AP payments that accounted correctly in 11i may account differently in R12 depending on how SLA accounting rules are configured. Void-and-reissue payment scenarios, in particular, have different accounting treatment between 11i and R12 — a common source of post-upgrade reconciliation issues.

Functional Work Scope

SLA Payment Accounting Validation

The core technical deliverable of the engagement was payment-level SLA accounting analysis across six specific payments tested under multiple upgrade scenarios: No Action (payment exists in both pre- and post-upgrade environments), Voided-then-Upgraded, and Voided-then-Not-Upgraded. The HTML diagnostic output files (generated by Oracle's PSA diagnostic tool) captured the accounting entries Oracle produced for each payment under each scenario — enabling a systematic comparison of whether accounting was correct, what the failure modes were, and which scenarios passed or failed the upgrade validation.

The SLA Analysis.docx synthesized findings across all payment scenarios into a structured assessment: which payment types accounted correctly after upgrade, which failed, what the root cause was for failures, and what remediation (SLA rule modification, accounting method change, or manual journal) was required to correct each failure type. This analysis provided CherryRoad and MPHA's finance team with a clear picture of upgrade accounting risk before go-live.

FITGAP Retesting and QA

FITGAP retesting addressed gaps identified in earlier testing rounds that were remediated before the final quality assurance cycle. The MPHA Upgrade Test Scenario Master — CRT-QA served as the authoritative test case library, with each scenario tracking whether MPHA's business processes worked correctly in R12. The Scenario Summary Update tracked pass/fail status across the scenario library, providing the project team with a real-time picture of upgrade readiness. The functional setup issue log (four versions across the testing period) tracked functional configuration items that required correction between test cycles.

Customization Inventory and Impact Assessment

The Customization Inventory Master (two versions: May 16 and May 30) documented all custom Oracle objects — custom reports, interfaces, forms extensions, concurrent programs, and workflow customizations — that existed in the 11i environment and needed to be evaluated for R12 compatibility. Custom PL/SQL objects that called 11i-specific APIs required rewriting; Oracle Forms extensions required conversion or replacement; custom reports built against 11i table structures required updating for R12 schema changes.

E-Business Tax Remediation

The Disabling EBTax deliverable addressed Oracle R12's E-Business Tax module — introduced in R12 and not present in 11i. Government and non-profit entities that do not collect sales tax and are not subject to use tax often need to disable EBTax's automatic tax calculation to prevent incorrect tax lines from appearing on AP invoices. The EBTax disable procedure requires specific profile option configuration and tax regime setup to suppress tax calculation without breaking Oracle's accounting chain.

Report Rationalization and Migration

The Obsolete Reports inventory and Report Mapping workbook addressed the reporting transition from 11i to R12. Standard Oracle reports that exist in 11i may be replaced or deprecated in R12; custom reports built against 11i may not run correctly against R12's schema. The report rationalization exercise identified which reports were obsolete (replaced by R12 equivalents), which required migration, and which needed to be rebuilt. The Publishing Reports in Oracle guide provided the framework for deploying R12 reports through Oracle's concurrent processing engine.

Key Deliverables

Deliverable	Type	Purpose
SLA Payment Accounting Analysis	Technical Assessment	Payment-level SLA accounting validation across six payments under multiple upgrade scenarios with pass/fail determination
SLA Analysis Document	Findings Report	Synthesized SLA accounting findings with root cause analysis and remediation recommendations for failures
Upgrade Test Scenario Master (QA)	Test Artifact	Complete QA test case library for R12 upgrade covering MPHA's business processes across PO, AP, and GL
Functional Setup Issue Log (4 versions)	Issue Tracking	Running functional configuration issue log updated across the testing period tracking open, in-progress, and closed items
Customization Inventory Master	Impact Assessment	Complete inventory of 11i custom objects with R12 compatibility assessment and remediation requirements
EBTax Disable Procedure	Configuration Document	Procedure for disabling Oracle E-Business Tax automatic calculation for government entity AP processing
Report Mapping and Rationalization	Migration Artifact	Legacy-to-R12 report mapping with obsolete report identification and migration priorities
PO Upgrade Behavior Reference	Reference Document	Documentation of PO functionality behavior differences between 11i and R12 for user community awareness

Consultant Insights

On SLA Void Payment Accounting in R12 Upgrades: Payment void scenarios are the most common source of SLA accounting failures in 11i-to-R12 upgrades. In 11i, voiding a payment reverses the payment accounting and leaves the invoice in an unpaid state. In R12, SLA handles void accounting through the Subledger Accounting engine, and the accounting rules applied depend on how the SLA method and journal line types are configured. A void that worked correctly in 11i will fail in R12 if the SLA accounting rules do not produce the correct clearing account reversal. Test void scenarios explicitly — do not assume that payment accounting validation covers void accounting as well.

On Customization Inventory as Upgrade Risk Management: The customization inventory is the single most important risk management artifact in an Oracle upgrade project. Every custom object — report, interface, concurrent program, form extension, workflow, PL/SQL package — is a potential upgrade failure point. The inventory should distinguish between: (1) customizations that call Oracle-supported public APIs (lower risk), (2) customizations that directly query or update Oracle base tables (higher risk), and (3) customizations that use obsolete or replaced Oracle objects (remediation required). The MPHA inventory approach — two versions across the testing period — reflects active risk tracking as remediations are completed.

On Disabling EBTax for Government Entities: Oracle R12's E-Business Tax module assumes that AP invoices may have tax implications that need to be calculated and tracked. For government and non-profit entities that are exempt from use tax and do not remit sales tax, EBTax's automatic tax calculation produces incorrect (and potentially confusing) AP invoice lines. The correct approach is not to ignore the tax lines, but to configure EBTax to suppress calculation entirely through tax regime and party tax profile configuration — creating a clean, tax-line-free AP environment without breaking Oracle's accounting chain. Disabling EBTax incorrectly can break the Create Accounting program.