Oracle Applications Standards for New Report Developments…
For developing a Report in Oracle Applications we should follow three standards.
1. Creation of Bind Variable – P_CONC_REQUEST_ID: We must create a Bind Variable called “P_CONC_REQUEST_ID” (We can’t change this name. It is standard name.). If we run Conc. Prgm. from SRS window, it will give a Request ID. It will get store in ‘P_CONC_REQUEST_ID” automatically. This Bind Variable is useful, when we call another Conc. Prgm. with in a Conc. Prgm.

2. FND SRWINIT in Before Report Trigger:
We call the USER_EXIT (‘FND SRWINIT’) form Before Report Trigger. Syntax is
SRW.USER_EXXIT(‘FND SRWINIT’):
This USER_EXIT is initializing the user profiles in the report trigger i.e., before getting the date from the Database.
Note:
While executing the Conc. Prgm. the system allocate memory for the program which contains all details of user. In above syntax,
SRW.USER_EXIT refers to D2K and purpose of this is, when we want to transfer the control from execution of report to other 3rd generation language and again transfer the control to report execution.
FND SRWINIT refers to Oracle Applications. Purpose of this is to get the “User Profile”.
3. FND SRWEXIT in After Report Trigger:
We call the USER_EXIT (‘FND SRWEXIT’) form After Report Trigger. Syntax is
SRW.USER_EXXIT (‘FND SRWEXIT’):
This USER_EXIT is frees the memory which is occupied by user profiles.

If we want to run the SQL script from the Concurrent Program window then we should follow the below steps.
1. Develop the SQL*plus (.SQL)
2. Transfer the SQL script file (.sql) file from local machine to the server in to respectable path CUST_TOP/11.5.0/SQL/.SQL
Then we have to follow the steps to implement (to run from Concurrent Program window) in Oracle Applications.
1. Create executable by executable method SQL*plus
2. Define Concurrent Program, attach executable, parameters, incompatibilities
3. Attach Concurrent Program to request group.
4. Attach request to responsibility
5. Attach responsibility to user
6. User will submit from SRS window.

Simple SQL Script:
Column user_id format 99999999
Column user_name format a50
Column ucreation_date format a11

Prompt *****************************
Prompt This is SQL* Plus Script
Prompt *****************************

SELECT user_id, user_name,creation_date
FROM end_user;

SQL Script with Parameter:
Inside of SQL script we can receive the parameter value by using &1, &2, &3 and so on. First Concurrent Program parameter value will come in the place, where we have mention &1. Second Concurrent Program parameter in to &2 and so on…
Note:
We can define max of 100 PARAMETERS for a Concurrent Program.
The Format Type of Concurrent Program output should be ‘TEXT’.

PL/SQL Stored Procedures :
If you want to make a PL/SQL procedure as a Concurrent Program, then we will define that procedure by using fallowing syntax

Syntax:
CREATE OR REPLACE PROCEDURE Procedure_Name
(errbuf OUT VARCHAR2,
recoded IN VARCHAR2
,
x IN NUMBER,
y IN NUMBER) AS
BEGIN
PL/SQL statements;
Fnd_file.put_line (fnd_file.output, ’message’variables);
Fnd_file.put.line (fnd_file.log, ’message’variables);
END ;

ERRBUF: Used to get the error messages in to the log file if any errors occur in side of procedure.
RETCODE: Used to get the status of Concurrent Program

The Status can be either 0 – for success
1 – for warning
2 – for error

Inside of procedure body we can use all valid PL/SQL statements except DBMS_OTUPUT.PUT_LINE Instead of this we will use fallowing to API’S (Application Programming Interface).
API is nothing but a package.
Fnd_file.put_line(fnd_file.output,’message’variables); – is write for the output file.
Fnd_file.put.line(fnd_file.log,’message’variables); – is used for log file.

Steps for Developing the Procedure:
1. Develop the procedure as per client requirement.
2. Create an executable with execution method as PL/SQL stored procedure
3. Define the Concurrent Program at as
• EXECUTION
• PARAMETER
• INCOMPATIBILITIES PROGRAM
4. Attach the Concurrent Program to the request group.
5. Attach the request group to the responsibility.
6. Attach the responsibility to user.
7. User will submit program from SRW window

Example for ErrorCode and retCode:

PROCEDURE Load_Cust_Item(ERRBUF OUT VARCHAR2,
                  RETCODE OUT VARCHAR2,
                  ARGUMENT1 IN VARCHAR2,
                  ARGUMENT2 IN VARCHAR2) IS

    L_Retcode Number;
        CONC_STATUS BOOLEAN;
BEGIN

    L_Retcode := Load_Cust_Items_Iface(argument1,
                               argument2);

    if L_Retcode = 0 then
        RETCODE := ‘Success’;
                CONC_STATUS := FND_CONCURRENT.SET_COMPLETION_STATUS(‘NORMAL’,Current_Error_Code);
    elsif L_Retcode = 1 then
        RETCODE := ‘Warning’;
                CONC_STATUS := FND_CONCURRENT.SET_COMPLETION_STATUS(‘WARNING’,Current_Error_Code);
    elsif L_Retcode = 2 then
        RETCODE := ‘Error’;
                CONC_STATUS := FND_CONCURRENT.SET_COMPLETION_STATUS(‘ERROR’,Current_Error_Code);
    end if;

END Load_Cust_Item;

What is SQL*Loader?
SQL*loader is one of the Oracle tool which will be used to transfer the data from Flat-File to oracle Database table.

Which files in SQL*loader?
1. Flat or Data File
2. Control File
3. Bad File
4. Discard File
5. Log File

What is Flat Or Data File: This file contains the records in a special format; these records will be fetching for other legacy. The extension of these files might be .dat, .txt, or .csv (comma separated view).

What is Control File: This is SQL loader execution file, which will be used to transfer the date from file to table. In side of these control file, we will mention the Data file path, table name, column mapping. The extension of control file is .ctl

Control File Creation:

Load data
INFILE ‘Data File Path’
INSERT INTO ‘Table Name’
FIELD TERMINATED BY ‘,’
WHERE deptno = 10
TRAILING NULL COLS
(column1 , empno
column2, ename
column3, deptno)

Once we develop the control file we will execute this by using fallowing command
C:> sqlldr user/passward @ Database Control = name of control file (with extension .ctl)
This command will start the control file execution, and it will try to read the data and inserting into table. After completion of this execution, automatically three files will gets created
Bad file
Discard file
Log file

Bad File: Bad file contain the records, which are rejected by the SQL*loader. SQL*loader will reject the records, when ever the Flat file format is not correct or if any internal error occurs it will rejected. The extension of bad file is .bad

Discard File: Discard file contains the records which are rejected by the control file, control file reject the records, if record is not satisfying the conditions, which we have mentioned inside of control files the extension of discard file is .dis

Logfile: It contains the complete info of the process, like no of records successfully loaded in to the table
No of records successfully loaded in to the bad file & discard file.
And where the bad, discard file gets created and time taken to complete the process.
Taking the complete log.
SQL* Loader Modes:
INSERT
APPEND
REPLACE
We can replaced the data in to the table by using any one of the allowing method

INSERT: When we are using this statement, table should be empty. SQL * loader will insert the new data form the file.

APPEND: This mode will be use to attach the new record to the existing records.

REPLACE: This will replace the existing records with new records.
C:> sqlldr userid/passward@Database control=text1.ctl path=direct

SQL* Loader Paths: We can execution SQL* loader in two paths or nodes
Direct
Conventional

By default SQL*loader will be running in conventional mode, if we want to run in direct mode will use the fallowing syntax
C:> sqlldr userid/passward@Database control=text1.ctl path=direct
Direct mode will disable the table and column constrains and it will insert the data.
Conventional path will check every constrains, if it is satisfied it will insert the record
Conventional path is just like ‘insert statement’
SQL Commands Limitations:
to_date, to_char, upper, lower, Initcap, string, decode, nvl
when clause
sequence_name.next_value, Ref-Cursor
sysdate, ltrim, rtrim, constant

Functional Training  of Purchase Order Flow
What is flow of PO:

Step 1:We will be raising the Requisitions for the items which are needed.
Requisition is 2 types • Internal Requisition • Purchase
Internal Requisition is used when we are getting the items from one organization to another organization of the same business group.
Purchase Requisition is raised when we are getting the items from outside the business group.

Step 2:Once the Requisition has been approved, we will be sending (Request For Quotes) RFQ’s to different Suppliers. It contains the information regarding the type of RFQ, terms and conditions, shipments, currency.
RFQ is of 3 types
• Bid RFQ • Catalog • Standard
BID: Used for a fixed specific quantity, Location and date. This will be used for large or expensive price of equipments. That you have never order before. There won’t be price any breaks for a BID Quotation.
CATALOG: This will be used for high volume items for which your supplier sends information regularly. The CATALOG RFQ includes price breaks at different quantity levels.
STANDARD: It is used for items we need only once or not very often for a specific fixed quantity, location and date. It includes price breaks at different quantity levels.

Step 3:We will be receiving the quotations from different suppliers. Quotation is of 3 Types.
• Bid
• Catalog
• Standard

Step 4:Based on the quotations, we will be deciding the supplier and purchasing order is given to that supplier.
Purchasing is of 4 types
• Standard
• Planned
• Blanket
• Contract

Step 5:Once we receive the items from the Supplier we will issue the receipts to the Supplier. This is done in 3 ways.
• Two-Way: In 2-way we will compare PO and Invoice.• Three-Way: In 3-way we will compare the PO, Receipt and Invoice.• Four-Way: In 4-way we will compare PO, Receipt, Inspection and Invoice.

2-Way Matching verifies that Purchase order and invoice information match within your tolerances as follows:Quantity Billed <-Quantity Ordered Invoice Price <- Purchase Order Price (<- Sign is used because of tolerances)

3-Way Matching verifies that the receipt and invoice information match with the quantity tolerances defined:Quantity billed Quantity received

4-Way Matching verifies that acceptance documents and invoice information match within the quantity tolerances defined:Quantity billed <- Quantity accepted. (Acceptance is done at the time of Inspecting goods).Whether a PO shipment has 2-way, 3-way or 4-way matching can be setup in the Shipment Details zone of the Enter PO form (character).

RECEIPT REQUIRED INSPECTION REQUIRED MATCHING
Yes Yes 4-Way
Yes No 3-Way
No No 2-Way
In ‘More’ alternative region of Shipments block, you define the Invoice Matching option, where you can choose 2-way, 3-way or 4-way match.

Step 6:Because of these Transactions Inventory and Payables get affected.