FA-02 EBS R12.x Fixed Assets Tier 2 Data Fix

Depreciation Run Diagnostic

Depreciation run status, assets with unexpected zero depreciation, fully reserved assets still depreciating, negative NBV detection, prior period adjustments, and calendar alignment.

PlatformOracle EBS R12.x
Input RequiredBook Name and Period
Diagnostic Checks30+
Data Sources7 Oracle tables
Fix Options4 guided fixes
Backup CreatedYes — Automatic

Why This Fails — and What It Costs

Oracle EBS Fixed Assets depreciation is a sequential, period-locked process — you cannot depreciate a period that is not open, you cannot skip a period, and you cannot re-run depreciation for a period that has already been fully depreciated unless you roll back the depreciation for that period first. When the Depreciation concurrent program fails mid-run or produces incorrect amounts, the recovery path depends entirely on the current state of FA_DEPRN_SUMMARY and FA_DEPRN_PERIODS — whether the period is partially depreciated, fully depreciated, or in an intermediate state where the run was interrupted.

The most operationally disruptive depreciation failure is a mid-run interruption. If the depreciation concurrent program is terminated — by a database instance restart, a DBA kill, or an Oracle error — some assets will have depreciation rows in FA_DEPRN_DETAIL and FA_DEPRN_SUMMARY for the current period, and others will not. The period will be in a partially deprecated state that cannot be rolled back through the standard Rollback Depreciation function, which only works on fully completed depreciation runs. Oracle Support must be engaged to execute the recovery script for a partially deprecated period, and the specific recovery steps depend on the exact point at which the interruption occurred.

Catch-up depreciation is the second complexity area. When an asset is added with a prior-period date in service — either because it was capitalized late or because an audit finding required backdating — Oracle FA calculates the depreciation that should have been taken in all prior periods since the date in service and accumulates it in the current period as catch-up depreciation. If the catch-up amount is unexpectedly large, it is often because the date in service was set further in the past than intended, or because the asset cost was entered incorrectly and was corrected after partial depreciation had already run.

FA-02 runs a complete depreciation run diagnostic — depreciation period status and lock flag in FA_BOOK_CONTROLS, asset count in the depreciation queue with estimated run time, assets with zero depreciation (fully reserved, expired life, or incorrect setup), catch-up depreciation identification and calculation, partial run detection via FA_DEPRN_PERIODS comparison, and depreciation journal creation status.

What This Script Diagnoses

FA-02 systematically investigates every major condition that can cause the issue this diagnostic targets. Below is the complete coverage breakdown.

Period Status & Lock
FA_BOOK_CONTROLS period status and DEPRN_STATUS flag. Confirms the period is open and no prior incomplete run is blocking. Partial run detection via FA_DEPRN_PERIODS comparison.
Depreciation Queue
Asset count in the depreciation queue by category and method. Estimated processing time. Identifies assets that will produce zero depreciation — separates expected (fully reserved, life expired) from unexpected (zero cost, method error).
Catch-up Depreciation
Assets with prior-period date in service that will generate catch-up depreciation in the current run. Period count, amount per period, and total catch-up amount. Flags amounts exceeding the normal period depreciation for review.
Journal Creation Status
Create Journal Entries completion status for the prior period. Confirms GL journals were generated before the next depreciation run. Identifies the GL period and ledger where journals will post.

What the Report Looks Like

Representative output showing the diagnostic running against a real-world scenario. The script identifies every condition, states the root cause, and generates the fix.

FA-02 — FA-02 Diagnostic Report
════════════════════════════════════════════════════════════
  ORACLE EBS R12 — FA DEPRECIATION RUN DIAGNOSTIC
════════════════════════════════════════════════════════════
  Book               : US CORP
  Period             : FEB-2026
  Case Number        : FA-492810
  Report Date        : 22-FEB-2026 08:15:44
════════════════════════════════════════════════════════════

[ SECTION 1 — PERIOD STATUS ]                STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  FA Period          : FEB-2026 — OPEN ✓
  Deprn Lock         : DEPRN_STATUS = REQUIRED ✓ (not yet run)
  Assets in Queue    : 4,841 assets

[ SECTION 2 — ZERO DEPRECIATION ASSETS ]     STATUS: ⚠ WARNING
────────────────────────────────────────────────────────────
  Fully Reserved     : 184 assets — expected ✓
  Life Expired       : 42 assets — expected ✓
  Unexpected Zero    : 3 assets — COST = 0 after adjustment ⚠
  ⚠ Assets 112801, 112802, 112803 have zero cost — verify before running deprn

[ SECTION 3 — CATCH-UP DEPRECIATION ]        STATUS: ⚠ WARNING
────────────────────────────────────────────────────────────
  ⚠ Asset 112841 — catch-up deprn $8,200 (backdated 6 months)
  Date in Service    : 01-AUG-2025
  Catch-up Periods   : 6 periods — AUG through JAN 2025
  Catch-up Amount    : $8,200 — confirm this is expected

[ SECTION 4 — PARTIAL RUN CHECK ]            STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  No prior partial run detected — FA_DEPRN_PERIODS clean ✓

[ SECTION 5 — JOURNAL CREATION ]             STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  Create Journal Entries will post to FEB-2026 in GL ✓

════════════════════════════════════════════════════════════
  DIAGNOSTIC SUMMARY
════════════════════════════════════════════════════════════
  2 advisory conditions — safe to run depreciation after review
  1. Verify 3 zero-cost assets before run
  2. Confirm $8,200 catch-up for asset 112841 is expected
════════════════════════════════════════════════════════════

The Four-Layer Architecture in FA-02

1
Diagnostic Engine
Runs 30+ checks across depreciation period status and lock flag, asset count in queue by category and method, zero depreciation asset analysis (fully reserved vs unexpected), catch-up depreciation identification and calculation, partial run detection, and depreciation journal creation status.
2
Backup Created
Before any depreciation data is modified, CONS_BACKUP.FA_BOOKS_<case#>, FA_DEPRN_SUMMARY_<case#>, and FA_DEPRN_DETAIL_<case#> are created and row counts verified.
3
Guided Data Fix
Unexpected zero-cost corrections and catch-up period validations are applied with full backup before depreciation is run. Partial run recovery requires Oracle Support engagement — FA-02 documents the state for the SR.
4
KB Article Generated
Complete KB article generated — book, period, asset queue, warnings identified, pre-run corrections made, depreciation completion confirmation. Upload directly to your knowledge base.

Backup & Rollback for FA-02

Every table touched by FA-02 data fixes is backed up before the first UPDATE fires. Backup is verified by row count. One script restores the original state if needed.

Tables Backed Up — FA-02

CONS_BACKUP.FA_BOOKS_<case#> CONS_BACKUP.FA_DEPRN_SUMMARY_<case#> CONS_BACKUP.FA_DEPRN_DETAIL_<case#> CONS_BACKUP.FA_BOOK_CONTROLS_<case#>

Backup happens before any DML. Script aborts if backup creation fails.

Pre-Flight Safety Guards

CAPITALIZED_FLAG = 'NO' or STATUS = 'PENDING'Required ✓
No active depreciation run in progressVerified ✓
No active session lock on target rowsChecked ✓
CONS_BACKUP schema accessibleVerified ✓

FIX_BACKUP_REGISTRY Entry

REGISTRY_ID<auto-generated>
CASE_NUMBER<consultant case#>
SOURCE_TABLE<table modified>
ROWS_BACKED_UP<row count>
BACKUP_VERIFIEDYES ✓
ROLLBACK_SQLStored as CLOB
STATUSACTIVE
ENVIRONMENTPRODUCTION

Auto-Generated Knowledge Base Article

This article is produced automatically at the end of every FA-02 execution — written from actual run output. No manual documentation required.

KB-FA-492810-001 · Script: FA-02
Depreciation Pre-Run Diagnostic — Zero Cost Assets and Catch-Up Depreciation Review
FA-02 pre-run diagnostic for US CORP FEB-2026: 3 assets with zero cost identified (112801-112803) and 1 asset with $8,200 catch-up depreciation (112841 backdated to AUG-2025). Depreciation not yet run — pre-flight review completed before submission.
Zero-cost assets: 3 assets had cost adjustment transactions that zeroed out the cost in the current period — adjustments were entered as part of a lease-to-buy reclassification but the replacement cost entry was not yet processed. Catch-up: Asset 112841 was added with AUG-2025 date in service reflecting the actual deployment date, producing 6 periods of catch-up.
FA_BOOKS — COST = 0 (Assets 112801, 112802, 112803 — post-adjustment)
FA_BOOKS — DATE_PLACED_IN_SERVICE = 01-AUG-2025 (Asset 112841 — catch-up calculated)
Replacement cost entries processed for assets 112801-112803 before depreciation run. Catch-up for asset 112841 confirmed as expected by Controller. Depreciation run submitted — 4,841 assets processed. Create Journal Entries run for FEB-2026.
FA-02 pre-run diagnostic should run 2 business days before depreciation submission to allow time for zero-cost and catch-up review. Asset additions with prior-period dates in service to be flagged for Controller review before the depreciation run.
FADepreciationFA_DEPRN_SUMMARYCatch-up DepreciationZero CostFA_BOOK_CONTROLSEBS R12.2

What This Script Finds

Pre-Run

Unexpected Zero Depreciation Asset

Asset with zero cost or zero net book value after an adjustment — will depreciate $0 and may indicate an incomplete reclassification or cost correction. FA-02 identifies the adjustment transaction and confirms whether the replacement cost entry was processed.

Pre-Run

Large Catch-up Depreciation

Asset with a prior-period date in service generating a catch-up amount that significantly exceeds the normal period depreciation. FA-02 calculates the catch-up by period and flags it for Controller review before the run.

Critical

Partial Run — Mid-Period Interruption

Depreciation run terminated mid-period. Some assets depreciated, others not. Standard Rollback Depreciation cannot recover this state. FA-02 documents the exact assets processed for the Oracle Support SR.

Post-Run

Create Journal Entries Not Run

Depreciation completed but GL journals not yet created. FA assets show correct NBV in FA_BOOKS but GL does not reflect the period depreciation. FA-02 identifies the depreciation batch ID and the CJE submission parameters.

Tables Examined

TableModulePurpose
FA_BOOK_CONTROLSFABook period status and DEPRN_STATUS lock flag
FA_DEPRN_PERIODSFAPeriod depreciation run history — batch ID, completion
FA_DEPRN_SUMMARYFADepreciation summary per asset per period
FA_DEPRN_DETAILFADepreciation detail by distribution — GL account level
FA_BOOKSFAAsset book data — cost, NBV, method, life, date in service
FA_ADDITIONS_BFAAsset master — category, date in service, status
GL_PERIOD_STATUSESGLGL period open status for journal creation
Decision Framework

How Every Fix Decision Is Made

Before any data is modified in a production Oracle database, AP-01 walks through a four-stage decision process. Every condition identified by the diagnostic maps to exactly one resolution path.

1
First Option — Always
Can the front end fix this?

Oracle's own forms and concurrent programs are always the first option. If the condition can be corrected through Oracle's standard UI — a form, a concurrent program, a setup screen — that path is taken first. No consultant SQL required, no database risk, and the fix is fully supported by Oracle. The diagnostic identifies these conditions explicitly and states the exact front-end navigation path.

✓ Functional Fix
2
When Front End Is Not Available
Is a direct data fix safe to apply?

When the front-end path is unavailable or would require an unacceptable volume of manual steps, a direct fix is evaluated against explicit criteria. All of the following must be true before proceeding:

The fix mirrors exactly what Oracle's own code would have done if the underlying condition were corrected
All dependent tables have been identified and will be updated in the same transaction
The fix is fully reversible — a single INSERT from the backup table restores the original state
The environment patch level has been confirmed against the fix logic version
⚡ Direct Fix
3
Hard Stops — No Exceptions
Does this require Oracle Support?

Certain table areas are never touched directly, regardless of how well the underlying structure is understood. The diagnostic flags these conditions and generates the Service Request documentation:

XLA subledger tablesXLA_EVENTS, XLA_AE_HEADERS — incorrect changes corrupt the subledger audit trail in ways undetectable until period close fails or an auditor requests a reconciliation
Workflow engine tablesWF_ITEMS, WF_ITEM_ACTIVITY_STATUSES — ad-hoc DML can corrupt the workflow engine state instance-wide
Recurring conditions after a fix — indicates a code defect, not a data error. Documented and submitted as a Service Request with a reproducible test case
⚠ Oracle Support
4
For All Approved Direct Fixes
Backup → Execute → Verify → Document

A timestamped backup table is created and row-count verified before the first UPDATE fires. Explicit parameter confirmation is required — the script will not self-execute. After execution, a verification query confirms the expected state. A complete change record — rows affected, before and after values, database username, timestamp — is written to the FIX_BACKUP_REGISTRY and becomes the primary artifact in the knowledge base entry for this incident.

📋 Documented
Condition Identified Resolution Path Notes
Zero-cost asset — unexpected zero after adjustment Direct Fix FA-02 identifies the cost adjustment transaction that produced the zero cost, confirms whether the replacement cost entry is missing, and corrects FA_BOOKS.COST with full backup before the depreciation run.
Catch-up depreciation unexpectedly large Direct Fix FA-02 identifies the catch-up calculation — periods affected, amount per period — and confirms whether the date in service is correct. If the date is wrong, FA-02 corrects DATE_PLACED_IN_SERVICE in FA_ADDITIONS_B with full backup.
Partial depreciation run — interrupted mid-period Oracle Support Partial run recovery cannot be performed with standard tools. FA-02 documents the exact state — assets processed vs remaining, FA_DEPRN_PERIODS status — for the Oracle Support SR. Recovery requires Support-provided scripts.
Period locked — DEPRN_STATUS not REQUIRED Functional First If the period shows RUNNING or COMPLETED unexpectedly, FA-02 investigates whether a prior incomplete run is blocking. Rollback Depreciation via Assets > Depreciation > Rollback if the run was completed in error.
Assets with life expired but not retired Functional First FA-02 identifies assets past their end of life that are still active. These should be reviewed for physical retirement and processed via the Retirements form.
Depreciation method not allowed for book Functional First FA-02 identifies assets using a depreciation method that is not enabled for the book in FA_BOOK_CONTROLS. The method must be added to the book or the asset recategorized.
Create Journal Entries not run after depreciation Functional First Submit Create Journal Entries for Fixed Assets concurrent program. FA-02 confirms depreciation completed (FA_DEPRN_PERIODS.DEPRECIATION_BATCH_ID populated) before CJE submission.
Tax book not depreciated after corporate book Functional First Run depreciation for the TAX book separately. FA-02 identifies the tax book period status and the assets requiring tax depreciation for the period.
Safeguards

Nothing Executes Without a Safety Net

Before any data fix runs, the script verifies pre-flight conditions and creates a complete verified backup. If any check fails, the script aborts. There is no partial execution path.

Pre-Flight Checks — All Must Pass
POSTED_FLAG = 'N'
Will not modify a posted transaction under any circumstances
ACCOUNTING_EVENT_ID IS NULL
Will not modify rows with an active or pending XLA accounting event
No active database lock
Checks V$LOCK — will not proceed if another session holds a lock on target rows
CONS_BACKUP schema writable
Backup schema must be accessible before any DML is permitted
Explicit confirmation required
Script outputs a confirmation prompt — DML does not execute until consultant enters the case number as the execution parameter
Backup Methodology

Before the first UPDATE fires, the script creates a complete copy of every row to be modified. Tables are named CONS_BACKUP.<TABLE>_<CASE#> and persist permanently after execution.

FA_BOOKS
FA_DEPRN_SUMMARY
FA_DEPRN_DETAIL
FA_BOOK_CONTROLS
Row count verified after backup creation. If backup fails for any reason the script aborts without executing any DML. Rollback is a single INSERT from the backup table. No reconstruction required.
FA-02 — Pre-Flight & Backup Verification
════════════════════════════════════════════════════════════
  PRE-FLIGHT SAFETY CHECK
════════════════════════════════════════════════════════════
  Book               : US CORP
  Period             : FEB-2026
  DEPRN_STATUS       : REQUIRED ✓ — not yet run
  Partial Run        : None detected ✓
  CONS_BACKUP Schema : Accessible ✓
────────────────────────────────────────────────────────────
  ALL PRE-FLIGHT CHECKS PASSED
════════════════════════════════════════════════════════════
  Creating : CONS_BACKUP.FA_BOOKS_492810
  Rows     : 3 zero-cost asset rows backed up ✓
  Registry : FIX_BACKUP_REGISTRY — ID 5058 created ✓
────────────────────────────────────────────────────────────
  BACKUP COMPLETE — Pre-run corrections applied
════════════════════════════════════════════════════════════
  Enter case number to confirm : 492810
  Confirmed. Corrections applied — safe to run depreciation.
════════════════════════════════════════════════════════════
Knowledge Base

Every Execution Produces a Record

The knowledge base article is generated automatically from the script's execution output. No manual documentation required. It becomes the institutional record — for the team, for auditors, and for every future engagement in the same environment.

Zero Manual Effort
Every field — environment, tables, before/after values, backup reference, root cause, prevention — is generated from actual execution output. Nothing is written by hand.
Patterns Surface Over Time
The first engagement produces findings. The third produces patterns. Recurring conditions that are invisible as individual incidents become obvious as knowledge base trends.
Survives Staff Turnover
The knowledge base is an institutional record of the Oracle environment. A new manager, a new DBA, or an external auditor can read exactly what happened, what was done, and what prevents recurrence.
KB-FA-492810-001
Depreciation Pre-Run Diagnostic — Zero Cost Assets and Catch-Up Depreciation Review
EBS R12.2.10 · Fixed Assets
● RESOLVED
Symptom
FA-02 pre-run diagnostic for US CORP FEB-2026: 3 assets with zero cost identified (112801-112803) and 1 asset with $8,200 catch-up depreciation (112841 backdated to AUG-2025). Depreciation not yet run — pre-flight review completed before submission.
Root Cause
Zero-cost assets: 3 assets had cost adjustment transactions that zeroed out the cost in the current period — adjustments were entered as part of a lease-to-buy reclassification but the replacement cost entry was not yet processed. Catch-up: Asset 112841 was added with AUG-2025 date in service reflecting the actual deployment date, producing 6 periods of catch-up.
Tables
FA_BOOKS — COST = 0 (Assets 112801, 112802, 112803 — post-adjustment)
FA_BOOKS — DATE_PLACED_IN_SERVICE = 01-AUG-2025 (Asset 112841 — catch-up calculated)
Fix Applied
Replacement cost entries processed for assets 112801-112803 before depreciation run. Catch-up for asset 112841 confirmed as expected by Controller. Depreciation run submitted — 4,841 assets processed. Create Journal Entries run for FEB-2026.
Prevention
FA-02 pre-run diagnostic should run 2 business days before depreciation submission to allow time for zero-cost and catch-up review. Asset additions with prior-period dates in service to be flagged for Controller review before the depreciation run.
Tags
FADepreciationFA_DEPRN_SUMMARYCatch-up DepreciationZero CostFA_BOOK_CONTROLSEBS R12.2

Oracle Documentation References

References the Oracle public documentation for this diagnostic area. These links open directly on docs.oracle.com.

R12 Guide (PDF)Title & ChapterDetail
120faug.pdfOracle Assets User Guide — DepreciationDepreciation program, prorate conventions, depreciation methods, and error resolution
120faug.pdfOracle Assets User Guide — Chapter 2: Depreciation Rules (Books)pp. 2-5 to 2-11: Book setup, depreciation method, and prorate convention configuration
120faug.pdfOracle Assets User Guide — ReportsDepreciation reports including Asset Register and depreciation projections

Ready to Resolve This in Your Environment?

FA-02 is one of 65 diagnostic scripts covering every major Oracle EBS and Fusion module. William A. Green Consulting runs the script in your environment, applies guided data fixes, and builds the knowledge base that prevents the same issues from recurring.

Schedule a Discovery Call → ← View All 65 Scripts

See this script run autonomously — Oracle AI Platform →