Thursday, September 29, 2016

Query to find out concurrent program details

select
prog.user_concurrent_program_name "program name",
prog.concurrent_program_name "program short name",
appl.application_name "program application name",
prog.description "program description",
exe.executable_name "executable name",
exe.execution_file_name "executable file name",
decode( exe.execution_method_code, 'I', 'PLSQL Stored Procedure', 'P', 'Report', 'L', 'SQL Loader','Q','SQL*Plus', exe.execution_method_code) "execution method"
from
fnd_executables exe,
fnd_application_tl appl,
fnd_concurrent_programs_vl prog
where exe.application_id = appl.application_id
AND exe.executable_id = prog.executable_id
AND appl.language='US'
AND prog.user_concurrent_program_name =:p_conc_prog_name

Wednesday, September 7, 2016

EDI Gateway & Trading Partner Setup

Overview of Oracle EDI Gateway

Oracle Applications provides users with the ability to conduct business electronically between trading partners based on the Electronic Commerce standards and methodology. One form of Electronic Commerce is Electronic Data Interchange (EDI).
EDI is an electronic exchange of information between trading partners. Data files are exchanged in a standard format to minimize manual effort, speed data processing, and ensure accuracy.
The EDI Gateway performs the following functions:

  • define trading partner groups and trading partner locations
  • enable transactions for trading partners
  • provide location code conversion between trading partner location codes and codes used in Oracle Applications
  • provide general code conversion between trading partner codes or standard codes
  • define interface data files so that application data can interface with EDI translators
  • extract application data, format, and write to data files (outbound transactions)
  • import data or converted codes into application open interface tables so that application program interfaces (API) can validate and update Oracle application tables (inbound transactions)

How Oracle EDI Gateway Works with Other Oracle Applications

Oracle Applications are designed with an open architecture for easy integration with EDI translators and electronic transmission products to provide a seamless solution. Oracle Applications utilize the Oracle EDI Gateway to integrate with EDI translator software. EDI translation software packages integrate with an electronic transmission service to provide a closed-loop between Oracle Applications and the trading partner's application.
The Oracle Applications for Manufacturing, Distribution, and Financials are EDI-enabled using the Oracle EDI Gateway product. The Oracle EDI Gateway product augments the existing standard paper document capabilities of Oracle Applications, or adds functionality where no corresponding paper documents exist.
A common EDI implementation is via ASCII data files in a batch environment. Data from the sending application is extracted into an application data file. The application data file is received by the translation software which translates it into the an EDI standard both trading partners agree upon. Then the EDI data file is placed on a network for transmission to the receiving application. The receiving application's EDI translator receives the EDI data file from the network and begins the file processing in reverse sequence. The translator translates the EDI data file and creates an application data file meaningful to the receiving application. The receiving application receives the application data file for processing and imports the data into the application.
The following figure illustrates the outbound EDI Gateway transaction flow:
Figure 1 - 1.

The following figure illustrates the inbound EDI Gateway transaction flow:
Figure 1 - 2.


Oracle EDI Gateway Product Architecture

With an open architecture, Oracle Applications allows you to choose the best translation and electronic transmission service for your business requirements. You can use a commercially available EDI translator and transmission provider or use a proprietary solution. The Oracle Applications and the Oracle EDI Gateway places no restriction on your choices.

Product Components for All Transactions

The Oracle EDI product architecture consists of the following features for both outbound and inbound EDI transactions.

Trading Partner Definition

Used for both inbound and outbound transactions to define trading partner locations within a trading partner group. By defining a trading partner, you do the following:

  • enable EDI translations
  • establish a link to the location or business entity defined in the Oracle Applications
  • establish a link to the trading partner definition in the EDI translator.

Code Conversion Definition

Used for both inbound and outbound transactions to convert general codes between the sending and receiving systems. This can be used to convert Oracle Applications codes to EDI standard codes or user-defined codes.

Flexfields

Flexfields (attributes) are user-defined fields in the Oracle Applications. They are found in both inbound and outbound transactions.
You have to modify the general EDI translator data maps or templates to use flexfields.

Product Components for Outbound Transactions

The Oracle EDI Gateway product architecture consists of the following components for outbound transactions:

Oracle Applications Concurrent Program Manager

Used for outbound transactions to initiate data extraction programs that create interface data files that are passed to the EDI translator for processing the data into the desired EDI standard.

Stored Procedures to Prevent Duplicate Extraction

Used with outbound transactions to provide encapsulated application logic to record the EDI transaction in the Oracle application. For example, the Oracle Purchasing tables are updated to reflect the extraction of purchase order data. This prevents the same data from being extracted again.

Transaction-specific Extension Tables

Used with outbound transactions to temporarily store user-supplied data or data from a non-Oracle Applications source that is required by target EDI documents. See: Extensible EDI Gateway Architecture.

Transaction-specific Interface Tables

Used with outbound transactions to temporarily store data extracted from the Oracle Applications, including converted codes and data copied from customized extension tables.

Transaction-specific Database Views

Used with outbound transactions to provide encapsulated data selection logic for the target EDI transaction. You enter selection criteria, using Standard Request Submission, to launch individual extract programs.

Interface Tables Table

Used with outbound transactions to store the starting record identifier of each section of the output file and to track which transaction-specific interface and extension tables are related. The data extract program uses this information to write the next sequential identifier at the beginning of each record in the data file.

Interface Columns Table

Used with outbound transactions to store the assigned location of each data element within the data file. The data extract program uses this information to write data to the correct position in the data file.

Data Extract Programs

Used with outbound transactions to create a standard ASCII data file format that can be mapped to any standard. The data file contains data from Oracle Applications, converted codes from EDI Gateway tables, and descriptive flexfields defined in both EDI Gateway and the Oracle applications.

Extension Tables

The EDI Gateway extension tables are used to hold outbound data from tables that are outside the Oracle application. These extension tables are installed with EDI Gateway. However, you must define and populate the table columns if you want to use these tables.
Each transaction interface table has one extension table per interface table for the given transaction. The extension tables share the same base interface table name as the transaction with an "_X" suffix. For example, the primary interface table ECE_DSNO_ORDERS has the extension table ECE_DSNO_ORDERS_X.

Industry-Specific Tables

Some Oracle Applications have additional application tables for vertical industry solutions. These additional tables are detected in the EDI Gateway by reading system setup tables. If industry-specific tables are detected, their data, along with customer-defined extension table data, is copied to the EDI Gateway extension tables during the data extraction for outbound transactions.

Note: EDI extension tables are not used with inbound transactions.

Product Components for Inbound Transactions

The Oracle EDI Gateway product architecture consists of the following components for inbound transactions:

Oracle Applications Concurrent Program Manager

Used for inbound transactions to initiate data load programs that import interface data files from the EDI translator to EDI Gateway for processing into Oracle Applications.

Data Load Programs

Used with inbound transactions to load the Oracle Applications open interfaces from a standard ASCII data file. The data load program converts external codes in the file to internal codes found in the code conversion tables. The internal codes found in the code conversion tables or found in the internal fields as populated by the EDI translator are loaded into the application open interface tables.

Oracle Applications Open Interface

Used with inbound transactions. The application open interface consists of temporary interface tables and an application open interface API. The temporary interface tables are used to store the data loaded by the data load programs. The API is used to validate the data in the temporary interface tables and populate the Oracle Application tables. See: Running the Import Program for Inbound Transactions. Error detection, reporting, correction, and recovery are addressed by the respective Oracle Applications.

EDI Standards Supported

The Oracle EDI Gateway product is designed to support any EDI standard supported by EDI translation software; it is not tailored to any specific EDI standard.

EDI Transaction Support

The following transactions are supported:

ASC X12EDIFACTDocument IDDescription
Inbound Transactions
810INVOICINIInbound Invoice
832PRICATCATIInbound Price / Sales Catalog
843QUOTESRRQIInbound Response to Request for Quote
850ORDERSPOIInbound Purchase Order
856DESADVASNIInbound Ship Notice / Manifest
857No equivalentSBNIInbound Shipping and Billing Notice
Outbound Transactions
824APERAKADVOOutbound Application Advice
810INVOICINOOutbound Invoice
820PAYORD / REMADVPYOOutbound Payment Order / Remittance Advice
830DELFORSPSOOutbound Planning Schedule
862DELJITSSSOOutbound Shipping Schedule
850ORDERSPOOOutbound Purchase Order
860ORDCHGPOCOOutbound Purchase Order Change Request
856DESADVDNSOOutbound Ship Notice / Manifest


Overview of Trading Partners

The term "trading partner" is used differently in the context of EDI translators than in the context of the EDI Gateway.For EDI translators, the purpose of trading partner data is to:

  • identify sending and receiving electronic mailbox addresses
  • identify the communication medium (such as network or direct connection)
  • enable specific transactions by trading partner
For the Oracle EDI Gateway, the purpose of trading partner data is to:
  • cross-reference a particular address location in Oracle Applications to the location code defined for the trading partner for that address
  • link the EDI translator trading partner identifier to the EDI Gateway trading partner for the primary business address entity in the transaction
  • enable specific transactions for the EDI Gateway trading partner
In the EDI Gateway, the trading partner is defined as any address in Oracle Applications. This allows the conversion of location codes between the sender's defined code in their application to the receiver's defined code in their Oracle Application and vice versa. The translator code definition in the EDI Gateway identifies the trading partner setup code as defined in the EDI translator.For example, assume the trading partner defined the address code as AL-012. However, the same physical address was defined as 1234 in Oracle Applications. Defining the trading partner location in the appropriate Oracle application ensures that the code AL-012 is returned in transactions.
When defining trading partner data in the EDI Gateway, transactions must be enabled for the trading partner in order for data to be imported or extracted and written to the data file.

Inbound Transactions

The primary trading partner location is the location in the transaction detail records that is reviewed in the EDI Gateway to determine the key business entity that has ownership of this transaction in the Oracle Application. This entity is at the address or site level in the transaction. The higher level customer or supplier definition (without addresses) is determined by the primary site entity found within the transaction.The EDI translator writes a trading partner code for the record 0010 control record but it is not reviewed by the EDI Gateway. The detail location codes extracted from N104 and NAD records are reviewed within the EDI Gateway to determine the primary entity as needed by the Oracle application.

Outbound Transactions

The primary trading partner location is the address location reviewed within the transaction to determine the trading partner code for the record 0010 control record. This is the coded that links the transaction to the trading partner definition in the EDI translator.
DocumentDirectionASC X12EDIFACTContentPrimary Trading Partner Location
INIInbound810INVOICInvoiceSUPPLIER SITE
CATIInbound832PRICATPrice / Sales CatalogSUPPLIER SITE
RRQIInbound843QUOTESResponse to Request for QuotationSUPPLIER SITE
POIInbound850ORDERSPurchase OrdersSHIP TO
ANSIInbound856DESADVShip Notice / ManifestSUPPLIER SITE
SBNIInbound857n/aShipment and Billing NoticeSHIP TO
INOOutbound810INVOICInvoiceBILL TO
PYOOutbound820REMADV / PAYORDPayment Order / Remittance AdvicePAYING BANK BRANCH
SPSOOutbound830DELFORPlanning ScheduleSUPPLIER SITE
POOOutbound850ORDERSPurchase OrdersSUPPLIER SITE
POCOOutbound860ORDCHGPurchase Order ChangeSUPPLIER SITE
SSSOOutbound862DELJITShipping ScheduleSUPPLIER SITE

Each trading partner is assigned a primary address to associate with the transaction, such as bill-to address for outbound invoices or ship-to address for inbound purchase orders.
If a trading partner is both a customer and a supplier, Oracle recommends that you define the partner twice, once as a customer and once as a supplier. For each, enter a note in the trading partner description field to indicate whether it is the customer or supplier definition.
You must define a trading partner header for every location code found in the transaction. For example, an outbound invoice may have a remit-to location and a ship-to location. Both locations must be defined as trading partners in the EDI Gateway to define the external location code to appear in transactions.

Test / Production Transaction Status

Each application open interface has its own processing rules for validating EDI inbound transactions, including those marked as test transactions. The test / production status code is found on the control record (0010) in the data file. The status code is set by the EDI translator for inbound transactions. For outbound transactions, the status code is set by the EDI Gateway.Some open interface programs include a test / production status code as one of the parameters entered when you launch the Standard Request. This status code may override the test / production status code found in the control record (0010) for each transaction.

    Note: The test / production status code may be presented differently for various reasons. For example, T for Test, P for Production, or Y for Yes.
If the application open interface table has a test / production status code, the following may happen:

  • the test / production status code is passed from the control record of each transaction to the open interface table without being overridden by the Standard Request Submission or the open interface.
  • the test /production status code is passed from the control record but overridden by the test / production code from the Standard Request Submission parameters
  • the test / production status code is ignored by the application open interface and is determined from the Standard Request Submission parameters.
For further information, refer to the Oracle Manufacturing and Distribution Open Interfaces Manual, Release 11 or the Oracle Financials Open Interfaces Manual, Release 11.

EDI in a Multi-Organization Environment

A separate EDI responsibility must be defined for each organization that processes EDI transactions. Therefore, you must run EDI transactions separately by organization.
    Note: Some outbound transactions may operate on all organizations. However, you must still define a separate responsibility for each organization.
For outbound transactions, you extract data for the organization assigned to the current responsibility. So, if you intend to extract data from multiple organizations, you must do so from separate responsibilities.
For inbound transactions, the EDI translator, another process, or the trading partner sending the data file must separate the transactions by organization before the EDI Gateway imports the data. In other words, each data file sent by a trading partner should contain only those transactions into the specific organization.
If you intend to extract data from multiple organizations, you must switch to Transactions associated with other organizations will not successfully cross-reference the trading partner's location codes. The EDI Gateway associates the organization defined in the EDI Gateway responsibility with each primary trading partner location during the location cross reference. If the responsibility has organization A, but all the trading partner primary locations in the transactions are defined to organization B in the Oracle Application, the location codes cross reference process cannot find the location in the Oracle Application. The EDI Gateway reads only trading partner locations for the specified organization.

    Attention: During code conversion, the organization defined in the EDI responsibility is assigned to the trading partner primary location. If that organization is not correct for the location, the application open interface rejects the transaction during validation. Review the error report or on-line error handling procedure for the specific application.

Separate Transactions by Location

EDI translators can separate transactions into different data files. Transactions can be segregated into:
  • different trading partner electronic envelopes
  • different functional groups within the same electronic envelope
  • different mailboxes.
One solution is to have your trading partner separate the transactions in separate address locations that mirror your different organizations. If you have a single physical address that you have defined to two or more organizations, you may request that your trading partner also distinguish the locations. They can define unique address site / location codes in their application even those codes have the same physical address. The EDI translator can then separate the transactions to different electronic envelopes or functional groups within envelopes. The transactions can then be processed separately into different organizations.

Address Site ID Retrieval

Each transaction is associated with a primary internal location address site defined in the Oracle application. That has a corresponding external location code defined by the trading partner. The external code is the location code found in the ASC X12 N1 name segment or the UN/EDIFACT NAD name and address segment. Multiple customers could use the same external location codes because the combination of their trading partner translator code (their identifier in the EDI translator) and their external location code make a unique combination in the EDI Gateway trading partner definition. This pair of codes is associated with the address site in the Oracle application.There is a conflict when a given trading partner sends transactions with the same trading partner translator code and the same external location codes. However, some of these transactions are split across different organizations. Only one organization can be associated to a given address site.
Each EDI trading partner location code is derived from a unique address site ID defined in the Oracle application. That site ID is often written into the transaction so that the application open interface can correctly identify the correct address site for the customer, supplier, or other trading partner.
When extracting or importing transactions, only those address site IDs that belong to the organization defined for the current responsibility are retrieved. The same location codes used in other organizations are not retrieved, since the process is organization-specific.
The following table illustrates an external location code defined in multiple organizations. Assume that the trading partner used the code AB123 that is associated with two addresses in different organizations in the Oracle application:
Customer or SupplierAddress SiteTrading Partner Translator Code External Location Code (on N1 or NAD segment) Address Site IDOrganization for the Address Site ID
ACME Inc.123 Main, Chicago ILE1-ACME-1+AB123=12345678A
ACME. Inc.123 Main, Chicago ILE1-ACME-2+AB123=13567890B


    Note: The organization is defined in the Oracle application for this address site. This is not validated by the EDI Gateway. It may be passed to the application open interface table given the address site ID that is retrieved by the EDI Gateway.

    The address site ID is assigned when you set up the trading partner and is retrieved when the EDI Gateway processes the transaction.
    The EDI Gateway cross-references the trading partner external location code to the Oracle application internal location code (defined during trading partner set up) to retrieve the associated address site ID to be used bye the application open interface. For organization A, only the address site IDs defined for organization A are retrieved. Address site ID 13567890 in organization B is not referenced during execution.
    Attention: If there are problems with transactions loading to the correct address site, review the organization for the address site, and check the EDI responsibility in use when loading transactions to the open interface tables.

Test and Production Environments

The following table describes four possible scenarios for inbound transactions. If you import a production transaction into either a production or test environment, or if you import a test transaction in a test environment, the open interfaces validate the data and load it into production tables.However, you must use caution when importing a test transaction into a production environment. Otherwise, test data is imported into your production environment.

Test Transaction to Production Environment

    Caution: Unless care is exercised, test transactions may be processed into production tables. You must set up test / production status codes properly in your EDI translator and enter them properly when you launch Standard Requests to ensure test data is not loaded into your production database.
If the application open interface has a test / production status code and it is set for test, validation is performed but data is not committed to the database. (To perform a complete test where data is committed to the database, you must set up a test environment with a test database.)
If the trading partner is currently in production for the particular transaction at the particular site, and you want to test a transaction for that trading partner, make sure that you set up a trading partner for the test transaction with a different translator code. All test transactions must be given a different translator code when defining trading partner data. All test / production flags are associated with the combinationof the trading partner definition and the translator code. Providing different translator codes for production and test transactions ensures that the two are not confused. This is only necessary if the trading partner is mixing production and test transactions for the same locations within one translator code.


Defining Trading Partner Data

   To define a trading partner group:

    1. Navigate to the Trading Partner Groups window.
    2. Enter a unique trading partner group identifier.
    A trading partner group is a collection of individual address entities for a given trading partner.
    3. Optionally, enter a description for the trading partner group.
    4. Do one of the following:
  • To add a new trading partner to a trading partner group, enter the trading partner code and description. Then choose the New button.
    This trading partner entity is linked to a physical address in the Oracle application using the Assignments alternative region of the Define Trading Partner window.
  • To update an existing trading partner in a trading partner group, enter the trading partner location code and description. Then choose the Open button.

   To define a trading partner within a trading partner group:

    1. Enter a unique trading partner identifier. This defines a trading partner identifier for the EDI Gateway. This code is not written to the data files.
    2. Optionally, enter the trading partner description.
    3. Enter references 1 and 2. This is for any additional information needed by the trading partner.
    This data is written to the control record of every outbound transaction as the primary location for the specific transaction. You can use this information to return codes to the trading partner per their requirement.
    For example, assume the bill-to customer wants code 'AB-XY' added to all invoices, but you do not want to define an application flexfield for this customer-specific code. Once the code is in the data file, you can map it to the desired data element in the standard transaction.
    4. Access trading partner flexfields (also known as attributes) set up using system administration.

   To define trading partner assignment:

    1. In the Assignment alternative region, associate this trading partner definition with the corresponding Oracle Applications physical address entity. This is usually address- or site-level data.
    2. Do one of the following:
  • If you are defining the trading partner as a customer, select a customer and customer site. These values are defined in Oracle Order Entry and / or Oracle Receivables.
  • If you are defining the trading partner as a supplier, select a supplier and supplier site. These values are defined in Oracle Purchasing and / or Oracle Payables.
  • If you are defining the trading partner as a bank, select a bank branch address. This value is defined in Payables.
  • If you are defining other trading partner relationships, select the Human Resources location code. These values are defined in Oracle Human Resources.

   To define trading partner details:

    1. Open the Details alternative region to enable EDI transactions and processing rules for the trading partner location.
    2. Select the EDI document and the document type. Doing so enables the transaction for the trading partner.
    You must enter each document and each type explicitly to enable the transaction. If you do not enter both, no data is extracted.
    3. Enter the translator code (as defined in the EDI translator software) to associate with the transaction and location which is being enabled. The translator code links the EDI Gateway trading partner definition to that in the EDI translator.
    4. Indicate whether to send documents via EDI to this trading partner. This permits outbound transactions to be extracted and sent via EDI for this trading partner.
    5. Indicate whether to print a paper copy for this partner. (This functionality is not presently supported.)
    6. Indicate whether you are sending / receiving test EDI transactions for this partner.
    This allows transactions to be marked as a test transaction even if it is extracted from a production application. This code should agree with the test / production flag defined in the EDI translator software.

   To define trading partner contact data:

  • Optionally, open the Contact alternative region and enter the EDI contact name, title, basic address information, electronic mail address, phone, fax number, and so on. This information is useful for EDI coordinators in case issues arise regarding transmission of EDI files. This data is not written to the data files. The data is independent of all contact information in the Oracle Applications.

Thursday, September 1, 2016

AutoInvoice Grouping Rules

AutoInvoice Grouping Rules

Grouping rules specify attributes that must be identical for lines to be created as one transaction. Grouping rules always include the mandatory attributes, and to this is added optional attributes that you define in the grouping rule.
Grouping rules tell AutoInvoice how you want to group records in the interface tables into invoices, debit memos, and credit memos. Grouping rules specify which attributes must be identical for lines to appear on the same transaction.
All grouping rules you define implicitly include mandatory attributes plus the optional attributes you define.  So if you want to refine the grouping of transaction records, you can use the Optional Grouping Attributes to do so.
All transaction records  having the same Grouping Attributes (Mandatory and Optional)  are grouped into the same transaction.
Responsibility: Receivables Manager
Navigation: Setup > Transactions > AutoInvoice > Grouping Rules
As per the grouping rules the grouping happens based upon Interface Line Attribute1 for invoice class.

Auto Invoice Import

Sample scripts to populate the table for various scenarios:

INSERT INTO ra_interface_lines_all ( interface_line_context , interface_line_attribute1 , interface_line_attribute2 , amount , batch_source_name , conversion_rate , conversion_type , currency_code , cust_trx_type_id , description , gl_date , line_type , orig_system_bill_address_id , orig_system_bill_customer_id , quantity , unit_selling_price , term_id , taxable_flag , amount_includes_tax_flag , set_of_books_id , org_id) VALUES ( 'XAOA' , 'All Oracle Apps 2' , 'ALLORACLEAPPS.COM 2' , 1000.00 , 'AOA Transaction Source' , 1 , 'User' , 'USD' , 3436 , 'All Oracle Apps 2 - ITEM #1' , '10-DEC-2013' , 'LINE' , 11842 , 126871 , 10 , 100.00 , 1228 , 'Y' , 'N' , 1 , 204); COMMIT;

SQL * LOADER

SQL LOADER is an Oracle utility used to load data into table given a datafile which has the records that need to be loaded. SQL*Loader takes data file, as well as a control file, to insert data into the table. When a Control file is executed, it can create Three (3) files called log file, bad file or reject file, discard file.
·         Log file tells you the state of the tables and indexes and the number of logical records already read from the input datafile. This information can be used to resume the load where it left off.
·         Bad file or reject file gives you the records that were rejected because of formatting errors or because they caused Oracle errors.
·         Discard file specifies the records that do not meet any of the loading criteria like when any of the WHEN clauses specified in the control file. These records differ from rejected records.
Structure of the data file:
The data file can be in fixed record format or variable record format.
Fixed Record Format would look like the below. In this case you give a specific position where the Control file can expect a data field:
7369 SMITH      CLERK        7902  12/17/1980         800
7499 ALLEN      SALESMAN  7698  2/20/1981           1600
7521 WARD      SALESMAN  7698  2/22/1981           1250
7566 JONES      MANAGER   7839  4/2/1981             2975
7654 MARTIN    SALESMAN  7698  9/28/1981           1250
7698 BLAKE      MANAGER   7839  5/1/1981             2850
7782 CLARK      MANAGER   7839  6/9/1981             2450
7788 SCOTT      ANALYST    7566  12/9/1982           3000
7839 KING        PRESIDENT          11/17/1981         5000
7844 TURNER    SALESMAN  7698  9/8/1981            1500
7876 ADAMS     CLERK         7788  1/12/1983          1100
7900 JAMES      CLERK         7698  12/3/1981          950
7902 FORD        ANALYST     7566  12/3/1981          3000
7934 MILLER     CLERK         7782  1/23/1982          1300
Variable Record Format would like below where the data fields are separated by a delimiter.
Note: The Delimiter can be anything you like. In this case it is “|”
1196700|9|0|692.64
1378901|2|3900|488.62
1418700|2|2320|467.92
1418702|14|8740|4056.36
1499100|1|0|3.68
1632800|3|0|1866.66
1632900|1|70|12.64
1637600|50|0|755.5

Structure of a Control file:
Sample CTL file for loading a Variable record data file:
OPTIONS (SKIP = 1)   --The first row in the data file is skipped without loading

LOAD DATA

INFILE '$FILE'             -- Specify the data file  path and name

APPEND                       -- type of loading (INSERT, APPEND, REPLACE, TRUNCATE

INTO TABLE "APPS"."BUDGET"   -- the table to be loaded into

FIELDS TERMINATED BY '|'           -- Specify the delimiter if variable format datafile

OPTIONALLY ENCLOSED BY '"'   --the values of the data fields may be enclosed in "

TRAILING NULLCOLS     -- columns that are not present in the record treated as null

(ITEM_NUMBER    "TRIM(:ITEM_NUMBER)", -- Can use all SQL functions on columns

QTY                 DECIMAL EXTERNAL,

REVENUE             DECIMAL EXTERNAL,

EXT_COST            DECIMAL EXTERNAL TERMINATED BY WHITESPACE "(TRIM(:EXT_COST))"  ,

MONTH           "to_char(LAST_DAY(ADD_MONTHS(SYSDATE,-1)),'DD-MON-YY')" ,

DIVISION_CODE    CONSTANT "AUD"  -- Can specify constant value instead of Getting value from datafile

)
OPTION statement precedes the LOAD DATA statement. The OPTIONS parameter allows you to specify runtime arguments in the control file, rather than on the command line. The following arguments can be specified using the OPTIONS parameter.
SKIP = n — Number of logical records to skip (Default 0)
LOAD = n — Number of logical records to load (Default all)
ERRORS = n — Number of errors to allow (Default 50)
ROWS = n   — Number of rows in conventional path bind array or between direct path data saves (Default: Conventional Path 64, Direct path all)
BINDSIZE = n — Size of conventional path bind array in bytes (System-dependent default)
SILENT = {FEEDBACK | ERRORS | DISCARDS | ALL} — Suppress messages during run
(header, feedback, errors, discards, partitions, all)
DIRECT = {TRUE | FALSE} –Use direct path (Default FALSE)
PARALLEL = {TRUE | FALSE} — Perform parallel load (Default FALSE)
LOADDATA statement is required at the beginning of the control file.
INFILE: INFILE keyword is used to specify location of the datafile or datafiles.
INFILE* specifies that the data is found in the control file and not in an external file. INFILE ‘$FILE’, can be used to send the filepath and filename as a parameter when registered as a concurrent program.
INFILE   ‘/home/vision/kap/import2.csv’ specifies the filepath and the filename.

Example where datafile is an external file:
LOAD DATA
INFILE   ‘/home/vision/kap/import2.csv’
INTO TABLE kap_emp
FIELDS TERMINATED BY “,”
( emp_num, emp_name, department_num, department_name )


Example where datafile is in the Control file:
LOAD DATA
INFILE *
INTO TABLE kap_emp
FIELDS TERMINATED BY “,”
( emp_num, emp_name, department_num, department_name )
BEGINDATA
7369,SMITH,7902,Accounting
7499,ALLEN,7698,Sales
7521,WARD,7698,Accounting
7566,JONES,7839,Sales
7654,MARTIN,7698,Accounting

Example where file name and path is sent as a parameter when registered as a concurrent program
LOAD DATA
INFILE ‘$FILE’
INTO TABLE kap_emp
FIELDS TERMINATED BY “,”
( emp_num, emp_name, department_num, department_name )
TYPE OF LOADING:
INSERT   — If the table you are loading is empty, INSERT can be used.
APPEND  — If data already exists in the table, SQL*Loader appends the new rows to it. If data doesn’t already exist, the new rows are simply loaded.
REPLACE — All rows in the table are deleted and the new data is loaded
TRUNCATE — SQL*Loader uses the SQL TRUNCATE command.
INTOTABLEis required to identify the table to be loaded into. In the above example INTO TABLE “APPS”.”BUDGET”, APPS refers to the Schema and BUDGET is the Table name.
FIELDS TERMINATED BY specifies how the data fields are terminated in the datafile.(If the file is Comma delimited or Pipe delimited etc)
OPTIONALLY ENCLOSED BY ‘”‘ specifies that data fields may also be enclosed by quotation marks.
TRAILINGNULLCOLS clause tells SQL*Loader to treat any relatively positioned columns that are not present in the record as null columns.

Loading a fixed format data file:
LOAD DATA
INFILE ‘sample.dat’
INTO TABLE emp
( empno         POSITION(01:04)   INTEGER EXTERNAL,
ename          POSITION(06:15)   CHAR,
job            POSITION(17:25)   CHAR,
mgr            POSITION(27:30)   INTEGER EXTERNAL,
sal            POSITION(32:39)   DECIMAL EXTERNAL,
comm           POSITION(41:48)   DECIMAL EXTERNAL,
deptno         POSITION(50:51)   INTEGER EXTERNAL)

Steps to Run the SQL* LOADER from UNIX:
At the prompt, invoke SQL*Loader as follows:
sqlldr USERID=scott/tiger CONTROL=<control filename> LOG=<Log file name>
SQL*Loader loads the tables, creates the log file, and returns you to the system prompt. You can check the log file to see the results of running the case study.

Register as concurrent Program:
Place the Control file in $CUSTOM_TOP/bin.
Define the Executable. Give the Execution Method as SQL*LOADER.
Define the Program. Add the Parameter for FILENAME.


Skip columns:
You can skip columns using the ‘FILLER’ option.
Load Data



TRAILING  NULLCOLS
(
name Filler,
Empno ,
sal
)
here the column name will be skipped.
SQL LOADER is a very powerful tool that lets you load data from a delimited or position based data file into Oracle tables. We have received many questions regarding SQL LOADER features from many users. Here is the brief explanation on the same.
Please note that the basic knowledge of SQL LOADER is required to understand this article.
This article covers the below topics:
1.Load multiple data files into a single table
2.Load a single data file into multiple tables
3.Skip a column while loading using “FILLER” and Load field in the delimited data file into two different columns in a table using “POSITION”
4.Usage of BOUNDFILLER
5.Load the same record twice into a single table
6.Using WHEN to selectively load the records into the table
7.Run SQLLDR from SQL PLUS
8.Default path for Discard, bad and log files
1)Load multiple files into a single table:
SQL LOADER lets you load multiple data files at once into a single table. But all the data files should be of the same format.
Here is a working example:
Say you have a table named EMP which has the below structure:
Column
Data Type
emp_num
Number
emp_name
Varchar2(25)
department_num
Number
department_name
Varchar2(25)

You are trying to load the below comma delimited data files named eg.dat and eg1.dat:
eg.dat:
7369,SMITH,7902,Accounting
7499,ALLEN,7698,Sales
7521,WARD,7698,Accounting
7566,JONES,7839,Sales
7654,MARTIN,7698,Accounting

eg1.dat:
1234,Tom,2345,Accounting
3456,Berry,8976,Accounting

The Control file should be built as below:

LOAD DATA
INFILE ‘eg.dat’ — File 1
INFILE ‘eg1.dat’ — File 2
APPEND
INTO TABLE emp
FIELDS TERMINATED BY “,”
( emp_num, emp_name, department_num, department_name )

2)Load a single file into multiple tables:
SQL Loader lets you load a single data file into multiple tables using “INTO TABLE” clause.
Here is a working example:
Say you have two tables named EMP and DEPT which have the below structure:
Table
Column
Data Type
EMP
emp_num
Number
EMP
emp_name
Varchar2(25)
DEPT
department_num
Number
DEPT
department_name
Varchar2(25)

You are trying to load the below comma delimited data file named eg.dat which has columns Emp_num and emp_name that need to be loaded into table EMP and columns department_num and department_name that need to be loaded into table DEPT using a single CTL file here.
eg.dat:
7369,SMITH,7902,Accounting
7499,ALLEN,7698,Sales
7521,WARD,7698,Accounting
7566,JONES,7839,Sales
7654,MARTIN,7698,Accounting

The Control file should be built as below:
LOAD DATA
INFILE ‘eg.dat’
APPEND
INTO TABLE emp
FIELDS TERMINATED BY “,”
( emp_num, emp_name )
INTO TABLE dept
FIELDS TERMINATED BY “,”
(department_num, department_name)
You can further use WHEN clause to selectively load the records into the tables which will be explained later in this article.

3)Skip a column while loading using “FILLER” and Load field in the delimited data file into two different columns in a table using “POSITION”
SQL LOADER lets to skip unwanted fields in the data file by using the “FILLER” clause. Filler was introduced in Oracle 8i.
SQL LOADER also lets you load the same field into two different columns of the table.
If the data file is position based, loading the same field into two different columns is pretty straight forward. You can use Position (start_pos:end_pos) keyword
If the data file is a delimited file and it has a header included in it, then this can be achieved by referring the field preceded with “:” eg description “(:emp_name)”.
If the data file is delimited file without a header included in it, Position (start_pos:end_pos) or “(:field)” will not work. This can be achieved using POSITION (1) clause which takes you to the beginning of the record.

Here is a Working Example:
The requirement here is to load the field emp_name in the data field into two columns – emp_name and description of the table EMP. Here is the Working Example:

Say you have a table named EMP which has the below structure:
Column
Data Type
emp_num
Number
emp_name
Varchar2(25)
description
Varchar2(25)
department_num
Number
department_name
Varchar2(25)

You are trying to load the below comma delimited data file named eg.dat which has 4 fields that need to be loaded into 5 columns of the table EMP.
eg.dat:
7369,SMITH,7902,Accounting
7499,ALLEN,7698,Sales
7521,WARD,7698,Accounting
7566,JONES,7839,Sales
7654,MARTIN,7698,Accounting

Control File:
LOAD DATA
INFILE ‘eg.dat’
APPEND
INTO TABLE emp
FIELDS TERMINATED BY “,”
(emp_num,
emp_name,
desc_skip FILLER POSITION(1),
description,
department_num,
department_name)
Explanation on how SQL LOADER processes the above CTL file:
·The first field in the data file is loaded into column emp_num of table EMP
·The second field in the data file is loaded into column emp_name of table EMP
·The field desc_skip enables SQL LOADER to start scanning the same record it is at from the beginning because of the clause POSITION(1) . SQL LOADER again reads the first delimited field and skips it as directed by “FILLER” keyword.
·Now SQL LOADER reads the second field again and loads it into description column of the table EMP.
·SQL LOADER then reads the third field in the data file and loads into column department_num of table EMP
·Finally the fourth field is loaded into column department_name of table EMP.
4)Usage of BOUNDFILLER
BOUNDFILLER is available with Oracle 9i and above and can be used if the skipped column’s value will be required later again.
Here is an example:
The requirement is to load first two fields concatenated with the third field as emp_num into table emp and Fourth field as Emp_name

Data File:
1,15,7369,SMITH
1,15,7499,ALLEN
1,15,7521,WARD
1,18,7566,JONES
1,20,7654,MARTIN

The requirement can be achieved using the below Control File:
LOAD DATA
INFILE ‘C:eg.dat’
APPEND
INTO TABLE EMP
FIELDS TERMINATED BY “,”
(
Rec_skip BOUNDFILLER,
tmp_skip BOUNDFILLER,
Emp_num “(:Rec_skip||:tmp_skip||:emp_num)”,
Emp_name
)

5)Load the same record twice into a single table:
SQL Loader lets you load record twice using POSITION clause but you have to take into account whether the constraints defined on the table allow you to insert duplicate rows.

Below is the Control file:

LOAD DATA
INFILE ‘eg.dat’
APPEND
INTO TABLE emp
FIELDS TERMINATED BY “,”
( emp_num, emp_name, department_num, department_name )
INTO TABLE emp
FIELDS TERMINATED BY “,”
(emp_num POSITION(1),emp_name,department_num,department_name)

SQL LOADER processes the above control file this way:
First “INTO TABLE” clause loads the 4 fields specified in the first line of the data file into the respective columns (emp_num, emp_name, department_num, department_name)
Field scanning does not start over from the beginning of the record when SQL LOADER encounters the second INTO TABLE clause in the CTL file. Instead, scanning continues where it left off. Statement “emp_num POSITION(1)” in the CTL file forces the SQL LOADER to read the same record from the beginning and loads the first field in the data file into emp_num column again. The remaining fields in the first record of the data file are again loaded into respective columns emp_name, department_num, department_name. Thus the same record can be loaded multiple times into the same table using “INTO TABLE” clause.

6)Using WHEN to selectively load the records into the table
WHEN clause can be used to direct SQL LOADER to load the record only when the condition specified in the WHEN clause is TRUE. WHEN statement can have any number of comparisons preceded by AND. SQL*Loader does not allow the use of OR in the WHEN clause.
Here is a working example which illustrates how to load the records into 2 tables EMP and DEPT based on the record type specified in the data file.
The below is delimited data file eg.dat which has the first field as the record type. The requirement here is to load all the records with record type = 1 into table EMP and all the records with record type = 2 into table DEPT and record with record type =3 which happens to be the trailer record should not be loaded.
1,7369,SMITH
2,7902,Accounting
1,7499,ALLEN
2,7698,Sales
1,7521,WARD
2,7698,Accounting
1,7566,JONES
2,7839,Sales
1,7654,MARTIN
2,7698,Accounting
3,10
Control File:
LOAD DATA
INFILE ‘eg.dat’
APPEND
INTO TABLE emp
WHEN (01) = ‘1’
FIELDS TERMINATED BY “,”
( rec_skip filler POSITION(1),emp_num , emp_name )
INTO TABLE dept
WHEN (01) = ‘2’
FIELDS TERMINATED BY “,”
(rec_skip filler POSITION(1),department_num,
department_name )
Let’s now see how SQL LOADER processes the CTL file:
·SQL LOADER loads the records into table EMP only when first position (01) of the record which happens to be the record type is ‘1’ as directed by command
INTO TABLE emp
WHEN (01) = ‘1’
·If condition When (01) = ‘1’ holds true for the current record, then SQL LOADER gets to the beginning of the record as directed by command POSITION(1) and skips the first field which is the record type.
·It then loads the second field into emp_num and third field into emp_name column in the table EMP.
·SQL LOADER loads the records into table DEPT only when first position (01) of the record which happens to be the record type is ‘2’ as directed by the commands –
INTO TABLE dept
WHEN (01) = ‘2’
·If condition When (01) = ‘2’ holds true for the current record, then SQL LOADER gets to the beginning of the record as directed by command POSITION(1) and skips the first field which is the record type.
·It then loads the second field into department_num and third field into department_name columns in the table DEPT.
·The records with record type = ‘3’ are not loaded into any table.
Thus you can selectively loads the necessary records into various tables using WHEN clause.

7)Run SQLLDR from SQL PLUS
SQL LOADER can be invoked from SQL PLUS using “host” command as shown below:
host sqlldr userid= username/password@host control = C:eg.ctl log = eg.log

8)Default path for Discard, bad and log files
If bad and discard file paths are not specified in the CTL file and if this SQL Loader is registered as a concurrent program, then they will be created in the directory where the regular Concurrent programs’ output files reside. You can also find the paths where the discard and bad files have been created in the log file of the SQL LOADER concurrent request.


Oracle Fusion - Cost Lines and Expenditure Item link in Projects

SELECT   ccd.transaction_id,ex.expenditure_item_id,cacat.serial_number FROM fusion.CST_INV_TRANSACTIONS cit,   fusion.cst_cost_distribution_...