What is attachment in oracle application?
The attachments feature in oracle application enables users to link unstructured data, such as images, word-processing documents, spreadsheets, or text to their application data. For example, users can link images to items or video to operations as operation instructions.
Where to find an attachment?
There is an attachment icon in the oracle application toolbar that indicates whether the Attachments feature is enabled in a form block. When the button is dimmed, the Attachment feature is not available. When the Attachment feature is enabled in a form block, the icon becomes a solid paper clip. The icon switches to a paper clip holding a paper when the Attachment feature is enabled in a form lock and the current record has at least one attachment.
Attachment types:
An attached document can be:
1] Short Text
Text stored in the database containing less than 2000 characters.
2] Long Text
Text stored in the database containing 2000 characters or more.
3] Image
An image that Oracle Forms can display, including: bmp, cals, jfif, jpeg, gif, pcd, pcx, pict, ras, and tif.
4] OLE Object
An OLE Object that requires other OLE server applications to view, such as Microsoft Word or Microsoft Excel.
5] Web Page
A URL reference to a web page which you can view with your web browser.

Tables Involved:
For Importing Attachments in oracle application one has to populate following tables.
1. FND_DOCUMENTS
2. FND_ATTACHED_DOCUMENTS
3. FND_DOCUMENTS_TL
4. FND_DOCUMENT_DATATYPES.
5. FND_DOCUMENT_CATEGORIES
6. FND_DOCUMENTS_LONG_TEXT (Long text type attachment).
7. FND_DOCUMENTS_SHORT_TEXT (Short text type attachment).
8. FND_DOCUMENTS_LONG_RAW
9. FND_LOBS (File type attachments).
FND_DOCUMENTS:
FND_DOCUMENTS stores language-independent information about a document. For example, each row contains a document identifier, a category identifier, the method of security used for the document (SECURITY_TYPE, where 1=Organization,2=Set of Books, 3=Business unit,4=None), the period in which the document is active, and a flag to indicate whether or not the document can be shared outside of the security type (PUBLISH_FLAG).
Other specifications in this table include: datatype (DATATYPE_ID, where 1=short text,2=long text, 3=image, 4=OLE object), image type, and storage type (STORAGE_TYPE, where 1=stored in the database, 2=stored in the file system).
The document can be referenced by many application entities and changed only in the define document form (USAGE_TYPE=S); it can be used as a fill-in-the-blanks document, where each time you use a template, you make a copy of it (USAGE_TYPE=T); or it can be used only one time (USAGE_TYPE=O).Images and OLE Objects cannot be used as templates.
FND_ATTACHED_DOCUMENTS:
FND_ATTACHED_DOCUMENTS stores information relating a document to an application entity.  For example, a record may link a document to a sales order or an item. Each row contains foreign keys to FND_DOCUMENTS and FND_DOCUMENT_ENTITIES. There is also a flag to indicate whether or not an attachment was created automatically.
FND_DOCUMENTS_TL:
FND_DOCUMENTS_TL stores translated information about the documents in FND_DOCUMENTS. Each row includes the document identifier, the language the row is translated to, the description of the document, the file in which the image is stored, and an identifier (MEDIA_ID) of the sub-table in which the document is saved (FND_DOCUMENTS_SHORT_TEXT, FND_DOCUMENTS_LONG_TEXT, or FND_DOCUMENTS_LONG_RAW).
FND_DOCUMENT_DATATYPES:
FND_DOCUMENT_DATATYPES stores the document datatypes that are supported. Initial values are: short text, long text, image, and OLE Object (DATATYPE_ID=1, 2, 3, or 4). Customers can add datatypes to handle documents stored outside of Oracle and use non-native Forms applications to view/edit their documents. The table uses a “duplicate record” model for handling multi-lingual needs. That is, for each category there will be one record with the same CATEGORY_ID and CATEGORY_NAME for each language.
FND_DOCUMENT_CATEGORIES:
FND_DOCUMENT_CATEGORIES stores information about the categories in which documents are classified. For example, documents may be considered “Bill of Material Comments”, “WIP Job Comments”, etc. Document categories are used to provide a measure of security on documents. Each form that enables the attachment feature lists which categories of documents can be viewed in the form. This table uses a “duplicate record” model for handling multi-lingual needs.
FND_DOCUMENTS_LONG_TEXT:
FND_DOCUMENTS_LONG_TEXT stores information about long text documents.
FND_DOCUMENTS_SHORT_TEXT:
FND_DOCUMENTS_SHORT_TEXT stores information about short text documents.
FND_DOCUMENTS_LONG_RAW:
FND_DOCUMENTS_LONG_RAW stores images and OLE Objects, such as Word Documents and Excel spreadsheets, in the database.
FND_DOCUMENT_ENTITIES:
FND_DOCUMENT_ENTITIES lists each entity to which attachments can be linked. For example, attachments can be linked to Items, Sales Orders, etc. Since the table uses a “duplicate record” model for handling multi-lingual needs, for each document entity there will be one record with the same DOCUMENT_ENTITY_ID and DATA_OBJECT_CODE for each language.

Queries:
1] To find all Long Text attachments:

SELECT
        FAD.SEQ_NUM “Seq Number”,
        FDAT.USER_NAME “Data Type”,
        FDCT.USER_NAME “Category User Name”,
        FAD.ATTACHED_DOCUMENT_ID “Attached Document Id”,
        FDET.USER_ENTITY_NAME “User Entity”,
        FD.DOCUMENT_ID “Document Id”,
        FAD.ENTITY_NAME “Entity Name”,
        FD.MEDIA_ID “Media Id”,
        FD.URL “Url”,
        FDT.TITLE “Title”,
        FDLT.LONG_TEXT “Attachment Text”
FROM
        FND_DOCUMENT_DATATYPES FDAT,
        FND_DOCUMENT_ENTITIES_TL FDET,
        FND_DOCUMENTS_TL FDT,
        FND_DOCUMENTS FD,
        FND_DOCUMENT_CATEGORIES_TL FDCT,
        FND_ATTACHED_DOCUMENTS   FAD,
        FND_DOCUMENTS_LONG_TEXT FDLT
WHERE
        FD.DOCUMENT_ID          = FAD.DOCUMENT_ID
        AND FDT.DOCUMENT_ID     = FD.DOCUMENT_ID
        AND FDCT.CATEGORY_ID    = FD.CATEGORY_ID
        AND FD.DATATYPE_ID      = FDAT.DATATYPE_ID
        AND FAD.ENTITY_NAME     = FDET.DATA_OBJECT_CODE
        AND FDLT.MEDIA_ID       = FD.MEDIA_ID
        AND FDAT.NAME           = ‘LONG_TEXT’;

 

2] To find all Short Text attachments:

SELECT
        FAD.SEQ_NUM “Seq Number”,
        FDAT.USER_NAME “Data Type”,
        FDCT.USER_NAME “Category User Name”,
        FAD.ATTACHED_DOCUMENT_ID “Attached Document Id”,
        FDET.USER_ENTITY_NAME “User Entity”,
        FD.DOCUMENT_ID “Document Id”,
        FAD.ENTITY_NAME “Entity Name”,
        FD.MEDIA_ID “Media Id”,
        FD.URL “Url”,
        FDT.TITLE “Title”,
        FDST.SHORT_TEXT “Attachment Text”
FROM
        FND_DOCUMENT_DATATYPES FDAT,
        FND_DOCUMENT_ENTITIES_TL FDET,
        FND_DOCUMENTS_TL FDT,
        FND_DOCUMENTS FD,
        FND_DOCUMENT_CATEGORIES_TL FDCT,
        FND_ATTACHED_DOCUMENTS   FAD,
        FND_DOCUMENTS_SHORT_TEXT FDST
WHERE
        FD.DOCUMENT_ID          = FAD.DOCUMENT_ID
        AND FDT.DOCUMENT_ID     = FD.DOCUMENT_ID
        AND FDCT.CATEGORY_ID    = FD.CATEGORY_ID
        AND FD.DATATYPE_ID      = FDAT.DATATYPE_ID
        AND FAD.ENTITY_NAME     = FDET.DATA_OBJECT_CODE
        AND FDST.MEDIA_ID       = FD.MEDIA_ID
        AND FDAT.NAME           = ‘SHORT_TEXT’;

Attachment upload through API:
Attachments can also be uploaded through an oracle provided API called  FND_ATTACHED_DOCUMENTS_PKG.
It consist of three procedures
1)  Insert Row
2)  Update Row
3)  Lock Row
Names of these procedures are self explanatory. insert row is used to insert a new row for attachment data, update row is used to update existing row for a particular row and Lock Row is used to lock a existing row for further modification.
 

AP_SUPPLIERS:

  • This table replaces the old PO_VENDORS table.
  • It stores information about your supplier level attributes.
  • Each row includes the purchasing, receiving, invoice, tax, classification, and general information.
  • Oracle Purchasing uses this information to determine active suppliers.
  • The supplier name, legal identifiers of the supplier will be stored in TCA and a reference to the party created in TCA will be stored in AP_SUPPLIERS.PARTY_ID, to link the party record in TCA.

AP_SUPPLIER_SITES_ALL:

  • This table replaces the old PO_VENDOR_SITES_ALL table.
  • It stores information about your supplier site level attributes.
  • There is a row for unique combination of supplier address, operating unit and the business relationship that you have with the supplier.
  • The supplier address information is not maintained in this table and is maintained in TCA. The reference to the internal identifier of address in TCA will be stored in AP_SUPPLIER_SITES_ALL.LOCATION_ID, to link the address record in TCA.
  • Each row includes the supplier reference, purchasing, invoice, and general information.

AP_INVOICES_ALL:

  • It contains records for invoices you enter.
  • There is one row for each invoice you enter.
  • An invoice can have one or more invoice distribution lines and can have one or more scheduled payments.  

AP_INVOICE_LINES_ALL:

  • It contains records for invoice lines entered manually, generated automatically or imported from the Open Interface.
  • An invoice can have one or more invoice lines.
  • An invoice line represents goods (direct or indirect materials), service(s), and/or associated tax/freight/miscellaneous charges invoiced from a supplier.
  • An invoice line should contain all the attributes that are present on the physical or electronic invoice presented by the supplier.

AP_INVOICE_DISTRIBUTIONS_ALL:

  • It holds the distribution information that is manually entered or system-generated.
  • There is one row for each invoice distribution and a distribution must be associated with an invoice.
  • An invoice can have multiple distributions.

AP_INVOICE_PAYMENTS_ALL:

  • It contains records of invoice payments that you made to suppliers.
  • There is one row for each payment you make for each invoice and there is one payment and one invoice for each payment in this table.
  • Oracle Payables application updates this table when you confirm an automatic payment batch, enter a manual payment, or process a Quick payment.
  • When you void a payment, your Oracle Payables inserts an additional payment line that is the negative of the original payment line.

AP_PAYMENT_SCHEDULES_ALL:

  • This table stores information about scheduled payment information on invoices.

AP_PAYMENT_HISTORY_ALL:

  • It stores the clearing/unclearing history for payments.
  • It also stores the maturity history for future dated payments.
  • The table contains a row for each future dated payment, once the future dated payment matures, i.e. becomes negotiable.
  • Any time a payment is cleared or uncleared, a row is inserted into this table for the payment.

AP_BATCHES_ALL:

  • It contains summary information about invoices you enter in batches if you enable the Batch Control Payables option.
  • There is one row for each batch of invoices you enter.
  •  If you enable Batch Control, each invoice must correspond to a record in this table.
  •  Your Oracle Payables application uses this information to group together invoices that one person entered in a batch.

AP_CHECKS_ALL:

  • It stores information about payments issued to suppliers or refunds received from suppliers. 
  • There is one row for each payment you issue to a supplier or refund received from a supplier.
  • Oracle Payables application uses this information to record payments you make to suppliers or refunds you receive from suppliers.
  • Oracle Payables application stores the supplier name and bank account name for auditing purposes, in case either one is changed after you create the payment. Oracle Payables application also stores address information for all payments.

AP_HOLDS_ALL:

  • It contains information about holds that you or your Oracle Payables application place on an invoice.
  • For non-matching holds, there is one row for each hold placed on an invoice. For matching holds, there is one row for each hold placed on an invoice-shipment match.
  • An invoice may have one or more corresponding rows in this table.
  • Your Oracle Payables application does not pay invoices that have one or more unreleased holds recorded in this table.

AP_BANK_ACCOUNTS_ALL:

  • It contains information about your bank accounts.
  • There is one row for each bank account you define and each bank account must be affiliated with one bank branch.

AP_BANK_ACCOUNT_USES_ALL:

  • It stores information for the internal and external bank accounts you define in Oracle Payables and Oracle Receivables applications.

AP_CARDS_ALL:

  • It stores information about the corporate credit cards issued to your employees by your corporate credit card providers.

AP_TRIAL_BALANCE:

  • It contains denormalized information about invoices and payments posted to the accrual set of books.
Below is the script to get the Concurrent Program Request details by Various Users in a Particular Day.

select
request_id,
parent_request_id,
fcpt.user_concurrent_program_name Request_Name,
fcpt.user_concurrent_program_name program_name,
DECODE(fcr.phase_code,
‘C’,’Completed’,
‘I’,’Incactive’,
‘P’,’Pending’,
‘R’,’Running’) phase,
DECODE(fcr.status_code,
‘D’,’Cancelled’,
‘U’,’Disabled’,
‘E’,’Error’,
‘M’,’No Manager’,
‘R’,’Normal’,
‘I’,’Normal’,
‘C’,’Normal’,
‘H’,’On Hold’,
‘W’,’Paused’,
‘B’,’Resuming’,
‘P’,’Scheduled’,
‘Q’,’Standby’,
‘S’,’Suspended’,
‘X’,’Terminated’,
‘T’,’Terminating’,
‘A’,’Waiting’,
‘Z’,’Waiting’,
‘G’,’Warning’,’N/A’) status,
round((fcr.actual_completion_date – fcr.actual_start_date),3) * 1440 as Run_Time,
round(avg(round(to_number(actual_start_date – fcr.requested_start_date),3) * 1440),2) wait_time,
fu.User_Name Requestor,
fcr.argument_text parameters,
to_char (fcr.requested_start_date, ‘MM/DD HH24:mi:SS’) requested_start,
to_char(actual_start_date, ‘MM/DD/YY HH24:mi:SS’) ACT_START,
to_char(actual_completion_date, ‘MM/DD/YY HH24:mi:SS’) ACT_COMP,
fcr.completion_text
From
apps.fnd_concurrent_requests fcr,
apps.fnd_concurrent_programs fcp,
apps.fnd_concurrent_programs_tl fcpt,
apps.fnd_user fu
Where 1=1
— and fu.user_name = ‘DJKOCH’ ‘
— and fcr.request_id = 1565261
— and fcpt.user_concurrent_program_name = ‘Payables Open Interface Import”
and fcr.concurrent_program_id = fcp.concurrent_program_id
and fcp.concurrent_program_id = fcpt.concurrent_program_id
and fcr.program_application_id = fcp.application_id
and fcp.application_id = fcpt.application_id
and fcr.requested_by = fu.user_id
and fcpt.language = ‘US’
and fcr.actual_start_date like sysdate
— and fcr.phase_code = ‘C’
— and hold_flag = ‘Y’
— and fcr.status_code = ‘C’
GROUP BY
request_id,
parent_request_id,
fcpt.user_concurrent_program_name,
fcr.requested_start_date,
fu.User_Name,
fcr.argument_text,
fcr.actual_completion_date,
fcr.actual_start_date,
fcr.phase_code,
fcr.status_code,
fcr.resubmit_interval,
fcr.completion_text,
fcr.resubmit_interval,
fcr.resubmit_interval_unit_code,
fcr.description
Order by 1 desc;

In Oracle Apps Interfaces are generally tables, which act as a medium to transfer the data from one module to another module or to transfer the data from legacy system into Oracle Applications. There are 352 tables provided by the Oracle Package. Each module has its own Interface Tables.
A typical path to transfer the data from Legacy System to Oracle Apps:

What is Interfacing?

It is the process of converting the records from one format to another format. The main components of this interfacing are
• Transfer Program
• Interface Table and
• Import Program
A] Transfer Program:
If the source modules data are implemented in Oracle Applications then the Transfer Programs are integrated with the Package. If the source modules are implemented in external system (i.e. other than Oracle Applications) then we have to develop our own Transfer Programs. Generally these Transfer Programs are developed using PL/SQL, JAVA or SQL Loader.

What they do?

  • It maps the columns of source table with the columns of Interface Tables.
  • It performs Row Level and Column Level validations.
  • It transfers the data from Source to the Interface Table.

B] Interface Tables:
The Interface tables basically have 4 types of columns.

  1. Mandatory Columns.
  2. Conditionally Required Columns.
  3. Optional Columns.
  4. Internal Processing Columns.

Mandatory Columns:
These are the main columns which are required in the destination tables (i.e. Oracle Application Module Tables). With the help of mandatory columns only the Import Program will converts the records from source to destination.
Conditionally Required Columns:
The values for these columns are based on the values of Mandatory columns. For Example: If you are converting foreign currency transactions to INR then it as compulsory to provide conditionally required columns like Currency conversion rate, Conversion Time and Conversion Date.
Optional Columns:
These are used when a client wanted to transfer some additional information from source to destination. These are based on client’s requirement.
Internal Processing Columns:
Status and Error Message columns are called Internal Processing Columns. These are specific only to Interface Table. These columns are going to be used by the Import Program to update the status and error message, if the record fails its validation while importing from Interface Table to the Destination Table.
C] Import Program:
For all Interface Tables, Oracle Application Package is going to provide Import Programs. These are generally registered with destination modules. These Import Programs are designed using PL/SQL, JAVA, C, C++, etc.
What they do?

  • It maps the columns of the Interface Table with one or more columns in the destination table.
  • It performs row level and column level validation.
  • It imports the data from Interface Table to the Destination tables, if the records validated successfully.
  • It deletes all the successfully validated records from Interface Table.
  • If the record fails its validation then the Import Program will update the status and error message columns of Interface Table.

Interface Vs. Application Program Interface (API):

Interfaces are used to transfer the data from legacy system to Oracle Application system where as API is used to convert the data from one form to another form with in the Oracle Application Module.

This interface helps us to import vendor invoices into Oracle applications from external systems into Oracle Applications.

Interface tables: 

1] AP_INVOICES_INTERFACE
This is the open interface table for importing AP Invoices from external sources and stores header information about invoices. Invoice data comes from sources including:

  • EDI invoices from suppliers that are loaded through Oracle e-Commerce Gateway
  • Supplier invoices that are transferred through the Oracle XML Gateway
  • Invoices that are loaded using Oracle SQL*Loader
  • Lease invoices from Oracle Property Manager
  • Lease payments from Oracle Assets
  • Credit card transaction data that are loaded using the Credit Card Invoice Interface Summary
  • Expense Report invoices from Oracle Internet Expenses
  • Payment Requests from Receivables
  • Invoices that are entered through the Invoice Gateway.

There is one row for each invoice you import. Oracle Payables application uses this information to create invoice header information when Payables Open Interface program is submitted.
Data in the AP_INVOICES_INTERFACE table used in conjunction with AP_INVOICE_LINES_INTERFACE table to create Payables Invoice, Invoice lines, Distributions and Schedule payments. Data in this table can be viewed and edited using ‘Open Interface Invoices’ window. The Payables Open Interface program validates each record in this interface table selected for import, and if the record contains valid data then the program creates a Payables Invoice.

Important columns: 
INVOICE_ID (Required) : Unique identifier for this invoice within this batch. Same value should be populated in invoice’s lines in the AP_INVOICE_LINES_INTERFACE table to identify the data as belonging to the same invoice.
INVOICE_NUM (Required) :  Enter the invoice number that needs to be assigned to the invoice created in Payables from this record.
INVOICE_TYPE_LOOKUP_CODE (Optional) : Type of invoice: Credit or Standard.
INVOICE DATE (Optional) : Date of the invoice. If you do not enter a value, the system uses the date you submit Payables Open Interface Import as the invoice date.
PO_NUMBER (Optional)  : Purchase order number from PO_HEADERS.SEGMENT1. This column needs to be populated if invoice to be matched with an purchase order.
VENDOR_ID & VENDOR_SITE_ID (Required) : VENDOR_ID is unique identifier for a supplier and VENDOR_SITE_ID is Internal supplier site identifier. Supplier of the invoice to be derived by value in one of the following columns in this table: VENDOR_ID, VENDOR_NUM, VENDOR_NAME, VENDOR_SITE_ID or PO_NUMBER.
VENDOR_NUM & VENDOR_NAME (Optional) : Supplier number and name. You must identify the supplier by entering a value for one of the following columns in this table: VENDOR_ID, VENDOR_NUM, VENDOR_SITE_ID, VENDOR_SITE CODE, or PO_NUMBER.
INVOICE_AMOUNT (Required) : Amount of the invoice.
INVOICE_CURRENCY_CODE (Optional)  : Currency code for the invoice. If you want to create foreign currency invoices, enter a currency code that is different from your functional currency.
EXCHANGE_RATE (Optional) :  This column is required if you enter a foreign currency code in the INVOICE_CURRENCY_CODE column and you enter User as the EXCHANGE_RATE_TYPE.
TERMS_ID (Optional) : Internal identifier for the payment terms.
DESCRIPTION (Optional) : Enter the description that you want to assign to the invoice created from this record.
SOURCE (Required) : Source of the invoice data. If you import EDI invoices from the Oracle EDI Gateway, the source is EDI Gateway. For invoices you import using SQL*Loader, use a QuickCode with the type Source that you have defined in the QuickCodes window in Payables.
2] AP_INVOICE_LINES_INTERFACE
This is the lines interface table for the AP Invoice Open Interface and it is used in conjunction with AP_INVOICE_INTERFACE table. AP_INVOICE_LINES_INTERFACE stores information used to create one or more invoice distributions. Note that one row in this table may create, during the import process, more than one invoice distribution.
Important columns: 
INVOICE_ID (Required) :Enter the INVOICE_ID of the corresponding invoice in the AP_INVOICES_INTERFACE table. 
INVOICE_LINE_ID : This value is not required. You can enter a unique number for each invoice line of an invoice.
LINE_NUMBER (Optional) : You can enter a unique number to identify the line.
LINE_TYPE_LOOKUP_CODE (Required) : Enter the lookup code for the type of invoice distribution that you want Payables Open Interface Import to create from this record. The code you enter must be ITEM, TAX, MISCELLANEOUS, or FREIGHT. These lookup codes are stored in the AP_LOOKUP_CODES table.
AMOUNT (Required) : The invoice distribution amount. If you are matching to a purchase order, the AMOUNT = QUANTITY_INVOICED x UNIT PRICE. If the total amount of all the invoice distributions does not equal the amount of the invoice that has the same INVOICE_ID, then Payables Open Interface Import will reject the invoice.

Concurrent program:  

Payables Open Interface Import
Parameters:
Source: Choose the source of the invoices from the list of values. Use EDI Gateway, Credit Card, or a Source type QuickCode you defined in the Payables QuickCodes window.
Group: To limit the import to invoices with a particular Group ID, enter the Group ID. The Group must exactly match the GROUP_ID in the Payables Open Interface tables.
Batch Name: Payables groups the invoices created from the invoices you import and creates an invoice batch with the batch name you enter. You can enter a batch name only if you have enabled the Use Batch Control Payables option, and if you have enabled the Use Batch Control Payables option, you must enter a batch name. If you use a batch name and some invoices are rejected during the import process, you can import the corrected invoices into the same batch if you enter the exact batch name during the subsequent import.
Hold Name: If you want to place all invoices on hold at the time of import, enter an Invoice Hold Reason. You can define your own hold reasons in the Invoice Approvals window.
Hold Reason: Payables displays the Invoice Hold Reason Description.
GL Date: If you want to assign a specific GL Date to all invoices, enter a GL Date. If you do not enter a value here, the system will assign a GL Date based on the GL Date Payables option.
Purge: Enter Yes if you want Payables to delete all successfully imported invoice records that match the Source and Group ID of this import. Payables does not delete any invoice data for which it has not yet created invoices. If you want to purge later, you can use the Payables Open Interface Purge Program.
 Steps:
1] Firstly, let’s get a unique number to be used as INVOICE_ID to the invoice to be imported.  This method ensures that each invoice has a unique INVOICE_ID assignment.
 select ap_invoices_interface_s.nextval from dual;
NEXTVAL
————-
132277

 2] Then, create records in the Invoice Open Interface tables through SQL queries.

insert into AP_INVOICES_INTERFACE (
            invoice_id,
            invoice_num,
            vendor_id,
            vendor_site_id,
            invoice_amount,
            INVOICE_CURRENCY_CODE,
            invoice_date,
            DESCRIPTION,
            PAY_GROUP_LOOKUP_CODE,
            source,
            org_id
                )
values (
            132277,
            ‘INV100’,
            ‘7124’,
            ‘11792’,
            1200.00,
            ‘USD’,
            to_date(’01-31-2010′,’mm-dd-yyyy’),
            ‘This Invoice is created for test purpose’,
            ‘WUFS SUPPLIER’,
            ‘Manual Invoice Entry’,
            81
);

insert into AP_INVOICE_LINES_INTERFACE (
            invoice_id,
            line_number,
            line_type_lookup_code,
            amount
            )
values     (
            132277,
            1,
            ‘ITEM’,
            1200.00
);
3] You can go to Payables > Invoices > Entry > Open Interface Invoices to check the details of Invoice and Invoice Lines from the front end. If required you can do any modifications here. Alternatively you can use these forms to put invoice data in AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE tables.
4] Go to the front end and run the concurrent program “Payables Open Interface Import”  to submit a request for Invoice Import.

Output:

output of Payables Open Interface Import

5] The imported invoice becomes available for review in Invoices Workbench.

Interface Invoice through Invoice Bench