SYS-07 EBS R12.x System / Technical Tier 2 Data Fix

Security & Role Diagnostic (EBS)

User-responsibility mapping, expired accounts, orphaned grants, menu function exclusions, profile option conflicts at all levels, operating unit access setup, and password policy compliance.

PlatformOracle EBS R12.x
Input RequiredFND Username or Responsibility Name
Diagnostic Checks30+
Data Sources8 Oracle tables
Fix Options4 guided fixes
Backup CreatedYes — Automatic

Why This Fails — and What It Costs

Oracle EBS security is built on a responsibility-based access model. A user is granted one or more FND_RESPONSIBILITY assignments through FND_USER_RESP_GROUPS_ALL, and each responsibility provides access to a specific set of menus, functions, and reports. When a user cannot access a function they should have, the root cause is almost always one of four conditions: the responsibility is not assigned to the user, the responsibility's menu hierarchy does not include the function, a function security exclusion is blocking access, or the user's FND account is end-dated or suspended.

The most operationally impactful EBS security failure is the responsibility-to-menu gap. Oracle EBS responsibilities reference a top-level menu through FND_MENUS. That menu contains submenus and function entries through FND_MENU_ENTRIES. A function exclusion in FND_RESP_FUNCTIONS can selectively remove a function from a responsibility without changing the menu structure. When a user reports they cannot see a specific menu item, the diagnostic requires traversing the full menu hierarchy — menu to submenu to function — and checking every FND_RESP_FUNCTIONS exclusion for their responsibility. This is not visible in any Oracle EBS screen without running custom queries.

Profile options are the second major security complexity. Profile options control Oracle EBS behavior at the site, application, responsibility, and user levels. A profile option set at the responsibility level overrides the site-level setting for all users of that responsibility. When a user reports unexpected behavior — a form that opens read-only, a button that is greyed out, an approval limit that seems wrong — the root cause is often a profile option set at the wrong level or with the wrong value. SYS-07 reads the full profile option hierarchy for the reported user and responsibility.

SYS-07 runs a complete Oracle EBS security diagnostic — FND_USER account status and end-date, responsibility assignments and effective dates, menu-to-function traversal for the reported inaccessible function, FND_RESP_FUNCTIONS exclusion check, profile option values at all four levels, and operating unit security profile validation for multi-org access.

What This Script Diagnoses

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

Account & Responsibility
FND_USER account status, end date, and employee linkage. All responsibility assignments with effective dates — current, future-dated, and recently expired. Identifies missing responsibilities and expired assignments in one pass.
Menu & Function Traversal
Full menu hierarchy traversal from the responsibility's top-level menu down to the reported inaccessible function — confirming whether the function is in the menu structure at all. FND_RESP_FUNCTIONS exclusion check for every assigned responsibility.
Profile Option Analysis
Profile option values at all four levels — site, application, responsibility, and user — for the key options affecting the reported behavior. Identifies options set at the wrong level or with values that override the correct site-level configuration.
Multi-Org Security
MO Operating Unit and MO Security Profile configuration at user and responsibility level. Identifies operating units the user cannot access and the profile level where the restriction is set. Essential for multi-org environments where users work across multiple OUs.

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.

SYS-07 — SYS-07 Diagnostic Report
════════════════════════════════════════════════════════════
  ORACLE EBS R12 — SECURITY & ROLE DIAGNOSTIC
════════════════════════════════════════════════════════════
  FND Username       : JMARTINEZ
  Issue Reported     : Cannot access AP Invoice Workbench
  Case Number        : SYS-524820
  Report Date        : 23-FEB-2026 13:15:30
════════════════════════════════════════════════════════════

[ SECTION 1 — FND_USER STATUS ]            STATUS: ✓ ACTIVE
────────────────────────────────────────────────────────────
  JMARTINEZ — ACTIVE, no end date ✓
  Employee Link      : PER_ALL_PEOPLE_F — linked to EMP-10482 ✓

[ SECTION 2 — RESPONSIBILITY ASSIGNMENTS ] STATUS: ✗ ISSUE
────────────────────────────────────────────────────────────
  Payables Manager   : Assigned — active, no end date ✓
  AP Invoice Entry   : NOT ASSIGNED ✗
  AP Invoice Inquiry : Assigned — active ✓
  ✗ FAIL: AP Invoice Entry responsibility not assigned — user has Inquiry only

[ SECTION 3 — MENU / FUNCTION CHECK ]      STATUS: ✓ MENU OK
────────────────────────────────────────────────────────────
  Payables Manager menu → Invoices → Invoice Workbench — function found ✓
  No FND_RESP_FUNCTIONS exclusion for AP_INVOICE_WORKBENCH ✓

[ SECTION 4 — PROFILE OPTIONS ]            STATUS: ⚠ WARNING
────────────────────────────────────────────────────────────
  ⚠ MO: Operating Unit — set at Responsibility level to OU 201 only
  ⚠ JMARTINEZ needs OU 201 and OU 205 — Payables Manager has OU 201 only

[ SECTION 5 — FUNCTION EXCLUSIONS ]        STATUS: ✓ NONE
────────────────────────────────────────────────────────────
  No function exclusions on Payables Manager for reported functions ✓

════════════════════════════════════════════════════════════
  DIAGNOSTIC SUMMARY
════════════════════════════════════════════════════════════
  Missing responsibility: AP Invoice Entry not assigned
  OU profile: Payables Manager OU 201 only — OU 205 needed
  FIX: Assign AP Invoice Entry responsibility via System Administrator > Users
════════════════════════════════════════════════════════════
  Backup Created  : CONS_BACKUP.FND_USER_RESP_GROUPS_524820 ✓
  Registry ID     : 7152
════════════════════════════════════════════════════════════

The Four-Layer Architecture in SYS-07

1
Diagnostic Engine
Runs 30+ checks across FND_USER account status and end-date, responsibility assignments and effective dates, full menu hierarchy traversal from responsibility to function, FND_RESP_FUNCTIONS exclusion check for all assigned responsibilities, profile option values at site/application/responsibility/user levels, and MO operating unit security profile validation.
2
Backup Created
Before any responsibility is assigned or security configuration is changed, CONS_BACKUP.FND_USER_RESP_GROUPS_ALL_<case#> is created with the current state. Profile option changes are backed up in CONS_BACKUP.FND_PROFILE_OPTION_VALUES_<case#>.
3
Guided Data Fix
Responsibility assignments are made via System Administrator > Security > User > Define — never by direct FND_USER_RESP_GROUPS_ALL DML. Profile option changes are made via System Administrator > Profiles > System. Function exclusions are removed via System Administrator > Security > Responsibility > Define.
4
KB Article Generated
Complete KB article generated — username, issue, missing responsibility, profile option gaps, fix applied, access confirmed. Upload directly to your knowledge base.

Backup & Rollback for SYS-07

Every table touched by SYS-07 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 — SYS-07

CONS_BACKUP.FND_USER_RESP_GROUPS_ALL_<case#> CONS_BACKUP.FND_USER_<case#> CONS_BACKUP.FND_PROFILE_OPTION_VALUES_<case#>

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

Pre-Flight Safety Guards

No active 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 SYS-07 execution — written from actual run output. No manual documentation required.

KB-SYS-524820-001 · Script: SYS-07
JMARTINEZ Cannot Access AP Invoice Workbench — Missing AP Invoice Entry Responsibility
JMARTINEZ reports inability to access AP Invoice Workbench. SYS-07 confirms FND_USER account active. FND_USER_RESP_GROUPS_ALL shows AP Invoice Inquiry assigned but AP Invoice Entry not assigned. Menu traversal confirms AP Invoice Workbench function is accessible via Payables Manager responsibility — but JMARTINEZ does not have Payables Manager either.
JMARTINEZ was granted AP Invoice Inquiry when onboarded for read-only review work. New role expanding to full invoice entry was approved by manager on 20-FEB-2026 but IT provisioning only assigned Payables Manager — not AP Invoice Entry which is required for the invoice workbench access path. Additionally, Payables Manager has OU 201 only; JMARTINEZ works across OU 201 and OU 205.
FND_USER_RESP_GROUPS_ALL: JMARTINEZ — AP_INVOICES_INQUIRY assigned, AP_INVOICE_ENTRY not present
FND_PROFILE_OPTION_VALUES: Payables Manager — MO_OPERATING_UNIT = 201 (OU 205 not accessible)
AP Invoice Entry responsibility assigned to JMARTINEZ via System Administrator > Security > User. MO Operating Unit profile updated at user level to include OU 205. JMARTINEZ confirmed able to access Invoice Workbench for both OU 201 and OU 205.
Provisioning checklist updated — AP invoice entry access requires both AP Invoice Entry responsibility and verification of OU coverage. SYS-07 user audit to run quarterly — identifies users with Inquiry responsibilities who should have transactional access.
SystemSecurityFND_USERFND_USER_RESP_GROUPS_ALLResponsibilityProfile OptionsOperating UnitEBS R12.2

What This Script Finds

Access

Responsibility Not Assigned or Expired

The most common EBS security issue. User was provisioned with read-only responsibilities when their role requires transactional access, or a responsibility expired without being renewed. SYS-07 identifies the specific missing responsibility by traversing from the reported inaccessible function back to the responsibility that should contain it.

Exclusion

Function Excluded from Responsibility

A function exclusion in FND_RESP_FUNCTIONS removes a specific menu item or function from a responsibility without changing the menu structure. The user has the correct responsibility but cannot see the function. Not visible in any Oracle EBS screen — requires SYS-07 to detect.

Profile

Profile Option Overriding Expected Behavior

A profile option set at the responsibility or user level overrides the site-level setting — causing a form to open read-only, a limit to be too low, or an operating unit to be inaccessible. SYS-07 reads all four profile levels for the user and responsibility to identify the conflicting setting.

Multi-Org

Operating Unit Not Accessible

User cannot see transactions for a specific operating unit — their MO profile only covers certain OUs. Most common when a user's role expands across a new OU without the security profile being updated. SYS-07 identifies the accessible OUs and the missing OU configuration.

Tables Examined

TableModulePurpose
FND_USERFNDUser accounts — status, end date, employee linkage
FND_USER_RESP_GROUPS_ALLFNDUser-responsibility assignments — effective dates
FND_RESPONSIBILITYFNDResponsibility definitions — menu, data group
FND_MENU_ENTRIESFNDMenu hierarchy — submenus and function entries
FND_RESP_FUNCTIONSFNDFunction exclusions per responsibility
FND_PROFILE_OPTION_VALUESFNDProfile option values at all four levels
FND_PROFILE_OPTIONSFNDProfile option definitions
HR_OPERATING_UNITSHROperating unit definitions for multi-org access
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
Responsibility not assigned — user cannot access function Functional First Assign the responsibility via System Administrator > Security > User > Define. SYS-07 identifies the responsibility name and the effective date to use. Direct DML on FND_USER_RESP_GROUPS_ALL is never used.
Responsibility end-dated — access expired Functional First Extend the responsibility end date via System Administrator > Security > User > Define. SYS-07 identifies the current end date and confirms the correct extension date with the business owner.
Function excluded from responsibility — menu item missing Functional First Remove the function exclusion via System Administrator > Security > Responsibility > Define > Exclusions. SYS-07 identifies the specific FND_RESP_FUNCTIONS row causing the exclusion.
Profile option wrong value or wrong level Functional First Correct the profile option via System Administrator > Profiles > System. SYS-07 identifies the option name, the current level and value causing the issue, and the correct value.
MO Operating Unit not accessible — user cannot see transactions for an OU Functional First Update the MO: Operating Unit profile at user or responsibility level via System Administrator > Profiles > System. SYS-07 identifies which OUs the user needs and which are currently configured.
FND_USER account end-dated — account appears active in HR but expired in Oracle Direct Fix SYS-07 updates END_DATE in FND_USER with full backup after confirming the account should remain active. Standard path is System Administrator > Security > User > Define.
User has no active responsibilities Functional First Assign the correct responsibilities via System Administrator > Security > User > Define. SYS-07 identifies the responsibilities that were previously active from backup or audit trail.
Multi-Org access profile gap — MO Security Profile not assigned Direct Fix SYS-07 updates the MO Security Profile at the appropriate level with full backup. The security profile must be defined in HR_ORGANIZATION_INFORMATION and linked to the correct set of operating units.
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.

FND_USER_RESP_GROUPS_ALL
FND_USER
FND_PROFILE_OPTION_VALUES
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.
SYS-07 — Pre-Flight & Backup Verification
════════════════════════════════════════════════════════════
  PRE-FLIGHT SAFETY CHECK
════════════════════════════════════════════════════════════
  FND Username       : JMARTINEZ
  Account Status     : ACTIVE, no end date ✓
  Responsibilities   : 2 active — AP Invoice Inquiry, Payables Manager
  CONS_BACKUP Schema : Accessible ✓
────────────────────────────────────────────────────────────
  ALL PRE-FLIGHT CHECKS PASSED
════════════════════════════════════════════════════════════
  Creating : CONS_BACKUP.FND_USER_RESP_GROUPS_524820
  Rows     : 2 rows backed up ✓
  Creating : CONS_BACKUP.FND_PROFILE_OPTION_VALUES_524820
  Rows     : 8 profile option rows backed up ✓
  Registry : FIX_BACKUP_REGISTRY — ID 7152 created ✓
────────────────────────────────────────────────────────────
  BACKUP COMPLETE — Assign responsibility via System Administrator
════════════════════════════════════════════════════════════
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-SYS-524820-001
JMARTINEZ Cannot Access AP Invoice Workbench — Missing AP Invoice Entry Responsibility
EBS R12.2.10 · System / Technical
● RESOLVED
Symptom
JMARTINEZ reports inability to access AP Invoice Workbench. SYS-07 confirms FND_USER account active. FND_USER_RESP_GROUPS_ALL shows AP Invoice Inquiry assigned but AP Invoice Entry not assigned. Menu traversal confirms AP Invoice Workbench function is accessible via Payables Manager responsibility — but JMARTINEZ does not have Payables Manager either.
Root Cause
JMARTINEZ was granted AP Invoice Inquiry when onboarded for read-only review work. New role expanding to full invoice entry was approved by manager on 20-FEB-2026 but IT provisioning only assigned Payables Manager — not AP Invoice Entry which is required for the invoice workbench access path. Additionally, Payables Manager has OU 201 only; JMARTINEZ works across OU 201 and OU 205.
Tables
FND_USER_RESP_GROUPS_ALL: JMARTINEZ — AP_INVOICES_INQUIRY assigned, AP_INVOICE_ENTRY not present
FND_PROFILE_OPTION_VALUES: Payables Manager — MO_OPERATING_UNIT = 201 (OU 205 not accessible)
Fix Applied
AP Invoice Entry responsibility assigned to JMARTINEZ via System Administrator > Security > User. MO Operating Unit profile updated at user level to include OU 205. JMARTINEZ confirmed able to access Invoice Workbench for both OU 201 and OU 205.
Prevention
Provisioning checklist updated — AP invoice entry access requires both AP Invoice Entry responsibility and verification of OU coverage. SYS-07 user audit to run quarterly — identifies users with Inquiry responsibilities who should have transactional access.
Tags
SystemSecurityFND_USERFND_USER_RESP_GROUPS_ALLResponsibilityProfile OptionsOperating UnitEBS 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
120funmo.pdfOracle Applications Multiple Organizations Implementation Guide — SecurityMO: Security Profile, MO: Operating Unit, and responsibility-based data access
120apug.pdfOracle Payables User's Guide — Ch. 1: Multiple Organization Access Controlpp. 1-4: MOAC setup for AP responsibility access to multiple operating units
120funmo.pdfOracle Applications Multiple Organizations Implementation GuideFunction security, data security, and business group assignment for EBS roles

Ready to Resolve This in Your Environment?

SYS-07 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 →