An Advance Shipment
Notice (ASN) is transmitted via Electronic Data Interchange (EDI) from a
supplier to let the receiving organization know that a shipment is coming. The
ASN contains details including shipment date, time, and identification number;
packing slip data; freight information; item detail including cumulative
received quantities; purchase order number; and returnable container
information.
Once an ASN is successfully validated, you can use it in the Receipts window
to create receipts, reducing data entry time. (A validated ASN is one that
contains no errors during data validation in the Receiving Open Interface.)
Suppliers can also send ASNs with billing information. These contain the same
information as ASNs plus invoice and tax information. Once an ASN with billing
information is validated in the receiving open interface and imported into
Purchasing, an invoice for the shipment is created automatically.
A supplier creates an ASN based on the demand conveyed by the purchasing
organization's Purchase Order, Planning Schedule, or Shipping Schedule. If
Purchasing detects errors or discrepancies in the ASN at any time, from the time
the ASN is sent to the time it is entered as received, an Application Advice,
transmitted via EDI, is sent automatically to the supplier. The supplier can
then send a corrected ASN.
Attention:
ASNs come
from external suppliers only. They cannot be used for internal sales orders
sourced from your inventory and generated by internal requisitions.
You can view or cancel an accepted ASN as an intransit shipment in the
Maintain Shipments window.
ASN Process
The ASN process, shown in the next figure, includes
the following:
A shipment authorization is made
to the supplier in the
form of a Purchase Order, Planning Schedule, or Shipping
Schedule.
The supplier sends the ASN
to the receiving organization at
the time of shipment.
The ASN is verified in the Receiving Open Interface.
Intransit and purchasing supplies are updated for ASN lines that are
successfully validated. For each accepted line on the ASN, intransit supply is
increased and purchasing supply is reduced. If the data isn't accepted or if
there is an error or discrepancy in the data, an Application Advice, containing
the most likely cause of the error, is sent to the supplier. The supplier can
then send a corrected (New) ASN.
The goods arrive.
You can use the ASN in the Receipts
window to create receipts.
Shipment-vs.-receipt quantities are compared
during the
receipt transaction process. (As an optional step, CUM quantities can be
compared if Oracle Supplier Scheduling is installed.) If discrepancies are
detected in shipment-vs.-receipt or CUM quantity comparisons, an Application
Advice is sent to the supplier.
ASN Receiving Options
There
are two receiving options related to ASNs:
ASN Control option in the Receiving Options window - With this
option, you can choose whether or not you receive an error message--or are
prevented by Purchasing--when you attempt to receive against a purchase order
shipment for which an ASN already exists. See: Defining Receiving Options.
RCV: Fail All ASN Lines if One Line Fails - With this profile
option, you can choose to reject an entire ASN if any ASN line fails validation
or processing, or to accept an ASN if at least one ASN line is successful. See:
Profile Options in Purchasing.
Application Advices
If an ASN
is not accepted or is only partially accepted, errors and discrepancies are
electronically conveyed to the supplier in an Application Advice. The
Application Advice transmits to the supplier the status (acceptance with errors
or rejection) of the ASN, and the severity and description of the errors.
An Application Advice can be sent at several points during the receiving
process:
When the ASN is first sent and contains header or line
errors.
When the quantity received does not match the quantity shipped
indicated by the ASN.
When the receiving organization's newly updated cumulative
received quantities do not match the supplier's cumulative shipped quantities.
Note:
CUM quantity
comparisons can be performed only if Oracle Supplier Scheduling is
installed.
The supplier can respond to an Application Advice by sending a Cancellation
ASN followed by a corrected (New) ASN. The receiving organization can also
cancel an ASN manually in the Maintain Shipments window.
The following table indicates the appropriate supplier response to particular
Application Advices.
Supplier Response to Application Advices
ASN Header
ASN Lines
Transaction Status
Supplier Action
Fatal Error
Not Validated
Transaction Rejected
Send New ASN before goods arrive.
Warning or Valid
All lines Warning or Valid (no fatal errors)
Transaction Accepted
Do not send a New ASN, but correct indicated problems on future
ASNs.
Warning or Valid
Some Warning Some Valid Some Fatal Error
Transaction Accepted with Some Lines Rejected
Send Cancellation ASN, then send a New (corrected) ASN.
A
Cancellation
ASN, once validated, cancels the original
(New) ASN
if the original (New) ASN has not yet had a receipt created against
it
. The shipment number on the Cancellation ASN is matched to the shipment
number on the validated, original (New) ASN.
A
Test
ASN is sent by the supplier usually to make sure the
ASN transmission works between you and your supplier. A Test ASN is verified as
if it were a New ASN and generates an outbound Application Advice if necessary.
A Test ASN is not available for creating a receipt against it and is not visible
as inbound supply.
Note:
A validated ASN,
as described above, is one that contains no errors during data validation in the
Receiving Open Interface.
ASNs and CUM Management
You can
perform CUM management under the following conditions:
Oracle Supplier Scheduling is installed and CUM Accounting is
enabled for the ship-to organization.
The ASN item or items are defined in the Approved Supplier
List.
The items are sourced from the supplier using a Supply Agreement
Blanket Purchase Order.
The CUM is the total quantity received
from a supplier site, for a particular item, within a CUM period. When an ASN is
used during receiving and Supplier Scheduling is installed, the updated CUM is
compared to the supplier's CUM. Any discrepancy transmits an Application Advice
to the supplier. For more information about CUM management, see: CUM Management.
ASNs and Supply
For each
accepted line on the accepted ASN, intransit supply quantity is automatically
increased and purchasing supply quantity is automatically reduced by the
shipment quantity specified in the ASN.
When an accepted ASN is cancelled or a corrected ASN is sent, corresponding
changes are also made to purchasing and intransit supply. (A supplier can send a
Cancellation ASN or you can cancel the ASN in the Maintain Shipments window.)
The table below shows, for each action you perform with an ASN, the movement
of the quantity on the ASN between the various categories of supply.
ASNs and Supply
Accept ASN
Purchasing Supply
Intransit Supply
Inventory
Accept the New ASN
Reduced for accepted lines only
Increased for accepted lines only
Accept the Cancellation ASN
Increased for all accepted lines on New ASN
Reduced for all accepted lines on New ASN
Receive Items
Purchasing Supply
Intransit Supply
Inventory
Receive item when the item is indicated on an ASN line
Reduced
Increased
Receive item when the item is not indicated on an ASN line
Reduced
Increased
Change Receipt Quantities
Purchasing Supply
Intransit Supply
Inventory
Increase receipt quantity before the ASN is closed
Reduced
Increased
Increase receipt quantity after the ASN is closed
Reduced
Increased
Decrease receipt quantity before the ASN is closed
Increased
Reduced
Decrease receipt quantity after the ASN is closed
Increased
Reduced
Return Items
Purchasing Supply
Intransit Supply
Inventory
Return item(s) to the supplier before the ASN is closed
Increased
Reduced
Return item(s) to the supplier after the ASN is closed
Increased
Reduced
Close Corresponding Purchase Order
Purchasing Supply
Intransit Supply
Inventory
Close the Purchase Order while an ASN for that purchase order is
open
The ASN process, shown in the next figure, includes the following:
A shipment authorization
is made to the supplier in the
form of a Purchase Order, Planning Schedule, or Shipping Schedule.
The supplier sends the ASN
to the receiving
organization at the time of shipment. Applications like iSupplier portal provide
an interface to suppliers to enter the ASN/ASBN details and populate the
Receiving Open Interface tables directly. A supplier can also transmit the
ASN/ASBN via EDI or XML to be imported into the applications via Receiving Open
Interface.
The ASN is verified in the Receiving Open
Interface
. Intransit and purchasing supplies are updated for ASN lines
that are successfully validated. For each accepted line on the ASN, intransit
supply is increased and purchasing supply is reduced (See Supply Information
section for more detailed explanation). If the data isnt accepted or if there is
an error or discrepancy in the data, the supplier is informed about it depending
on the method that the supplier chose to communicate. The supplier can then send
a corrected (New) ASN.
The goods arrive
. ASN is used in
the Receipts window to create receipts.
Fig:
ASN Process Overview
NOTE: Shipment number must be unique for the supplier and
supplier site for a period of one year.
There are three types of ASNs:
1.
A New ASN
is
the initial ASN sent by the supplier.
2.
A Cancellation
ASN
, once validated, cancels the original (New) ASN if the original
(New) ASN has not yet had a receipt created against it. The shipment number on
the Cancellation ASN is matched to the shipment number on the validated,
original (New) ASN.
3.
A Test ASN
is sent by the
supplier usually to make sure the ASN transmission works. A Test ASN is verified
as if it were a New ASN and generates an ASN failure notice, if necessary. A
Test ASN is not available for creating a receipt against it and is not visible
as inbound supply.
SETUP
Receiving Option - ASN Control Action
This
option can have any of the following three values.
Reject
:
Users receive an error message if an
attempt is made to receive a Purchase Order (PO) for which an ASN already exists
and is prevented from completing the receipt.
Warning
:
Users receive a warning message if an
attempt is made to receive a PO for which an ASN already exists, but the user
can continue to save the receipt, if they choose to.
None
:
No error or warning is shown to the user if
an attempt is made to receive a PO for which an ASN already exists.
PROFILES
a) RCV: Fail All ASN Lines if One Line Fails
When
this value is set to Yes, Receiving Open Interface (ROI) rejects an entire ASN
if any ASN line fails validation or processing. When this option is set to No,
ROI will accept an ASN, if at least one ASN is processed successfully.
Note:
11.5.9 and prior releases also used this profile to fail Receive transactions as
referenced in
Note 413288.1
(11.5.10/R12 Profile "Fail All ASN Lines If One Fails" Is Not Used To Fail
Non-ASN Transactions).
b) PO: Automatically Deliver Drop Ship
ASNs
When this profile value is set to Yes, ASN for drop shipment POs
are automatically received and delivered. In the case of drop shipment POs,
since there is no physical receipt of goods, this profile adds automation into
the drop shipment process. This profile was introduced in 11.5.10 and is not
available in prior releases. Please review Note 286996.1
(How to Automatically Generate Receipts for Drop Shipments with Advanced
Shipment Notices (ASN's)) for additional details about how this
functionality.
TECHNICAL OVERVIEW
There are two Receiving Open Interface tables:
RCV_HEADERS_INTERFACE (RHI) and RCV_TRANSACTIONS_INTERFACE (RTI). These tables
are populated with ASN data, either by iSupplier, EDI / XML gateways or
manually using a custom program. After the tables are populated, Receiving
Transaction Processor (RTP) concurrent request is submitted (either manually or
through a scheduled run).
Receiving Transaction Processor first
validates the data populated in RHI & RTI using a program called the
pre-processor. The pre-processor not only validates the data, but also derives
and defaults the data that is not populated in the interface table.
After performing header- and line-level validation, the pre-processor
checks the profile option RCV: Fail All ASN Lines if One Line Fails. If the
profile option is set to Yes and if any line failed validation, the
pre-processor fails the entire ASN. If the profile option is set to No, the
Receiving Transaction Processor takes over and processes the ASN.
For a
successfully processed ASN, RTP populates the RCV_SHIPMENT_HEADERS (RSH) table
with the ASN header information and the RCV_SHIPMENT_LINES(RSL) table for each
shipment line in the ASN. the following fields are populated to indicate that
the shipment is an ASN.
RSH.ASN_TYPE = ASN (or ASBN)
RSL.ASN_LINE_FLAG =
Y
Descriptive Flexfields
Suppliers can send extra
information, for which there are no fields in standard tables, using the
Descriptive Flexfields. In table RTI, fields
SHIP_LINE_ATTRIBUTE1...SHIP_LINE_ATTRIBUTE15 are provided so that suppliers can
provide additional information, if needed. Values from these fields go into the
ATTRIBUTE1...ATTRIBUTE15 fields of RSL.
Lot / Serial
Information
Starting in 11.5.10, suppliers can include lot/serial
and LPN information in an Advance Shipment Notice (ASN). However, if an ASN was
created with lot/serial and/or LPN information, then it must be received via
Receiving Open Interface and cannot be received via the core application forms.
This feature is useful when WMS is installed and mobile application is used to
receive and put-away items, since mobile application uses ROI for all inbound
transactions.
Supply Information
When a Purchase
Order is approved, a record is inserted into MTL_SUPPLY(MS) for each of the
Shipment Lines (MS.QUANTITY = PO_LINE_LOCATIONS_ALL.QUANTITY_ORDERED). When ASNs
are created or Receiving activties are performed, the records in MS are adjusted
accordingly. The MS record is deleted when one of the following occurs:
a.
entire Quantity has been Received/Delivered
-OR-
b. PO Shipment Line has
been Final Closed
-OR-
c. ASN Line is Canceled
The total Quantity of the MS records (with PO or SHIPMENT supply
type) for each PO Shipment Line will be the total unreceived Quantity for the PO
Shipment Line.
Example:
1. Create Purchase Order with 3 Shipment
Lines:
Line 1 Quantity=50 (po_line_locations_all.line_location_id=168544)
Line 2 Quantity=75 (po_line_locations_all.line_location_id=168545)
Line
3 Quantity=100 (po_line_locations_all.line_location_id=168546)
**there are
no records in mtl_supply at this time
2. Approve Purchase Order
there will be three records in mtl_supply with supply_type_code=PO:
mtl_supply.po_line_location_id=168544, Quantity=50, supply_type_code=PO
mtl_supply.po_line_location_id=168545, Quantity=75, supply_type_code=PO
mtl_supply.po_line_location_id=168546, Quantity=100, supply_type_code=PO
3. Perform Receive/Deliver of Quantity=7 for PO Shipment Line 1
(po_line_locations_all.line_location_id=168544)
there will still be 3
records in mtl_supply with supply_type_code=PO, but the supply Quantity for PO
Shipment Line 1 will change from 50 to 43 (50-7):
mtl_supply.po_line_location_id=168544, Quantity=43, supply_type_code=PO
mtl_supply.po_line_location_id=168545, Quantity=75, supply_type_code=PO
mtl_supply.po_line_location_id=168546, Quantity=100, supply_type_code=PO
4. Create ASN with Quantity=12 for PO Shipment 2
(po_line_locations_all.line_location_id=168545)
there will still be 3
records in mtl_supply with supply_type_code=PO, but the Quantity for PO Shipment
Line 2 will change from 75 to 63 (75-12) and a new Shipment supply record will
be inserted into mtl_supply with Quantity=12:
mtl_supply.po_line_location_id=168544, Quantity=43, supply_type_code=PO
mtl_supply.po_line_location_id=168545, Quantity=63, supply_type_code=PO
mtl_supply.po_line_location_id=168545, Quantity=12,
supply_type_code=SHIPMENT
mtl_supply.po_line_location_id=168546,
Quantity=100, supply_type_code=PO
Once an ASN is created, it can be viewed or cancelled using the
Manage Shipments form. Shipment header and line details are available on this
form. Some information can be changed in Manage Shipments form for ASNs.
Fields that can be changed at header level:
Expected Receipts Date
Freight Carrier
Ship-To-Location (Note that this is location, not
inventory organization)
Bill of Lading
Packing Slip
Number of
Containers
Comments
Fields that can be changed at line level:
Comments
Packing Slip
Reason Code
Receipt Routing
Note
that quantities (or any other fields other than those listed above) cannot be
changed on this form. If the quantity on an ASN needs to be changed, then the
supplier needs to cancel the original ASN and send another ASN with corrected
quantities.
An ASN can also be cancelled on this form by choosing Cancel
from the Tools menu.
Only Expected and Partially received shipments
(ASNs) can be cancelled in Manage Shipments Form.
Once an ASN is
cancelled, it cannot be undone. So, this option should be used on rare
occasions. Ideally, only the supplier who sent the ASN should cancel it.
Nav: Receivng > Manage Shipments
RECEIVING ASNs
ASNs can be received using the Enter Receipts form, just like any
POs without ASNs. To find an ASN to receive, enter the shipment number on Find
Expected Receipts form and select the source type as Supplier.
When Only a PO# is used as a search criteria on the Find
Expected Receipts form, all lines eligible for receipt for the PO (ASN and
non-ASN) are shown on the form. On the Lines tab, the ASN Type and ASN No fields
show if the line being received is for an ASN.
Nav:
Receiving > Receipts
ASNs can also be processed (Created, Received, Canceled) via
Receiving Open Interface. Sample scripts:
Create ASN
A:
The ASN (Advanced Shipment Notice (856)) is a document that
is sent to a buyer in advance of the buyer receiving the product. It is typically
used within the context of an EDI environment. It can be used to list the
contents of an expected shipment of goods as well as additional information
relating to the shipment, such as order information, product description,
physical characteristics, type of packaging, marking carrier information,
and configuration of goods within the transportation equipment. In the implementation
of the transaction the latest the ship notice may be sent is the time of
shipment. In practice the ship notice just arrive before the shipment.
The process flow is as follows:
1. Supplier sends ASN.
2. EDI validates the data for EDI standards and inserts data into Receiving
Interface tables.
3. Receiving Open Interface validates ASN data. If accepted shipment lines
are populated.
4. Supply details are maintained.
5. Application Advice is generated. The supplier can check if there is a
rejection of ASN through the advice.
A:
Receive a Shipping notice in Advance.
Load ASN electronically into Oracle Apps using ROI.
Respond using Application Advice via EDI against the received ASN.
Q3. What are the different ways of populating
data in the interface table?
A:
The data can be populated in the interface table either by
EDI, custom scripts that the customer can write (an example script is provided
below) or via SQL Loader. The documentation is available in Oracle Manufacturing
APIs and Open Interfaces Manual, Volume 1, Receiving Open interface between
pages 658-690.The documentation clearly states which fields are required,
which fields are optional and which fields are conditionally populated in
each of the receiving open interface tables. A sample script is as follows.
Save the below information in a file called asn.sql and run it :
/*The following script is what we use to load data for testing.
You may have to change this as per the data at your site. You need to create and approve a PO for use with this script.
You run the asn.sql script in sqlplus which deletes old data from the interface tables and then calls testasn.sql which inserts the data into the interface tables.
This script inserts data into the RCV_HEADERS_INTERFACE and RCV_TRANSACTIONS_INTERFACE. This data is for a DELIVER transaction (TRANSACTION_TYPE ='RECEIVE' & AUTO_TRANSACT_CODE = 'DELIVER') -- DELIVER transaction
Other supported types are
(TRANSACTION_TYPE ='RECEIVE' & AUTO_TRANSACT_CODE = 'RECEIVE') -- RECEIVE transaction
(TRANSACTION_TYPE = 'SHIP' & AUTO_TRANSACT_CODE = 'SHIP'/'RECEIVE') -- SHIP or SHIP and RECEIVE transaction
*/
/* Start of asn.sql */
set serveroutput on;
set pages 999;
execute DBMS_OUTPUT.ENABLE (100000);
execute fnd_client_info.set_org_context ('129');
delete from rcv_transactions_interface where processing_mode_code = 'BATCH';
delete from rcv_headers_interface;
delete from po_interface_errors where interface_type in ('RCV-856', 'ASBN');
commit;
start testasn.sql;
/* end of asn.sql */
/* testasn.sql */
INSERT INTO RCV_HEADERS_INTERFACE
(
HEADER_INTERFACE_ID ,
GROUP_ID ,
PROCESSING_STATUS_CODE ,
RECEIPT_SOURCE_CODE ,
ASN_TYPE ,
TRANSACTION_TYPE ,
LAST_UPDATE_DATE ,
LAST_UPDATED_BY ,
LAST_UPDATE_LOGIN ,
CREATION_DATE ,
CREATED_BY ,
SHIPMENT_NUM ,
SHIPPED_DATE ,<
A:
We can check in the po_interface_errors for errors with shipment
numbers. As each ASN uses distinct shipment number, we can identify the error
for the shipment. We may get a very generic error message RCV_ASN_NOT_ACCEPT.
When we get the error message either there are a series of errors have occurred
which cannot be handled or an undetermined error has occurred. To handle
this kind of situation we have a script called runit.sql. This actually prints
debug messages as the pre-processor process the interface records. We can
also run the Receiving Interface report. This report shows you what warnings
or errors occurred while the Receiving Transaction Processor was processing
rows in the Receiving Open Interface tables. Rows processed in the Receiving
Open Interface include Advance Shipment Notices (ASNs), receipts, and deliveries.
Any errors that occur during this process are displayed in the Receiving
Interface Errors report when you run the report. At the same time, the errors
are also sent to the Oracle e–Commerce Gateway process responsible for generating
Application Advices. (For example, Application Advices are sent back to suppliers
detailing errors that occurred when the suppliers sent ASNs.)
A sample of runit.sql is available at the following link: http://www-apps.us.oracle.com/po/support
For R11i we have a profile option PO: Enable sql Trace on for Receiving,
which actually prints the debug messages of runit.sql in the log file.
Q5. What are the profile options available
for ASN?
A:
The profile option available for ASN is RCV: Fail All ASN
Lines if One Line Fails. When this profile option is set to ‘YES’, when multiple
lines are being processed, even if one line fails validations or errors,
the valid lines also error out.
A:
In R107, ASN is a controlled production, which means only
customers in the controlledproduction list can use ASN. In R11 and R11i,
it is available for all customers.
How to Automatically Generate Receipts for Drop Shipments with Advanced Shipment Notices (ASN's) (Doc ID 286996.1)
How To Add New Shipment Line To Existing ASN? (Doc ID 949604.1)
How To Create ASN And ASBN - Demo Using Viewlets (Doc ID 788938.1)
What Is The Functionality Of Cancel/Change Quantity Of An Advanced
Shipment Notice (ASN) That Has Been Received Or Returned? (DocID 465686.1)
Is There A Way To View The Cancelled ASN's ? (Doc ID 829173.1)
How Can The ASN Preview Page Be Personalized To Show The Item Number (Doc ID 795534.1)
When Creating ASN, User Can Reuse S/N, If The RCV Transactions Processor Is Not Run Yet. (DocID 810064.1)
How to Return or Cancel Item After ASN Is Created. (Doc ID 797935.1)
Is it Possible To Enter ASN From Internal View Responsibility (DocID 375209.1)
How Can The ASN or ASBN Transaction Be Saved For Future Data Entry? (DocID 782755.1)
11.5.10 / R12 ROI How To Create ASN / Perform Receipt For ASN Already Created Via ROI [ID 549609.1]
Related documents and References
Information About Advance Shipment Notices (ASN) Functionality [ID 601787.1]
11.5.10 / R12 ROI How To Create ASN / Perform Receipt For ASN Already Created Via ROI [ID 549609.1]
PO Receipt or ASN Transaction Fails with: RVTTH-115f: Subroutine process_transaction() returned error (Doc ID 301701.1)
PO Status Affects Receiving Transactions (Receive, Deliver, Correct, Return, ASN) For In-Process or Incomplete PO or APP-PO-14094 Errors When Receiving (Doc ID 551232.1)
Unable To Express Receipt Advanced Shipping Notice (ASN) Shipment for a Serial Controlled Item in Mobile Supply Chain Application (MSCA) (Doc ID 1146903.1)
Receiving a 'T-Type' Advanced Shipment Notice (ASN) Container Having Mixed SKU's Causes Data Corruption in Retail Merchandising System (RMS) (Doc ID 1106933.1)
NO ORANIZATION ID INSERTED IN RTI FOR ASN, Error RCV_INVALID_ROI_VALUE_NE (Doc ID 1115573.1)
