Pre Patch Analysis

Impact of Patch can be analyzed in two ways

1) Using Patch Wizard functionality which is available from System Administrator responsibility under OAM > Patching and Utilities

2) adpatch utility

There are 3 modes of applying the patch.
 
1) Pre-Install Mode
2) Test Mode
3) Non-Interactive Mode
Test Mode
It’s always good to run the patch in test mode and analyze the things before applying the patch in normal mode. When running the patch in test mode, it tells us everything it would have done in applying a patch, but doesn’t actually apply the patch.

To run AutoPatch in Test Mode, we must include ‘apply=no’ on the AutoPatch command line. For example:

$ adpatch apply=no

After running this command, it will ask you for log file name which will be stroed in $APPL_TOP/admin/ directory. This log file will list out all the files which will be applied or not applied.

Below are the steps to identify logical changes applied by the patch. Once you identify the change being applied by patch, you can create test scenarios out of it

1) Look at the "list of bugs fixed" section in the README file for the patch

2) Run below query, which will tell you the list of bugs already applied. Remaining list of bugs are the actual ones which will be applied by patch as a logical change. You can then create test cases and scenarios by studying this bugs

SELECT bug_number, creation_date
FROM ad_bugs
WHERE bug_number in (list of bug numbers from README file in step-1)
 

How to Apply a Patch?

1) Stop all application services (keep the database and the database listener up and running)

2) Download the patch from Metalink

3) Copy the patch file to any directory (i.e. /u04/patches)

4) As 'applmgr' do the following:

- Source the environment file
- Issue "adadmin" and Select (5. Change Maintenance Mode), then (1. Enable Maintenance Mode)
- $ cd /u04/patches
- Type 'unzip (patch_number).zip'
- cd (patch_number)
- Type 'adpatch'
- When it prompts you to enter the patch driver, type 'u.drv'

5) Apply the patch on the database tier first then on the application tier.

6) Once you apply the patch successfully, 'Disable Maintenance Mode' from adadmin.

Note- And, always follow the steps in the patch README file.
 

Printer Installation/Registeration in Oracle Apps

a) Login with System Administrator Responsibility
b) Navigate to System Administrator > Install > Printer
c) Printer and Drivers can be defined and registered using 4 following steps in sequence

1) System Administrator > Install > Printer > Driver

In order to make use of PDF Printing Directly from a Concurrent Program we need to have PASTA_PDF Driver existing in the Oracle Applications.

Driver Name : PASTA_PDF
User Driver : Pasta PDF Driver
Description : Pasta driver to print pdf converted to PostScript by 3rd party utility
Driver Method : Program
Driver Method Parameters : Spool File
Program Name : FNDPSTAX
Arguments: -pn$PROFILES$.PRINTER -f$PROFILES$.FILENAME – $PROFILES$.CONC_COPIES -Fpasta_pdf.cfg

2) System Administrator > Install > Printer > Style

We need to check whether a PDF Publisher Styles exists or not.

3) System Administrator > Install > Printer > Types

We need to Add a Customized Sytle to the following Type HPLJ4SI This Type supports maximum number of Printers with all types of Styles. Please add the PDF Publisher : PASTA_PDF Sytle to HPLJ4SI Type.

4) System Administrator > Install > Printer > Register

Now Register the Printer in Oracle Applications using printer type

Defining and Assigning the Printer at Concurrent Program Level

Usually we define Portrait or Landscape for the Style in the Concurrent Program at Output Tab.

Here we need to specific PDF Publisher as the Style in Concurrent Program and as well we have to mention the Name of the Printer which was registered in the Oracle Applications.

Run this program to get the output at Printer Tray

ORA-01861: literal does not match format string

For any Concurrent Program date parameter in Oracle Apps, we assign FND_STANDARD_DATE Value Set having length 11. This value set always pass date in below format to your program

YYYY/MM/DD

If the date format of your program (Report or PL/SQL Procedure) does not matches with above format, it will always throw below error in log file

ORA-01861: literal does not match format string

Below are the steps to resolve this error with different Program Type

Oracle Reports Type Program

Define user parameter for Date in RDF with below property details

Datatype- Date
Width- 20
Input Mask- RRRR/MM/DD HH24:MI:SS


PL/SQL Stored Procedure Type Program

1) Always use errbuf and retcode as first two OUT parameters in your procedure

2) Define the Date parameters with datatype VARCHAR2 in procedure

3) Use fnd_date.canonical_to_date to convert varchar2 format to oracle date format (DD-MON-YY) and then use it anywhere in a program

Below is an example for the same

CREATE OR REPLACE PROCEDURE APPS.TEST_TRANSFER
( p_errbuf OUT VARCHAR2
,p_retcode OUT VARCHAR2
,p_from_date VARCHAR2
,p_to_date VARCHAR2 )
IS
v_from_date DATE;
v_to_date DATE;
BEGIN
v_from_date := fnd_date.canonical_to_date (p_from_date);
v_to_date := fnd_date.canonical_to_date (p_to_date);

SAP Vs. ORACLE

What Is ROI?
Return on investment is calculated by dividing the average annual net benefits over a 3 year period by the initial costs:
(Y1+Y2+Y3)/3/initial cost
Benefits include both direct cost savings and productivity and other indirect benefits; costs include software, hardware, personnel, consulting, and training.

ROI AND PAYBACK
> 65 percent of Oracle E-Business Suite customers achieved a positive return on investment after an average deployment time of 3.1 years.
> 43 percent of SAP customers had achieved a positive return on investment after an average deployment time of 2.8 years.

COSTS
1) Oracle’s average costs were 48 percent lower than SAP’s.
2) Oracle’s median costs were 29 percent lower than SAP’s.
3) Oracle’s average 3-year TCO was 48% lower than SAP’s.
4) Oracle’s median 3-year TCO was 34 percent lower than SAP’s.

PERSONNEL REQUIREMENTS
1) It takes fewer internal personnel to deploy Oracle: an average of 81 man-months of internal personnel were needed for Oracle, compared to an average of 372 for SAP.
2) It takes less training to deploy Oracle: an average of 27 hours of training for Oracle, compared to an average of 49 hours for SAP

CONCLUSION
1) SAP projects are larger in scale and scope and thus take a longer time to reach positive ROI than Oracle.
2) More Oracle customers than SAP customers achieve a positive ROI. Ninety percent of Oracle customers can expect a positive ROI in fewer than 5 years.
3) SAP customers often face customization and integration challenges that slow deployments and increase consulting and personnel costs.
4) Oracle has a lower overall TCO than SAP

Application Diagnostic Test

After creating SR through Metalink, oracle usually asks for data collection test. Below are the detailed steps to execute those diagnostic test from Application.

1) Login to E-Business Suite or R12 using your username/password
2) Select the "Application Diagnostics" responsibility, If this responsibility is not assigned, contact the System Administrator to configure the responsibility
3) Click Diagnose in the right hand side menu
4) From the 'Diagnose' tab, under 'Tests', Click 'Select Application' button and using the LOV, select search criteria (application name or application shortname)
Note: Multiple products may be queried by using a comma (,) between products. Do not include a space before or after the comma.
5) Enter search criteria and click 'Go'
6) Select the desired application(s) from the list below, and click 'Select'
7) Expand group(s), select the test(s) you wish to execute and click 'Execute'
8) Enter parameters (as required) and click 'Select'.
9) Use the 'list of values' to help in your parameter selection. If multiple tests are selected, click the icon in 'Test Inputs' column followed by 'Add Another Row' to enter parameters. Click 'Add Another row' for each occurance of that test.
- Click 'Submit'
10) Click the 'Refresh' button for execution status. When the execution is complete, the 'Status' field in the 'Request Details' section will show as 'Completed'. The report is now available for viewing and download by clicking the icon in the respective 'View Report' or 'Download Report' column in the 'Execution Details' section.
11) When executing mulitple tests, click the number in the 'Total Executions' column to select the specific report.

Host Concurrent Program

Below are the steps to register host concurrent program in oracle apps

1) Define Concurrent Program with Executable Type = Host and Execution File Name = Name of .prog file without extension

2) Copy your .prog file (Shell Script) to Custom Top Bin directory (Eg: $XXCUST_TOP/bin)

3) Create symbollic link by executing below commands on Unix Server
cd $XXCUST_TOP/bin
ln -s $FND_TOP/bin/fndcpesr sample_file
WHERE sample_file = Name of your Host program script

Oracle Fusion Overview

Fusion is Oracle’s initiative to develop a set of “next generation” enterprise business applications, on a service oriented platform. It is broadly divided into 2 parts as below:

Fusion Applications

– Enterprise business applications developed using open industry based standards (vs. the proprietary languages of Oracle’s current products lines – Oracle Forms, Reports, People Tools..etc.)
– Based on the best features and functionalities of Oracle’s existing applications product lines (Oracle, PeopleSoft, JDEdwards, Siebel, etc.)

Fusion Middleware

Oracle’s currently available, standards based middleware platform and the application server platform for the future Fusion Applications.
An architecture blueprint that brings together enterprise applications, leveraging what Oracle believes are three key emerging trends in technology:
• Service Oriented Architectures (SOA)
• Grid Computing Infrastructure
• Enterprise Information Architecture

Oracle SOA Suite Components

JDeveloper (Application Development Framework)

BAM- Business Activity Monitoring

BPEL Process Manager- Business Process Execution Language

ESB- Enterprise Service BusWSM- Web Service Manager

AIM Documents

AIM- Application Implementation Methodology

Business Process Architecture (BP)
BP.010 - Define Business and Process Strategy
BP.020 - Catalog and Analyze Potential Changes
BP.030 - Determine Data Gathering Requirements
BP.040 - Develop Current Process Model
BP.050 - Review Leading Practices
BP.060 - Develop High-Level Process Vision
BP.070 - Develop High-Level Process Design
BP.080 - Develop Future Process Model
BP.090 - Document Business Procedure

Business Requirements Definition (RD)
RD.010 - Identify Current Financial and Operating Structure
RD.020 - Conduct Current Business Baseline
RD.030 - Establish Process and Mapping Summary
RD.040 - Gather Business Volumes and Metrics
RD.050 - Gather Business Requirements
RD.060 - Determine Audit and Control Requirements
RD.070 - Identify Business Availability Requirements
RD.080 - Identify Reporting and Information Access Requirements

Business Requirements Mapping
BR.010 - Analyze High-Level Gaps
BR.020 - Prepare mapping environment
BR.030 - Map Business requirements
BR.040 - Map Business Data
BR.050 - Conduct Integration Fit Analysis
BR.060 - Create Information Model
BR.070 - Create Reporting Fit Analysis
BR.080 - Test Business Solutions
BR.090 - Confirm Integrated Business Solutions
BR.100 - Define Applications Setup
BR.110 - Define security Profiles

Application and Technical Architecture (TA)
TA.010 - Define Architecture Requirements and Strategy
TA.020 - Identify Current Technical Architecture
TA.030 - Develop Preliminary Conceptual Architecture
TA.040 - Define Application Architecture
TA.050 - Define System Availability Strategy
TA.060 - Define Reporting and Information Access Strategy
TA.070 - Revise Conceptual Architecture
TA.080 - Define Application Security Architecture
TA.090 - Define Application and Database Server Architecture
TA.100 - Define and Propose Architecture Subsystems
TA.110 - Define System Capacity Plan
TA.120 - Define Platform and Network Architecture
TA.130 - Define Application Deployment Plan
TA.140 - Assess Performance Risks
TA.150 - Define System Management Procedures

Module Design and Build (MD)
MD.010 - Define Application Extension Strategy
MD.020 - Define and estimate application extensions
MD.030 - Define design standards
MD.040 - Define Build Standards
MD.050 - Create Application extensions functional design
MD.060 - Design Database extensions
MD.070 - Create Application extensions technical design
MD.080 - Review functional and Technical designs
MD.090 - Prepare Development environment
MD.100 - Create Database extensions
MD.110 - Create Application extension modules
MD.120 - Create Installation routines

Data Conversion (CV)
CV.010 - Define data conversion requirements and strategy
CV.020 - Define Conversion standards
CV.030 - Prepare conversion environment
CV.040 - Perform conversion data mapping
CV.050 - Define manual conversion procedures
CV.060 - Design conversion programs
CV.070 - Prepare conversion test plans
CV.080 - Develop conversion programs
CV.090 - Perform conversion unit tests
CV.100 - Perform conversion business objects
CV.110 - Perform conversion validation tests
CV.120 - Install conversion programs
CV.130 - Convert and verify data

Documentation (DO)
DO.010 - Define documentation requirements and strategy
DO.020 - Define Documentation standards and procedures
DO.030 - Prepare glossary
DO.040 - Prepare documentation environment
DO.050 - Produce documentation prototypes and templates
DO.060 - Publish user reference manual
DO.070 - Publish user guide
DO.080 - Publish technical reference manual
DO.090 - Publish system management guide

Business System Testing (TE)
TE.010 - Define testing requirements and strategy
TE.020 - Develop unit test script
TE.030 - Develop link test script
TE.040 - Develop system test script
TE.050 - Develop systems integration test script
TE.060 - Prepare testing environments
TE.070 - Perform unit test
TE.080 - Perform link test
TE.090 - perform installation test
TE.100 - Prepare key users for testing
TE.110 - Perform system test
TE.120 - Perform systems integration test
TE.130 - Perform Acceptance test

Performance Testing(PT)
PT.010 - Define Performance Testing Strategy
PT.020 - Identify Performance Test Scenarios
PT.030 - Identify Performance Test Transaction
PT.040 - Create Performance Test Scripts
PT.050 - Design Performance Test Transaction Programs
PT.060 - Design Performance Test Data
PT.070 - Design Test Database Load Programs
PT.080 - Create Performance Test TransactionPrograms
PT.090 - Create Test Database Load Programs
PT.100 - Construct Performance Test Database
PT.110 - Prepare Performance Test Environment
PT.120 - Execute Performance Test

Adoption and Learning (AP)
AP.010 - Define Executive Project Strategy
AP.020 - Conduct Initial Project Team Orientation
AP.030 - Develop Project Team Learning Plan
AP.040 - Prepare Project Team Learning Environment
AP.050 - Conduct Project Team Learning Events
AP.060 - Develop Business Unit Managers’Readiness Plan
AP.070 - Develop Project Readiness Roadmap
AP.080 - Develop and Execute CommunicationCampaign
AP.090 - Develop Managers’ Readiness Plan
AP.100 - Identify Business Process Impact onOrganization
AP.110 - Align Human Performance SupportSystems
AP.120 - Align Information Technology Groups
AP.130 - Conduct User Learning Needs Analysis
AP.140 - Develop User Learning Plan
AP.150 - Develop User
AP.160 - Prepare User Learning Environment
AP.170 - Conduct User Learning Events
AP.180 - Conduct Effectiveness Assessment

Production Migration (PM)
PM.010 - Define Transition Strategy
PM.020 - Design Production Support Infrastructure
PM.030 - Develop Transition and Contingency Plan
PM.040 - Prepare Production Environment
PM.050 - Set Up Applications
PM.060 - Implement Production Support Infrastructure
PM.070 - Verify Production Readiness
PM.080 - Begin Production
PM.090 - Measure System Performance
PM.100 - Maintain System
PM.110 - Refine Production System
PM.120 - Decommission Former Systems
PM.130 - Propose Future Business Direction
PM.140 - Propose Future Technical Direction

CRM Modules Listing

Oracle's integrated Customer Relationship Management (CRM) solution is a set of applications that give you information-driven Sales, Service and Marketing

Oracle Channel Management
Oracle Marketing
Oracle Order Management
Oracle Sales
Oracle Service

Oracle Service contains following applications
Depot Repair
Field Service
Advanced Scheduler
Mobile Field Service
Spares Management
Interaction Center
Advanced Inbound Telephony
Advanced Outbound Telephony
Email Center
Scripting
iSupport
Service Contracts
TeleService

All following 3 modules integrates seamlessly and are inter-related:
1) Field Service
2) TeleService
3) Service Contracts

R12- Upgrade Vs. Re-implementation

Upgrade Consideration
1) No major process changes
2) No major organizational restructuring
3) COA unchanged
4) Current system is cleaned, reconciled and up-to-date

Re-implement Consideration1) Major business process changes
2) Major organizational restructuring
3) Significant setup changes required (Eg. New COA)
4) Geographic expansion (New country roll-out)
5) Multiple environments to be merged
6) Heavily customized
7) New application to be implemented
8) Historical data can be viewed separately

For more detailed factors/parameters, visit discussion below
http://www.infosysblogs.com/oracle/2009/10/ebs_r12_roadmap_upgrade_vs_rei_1.html

CRP for Oracle R12

Conference Room Pilots (CRPs) are interpreted by different organizations in different ways and can be used in a variety of project types. The R12 project will have 3 conference room pilots followed by user acceptance testing (UAT). The overall goals will be to allow discrete transactional areas of the solution to be validated, with later CRPs building towards demonstrating end to end business scenarios in the new solution.

CRP1 will include:·
Process: An overview of current client process and best practice process recommendations from ESolutions.
System: Demonstration of a subset of the standard Oracle R12 functionality, with small amounts of representative data. (CRP1 is not a user training session. User participants will not follow along on their own PCs.)
Scope: Discussion of ESolution’s recommendations for best practice where applicable to client. Scope review based on ESolution’s recommendations together with the steering committee recommendations to determine the scope baseline for the Oracle R12 project. Gathering of high-level requirements - identify how well the application meets business needs, and identify gaps, whilst still in the design phase of the project.
User Input: An opportunity for users to ask questions and get feedback on the proposed configuration and use of the software. Business attendees will provide many observations and areas of feedback to the project team which will be recorded by the functional team. If these cannot be resolved during the session they will be processed once the CRP is completed with feedback provided to the representatives prior to the next CRP.

Between CRP1 and CRP2: 
1) Detailed requirements gathering interviews will be conducted.
2) “As-Is” business process modelling and gap analysis.
3) Draft to-be process flows and initial software configuration completed prior to the CRP2.
4) Prioritization of requirements/processes (based on business ranking and level of config/customization/development required) to be demonstrated in CRP2 or CRP3.
5) Completion of requirements for “bucket one” for custom development delivered to technical team.

CRP2 will include: 
Process:Functional leaders walk cross-functional teams and potential system users through flow charts. Review of key business scenarios against predefined scripts. The scenarios will be driven from the business process and requirements mapping activities carried out earlier in the project to show how the business processes, are mapped onto system functionality.
System:Functional leaders will take the group through on-line scenario exercises. Various questions and additions to the foreseen problems are raised and alternative approaches are tested.
User Input:User will use predefined scripts to carry out key process in the system. Most issues should be resolved by the team during the exercises or delegated for further action. Signoff by the business on high priority requirements.
Scope:Requests for additional functionality (an increase to the baselined requirements) would need to be handled as part of the scope management process within the project and that observations raised are not automatically included in scope. Changes to the scope baseline will result in change requests to the steering committee.

Between CRP2 and CRP3:
1) Finalization of “To-Be” process models and gap resolution.
2) Detailed requirements validation and sign-off.
3) Completion of requirements for “bucket two” of requirements for custom development delivered to technical team.
4) Development of training materials.

Objectives of CRP3:
Process:Functional leaders walk cross-functional teams and potential system users through final “To-Be” process models.
System:Most converted data available for review in CRP environment.
Some RICE (Reports, Interfaces, Conversions, Enhancements / Extensions) components available for business review.
User Input:User will be hands-on in the system completing real business scenarios from end-to-end.
Validate that any gaps identified during CRP2 have been addressed.
Continue to uncover any system / process issues and potential future phase business requirements.
Scope:Requests for additional functionality (an increase to the baselined requirements) would need to be handled as part of the scope management process within the project and that observations raised are not automatically included in scope. Only items critical for go-live will be considered.

In summary the CRP sessions will focus on the following:

CRP-1: Discrete transactional activities
CRP-2: Proposed business processes (No RICE – custom Reports, Interfaces, Conversions, Enhancements / Extensions)
CRP-3: End to end business scenarios. Processes with converted data and some RICE components
UAT: Test 100% of functionality and end-to-end integration testing including all RICE components

Enabling Trace in Apps

Form Tracing
I have a form where I am entering few values and then saving the form. This will have some insert and updates command in the backend which will get executed when we save the form. SQL tracing is used to track those DML queries to debug the issue.

1) Open the form and Navigate to Menu- Help -> Diagnostic -> Trace

2) Here we have many options available (default is ‘No Trace’). We can enable tracing by selecing on of the options from here. ‘Regular Trace’ gives the least information and ‘Trace with Binds and Waits’ (level 12) gives maximum information. Be careful while enabling SQL trace with wait and binds as this will make the trace file huge.

3) Also we can start the tracing in the middle of forms sessions.

4) When we enable the trace it will give the trace file location (This location will be the location of USER_DUMP_DESTINATION parameter of database)

5) After you save the form you can stop tracing by selecting ‘No Trace’ again from Help -> Diagnostic -> Trace -> No Trace

6) Finally use tkprof command to covert this raw trace file into readable format. TKPROF is explained in separate article

Report Tracing

1) Login to System Administrator responsibility and open concurrent program definition form

2) Check the 'Enable Trace' checkbox and save the program

3) In order to generate Level 12 Trace file, Navigate to Profile > System and find the profile option 'Initialization SQL Statement - Custom' for User who is submitting the process to trace. Click on User column - Edit Field and enter below statement:
begin fnd_ctl.fnd_sess_ctl('','','TRUE','TRUE','LOG','ALTER SESSION SET EVENTS=''''''10046 TRACE NAME CONTEXT FOREVER,LEVEL 12'''''); end;
Save the record.

4. Run the Concurrent program which generates the trace file on server

5. Run the following query that gives the directory where the trace file is stored.
SELECT name, value FROM v$parameter WHERE name = 'user_dump_dest';
Go to the directory returned by USER_DUMP_DEST and use below command to find the file
grep -i 'CONC_REQUEST_ID=' *
Ex: grep -i 'CONC_REQUEST_ID=1499133' *

6. Finally use tkprof command to covert this raw trace file into readable format

How to Use FNDLOAD?

It is merely time consuming task to create same setup data on each instance separately. Hence to migrate setup data from 1 instance to other (Eg. From DEV to PROD), ldt & lct files are used.

LDT (Data Loader Files)- This files are Used to upload & download setup data on different instances.

LCT (Data Config Files)- This files are used to create LDT Files. There are difference lct files for different sets of data.

Eg: Request Set- afcpreqg.lct, Concurrent Program- afcpprog.lct, Value Set- afffload.lct..etc..

** Now lets take a simple example where you want to migrate 1 concurrent program from Development (DEV) instance to Production (PROD).

Step 1: Login to Unix Development server and change the directory using following Command where you can store your LDT files:
cd $CUST_TOP/ patch/115/import/US/ (where CUST_TOP is your custom top on server)

Step 2: Run the following command by supplying the parameters given in {} as per your need
FNDLOAD {userid/password@connect_string} O Y DOWNLOAD $FND_TOP/patch/115/import/afcpprog.lct {file_name.ldt} PROGRAM APPLICATION_SHORT_NAME="{your_application_short_name}" CONCURRENT_PROGRAM_NAME="{your_concurrent_name}"
The above command will generate ldt file in your custom top directory ($CUST_TOP/ patch/115/import/US/ )

Step 3: Copy the LDT file from Development Server to your local desktop

Step 4: Login to Unix Production Server and copy the LDT files from local desktop to Production Server on following path:
$CUST_TOP/ patch/115/import/US/ {file_name.ldt}

Step 5: Finally Run the following command by supplying all parameters in {} to upload concurrent program definition on production application server.
$ FNDLOAD {userid/password@connect_string} 0 Y UPLOAD $FND_TOP/patch/115/import/afcpprog.lct $CUST_TOP/patch/115/import/US/{file_name}.ldt

Note:
1) All above FNDLOAD commands are single line commands.
2) All above steps will remain exactly same for all kind of setup data (Eg: Value Set, CP, Req.group, DFF…etc) except the name of LCT file (.lct). LCT file will be different for every different component because the setup data is different.

Refer to below link for list of various FNDLOAD commands
http://www.oracleappshub.com/aol/its-all-about-fndload/

Types of Value Sets

None (not validated at all)
Independent
Dependent
Table
Special (advanced)
Pair (advanced)

Attention: The Accounting Flexfield only supports Independent, Dependent, and Table validation. Also, You cannot change the validation type of an existing value set, since your changes affect all flexfields and report parameters that use the same value set.

None
You use a None type value set when you want to allow users to enter any value so long as that value meets the value set formatting rules. That is, the value must not exceed the maximum length you define for your value set, and it must meet any format requirements for that value set. Because a None value set is not validated, a parameter that uses this value set does not provide a list of values for your users.

Independent
An Independent value set provides a predefined list of values for a segment. These values can have an associated description. For example, the value 01 could have a description of "Company 01". The meaning of a value in this value set does not depend on the value of any other segment. Independent values are stored in an Oracle Application Object Library table. You define independent values using an Oracle Applications window, Segment Values.

Table
A table-validated value set provides a predefined list of values like an independent set, but its values are stored in an application table. You define which table you want to use, along with a WHERE cause to limit the values you want to use for your set. Typically, you use a table-validated set when you have a table whose values are already maintained in an application table (for example, a table of vendor names maintained by a Define Vendors form). Table validation also provides some advanced advanced features such as allowing a segment to depend upon multiple prior segments in the same structure.

Dependent
A dependent value set is similar to an independent value set, except that the available values in the list and the meaning of a given value depend on which independent value was selected in a prior segment of the flexfield structure. You can think of a dependent value set as a collection of little value sets, with one little set for each independent value in the corresponding independent value set. You must define your independent value set before you define the dependent value set that depends on it. You define dependent values in the Segment Values windows, and your values are stored in an Oracle Application Object Library table.

Special and Pair
Special and pair value sets provide a mechanism to allow a "flexfield-within-a- flexfield". These value sets are primarily used for Standard Report Submission parameters. You do not generally use these value sets for normal flexfield segments.

Interface Vs Conversion

Interface
1) Connection between two systems in order to synchronize the data.
2) Manual, batch or real-time.
3) Used repeatedly and should therefore be designed and constructed in the most efficient manner possible.
4) Can be triggered by an event (such as running a concurrent program) or it can be scheduled to run at a certain time.
5) Can be very costly to construct and maintain

Conversion
1) Process where existing data from the client’s old system is extracted, cleansed, formatted, and installed into a new system.
2) Manual or automated.
3) One-time only process that requires extensive testing and preparation.
4) Executed before a system goes into production

Descriptive Flexfields (DFF)

General Ledger
Daily Rates
Historical Rates

Payables
Bank Branch
Payment Term
Site Address

Receivables
Credit History Information
Address Information

Assets
Bonus Rates
Calendar Types
Price Indexes

HRMS
Additional Address Details
Additional Assignment Details
Additional Hierarchy Details
Additional Job Details
Additional Position Details
Additional Qualification Details
Additional Personal Details

Key FlexFields (KFF)

General Ledger
Accounting Flexfield
Reporting Attribute:Accountin

Receivables
Sales Tax Location
Territory

Assets
Asset
Category
Location

Inventory
Account Aliases
Item Catalogs
Item Categories
Sales Orders
Stock Locators
System Items

HRMS & Payroll
Grade
Job
Personal Analysis
Position
Competence
Cost Allocation
People Group

Period End Close- Oracle Financials

Payables
1) Ensure all invoices are Validated

2) Ensure all invoices are Accounted
3) Payables will transfer only those invoices which are in the status of Validated.
4) Run the following reports:
Unaccounted Transactions Report- Gives you the details of Unaccounted transactions for the period
Payable Accounting Process Report- For Invoices pending to be accounted
Payables Transfer to General Ledger - Transfer the invoices and payment details to General Ledger
Mass Additions Report- Transfer the asset related invoices into Oracle Fixed Assets module
5) Close the Period

Receivables
1) Ensure all transactions are completed
2) Ensure all Receipts are entered and status changed to Cleared
3) Once everything is completed, Click on Navigation Control>General Ledger and run the report. This will transfer the details to General Ledger
4) Close the Period

Assets
1) Ensure additions, adjustments, retirements and others details are completed for all the assets in a particular period
2) Ensure current period additions are transferred from Accounts payable thru Post Mass Additions
3) Run Depreciation Projection report to see the depreciation for the current period. Randomly check the depreciation amount for different categories
4) Run the report Create Journal Entries process which will transfer entries to General Ledger

Cash Management
1) Enter the Bank statement details for each bank in Oracel Cash Management module
2) Reconcile the Payments and Receipts details manually
3) Then Run below reports
Bank Statement Detail Report- This report will show transactions for each bank
GL Reconciliation Report

General Ledger
1) Make sure all the journals are transferrred to General Ledger. Check whether all the details transferred from sub-ledger
2) Review the Journals and Post the details once all the details are correct
3) Run the Trial Balance Report