PO 3 types of Match Approval Levels in Oracle EBS R12

 

Discrete BOM Setup Flow in Oracle EBS R12

1. Define Inventory Organization

2. Define BOM Parameters and WIP Parameters

3. Create Assembly Item

4. Create Component Items

5. Enable item attributes:

   - Inventory Item

   - Stockable

   - Transactable

   - BOM Allowed

   - Build in WIP

   - Costing Enabled

6. Define Departments and Resources

7. Define Routing:

   - Operation sequence

   - Department

   - Resource usage

8. Define BOM:

   - Assembly item

   - Components

   - Quantity per assembly

   - Operation sequence

   - Supply type

   - Effectivity date

9. Run Cost Rollup if required

10. Create Discrete Job

11. Release Job

12. Issue Materials

13. Complete Assembly

14. Check Costing and GL Posting

Main Tables Used:

MTL_SYSTEM_ITEMS_B / MTL_SYSTEM_ITEMS_KFV

BOM_BILL_OF_MATERIALS

BOM_INVENTORY_COMPONENTS

BOM_OPERATIONAL_ROUTINGS

BOM_OPERATION_SEQUENCES

BOM_OPERATION_RESOURCES

BOM_DEPARTMENTS

BOM_RESOURCES

WIP_DISCRETE_JOBS

WIP_ENTITIES

WIP_REQUIREMENT_OPERATIONS

CST_ITEM_COSTS

CST_COST_TYPES

AIM MD.050 Application Functional Design Oracle E-Business Suite R12 / R12.2

AIM MD.050

Application Functional Design

Oracle E-Business Suite R12 / R12.2

 

 

 

Client / Organization	[Client Name]
Project Name	[Project Name]
Extension Name	[XX Extension / Custom Object Name]
Oracle Module	[AP / AR / GL / PO / OM / INV / HRMS / Other]
Document ID	MD.050-[Project]-[Extension Code]
Version	0.1 Draft
Prepared By	[Functional Consultant Name]
Date	05-Jun-2026

 

 

 

Template note: This document is an original editable MD.050-style functional design template for Oracle EBS R12 application extensions. Replace bracketed placeholders with project-specific details. It is not an official Oracle-owned AIM template.

 

Document Control

Revision History

Version	Date	Author	Change Summary	Status
0.1	[DD-Mon-YYYY]	[Name]	Initial draft for functional review	Draft
0.2	[DD-Mon-YYYY]	[Name]	Updated based on business/process owner comments	Draft
1.0	[DD-Mon-YYYY]	[Name]	Approved baseline for MD.070 technical design	Approved

 

Reviewers and Approvers

Role	Name	Organization	Review / Approval Responsibility	Signature / Date
Business Process Owner	[Name]	[Department]	Confirms business requirement and acceptance criteria	[Sign / Date]
Functional Lead	[Name]	[SI / Client]	Confirms functional completeness and alignment with BR100	[Sign / Date]
Technical Lead	[Name]	[SI / Client]	Confirms technical feasibility and MD.070 handoff readiness	[Sign / Date]
Security / Compliance	[Name]	[Department]	Confirms access, audit, SOD, and control requirements	[Sign / Date]
Project Manager	[Name]	[Organization]	Approves baseline for build phase	[Sign / Date]

 

Document Distribution

Recipient	Role / Team	Purpose	Distribution Method
[Name]	[Functional Team]	Review and comment	Email / Repository
[Name]	[Technical Team]	Technical design input	Repository
[Name]	[Testing Team]	Test script preparation	Repository

 

Table of Contents

1. Purpose and Scope

2. AIM MD.050 Usage Guidance

3. Requirement and Traceability Summary

4. Current Business Process / Gap

5. Proposed Functional Design

6. Detailed Application Extension Specification

7. Data, Security, Controls, and Compliance

8. Reporting / Concurrent Processing

9. Integration, Workflow, and Notifications

10. Error Handling, Audit, and Operations

11. Testing and Acceptance Criteria

12. MD.070 / MD.060 Handoff Checklist

13. Open Issues, Risks, and Assumptions

14. Appendices and References

Word tip: To create an automatic table of contents, apply Heading 1/2/3 styles, then use References > Table of Contents in Microsoft Word.

 

1. Purpose and Scope

Purpose. This MD.050 document defines the functional design for an Oracle E-Business Suite R12 application extension. It should describe what the extension must do, why it is required, how users will interact with it, what data it will use, what controls are needed, and what outputs are expected. It should provide enough functional clarity for the technical team to prepare MD.070 technical design, MD.060 database extension design where needed, development estimates, and test scripts.

Scope. Use this template for custom forms, OA Framework pages, reports, concurrent programs, workflows, alerts, personalizations, extensions using public APIs, interface-related user actions, validations, or module-specific functional extensions in Oracle EBS R12/R12.2.

Scope Definition

Area	In Scope	Out of Scope / Deferred	Remarks
Business process	[Describe included business process steps]	[Describe excluded process steps]	[Notes]
Oracle module	[e.g., Payables, Purchasing, General Ledger]	[Modules not impacted]	[Notes]
Organization scope	[Ledger / OU / Inventory Org / Business Group]	[Excluded organizations]	Consider MOAC and security profile impact
Extension object	[Form / Report / Concurrent Program / Workflow / OAF Page]	[Objects not covered]	[Notes]
Data scope	[Master / Transaction / Reference data]	[Excluded data elements]	[Notes]

 

2. AIM MD.050 Usage Guidance

When to prepare MD.050. Prepare MD.050 after the business requirement is confirmed and before technical design/build starts. It should normally be linked to BR100 configuration decisions, RD.020/RD.050 requirement analysis, BP.080 future process design, MD.070 technical design, TE test scripts, and user acceptance criteria.

MD.050 Position in the Deliverable Chain

Input / Output	Related Deliverable	How It Is Used
Input	BR100 Configuration Document	Confirms standard setup decisions and shows why an extension is needed.
Input	Business Requirement / Gap Log	Identifies the requirement, gap, priority, owner, and acceptance basis.
Input	Future Process Design	Confirms how the extension fits into the target operating process.
Output	MD.060 Database Extension Design	Used if new custom tables, views, indexes, sequences, or data structures are required.
Output	MD.070 Technical Design	Translates this functional design into technical build specifications.
Output	TE Test Scripts	Converts scenarios, validation rules, and outputs into SIT/UAT test cases.

 

Good practice: Do not put deep code logic in MD.050. Keep MD.050 functional. Put PL/SQL package details, table DDL, APIs, architecture decisions, concurrent program executable details, and deployment instructions in MD.060/MD.070/MD.120 as applicable.

 

3. Requirement and Traceability Summary

Requirement Traceability Matrix

Req ID	Business Requirement / Gap	Priority	Source	Functional Design Section	Test Scenario ID
REQ-001	[Requirement statement]	High / Medium / Low	[BR100 / Gap Log / Workshop]	[Section #]	TS-001
REQ-002	[Requirement statement]	High / Medium / Low	[Source]	[Section #]	TS-002
REQ-003	[Requirement statement]	High / Medium / Low	[Source]	[Section #]	TS-003

 

Business Benefit / Justification

Benefit Category	Expected Benefit	Measurement / Evidence	Owner
Compliance	[e.g., enforce approval evidence before payment]	[Audit exception reduction / control report]	[Owner]
Efficiency	[e.g., reduce manual Excel reconciliation]	[Processing time reduction]	[Owner]
Data quality	[e.g., mandatory project code validation]	[Error rate / rejected transaction count]	[Owner]

 

4. Current Business Process / Gap

[Describe current process, pain points, manual workarounds, exception cases, and why standard Oracle functionality is insufficient: Replace this text with project-specific content.]

Current Process and Gap Analysis

Step	Current Process	Issue / Gap	Standard EBS Option Considered	Reason Extension Is Required
1	[Describe current user/business step]	[Problem]	[Standard function / setup / personalization]	[Why not sufficient]
2	[Describe current user/business step]	[Problem]	[Standard function / setup / personalization]	[Why not sufficient]
3	[Describe current user/business step]	[Problem]	[Standard function / setup / personalization]	[Why not sufficient]

 

Business Rules from Current/Future Process

Rule ID	Rule Description	Applies To	Exception Handling	Owner
BR-001	[Rule statement, e.g., invoice must not be submitted if tax registration number is missing]	[OU / Supplier Type / Transaction Type]	[Warning / Error / Approval Required]	[Owner]
BR-002	[Rule statement]	[Scope]	[Handling]	[Owner]

 

 

 

 

 

 

5. Proposed Functional Design

Design summary. Describe the target extension from a business and user perspective. The description should be clear enough for stakeholders to validate the behavior without reading technical code.

Extension Overview

Item	Description
Extension Name	[XX_EXTENSION_NAME]
Extension Type	[Custom Form / OAF Page / Report / Concurrent Program / Workflow / Alert / Personalization / Other]
Primary Oracle Module	[AP / AR / GL / PO / OM / INV / HRMS / Other]
Business Owner	[Name / Department]
Frequency of Use	[Real-time / Daily / Weekly / Period close / On demand]
Expected Users	[Responsibilities, roles, departments, or user groups]
High-Level Behavior	[One-paragraph description of the expected extension behavior]
Success Criteria	[Business-visible result after implementation]

 

High-Level Process Flow

Sequence	Actor / System	Action	Input	Output / Result
1	[User / System]	[Action]	[Input]	[Output]
2	[User / System]	[Action]	[Input]	[Output]
3	[User / System]	[Action]	[Input]	[Output]
4	[User / System]	[Action]	[Input]	[Output]

 

Functional Flow Diagram Placeholder

Insert process flow, swimlane diagram, screenshot mock-up, or Visio export here. Include responsibility, navigation path, user action, system validation, approval step, and output step where applicable.

 

6. Detailed Application Extension Specification

6.1 Navigation, Responsibility, Menu, and Function

Navigation and Access

Object	Value / Design Decision	Remarks
Responsibility	[Responsibility name(s)]	[Existing or new responsibility]
Menu	[Menu name]	[Add function to menu if applicable]
Function	[Function name / code]	[Form function / OAF function / report function]
Navigation Path	[Responsibility > Menu > Function]	[User-facing path]
Concurrent Program	[Program short name]	[If applicable]
Request Group	[Request group name]	[If applicable]

 

6.2 User Interface / Form / OAF Page Design

Screen / Page Design Summary

Screen / Region	Purpose	Main Actions	Comments
[Header Region]	[Purpose]	[Create / Search / Update / Submit]	[Notes]
[Lines Region]	[Purpose]	[Add / Delete / Validate]	[Notes]
[Review / Confirmation]	[Purpose]	[Approve / Reject / Confirm]	[Notes]

 

Field-Level Functional Specification

Field / Item	Prompt / Label	Data Type	Mandatory	Default / Derivation	Validation Rule	LOV / Source
[FIELD_1]	[User label]	[Text / Number / Date]	Y/N	[Default value]	[Validation]	[Lookup / SQL / Table]
[FIELD_2]	[User label]	[Text / Number / Date]	Y/N	[Default value]	[Validation]	[Lookup / SQL / Table]
[FIELD_3]	[User label]	[Text / Number / Date]	Y/N	[Default value]	[Validation]	[Lookup / SQL / Table]

 

6.3 Business Validations

Validation Rules

Validation ID	Trigger Point	Condition	System Response	Message Text	Severity
VAL-001	[On save / Submit / Import / Approval]	[Condition]	[Reject / Warning / Derive / Route]	[Message]	Error / Warning / Info
VAL-002	[Trigger]	[Condition]	[Response]	[Message]	Error / Warning / Info
VAL-003	[Trigger]	[Condition]	[Response]	[Message]	Error / Warning / Info

 

6.4 Descriptive Flexfield, Key Flexfield, Lookup, and Profile Impact

Flexfield / Lookup / Profile Impact

Component	Existing / New	Name	Purpose	Values / Structure	Owner
DFF	Existing / New	[DFF Name / Context]	[Purpose]	[Segments]	[Owner]
KFF	Existing / New	[KFF Name]	[Purpose]	[Segments / COA impact]	[Owner]
Lookup	Existing / New	[Lookup Type]	[Purpose]	[Codes / Meanings]	[Owner]
Profile Option	Existing / New	[Profile Name]	[Purpose]	[Site / Resp / User values]	[Owner]

 

6.5 Data Elements and Derivation

Data Derivation Matrix

Business Data Element	Source / Derivation	Transformation Rule	Display / Storage	Required for Test?
[Supplier Name]	[AP_SUPPLIERS / Vendor master]	[Derivation logic]	[Displayed / Stored]	Y/N
[Operating Unit]	[MOAC context / org_id]	[Derivation logic]	[Displayed / Stored]	Y/N
[Amount]	[Transaction source]	[Currency / rounding logic]	[Displayed / Stored]	Y/N

 

7. Data, Security, Controls, and Compliance

7.1 Multi-Org, Ledger, Inventory Organization, and Localization Impact

Organization and Localization Impact

Dimension	Impact / Decision	Control Requirement	Remarks
Ledger / Legal Entity	[Impact]	[Control]	[Notes]
Operating Unit / MOAC	[Impact]	[Control]	Validate org_id context and security profile
Inventory Organization	[Impact]	[Control]	[Notes]
Business Group	[Impact]	[Control]	[HRMS impact if applicable]
Localization / Tax	[Impact]	[Control]	[Country-specific rules]

 

 

 

7.2 Security, Roles, and Segregation of Duties

Security Design

Security Area	Functional Requirement	Design Decision	SOD / Audit Consideration
Responsibility access	[Who can access]	[Responsibility / menu / function setup]	[SOD risk]
Data access	[Which OU/ledger/org data]	[MOAC / security profile / grants]	[Data confidentiality]
Action control	[Create/update/approve/delete]	[Role-based restrictions]	[Maker-checker / approval evidence]
Sensitive data	[PII / payroll / bank / supplier data]	[Masking / restricted responsibility]	[Audit requirement]

 

7.3 Controls, Audit, and Compliance

Control Matrix

Control ID	Control Objective	Functional Control	Evidence Produced	Test Scenario
CTRL-001	[Prevent unauthorized update]	[Menu/function/security rule]	[Access report / audit log]	TS-SEC-001
CTRL-002	[Ensure complete processing]	[Control total / exception report]	[Concurrent request output]	TS-CON-001
CTRL-003	[Ensure valid master data]	[LOV / validation rule]	[Error log / screenshot]	TS-VAL-001

 

8. Reporting / Concurrent Processing

Use this section if the extension includes a report, extract, concurrent program, request set, or scheduled process.

Concurrent Program / Report Summary

Item	Functional Specification
Program / Report Name	[User-facing name]
Short Name	[XX_SHORT_NAME]
Purpose	[Business purpose]
Output Type	[PDF / Excel / Text / XML Publisher / BI Publisher / Other]
Execution Mode	[On demand / Scheduled / Request set / Triggered by event]
Expected Volume	[Records per run / peak volume]
Retention Requirement	[How long output/log should be retained]
Restart / Rerun Requirement	[Safe rerun logic / duplicate prevention]

 

Parameter Specification

Seq	Parameter Name	Data Type	Mandatory	Default	LOV / Validation	Remarks
10	[Operating Unit]	Number / Text	Y/N	[Default]	[LOV]	[Notes]
20	[From Date]	Date	Y/N	[Default]	[Validation]	[Notes]
30	[To Date]	Date	Y/N	[Default]	[Validation]	[Notes]

 

Output Layout Specification

Column / Section	Description	Source / Derivation	Sort / Group	Format
[Column 1]	[Business meaning]	[Source]	[Sort/Group]	[Format]
[Column 2]	[Business meaning]	[Source]	[Sort/Group]	[Format]
[Totals]	[Control total / subtotal]	[Derivation]	[Group level]	[Currency / number format]

 

9. Integration, Workflow, and Notifications

9.1 Integration Touchpoints

Integration / Interface Touchpoints

Touchpoint	Direction	Source	Target	Frequency	Functional Requirement
[Inbound / Outbound process]	Inbound / Outbound	[Source system]	[Target system]	[Real-time / Batch]	[Business behavior]
[API call / Event]	Inbound / Outbound	[Source]	[Target]	[Frequency]	[Requirement]

 

9.2 Workflow / Approval / Notification Design

Workflow / Notification Matrix

Event / Trigger	Recipient / Role	Condition	Notification Content	Action Required	Escalation
[Submit]	[Approver / User Role]	[Condition]	[Subject and message summary]	Approve / Reject / FYI	[Rule]
[Exception]	[Support / Business Owner]	[Condition]	[Message summary]	Resolve / FYI	[Rule]

 

10. Error Handling, Audit, and Operations

Error and Exception Handling

Error Scenario	Detection Point	User/System Message	Recovery Action	Owner
[Invalid input]	[UI / Program / API]	[Message text]	[Correct data and resubmit]	[Business/User]
[Missing setup]	[Program validation]	[Message text]	[Update setup / rerun]	[Functional/Admin]
[Technical failure]	[Concurrent log / workflow error]	[Message text]	[Raise incident / rerun safely]	[Support/DBA]

 

Operations and Support Requirements

Area	Requirement	Owner	SLA / Frequency
Monitoring	[Concurrent request / workflow / interface monitoring]	[Support role]	[Daily / Hourly / On demand]
Housekeeping	[Purge / archive / log cleanup requirement]	[Owner]	[Frequency]
Incident handling	[Known error and resolution path]	[Owner]	[SLA]
Period close impact	[Impact on close checklist / cut-off]	[Owner]	[Frequency]

 

11. Testing and Acceptance Criteria

Test scripts should be traceable to business requirements, validation rules, security rules, expected outputs, and exception conditions. Include both positive and negative tests.

Acceptance Criteria

AC ID	Acceptance Criterion	Mapped Requirement	Evidence Required
AC-001	[System performs required business action correctly]	REQ-001	[Screenshot / output / log]
AC-002	[System blocks invalid transaction with correct message]	REQ-002	[Screenshot / error log]
AC-003	[Authorized users can access; unauthorized users cannot]	REQ-003	[Access test evidence]

 

Functional Test Script Template

Test ID	Scenario	Preconditions	Steps	Expected Result	Actual Result	Status
TS-001	[Positive scenario]	[Setup / data required]	1. [Step] 2. [Step] 3. [Step]	[Expected result]	[To be completed during test]	Pass / Fail
TS-002	[Negative validation scenario]	[Setup / data required]	1. [Step] 2. [Step]	[Expected error/warning]	[To be completed]	Pass / Fail
TS-003	[Security scenario]	[User/responsibility]	1. [Step] 2. [Step]	[Access allowed/denied]	[To be completed]	Pass / Fail

 

Regression Test Considerations

Area	Regression Risk	Recommended Test
Standard transaction entry	Extension may affect normal transaction flow	Create/update/query standard transactions without using extension-specific data
Period close	Report or validation may block close activity	Run close checklist where relevant
Security	Menu/function changes may expose unauthorized function	Test representative responsibilities
Performance	New validation/report may slow large-volume processing	Test realistic data volume and peak-period criteria

 

12. MD.070 / MD.060 Handoff Checklist

Technical Design Handoff Checklist

Checklist Item	Required?	Status	Remarks
Functional requirement and acceptance criteria are complete	Y	Open / Complete	[Remarks]
Field-level specification is complete	Y/N	Open / Complete	[Remarks]
Validation and error messages are defined	Y/N	Open / Complete	[Remarks]
Security/responsibility/menu/function impact is defined	Y/N	Open / Complete	[Remarks]
Concurrent program/report parameters and output are defined	Y/N	Open / Complete	[Remarks]
New database objects identified for MD.060	Y/N	Open / Complete	[Remarks]
API/interface/workflow touchpoints identified	Y/N	Open / Complete	[Remarks]
Performance and volume assumptions documented	Y/N	Open / Complete	[Remarks]
Test scenarios and acceptance criteria mapped	Y/N	Open / Complete	[Remarks]

 

13. Open Issues, Risks, Assumptions, and Dependencies

Open Issues Log

Issue ID	Description	Owner	Target Date	Status	Impact if Unresolved
ISS-001	[Open functional decision]	[Owner]	[Date]	Open	[Impact]
ISS-002	[Open setup/data/security issue]	[Owner]	[Date]	Open	[Impact]

 

Risks and Mitigations

Risk ID	Risk Description	Probability	Impact	Mitigation	Owner
RISK-001	[Functional ambiguity / late change]	Low / Med / High	Low / Med / High	[Mitigation]	[Owner]
RISK-002	[Performance / data volume / security risk]	Low / Med / High	Low / Med / High	[Mitigation]	[Owner]

 

Assumptions and Dependencies

ID	Type	Statement	Owner / Dependency	Validation Date
ASM-001	Assumption	[Assumption statement]	[Owner]	[Date]
DEP-001	Dependency	[Dependency on setup/data/interface/user decision]	[Owner]	[Date]

 

14. Appendices and References

14.1 Glossary

Glossary

Term	Meaning
AIM	Application Implementation Methodology.
MD.050	Application Extensions Functional Design deliverable.
MD.060	Database Extension Design deliverable.
MD.070	Application Extensions Technical Design deliverable.
BR100	Application Setup / Configuration document commonly used in Oracle implementation projects.
MOAC	Multi-Org Access Control in Oracle E-Business Suite.
DFF / KFF	Descriptive Flexfield / Key Flexfield.
Concurrent Program	EBS background process submitted through the Standard Request Submission framework.

 

14.2 Official Oracle Documentation References

·        Oracle E-Business Suite Release 12.2 Documentation Library

·        Oracle E-Business Suite Developer's Guide, Release 12.2

·        Oracle E-Business Suite User's Guide, Release 12.2

·        Oracle Application Framework Developer's Guide, Release 12.2

14.3 Sample Mini Example - XXPO Approval Exception Report

Example purpose. The business requires an exception report listing purchase orders approved outside policy limits. The report will help Procurement Compliance review approval exceptions before month-end.

Sample Filled Functional Design Snapshot

Area	Sample Content
Extension Type	Concurrent Program / BI Publisher Report
Module	Purchasing
Users	Procurement Manager, Internal Audit
Parameters	Operating Unit, Buyer, From Approval Date, To Approval Date, Exception Type
Key Validation	To Approval Date must be equal to or greater than From Approval Date.
Output	PO Number, Supplier, Buyer, PO Amount, Approval Limit, Approver, Exception Reason, Approval Date
Acceptance Criteria	Report returns only policy exceptions for selected OU/date range and totals exception amount by buyer.

 

14.4 Document Completion Quality Checklist

·        Every requirement has a mapped functional design section and test scenario.

·        The design explains why standard Oracle EBS setup/personalization is insufficient.

·        Security, responsibility, menu, request group, and MOAC impacts are documented.

·        Field rules, defaults, validations, error messages, and output layout are clear.

·        Operational support, monitoring, rerun, and exception handling are covered.

·        Technical handoff items for MD.060 and MD.070 are complete.

·        Open issues are assigned to owners and do not block build approval unless explicitly accepted.

Final Approval Statement

By approving this document, the business owner and project stakeholders confirm that the functional design is sufficiently complete to proceed with technical design and build, subject to the open issues and assumptions recorded above.