Oracle Applications Interview Questions (FAQS)

Q1. What is the order of defaulting of the Receipt Routing on the receipts screen which may be set at various levels?

A: For Inter-Org Shipments (In-Transit Receipts) the Receipt Routing is defaulted as follows: 
1. Item Attribute 
2. if 1 is null, then Shipping Network for the Receiving Organization 
3. if 2 is null, then Receiving Option 

  

Q2. What are the different types of Inter-Organization Transfers?

A: Inter-Organization transfers can be performed as either direct or intransit shipments. 
Direct inter-organization transfers: Inventory is moved directly from a shipping organization to the destination organization. Inter organization transfers using intransit inventory: Usually done when transfer time is significant. Delivery location isn't specified during transfer transaction, You only need to enter subinventory you are shipping from, a shipment number, the freight information and inter-organization transfer charge. Then you need to perform Receipt from the Receiving forms. 

  

Q3. What are the minimum setups required for Items which we use for Internal Sales Order? 

A: The items which we use for Internal Sales Order must be Inventory enabled, internally orderable and stockable, shippable, and Order Management transactable for the source organizations. Under Inventory, you need to select the Inventory Item, Transactable, and Stockable options. Under Order Management, you need to select the Internal Ordered, Internal Orders Enabled, OE Transactable, and Shippable options. 

  

Q4. How do we define the Inter-Organization Shipping Network?

A: Use the Shipping Networks window to define your inter?organization network. You must enable the network between each source (shipping) and destination (receiving) organization. 
-Select Internal Order Required if you want all transfers between these two organizations to use internal orders. 
-Specify whether you ship material directly, or use intransit inventory for shipments between these two organizations. 
-For intransit transfers, you can choose from the following primary receipt routings: Standard receipt, Inspection required, or Direct delivery.

  

Q5. What are the steps to perform Inter-Organization Transfer? 

A: Follow these 3 simple steps: 

1. Setup Shipping Network: This information describes the relationships and accounting information that exists between a from (shipping) organization and a to (distribution) organization. 
Navigation path: 
A. Choose the Inventory Manager responsibility. 
B. Setup/Organizations - Make sure that there is an entry for from/to organization (between the organizations you intend to perform the transfer). When you click on this form, you will get a LOV with orgs. 
-Choose the From Org. 
-Transfer Type can be either Intransit or Direct (Direct would ship directly to Inventory, so it would be a Direct Delivery). 
-FOB can be either Receipt or Shipment, if the transfer type is entered as Intransit. 
If Receipt the source inventory quantities get updated at time of receipt.
If it be Shipping, then the quantities get updated as soon as the shipment is done. 

2. Inventory/Transactions/Interorganization Transfer: When you click on this form, you will get a LOV with orgs. Choose the from org. Specify the to-org, transfer type as intransit, and input a value for shipment-number. 
Click on the transaction lines button. Input the item, the quantity and the subinventories between which you want to do the transfer. (Sometimes there might not be enough quantity in the from-org to do this. For this : Go to: Inventory/Transactions/Miscellaneous Transactions. Specify the Type as Miscellaneous Receipt. Click on transaction lines button and specify item/quantity). 

3. Receive against an Inter-org Transfer: Choose Purchasing Super User responsibility. 
Under Purchasing/Receiving/Receipts - Query up against Shipment Number in the find window. In RCV Transactions block, specify the quantity you want to receive and commit the transaction. 

  

Q6. What are the steps required for receiving against Internal Sales Order? 

A: The process of receiving against Internal Sales Orders involves the following steps: 

1. Create an Internally Orderable Item - To do this you need to create an Item and in the Order Entry attributes, check the Internally Orderable check box. 

2. Setup Shipping Network: This information describes the relationships and accounting information that exists between a from (shipping) organization and a to (distribution) organization. 
Navigation path: 
A. Choose the Inventory Manager responsibility. 
B. Setup/Organizations - Make sure that there is an entry for from/to organization (between the organizations you intend to perform the transfer e.g.. GLO -> SAC). 
When you click on this form, you will get a LOV with orgs. 
-Choose the From Org. 
-Transfer Type can be either Intransit or Direct (Direct would ship directly to Inventory, so it would be a Direct Delivery). 
-FOB can be either Receipt or Shipment, if the transfer type is entered as Intransit. 
If Receipt the source inventory quantities get updated at time of receipt.
If it be Shipping, then the quantities get updated as soon as the shipment is done. 

3. Create an Internal Requisition. 
-Enter the item you created in step 1. 
-Enter the Source and Destination Organization. Source Organization is on the right of the form and Destination to the left. 
-Enter location (e.g.. SACHQ) and Source as Inventory. 
-Save and approve requisition. 

4. Run the Create Internal Orders concurrent program. 

5. Change responsibility to Order Entry Superuser. 

6. Run Order Import concurrent program. 

7. When the process completes, you will see the Order Number in the log file. 

8. If the process errors : "You must enter Tax Code. Tax code attribute is missing" then: 
-Change responsibility to AR Manager (Receivables) 
-Navigate Setup->Transaction->Transaction Types 
-Query up record with Name = "Invoice Hdwe/svcs" 
-Uncheck the Tax Calculation check box 
-Save 

9. Run the Demand Interface concurrent program. 

10. Run the Manufacturing Release concurrent program. 

11. Navigate to: 
-Orders, Returns -> Orders, Returns -> Do a Find on the Order Number 
-Click on the View button 
-Click on Cycle Status 
-Your Order should now be Pick Release Eligible 

12. Navigate to Shipping -> Pick Release -> Release Sales Order 
-Enter a Batch Name and your Order Number 
-Save 
-Note the Batch_ID by doing a Help->Tools->Examine. 

13. Run the Pick Release concurrent program. Use Batch Name/Order Number as parameter. This can be run from command line as: 
./OESREL apps_appdemo/fnd@comp16p 0 Y <Batch ID> (from step L) 

Perform Step K. Your Order should now be Ship Confirm Eligible 

14. Navigate to Shipping->Confirm Shipments->Pick Slip 
-Do a Find on the Order Number 
-Click on Open 
-Click on details 
-Check if all values of quantity to be shipped are correct 
-Save 

15. Change Responsibility to Purchasing Super User. 
Navigate to the Enter Receipts form and query on the Requisition Number. 
You can now receive against the Internal Order. 
To override the destination type at receipt time you need to set the profile option RCV: Allow routing override = Yes. 

  

Q7. How are Lot and Serial Numbers handled in Inter-Organization Transfers? 

A: When you perform an inter?organization transfer, the source and destination organization may have different lot/serial controls. Purchasing handles this situation as follows: 
1. When the source organization uses controls and the destination organization does not, the control numbers are recorded as being issued from the source organization. Lot/serial transactions are recorded for the destination organization. 
2. When the source organization does not use controls and the destination organization does, the transaction is processed normally. 
3. When both source and destination organizations use controls, the control numbers are recorded as being issued from the source organization. These control numbers are tracked to insure that the same control numbers that were shipped are the ones 
that are received. When items are returned from inventory to receiving or to the supplier, only the control numbers originally recorded for the delivery transaction can be used. 

  

Q8. What's the cause of the error RVTSH-150 and what's the solution for it?

A: Error RVTSH-150 is because the following select is failing, returning 0 rows:
SQL> select ms.unit_of_measure 
from mtl_supply ms 
where supply_type_code = 'REQ' 
and supply_source_id = :req_line_id; 

The error is because the Req. Supply missing. This is mostly a data problem caused at customer site. Look into why the records are missing. May be the data has been manually changed or some cancellations for the req. shipment has taken place. 


  

Q9. What are the main tables involved in Inter-Organization Transfer? 

A: A check is carried out to see if the transaction date is in an open period as specified in the profile option (INV: Transaction Date Validation). The column is acct_period, the table is ORG_ACCT_PERIODS. 
The organizations setting, cost information, etc, are derived from: 
ORG_ORGANIZATION_DEFINITIONS, MTL_PARAMETERS, MFG_LOOKUPS, MTL_INTERORG_PARAMETERS 
[HR_ORGANIZATION_INFORMATION - for rel 11I]. 
The transaction information is derived from MTL_TRX_TYPES_VIEW for inter-org transactions where transaction_source_type_id=13. 
The item information is derived from MTL_SYSTEM_ITEMS [MTL_SYSTEM_ITEMS_B - for rel 11I]. 
A check is carried out to verify the available item quantity on MTL_DEMAND and 
MTL_ONHAND_QUANTITIES [MTL_RESERVATIONS included in rel 11I]. 
MTL_SUBINVENTORIES_TRK_VAL_V keeps track of the values of the subinventories. 
MTL_ITEM_LOCATIONS is searched for the locators specified (if used). 
GL_CODE_COMBINATIONS is searched for a valid locator combination (if used). 
The cost of the item is gotten from CST_CG_ITEM_COSTS_VIEW. 
The transaction is inserted into MTL_MATERIAL_TRANSACTIONS_TEMP table. 
If the item is under lot control, lot information is deleted from MTL_TRANSACTION_LOTS_TEMP, likewise the serial numbers information if the item is serialized is deleted from MTL_SERIAL_NUMBERS_TEMP, MTL_SERIAL_NUMBERS. 
The new lot information is inserted into MTL_TRANSACTION_LOTS_TEMP. 

  

Q10. How can we correct delivered lines in an Internal Requisition?

A: The system allows corrections to internal requisition, but only the receiving lines and not the delivered lines. Once the internal requisition is delivered, correction is not allowed.

FAQ Details

Q1. What is the Receiving Transaction Processor, how do I launch it and what is the meaning of the various modes? 

A: The Receiving Transaction Processor processes pending or unprocessed receiving transactions. How the Receiving Transaction Processor handles these transactions depends on the processing mode, which is a profile option (RCV: Processing Mode) that you can set at the site, application, responsibility, and user levels. The debug log file can be generated if profile RCV: Debug Mode is set to Yes. However the log file will be generated only if the Processing Mode is Immediate or Batch. 

In On-line processing mode, Purchasing calls the Receiving Transaction Processor when you save your work. 

In Immediate processing mode, when you save your work, the receiving forms call the Receiving Transaction Processor for the group of transactions you have entered since you last saved your work. Note that this is a specific group of transactions. Transactions belonging to other groups (for example, those entered by another user in Batch processing mode) are not included. 

In Batch processing mode, the receiving forms insert transaction information into the receiving interface tables. These transactions remain in the interface table until you run the Receiving Transaction Processor. The receiving forms take into account all pending transactions, but Purchasing does not update the transaction history, source documents, and supply information until the transactions are processed. You can set Standard Report Submission parameters to run the Receiving Transaction Processor at specified intervals so that your pending transactions are processed as often as required. 

The Receiving Transaction Processor performs the following functions: 
. validates Advance Shipment Notice (ASN) and Advance Shipment and Billing and Notice (ASBN) information in the receiving open interface 
. derives and defaults values into the receiving interface tables (For example, if a particular value or field is not received, the receiving open interface tries to derive the value using defaulting and derivation rules.) 
. creates receipt headers for intransit shipments 
. creates receipt lines for all receipts 
. maintains transaction history information 
. maintains lot and serial transaction history 
. accrues uninvoiced receipt liabilities 
. maintains the following purchase order quantities: quantity received, quantity delivered, quantity accepted, and quantity rejected 
. closes purchase orders for receiving 
. maintains the following requisition quantities: quantity received, quantity delivered 
. maintains supply information 
. maintains inventory information (for Inventory destination type) 
. maintains outside processing information (for Shop Floor destination type) 
To run the Receiving Transaction Processor : 
1. Navigate to the Submit Requests window. 
2. Select Requests in the first field. 
3. Select Receiving Transaction Processor in the Name field. 
4. Choose Submit to begin the process. 

  

Q2. Which tables are populated when we create a Standard receipt against a PO before the Receiving Transaction Processor is invoked?

A: Records are inserted into rcv_transactions_interface with processing_status_code and transaction_status_code as 'PENDING' and transaction_type of 'RECEIVE'. Records are also inserted into rcv_shipment_headers which creates the shipment header. 

  

Q3. Why can't I find the receipt in the Receiving Transaction Summary even after completing the Receipt (Receiving -> Receipts)? 

A: a) From Transaction Status Summary query for the Receipt Number or PO Number and check to see if the transactions have been stuck in the interface (Status=Pending). 
b) If using RCV: Processing Mode = Batch, make sure to run the Receiving Transaction Processor. 
c) If using RCV: Processing Mode = Batch or Immediate...go to Concurrent Request screen...check to see if the concurrent 
process = Receiving Transaction Processor has completed. 
d)If the RCV: Processing Mode is Online or Immediate and records are fetched in the Transaction Status Summary form in 
PENDING or ERROR status, these can be deleted from the form and the receiving transaction done again. 

  

Q4. How many processes are needed for the Receiving Transaction Manager? 

A: In most cases, there are 3 processes. If you are in multi-org environment, then you need at least one for each operating unit. 

  

Q5. What is Receiving Transaction Manager RCVOLTM? 

A:RCVOLTM is the executable that runs the Online Receiving Transactions. The Executable is stored in the server ($PO_/bin). 
You can check the versions by the following command: 
cd $PO_/bin 
strings -a RCVOLTM | grep -i '$Header: rv' 

  

Q6. What happens if Receiving Transaction Manager fails using on-line mode? 

A: If the RCVOLTM fails, you will get the error message on the screen. There should be nothing stuck in the RCV_TRANACTIONS_INTERFACE.
However, the header information inserted into the RCV_SHIPMENT_HEADERS table will not rollback or be deleted. This process is followed to ensure that there is no break to the sequence of receipt numbers that have been generated when a header transaction was inserted. 

Potential workaround for failed receipts: Where there are headers without shipment lines, due to RCVOLTM failure, users can query the receipt number in the Enter Receipts form, and perform an 'Add to' receipt, to re-process the failed lines. 


  

Q7. Why do we get TIMEOUT error while Receiving in On-line mode? 

A: In on-line mode we launch a concurrent program (RCVOLTM) and wait for its completion before the control returns to the user. The time allotted is 60 seconds (hard coded) and if the program does not complete in 60 seconds, AOL raises "Timeout" error. 
($PO_/resource/RCVCOTRX.pld). This occurs mainly as the process cannot complete within 60secs due to huge processing size of the receiving transaction or heavy load on the CPU. 

  

Q8. What are the typical causes of RCVOLTM failure? 

A: a) Receiving transaction managers may not be up and running. 
Use the Administer Concurrent Manager form to check if Receiving Transaction Manager is Active and make sure the Actual and Target process > 0. 
b) A SQL error has occurred due to insufficient tablespace, etc. Please check the Alert log. 
c) Make sure Inventory Manager is running if receiving against inventory items. 

  

Q9. How does RCVOLTM work in a Multi-org environment? 

A: Since release 11 and 11i, there is only one DATA GROUP = apps schema and one installation for multiple operating units. We do not need to define multiple Receiving Managers for different operating unit. One Receiving Manager is good enough. 

  

Q10. What is the cause of the following error? 

A: "APP-FND-00204 Concurrent Manager encountered an error while running the spawned concurrent program Receiving Transaction Manager - RCVOLTM for your concurrent request 1180 TM-SVC LOCK HANDLE FAILED." 
This would mean that the Receiving Transaction Manager is inactive or terminated. 
This is the manager used for processing receiving transactions in the Online mode. 
Ask your system administrator to activate the Receiving Transaction Manager.
If that does not help you will have to take this up as with the AOL team. 

  

Q11. What are the differences between Batch, Immediate and on-line mode? 

A: Three choices on Profile RCV: Processing Mode: Immediate, Batch, On-line 

Immediate: The form will start running Receiving Transaction Processor as a background process. The system will not hold the screen and the user can do something else. 
Uses Receiving Transaction Processor (RVCTP). 

On-line: The user will not be able to perform any other application activities until the process completes. Uses Receiving Transaction Manager (RCVOLTM).

Batch: Control is returned to the User immediately so other application activities may be performed. The transaction will be processed by running Concurrent Program Receiving Transaction Processor (RVCTP). Typically, Customers will run this program periodically based on their processing and system requirements. 

  

Q12. How should I get a log file and database trace files for the Receiving Transaction Processor? 

A: To get the database trace file : 
Set the profile option PO: Enable Sql Trace for Receiving Processor = Yes. 

To get the log file : 
Set the profile option RCV: Debug Mode to Yes. 
Set the profile option RCV: Processing Mode to either Immediate or Batch. 

Debug messages will not be printed to the concurrent log file if the mode is On-line. 


  

Q13. Why is the log file not built even after setting the profile option RCV: Debug Mode = Yes? 

A: The profile option RCV: Debug Mode works only if the profile option RCV: Processing Mode = Immediate or Batch. Debug messages will not be printed to the concurrent log file if the mode is On-line. 

  

Q14. What's the cause of the error RVTSH-150 and what's the solution for it? 

A: Error RVTSH-150 is because the following select is failing, returning 0 rows:
SQL> select ms.unit_of_measure 
from mtl_supply ms 
where supply_type_code = 'REQ' 
and supply_source_id = :req_line_id; 

The error is because the Req. Supply missing. This is mostly a data problem caused at the customer's site. Look into why the records are missing. May be the data has been manually changed or some of the req. shipment has been cancelled.

FAQ Details

Q1. What pre-requisites are required for a vendor sourced receipt?

A: PO Receipt (vendor sourced receipt) can be performed for Shipments that are currently Approved even though the Purchase Order may not be currently Approved. Only Approved Shipments which have the ship-to-organization same as the active Inventory Organization are eligible to be received. 
This means that a PO supply exists in mtl_supply. Check the values of the following columns in PO_LINE_LOCATIONS: 
APPROVED_FLAG = 'Y' AND 
CANCEL_FLAG = 'N' AND 
CLOSED_CODE != 'FINALLY CLOSED' 

  

Q2. Where are the records inserted when a standard receipt is created against a PO before the Receiving Transaction Processor is called? 

A: Records are inserted into rcv_transactions_interface with processing_status_code and transaction_status_code as 'PENDING'. Records are also inserted into rcv_shipment_headers which creates the shipment header.

  

Q3. How does Receipt Close Point work? 

A: Define Purchase Options -> Control Options -> Receipt Close Point. 
Three choices: 
Accepted - Oracle Purchasing closes the shipment for receiving when you record the shipment as being fully accepted. 
Delivered - Oracle Purchasing closes the shipment for receiving when you record the shipment as being fully delivered. 
Received - Oracle Purchasing closes the shipment for receiving when you record the shipment as being fully received. 
Oracle Purchasing displays this option as the default. 
You also need to set the receipt close tolerance percentage in the Default Options Region. 
Choose one of the above values for the receipt close point. 

  

Q4. Why isn't my PO found when I query for it on the Receipt form?

A: Please check the following: 
a) Query the PO from the Purchase Order form and note the Organization on the Shipment. Ensure you are using the same Organization on the Receipt form. 
b) On the Receipt form, select the checkbox for 'Include closed POs' then requery the PO. 

  

Q5. Why can't I find the receipt in the Receiving Transaction Summary even after completing the Receipt (Receiving -> Receipts)? 

A: a) From Transaction Status Summary query for the Receipt Number or PO Number and check to see if the transactions have been stuck in the interface (Status=Pending). 
b) If using RCV: Processing Mode = Batch, make sure to run the Receiving Transaction Processor. 
c) If using RCV: Processing Mode = Batch or Immediate...go to Concurrent Request screen...check to see if the concurrent process = Receiving Transaction Processor is finished. 

  

Q6. Why can't I perform Direct Receipt if using Standard Receipt Routing or Inspection Required? 

A: To override the destination type at receipt time you need to set the profile option RCV: Allow routing override = Yes. 

  

Q7. What is the order of defaulting of the Receipt Routing on the receipts screen which may be set at various levels? 

A: The Receipt Routing on the receipts screen is defaulted as follows: 
1. Purchase Order Shipment 
2. if 1 is null, then Item Attribute 
3. if 2 is null, then Vendor Attribute 
4. if 3 is null, then Receiving Option 
But for Inter-Org Shipments (In-Transit Receipts) the Receipt Routing is defaulted as follows: 
1. Item Attribute 
2. if 1 is null, then Shipping Network for the Receiving Organization 
3. if 2 is null, then Receiving Option 

  

Q8. Where is the receipt history saved when I do various receiving transactions? 

A: The history records are saved in the rcv_transactions table and organized by transaction_type. 
In case item is under lot or serial control, records are also inserted into rcv_lot_transactions and rcv_serial_transactions. 

  

Q9. What are the various transactions types? 

A: Receive - Receive the items into Receiving Dock. 
Deliver - Deliver the items into expense or inventory destination. 
Return to Vendor - Return the received items directly to vendors. 
Return to Receiving - Return the delivered items to Receiving Dock or Inspection. 
Accept - Accept items following an inspection. 
Reject - Reject items following an inspection. 
Transfer - Transfer items between locations. 
Correct - Enter a positive or negative adjustment to a receiving or delivery transaction. 
Match - Match unordered receipts to purchase orders. 
Unordered - Receive items without purchase orders. 

  

Q10. Where does the mandatory Location field on the receipts form gets populated from when performing "Direct Receipt"?

A: The location field on the receipts form gets populated from the Purchase Order distributions. 
Here, there is a field called Deliver_To. This field populates the Location field in the receipts form. 

  

Q11. When is the Express button enabled in the Receiving form RCVRCERC? 

A: The Express function is available in the Receipts window if you have specified or inferred a source in the Find Expected Receipts window. (The source would be inferred if you entered, for example, a purchase order number). In the Receiving Transactions window, the express function is available for deliveries regardless of your search criteria in the Find Receiving Transactions window. 
Performing any manual action in a line disables the Express button, and it is not enabled until you have again selected the find button. 
You also need to check the option "Allow Express Transactions" in the Receiving Options Form as a prerequisite. 
Navigation - Setup --> Organizations --> Receiving Options. 

  

Q12. When will the Inspect button on the Receiving Transactions form get highlighted? 

A: The Inspect button will be highlighted when: 
1) 'RCV: Allow routing override' is set to YES. 
2) 'RCV: Allow routing override' set to NO but the Routing is set to Inspection Required. 

  

Q13. How does Receiving interface with Inventory? 

A: Once the PO is received, it creates the inventory interface record i.e. inserts a record into mtl_material_transactions_temp and calls the inventory function inltpu() which completes the delivery of the item into Inventory and also updates the on hand quantities. ($PO_/src/rvtp/rvtii.lpc) 

  

Q14. How does Receiving interface with WIP for OSP items? 

A: The function rvtooperation() in rvtoo.lpc calls the following WIP API which takes care of the interface with WIP for OSP items. WIP_Transaction_PVT.Process_OSP_Transaction (
p_OSP_rec => osp_rec,
p_validation_level => WIP_Transaction_PVT.NONE, 
p_return_status => :ret_status:ret_status_ind, 
p_msg_count => msg_count, 
p_msg_data => msg_data); 

  

Q15. Which tables are populated for accrual accounting to happen?

A: The following tables must be populated for accrual accounting to happen: 
GL_INTERFACE 
RCV_RECEIVING_SUB_LEDGER 
RCV_SUB_LEDGER_DETAILS (for match-to-receipt) 
Files: $PO_/src/accrual/rvcac.opc 
$PO_/src/accrual/rvacj.lpc

FAQ Details

Q1. What is a Debit Memo Invoice?

A: Negative amount invoice which is created and sent to a supplier to notify the Supplier of a credit you are recording.

  

Q2. When should a Debit Memo be created?

A: To correct over billing errors, we create a Debit Memo by doing a Return To Supplier transaction for the extra quantity that got invoiced. 

  

Q3. Is Debit Memo functionality supported in 10.7 and 11.0? 

A: No, Debit Memo functionality is supported only in Release 11i. 

  

Q4. How does Create Debit Memo from RTS Functionality Work?

A: Steps to Create a Debit Memo via RTS: 
1. Create a PO with supplier and supplier site. 
2. Receive the goods using Enter Receipts Form. 
3. Create an Invoice. If Pay on Receipt is used to create then Invoice then set �Pay on� as Receipt and �Invoice Summary Level� as Receipt in Supplier sites window under purchasing tab. 
4. Do a Return To Supplier (RTS) transaction for some of the goods using Returns form. 
5. Make sure the check Box 'Create Debit Memo' is checked in the Return line while doing the RTS transaction. 
6. This will automatically create a Debit Memo invoice in AP. 

Depending on how the RCV: Processing Mode Profile option, Receiving Transaction Processor will be kicked off as soon as Receipt/Return transaction is saved. 
If profile option RCV: Processing Mode = Batch, then user has to go and manually launch Receiving Transaction Processor concurrent request. 
If profile option RCV: Processing Mode = Immediate, then Receiving Transaction Processor concurrent request will be launched and runs in the background. In this case control comes back to user and he can do his operations. 
If profile option RCV: Processing Mode = Online, then Receiving Transaction Processor concurrent request will be launched. In this case control will not come back to user until processor completes processing.

  

Q5. What setup is required to create a Debit Memo?

A: Navigate: Supply Base -> Suppliers -> Query on supplier -> Sites -> Query on site -> Purchasing tab -> Check the box for Create Debit Memo from RTS Transaction. Make sure the check Box 'Create Debit Memo' is checked in the Return line while doing the RTS Transaction. 

  

Q6. Under what Conditions a Debit Memo can be created?

A: Automatic Debit Memo will be created only when billed quantity of Purchase Order is greater than or equal to Returned Quantity. Return To Supplier reduces the PO billed quantity by the returned quantity but in any case PO billed quantity will never go below zero. 

  

Q7. What to do if Debit Memo is not created after doing an RTS transaction? 

A: Set the profile options �RCV: Processing Mode� to Immediate and �RCV: Debug Mode� to Yes. Receiving Transaction Processor log file (with debug messages of Receiving and AP code) and database trace file for RTS transaction will help in finding the cause of the problem. 

  

Q8. Is Debit Memo not getting created when Inspection is involved?

A: This functionality has been incorporated in Procurement Family Pack �H�, and is also available via interim patch 2151718 (plus pre-reqs shown below). These are the list of patches to be applied for Debit Memo functionality to work if Inspection is involved. 

If applying Procurement If applying PO Family Pack H: - OR - interim patch 2151718:
----------------------- ----------------------
11i.PRC_PF.H 1763128
1842268 (AP patch) 1842268 (AP patch)
2045028 
2144921 
2179807 
2151718

If Inspection is not involved, then no need to apply the above mentioned patches.

FAQ Details

Q1. What is Pay On Receipt?

A: Pay on Receipt (also known as ERS (Evaluated Receipt Settlement) or Self-Billing) is an Oracle Purchasing's concurrent program, which automatically creates invoices in Oracle Payables and matches them with PO's automatically for the received amount. The short name for the program is POXPOIV.

  

Q2. What is the minimum set-up required? 

A: 1. In Oracle Purchasing responsibility, navigate to Supply base ->Suppliers. Query the supplier to be used in the PO and Query the site to be used in PO. In the General Tab, check the checkboxes for PAY SITE and PURCHASING. In the Purchasing tab, the Pay on field should have a value of' Receipt'. The invoice summary level should also have the value of 'Receipt'. 
2. Apart from the above set-up in R11i, we need to enter the value of ?Receipt? against the Pay on field in the Terms window of the PO. 

  

Q3. What is the impact of payables options on ERS? 

A: From Payables options, under GL date basis there are four options. The accounting date will be based on the option selected here. Make sure that the date is in the open period.

  

Q4. How can we identify the invoices created by Pay on receipt? 

A: The invoices created by ERS will have ERS prefix generally. To identify the invoice created for a particular receipt we can query with the combination of ERS and receipt number in the invoice number field. In R11i, the profile option PO: ERS invoice number prefix can be set as needed which can be used to identify the invoices. 

  

Q5. What are the parameters passed? 

A: For R107 and R11, the parameters passed are Parameter name value:
1. Transaction Source - ERS 
2. Commit interval- default 1 
3. Organization- Receiving org 
4. Receipt Number- optional 
If a receipt number is not specified all the receipts for that organization, which are eligible for Pay on Receipt, are picked. For R11i, the organization parameter does not exist instead a new parameter called Aging period exists. 

  

Q6. What is the significance of Ageing Period (R11i)? 

A: The parameter Aging period determines the transactions on the receipt that can be considered for the invoice creation. For ex if aging period is given as 1, then all the transactions that have a transaction date less than or equal to the (sysdate-1) are considered for invoice creation. The aging period can be set thru the profile option PO: ERS Aging period. 

  

Q7. How can we debug what went wrong? 

A: We can refer to the log file and check for error messages in po_interface_errors. 
There could be many errors. Listed below are some common errors and possible resolutions.
1) Error Occurred in routine: create_invoice_header - Location: 110. Please refer note 1071391.6.
2) Pay on receipt Autoinvoice does not create any invoice. Note 1047839.6 might be useful. Please ensure the setup is complete in payables and Purchasing modules.
3) You have a supplier who has a separate site for purchasing and Payables. When running the ERS (Evaluated Receipt Settlement) it is selecting the purchasing site and therefore does not create the invoice and gets a message that the POXPOIV: 'pay site is invalid'. 
4) Purchasing Pay on Receipt Autoinvoice shows multiple occurrences of same receipt number in multiorg environment. See Note 95384.1 for the solution.
5) Pay On Receipt AutoInvoice errors: po_inv_cr_invalid_gl_period. Please refer to note 179693.1 for resolution.