RECEIVING OVERVIEW BROWN BAG

Jennifer Reed
Premium Manufacturing Application Support

RECEIPTS

The receiving configuration can be setup to include the flexibility to inspect items like expensive
machined parts and avoid inspecting common office supplies such as pencils.

For a high level understanding of receiving, there are a couple things to be considered that can
have a very large impact on the amount of effort needed to process the receipt and the final
destination of the item ordered. They are Receipt Routing and Destination Type.

RECEIPT ROUTING

Basically, receipt routing decides how many ‘channels’ a receipt will have to go through before it
is considered delivered to its final destination.

Direct receipt routing is the simplest. It means that when a receipt is saved, the application
considers the item(s) on that receipt as being delivered to the final destination. The final
destination could be a locator in a subinventory within inventory or it could be the desk of a user.
The key word here is ‘delivered’. This word should be used with care in Oracle Receiving
terminology because it means that an item has been sent to its final destination. Even though it
seems like only one transaction is created with Direct receipt routing, there are actually two
transactions. The ‘receive’ is one and the ‘deliver’ is the second. To reduce the user’s time and
effort, the application processes both transactions as if they were one when a Direct receipt
routing transaction is saved.

Standard receipt routing is a two-step process. The transactions are still ‘receive’ and ‘deliver’;
however, with Standard receipt routing the ‘receive’ transaction is saved in one form and the
‘deliver’ transaction is saved in another. For example, goods might be received, but someone
may need to decide which location the goods are to be sent. So the goods might sit on a dock
while waiting to be ‘delivered’ to a final destination.

Inspection receipt routing is a three-step process. In this type of situation, there is a ‘receive’
transaction, ‘accept’ or ‘reject’ transaction and a ‘deliver’ transaction.

For all three receipt routings, the ‘receive’

transactions are always created in the Receipts
form [Receiving:Receipts]. If Direct receipt
routing is the only process used, then there is no
need to use the Receiving Transactions form
[Receiving:Receiving Transactions] because the
‘receive’ and ‘deliver’ transactions are both done
in the Receipts form.

With Standard receipt routing, the ‘deliver’

transaction is performed in the Receiving
Transactions form. For Inspection receipt

Receipt Routing on the Receiving Options form.

1 Setup:Organizations:Receiving Options
routing, the ‘accept’, ‘reject’ and ‘deliver’ transactions are performed by accessing the Receiving
Transactions form.

It is possible to have a receipt routing of Shop Floor, but only for outside processing items. This
type of transaction is only used when the WIP module is installed and can be quite involved in
setting up and will not be reviewed in this document.

There are several places where the Receipt Routing can be sourced. The first place is the
Receiving Options form. [Setup:Organizations:Receiving Options] The other places the Receipt
Routing can be entered are the Suppliers form, the Receiving Controls form and the
Organization/Master Items form. If the Receipt Routing is only entered in the Receiving Options
form, then all receipts will use whatever routing method is entered in the Receiving Options form.
The Receipt Routing in the Receiving Options form is overridden by the Receipt Routing in the
Supplier form. For example, if a client has their Receipt Routing set to Direct in the Receiving
Options form and they set the Receipt Routing to Standard in the Suppliers form for one supplier,
then all receipts from that one supplier will have a Standard Receipt Routing while receipts from
all other suppliers will have a Direct receipt routing. The Suppliers Receipt Routing is overridden
by the Receipt Routing in the Master or Organization Items form and the Receipt Routing for the
Master or Organization Items form is overridden by the Receiving Controls form for a specific
Purchase Order. Displayed are screen shots from forms where the Receipt Routing can be
entered.

Receipt Routing on the Suppliers form. Receipt Routing on the Organization Items form.
Supply Base:Suppliers – Open button the Receiving Items:Organization Items – Receiving alternate region
alternate region

If a user is ever uncertain of the Receipt Routing it

is simple to go to the Receipts form or the
Receiving Transaction form and view it there. It is
displayed as a view only field in the lower right side
of the form where the receipt lines are shown.

DESTINATION TYPES

2
Receipt Routing on the Receiving Controls form.
Purchase Orders:Purchase Orders – Shipments
button then Receiving Controls button
The Destination Type column in the Receipt form and the Receiving Transactions form show
where the receipt will need to go next to be processed. When the destination type shows
Expense, Shop Floor or Inventory, the transaction being entered will be the final transaction or
the deliver transaction needed to complete the receiving process. When the destination type
shows Receiving then the receipt routing is either Standard or Inspection meaning more than one
step is needed before the items are delivered.

If the receipt routing is direct, the destination type

will show Inventory, Expense or Shop Floor. This
is seen in the Receipts form.
[Receiving:Receipts]. When the receipt routing is
standard or inspection, the destination type will
show Receiving in the Receipts form and will
show Inventory, Expense or Shop Floor in the
Receiving Transactions form.
[Receiving:Receiving Transactions]

The Destination type can be somewhat tricky.

See the last page for a table diagram of how the Destination Type value in the Receipts form.
combination of item attributes, receipt routing and Receiving:Receipts
receiving controls affect the destination type.

An expense item can have a destination type of

Inventory under the following circumstances:
• Inventory item attributes enabled
• Item is accrued on receipt
• Item is NOT inventory asset value enabled
• Item is going to be delivered to an expense
subinventory.
However, if that same item is accrued at period
end it can only have a destination type of
Expense.

The destination type for expense items should be

determined when the Requisition or Purchase
Order is created and before the line is saved.
The destination type is set in the Distribution form
under the Destination alternate region. To check
the setting for the Accrue on Receipt flag, click on Destination Type value in Distribution form.
the alternate region called More while in the Purchase Orders:Purchase Orders – Shipments
button then Distribution button in the Destination
Shipments form. All items with a destination type
alternate region
of Inventory must be accrued on receipt.

CREATING NEW RECEIPTS

When items arrive, receipts need to be created. To

find expected receipts, go to the Receipts form
[Receipts:Receipts] and enter the search criteria in
the Find Expected Receipts form. A common error

Accrue on Receipt flag in the More alternate

3
region.
Purchase Orders:Purchase Orders – Shipments
button then More alternate region
 displayed in the toolbar after entering the search criteria and the Find button is pressed is FRM-
40212: Invalid value for field PO_NUM.

Usually, this error is seen when either the purchase order is closed, isn’t approved or isn’t being
shipped to the organization in which it is being searched. The organization code is shown on all
receiving forms window name in parentheses next to the window name. It must match the
organization code shown in the Ship To column of the Shipments form for PO. [Purchase
Orders:Purchase Orders – Shipments button] or the shipment information can also be viewed in
the Purchase Order Summary form when querying the shipments of a purchase order. The ship
to organization shown in the shipment form or the summary form is the organization where the
receipt must be created

Inventory organization in parenthesis on the

The organization where the item will be received. Receipts form.
Purchase Orders:Purchase Orders – Shipments button Receiving:Receipts
then Shipments alternate region
If the purchase order is approved and is
being received in the correct organization, then the purchase order is most likely closed for
receiving. To search for closed orders, check the box called Include Closed PO’s on the Find
Expected Receipts form. To set this box to be checked each time the form is entered set the
system profile option called RCV: Default Include Closed PO Option to “Yes”. [System
Administrator:Profile:System]

In the Receipt Header form, the Receipt Date field must be within an open GL, PO and INV
period. If all three modules appear to be open and an error mentioning the period being closed is
still displayed, then ensure that the Open and Close Periods form
[Setup:Financials:Accounting:Open and Closer Periods] shows the correct set of books name in
parenthesis and is the same as the set of books for the inventory organization for which the
receipt is being generated. If it’s wrong, query up the system profile option called GL Set of Books
Name for the site, application, responsibility and user and correct the value.

It is possible to setup items sent to inventory so that a subinventory and locator are automatically
populated in the Receipts and/or Receiving Transaction forms with a single default subinventory
and a single default locator. To do this, go to Inventory:Setup:Transactions: Item Transaction
Defaults and create a new record in the subinventory alternate region as well as the locator
alternate region.

Express and Cascade receipts can be created in the Receipts form. Express receipts allow users
to receive multiple lines at one time, and Cascade receipts allow users to receive multiple
shipments of the same item at one time. More detail on Express and Cascade receiving is
available, in the Oracle Purchasing User’s Guide.

4
WHAT IS THE PURPOSE OF EACH RECEIVING FORM?

PROCESSING MODES

There are three processing modes which receipts can be processed. They are On-Line,
Immediate and Batch. On-Line processes the transaction as soon as you hit the save button.
Batch mode processes the transaction when the Receiving Transaction Processor is run. With
Immediate mode, transactions go into the interface table and the Receiving Transaction
Processor is called to processes the group of transactions entered since you last saved your
work. The Receiving Transaction Processor can be run by going to Reports:Run and it can be
setup to run on a schedule. The RCV: Processing Mode profile option is set by going to System
Administrator:Profile:System. It can also be set within the Purchasing responsibility by going to
Personal Profiles. Setting this value at the user level will allow some users to process their
transactions in Batch mode while others process theirs in Immediate or On-line mode.

The high point of using On-Line processing is that receipt errors are seen as soon as the save
button is pressed. If the receipt saves without error, the transaction processed without error. If
the processing mode is On-Line and destination type on the transaction says Inventory, then the
on hand quantity is updated as soon as the transaction is saved. The low point of On-Line
processing is that more resources are used to save each transaction.

MANAGING STUCK RECEIPTS

To ensure that receipts processes correctly, users can go to Receiving:Transaction Status

Summary. In this form any errored receipts for the organization can be seen. If any receipts exist
in the form, then a user can look at the error to find out what may have caused the error.

If there is no error, then there is a good chance that the processing mode is batch and the
processor hasn’t run yet. If the user is interested in trying to create the transaction again, the
transaction can be safely deleted from the system by clicking on the ‘X’ icon in the Transaction
Status Summary form toolbar. Once that is complete, the user can re-enter the transaction. If
there is an error and the error isn’t clear or if the user has already deleted and re-entered the
transaction, then users can login to Metalink [http://metalink.oracle.com] and type the error into
the search field seen at the top of home page or the user can also click on the Bugs button and
put the error into the keywords field and then search for a logged bug. If the solution is not found
on Metalink, the user can log a tar via Metalink by clicking on the Tars button.

[TIP: When searching in Metalink use error numbers, form short names and subroutine names to
get more matches.]

MAINTAINING RECEIPTS

For monitoring errored receipts on a regular basis, the report called Receiving Interface Errors
Report can be run from Reports:Run. It will produce a list of errored receipts.

It is possible to view the receiving transactions that have gone to inventory by switching to an
inventory responsibility and going to Transactions:Material Transactions.

5
If it seems that the inventory on-hand quantity was not updated and the receiving processing
mode is either batch or immediate and the receiving transaction processor has processed the
records without any errors being seen in the Transaction Status Summary form, then it’s possible
that the receiving transaction could be stuck in the MTL_MATERIAL_TRANSACTIONS_TEMP
table. To view the records in that table go to an Inventory responsibility and navigate to
Transactions:Pending Transactions. There are a few reasons that records could be in the
Pending Transaction form. One could be that the Inventory Interface Manager is not active. To
check this, go to Inventory:Setup:Transactions:Interface Managers. Another reason could be that
the transaction failed inventory validation. If this is the case, the error message should be
displayed in the Pending Transaction form. Any records seen in this form cannot be deleted. If
the error message isn’t clear, the user can search in Metalink for the solution and a new tar can
be logged with the Inventory Support Team if the solution cannot be found in Metalink.

One last tip on the relationship between receiving transactions and inventory transactions is that
receipts with inventory destinations having a TRANSACTION_TYPE of DELIVER, CORRECT or
RETURN will have a TRANSACTION_ID that is equal to the RCV_TRANSACTION_ID in the
MTL_MATERIAL_TRANSACTIONS table. 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.
This is the technical translation of the previous paragraph:
RCV_TRANSACTIONS.TRANSACTION_ID=MTL_MATERIAL_TRANSACTIONS.RCV_TRANSACTION_ID