Receiving Receipts FAQ

What is the Restriction of Decimal Precision for Receiving Forms in 11.5.10 and R12?

Starting in 11.5.10 + Patch 5880504 and 12.0.4 Release Update Pack RUP4 - Patch 6435000 (which Includes Bug fix 6491333) + Patch 6597742, in all Receiving forms transaction quantity restriction to 6 decimal places is removed and users will be able to enter quantity in more than 6 decimal precision (limited now to the maximum size of Receiving forms quantity field, which is 30 characters. After fix on Bug 7626008, Included in INV/RCV Rollup 13 - Patch 7581431, the maximum size is increased to 80 characters).

The above is true for receiving forms only. That means rounding will occur from one module to another when their decimal precision support is different from one another.

For Core Inventory transactions and forms, the following excerpts from Inventory User's Guide (11.5.10), Part No. A83507-09, Pages 3-5, need to be considered:

"...Important: Inventory transactions and on hand balance supports decimal precision to 5 digits after the decimal point. Oracle Work in Process supports decimal precision to 6 digits. Other Oracle Applications support different decimal precision. As a result of the decimal precision mismatch, transactions another Oracle Application passes may be rounded when processed by Inventory. If the transaction quantity is rounded to zero, Inventory does not process the transaction. It is therefore suggested that the base unit of measure for an item is set up such that transaction quantities in the base unit of measure not require greater than 5 digits of decimal precision."

There is an Enhancement Request logged to have Receiving, Inventory and Purchasing, all support the same decimal precision.

ER Bug 6000073: Receiving, Inventory, and PO Should All Support 15 Decimal Precision
Related Receiving Patches About the functionality described above:

For 11.5.10:

* Patch 5880504 - Standalone patch for removing the 6 digits restriction in the receiving forms to maximum of 30 characters
(to be applied only if current RUP is lower than RUP5, as RUP5 - Patch 6449139 also includes this fix)

* INV/RCV Rollup 13 Patch 7581431 - to have the maximum size increased to 80 characters (that is the fix provided in Bug 7626008) - This roll up includes all the fixes mentioned above to remove the 6 decimal restriction in the receiving forms.

For 12.0.x:

* Patch 6597742 - To implement unlimited precision for receiving forms
(to be applied only if current RUP is lower than Update Pack RUP6, as RUP6 - Patch 6728000 also includes this fix)
See: Document  736699.1

How to prevent receiving a Purchase Order PO, when the PO is in Requires Reapproval status? It is available to receive PO even though PO is in Requires Reapproval status.

This is the intended functionality. The functionality has always been to allow Receiving if the PO Shipment Line (po_line_locations_all record) has approved_flag='Y', regardless of the PO Header status. Once the PO Shipment is Approved, it remains Approved (and is eligible to be Received) until the PO Line or PO Shipment Line or PO Distribution is changed such that Reapproval is required for the PO Shipment Line.  Please review
Note 352095.1 (PO With Status of Requires Reapproval or In Process Allows Receipt) if po_line_locations_all.approved_flag does not change to 'R' when the PO Header changes to Requires Reapproval.

How to Troubleshoot APP-FND-00204 error messages with the Receiving Transaction Manager - RCVTPO or RCVOLTM

1. 1. Relink receiving executables.
      cd $PO_TOP/bin
      $ adrelink force=y ranlib=y "PO RCVOLTM"
      $ adrelink force=y ranlib=y "PO RVCTP"
   2. Bounce the Receiving Transaction Manager.
      a. $ps -ef | grep RCVOLTM (to see how many processes are running)
      b. Deactivate Receiving Transaction Manager
      (System Administrator > Concurrent > Manager > Administer)
      c. $ps -ef | grep RCVOLTM (repeat until no processes are running)
      d. Restart Receiving Transaction Manager 
   3.  Verify rvacj.lpc file version is at 115.30 or higher. If not apply Patch 2019427.
      cd $PO_TOP/bin
      strings -a RVCTP|grep -i 'Header: rvacj.lpc' 
   4.  Verify rvtth.lpc file version is at 115.27 or higher. If not apply Patch 2191407.
      cd $PO_TOP/bin
      strings -a RVCTP|grep -i 'Header: rvtth.lpc'
   5. Verify if 11i.INV.G(2004922) or a patch containing this patch has been applied. If so, Patch 2217071 is required and should be applied.
   
   As a workaround, test changing the RCV: Processing Mode profile option to Immediate or Batch and verify if the problem is reproducible.
    

How to receive Complex Purchase Orders PO?

When trying to retrieve the complex PO in the core applications receiving form (Nav > Receipt > Receipts) the error "APP-PO-14094: No records meet your search criteria" is encountered when searching on the Complex PO number.

Answer:
Complex PO's are not received via the core application forms. Complex POs are transacted using the Buyers Work Center and are processed by Receiving Transaction Processor (which runs automatically). The receiving forms are not used for Complex PO receipts.

When you create and approve the complex PO and then Create the Work Confirmation this step populates the complex po receipt data into the receiving interface (rcv_transactions_interface table) and then Buyers Work Center/ iSupplier calls the Receiving Transaction Processor (RVCTP) to process the receipt.

Please check the Transaction Status Summary form (complex PO uses Immediate receiving mode) in the core application to see if the record has failed in the receiving interface (Nav > Receiving > Transaction Status Summary). If the record is not there, then please check to see if it already has been received.

Work Confirmations can be created from iSupplier Portal, iProcurement, and the Professional Buyers Work Center in Purchasing (the most frequent place where this is done). If there are no problems with the the receiving interface tables and no errors, and nothing is in the PO_INTERFACE_ERRORS table, then please create an SR to the iSupplier Portal product.

How do Internal Orders process through Purchasing, Order Entry and Inventory?

The internal order process can start with Inventory, MRP or it can start in the purchasing module. All requisitions imported from Inventory or MRP will be loaded with an AUTHORIZATION_STATUS='APPROVED' unless the requisitions are created by Inventory's Min-Max Planning Report and those can only have an AUTHORIZATION_STATUS='INCOMPLETE' when the profile option called 'INV: Minmax Reorder Approval to Approved' is set to prevent requisitions from being created in an approved status. The Min-Max Planning Report must be run with the Restock parameter set to Yes in order for the requisitions to be imported.

For the requisitions created from the MRP and Inventory modules, the Requisition Import program must be run in order to move records from the requisition interface tables to the historical PO_REQUISITION_HEADERS_ALL, PO_REQUISITION_LINES_ALL and PO_REQ_DISTRIBUTIONS_ALL.

All internal requisitions created in the Purchasing module will directly insert into the historical requisition tables bypassing the interface tables. When each requisition is approved, data will be inserted into the MTL_SUPPLY table. When the items on the requisition are stocked in inventory, the supply data can be viewed from the inventory form called Item Supply/Demand.

Once the Internal Requisition is approved, a user should run Create Internal Sales Orders (from a Purchasing responsibility) to load the internal sales orders interface tables called in Order Entry.

After the Create Internal Sales Orders has completed, a user should run Import Orders from an Order Management or Order Entry responsibility, using the Order Source and Type as it is shown in the Purchasing Options form under the Internal Requisition tab.

At that point, Oracle Workflow will process the internal sales order using the workflow definition listed for the Transaction Type definition in Order Management. When the workflow completes the Shipping Network is checked to see if the Transfer Type between the source and destination organization is In transit or Direct.

If the Transfer Type is In transit, then the Inventory manager will load the Receiving tables so the Internal Requisition can be found in the Receipts form [PO-Receiving: Receipts]. At the same time, the Inventory manager will insert an issue transaction into MTL_TRANSACTIONS_INTERFACE and will process it through to MTL_MATERIAL_TRANSACTIONS and MTL_ONHAND_QUANTITIES. This will decrement the source inventory organization's on-hand quantity. When the receipt is delivered, the receipt will be inserted into the receiving historical table called RCV_TRANSACTIONS. If the internal requisition's Destination Type is Expense, there will be no receipt transactions added to the inventory tables. If the internal requisition's Destination Type is Inventory, the receipt transaction will move through MTL_MATERIAL_TRANSACTIONS_TEMP and insert into MTL_MATERIAL_TRANSACTIONS and MTL_ONHAND_QUANTITIES. This will increment the on-hand quantity in the receiving inventory organization.

If the Transfer Type is Direct, then the Inventory manager will insert an issue transaction into MTL_TRANSACTIONS_INTERFACE and will process it through to MTL_MATERIAL_TRANSACTIONS and MTL_ONHAND_QUANTITIES. This will decrement the source inventory organizations on hand quantity. For Direct Transfer Types with a destination type of Expense, the only transaction that will move through inventory will be the issue transaction; however for destination types of Inventory will additionally have a receipt transaction created, which will automatically move through MTL_MATERIAL_TRANSACTIONS_TEMP and insert into MTL_MATERIAL_TRANSACTIONS and MTL_ONHAND_QUANTITIES without any user actions needed. This will automatically increment the on-hand quantity in the receiving inventory organization.

References:
Oracle Order Entry User's Guide  11i , R12Oracle Inventory User's Guide  11i, R12Oracle Purchasing User's Guide  11i, R12NOTE:106678.1 Purchasing Setup: Min-Max Planning

Are Receiving Open Interface (ROI) Transactions listed on Transaction Status Summary form, and can they be Deleted using Delete (Red X Icon)?

10.7, 11.5.9 and below, 11.5.10 (INV/RCV Rollup Patch RUP12 and lower)
There is no functionality to list ROI Transactions on the Transaction Status Summary form.

11.5.10 (Inventory/Receiving Rollup Patch RUP13 and higher)
Records in rcv_transactions_interface for ROI processing will be listed only if certain fields are populated in rcv_transactions_interface. The Transaction Status Summary form is not designed to derive data in the same way as Receiving Transaction Processor for ROI transaction processing, so it is not possible to list all ROI transactions. The records should be listed on Transaction Status Summary form if:
1. these fields are populated in rcv_transactions_interface:

TRANSACTION_TYPE
TRANSACTION_STATUS_CODE
PROCESSING_MODE_CODE
TO_ORGANIZATION_ID
SOURCE_DOCUMENT_CODE
RECEIPT_SOURCE_CODE

AND

2. these fields have correct values (if the fields are populated):

SHIPMENT_HEADER_ID
SHIPMENT_LINE_ID
REQUISITION_LINE_ID
ITEM_ID
UNIT_OF_MEASURE
OE_ORDER_LINE_ID
OE_ORDER_HEADER_ID
PO_HEADER_ID
PO_LINE_ID
PO_LINE_LOCATION_ID
PO_RELEASE_ID
DELIVER_TO_LOCATION_ID
LOCATION_ID
ROUTING_HEADER_ID
REASON_ID
DELIVER_TO_PERSON_ID
FROM_ORGANIZATION_ID
JOB_ID

Although some file versions may allow Deletion of ROI records using Transaction Status Summary form , this should never have been allowed so the software was later reverted to disallow. Please review Document 726045.1  (What Form Functionality Is Available to Delete Or Reprocess ROI Transactions?) for additional information about deleting and reprocessing ROI records.

Deletion of ROI records from Transaction Status Summary are disallowed if the following file versions are at or above:

11.5.10:
RCVTXVTX.fmb 115.46.11510.6
poxrcv.odf 115.109.11510.29
RCVTXVTX.pld 115.33.11510.5

12.0:
RCVTXVTX.fmb 120.9.12000000.5
poxrcv.odf 120.21.12000000.9
RCVTXVTX.pld 120.7.12000000.3

12.1:
RCVTXVTX.fmb 120.9.12010000.7
poxrcv.odf 120.25.12010000.17
RCVTXVTX.pld 120.8.12010000.3

What Are The Different Descriptive Flexfields (DFF) Used In Receiving And What Is Their Usage?

There are 4 descriptive flexfields in Receiving Process. These are

* RCV_SHIPMENT_HEADERS
* RCV_SHIPMENT_LINES
* Receiving Transactions
* Receiving Transactions Interface

All of these flexfields are updatable.

USAGE:
1. Enter Receipts Form
In Enter Receipts Form, there are two windows - Header and lines.

In header window the flexfield gets defined on the basis of the profile option "ussgl_option_value".
- If the value of the profile is "Y", then a descriptive flexfield called PO_REQEXPRESS_LINES will be enabled.
- If the value of the profile is "N", then a descriptive flexfield called RCV_SHIPMENT_HEADERS will be enabled.

In the lines window, Receiving Transactions flexfield is enabled. The data for this flexfield comes from a view called RCV_ENTER_RECEIPTS_V. This view pulls the attributes from the following:

Table

Document Type
PO_LINE_LOCATIONS Purchase Orders
RCV_SHIPMENT_LINES Internal Reqs and Inter-Org Transfers
RCV_SHIPMENT_LINES ASNs and ASBNs
OE_ORDER_LINES RMAs

When the receipt is then saved, the Header flexfield goes to RCV_SHIPMENT_HEADERS and line flexfield goes to RCV_TRANSACTIONS_INTERFACE which will eventually land up in RCV_TRANSACTIONS after running Receiving Transaction Processor.

2. Receiving Transactions Form
The flexfield on Receiving Transactions form is "Receiving Transactions" and the source of this data is from RCV_TRANSACTIONS from the previous RECEIVE or INSPECTION transaction and the final value goes into RCV_TRANSACTIONS_INTERFACE and eventually to RCV_TRANSACTIONS.

3. Manage Shipments Form
There are two flexfields on Manage Shipments Form - Header and Line. The Header comes from
RCV_SHIPMENT_HEADERS and the line comes from RCV_SHIPMENT_LINES (flexfield and
data).

The attributes in RCV_SHIPMENT_LINES get filled from fields SHIP_LINE_ATTRIBUTE1... SHIP_LINE_ATTRIBUTE15 entered in RCV_TRANSACTIONS_INTERFACE while performing Receiving Open Interface(including ASN and ASBN) and from corresponding shipping transactions from Inventory/Order Management for Inter-org and Internal Order Cycles respectively.

4. Match Unordered Receipts Form
The flexfield comes from RCV_TRANSACTIONS and finally goes back to RCV_TRANSACTIONS table.

5. Receiving Transaction Summary Form
The header flexfield comes from RCV_SHIPMENT_HEADERS and the lines flexfield comes from RCV_TRANSACTIONS.

6. Transaction Status Summary Form
The flexfield displayed is from RCV_TRANSACTIONS_INTERFACE (ATTRIBUTE1... ATTRIBUTE15)

Why Receipt Tolerance Is Not Considered And Over Receipt Quantity Is Allowed?

You find that while creating a receipt, the tolerance is not accounted and over receipt quantity can be received.

Example
1. Create a PO with line quantity = 10, shipment quantity = 10.
At shipment Receiving Controls -> Over Receipt Tolerance:
Tolerance=5%
Action=reject
More tab from Shipments shows:
Receipt Close Tolerance = 0
Invoice Close Tolerance = 0
2. Navigate to the Enter Receipts form.
3. Query the PO and note that the line to be received comes in with '0' quantity
4. Enter a quantity to be received, like qty = 20 and save.
5. Receipt number is issued, no errors are received.
Note: There is no pop message/warning about over receipt tolerance.
6. Navigate to the PO Summary form and query the PO shipment.
Shipment is 'Closed for Receiving', quantity Ordered = 10, quantity Received = 20
Answer:
This is possible when blind receiving is allowed in the Receiving Options for the Inventory Organization involved.

When blind receiving is enabled, Receipts form shows zero quantity when the PO is queried and thereafter user is allowed to receive any quantity irrespective of the over receipt tolerance and the action associated to it.

If users do not want this possibility, then 'Allow Blind Receiving' flag in the Receiving Options of Inventory Organization should be unchecked. This will not allow users to receive more than the tolerable quantity.

This is explained Bug 6070256- While Creating Receipt, Tolerance Is Not Considered & Over Receipt Qty Is Allowed

How To Restrict List Of Inventory Organizations In Change Organization Window?

Navigation:
Inventory Resp > Setup > Organizations > Organization Access

In the Organization Access form, you can specify which organizations a responsibility can access by mapping responsibilities to organizations. Once this mapping is set up, a user logging into an Oracle Manufacturing product is restricted to the organizations mapped to the responsibility chosen. The Change Organization window is restricted as well.

Until you assign an organization to a responsibility in this window, all responsibilities have access to all organizations. Therefore, the Change Organization window will list organizations for which the responsibility has access and those for which no restrictions have been defined. Only once an organization is entered in the organization access form will it not be accessible to other responsibilities.

Example:
Three inventory organizations are defined, IO1, IO2 and IO3.
On the Organization Access form, restrict IO1 to responsibility Purchasing Super User.
No restrictions defined for IO2 and IO3.
When a user is in Purchasing Super User responsibility, they will see all 3 organizations in Change Organization form.
But a user in any other responsibility will only see IO2 and IO3 in Change Organization form.

Refer to 'Defining Organization Access' in Inventory User's Guide for more details.

How can an internal requisition be closed, if the related internal sales order does not ship the entire ordered quantity (under-ship)?

 No further quantity is expected to be shipped from the shipping inventory org.

Answer:
Manually 'Finally Close' or 'Cancel' the internal requisition line.

(N) Purchasing Resp > Requisition Summary > Query Requisition
Click on Lines(B)
(M) Tools > Control
Select action and click Ok (B)


Since system does not know that no more quantity will be shipped, the requisition line remains open and will show as expected supply. Closing or cancelling the line indicates that no more quantity is expected for the line and the supply is then removed.

How to to prevent duplicate serials from being existing in install base (Expense Destination Items) and be able to Correct / Return?

Serial Entry is allowed for Install base Expense Items (via functionality provided by bug 6364914), but there is no Serial validation.
This causes two problems:
1. Duplicate Serial Numbers can be transacted
2. Returns and Corrections forms do not allow for Serial Entry
Answer
There is no functionality to validate Serial Numbers for Expense Destination transactions because the Serial Numbers are not tracked in Inventory (mtl_serial_numbers table)

Enhancement Request <> (SERIAL VALIDATION REQUIRED FOR INSTALL BASE EXPENSE ITEMS) was logged for this issue. Please monitor the Enhancement Request using My Oracle Support.

How can an Intransit Shipment be Canceled?

There is no functionality to Cancel an Intransit Shipment. Once the Shipment is created, the
Items are Issued out of the Subinventory. The Shipment must then be processed (Received/Delivered)
in the Receiving/Destination Org then one of the following options performed to return the Item to the correct Org:
1. Create Internal Req in Receiving/Destination Org and Ship Confirm it back
-or- 2. Perform Miscellaenous transactions to adjust inventory (or Cycle Counting)
-or- 3. Perform InterOrg Transaction to return the Item to the correct Organization

How To Perform Receiving Inspections?

Purchasing lets you inspect items you receive from suppliers or customers before internal delivery. You can inspect any item or set up certain items to require inspection.

The buyer can use the Note to Receiver field when preparing the purchase order to indicate where items that require inspection should go. The inspector or requestor can record the inspection results in the Inspections window.

You can review in the Receiving Transactions window what items require inspection, and the quantity accepted after inspection. If items require inspection, but the quantity accepted for the receipt is zero, then you know the items are still in inspection. Requestors can review the status of their requisitions in the Requisitions window. In the Purchase Orders window, you can view whether items require inspection and the quantities received and accepted.

If you choose to let requestors inspect items, they can enter the results of their inspections and then record the quantity delivered in the Receiving Transactions window.

If Oracle Quality is installed, you can inspect items through Quality, if the profile option QA: PO Inspection is set to Oracle Quality. (By default, it is set to Oracle Purchasing.) See: Profile Options (in Oracle Quality), Oracle Quality User's Guide. You cannot use Oracle Quality to inspect customer returns.

Purchasing lets you identify returns to a supplier or customer. There may be many receipt numbers associated with a particular purchase order or RMA number. If, after inspection, you find damaged goods and reject these, you can send the goods back to Receiving to return to the supplier or customer. The receiving agent records the quantity returned to the supplier using the Receiving Returns window.

Use the Inspection Details window to enter inspection information for received items.

To enter inspection information:

1. Navigate to the Inspection Details window by selecting the Inspect button in the Receiving Transactions window.
Note: If you use Oracle Quality to inspect the items, when you choose the Inspect button the system selects the first based on the alphanumeric order of inspection plan names of the inspection plans to display. See: Entering Quality Results for Receiving Inspections, Oracle Quality User's Guide.

2. Select Accept or Reject to describe the action you are taking in a line.
3. Enter the Quantity accepted or rejected. Purchasing displays the uninspected quantity as the default.
4. Enter the UOM for the inspected item.
5. Enter the Quality Code.
6. Enter a Reason Code for the transaction. See: Defining Transaction Reasons, Oracle Inventory User's Guide.
7. Enter the Supplier Lot number.
8. Enter the inspection Date. The system date is the default.
9. Enter a Comment.
10. Save your work.

To cancel inspection entry:

Select the Cancel button to cancel inspection entry and return to the Receiving Transactions window.

To save your work:

Select OK to save your inspection entries and return to the Receiving Transactions window. You can use Inspection to return to this line for additional inspection entries until you have saved your work. After this time, the receipts will no longer be available for inspection.

If you want to enter more inspection results for a receipt after you've saved your work, re-query the receiving transaction line using the Find Receiving Transactions window, and then enter more inspection results.

How To Receive Against Closed For Invoice PO that Was Matched but Received Via Misc Receipt?

A Miscellaneous Receipt was performed for item intended to be received into Inventory via standard Purchase Order (PO) receipt. The PO was matched in Accounts Payables (AP) to Invoice, but a Hold occurred due to Quantity Billed > Quantity Received. The Hold was overridden and the Invoice paid.

Now the concern is if the item is received as originally intended will the PO receipt be eligible to be matched again thus allowing the vendor to be overpaid? How can this receipt be performed against the PO when the item has already been received via Misc Receipt without the receipt being double matched and vendor overpaid?
Answer
You can proceed with receiving against the PO, as long as the PO is in status Closed For Invoicing as that will prevent further matching in AP. If an attempt at Matching occurs the following error should be displayed to the user:
APP-SQLAP-10715: This purchase order line is closed for invoicing

Also when the PO is received against, the shipment and line status should then be Closed For Receiving and the shipment status will then progress automatically to Closed status (not a Final Close status).

You do not have to worry about overpaying this vendor, you may proceed with performing the receipt. To keep the inventory On Hand quantity in check you will need to do a Miscellaneous Issue in Inventory and then perform the receipt.

How can the Inventory Period be Opened using the Purchasing Responsibility?

Inventory is installed but not used but Oracle still requires the INV period to be opened. If the period is not opened the following error is received "Please enter the GL date with in open inventory accounting period".
Answer
The Inventory period form will need to be added to the Purchasing responsibility. Follow the steps below:

1. Move to system administrator.
2. Choose Application - Menu
- Query on the MENU - PO_SETUP_GUI
- add a new sequence at the very bottom giving the next sequence number
- Give a prompt of Accounting Close Cycle
- give the Sub-Menu of INV_ACCOUNTING_CLOSE
- Save
3. Confirm the concurrent request kicks off and completes.
4. Navigate to purchasing super user, choose Setup/Accounting Close Cycle/inventory accounting periods
- You should now be able to open periods for the inventory organizations

How To Open Periods So Receiving Can Be Completed?

When attempting to receive against a source document, you may get errors such as:
"The purchasing accounting period in which you are trying to create this receiving trx is not open for the following item(s)"  or  "APP-14376: Please Enter A GL Date Within A Open PO Period".
Below are the steps to open periods in Purchasing, General Ledger and Inventory:

For Purchasing Period:

1. Log in to application with Purchasing responsibility.
2. The navigation path is: Setup > Financials > Accounting > Control Purchasing Periods
3. Find the current month period.
4. Click in the status box
5. Click on the List of Values on the toolbar.
6. Select Open
7. Click on the Save Disk on the toolbar

For General Ledger Period:

1. Log in to application with Purchasing responsibility.
2. The navigation path is: Setup > Financials > Accounting > Open and  Close periods
3. Click Open Next Period button.
4. Click on the Save Disk on the toolbar

For Inventory Period:

1. Log in to application with Inventory responsibility.
2. The navigation path is: Accounting Close Cycle > Inventory Accounting  Periods
3. Select Organization
4. Select Month
5. Click on Change Status button
6. Click OK

How to Enter a Tag or Serial Number in Receiving And Have it Flow Flow To Fixed Assets?

Is there any way for the Tag number to flow from PO to Fixed Assets for a received Fixed Asset item?
Can Receiving enter a receipt for an asset and include the tag and serial number on the receipt transaction, which would then populate the tag and serial number fields in Mass Additions for Fixed Assets?
Currently, there is no capability for the tag number for fixed asset item to flow from PO to Fixed Assets. The interface is via Accounts Payables and there is not any sort of process flow or interface here to accommodate this.

Please try the following workaround:

1. To add the Asset Tag Number and the Serial Number for a Fixed Asset cannot be added to the Purchase Order. After you Create the Mass Addition to Fixed Assets from Accounts Payable, go into the Prepare Mass Additions Form to add these fields.
2. Navigation path: Mass Additions\Prepare Mass Additions\Summary\Open, .. Add these fields.
3. There is no direct interface between Purchasing-Accounts Payable-Fixed Assets for these fields.

The following Enhancement Request has been logged for the same:
Bug:4581877 ER: Capture All Asset Information Upon Receipt Like Serial / Tag Number

Why Receiving Forms Allow Receipt of Unimplemented Item Revision?

This is the current functionality. As documented in Bug 5205665, Revision list of lalues within Receiving forms do not currently validate unimplemented item revisions. Following Enhancement Request has been logged for this issue.
Bug 5205665 ABLE TO SELECT UNIMPLEMENTED REVISION IN RECEIVING FORM,

How To Correct A Wrong Exchange Rate For A PO Receipt?

While creating Receipts the receipt dates were set to an earlier date. For the receipt line under the currency tab the date for the currency conversion was not changed. Because of this the currency conversion for the receipts were using the rate for the wrong date. How can the currency rate be changed for these receipts?
Answer:
The rate date was not changed while creating the receipts. When a receipt is saved, the rate that is in the receipts form goes into the receiving tables, the same rate is passed to inventory which in turn is used for material costing, same rate goes into the accrual tables for accrual accounting, same rate to GL tables also.
This is not an issue that occurred as a result of a bug in the application. Its purely user's error, datafix cannot be provided.
Note: If the application would be creating receipts with a different rate than that of the user entered rate (in receipt), then Development would provide a datafix but for user errors datafix would not be provided. Especially in cases as the reported one datafix cannot be provided by Receiving - there are multiple modules involved which use the same rate.
Users can contact their local Oracle consulting department to discuss the issue and request their assistance.

Why Do Receipts Exist Without Receipt Lines/Transactions?

Why do Receipt Numbers (rcv_shipment_headers records) exist when there are no Receipt Lines (rcv_shipment_lines) or Transactions (rcv_transactions) associated with the Receipt Number?
Answer:
It is correct functionality that Receipt Numbers can be Saved without corresponding Receipt Lines. The existence of Receipt Numbers (Receipt Headers) without Receipt Lines does not cause any problems so those Receipts Numbers can be ignored or can be utilized for Add To Receipt functionality for adding to the receipt at later time.
When using RCV: Processing Mode=Immediate or Batch, the Receipt Header (rcv_shipment_headers record) is Saved before the Receiving Transaction Processor processes the transaction (which means if the Transaction fails or remains unprocessed (Pending), the Receipt Header will still exist). Oracle receiving software does not delete the Receipt Header if the Immediate or Batch transaction does not process successfully.
The following Notes also reference this issue:
Note 269073.1 - RCVRCERC: A Receiving Header Transaction is able to be Saved With No Receipt Lines
The following sql can be used to identify Receipt Headers which do not have corresponding Receipt Lines:

select receipt_num, creation_date, ship_to_org_id
from rcv_shipment_headers
where shipment_header_id not in (select shipment_header_id from rcv_shipment_lines);

Steps that can be done to create Receipt header without Receipt lines:

1. Nav > Receipt > Receipts
2. Query by supplier
3. Select a line then deselect the line.
4. Set focuse to receipt header and save. Note the receipt number
5. Run the following sql query and enter the receipt number:

select receipt_num, creation_date, ship_to_org_id
from rcv_shipment_headers
where shipment_header_id not in
(select shipment_header_id from rcv_shipment_lines)
and receipt_num = '&RECEIPT_NUMBER';

Another way to create receipt header without shipment line is as follows...

1. Nav > Receipt > Receipts
2. Perform Blind Query
3. Enter a Supplier in the Supplier field in the header record
4. Save and note the receipt number
5. Run the query and enter the receipt number:

select receipt_num, creation_date, ship_to_org_id
from rcv_shipment_headers
where shipment_header_id not in
(select shipment_header_id from rcv_shipment_lines)
and receipt_num = '&RECEIPT_NUMBER';

6. The above queries will return records for across ship to organizations, so you  need to narrow down the specific ship to org.

How to Receive into 'Receiving' type SUB-INVENTORY using Enter Receipts form (Both in WMS and non-WMS Enabled Orgs)?

Inventory extended sub-inventory and locator functionality to receiving docks by introducing "Receiving" type sub-inventories to track material on the receiving docks. However, it is unavailable to enter sub-inventory when the destination type is Receiving on the Enter Receipts form.
It is available to receive into a "receiving" sub-inventory when using MSCA for both WMS and non-WMS enabled inventory orgs. But unavailable to receive into a "receiving" subinventory using Enter Receipts form (both in WMS and non-WMS enabled orgs).

Answer:

This is expected functionality. In 11.5.10, inventory extended sub-inventory and locator functionality to receiving docks by introducing "Receiving" type sub-inventories to track material on the receiving docks. However, this functionality is supported only when entering receipts via mobile applications.
Following Enhancement has been logged to request to provide this functionality via forms:
Bug 6820861 - RCVRCERC: ALLOW RECEIPT INTO 'RECEIVING' SUBINV / LOCATOR VIA FORM

How to Personalize the Receipts Form and Make A Text Field In Customized Color?

In the Receipts form there is a field 'Header Receiver Note' that we would like the text color to be red. Is there any way to implement a personalization to change the text color in that field to Red?

Answer:

Personalizations are considered custom code and a customization. With that said, here is
personalization that you can effect to implement a text color change for that field. In this
example we are using the Enter Receipts form in Purchasing for the field 'Header Receiver
Note' which is in the Overflow region in the Enter Receipts form and it correlates to Note
To Receiver. Here we are setting the text color in the field to the color red:

1. Login to Applications and navigate to the Enter Receipts form

2. Query up a receipt

3. Click on the menu Help > Diagnostics > Custom Code > Personalize

4. Set the following personalization at header region in the Personalization form:

Function Name = RCV_RCVRCERC Form Name = RCVRCERC

Seq Description Level Enabled
---- ------------------------- -------- --------
10 Set Header Receiver Note Text Color Function X

5. Then click on Condition tab:

Condition Tab
Trigger Event = WHEN-NEW-BLOCK-INSTANCE
Trigger Object = Header
Processing Mode = Not in Enter-Query Mode

Context region
Level Value
---------- -----------------
Set for (select value from LOV if necessary)
desired level
(User, resp,
app, site)

6. Click on Actions tab

Seq Type Description Language Enabled
------ -------- ---------------- -------- ----
10 Property Receiver Note Field All X

7. On same Actions tab over on right side of form:

Object Type = Item
Target Object = OVERFLOW_REGION.NOTE_TO_RECEIVER
Property Name = FOREGROUND_COLOR
Value = r255g0b0

Note: Colors are defined in terms of red-blue-green values ranging from 0 to 255. Various
hues can be derived by varying values of the above Value setting

8. Save the settings, log off and back on to the form and test.

How to Set Invoice Close Tolerance in Purchasing?

Set invoice close tolerance with Purchasing superuser responsibility at:
1. Item :
Items -> Organization Items -> Purchasing region -> field=Invoice Close Tolerance
2. Purchasing Options
Setup -> Organizations -> Purchasing Options -> Default region ->  field=Invoice Close

How to View Pending Receiving Transactions ?

From Purchasing Super User:

1. Navigate to Receiving > Transaction Status Summary.

2. In the date fields, enter the dates for the period you are trying to close.

3. Blank out the transaction type.

This brings up all pending transactions.

What Generates the GL_SL_LINK_ID Value in RCV_RECEIVING_SUB_LEDGER ?

The GL_SL_LINK_ID value is generated by sequence PO_SL_LINK_S for Purchasing receiving transactions. Note that this will have a corresponding value of 'RSL' in the GL_SL_LINK_TABLE column of the GL_INTERFACE table.
Other applications may also generate GL_SL_LINK_ID values, but may use a different sequence and will have different values in the GL_SL_LINK_TABLE column of the GL_INTERFACE table.

How to Deal with Pending Receiving Transaction?

(Apps Version 11.0.3)
To deal with the stuck data, go into the Transaction Status Summary (Receiving -> Transaction Status Summary), and delete these transactions, and then re- enter the receipt.
If need to process a large amount of receipts, can change the Profile option RCV: Processing Mode to BATCH, and run the Receiving Transaction Processor (Reports -> Run), and this should pick them up.
In the above case leave the processing_status_code and transaction_status_code to status PENDING. However, changing data at the SQL level automatically desupports that transaction, hence should back up the data before trying anything.
To fix the source, switch from ONLINE or IMMEDIATE mode to BATCH mode. Do this by changing the Site System Profile option RCV: Processing Mode to BATCH.
System Administrator Responsibility, go to (Profiles->System), then check the Site flag, put in the profile name %RCV:% and do the find.
Then need to have the Receiving Transaction Processor process kick-off every now and then. Do this from Purchasing Super User Responsibility, (Reports -> Run) by running the process Receiving Transaction Processor at an interval that suits requirement. This will handle all receiving transactions with one
process, as opposed to one-process-per-transaction when it is ONLINE or IMMEDIATE.

Why View Accounting is Disabled For Expense Item in View Receiving Transactions?

When 2-Way matching is being used View Accounting is not enabled in the Receiving Transaction Summary. Expense items are being used.

Answer:

This is standard behaviour. The Accrue at Receipt flag will be unchecked (as default) for Expense Destination when the invoice match option is set to 2-way. Since the accrue at receipt flag is unchecked at PO shipment level, the receipt will be accrued at period end and therefore the Accrual Period End Process must be run.
If Expense PO is set to Accrue at Period End, no accounting transactions are viewable from the Receiving Transaction Summary. Accounting Transactions which are Accrued at Period End will be viewable from GL application after the Accrual Period End Process has been run.

Why is a PO Line Closed For Receiving Still Showing in PO LOV For Receipts?

In the Find Expected Receipts form the Purchase Order (PO) number List Of Values (LOV) is able to retrieve a PO where the corresponding PO line is closed for receiving, the PO itself is still open. The PO is not enabled for over receipt.

Answer:

1. It is per functionality that a closed for receiving PO can be retrieved in the Find Expected Receipts form LOV as the criteria is that the PO shipment only need be approved and not canceled or finally closed.
2. Per the 11i Oracle User's Guide, page 7-32 it states:
" For a Supplier source type, enter the Purchase Order number. To be available, a purchase order must have at least one approved shipment for which the ship–to organization is the same as the current active organization..."
There is no restriction for the PO field LOV other than there must be at least one approved shipment line (not canceled and not Finally Closed) for the PO to be retrieved in this LOV.

Why Service Purchase Orders are not Changing to Closed Status After Being Invoiced?

Set Receipt close tolerance = 100%.
When entering a purchase order,
1. Click on Shipments button, More tab.
2. Populate Receipt Close Tolerance field with 100. or Set Receipt close tolerance = 100 for Service Line Type
1. Navigate to Setup > Purchasing > Line Types
2. For Name = Service, populate Receipt Close field with 100.

How can all the Expected Receipt Lines be selected for processing when performing a Receipt?

Use Express button to select all expected receipt lines.
You need to determine if one step or two step receiving is needed.

For one step (Direct Delivery Routing), the Receive and Deliver transactions would be processed at same time (Destination Type=Inventory, Expense or Shop Floor)--Final Destination.

For two step (Standard Receipt Routing), only Receive transaction is performed (Destination Type=Receiving) is performed on Receipts form then user must Deliver using Receiving Transactions (Nav > Receiving > Receiving Transactions) form.

How are Receiving Transaction Tied to Inventory Transactions?

How the MTL_MATERIAL_TRANSACTIONS table tie to the RCV_TRANSACTIONS table?

If the RECEIVING transaction information is known, then do the following:
1. Get the transaction_id from rcv_transactions where the receiving transaction_type is CORRECT, DELIVER or RETURN TO RECEIVING.
2. The transaction_id in rcv_transactions will be the rcv_transaction_id in mtl_material_transactions.
RCV_TRANSACTIONS.TRANSACTION_ID=MTL_MATERIAL_TRANSACTIONS.RCV_TRANSACTION_ID If the INVENTORY transaction information is known, then do the following:
1. Get the transaction_id and the rcv_transaction_id from mtl_material_transactions.
2. The rcv_transaction_id.mtl_material_transactions will equal the transaction_id in rcv_transactions.
The Technical Reference Manual for the RCV_TRANSACTIONS table reads that the inv_transaction_id ties to mtl_material_transactions.
This is true, but only applies to Internal Order Issue transactions.
There is little documentation on the links between the tables.

How to Find Transactions Exist in the RCV_RECEIVING_SUB_LEDGER but are Missing in GL?

You have receipt transactions that exist in RCV_RECEIVING_SUB_LEDGER that do not exist in General Ledger.
Answer:

The receiving sub ledger(RCV_RECEIVING_SUB_LEDGER) has data both from period end accrual and accrue on receipt. For items on accrue at period end, the period end accrual code inserts both into gl_interface table and sub ledger and there is no way that these transactions are in one and not in the other.
For inventory items that are accrue on receipt, system inserts into the gl_interface and sub ledger and into the mtl_material_transactions table at the
same time, the same data.
The Inventory Cost Processor then processes these records and creates new rows in mtl_transaction_accounts table using the entries from the mtl_material_transactions table. The GL Update process in Inventory then transfers these records to gl_interface table.
Receipt Transactions can be deleted from GL_INTERFACE which could cause this problem.

Records being inserted in Gl_interface is dependent on the below setup in Inventory Org Parameters form. Navigation:
Inventory Responsibility -> Setup-> Organizations-> Organization Parameters.
query the inventory org where the receipt is entered.In the costing tab -> enable the "Transfer to GL" option to either detail or summary. If this option is None, then receipt accounting entries will not be inserted in GL_interface. (this is choosen for customers using 'cash basis ‘accounting
 

How can these receipt and deliveries be accomplished into the correct Destination Type?

Having received and delivered transactions but the Destination Type was incorrect, now want to revise the Destination Type to Inventory so that it can be received into a sub-inventory. When trying to change the destination type however it cannot be changed to Inventory.How can these receipt and deliveries be accomplished into the correct Destination Type?

Answer:

The only way to change the receipt destination is to perform a return to receiving and then a return to vendor and then re-receive the receipts into the correct destination type on a revised PO or create a new PO. The profile option RCV: Allow Routing Override (11.5.9 and earlier - RCV: Override Destination Type) is intended for use during the performance of receiving and delivering activities. It is not intended for usage after the receipt.

How can we undo a receipt and thus cancel a purchase order so that we may create a new Purchase Order (PO) with the correct destination type?

The Destination Type value is defaulted based on the Receipt Routing at the purchase order shipment line level. To determine this value navigate to

(r) Purchasing (n) Purchase Order > Purchase Order Summary > Shipment radio button > Receiving Controls radio button.

The defaulting rules are as follows:
1. Destination Type will default to Inventory if the Receipt Routing is DIRECT and the item is an Inventory item.
2. Destination Type will default to Expense if the Receipt Routing is DIRECT and the Item is an Expense item.
3. Destination Type will be Receiving if Receipt Routing is Standard or Inspection Required
So in order to correct the destination of the receipt, the correct way to address this would be to do the following:

1. Perform a return to receiving for the full amount. This will return the material to the receiving dock where you can then perform the next step.
2. Once the items have been returned to receiving, you can then perform a return to vendor
3. After you performed the return to vendor, you can then cancel the purchase order and create a new PO with the correct inventory destination type or revise the existing po and create a revision with the correct destination type on the newly revised PO.

How to enter Kit Items in Purchase Order and Receive the Kit's components of that item to Inventory?

Example: For 1 Kit item A, including 1 table and 4 chairs. Define components (table and chair) for item A by using Bills of Material screen. In Order Management, when user orders 100 item A, system will generate automatically 100 tables and 400 chairs and Ship to customer. Item A does not have Onhand, only its components have Onhand.
Also in Purchasing, How to create Purchase Order with "Kit" item and receive its components in Receipt screen?

Answer:
There is no way to order a Kit and when received, have the Receipts performed for the components in the Kit. If an item is defined on the Purchase Order and received, there is no way to make the Receipt break down the Kit item into its components.

How to Delete a Receipt?

How do users delete the receipts made in error and how do users undo a receiving transaction so the receipt is not accessible for matching?

Answer:

Users cannot delete a receipt once it is made, however users can perform either a 'Correction' or a 'Return' to the receipt dependant upon the nature of the error made when performing the receipt:

Return To Vendor - This is typically done if you do not want the shipment received from the vendor (for example, vendor over-shipped, or items received were damaged or wrong color, or you just don't want to receive that shipment at this time). You can return the shipment for the full amount.

Correction - This is typically done when you wish to correct an error made when receiving a shipment (for example, you physically received 9 but put down that you received 10).

Both methods above ensure that correct accounting adjustments are made when performing either a return or a correction.

How To Receive Against A Canceled PO?

Goods were received on the receiving dock before they could be entered into the system, but then the Purchase Order (PO) was canceled. How can this canceled Purchase Order be handled and address these received goods when the original PO is now canceled?
Answer:

There is no way in the system to be able to receive against this canceled PO. There are a couple of options in how to address this, a canceled PO means just that - it is canceled and is no longer considered to be required and is not in the system.
1. Since the original Purchase Order is now canceled, what will have to be done is create a new Purchase Order for the received items and then complete receipt. Then if it is desired to return the items to the supplier then that can be done now as there is an open PO to perform the return.
If it is desired to actually receive the items that were received then go ahead and continue receipt.
This is the only way to receive and address these items in the system.
OR
2. Unordered Receipt functionality can be used as an alternative but eventually there will have to be a match of the unordered receipt to a Purchase Order

Why isn't Internal Order for Expense Item available to transact on Receipts form?

The Shipping Network shipping Method=Intransit, but the Internal Order Ship Confirm does not create an Intransit Shipment; instead, the Items are automatically Received/Delivered in the Destination/Receiving Organization. Why isn't the Shipping Network setup being used?
Answer:
On the Shipping Networks form, there is a checkbox 'Manual Receipt at Expense Destination'. If this is not checked, then Expense destination transfers are treated as Direct.
If you need to receive the Expense destination goods manually, please select 'Manual Receipt at Expense
Destination' then create a new Internal Requisition/Sales Order.