1)
Introduction about BOM
2)
BOM parameters
3)
Resource Groups
4)
Department Class
5)
Define Departments
6)
Define the Standard Operations
7)
Define Routing for BOM
8)
Define BOM and query BOM
9)
Discrete Jobs (Create)
10) Query
Resource where its use
11) Comparing
Between two BOM’s
12) Query
Item where it is used in BOM
13) Mass
changes for BOM
14) Attach
Documents to BOM
15) Create
Common BOM
16) Import
BOM
17) Import
Routings
ORACLE E-BUSINESS SUITE R12
Practical Functional Consultant Guide with Editable
Templates
Oracle A.I.M Methodology (Application Implementation Methodology):
|
Document Type |
Functional documentation preparation guide and template |
|
Target System |
Oracle E-Business Suite R12 / R12.2 |
|
Primary Users |
Functional consultants, business analysts, solution leads,
testers, project managers |
|
Deliverables Covered |
BR100, MD50, configuration guide, test scripts,
traceability matrix, sign-off checklist |
|
Version |
1.0 - Editable template |
|
Terminology note: BR100 and MD50 names are widely used in Oracle AIM-style EBS
projects, but many organizations customize document names, numbering, and
approval gates. Use this file as a professional baseline and align final
deliverables with the client PMO, project methodology, and module-specific
Oracle documentation. |
1.
Purpose and document set overview
2.
Preparation lifecycle and required inputs
3.
BR100 - application setup / configuration design document
4.
MD50 - functional design document for custom components
5.
Configuration guide - build and support guide
6.
Test scripts - unit, SIT, UAT, regression, and negative testing
7.
Traceability matrix, approval workflow, and quality checklist
8.
Ready-to-fill templates and practical examples
9.
References
This document explains how to
prepare professional functional documentation for Oracle EBS R12
implementation, enhancement, rollout, and support projects. It focuses on four
common deliverables: BR100, MD50, configuration guide, and test scripts.
The practical objective is to
make each document auditable, testable, maintainable, and clear enough for
business users, functional consultants, technical developers, testers, and
support teams.
|
Deliverable |
Main Purpose |
Prepared By |
Reviewed By |
When Prepared |
Output Quality Standard |
|
BR100 |
Documents EBS
setup/configuration decisions and values for a module or process area. |
Functional consultant |
Solution lead, business
process owner, technical/security teams |
Solution design and build |
Every setup value must be
traceable to requirement, process decision, or statutory need. |
|
MD50 |
Defines the functional
requirement for a customization, extension, interface, conversion, report,
workflow, form personalization, or enhancement. |
Functional consultant /
business analyst |
Business owner, technical
lead, integration lead, QA |
Before technical design and
development |
Developer can create
MD70/technical design without guessing the business rule. |
|
Configuration Guide |
Explains repeatable setup
steps, navigation paths, screenshots/placeholders, dependencies, and support
notes. |
Functional consultant /
support lead |
Project build lead, support
team |
During build and before
transition |
A trained support user can
repeat or verify setup in another instance. |
|
Test Scripts |
Defines testable business
scenarios, data, steps, expected results, and evidence requirements. |
Functional consultant / QA
/ business user |
QA lead, business process
owner |
Unit test, SIT, UAT,
regression |
A tester can execute the
process consistently and record pass/fail evidence. |
·
Approved scope, business process flows, and
module list.
·
Requirement register or user stories with unique
requirement IDs.
·
Chart of accounts, ledger/legal entity/operating
unit/inventory organization structure, and security model.
·
Gap list, customization register, interface
register, report register, and data migration scope.
·
CRP/SIT/UAT decisions, open issues, assumptions,
and design constraints.
·
Oracle module implementation guides, client
policies, statutory requirements, and project-specific templates.
·
Instance details: DEV, TEST, CRP, UAT, PROD;
responsibility names; user roles; profile option levels; concurrent programs.
1.
Confirm scope and process ownership. Do not start detailed documentation
until the business process owner and implementation scope are clear.
2.
Map each business requirement to an EBS standard feature, setup item,
personalization, report, interface, or customization.
3.
Separate configuration from customization. Standard setup belongs mainly
in BR100/configuration guide; custom logic belongs in MD50 and later MD70.
4.
Write the BR100 setup design first for standard functionality. Capture
exact setup values, navigation, responsibility, profile levels, defaults, and
dependencies.
5.
Write the MD50 only for gaps requiring extension or development.
Document business rules, validations, layouts, exceptions, and integration
behavior.
6.
Prepare configuration guide in step-by-step support language. This
should help rebuild or validate setup in another instance.
7.
Prepare test scripts from requirements and design documents. Every
critical rule in BR100/MD50 should be testable.
8.
Run peer review and business review. Resolve open items, update
assumptions, and baseline the documents before build freeze or UAT.
9.
Maintain version control. Any change after sign-off should go through
change control and impact analysis.
BR100 is commonly used as the
application setup documentation artifact in Oracle EBS projects. It records the
configuration design and setup values that make standard Oracle functionality
behave according to the approved business process.
·
The setup is complete for the agreed scope.
·
Each setup choice has a business reason,
statutory reason, integration dependency, or operational reason.
·
Dependencies are clear, such as ledger before
operating unit, payment terms before supplier/site usage, approval hierarchy
before purchase order approval, or transaction type before order entry.
·
Profile options, lookups, value sets,
flexfields, sequences, workflows, and security responsibilities are documented
at the correct level.
·
Configuration can be rebuilt, audited, compared
across instances, and supported after go-live.
|
Section |
Content to Include |
Practical Notes |
|
Document control |
Version, author, reviewers,
approvers, module, instance, status, change log. |
Use formal approvals before
build freeze and UAT. |
|
Business scope |
Processes, operating units,
ledgers, organizations, user groups, countries, exclusions. |
Avoid vague phrases such as
'all AP setup'. State exact scope. |
|
Assumptions and
dependencies |
Prerequisite master data,
integrations, security, statutory rules, chart of accounts, calendars. |
Unclear assumptions become
UAT defects later. |
|
Organization setup |
Business groups, ledgers,
legal entities, operating units, inventory organizations, MOAC access. |
Document hierarchy and data
access implications. |
|
Core setup values |
Each setup object,
navigation path, exact value, enabled flag, start/end date, defaulting
behavior. |
Use setup tables rather
than long prose. |
|
Profile options |
Profile name, level, value,
reason, affected responsibility/user/site. |
Profile level is critical
in EBS troubleshooting. |
|
Lookups and value sets |
Lookup type, code, meaning,
value set type, validation, dependent values. |
State whether seeded or
custom. |
|
Flexfields |
KFF/DFF context, segment
name, value set, mandatory flag, display order, business use. |
Include accounting/security
impact where relevant. |
|
Workflow and approvals |
Approval groups, hierarchy,
AME rules, workflow attributes, notifications. |
Document exception behavior
and delegation rules. |
|
Reports and concurrent
programs |
Program name, parameters,
responsibility access, schedule, output, bursting if any. |
Include operational owner. |
|
Security |
Responsibilities, menus,
request groups, function exclusions, data access sets. |
Link to
segregation-of-duties control where required. |
|
Validation and sign-off |
CRP evidence,
screenshots/evidence references, open items, approval names and dates. |
Do not sign off with hidden
unresolved design items. |
|
Setup ID |
Module |
Responsibility |
Navigation Path |
Setup Object |
Value / Rule |
Level |
Business Reason |
Dependency |
Evidence Ref. |
|
BR100-AP-001 |
Payables |
Payables Manager |
Setup > Options >
Payables |
Payables Options |
Payment accounting enabled;
invoice matching policy as approved |
Operating Unit |
Supports AP invoice
accounting and matching control |
Ledger, operating unit,
suppliers |
Screenshot / config export |
|
BR100-PO-001 |
Purchasing |
Purchasing Super User |
Setup > Organizations
> Purchasing Options |
Purchasing Options |
Receipt required for
inventory items |
Operating Unit |
Ensures three-way match for
stock purchases |
Inventory org, receiving
options |
Screenshot / test PO |
|
BR100-FND-001 |
System Administration |
System Administrator |
Profile > System |
Profile Option |
MO: Operating Unit = <OU
Name> |
Responsibility |
Controls operating unit
context for responsibility |
OU setup and responsibility
assignment |
Profile export |
|
Check |
Question |
Status |
|
Scope |
Does the BR100 clearly
state included and excluded modules, operating units, ledgers, and
organizations? |
Open / Done / N/A |
|
Traceability |
Is every major setup linked
to a requirement, process decision, policy, or statutory rule? |
Open / Done / N/A |
|
Exact values |
Are setup values written
exactly as configured, not only described conceptually? |
Open / Done / N/A |
|
Dependencies |
Are prerequisite setups and
cross-module impacts stated? |
Open / Done / N/A |
|
Security |
Are responsibilities,
menus, request groups, and profile levels documented? |
Open / Done / N/A |
|
Testing |
Does every critical setup
have at least one test scenario? |
Open / Done / N/A |
|
Evidence |
Are screenshots, export
references, or instance evidence attached or referenced? |
Open / Done / N/A |
|
Approval |
Has the business process
owner approved the design? |
Open / Done / N/A |
MD50 is the functional design
document for custom development or extension work. It defines what the solution
must do from a business and functional perspective. The technical team
typically uses the approved MD50 to prepare the technical design, often called
MD70 in Oracle AIM-style projects.
·
Custom report, BI Publisher report, XML
Publisher layout, or custom concurrent program.
·
Inbound or outbound interface between EBS and
external systems.
·
Data conversion or migration requiring business
transformation rules.
·
Workflow extension, AME rule gap, notification
change, or custom approval requirement.
·
Form personalization, OA Framework
personalization, custom form/page, or validation extension.
·
Business rule not achievable through standard
setup, profile option, lookup, AME, personalization, or seeded report.
|
Section |
Content to Include |
Common Mistakes to Avoid |
|
Document control |
Version, author, business
owner, technical owner, module, customization ID. |
Missing ownership and
approval trail. |
|
Business requirement |
Problem statement,
requirement ID, current pain point, expected benefit. |
Writing a solution without
explaining the business need. |
|
Scope and exclusions |
Included functions,
excluded scenarios, impacted entities, roles, interfaces. |
Allowing uncontrolled scope
expansion during development. |
|
Current process |
As-is behavior or standard
EBS limitation. |
Ignoring whether standard
functionality can solve the gap. |
|
Proposed process |
To-be process, trigger
point, user interaction, system behavior, approvals. |
Using only technical
language that business cannot validate. |
|
Functional rules |
Defaulting, validation,
calculations, tolerances, exception handling, error messages. |
Ambiguous words like
'proper', 'valid', 'as required'. |
|
Data design |
Input fields, output
fields, source/target systems, mapping, transformation, mandatory flags. |
No field-level mapping or
unclear data ownership. |
|
Security |
Responsibilities, menus,
roles, function access, data restrictions. |
Assuming all users can
access the customization. |
|
Reporting/layout |
Columns, filters, sort
order, parameters, totals, output format, layout mock-up. |
No sample output or
parameter definition. |
|
Interface behavior |
Frequency, mode,
file/API/table, error handling, retry, reconciliation. |
No reconciliation or error
correction process. |
|
Testing and acceptance |
Positive, negative,
boundary, security, reconciliation, performance scenarios. |
Only happy-path test cases. |
|
Open items and approvals |
Design decisions, risks,
dependencies, sign-off names/dates. |
Starting build with
unresolved business rules. |
|
Rule ID |
Requirement ID |
Trigger / Event |
Condition |
Expected System Behavior |
Error / Exception |
Priority |
Test Scenario |
|
MD50-R001 |
REQ-AP-014 |
Invoice import runs |
Supplier site is inactive |
Reject invoice and write
error to interface error report |
Inactive supplier site -
correct supplier site or reactivate after approval |
High |
TS-AP-IMP-003 |
|
MD50-R002 |
REQ-PO-009 |
User submits PO approval |
PO amount exceeds approval
limit |
Route approval to next
authority level |
No approver found - notify
purchasing admin |
High |
TS-PO-APP-002 |
|
MD50-R003 |
REQ-GL-006 |
Report submitted |
Ledger parameter is blank |
Show mandatory parameter
validation |
Ledger is required |
Medium |
TS-GL-RPT-001 |
|
Field No. |
Field Name |
Source |
Target / Output |
Type / Length |
Mandatory |
Transformation Rule |
Validation |
Sample Value |
|
1 |
Invoice Number |
External AP file |
AP invoice interface |
VARCHAR2(50) |
Yes |
Trim spaces; preserve
original case |
Must be unique for supplier |
INV-2026-001 |
|
2 |
Supplier Number |
External AP file |
Supplier master |
VARCHAR2(30) |
Yes |
Direct mapping |
Must exist and be active |
SUP-10025 |
|
3 |
Invoice Amount |
External AP file |
Invoice amount |
NUMBER |
Yes |
Two decimal rounding |
Greater than zero |
125000.00 |
|
Check |
Question |
Status |
|
Business need |
Is the business problem and
benefit clear? |
Open / Done / N/A |
|
Standard fit check |
Has standard EBS
functionality/configuration been evaluated before customization? |
Open / Done / N/A |
|
Rules |
Are all business rules
precise, testable, and free from ambiguity? |
Open / Done / N/A |
|
Data mapping |
Are all fields, sources,
targets, validations, and transformations documented? |
Open / Done / N/A |
|
Security |
Are users,
responsibilities, menus, and access restrictions defined? |
Open / Done / N/A |
|
Error handling |
Are rejection, correction,
retry, and reconciliation processes defined? |
Open / Done / N/A |
|
Testing |
Are positive, negative,
boundary, and regression scenarios identified? |
Open / Done / N/A |
|
Approval |
Has the business owner
signed off before technical design/development? |
Open / Done / N/A |
A configuration guide is more
operational than a BR100. The BR100 records design and approved setup values;
the configuration guide explains how to perform, verify, migrate, or support
the setup. In some projects, both are combined; in controlled programs, they
are kept separate.
|
Section |
Content |
Example |
|
Purpose |
What setup this guide
covers and why it exists. |
Configure Payables Options
for operating unit ABC OU. |
|
Prerequisites |
Required roles, master
data, previous setup, access, profile options. |
Ledger, legal entity,
operating unit, supplier numbering policy. |
|
Instance and responsibility |
DEV/TEST/UAT/PROD and exact
EBS responsibility. |
Payables Manager > Setup
> Options > Payables. |
|
Step-by-step setup |
Numbered steps with exact
navigation and field values. |
Enter liability account;
select invoice tolerance template. |
|
Screenshots/evidence |
Screenshot placeholders or
evidence references. |
Attach screenshot after
field value entry and save. |
|
Validation |
How to confirm setup is
working. |
Create test invoice and
validate accounting behavior. |
|
Rollback/change note |
How to reverse or change
the setup safely. |
Disable lookup code instead
of deleting historical value. |
|
Support notes |
Common errors,
troubleshooting, owner, escalation path. |
If operating unit not
visible, check MO profile and responsibility. |
|
Step |
Responsibility |
Navigation |
Action |
Field / Object |
Value |
Expected Result |
Evidence |
|
1 |
System Administrator |
Profile > System |
Set profile option |
MO: Security Profile |
<Security Profile> |
Responsibility can access
permitted operating units |
Screenshot |
|
2 |
Payables Manager |
Setup > Options >
Payables |
Review and update |
Payables Options |
As per BR100-AP-001 |
Options saved without error |
Screenshot |
|
3 |
Payables Manager |
Invoices > Entry >
Invoices |
Create sample transaction |
Invoice header and lines |
Test supplier/invoice |
Invoice validates
successfully |
Test evidence |
·
Use exact EBS navigation paths and
responsibility names; do not write only generic menu names.
·
Mention profile option level: Site, Application,
Responsibility, or User.
·
For multi-org environments, state operating
unit, ledger, legal entity, and inventory organization where applicable.
·
Do not delete seeded values unless Oracle
documentation and project governance explicitly allow it; prefer
disable/end-date where appropriate.
·
Include migration notes, because manual setup
differences between DEV, TEST, UAT, and PROD are a common root cause of
defects.
·
Keep setup evidence references separate from
design logic so the document remains readable.
Test scripts convert BR100 and
MD50 content into executable validation steps. A strong test script proves that
the configured or customized system supports the approved business process,
security rules, data rules, and exception handling.
|
Test Type |
Purpose |
Owner |
Typical Evidence |
|
Unit / Module Test |
Validate one setup item,
report, interface, or customization in isolation. |
Functional consultant /
developer |
Screenshot, log, report
output, concurrent request ID. |
|
SIT |
Validate end-to-end
cross-module flow with integrated data. |
QA / functional team |
End-to-end transaction
evidence and defect log. |
|
UAT |
Business users validate
that the solution supports real operating processes. |
Business process owner |
Signed test execution sheet
and evidence pack. |
|
Regression |
Confirm that new changes do
not break existing critical flows. |
QA / support team |
Regression pass/fail
summary. |
|
Negative / Exception Test |
Confirm validation, error
handling, approvals, and rejection behavior. |
QA / functional team |
Error screenshots, logs,
rejection report. |
|
Security Test |
Confirm access is allowed
only to correct roles/responsibilities. |
Security / QA |
User/responsibility test
evidence. |
|
Migration Reconciliation |
Confirm migrated/opening
data totals and records are accurate. |
Data migration / finance
operations |
Source-target
reconciliation report. |
|
Field |
Value to Enter |
|
Test Script ID |
TS-<Module>-<Process>-<Number> |
|
Process Area |
Example: Procure to Pay,
Order to Cash, Record to Report |
|
Requirement IDs |
REQ-001, REQ-002, GAP-003,
MD50-R001 |
|
Related Documents |
BR100 section, MD50 ID,
configuration guide step, business process flow |
|
Instance |
DEV / TEST / CRP / UAT /
PROD-like clone |
|
Tester |
Name and role |
|
Responsibility |
Exact Oracle EBS
responsibility |
|
Test Data |
Supplier, customer, item,
ledger, operating unit, amount, date, currency |
|
Preconditions |
Setup completed, master
data exists, user assigned responsibility |
|
Pass Criteria |
Expected result must be
measurable and evidence-based |
|
Step |
Action |
Navigation / Program |
Input Data |
Expected Result |
Actual Result |
Status |
Evidence / Defect ID |
|
1 |
Login with test user |
EBS Login Page |
User: AP_TEST_USER |
User logs in and sees
assigned responsibility |
|
Pass / Fail |
Screenshot |
|
2 |
Create invoice |
Payables Manager >
Invoices > Entry > Invoices |
Supplier, invoice number,
amount |
Invoice is saved and
assigned status Never Validated |
|
Pass / Fail |
Screenshot |
|
3 |
Validate invoice |
Actions > Validate |
Validate checkbox |
Invoice status becomes
Validated or expected hold appears |
|
Pass / Fail |
Screenshot / Hold details |
|
4 |
Create accounting |
Actions > Create
Accounting |
Final or Draft as test
requires |
Accounting entries
generated as per expected account combination |
|
Pass / Fail |
Accounting output |
·
Every expected result should be objective.
Example: 'invoice status becomes Validated' is stronger than 'invoice works
correctly'.
·
Use real-like test data and include negative
scenarios, boundary values, approval limits, inactive records, missing
mandatory fields, and security restrictions.
·
Link each test case to requirement IDs and
design document sections to prove coverage.
·
Do not mix multiple independent scenarios into
one long script; split by business objective.
·
Capture evidence consistently: screenshot names,
concurrent request IDs, report outputs, interface logs, accounting output, and
defect IDs.
·
For interfaces, include source file/API payload,
concurrent request/log, staging table status, target transaction, rejection
report, and reconciliation totals.
Traceability protects the project
from undocumented configuration and untested customization. It connects
requirements, design documents, build objects, and test evidence.
|
Requirement ID |
Business Process |
BR100 Ref. |
MD50 Ref. |
Config Guide Ref. |
Test Script Ref. |
Defect / CR Ref. |
Sign-off Status |
|
REQ-AP-001 |
AP invoice validation |
BR100-AP-001 |
N/A |
CFG-AP-001 |
TS-AP-001 |
None |
Approved |
|
GAP-AP-014 |
AP invoice import
validation |
N/A |
MD50-AP-IMP-001 |
CFG-AP-IMP-001 |
TS-AP-IMP-003 |
DEF-102 closed |
Approved |
|
REQ-PO-009 |
PO approval routing |
BR100-PO-AME-001 |
MD50-PO-APP-001 if custom |
CFG-PO-AME-001 |
TS-PO-APP-002 |
Open CR if approval matrix
changes |
Pending |
Oracle EBS documentation should
be controlled because small setup or design changes can affect accounting,
approvals, inventory, tax, security, and statutory reporting. Use clear
versioning and approval gates.
|
Version |
Date |
Author |
Change Summary |
Reviewer |
Approval Status |
|
0.1 |
DD-MMM-YYYY |
Functional Consultant |
Initial draft |
Solution Lead |
Draft |
|
0.2 |
DD-MMM-YYYY |
Functional Consultant |
Updated after business
review |
Business Owner |
Review |
|
1.0 |
DD-MMM-YYYY |
Functional Consultant |
Baselined for build/UAT |
Project Manager |
Approved |
|
Role |
Name |
Department |
Signature |
Date |
Comments |
|
Business Process Owner |
|
|
|
|
|
|
Functional Lead |
|
|
|
|
|
|
Technical Lead |
|
|
|
|
|
|
QA Lead |
|
|
|
|
|
|
Project Manager |
|
|
|
|
|
Example scenario: The client
wants controlled purchase order approval, three-way matching for inventory
purchases, and an AP invoice import from an external procurement portal.
|
Need |
Where to Document |
Why |
|
Three-way matching setup |
BR100 and configuration
guide |
This is mostly standard
configuration and setup evidence. |
|
PO approval hierarchy / AME
rules |
BR100; MD50 only if custom
logic is required |
Standard approval setup
belongs to BR100; custom approval logic requires MD50. |
|
AP invoice import from
external portal |
MD50, interface mapping,
test scripts |
Inbound interface requires
field mapping, validation, error handling, and reconciliation. |
|
User access to purchasing
and payables responsibilities |
BR100 security section and
test script |
Security must be configured
and tested. |
|
End-to-end process from
requisition to payment |
SIT/UAT scripts |
Business process acceptance
requires transaction-level validation. |
|
Defect |
Why It Is Risky |
Better Practice |
|
Setup values described
generally |
Support team cannot rebuild
or audit setup. |
Capture exact field values,
navigation, responsibility, level, and evidence. |
|
MD50 lacks negative
scenarios |
Development may pass happy
path but fail real operations. |
Include validation,
exception, rejection, and retry rules. |
|
No traceability |
UAT coverage gaps and audit
weakness. |
Maintain
requirement-to-design-to-test matrix. |
|
No multi-org context |
Setup may work in one
operating unit but fail in another. |
Document ledger, legal
entity, operating unit, inventory organization, and MOAC behavior. |
|
Screenshots without
explanation |
Screenshot evidence alone
does not explain design rationale. |
Pair screenshots with
business reason and setup impact. |
|
Unapproved post-signoff
changes |
Configuration drift and
production defects. |
Use change control, impact
assessment, and version update. |
|
Test expected result is
vague |
Pass/fail decision becomes
subjective. |
Write measurable expected
results with status, accounting, report, or log evidence. |
|
Area |
Checklist Item |
Done |
|
Document control |
Version history, author,
reviewers, approvers, and status are complete. |
Yes / No |
|
Scope |
Included and excluded scope
is clear. |
Yes / No |
|
Business alignment |
Business owner can
understand and validate the document without technical guessing. |
Yes / No |
|
Oracle alignment |
Module-specific setup
follows Oracle documentation, seeded behavior, and project configuration
standards. |
Yes / No |
|
Traceability |
Every requirement links to
BR100/MD50/config/test where applicable. |
Yes / No |
|
Multi-org and security |
Operating unit, ledger,
inventory org, responsibility, and profile levels are documented. |
Yes / No |
|
Testing |
Positive, negative,
integration, security, regression, and reconciliation tests are included
where applicable. |
Yes / No |
|
Evidence |
Screenshots, request IDs,
reports, logs, or references are attached or clearly referenced. |
Yes / No |
|
Risks |
Open assumptions,
dependencies, and decisions are visible. |
Yes / No |
|
Approval |
Sign-off section is ready
for formal approval. |
Yes / No |
In Oracle EBS R12 projects, I
prepare BR100, MD50, configuration guides, and test scripts by first confirming
the approved business process, scope, module, multi-org structure, and
requirement IDs. For standard Oracle setup, I document configuration in BR100
with exact setup values, navigation paths, profile option levels, dependencies,
and business reasons. For customizations, interfaces, reports, workflows, or
conversions, I prepare MD50 with functional rules, field mapping, validation
logic, error handling, security, and acceptance criteria. Then I prepare
configuration guides so the setup can be repeated or supported, and I create
test scripts linked to each requirement and design rule. Finally, I maintain
traceability, evidence, version control, and formal business sign-off.
Use official Oracle documentation
as the baseline for product setup, seeded behavior, architecture, development
standards, and module-specific constraints. Project templates should still be
aligned with the client PMO, internal control requirements, and implementation
methodology.
·
Oracle
E-Business Suite Release 12.2 Documentation Library: https://docs.oracle.com/cd/E51111_01/current/html/doclist.html
·
Oracle
E-Business Suite Developer's Guide: https://docs.oracle.com/cd/E26401_01/doc.122/e22961/toc.htm
·
Oracle
E-Business Suite Concepts - Architecture: https://docs.oracle.com/cd/E26401_01/doc.122/e22949/T120505T120508.htm
·
Oracle
E-Business Suite Multiple Organizations Implementation Guide: https://docs.oracle.com/cd/E26401_01/doc.122/e48833/toc.htm
·
Oracle
Purchasing User's Guide - Overview of Setting Up: https://docs.oracle.com/cd/E26401_01/doc.122/e48931/T446883T443950.htm
|
Field |
Input |
|
Project / Client |
|
|
Module / Process Area |
|
|
Instance |
|
|
Operating Unit / Ledger /
Organization |
|
|
Prepared By |
|
|
Reviewed By |
|
|
Approved By |
|
|
Related Requirement IDs |
|
|
Scope |
|
|
Assumptions |
|
|
Dependencies |
|
Setup detail table:
|
Setup ID |
Responsibility |
Navigation |
Setup Object |
Value |
Level |
Reason |
Dependency |
Evidence |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Field |
Input |
|
Customization ID |
|
|
Requirement / Gap ID |
|
|
Object Type |
Report / Interface /
Conversion / Extension / Workflow / Personalization / Other |
|
Business Problem |
|
|
Proposed Functional
Solution |
|
|
In Scope |
|
|
Out of Scope |
|
|
Users / Responsibilities |
|
|
Assumptions |
|
|
Dependencies |
|
|
Acceptance Criteria |
|
Functional rules:
|
Rule ID |
Trigger |
Condition |
Expected Behavior |
Error Handling |
Test Case |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Field mapping:
|
Field |
Source |
Target |
Type |
Mandatory |
Transformation |
Validation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Field |
Input |
|
Test Script ID |
|
|
Scenario Name |
|
|
Requirement IDs |
|
|
Related BR100 / MD50 |
|
|
Instance |
|
|
Tester |
|
|
Responsibility |
|
|
Preconditions |
|
|
Test Data |
|
|
Pass Criteria |
|
Execution steps:
|
Step |
Action |
Navigation / Program |
Input |
Expected Result |
Actual Result |
Status |
Evidence / Defect |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
