Posted on June 25th, 2007 by Sanjit Anand |
Print This Post
|
Email This Post
| Have you tried OracleappsHub in ipad/iphone/smart Phone? Don't wait. try it today |
This is in continuation to API’s availability,Here are the API’s availability in AP.
Credit Card Transaction Processing
- Manual Credit Card Entry: A form is available for entry through the Oracle Payables application.
- Credit Card Transaction Interface Table: This process loads transaction data from the credit card issuer (American Express, Diner's Club, MasterCard and Visa) into Oracles AP module. Oracle Payable then uses this data to confirm transactions with employees. Once the transactions have been approved the credit card transaction lines are imported into Payables Open Interface using the Credit Card Invoice Interface Summary program. The credit card transactions are then available for final import to Oracle Payables where the transactions become invoices.
Creating Invoices
In Oracle Payables four methods are available for entering an invoice into the system.
- Manual Invoice Entry: Two methods for manual invoice entry exist. Using Oracle Payables system Invoice Workbench which includes the Invoice Batches window and Distribution window users can enter complex invoices, and invoices requiring online validation. In addition this functionality is useful in processing invoices that require special attention such as immediate payment.
- The second method of manual invoice entry, Invoice Gateway, is used when entering high volumes of invoices. Generally these invoices do not require online validation or defaulting of accounting information. After entering invoices using the gateway, the invoice import must be run, at that time validation and defaulting is performed. This method of entry can be used in lieu of invoice interfaces. Although, using the gateway can accomplish similar results to that found with an interface process, manual entry is no substitute.
- Automatic Invoice Creation: Oracle Payables provides functionality to produce periodically recurring invoices. This functionality may be used to substitute manual invoice entry or the payables open interface. In the case of recurring invoices that would normally come from an external system choosing to setup a recurring invoice formula may be an alternative.
- Using Payables Open Interface: Choose this method for processing large volumes of invoices that originate in external system. Additionally, this process is useful in handling employee expense reports generated through self-service applications, expense reports entered by the Payables Department, invoices for employee credit card expenses, Oracle Projects billing and time and expenses, and EDI invoices transferred from the Oracle EDI gateway.
Purchase Order Matching
Oracle Payables can be implemented without Oracle Purchasing, to allow this several purchasing tables are installed initially which must be populated using custom interfaces. Only two-way matching is available when data is loaded using the interface method. Two-way approval verifies that purchase order and invoice information match within your tolerances as follows: Quantity billed on the purchase order shipment is less than or equal to Quantity ordered on the purchase order shipment. Invoice price on the purchase order shipment is less than or equal to Purchase order price on the purchase order shipment.
Receipts can only be matched in an install that also includes Oracle Purchasing.
The only method for interfacing data into the purchasing tables described in this section is through a customized interface from an external source. Note: Interfacing this information is not supported by Oracle.
- Loading PO_HEADERS: Each record in this table represents a purchase order, which is an order for goods or services from a single supplier. Each purchase order may have multiple lines (PO_LINES). In addition, each blanket purchase order may have multiple blanket releases (PO_RELEASES), which release an amount from the blanket.
- Loading PO_LINES: Each record in this table represents a purchase order line, which identifies the items and unit price for the goods ordered on a purchase order. Each purchase order line may have multiple shipments (PO_LINE_LOCATIONS).
- Loading PO_LINE_LOCATIONS: Each record in this table represents a purchase order line, which identifies the items and unit price for the goods ordered on a purchase order. Each purchase order line may have multiple shipments (PO_LINE_LOCATIONS).
- Loading PO_DISTRIBUTIONS/PO_DISTRIBUTIONS_AP_V: Each record in this table/view represents a purchase order distribution, which identifies the account charged for the items on a purchase order shipment.
- Loading PO_RELEASES: Each record in this table represents a blanket release for a purchase order. A blanket release may create multiple shipments.
- Loading AP_INVOICES/AP_INVOICE_DISTRIBUTIONS: Each purchase order shipment can be matched to multiple invoices(AP_INVOICES), and a single invoice may be matched to multiple purchase order shipments. When you match an invoice to a purchase order shipment, Payables creates an invoice distribution AP_INVOICE_DISTRIBUTIONS) from each purchase order distribution on the shipment. When you match an invoice to a single purchase order distribution, Payables creates a single invoice distribution from the purchase order distribution.
Vendor Interface
Existing and new vendors must be loaded into the Oracle Payables application to support payables activities. Two methods may be used to enter vendors into Oracle Applications, manual entry and direct loading using a customized loader program.
- Manual Vendor Loading: Use the Enter Vendor window. Using this functionality vendor header information as well as vendor site information can be entered.
- Vendor Interface: When interfacing vendors into Oracle Applications two tables must be loaded the PO_VENDORS and PO_VENDOR_SITES_ALL. The vendor table contains all header information and the site table contains information about each the vendor locations such as "ship to" and "bill to". Using this method makes sense when the volume of new vendors is large. Note: Interfacing this information is not supported by Oracle.
- Those who are in 11.5.10 they will find yet another method ie by interface.
You have to Load data into the staging tables first ie.AP_SUPPLIERS_INT - Supplier Information
AP_SUPPLIER_SITES_INT - Supplier Sites Information ,AP_SUP_SITE_CONTACT_INT - supplier Contact details This uses Vendor ID, Vendor Site Code to relate the contacts to specific vendor. Once data get loaded three interface program should be kicked out which is as- Supplier Open Interface Import.
- Supplier Sites Open Interface Import
- Supplier Site Contacts Open Interface Import
Related Posts







September 9th, 2007 at 8:57 am
[...] or Public exist for supplliers, thus it was a tricky to handle supplier. As we have already seen AP availability of AP some time [...]
May 26th, 2008 at 7:47 pm
Hi,
This document is really helpful. I have a query. Is there any AP Invoice line API to update the line DFF programatically from a backend package..
August 25th, 2008 at 10:24 am
Purchase Order Matching:
As noted above: Oracle Payables can be implemented without Oracle Purchasing. We require the ability to enter and lookup AP invoices by PO number, but we don’t own or want to use the Purchasing Module. Do you know of a way to override the PO matching so that it is zero way? Ideally it would be great to use the PO Number field, but have it not validate against a real PO number.
August 25th, 2008 at 11:02 pm
John,
Vendors setups are the most crucial, and also the way Invoice Matching is going to be done, and the matching level. Most of my clients I recommend match invoices against PO’s not receipts, as this means that the AP clerk can process the invoice without having to wait for the receipt to be done. But you also need to make sure that the matching level is correct for the Invoice matching holds to work, ie 3-way or 2-way, as this option is defined in the Purchasing setups.
It is actually the Purchasing that is dependent upon AP.
1) Payables will usually control the Supplier Set up
2) Payables will usually control both the Payables & Purchasing Lookup codes ( Pay Groups, Supplier Types etc.)
3) Finance can define the Supplier Numbering, Payment Terms, Match Options.
Coming to your point
Oracle Payables can be implemented without Oracle Purchasing
>>> You can do it
We require the ability to enter and lookup AP invoices by PO number, but we don’t own or want to use the Purchasing Module. Do you know of a way to override the PO matching so that it is zero way?
>>> as far as Oracle is concern , I donot think so….
The field itself have attached LOV , that means pre-requiste should be completed from PR/PO route. This is not a free text.
What i can figure out is required heavily customaization to pull the details of PO number at Invoice screen and should be bypaased into Invoice Validation as well Hold Program. There are number of items which are hiting if you are thinking to bypass rule what is being currently designed and driving the details from one module(PO) to other(AP).
The best case senario’s, is you can capture the information in any DFF if you are not pulling any accounting information.
This I did with some clients who didnot implement PO.
November 19th, 2008 at 3:08 am
Any API is there to create invoice in payables. If it is present please send the name of the API.
November 19th, 2008 at 3:22 am
Ganesh,
As far as my knowledge there is no public API supported for AP invoice. try to use Payable import which will handle all complexity which cover most of business need expect CN.
Try to explore API’s in irep.oracle.com for any recent one. If you want to utilize the API which is used for invoice workbench , but it will end up with lot of complexity if you are not able to handle.
thanks
sanjit
July 9th, 2009 at 3:06 am
Sanjit anand i will suggest this
On the basis of PO created or whatever setup yu did. with help of concurrent program
Move record in recieving_transaction_interface.
after running Receiving transaction proccessor
It will create recieving transaction. Make proccess automted instead of skipping some workflow steps. This is ong solution. but may be helpfull.
August 24th, 2009 at 5:02 am
Hi,
Can anyone explain the flow of interface.
(EXCEL – TEMPTABLE – INTERFACE – BASE)
September 22nd, 2010 at 10:13 pm
hi,
vamsi
interface is multi processing .
the flat file not only excel file other format like .dat,.txt,.sh etc
the flat file using to generating .ctl file using sql* loader the file trasfer to interface tables .each module having its own interface table .after that the data transfer to oracle base tables.