SCM RCV ExternalServices-Version 2

Fusion Receiving
External Web Services

1. Introduction ..........................................................................................................................................6
1.1 List of External Services in Fusion Receiving ...........................................................................6
2. Receiving Open Interface Version 2 ...................................................................................................7
2.1 Functional Overview ..................................................................................................................8

2.1.1 Supported Transaction Features ............................................................................................................... 8
2.2 Service Operations .....................................................................................................................9
2.2.1 processor (asynchronous version: processorAsync)................................................................................. 9
2.2.1 interfaceTransactions (asynchronous version: interfaceTrasnactionsAsync) ........................................... 9
2.3 Components of the input payload ..............................................................................................9
2.4 Sample Input Payloads .............................................................................................................10

2.4.1 Standard Receipt against a Purchase Order to receiving destination ..................................................... 10
2.4.2 Direct receipt against a Purchase Order to Inventory destination .......................................................... 11
2.4.1 Direct receipt against a Purchase Order to Expense destination ............................................................ 11
2.4.2 Receive against a fixed price service purchase order line ...................................................................... 12
2.4.3 DELIVER transaction for a standard routing receipt for an inventory destination ................................ 13
2.4.4 DELIVER transaction for standard routing Purchase Order with lot and serials ................................... 14
2.4.5 Correction (Negative) for a direct routing receipt to negate receipt....................................................... 15
2.4.6 Correction (Positive) for a direct routing receipt to add quantities ........................................................ 15
2.4.7 RETURN TO VENDOR against a Purchase Order ............................................................................... 16
2.4.8 Receipt against an In-transit Shipment................................................................................................... 17
2.4.9 Receipt against a Transfer Order Inbound Shipment ............................................................................. 18
2.4.10 DELIVER against a transfer order shipment ......................................................................................... 19
2.4.11 Create ASN against a PO ....................................................................................................................... 20
2.4.12 Create ASBN against a PO .................................................................................................................... 20
2.4.13 Create Receipt against ASN ................................................................................................................... 21
2.4.14 Create Receipt against RMA – Direct Routing ...................................................................................... 22
2.5 Sample Output Response of Receiving Open Interface Version 2 ..........................................23
2.5.1 Sample response if processing is successful .......................................................................................... 23
2.5.2 Sample response when there are processing errors ................................................................................ 24
3. Receipt Advice Version 2...................................................................................................................25
3.1 Overview ..................................................................................................................................25
3.2 Service Operations ...................................................................................................................25

3.2.1 processReceiptAdvice ............................................................................................................................ 25
3.2.2 interfaceReceiptAdvice .......................................................................................................................... 25
3.3 Components of input payload ..................................................................................................25
3.4 Information on ActionCode attribute (Receipt Advice header) ...............................................26

3.5.1 Create RMA Receipt Advice ................................................................................................................. 26
3.5.2 Update RMA Receipt Advice ................................................................................................................ 27
3.6 Sample Output response of Receipt Advice Version 2. ...........................................................28
4. Process Staged Receiving Transactions Group Version 2..............................................................29
4.1 Service Operation.....................................................................................................................29

4.1.1 processTransactionsForGroup................................................................................................................ 29
4.3 Sample Input Payload ..............................................................................................................29

4.3.1 Process Staged Receiving Transactions ................................................................................................. 29
4.4 Sample response if processing is successful ............................................................................29
5. Receipt Details ....................................................................................................................................30
5.1 Overview ..................................................................................................................................30

5.2.1 FindReceipt ............................................................................................................................................ 30
5.3 Components of response payload ............................................................................................30

5.5.1 Search using receipt number and receiving organization ....................................................................... 32
5.5.2 Search for a particular receipt line using receipt number and item ........................................................ 32
5.6 Sample Output Response of Receipt Details ...........................................................................33
6. Receiving Transaction Details ..........................................................................................................38

6.1.1 FindTransaction ..................................................................................................................................... 38

6.4.1 Search DELIVER transactions for a receipt using ReceiptId ................................................................ 39
6.4.2 Find details of a child transaction given the parent transaction ............................................................. 40
6.4.3 Find all transactions for a given root RECEIVE Transaction Id ............................................................ 41
6.5 Sample Output Response of Receiving Transaction Details ...................................................41
7. Inbound Shipment Details.................................................................................................................46
7.1 Overview ..................................................................................................................................46

7.2.1 FindShipment ......................................................................................................................................... 46

7.5.1 Search using shipment number and receiving organization ................................................................... 47
7.5.2 Search for a particular shipment line using shipment number and item................................................. 48
7.6 Sample Output Response of Inbound Shipment Details ..........................................................49
8. Send Receipt Advice ..........................................................................................................................54
8.1 Overview ..................................................................................................................................54

8.2.1 getReceiptAdviceDetails ........................................................................................................................ 55
8.3 Components of Input Payload ..................................................................................................55
8.4 Components of Response Payload ...........................................................................................56

8.5.1 Search for expected shipments using Purchase Order Header and Line ................................................ 58
8.5.2 Search expected shipments due today and next three days for a supplier .............................................. 58
8.5.3 Search expected shipments due today for an item and all document types ............................................ 59
8.5.4 Search expected shipments due today for all document types ............................................................... 59
8.5.5 Search expected shipments for a Transfer Order number ...................................................................... 59
8.5.6 Re-send receipt advice for a Purchase Order ......................................................................................... 60
8.6 Sample Output Response of Send Receipt Advice ..................................................................60
8.6.1 Receipt Advice response with expected shipments for a Purchase Order .............................................. 60
8.6.1 Receipt Advice response for in-transit shipment with lot and serials .................................................... 62
9. Receive Receipt Confirmation ..........................................................................................................66
9.1 Overview ..................................................................................................................................66

9.2.1 processReceiptConfirmations ................................................................................................................ 66
9.5 Components of Response Payload ...........................................................................................68

9.6.1 Receipt Confirmations for a Purchase Order ......................................................................................... 69
9.6.2 Receipt Confirmation for In-transit Shipment........................................................................................ 69
9.6.3 Receipt Confirmation for a Transfer Order Shipment ............................................................................ 70
9.6.4 Receipt confirmation for RMA .............................................................................................................. 71
9.6.5 Receipt Confirmation with all transactions interfaced from EP ............................................................. 72
9.1 Sample Output Response of Receive Receipt Confirmation Service ......................................74
9.1.1 Sample response when receipt confirmation is interfaced successfully ................................................. 74
1. Introduction
This document is intended to list down the external web services that are provided by Oracle Fusion Receiving as of fusion
applications release 11.1.11.0.0. It also provides sample payloads for invoking these web services.
1.1 List of External Services in Fusion Receiving

As of Fusion applications version 11.1.11.0.0, the following web services are available and
categorized as external
 Receiving Open Interface Version 2

o Used to process and validate the receipt data from various sources other than
Receipts User interface in Oracle Fusion Receiving. These sources include
transactions from other Oracle applications or legacy systems, or Advance
Shipment Notices (ASNs) from suppliers
 Receipt Advice Version 2
o A process to create, update, or cancel receipt advices, or to interface receipt advice

(e.g. for a Return Material Authorization) information for future processing
 Process Staged Receiving Transactions Group Version 2
o Processes pending or unprocessed receiving transactions for a given transaction

group identifier provided as input
 Receipt Details
o Services that provides the information regarding a receiving receipt - receipt

header, lines, transactions and lot and/or serial numbers transacted
 Receiving Transaction Details
o Service that provides the information about the receiving transactions performed
after creation of a receipt, such as deliver, returns and corrections
 Inbound Shipment Details
o Service to get the inbound shipment details
 Send Receipt Advice
o Process to retrieve expected shipment lines that need to be interfaced
 Receive Receipt Confirmation
o Process to receive confirmations on expected shipment lines

2. Receiving Open Interface Version 2
Receiving Open Interface can be used to process and validate the receipt data from various sources other than Receipts User
interface in Oracle Fusion Receiving. These sources include
 Receipt information from other Oracle applications or legacy systems
 Advance Shipment Notices (ASNs) from suppliers
Receiving Open Interface maintains the integrity of the new data as well as the receipt data that resides in Oracle Fusion Receiving.
The following table identifies the supported transactions in Oracle Fusion Receiving:
Receiving Interface Supported Transactions
Transaction ASN-PO In-transit RMA TRANSFER ORDER

Shipment
RECEIVE Yes Yes Yes Yes
TRANSFER Yes Yes Yes Yes
ACCEPT/REJECT Yes Yes Yes Yes
DELIVER to Yes Yes Yes Yes

Inventory
DELIVER to Yes NA NA NA
Expense
RETURN TO Yes No NA No
RECEIVING
RETURN TO Yes No NA NA
VENDOR
RETURN TO NA No Yes NA
CUSTOMER
+ CORRECT to Yes Yes No Yes
RECEIVE
- CORRECT to Yes Yes Yes Yes
RECEIVE
CORRECT to Yes Yes Yes Yes
TRANSFER
CORRECT to Yes Yes Yes Yes
ACCEPT/REJECT
Transaction ASN-PO In-transit RMA TRANSFER ORDER

Shipment
CORRECT to Yes No No No
DELIVER to
Inventory
CORRECT to Yes NA NA NA
DELIVER to
Expense
CORRECT to No NA NA NA
RETURN TO
RECEIVING
CORRECT to Yes NA NA NA
RETURN TO
VENDOR
CORRECT to NA NA Yes NA
RETURN TO
CUSTOMER
RETURN TO NA NA NA Yes
ORGANIZATION
Note: The Receiving Open Interface does not support corrections to returns for global procurement
transactions, nor does it support corrections for drop shipments that use transaction flows for accounting.
The Receiving Open Interface does not support:

 Corrections to return to receiving
 Correction to deliver except when the source document is ASN or Purchase Order
 Positive Corrections against Return Material Authorization
 Returns or corrections against in-transit shipment
 Unordered receipts and matching to unordered receipts
 Additions to receipt transactions
2.1 Functional Overview

Within the Receiving Open Interface, receipt data is validated for compatibility with Oracle Fusion Receiving. There are two
Receiving Open Interface tables: RCV_HEADERS_INTERFACE and RCV_TRANSACTIONS_INTERFACE.
2.1.1 Supported Transaction Features

The Receiving Open interface supports creation of ASN receipts, deliveries returns to vendor,
returns to customers, corrections, and transfers. The Receiving Open Interface supports all of
these transactions for all source documents including purchase orders, RMAs and in-transit
shipment. The Receiving Open Interface does not support unordered receipts or any transactions
for unordered receipts. The Receiving Open Interface supports these features:
 Receiving subinventory and locator: You can identify the receiving location,
receiving subinventory, and receiving locator in the Receiving Open Interface. You can
enter the subinventory, locator, or locator_id for receive, transfer, and return to vendor
from receipt transactions, and the system transfers this information to other
transactions. In the subsequent transactions, the receiving subinventory becomes from
subinventory, and the receiving locator becomes the from locator.
 Parent-child transactions: The system can create multiple transactions at the same
time. For example, you can receive five units, deliver three units, and correct one unit
from the delivery by inserting all the transactions at the same time in the
rcv_transactions_interface. The columns source_transaction_num and
parent_source_transaction_num can be used to uniquely identify the individual
transaction rows and the parent-child relationship between transactions. For example,
the RECEIVE transaction can have the value of source_transaction_num as 10005, the
DELIVER transaction which is the child of the RECEIVE transaction will have the
value of source_transaction_num as 10006 and parent_source_transaction_num as
10005.
 Lot and serial: The Receiving Open Interface supports lot and serial-based delivery
transactions .You can define lot and serial information for lot or serial-controlled items
on all receiving transactions that you import through the Receiving Open Interface.
These transactions include: receipts, transfers, inspections, deliveries, returns, and
corrections. When you receive an item, lot and serial information is optional, but upon
delivery, lot and serial information is required. However, if you specified lot and serial
information on previous
transaction then the system requires that you enter this information on all subsequent
transactions.
 Lot support: Multiple rows can exist in the inv_transaction_lots_interface for
each row in the rcv_transactions_interface. One row must exist for each lot
number in the inv_transaction_lots_interface (itli) where itli.product_transacton_id =
rti.interface_transaction_id and itli.product_code=’RCV’
 Serial Support: Multiple rows can exist in the inv_serial_numbers_interface for

each row in the rcv_transactions_interface if the
inv_serial_numbers_interface.product_transaction_id =
rti.interface_transaction_id or if the isni.transaction_interface_id =
itli.serial_transaction_temp_id if the item is lot and serial controlled.
2.2 Service Operations

The URL for receiving open interface Version 2 service is http://<server-name>:<port-
number>/rcvProcessor/ProcessorServiceV2. This service has two operations:
2.2.1 processor (asynchronous version: processorAsync)
The operation and its asynchronous equivalent accept the interface data from input payload. The
payload is first loaded to receiving interface tables (rcv_transactions_interface,
rcv_headers_interface, inv_transaction_lots_interface, inv_serial_numbers_interface and
inv_lpn_interface). Once the tables are populated, it automatically invokes the receiving transaction
manager to pick up the interface records that have been staged and process these interface records.
The receiving transaction manager will create the necessary transactions and then return the status
back to the service, which in turns sets the response back to the caller.
2.2.1 interfaceTransactions (asynchronous version:

interfaceTrasnactionsAsync)
The operation and its asynchronous equivalent accept the interface data from input payload. The
payload is first loaded to receiving interface tables (rcv_transactions_interface,
rcv_headers_interface, inv_transaction_lots_interface, inv_serial_numbers_interface and
inv_lpn_interface. This operation does not process these interface records and returns the status back
to the caller whether the interface records have been inserted successfully.
2.3 Components of the input payload

The input payload for the service maps to the following interface tables:
 ns1:Receipt – Maps to staged receiving header interface and stores the receipt header and
inbound shipment header information. Data populated here is transferred to
rcv_headers_interface. Upon processing, the receipt header information is stored in
rcv_shipment_headers.
 ns2:StagedReceivingTransaction – Maps to staged receiving header interface and stores the

receipt line/receiving transaction information as well as inbound shipment line information
(when creating ASN). Data populated here is transferred to rcv_transactions_interface.
Upon processing, this interface lines are stored in two different tables – rcv_shipment_lines,
that stores the receipt line information, and rcv_transactions, that stores the individual
transactions created.
 ns2:StagedTransactionLot – Maps to staged lots for an item that is only lot controlled and
not serial controlled. Stores the lots to be transacted against the line stored in
ns2:StagedReceivingTransaction. Data populated here is transferred to
inv_transaction_lots_interface.
 ns2:StagedTransactionSerial – Maps to staged serials for an item that is only serial
controlled and not lot controlled. Stores the serials to be transacted against the line stored in
 ns2:StagedLotSerialItemLot – Maps to staged lots for an item that is both lot controlled and
serial controlled. Stores the lots to be transacted against the line stored in
 ns2:StagedLotSerialItemSerial – Maps to staged serials for an item that is both serial

controlled and lot controlled. Stores the serials to be transacted for a given lot for a lot
controlled item, the lots containing these serials will be part of the node
ns2:StagedLotSerialItemLot. Data populated here is transferred to
2.4 Sample Input Payloads
2.4.1 Standard Receipt against a Purchase Order to receiving destination

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:processor
xmlns:ns1="http://xmlns.oracle.com/apps/scm/receiving/receiptsInterface/transactio
ns/processorServiceV2/types/">
<ns1:Receipt
xmlns:ns2="http://xmlns.oracle.com/apps/scm/receiving/receiptsInterface/transactio
ns/processorServiceV2/">
<ns2:TransactionType>NEW</ns2:TransactionType>
<ns2:ASNType>STD</ns2:ASNType>
<ns2:ReceiptSourceCode>VENDOR</ns2:ReceiptSourceCode>
<ns2:ShipToOrganizationCode>M1</ns2:ShipToOrganizationCode>
<ns2:VendorName>Advanced Network Devices</ns2:VendorName>
<ns2:VendorSiteCode>FRESNO</ns2:VendorSiteCode>
<ns2:BusinessUnit>Vision Operations</ns2:BusinessUnit>
<ns2:EmployeeName>Stock Pat</ns2:EmployeeName>
<ns2:StagedReceivingTransaction>
<ns2:SourceDocumentCode>PO</ns2:SourceDocumentCode>
<ns2:TransactionType>RECEIVE</ns2:TransactionType>
<ns2:AutoTransactCode>RECEIVE</ns2:AutoTransactCode>
<ns2:ToOrganizationCode>M1</ns2:ToOrganizationCode>
<ns2:TransactionDate>2015-05-11T00:00:00.000</ns2:TransactionDate>
<ns2:DocumentNumber>1000125</ns2:DocumentNumber>
<ns2:DocumentLineNumber>1</ns2:DocumentLineNumber>
<ns2:DocumentShipmentLineNumber>1</ns2:DocumentShipmentLineNumber>
<ns2:ItemNumber>RCV-100</ns2:ItemNumber>
<ns2:Quantity unitCode="">1</ns2:Quantity>
<ns2:UnitOfMeasure>Each</ns2:UnitOfMeasure>
<ns2:SoldtoLegalEntity>Vision Operations</ns2:SoldtoLegalEntity>
</ns2:StagedReceivingTransaction>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.2 Direct receipt against a Purchase Order to Inventory destination
To create a direct receipt against a receiving document, you should populate the attribute
ns:AutoTransactCode value to DELIVER. If this is an inventory destination, you should specify the
inventory destination subinventory and locator as shown below in the payload sample. If item
transaction default subinventory and/or locators have been setup, you can leave the subinventory and
locator attributes blank, in which case, the receiving transaction manager will derive the default
subinventory and/or locator.
<soap:Body>
<ns1:processor
xmlns:ns1="http://xmlns.oracle.com/apps/scm/receiving/receiptsInterface/transactions/pro
cessorServiceV2/types/">
<ns1:Receipt
cessorServiceV2/">
<ns2:AutoTransactCode>DELIVER</ns2:AutoTransactCode>
<ns2:Subinventory>ABCSUB</ns2:Subinventory>
<ns2:Locator>ABC1.1.1</ns2:Locator>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.1 Direct receipt against a Purchase Order to Expense

destination
To create a direct receipt against a receiving document, you should populate the attribute
ns:AutoTransactCode value to DELIVER. When delivering a line with expense destination, deliver
to location is mandatory. This can be specified using the attributes ns2:DeliverToLocationCode or
ns2:DeliverToLocationId in the <ns2:StagedReceivingTransaction> part of the payload. However, if
you leave these attributes blank, then deliver to location is automatically derived from the document.
So, this is completely optional and populate DeliverToLocationCode/Id only if you want to override
the value that was specified on the document.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:ItemDescription>EXPENSE-DEST-ITEM</ns2:ItemDescription>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.2 Receive against a fixed price service purchase order line
For creating receipts against a fixed price service lines, then you need to populate the attribute
ns2:Amount in the payload (ns2:StagedReecivingTransaction). CurrencyCode is optional and need
not be specified, since it is derived from the purchase order. Quantity and UnitOfMeasure are not
applicable and should not be populated for receiving against fixed price service lines.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:Amount currencyCode="USD">100</ns2:Amount>
<ns2:ItemDescription>Calendars</ns2:ItemNumber>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.3 DELIVER transaction for a standard routing receipt for an inventory

destination
All transactions that occur after receipt creation need the parent transaction reference to be specified.
The transaction types ACCEPT, REJECT, TRANSFER, CORRECT, RETURN TO VENDOR,
RETURN TO RECEIVING, RETURN TO CUSTOMER, RETURN TO ORGANIZATION all need
the parent transaction reference to be populated. And these all transactions should not have the
header information populated. The parent transaction information can be specified through either of
these attributes
o ParentTransactionId - This column is the unique identifier of the parent receiving

transaction and maps to RCV_transactions.transaction_id
o ParentSourceTransactionNumber - Can be alternatively used to uniquely identify the

individual transaction rows. For example, the RECEIVE transaction can have the value
of source_transaction_num as 10005, the DELIVER transaction which is the child of
the RECEIVE transaction will have the value of source_transaction_num as 10006 and
parent_source_transaction_num as 10005.
o SourceTransactionNumber should be unique in the system and these columns are

applicable only for legacy system interface. Otherwise, parent_transaction_id is
sufficient.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:TransactionType>DELIVER</ns2:TransactionType>
<ns2:ParentTransactionId>3048409</ns2:ParentTransactionId>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.4 DELIVER transaction for standard routing Purchase Order with lot and
serials
This sample payload is for an item that is both lot and serial controlled. This also assumes that the
user created a RECEIVE transaction with SourceTransactionNumber as “TXN-31”.
SourceTransactionNumber of the RECEIVE transaction will become the
ParentSourceTransactionNumber for the DELIVER transaction. As mentioned before,
SourceTransactionNumber and ParentSourceTransactionNumber must be unique and there cannot be
duplicate values provided.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:SourceTransactionNumber>TXN-32</ns2:SourceTransactionNumber>
<ns2:ParentSourceTransactionNumber>TXN-
31</ns2:ParentSourceTransactionNumber>
<ns2:ItemNumber>VC110</ns2:ItemNumber>
<ns2:StagedLotSerialItemLot>
<ns2:LotExpirationDate></ns2:LotExpirationDate>
<ns2:LotNumber>RKRCV090115-L8</ns2:LotNumber>
<ns2:ParentLotNumber></ns2:ParentLotNumber>
<ns2:TransactionQuantity unitCode="">2</ns2:TransactionQuantity>
<ns2:StagedLotSerialItemSerial>
<ns2:FmSerialNumber>RKRCV090115-S16</ns2:FmSerialNumber>
<ns2:ToSerialNumber>RKRCV090115-S17</ns2:ToSerialNumber>
</ns2:StagedLotSerialItemSerial>
</ns2:StagedLotSerialItemLot>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.5 Correction (Negative) for a direct routing receipt to negate receipt
The use case here is that PO 1000066 has direct routing. A receipt is created against this PO, which
creates two transactions. Transaction Id 3086396 corresponds to the RECEIVE transaction and
3086397, the DELIVER transaction. Both transactions are created during direct receipt. Now, if you
need to negate the entire receipt, you must correct both the DELIVER and RECEIVE transactions.
For negative corrections, you must correct the DELIVER transaction first and the RECEIVE
transaction next. Both the corrections are posted in the same service invocation. And so, each
correction becomes a separate node of ns2:StagedReceivingTransaction in the payload.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:TransactionType>CORRECT</ns2:TransactionType>
<ns2:ToOrganizationCode>V1</ns2:ToOrganizationCode>
<ns2:Quantity>-2</ns2:Quantity>
<ns2:Quantity>-2</ns2:Quantity>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.6 Correction (Positive) for a direct routing receipt to add quantities
The use case here is that PO 1000066 has direct routing. A receipt is created against this PO, which
creates two transactions. Transaction Id 3086396 corresponds to the RECEIVE transaction and
3086397, the DELIVER transaction. Both transactions are created during direct receipt. Now, if you
need to add to the received and delivered quantities, you must correct both the DELIVER and
RECEIVE transactions. For positive corrections, you must correct the RECEIVE transaction first and
the DELIVER transaction next. Both the corrections are posted in the same service invocation. And
so, each correction becomes a separate node of ns2:StagedReceivingTransaction in the payload.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:Quantity>2</ns2:Quantity>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.7 RETURN TO VENDOR against a Purchase Order
Use case here is that PO 1000066 is a direct routing PO which has been received into an expense
destination. Transaction Id 3086396 corresponds to the RECEIVE transaction and 3086397
corresponds to the DELIVER transaction. Now, we need to return the delivered material from
expense destination back to the supplier. So, we need to specify ParentTransactionId as that of the
DELIVER transaction and specify the transaction type (RETURN TO VENDOR) and the quantity to
be returned.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:TransactionType>RETURN TO VENDOR</ns2:TransactionType>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.8 Receipt against an In-transit Shipment
Creating a receipt against an in-transit shipment is similar to creating one against a purchase order.
The differences in the payload for an in-transit shipment are:
 ReceiptSourceCode – Will have the value INVENTORY – in both header and transaction part of
payload
 SourceDocumentCode – Will have the value INVENTORY – in transaction part of payload
 DocumentNumber – Will correspond to the in-transit shipment number – in transaction part of

payload
 DocumentLineNumber – Will correspond to the in-transit shipment line number – transaction

part of payload
 ShipmentNumber - In the header part of the payload (ns1:Receipt), we must specify the value for
ShipmentNumber to identify that this receipt is being created against that particular shipment.
So, the in-transit shipment number must be provided in both the header and transaction part of
the payload.
 ShipFromOrganizationCode – Organization where the material is shipped from. Normally is

optional. But must be specified if there is a possibility that the same shipment number is created
for a receiving organization for two shipments from different inventory organizations.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:ReceiptSourceCode>INVENTORY</ns2:ReceiptSourceCode>
<ns2:FromOrganizationCode>M1</ns2:FromOrganizationCode>
<<ns2:ShipmentNumber>23451245</ns2:ShipmentNumber>
<ns2:SourceDocumentCode>INVENTORY</ns2:SourceDocumentCode>
<ns2:Subinventory>Stores</ns2:Subinventory>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.9 Receipt against a Transfer Order Inbound Shipment
Creating a receipt against a transfer order inbound shipment is similar to creating one against a
purchase order. The differences in the payload for an in-transit shipment are:
 ReceiptSourceCode – Will have the value TRANSFER ORDER – in both header and transaction
part of payload
 SourceDocumentCode – Will have the value TRANSFER ORDER – in transaction part of

payload
 DocumentNumber – Will correspond to the transfer order shipment number – in transaction part
of payload.
o Note: There could be multiple inbound shipments created against the same transfer
order/transfer order line. Hence, receiving open interface accepts the transfer order
shipment as the document number. Transfer Order number will not be accepted as
document number.
 DocumentLineNumber – Will correspond to the in-transit shipment line number – transaction

part of payload
o Note: There could be multiple inbound shipments created against the same transfer
order/transfer order line. Hence, receiving open interface accepts the transfer order
shipment line number as the document line number. Transfer Order line number will
not be accepted as document line number.
 ShipmentNumber - In the header part of the payload (ns1:Receipt), we must specify the value for
ShipmentNumber to identify that this receipt is being created against that particular shipment.
So, the transfer order shipment number must be provided in both the header and transaction part
of the payload.
 ShipFromOrganizationCode – Organization where the material is shipped from. Normally is

optional. But must be specified if there is a possibility that the same shipment number is created
for a receiving organization for two shipments from different inventory organizations.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:ReceiptSourceCode>TRANSFER ORDER</ns2:ReceiptSourceCode>
<<ns2:ShipmentNumber>23451246</ns2:ShipmentNumber>
<ns2:SourceDocumentCode>TRANSFER ORDER</ns2:SourceDocumentCode>
<ns2:StagedTransactionLot>
<ns2:LotNumber>RKRCV090115-L8</ns2:LotNumber>
<ns2:ParentLotNumber></ns2:ParentLotNumber>
<ns2:TransactionQuantity unitCode="Ea">2</ns2:TransactionQuantity>
</ns2:StagedTransactionLot>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.10 DELIVER against a transfer order shipment
Use case is that transfer order 2376542 is shipped from organization M1 to M2 with standard receipt
routing. This shipment is received in org M2 and transaction Id 3048419 corresponds to the
RECEIVE transaction. The item is RCV-102 (line #3 of the shipment) which is serial controlled.
Serials SHP-SN-001 and SHP-SN-002 are shipped as part of this line. The payload below is to
deliver this receipt to subinventory Stores.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:StagedTransactionSerial>
<ns2:FmSerialNumber>SHP-SN-001</ns2:FmSerialNumber>
<ns2:ToSerialNumber>SHP-SN-002</ns2:ToSerialNumber>
</ns2:StagedTransactionSerial>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.11 Create ASN against a PO
The current use case is that PO 1000125 is created with 5 lines. We need to interface an Advance
Shipment Notice (ASN) against this PO for line 1 (whose item is RCV-100) and schedule 1. The
shipped date of the ASN is current date and the expected receipt date is current date + 1. For creating
ASN, the ASNType in the Receipt part of the payload must be “ASN”. For creating ASBN, the
ASNType attribute must be “ASBN”. In StagedReceivingTransaction part of the payload,
TransactionType should be SHIP indicating that ASN is created. If the ASN has to be shipped and
not received automatically, then AutoTransactCode should be “SHIP”. If the ASN has to be shipped
and received and delivered to inventory automatically, then AutoTransactCode should be DELIVER.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:ASNType>ASN</ns2:ASNType>
<ns2:ShipmentNumber>ASN-1000125-1</ns2:ShipmentNumber>
<ns2:ShippedDate>2016-08-29T00:00:00.000</ns2:ShippedDate>
<ns2:ExpectedReceiptDate>2016-08-30T00:00:00.000</ns2:ExpectedReceiptDate>
<ns2:BillOfLading>BOL1</ns2:BillOfLading>
<ns2:WaybillAirbillNumber>WAYBILL1</ns2:WaybillAirbillNumber>
<ns2:EmployeeName>Patric</ns2:EmployeeName>
<ns2:TransactionType>SHIP</ns2:TransactionType>
<ns2:AutoTransactCode>SHIP</ns2:AutoTransactCode>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.12 Create ASBN against a PO
The current use case is that PO 1000125 is created with 5 lines. We need to interface an Advance
Shipment Billing Notice (ASBN) against this PO for line 1 (whose item is RCV-100) and schedule 1.
An ASBN not only creates the shipment but also creates the invoice for the supplier automatically.
The shipped date of the ASN is current date and the expected receipt date is current date + 1. For
creating ASN, the ASNType in the Receipt part of the payload must be “ASN”. For creating ASBN,
the ASNType attribute must be “ASBN”. In StagedReceivingTransaction part of the payload,
TransactionType should be SHIP indicating that ASN is created. If the ASN has to be shipped and
not received automatically, then AutoTransactCode should be “SHIP”. If the ASN has to be shipped
and received and delivered to inventory automatically, then AutoTransactCode should be DELIVER.
For creating ASBN, the following additional columns must be mandatorily provided in the Receipt
part of the payload:
InvoiceNumber, InvoiceAmount,InvoiceDate,
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:ASNType>ASBN</ns2:ASNType>
<ns2:ShipmentNumber>ABSN-1000125-1</ns2:ShipmentNumber>
<ns2:BillOfLading>BOL1</ns2:BillOfLading>
<ns2:WaybillAirbillNumber>WAYBILL1</ns2:WaybillAirbillNumber>
<ns2:InvoiceNumber>ASBNINV-1000125-1</ns2:InvoiceNumber>
<ns2:InvoiceDate>2016-08-29T00:00:00.000</ns2:InvoiceDate>
<ns2:InvoiceAmount>6</ns2:InvoiceAmount>
<ns2:TransactionType>SHIP</ns2:TransactionType>
<ns2:AutoTransactCode>SHIP</ns2:AutoTransactCode>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.13 Create Receipt against ASN
To create receipt against the ASN, it is important to provide both the PO information as well as the
ASN information in the payload. Consider the use case where ASN “ASN-1000125-1” has been
created for PO 1000125, PO line 1, PO schedule 1. In the Receipt part of the payload, we need to
provide a reference to the ASN. This is done through the attribute ShipmentNumber. By providing
ShipmentNumber as “ASN-1000125-1” we state that we are attempting to map the receipt header to
this ASN so that the receipt is updated on the ASN header that was already created. In the
StagedReceivingTransaction part of the payload, we must provide the PO as well as ASN reference.
The PO number is provided in DocumentNumber, PO line is provided in DocumentLineNumber, PO
schedule is provided in DocumentShipmentLineNumber. As mentioned above, we also need to
provide the ASN reference. The ASN number is provided through the attribute ShipmentNumber and
the ASN line number is provided through the attribute ASNLineNumber.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:AutoTransactCode>RECEIVE</ns2:AutoTransactCode>
<ns2:ASNLineNumber>1</ns2:ASNLineNumber>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.4.14 Create Receipt against RMA – Direct Routing
To receive a Return Material Authorization (RMA), the payload for the receiving open interface
version 2 web service is different from the other document types. The other document types use
DocumentNumber and DocumentLineNumber (to represent PO number/Line number or Transfer
Order Shipment Number/line number). But those attributes should not be used for RMA. Instead,
you should use the attribute RaDocumentNumber to represent the RMA number (return sales order
number) and RaDocumentLineNumber to represent the RMA line number (return sales order line
number). ReceiptSourceCode (in header and transaction portion of the payload) should have the
value “CUSTOMER”. If the routing is direct, ensure that the DestinationTypeCode should be
“INVENTORY” and if the routing is standard, ensure DestinationTypeCode is “RECEIVING”. The
SourceDocumentCode attribute in the transaction portion should have the value “RMA”. In order to
identify the unique identifier for the RMA header and RMA line, receiving needs one more attribute
– RaDooSourceSystemName in the header portion of the payload. If the RMA is created from Fusion
Order Management, then the value to be populated in the attribute RaDooSourceSystemId should be
“Oracle Fusion Order Orchestration And Planning”. If the RMA is created from other systems, the
source system will be available in the table HZ_ORIG_SYSTEMS. Here is the payload to create a
receipt against RMA when routing is direct and created from Fusion Order Management.
<soap:Body>
<ns1:processor
<ns1:Receipt
cessorServiceV2/">
<ns2:ReceiptSourceCode>CUSTOMER</ns2:ReceiptSourceCode>
<ns2:CustomerPartyName>Computer Services and Rentals</ns2:CustomerPartyName>
<ns2:EmployeeName>Oliver, Sam</ns2:EmployeeName>
<ns2:RaDooSourceSystemName>Oracle Fusion Order Orchestration And
Planning</ns2:RaDooSourceSystemName>
<ns2:SourceDocumentCode>RMA</ns2:SourceDocumentCode>
<ns2:DestinationTypeCode>INVENTORY</ns2:DestinationTypeCode>
<ns2:ItemNumber>AU11888</ns2:ItemNumber>
<ns2:RaDocumentNumber>UPCR-007-R10-3</ns2:RaDocumentNumber>
<ns2:RaDocumentLineNumber>1</ns2:RaDocumentLineNumber>
</ns1:Receipt>
</ns1:processor>
</soap:Body>
</soap:Envelope>
2.5 Sample Output Response of Receiving Open Interface Version 2
2.5.1 Sample response if processing is successful
If processing is successful, then the status attribute of the service response will have the value
SUCCESS.
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd" wsu:Id="Body-r33DG912se16itXGQE8xVg22">
<ns0:interfaceTransactionsResponse
<ns2:result xmlns:ns0="http://xmlns.oracle.com/adf/svc/types/"
cessorServiceV2/"
cessorServiceV2/types/" xmlns:tns="http://xmlns.oracle.com/adf/svc/errors/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns1:ProcessorResponseResult">
<ns1:Value>
<ns1:GroupId>44343</ns1:GroupId>
<ns1:Status>SUCCESS</ns1:Status>
</ns1:Value>
</ns2:result>
</ns0:interfaceTransactionsResponse>
</env:Body>
</env:Envelope>
2.5.2 Sample response when there are processing errors
If there are any errors during processing, the status of the response message will be WARNING.
More importantly, the error message information is sent as part of the response.
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:typ="http://xmlns.oracle.com/apps/scm/receiving/receiptsInterface/transactions/pro
<env:Body>
<ns0:processorResponse
<ns2:result xsi:type="ns1:ProcessorResponseResult"
cessorServiceV2/types/"
cessorServiceV2/" xmlns:tns="http://xmlns.oracle.com/adf/svc/errors/"
xmlns:ns0="http://xmlns.oracle.com/adf/svc/types/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:Value>
<ns1:Status>WARNING</ns1:Status>
<ns1:ReceivingInterfaceError>
<ns1:HeaderInterfaceId>34001</ns1:HeaderInterfaceId>
<ns1:TransactionInterfaceId>300000003294501</ns1:TransactionInterfaceId>
<ns1:ErrorType>ERROR</ns1:ErrorType>
<ns1:ErrorCode>RCV_RECEIPT_NUM_REQ</ns1:ErrorCode>
<ns1:ErrorMessage>You must enter a receipt number for this
transaction.</ns1:ErrorMessage>
<ns1:TableName>RCV_HEADERS_INTERFACE</ns1:TableName>
<ns1:ColumnName>RECEIPT_NUM</ns1:ColumnName>
</ns1:ReceivingInterfaceError>
</ns1:Value>
</ns2:result>
</ns0:processorResponse>
</env:Body>
</env:Envelope>
3. Receipt Advice Version 2
3.1 Overview
Receipt Advice web service provides a standard way for the source systems to communicate
information on material to be received through the Receiving Product. This is typically used to
communicate RMA (Return Material Authorization) documents from the source order
management/order capture system to Fusion Receiving. When this RMA is communicated through
this service, it will create a receipt advice against this document. And the user can search by the
RMA number in receiving UIs to create receipts and receiving transactions. Receiving transactions
against these RMA receipt advices can also be performed through Receiving Open Interface version
2 web service. This service exposes all the possible attributes to capture very detailed information
regarding the source document.

The URL for receiving open interface Version 2 service is http://<server-name>:<port-
number>/rcvInbound/FlexSupplyInboundServiceV2. This service provides two operations in both
synchronous and asynchronous modes, the operations being “processReceiptAdvice” and
“interfaceReceiptAdvice”.
3.2.1 processReceiptAdvice
This operation its asynchronous equivalent, not only pushes the input payload data into the receiving
open interface tables, but also triggers the transaction processor to process the receipt advices and
finally responds with the outcome of the processing to the caller.
3.2.2 interfaceReceiptAdvice
This operation and its asynchronous equivalent, only dumps the data in to receiving open interface
tables. This will not trigger receiving transaction manager and the pending receipt advices will have
to be processed later.
3.3 Components of input payload
 ns1:ReceiptAdvice – Maps to staged receipt advice header, and stores the attributes
pertaining to the receipt advice header and inbound shipment header information. Data
populated here is transferred to rcv_headers_interface. Upon processing, the receipt advice
is stored in rcv_shipment_headers.
 ns2: ReceiptAdviceLine – Maps to staged receipt advice line and stores the attributes
pertaining to the receipt advice line. Data populated here is transferred to
rcv_transactions_interface. Upon processing, the receipt advice line is stored in
rcv_shipment_lines.
 ns2: ReceiptAdviceLineLot– Maps to staged lots for an item that is only lot controlled and
not serial controlled. Stores the lots to be transacted against the line stored in
ns2:ReceiptAdviceLine. Data populated here is transferred to
inv_transaction_lots_interface. After processing, the receipt advice lots are stored in
rcv_lots_supply.
 ns2: ReceiptAdviceLineSerials – Maps to staged serials for an item that is only serial
controlled and not lot controlled. Stores the serials to be transacted against the line stored in
ns2: ReceiptAdviceLine. Data populated here is transferred to
inv_transaction_lots_interface. After processing, the receipt advice serials are stored in
rcv_serials_supply.
 ns2: ReceiptAdviceLineLotWithSerials – Maps to staged lots for an item that is both lot
controlled and serial controlled. Stores the lots to be transacted against the line stored in
inv_transaction_lots_interface. After processing, the receipt advice lots are stored in
rcv_lots_supply.
 ns2: ReceiptAdviceLineLotSerials – Maps to staged serials for an item that is both serial
controlled and lot controlled. Stores the serials to be transacted for a given lot for a lot
controlled item, the lots containing these serials will be part of the node
ns2:StagedLotSerialItemLot. Data populated here is transferred to
inv_transaction_lots_interface. After processing, the receipt advice serials are stored in
rcv_serials_supply.
3.4 Information on ActionCode attribute (Receipt Advice header)

There are three different operations that can be performed on a receipt advice – CREATE, UPDATE
and CANCEL. These operations are specified using the attribute ns2:ActionCode that is part of the
header (ns1:ReceiptAdvice) part of the input payload.
To create a new receipt advice, ns2:ActionCode must have the value “CREATE”
To update an existing receipt advice (e.g. increase the expected quantity to receive), ActionCode
must have the value UPDATE
To cancel an existing receipt advice (e.g. source system has canceled the original document),
ActionCode must have the value CANCEL. When you call the service with action code CANCEL,
you can cancel a single receipt advice line or an entire receipt advice
3.5.1 Create RMA Receipt Advice
This sample payload is used to create a RMA receipt advice. The RMA has one line. The RMA
number is RK120115_1 and RMA line number is 1. Receipt Advice Number is mandatory and must
be unique. There cannot be a repetition of receipt advice number for two different receipt advices.
Same is true for receipt advice line number. RMA Number maps to DocumentNumber that is part of
the header part of the payload. A receipt advice creates one header and can have multiple lines. The
RMA is to be received in org V1, and is for line item RCV-101, and lot number information is
provided on the RMA line. This lot number is the lot that has been returned against the original sales
order against which this RMA is created.
<soap:Body>
<ns1:processReceiptAdvice
xmlns:ns1="http://xmlns.oracle.com/apps/scm/receiving/receiptsInterface/flexSupply/inbou
ndServiceV2/types/">
<ns1:ReceiptAdvice
ndServiceV2/">
<ns2:SourceSystemId>100010026240309</ns2:SourceSystemId>
<ns2:ReceiptAdviceNumber>RK120115_1</ns2:ReceiptAdviceNumber>
<ns2:ActionCode>CREATE</ns2:ActionCode>
<ns2:SourceDocumentType>RMA</ns2:SourceDocumentType>
<ns2:DocumentNumber>RK120115_1</ns2:DocumentNumber>
<ns2:DocumentCreationDate>2015-01-12T13:10:29.0-
07:00</ns2:DocumentCreationDate>
<ns2:DocumentLastUpdateDate>2015-01-14T13:10:29.654-
07:00</ns2:DocumentLastUpdateDate>
<ns2:CustomerPartyName>Computer Service and
Rentals</ns2:CustomerPartyName>
<ns2:ReceiptAdviceLine>
<ns2:ReceiptAdviceLineNumber>100000023384847</ns2:ReceiptAdviceLineNumber>
<ns2:DocumentLineCreationDate>2015-01-14T13:10:29.026-
07:00</ns2:DocumentLineCreationDate>
<ns2:DocumentLineLastUpdateDate>2015-01-14T13:10:29.658-
07:00</ns2:DocumentLineLastUpdateDate>
<ns2:UOMCode>Ea</ns2:UOMCode>
<ns2:QuantityExpected>4</ns2:QuantityExpected>
<ns2:ExpectedReceiptDate>2015-01-14T12:53:51.0-
07:00</ns2:ExpectedReceiptDate>
<ns2:ShipToOrganizationCode>V1</ns2:ShipToOrganizationCode>
<ns2:TransactionDate>2015-01-14T12:53:51.0-
07:00</ns2:TransactionDate>
<ns2:ReceiptAdviceLineLot>
<ns2:LotNumber>Lot21</ns2:LotNumber>
<ns2:TransactionQuantity>4</ns2:TransactionQuantity>
</ns2:ReceiptAdviceLineLot>
</ns2:ReceiptAdviceLine>
</ns1:ReceiptAdvice>
</ns1:processReceiptAdvice>
</soap:Body>
</soap:Envelope>
3.5.2 Update RMA Receipt Advice
This sample payload is used to updating an existing RMA receipt advice. The RMA has one line.
The RMA number is RK120115_2 and RMA line number is 1. RMA Number maps to
DocumentNumber that is part of the header part of the payload. A receipt advice creates one header
and can have multiple lines. The RMA is to be received in org V1, and is for line item RCV-100. As
part of the update message, the expected quantity is being increased to 5 Each.
<soap:Body>
<ns1:processReceiptAdvice
<ns1:ReceiptAdvice
ndServiceV2/">
<ns2:SourceSystemId>100010026240309</ns2:SourceSystemId>
<ns2:SourceDocumentType>RMA</ns2:SourceDocumentType>
<ns2:DocumentNumber>RK120115_2</ns2:DocumentNumber>
<ns2:CustomerPartyName>Computer Service and
Rentals</ns2:CustomerPartyName>
<ns2:QuantityExpected>5</ns2:QuantityExpected>
<ns2:ShipToOrganizationCode>V1</ns2:ShipToOrganizationCode>
<ns2:TransactionDate>2015-01-14T12:53:51.0-
07:00</ns2:TransactionDate>
</ns1:processReceiptAdvice>
</soap:Body>
</soap:Envelope>
3.6 Sample Output response of Receipt Advice Version 2.

The sample response of the receipt advice version 2 service is pasted below for the case where
receipt advice is created successfully. If processing of the receipt advice is successful, then the
ResultCode attribute of the service response will have the value SUCCESS. In case of errors, the
ErrorCode and ErrorMessage attributes will contain error details
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd" wsu:Id="Body-1ojU4vMBpScnkIOBMPCRqQ22">
<ns0:processReceiptAdviceResponse
ndServiceV2/"
ndServiceV2/types/" xmlns:tns="http://xmlns.oracle.com/adf/svc/errors/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns1:ReceiptAdviceResponseResult">
<ns1:Value>
<ns1:MessageId>44391</ns1:MessageId>
<ns1:ProcessedReceiptAdvice>
<ns1:RequestType>CREATE</ns1:RequestType>
<ns1:ResultCode>SUCCESS</ns1:ResultCode>
<ns1:ErrorCode xsi:nil="true"/>
<ns1:ErrorMessage xsi:nil="true"/>
</ns1:ProcessedReceiptAdvice>
</ns1:Value>
</ns2:result>
</ns0:processReceiptAdviceResponse>
</env:Body>
</env:Envelope>
4. Process Staged Receiving Transactions Group Version 2
The process staged receiving transactions group version 2 web service provides the ability to process
previously receiving transactions that were previously interfaced to fusion receiving. The URL for
this service is
http://server:port/rcvProcessStagedTransactionGroup/ProcessStagedTransactionGroupServiceV2.
4.1 Service Operation
4.1.1 processTransactionsForGroup
This method and its asynchronous equivalent accept the group identifier supplied by the caller and
will invoke the Manage Receiving Transactions API with the provided group Id. And the manage
receiving transactions API will use this group Id to filter pending receiving interface records and
process them. After processing, the API returns back the status to the service which displays the
status as response.

The service operation has one input parameter ns1:groupId, which corresponds to the group Id that
the manage receiving transactions API uses to filter the pending receiving interface records.
4.3 Sample Input Payload
4.3.1 Process Staged Receiving Transactions

<soap:Body>
<ns1:processTransactionForGroup
cessStagedTransactionGroupServiceV2/types/">
<ns1:groupId>47907</ns1:groupId>
</ns1:processTransactionForGroup>
</soap:Body>
</soap:Envelope>
4.4 Sample response if processing is successful

If processing is successful, then the service returns status as SUCCESS and the processing message
as ONLINE PROCESSING SUCCESSFUL
<ns0:processTransactionForGroupResponse xmlns=""
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
cessStagedTransactionGroupServiceV2/types/"
xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<result
xmlns="http://xmlns.oracle.com/apps/scm/receiving/receiptsInterface/transactions/process
StagedTransactionGroupServiceV2/types/">SUCCESS</result>
<result
xmlns="http://xmlns.oracle.com/apps/scm/receiving/receiptsInterface/transactions/process
StagedTransactionGroupServiceV2/types/">ONLINE PROCESSING SUCCESSFUL</result>
</ns0:processTransactionForGroupResponse>
5. Receipt Details
5.1 Overview
The Receipt Details service is intended to fetch the information for a Receipt created in Fusion
Receiving. It fetches the receipt header, receipt lines for that header and the RECEIVE transactions
that were created against this receipt. It also provides the lot and serial numbers that were transacted
against each transaction. This service can be invoked in scenarios where an external system needs to
retrieve information regarding a receipt from fusion applications.

The URL for the Receipt Details service is http://<server-name>:<port-
number>/rcvReceivingTransaction/ReceiptService. This has one operation FindReceipt and its
asynchronous version FindReceiptAsync.
5.2.1 FindReceipt
The FindReceipt operation and its asynchronous equivalent constitute the standard find operation that
is provided by ADF BC web services. The find operation lets you query by the receipt number,
receipt identifier and will fetch the receipt details.
5.3 Components of response payload
 ns2:Result – This node represents the result of the find operation. The receipt details are tied
to this node of the response payload.
 ns1:ReceiptHeader – This node represents the receipt header. It contains attributes such as
receipt number, receiving organization, receipt source code and receipt Id etc.
 ns1:ReceiptLine – This node represents the receipt line and the receiving transaction. It
contains attributes such as receipt line number, item, quantity received against the
transaction etc.
 ns1:Lot – This node represents the lot numbers received against each RECEIVE transaction
for this receipt.
 ns1:Serial – This node represents the serial numbers received against each RECEIVE
transaction for this receipt. This node contains the serial numbers when the item is serial
controlled and not lot controlled.
 ns1:LotSerial – This node represents the serial numbers for a particular lot received against
each RECEIVE transaction for this receipt. This node contains the serial numbers when the
item is both serial controlled and lot controlled.
 ns1:RcvShpHdrDFFVA – This node represents the descriptive flexfield information

corresponding to the receipt header.
 ns1:ReceiptLinesRcvTxnDFFVA – This node represents the descriptive flexfield

information for each receive transaction created for this receipt.
 ns1:findReceipt – This is the top node for the input payload and all the search related
components are enclosed under this node. This is like a container for the whole input.
 ns1: findCriteria – This node represents the criteria that the GET service is invoked with.
You enter the attributes to search on, the search conditions and conjunctions between
individual search attributes.
 ns1:fetchStart – This element is used when the caller of the service is iterating through the
results sent by the customer. This element denotes the row number to fetch the details from.
This element and the fetchSize element is useful when there are a large number of rows that
are fetched by the service, and when the caller needs to limit the number of rows fetched at
one point in time and then iterate through the results.
 ns2:fetchSize – This element denotes the number of rows to fetch in each invocation.
 ns2:filter – This node is where you specify the filter criteria that you need to query the
service with.
 ns2:group – This node represents a group of attributes (one or more) that you need to pass as
inputs to the service, and filter the results on.
 ns2:conjunction – This element (which can be specified at a group level or item level), can
be used to specify the query conjunction. You can specify either “AND” or “OR” based on
how you want to construct the filter criteria.
 ns2:upperCaseCompare – This element denotes whether you want the search operation
should be case sensitive or not. Set to true if you want a case insensitive search.
 ns2:item – This node denotes an individual attribute to filter the service on. This is where
you enter the receipt number to search for.
 ns2:attribute – This element denotes the name of the attribute to filter with. When you want
to fetch results for receipt number, set this node as “ReceiptNumber”.
 n2:operator – Arithmetic operator (e.g. =, <, > etc.).
 ns2:value – This is where you enter the value that you want to search for. For instance, if
you want to search using receipt number 33550, the attribute element will have
“ReceiptNumber”, operator element will have “=” and value element will have “33550”.
 ns2:childFindCriteria – This node should be used to specify the filter criteria that need to be
applied on the child nodes of the service – i.e. ns2:ReceiptLine. For instance, you can use
this node to filter the receipt details service by ItemNumber RCV-100, and the service will
filter the child nodes.
 ns2:childAttributeName – This element will need to be used in conjunction with

ns2:childFindCriteria. Use this element to identify the child attribute against which you
apply the filter criteria as part of childFindCriteria. For instance, if you want to receipt lines
to be used, specify ReceiptLine in this node.
5.5.1 Search using receipt number and receiving organization
A Receipt in fusion applications is uniquely identified using Receipt number and the receiving
organization (ship to organization code). The sample payload below fetches the details for receipt
number 33550 and receiving organization code M1.
<soap:Body>
<ns1:findReceiptAsync
xmlns:ns1="http://xmlns.oracle.com/apps/scm/receiving/receipts/receivingTransaction/type
s/">
<ns1:findCriteria xmlns:ns2="http://xmlns.oracle.com/adf/svc/types/">
<ns2:fetchStart>0</ns2:fetchStart>
<ns2:fetchSize>10</ns2:fetchSize>
<ns2:filter>
<ns2:conjunction>And</ns2:conjunction>
<ns2:group>
<ns2:upperCaseCompare>false</ns2:upperCaseCompare>
<ns2:item>
<ns2:attribute>ReceiptNumber</ns2:attribute>
<ns2:operator>=</ns2:operator>
<ns2:value>33550</ns2:value>
</ns2:item>
<ns2:item>
<ns2:attribute>ShipToOrgCode</ns2:attribute>
<ns2:value>M1</ns2:value>
</ns2:item>
</ns2:group>
</ns2:filter>
<ns2:excludeAttribute>false</ns2:excludeAttribute>
</ns1:findCriteria>
<ns1:findControl xmlns:ns2="http://xmlns.oracle.com/adf/svc/types/">
<ns2:retrieveAllTranslations>true</ns2:retrieveAllTranslations>
</ns1:findControl>
</ns1:findReceiptAsync>
</soap:Body>
</soap:Envelope>
5.5.2 Search for a particular receipt line using receipt number and item
Consider receipt 33550 which has 5 lines and 5 receiving transactions created. If you want to fetch
the receipt line for the item RCV-100, then you should specify additional criteria for the receipt line
as part of the childFindCriteria node of the find operation. And you also should specify the child
attribute name (in this case ReceiptLine) to ensure that the filters are applied on the node
ns2:ReceiptLine.
<soap:Body>
<ns1:findReceiptAsync
s/">
<ns2:filter>
<ns2:group>
<ns2:item>
<ns2:attribute>ReceiptNumber</ns2:attribute>
</ns2:item>
<ns2:item>
</ns2:item>
</ns2:group>
</ns2:filter>
<ns2:childFindCriteria>
<ns2:filter>
<ns2:group>
<ns2:item>
<ns2:attribute>ItemNumber</ns2:attribute>
<ns2:value>RCV-100</ns2:value>
</ns2:item>
</ns2:group>
</ns2:filter>
<ns2:childAttrName>ReceiptLine</ns2:childAttrName>
</ns2:childFindCriteria>
</ns1:findCriteria>
</ns1:findControl>
</ns1:findReceiptAsync>
</soap:Body>
</soap:Envelope>
5.6 Sample Output Response of Receipt Details

This sample response payload has all elements of the receipt details service.
<ns0:findReceiptAsyncResponse xmlns=""
s/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-
xmlns:ns1="http://xmlns.oracle.com/apps/scm/receiving/receipts/receivingTransaction/"
s/"
xmlns:ns3="http://xmlns.oracle.com/apps/scm/receiving/common/protectedUiModel/flex/rcvSh
pHdr/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns1:ReceiptHeader">
<ns1:ShipmentHeaderId>2710285</ns1:ShipmentHeaderId>
<ns1:CreationDate>2010-01-08T00:40:21.0-08:00</ns1:CreationDate>
<ns1:OrganizationId xsi:nil="true"/>
<ns1:OrganizationCode xsi:nil="true"/>
<ns1:ShipmentNumber xsi:nil="true"/>
<ns1:ReceiptNumber>33550</ns1:ReceiptNumber>
<ns1:FreightCarrierId xsi:nil="true"/>
<ns1:ShipToOrgId>207</ns1:ShipToOrgId>
<ns1:ShipToOrgCode>M1</ns1:ShipToOrgCode>
<ns1:ReceiptLine
xmlns:ns2="http://xmlns.oracle.com/apps/scm/receiving/common/protectedUiModel/flex/rcvTx
n/">
<ns1:TransactionId>2958274</ns1:TransactionId>
<ns1:TransactionDate>2010-01-08T00:38:20.0-08:00</ns1:TransactionDate>
<ns1:ShipmentLineId>2790945</ns1:ShipmentLineId>
<ns1:LineNumber>1</ns1:LineNumber>
<ns1:Quantity unitCode="Ea"
xmlns:tns="http://xmlns.oracle.com/adf/svc/errors/">10</ns1:Quantity>
<ns1:Amount xsi:nil="true"/>
<ns1:CurrencyCode>USD</ns1:CurrencyCode>
<ns1:ItemDescription>LSR Item</ns1:ItemDescription>
<ns1:ItemId>663912</ns1:ItemId>
<ns1:ItemRevision>A</ns1:ItemRevision>
<ns1:DestinationTypeCode>RECEIVING</ns1:DestinationTypeCode>
<ns1:POHeaderId>100000012026081</ns1:POHeaderId>
<ns1:POLineId>100000012026195</ns1:POLineId>
<ns1:POLineLocationId>100000012026196</ns1:POLineLocationId>
<ns1:OrganizationId>207</ns1:OrganizationId>
<ns1:OrganizationCode>M1</ns1:OrganizationCode>
<ns1:SecondaryQuantity xsi:nil="true"/>
<ns1:SecondaryUOMCode xsi:nil="true"/>
<ns1:SecondaryUnitOfMeasure/>
<ns1:TransferOrderHeaderId xsi:nil="true"/>
<ns1:TransferOrderLineId xsi:nil="true"/>
<ns1:ConsignedTransaction xsi:nil="true"/>
<ns1:ReceiptAdviceLineNumber xsi:nil="true"/>
<ns1:SfoTransaction>N</ns1:SfoTransaction>
<ns1:DropShipTransaction>N</ns1:DropShipTransaction>
<ns1:ScoTransaction>N</ns1:ScoTransaction>
<ns1:WORelatedPOSchedule>N</ns1:WORelatedPOSchedule>
<ns1:BuyerManagedTransportation xsi:nil="true"/>
<ns1:InventoryShipmentTransactionId xsi:nil="true"/>
<ns1:OrigShipmentInvTransactionId xsi:nil="true"/>
<ns1:ReceiptCreatedAgainstASN xsi:nil="true"/>
<ns1:ReceiptLinesRcvTxnDFFVA>
<ns2:_Global__Segment xsi:nil="true"/>
<ns2:_zBIADFF1 xsi:nil="true"/>
<ns2:_BI_2DGlob_2DRT xsi:nil="true"/>
<ns2:__FLEX_Context xsi:nil="true"/>
<ns2:_FLEX_NumOfSegments>3</ns2:_FLEX_NumOfSegments>
</ns1:ReceiptLinesRcvTxnDFFVA>
</ns1:ReceiptLine>
<ns1:ReceiptLine
n/">
<ns1:ItemDescription>Serial @ Receipt Item</ns1:ItemDescription>
<ns1:ItemRevision xsi:nil="true"/>
</ns1:ReceiptLine>
<ns1:ReceiptLine
n/">
<ns1:ItemDescription>Lot Item</ns1:ItemDescription>
</ns1:ReceiptLine>
<ns1:ReceiptLine
n/">
<ns1:ItemDescription>Plain Item</ns1:ItemDescription>
</ns1:ReceiptLine>
<ns1:RcvShpHdrDFFVA>
<ns3:_BI_2DGlob_2DRH xsi:nil="true"/>
</ns1:RcvShpHdrDFFVA>
</ns2:result>
</ns0:findReceiptAsyncResponse>
6. Receiving Transaction Details
The Receipt Details service fetches the details for a receipt and consists of the header, line and the
RECEIVE transaction corresponding to a receipt line. Once a line is received, all subsequent
transactions – inspection, delivery, corrections and returns – follow a parent-child hierarchy. For
example you have received 5 Each against a PO schedule, accepted 5, delivered 5 and returned 5.
The receive transaction becomes the parent transaction for accept transaction. You can accept the
material by providing reference to the receive transaction and the transaction_id of the RECEIVE
transaction becomes the parent_transaction_id of the ACCEPT transaction. And when you deliver,
the transaction_id of the ACCEPT transaction becomes the parent_transaction_id for the DELIVER
transaction. On the same lines, transaction_id of the DELIVER transaction acts as
parent_transaction_id for RETURN TO VENDOR transaction.
Now, in order to find out all child transactions for a RECEIVE transaction or ACCEPT transaction,
you can use the receiving transaction details service. For instance, you need to call receiving open
interface version 2 service to correct both receive and deliver transaction. You can first call the
receipt details service passing the receipt number and you will get the transaction_id of the
RECEIVE transaction. And then you call the receiving transaction details service by passing
transaction_id of the RECEIVE transaction and get the DELIVER transaction_id.

The URL for the Receiving Transaction Details service is http://<server-name>:<port-
number>/rcvReceivingTransaction/ReceivingTransactionService. This has one operation
FindTransaction and its asynchronous version FindTransactionAsync.
6.1.1 FindTransaction
The FindTransaction operation and its asynchronous equivalent constitute the standard find operation
that is provided by ADF BC web services. The find operation lets you query by different attributes
such as receipt Id (ShipmentHeaderId), parent transaction Id, transaction type (find all DELIVER
transactions for a receipt or find all return to supplier transactions for a receipt). You can also use this
to find all child transactions for a root transaction of type RECEIVE.
 ns1:ReceivingTransaction – This node represents the receiving transaction. It contains

attributes such as transaction Id, transaction type, item, transaction quantity, parent
transaction Id, parent transaction type, root receiving transaction Id (which is the first
RECEIVE transaction that was created for each transaction).
 ns1: RcvTxnDFFVA – This node represents the descriptive flexfield information for each
receiving transaction.
 ns1:findTransaction – This is the top node for the input payload and all the search related
service with.
how you want to construct the filter criteria
should be case sensitive or not. Set to true if you want a case insensitive search
you enter the receipt number to search for.
to fetch results for receipt number, set this node as “ReceiptNumber”
 n2:operator – Arithmetic operator (e.g. =, <, > etc.)
you want to search using receipt number 33550, the attribute element will have
“ReceiptNumber”, operator element will have “=” and value element will have “33550”.
6.4.1 Search DELIVER transactions for a receipt using ReceiptId
A Receipt in fusion applications is uniquely identified by the attribute ShipmentHeaderId, which is

part of the response in the Receipt Details service. In order to perform a return or a correction, you
might need to identify the DELIVER transaction’s transaction Id. For that you can get the deliver
transactions by invoking the receiving transaction details service passing the receipt Id and filtering
on transaction type DELIVER.
<soap:Body>
<ns1:findTransaction
s/">
<ns2:filter>
<ns2:group>
<ns2:item>
<ns2:attribute>ShipmentHeaderId</ns2:attribute>
</ns2:item>
<ns2:item>
<ns2:attribute>TransactionType</ns2:attribute>
<ns2:value>DELIVER</ns2:value>
</ns2:item>
</ns2:group>
</ns2:filter>
</ns1:findCriteria>
</ns1:findControl>
</ns1:findTransaction>
</soap:Body>
</soap:Envelope>
6.4.2 Find details of a child transaction given the parent transaction
You can use this sample payload in a case where you know the parent RECEIVE transaction and
want to find the details of its immediate child transaction (which could be an inspection or a deliver
transaction).
<soap:Body>
s/">
<ns2:filter>
<ns2:group>
<ns2:item>
<ns2:attribute>ParentTransactionId</ns2:attribute>
</ns2:item>
</ns2:group>
</ns2:filter>
<ns2:excludeAttribute></ns2:excludeAttribute>
</ns1:findCriteria>
</ns1:findControl>
</soap:Body>
</soap:Envelope>
6.4.3 Find all transactions for a given root RECEIVE Transaction Id
You can use this sample payload to retrieve all the transactions that have been recorded for a given
RECEIVE transaction. The response will comprise of all transactions starting from inspection and
down to returns, and will include all corrections done in the hierarchy of these transactions.
<soap:Body>
s/">
<ns2:filter>
<ns2:group>
<ns2:item>
<ns2:attribute>RootReceivingTransactionId</ns2:attribute>
</ns2:item>
</ns2:group>
</ns2:filter>
<ns2:excludeAttribute></ns2:excludeAttribute>
</ns1:findCriteria>
</ns1:findControl>
</soap:Body>
</soap:Envelope>
6.5 Sample Output Response of Receiving Transaction Details

This is the sample response payload of the Receiving Transaction service
<ns0:findTransactionResponse xmlns=""
s/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-
n/"
s/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:ReceivingTransaction">
<ns2:ParentTransactionType>RECEIVE</ns2:ParentTransactionType>
<ns2:RootReceivingTransactionId>2958278</ns2:RootReceivingTransactionId>
<ns2:PODistributionId>100000012026106</ns2:PODistributionId>
<ns2:RcvTxnDFFVA>
</ns2:RcvTxnDFFVA>
</ns3:result>
n/"
<ns2:RcvTxnDFFVA>
</ns2:RcvTxnDFFVA>
</ns3:result>
n/"
<ns2:RcvTxnDFFVA>
</ns2:RcvTxnDFFVA>
</ns3:result>
n/"
<ns2:RcvTxnDFFVA>
</ns2:RcvTxnDFFVA>
</ns3:result>
</ns0:findTransactionResponse>
7. Inbound Shipment Details
7.1 Overview
The Shipment Details is provided to fetch the information for an inbound shipment created in Fusion
Receiving. There are three kinds of inbound shipments in fusion receiving – ASN, inventory in-
transit shipment and transfer order shipment. This service allows you to fetch the details of these
three kinds of shipments.

The URL for the Receipt Details service is http://<server-name>:<port-
number>/rcvShipmentDetails/InboundShipmentService. This has one operation FindShipment and its
asynchronous version FindShipmentAsync.
7.2.1 FindShipment
The FindShipment operation and its asynchronous equivalent constitute the standard find operation
that is provided by ADF BC web services. The find operation lets you query by the shipment
number, shipment identifier and will fetch the details of the shipment, its lines and the lot and serials
that were shipped as part of each line.
 ns1:InboundShipmentHeader – This node represents the inbound shipment header. It

contains attributes such as shipment number, receiving organization, receipt source code and
shipment Id etc.
 ns1:shipmentLine – This node represents the inbound shipment lines for a shipment header.
It contains attributes such as line number, item, quantity shipped, quantity received etc.
 ns1:Lot – This node represents the lot numbers shipped against a shipment line.
 ns1:Serial – This node represents the serial numbers shipped against a shipment line. This
node contains the serial numbers when the item is serial controlled and not lot controlled.
 ns1:LotSerial – This node represents the serial numbers for a particular lot shipped against a
shipment line. This node contains the serial numbers when the item is both serial controlled
and lot controlled.
 ns1:RcvShpHdrDFFVA – This node represents the descriptive flexfield information

corresponding to the shipment header.
 ns1:findShipment – This is the top node for the input payload and all the search related
service with.
how you want to construct the filter criteria
should be case sensitive or not. Set to true if you want a case insensitive search
you enter the shipment number to search for.
to fetch results for shipment number, set this node as “ShipmentNumber”
 n2:operator – Arithmetic operator (e.g. =, <, > etc.)
you want to search using receipt number “ASN1415”, the attribute element will have
“ShipmentNumber”, operator element will have “=” and value element will have
“ASN1415”.
 ns2:childFindCriteria – This node should be used to specify the filter criteria that need to be
applied on the child nodes of the service – i.e. ns2:ShipmentLine. For instance, you can use
this node to filter the receipt details service by ItemNumber RCV-100, and the service will
filter the child nodes.
 ns2:childAttributeName – This element will need to be used in conjunction with

ns2:childFindCriteria. Use this element to identify the child attribute against which you
apply the filter criteria as part of childFindCriteria. For instance, if you want to receipt lines
to be used, specify ShipmentLine in this node.
7.5.1 Search using shipment number and receiving organization
The sample payload below fetches the details for shipment number ASN-1000125-5 and receiving
organization code M1.
<soap:Body>
<ns1:findShipment
xmlns:ns1="http://xmlns.oracle.com/apps/scm/receiving/receipts/shipmentDetails/service/t
ypes/">
<ns2:filter>
<ns2:group>
<ns2:item>
<ns2:attribute>ShipmentNumber</ns2:attribute>
<ns2:value>ASN-1000125-5</ns2:value>
</ns2:item>
<ns2:item>
</ns2:item>
</ns2:group>
</ns2:filter>
</ns1:findCriteria>
</ns1:findControl>
</ns1:findShipment>
</soap:Body>
</soap:Envelope>
7.5.2 Search for a particular shipment line using shipment number and item
Consider inbound shipment ASN-1000125-5 which has 4 lines. If you want to fetch the receipt line
for the item RCV-100, then you should specify additional criteria for the shipment line as part of the
childFindCriteria node of the find operation. And you also should specify the child attribute name (in
this case ShipmentLine) to ensure that the filters are applied on the node ns2:ShipmentLine.
<soap:Body>
<ns1:findShipment
ypes/">
<ns2:filter>
<ns2:group>
<ns2:item>
<ns2:attribute>ShipmentNumber</ns2:attribute>
<ns2:value>ASN-1000125-5</ns2:value>
</ns2:item>
<ns2:item>
</ns2:item>
</ns2:group>
</ns2:filter>
<ns2:childFindCriteria>
<ns2:filter>
<ns2:group>
<ns2:item>
<ns2:attribute>ItemNumber</ns2:attribute>
<ns2:value>RCV-100</ns2:value>
</ns2:item>
</ns2:group>
</ns2:filter>
<ns2:childAttrName>ShipmentLine</ns2:childAttrName>
</ns2:childFindCriteria>
</ns1:findCriteria>
</ns1:findControl>
</ns1:findShipment>
</soap:Body>
</soap:Envelope>
7.6 Sample Output Response of Inbound Shipment Details

This sample response payload has all elements of the inbound shipment details service.
<ns0:findShipmentResponse xmlns="" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
ypes/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-
xmlns:ns1="http://xmlns.oracle.com/apps/scm/receiving/receipts/shipmentDetails/service/"
ypes/"
pHdr/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns1:InboundShipmentHeader">
<ns1:OrganizationId xsi:nil="true"/>
<ns1:OrganizationCode xsi:nil="true"/>
<ns1:ReceiptNumber xsi:nil="true"/>
<ns1:BillOfLading xsi:nil="true"/>
<ns1:PackingSlip xsi:nil="true"/>
<ns1:ShippedDate>2015-05-25T00:00:00.0-07:00</ns1:ShippedDate>
<ns1:FreightCarrierId xsi:nil="true"/>
<ns1:ExpectedReceiptDate>2015-05-25T00:00:00.0-07:00</ns1:ExpectedReceiptDate>
<ns1:NumberOfContainers xsi:nil="true"/>
<ns1:WaybillAirbillNumber xsi:nil="true"/>
<ns1:ASNType>ASN</ns1:ASNType>
<ns1:GrossWeight xsi:nil="true"/>
<ns1:GrossWeightUOMCode xsi:nil="true"/>
<ns1:GrossWeightUOMName/>
<ns1:NetWeight xsi:nil="true"/>
<ns1:NetWeightUOMCode xsi:nil="true"/>
<ns1:NetWeightUOMName/>
<ns1:TarWeight xsi:nil="true"/>
<ns1:TarWeightUOMCode xsi:nil="true"/>
<ns1:TarWeightUOMName/>
<ns1:FreightTerms xsi:nil="true"/>
<ns1:ShipToOrgId>207</ns1:ShipToOrgId>
<ns1:ShipToOrgCode>M1</ns1:ShipToOrgCode>
<ns1:ShipmentLine
pLine/">
<ns1:QuantityShipped>2</ns1:QuantityShipped>
<ns1:QuantityReceived>0</ns1:QuantityReceived>
<ns1:ItemDescription>VC-Lot Serial Revision</ns1:ItemDescription>
<ns1:ToOrganizationId>207</ns1:ToOrganizationId>
<ns1:SecondaryQuantityShipped xsi:nil="true"/>
<ns1:SecondaryQuantityReceived xsi:nil="true"/>
<ns1:SecondaryUOMCodeName/>
<ns1:ASNLPNId xsi:nil="true"/>
<ns1:ConsignedTransaction>N</ns1:ConsignedTransaction>
<ns1:Lot>
<ns1:LotNumber>LOTASN4</ns1:LotNumber>
<ns1:LotSerial>
<ns1:SerialNumber>SERASN-90</ns1:SerialNumber>
</ns1:LotSerial>
<ns1:LotSerial>
</ns1:LotSerial>
</ns1:Lot>
</ns1:ShipmentLine>
<ns1:ShipmentLine
pLine/">
<ns1:Serial>
</ns1:Serial>
<ns1:Serial>
</ns1:Serial>
</ns1:ShipmentLine>
<ns1:ShipmentLine
pLine/">
<ns1:ItemDescription>Lot Item</ns1:ItemDescription>
<ns1:Lot>
<ns1:LotNumber>LOTASN1</ns1:LotNumber>
</ns1:Lot>
</ns1:ShipmentLine>
<ns1:ShipmentLine
pLine/">
</ns1:ShipmentLine>
<ns1:RcvShpHdrDFFVA>
<ns3:_BI_2DGlob_2DRH xsi:nil="true"/>
</ns1:RcvShpHdrDFFVA>
</ns2:result>
</ns0:findShipmentResponse>
8. Send Receipt Advice
8.1 Overview
The principal intent of the Send Receipt Advice service is to communicate expected shipment lines
to an execution partner, such as a contract manufacturer. The service provides users a mechanism to
choose which lines to be transmitted by providing attributes that the user can search on. A Receipt
Advice is an expected shipment line that the external party awaits and maps to a Purchase Order,
inter-organization in-transit shipment, Transfer Order inbound shipment or a RMA. This service
constructs the receipt advice in the SDO (service data object) format and hand it off to the execution
partner (EP). EP will also be able to invoke this service with minimal criteria on a frequent basis in
which case, this service will fetch the open expected shipment lines based on criteria like document
number, supplier, due date and send them as a group.
The service provides the following attributes to filter the expected receipt advices on
 Purchase Order related – Purchase Order Number, PO Line Number, PO schedule Number
 Transfer Order related –Transfer Order number, Transfer order line number
 RMA related – RMA number, RMA line number
 In-transit shipment related – In-transit shipment number, in-transit shipment line number
 Supplier
 Supplier site
 Customer
 Item number
 Receiving location
 Due date
 Carrier
The receiving organization which the expected shipment lines belong to, must be mandatorily
provided. Without the receiving organization the service will not generate
The service does not support blind queries. You need to provide at least one of the following
attributes when invoking the service to fetch the expected shipment lines/receipt advices.
 Purchase Order
 In-transit Shipment
 RMA
 Transfer Order
 Supplier
 Customer
 Item
 Due Date

The URL for the Send Receipt Advice service is http://<server-name>:<port-
number>/rcvReceiptAdvice/ReceiptAdviceService. This has one operation getReceiptAdviceDetails
and its asynchronous version getReceiptAdviceDetailsAsync.
8.2.1 getReceiptAdviceDetails
The send receipt advice service has one operation getReceiptAdviceDetails and its asynchronous
equivalent is getReceiptAdviceDetailsAsync.
8.3 Components of Input Payload
 ns1:ReceiptAdviceParameter – This node or object represents the criteria of the expected

shipment lines to be included in the outbound receipt advice. The attributes that you
populated as part of this node will be used to filter the open expected shipments and prepare
the response.
 Note: For each attribute, the ReceiptAdviceParameter input payload provides both
Number/Code as well as internal identifiers. Providing internal identifiers is optional. But
when these internal identifiers are provided, the query operation responds faster as
compared to when number/code attributes are provided. Some of the important attributes of
the ReceiptAdviceParameter node are:
o OrganizationCode / OrganizationId – These are mandatory attributes. The expected

shipment lines are filtered by the provided Organization. You can either provide an
Organization Code or Organization Identifier if you know the internal identifier.
o Purchase Order attributes
 PO Number (attribute name PurchaseOrder), PO Line (attribute name

PurchaseOrderLine) and PO schedule (attribute name
PurchaseOrderSchedule) – Using these attributes you can filter the
expected shipments by PO number, line number, schedule number.
 PurchaseOrderHeaderId, PurchaseOrderLineId and

PurchaseOrderLineLocationId – These are internal identifiers that
correspond to a PO header, PO line or PO schedule.
o In-transit Shipment attributes
 In-transit shipment number (attribute name IntransitShipment), In-transit

shipment line number (attribute name IntransitShipmentLine)
 IntransitShipmentHeaderId and IntransitShipmentLineId – Internal

identifiers that correspond to the in-transit shipment header and line.
o Transfer Order attributes
 Transfer Order Header Number (attribute name TransferOrder), Transfer

Order Line Number (attribute name: TransferOrderLine)
 TransferOrderHeaderId and TransferOrderLineId – Internal identifiers
corresponding to TO header and line number.
o RMA attributes
 RMA Number (attribute name RMA), RMA line number (attribute name
RMALine)
 RMAHeaderId and RMALineId – internal identifiers for RMA number

and line number. These distinguish two different RMAs with same
Number created from two different source systems
o Supplier attributes
 Supplier name (attribute name Supplier), Supplier identifier (attribute

name SupplierId)
 Supplier site code (attribute name SupplierSite), supplier site identifier

(attribute name: SuppliersiteId)
o Customer – Customer name (attribute Customer) and Customer identifier (attribute

name CustomerId)
o Item – Item Number (attribute Item) and Item identifier (attribute name ItemId)
o ReceivingLocation – Location Code (attribute name ReceivingLocation) and

Location identifier (attribute name ReceivingLocationId)
o Carrier – Carrier name (attribute name Carrier), Carrier identifier (attribute name
CarrierId)
o DueDate – Due date of the expected shipment line. The value that you provided to
this parameter corresponds to a lookup code which is defined for the standard
lookup “RCV_DUE_DATE_OPTION”. You can access the lookup codes for this
lookup type by navigating to the Manage Standard lookups UI and searching by
this lookup type. Possible values that you can provide to the attribute DueDate are
ALL_PAST_DUE, TODAY, TOMORROW, TWO_DAYS_AHEAD,
THREE_DAYS_AHEAD, ONE_WEEK_AHEAD, ONE_MONTH_AHEAD,
TWO_DAYS_BACK, THREE_DAYS_BACK, ONE_WEEK_BACK,
ONE_MONTH_BACK.
o Resend – This parameter controls whether you want to re-send an already

transmitted receipt advice. The default behavior of the send receipt advice service
is that once a receipt advice has been transmitted, it will not be transmitted again.
However, if you call the service with Resend = “Y” and provide a single document
(PO number, In-transit Shipment number, RMA number or Transfer Order
Number), you can re-transmit the document again. Note that if Resend attribute is
set as Y, then you must provide one of the following in addition - PO number, In-
transit Shipment number, RMA number or Transfer Order Number. Otherwise, the
service does not return a response.
8.4 Components of Response Payload
 ns0:getReceiptAdviceDetailsResponse – Top level node that encompasses the output

response of the send receipt advice service. The receipt advice header and its lines are
contained within this node
 ns2:ReceiptAdvice – Corresponds to the Receipt Advice summary section. It comprises of
when the receipt advice was generated (ns0:creationDate) and the receiving organization to
which the expected shipment lines belong.
 ns0:ReceiptAdviceLine – Represents the individual receipt advice line and corresponds to

the expected shipment line. This node consists of:
o Action Code – Indicates the message type for this receipt advice line.
 CREATE – If this receipt advice line is transmitted for the first time from
fusion receiving to execution partners
 UPDATE – If this receipt advice line was previously transmitted earlier

and is being sent again either because the document was modified after
the previous transmission or if the resend option was set to Y while
invoking the service
o Document Type – PO (Purchase Order), INVENTORY (In-transit shipment),

TRANSFER ORDER (transfer order inbound shipment) and RMA (Return
Material Authorization)
o Receipt source (VENDOR, CUSTOMER, INVENTORY, TRANSFER ORDER),
o Supplier information – Supplier and Supplier Site
o Customer Name
o From Organization – where the material was shipped from in case of in-transit
shipments and transfer order shipments
o Supplier item reference, customer item reference if any
o Item details – Item Number, Item Description, Item Revision, Item category
o Document quantities in both ordered and secondary UOM
o RMA Line Id – RMA Line identifier.. This attribute is used to identify the exact
RMA line row in Fusion Receiving to transact against.
o Receiving controls – Receipt routing, over receipt tolerance percentage, over

receipt action code, early receipt days tolerance, late receipt days tolerance, receipt
date tolerance exception code, allow substitute item receipts indicator and enforce
ship to location code
o RMA references – Original Sales order references and the references from Oracle
Fusion Distributed Order Orchestration if the RMA was created from there.
o Country Of Origin
o Carrier
o Comments, Notes to receiver
 ns0:ReceiptAdviceLineLotNumber – This node represents the lot numbers shipped as part

of the current receipt advice line/expected shipment line and is applicable for in-transit
shipments and transfer order shipments. The components of this node are
o Lot number
o Lot quantity
o Lot quantity in item’s secondary UOM
 ns0:ReceiptAdviceLineSerialNumber – This node represents the serial numbers shipped as

part of the current receipt advice line/expected shipment line. This is applicable for in-
transit shipments and transfer order shipments and is populated for an item that is serial
controlled and is not lot controlled. This node is populated for each serial number that was
shipped.
o SerialNumber – Individual serial number that is part of the current expected

shipment line
 ns0:ReceiptAdviceLineLotSerialNumber – This node represents the serial numbers that

belong to a given lot shipped as part of the current receipt advice line/expected shipment
line. This is applicable for in-transit shipments and transfer order shipments and is
populated for an item that is both serial controlled and lot controlled. This node is populated
for each serial number that was shipped.
o SerialNumber – Individual serial number that is part of the current lot
8.5.1 Search for expected shipments using Purchase Order Header and Line
The sample payload below fetches the receipt advice for PO 1000125 and line 1.
<soap:Body>
<ns1:getReceiptAdviceDetails
xmlns:ns1="http://xmlns.oracle.com/apps/scm/receiving/receiptsInterface/receiptAdvice/re
ceiptAdviceService/types/">
<ns1:ReceiptAdviceParameter
ceiptAdviceService/">
<ns2:PurchaseOrder>1000125</ns2:PurchaseOrder>
<ns2:PurchaseOrderLine>1</ns2:PurchaseOrderLine>
</ns1:ReceiptAdviceParameter>
</ns1:getReceiptAdviceDetails>
</soap:Body>
</soap:Envelope>
8.5.2 Search expected shipments due today and next three days for a supplier
The sample payload below fetches the shipment lines for supplier Advanced Network Devices and
supplier site FRESNO. Due date has to be mentioned as mentioned in section 8.3
<soap:Body>
<ns2:Supplier>Advanced Network Devices</ns2:Supplier>
<ns2:SupplierSite>FRESNO</ns2:SupplierSite>
<ns2:DueDate>THREE_DAYS_AHEAD</ns2:DueDate>
</soap:Body>
</soap:Envelope>
8.5.3 Search expected shipments due today for an item and all document types
The sample payload below fetches the shipment lines for item RCV-100 that with due date as today.
This will fetch all open Purchase orders schedules, transfer order shipment lines, in-transit shipment
lines and RMA lines that contain the item RCV-100.
<soap:Body>
<ns2:Item>RCV-100</ns2:Item>
<ns2:DueDate>TODAY</ns2:DueDate>
</soap:Body>
</soap:Envelope>
8.5.4 Search expected shipments due today for all document types
The sample payload below fetches all open Purchase orders schedules, transfer order shipment lines,
in-transit shipment lines and RMA lines with current date as the due date.
<soap:Body>
<ns2:DueDate>TODAY</ns2:DueDate>
</soap:Body>
</soap:Envelope>
8.5.5 Search expected shipments for a Transfer Order number
The sample payload below fetches the shipment lines for transfer order 169001 in the organization
M2.
<soap:Body>
<ns2:TransferOrder>169001</ns2:TransferOrder>
</soap:Body>
</soap:Envelope>
8.5.6 Re-send receipt advice for a Purchase Order
If you have transmitted a Purchase order to an execution partner but there was a problem at the end
of the EP receiving the message, then there may be a need to re-send the receipt advice. In that case,
you need to provide the document number that needs to be transmitted and populate the attribute
Resend as Y
<soap:Body>
<ns2:PurchaseOrder>1003068</ns2:PurchaseOrder>
<ns2:PurchaseOrderLine>1</ns2:PurchaseOrderLine>
<ns2:Resend>Y</ns2:Resend>
</soap:Body>
</soap:Envelope>
8.6 Sample Output Response of Send Receipt Advice
8.6.1 Receipt Advice response with expected shipments for a Purchase Order
This sample payload contains the response when the service is called with PurchaseOrder as 1000125
and line 1.
<ns0:getReceiptAdviceDetailsResponse xmlns=""
ceiptAdviceService/types/" xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-
1.0.xsd">
<ns2:ReceiptAdvice
ceiptAdviceService/" xmlns:ns1="http://xmlns.oracle.com/adf/svc/types/"
ceiptAdviceService/types/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns0:ReceiptAdvice">
<ns0:SourceDocumentType>PO</ns0:SourceDocumentType>
<ns0:SoldtoLeName>Vision Operations</ns0:SoldtoLeName>
<ns0:DocumentRevisionNumber>0</ns0:DocumentRevisionNumber>
<ns0:DocumentRevisionDate xsi:nil="true"/>
<ns0:ReceiptAdviceLineStatus>OPEN</ns0:ReceiptAdviceLineStatus>
<ns0:ReceivingLocation>M1- Seattle Mfg</ns0:ReceivingLocation>
<ns0:FromOrganization xsi:nil="true"/>
<ns0:CustomerPartyName xsi:nil="true"/>
<ns0:SupplierName>Advanced Network Devices</ns0:SupplierName>
<ns0:SupplierSiteCode>FRESNO</ns0:SupplierSiteCode>
<ns0:Carrier xsi:nil="true"/>
<ns0:FreightTerms>Due</ns0:FreightTerms>
<ns0:NoteToReceiver xsi:nil="true"/>
<ns0:Comments>VamsiPO1</ns0:Comments>
<ns0:DocumentScheduleNumber>1</ns0:DocumentScheduleNumber>
<ns0:SourceHeaderNumber xsi:nil="true"/>
<ns0:SourceLineNumber xsi:nil="true"/>
<ns0:SourceFulfilLineNumber xsi:nil="true"/>
<ns0:OriginalSourceHeaderNumber xsi:nil="true"/>
<ns0:OriginalSourceLineNumber xsi:nil="true"/>
<ns0:OrigSrcFulfilLineNumber xsi:nil="true"/>
<ns0:OriginalSalesOrderNumber xsi:nil="true"/>
<ns0:OrigSalesOrderLineNumber xsi:nil="true"/>
<ns0:ItemCategory>Miscellaneous_1</ns0:ItemCategory>
<ns0:SupplierItemNumber xsi:nil="true"/>
<ns0:CustomerItemNumber xsi:nil="true"/>
<ns0:Quantity unitCode="Each"
<ns0:CountryOfOriginCode xsi:nil="true"/>
<ns0:SecondaryUnitOfMeasure xsi:nil="true"/>
<ns0:SecondaryQuantity
xmlns:tns="http://xmlns.oracle.com/adf/svc/errors/">0</ns0:SecondaryQuantity>
<ns0:DaysEarlyReceiptAllowed>5</ns0:DaysEarlyReceiptAllowed>
<ns0:DaysLateReceiptAllowed>5</ns0:DaysLateReceiptAllowed>
<ns0:ReceiptDaysExceptionCode>WARNING</ns0:ReceiptDaysExceptionCode>
<ns0:AllowSubstituteItemReceipt>Y</ns0:AllowSubstituteItemReceipt>
<ns0:EnforceShipToLocationCode>WARNING</ns0:EnforceShipToLocationCode>
<ns0:OverReceiptTolerance>5</ns0:OverReceiptTolerance>
<ns0:OverReceiptExceptionCode>WARNING</ns0:OverReceiptExceptionCode>
<ns0:ReceivingRouting>Standard receipt</ns0:ReceivingRouting>
<ns0:RMALineId xsi:nil="true"/>
</ns0:getReceiptAdviceDetailsResponse>
8.6.1 Receipt Advice response for in-transit shipment
with lot and serials
This sample payload contains the response when the service is called for in-transit shipments and
contains the lot and serials that have been shipped as part of these lines.
<ns0:getReceiptAdviceDetailsResponse xmlns=""
ceiptAdviceService/types/" xmlns:wsa="http://www.w3.org/2005/08/addressing"
1.0.xsd">
<ns2:ReceiptAdvice
ceiptAdviceService/" xmlns:ns1="http://xmlns.oracle.com/adf/svc/types/"
ceiptAdviceService/types/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns0:ReceiptAdvice">
<ns0:SourceDocumentType>INVENTORY</ns0:SourceDocumentType>
<ns0:SoldtoLeName xsi:nil="true"/>
<ns0:DocumentNumber>M1M3SH04</ns0:DocumentNumber>
<ns0:DocumentRevisionNumber xsi:nil="true"/>
<ns0:ReceiptAdviceLineStatus>PARTIALLY RECEIVED</ns0:ReceiptAdviceLineStatus>
<ns0:ReceivingLocation xsi:nil="true"/>
<ns0:FromOrganization>M1</ns0:FromOrganization>
<ns0:SupplierName xsi:nil="true"/>
<ns0:SupplierSiteCode xsi:nil="true"/>
<ns0:Comments xsi:nil="true"/>
<ns0:DocumentScheduleNumber xsi:nil="true"/>
<ns0:ItemDescription>VC-Lot Serial Revision</ns0:ItemDescription>
<ns0:DaysEarlyReceiptAllowed xsi:nil="true"/>
<ns0:DaysLateReceiptAllowed xsi:nil="true"/>
<ns0:ReceiptDaysExceptionCode xsi:nil="true"/>
<ns0:AllowSubstituteItemReceipt xsi:nil="true"/>
<ns0:EnforceShipToLocationCode xsi:nil="true"/>
<ns0:OverReceiptTolerance xsi:nil="true"/>
<ns0:OverReceiptExceptionCode xsi:nil="true"/>
<ns0:ReceiptAdviceLineLotNumber>
<ns0:LotNumber>INTSL2</ns0:LotNumber>
<ns0:LotQuantity unitCode="Each"
xmlns:tns="http://xmlns.oracle.com/adf/svc/errors/">9</ns0:LotQuantity>
<ns0:SecondaryLotQuantity xsi:nil="true"/>
<ns0:ReceiptAdviceLineLotSerialNumber>
<ns0:SerialNumber>INT2S002</ns0:SerialNumber>
</ns0:ReceiptAdviceLineLotSerialNumber>
<ns0:ReceiptAdviceLineSerialNumber>
</ns0:ReceiptAdviceLineLotNumber>
<ns0:SourceDocumentType>INVENTORY</ns0:SourceDocumentType>
<ns0:SoldtoLeName xsi:nil="true"/>
<ns0:DocumentNumber>M1M3SH02</ns0:DocumentNumber>
<ns0:DocumentRevisionNumber xsi:nil="true"/>
<ns0:ReceiptAdviceLineStatus>PARTIALLY RECEIVED</ns0:ReceiptAdviceLineStatus>
<ns0:ReceivingLocation xsi:nil="true"/>
<ns0:FromOrganization>M1</ns0:FromOrganization>
<ns0:SupplierName xsi:nil="true"/>
<ns0:SupplierSiteCode xsi:nil="true"/>
<ns0:Comments xsi:nil="true"/>
<ns0:DocumentScheduleNumber xsi:nil="true"/>
<ns0:DaysEarlyReceiptAllowed xsi:nil="true"/>
<ns0:DaysLateReceiptAllowed xsi:nil="true"/>
<ns0:ReceiptDaysExceptionCode xsi:nil="true"/>
<ns0:AllowSubstituteItemReceipt xsi:nil="true"/>
<ns0:EnforceShipToLocationCode xsi:nil="true"/>
<ns0:OverReceiptTolerance xsi:nil="true"/>
<ns0:OverReceiptExceptionCode xsi:nil="true"/>
</ns0:ReceiptAdviceLineSerialNumber>
</ns0:getReceiptAdviceDetailsResponse>
9. Receive Receipt Confirmation
9.1 Overview
The Send Receipt Advice service will transmit the expected shipments for a receiving organization as
receipt advices to an execution partner (EP). The goods are physically received in the external
system. To send the details of the confirmation of the receipts in the external system, EP will invoke
the Receive Receipt Confirmation service. This service provides the mechanism for systems to send
the material and receiving details for the expected shipment lines received using those systems. This
service will interpret and transform the message, and create the necessary records in the receiving
open interfaces.
An EP would be able to invoke this service directly and the receipt confirmation is expected in the
native SDO format. The service then will interpret and convert the messages appropriately and create
the necessary records in the receiving open interface tables. The receiving interface records will in
turn be processed by the receiving transaction processor to automate receipt, inspection, deliver,
return, and correction transactions as necessary by invoking the Manage Receiving Transactions ESS
job.
The receipt confirmation service will have references to the documents (document number, line and
schedule) that were transmitted by the send receipt advice service. The EP will communicate the
quantities that were received, accepted, rejected, delivered, corrected and returned against each
document. When the item is lot and/or serial controlled, the payload should contain the lot and serial
numbers that were delivered and/or returned/corrected.

The URL for the Send Receipt Advice service is http://<server-name>:<port-
number>/rcvReceiptConfirmation/ReceiptConfirmationService. This has one operation
processReceiptConfirmations and its asynchronous version processReceiptConfirmationsAsync.
9.2.1 processReceiptConfirmations
The send receipt advice service has one operation processReceiptConfirmations and its asynchronous
equivalent is processReceiptConfirmationsAsync.
 ns1:ReceiptAdviceParameter – This node or object represents the criteria of the expected

shipment lines to be included in the outbound receipt advice. The attributes that you
populated as part of this node will be used to filter the open expected shipments and prepare
the response.
 ns1:ReceiptConfirmation – This node or object represents the header of the receipt

confirmation input response.
o ns2:OrganizationCode – Organization Code that groups all the receipt confirmation

messages. All receipt confirmation messages for a single invocation must be part of
the same receiving organization.
o ns2:ReceiptNumber – receipt number from source system. However, this is not

currently used. Each receipt in fusion receiving is created by generating a new
receipt number.
 ns2:StagedReceiptConfirmationLine – This node represents each receipt confirmation line
that is part of the inbound message. Each receipt confirmation line that you interface to this
service is then transformed to receiving interface tables.
o ns2:ItemNumber – Item Number that is to be received and transacted in Fusion

Receiving
o ns2:ItemDescription – Description of the item/Purchase order line that is being

received in Fusion Receiving
o ns2:ItemRevision – Revision of the item that is being received
o ns2:SourceDocumentCode – Document type for the document being

received/transacted in Fusion Receiving. Possible values – PO, TRANSFER
ORDER, INVENTORY and RMA
o ns2:DocumentNumber – Document number. Holds purchase order number (if

SourceDocumentCode is PO), transfer order shipment number (if
SourceDocumentCode is TRANSFER ORDER), in-transit shipment number (if
SourceDocumentCode is INVENTORY) and RMA number (if
SourceDocumentCode is RMA)
o ns2:DocumentLineNumber – Document line number. Holds purchase order line

number (if SourceDocumentCode is PO), transfer order shipment line number (if
SourceDocumentCode is TRANSFER ORDER), in-transit shipment line number
(if SourceDocumentCode is INVENTORY) and RMA line number (if
SourceDocumentCode is RMA)
o ns2:Document Schedule Number – Document schedule number. Holds purchase

order schedule number (if SourceDocumentCode is PO)
o ns2:SoldToLegalEntity – Sold-to legal entity. Used when there are more than one
purchase orders with same purchase order number
o ns2:FromOrganizationCode – Source organization code where the transfer order

shipment or in-transit shipment was shipped from. This attribute is mandatory
when the SourceDocumentCode for the receipt confirmation line is TRANSFER
ORDER or INVENTORY
o ns2:UnitOfMeasure – UOM in which the source system has transacted in. All the
quantities that are transmitted to the receipt confirmation lines node are transacted
in fusion system in the value specified in this element
o ns2:QuantityReceived – Net Quantity that has been Received in EP system for this
document line/schedule
o ns2:QuantityAccepted – Net Quantity that has been Accepted in EP system for this
o ns2:QuantityRejected – Net Quantity that has been Rejected in EP system for this
o ns2:QuantityDelivered – Net Quantity that has been Delivered to inventory in EP

system for this document line/schedule
o ns2:QuantityCorrected – Net Quantity that has been corrected in EP system for this
o ns2:QuantityReturned – Net Quantity that has been returned (to supplier, customer
or organization based on the document type) for this document line/schedule
o ns2:InspectionQuality – Inspection quality code applicable while accepting or
rejecting material. This should correspond to lookup code for the lookup type
“RCV_QUALITY_CODE”
o ns2:ReasonName – Transaction reason name
o ns2:Subinventory – Subinventory where the material is delivered to
o ns2:Location – Storage Locator where the material is delivered to
o ns2:RMALineId – RMA Line identifier. This is mandatory while transmitting

receipt confirmation messages for a RMA line. This attribute is used to identify the
exact RMA line row in Fusion Receiving to transact against. This attribute is part
of the Send Receipt Advice service as well and the EP can read this attribute from
the send receipt advice service.
o ns2:SubstituteItemNumber – Item number of the substitute item, in case substitute

items are being received
o ns2: StagedReceiptConfirmationLotAndSerial – This node is used to transmit the

lot and/or serial numbers that are to be transacted in fusion receiving as part of the
receipt confirmation line. This node has been designed to flatten the lot and serial
hierarchy to facilitate a simpler communication between EP and fusion receiving.
So, if you are delivering Lot “Lot1” and serials “SN001”, “SN002”, you need to
create two rows for ns2: StagedReceiptConfirmationLotAndSerial node. In the first
row, give “Lot1” and “SN001” and for the second row, give “Lot1” and “SN002”,
essentially repeating the lot number in two rows.
 ns2:LotNumber – Lot number that is being delivered, returned or

corrected
 ns2:LotQuantity – Lot quantity. Should be in the same UOM as that of the

receipt confirmation line
 ns2:LotExpirationDate – Lot expiration date. Applicable for items that

have shelf life code as days
 FmSerialNumber – From serial number of the range of serials being

delivered, corrected or returned
 ToSerialNumber – To serial number of the range of serials being

delivered, corrected or returned
 ns2:Subinventory – Subinventory where the material is delivered to. If

you want lot “A” to be delivered to one subinventory and lot “B” to
delivered to another, you can specify those values in this node rather than
specifying subinventory in the ns2:StagedReceiptConfirmationLine node
 ns2:Location – Storage locator where the material is delivered to. If you

want lot “A” to be delivered to one locators and lot “B” to delivered to
another, you can specify those values in this node rather than specifying
subinventory in the ns2:StagedReceiptConfirmationLine node
9.5 Components of Response Payload
 ns1:ReceiptConfirmationResponse – This node or object represents the response object

header.
o ns2:groupId – Internal identifier that is generated by Fusion Receiving in order to
group the receipt confirmation lines that have been transmitted in the current
invocation
o ns2:Status – Return Status to indicate whether the message has been received
successfully or there were errors encountered in interfacing these receipt
confirmation lines to receiving open interface. Possible values – SUCCESS,
ERROR
o ns2:ReceiptConfirmationError – This node displays error details when any of the

receipt confirmation lines are in error. It comprises of the following elements:
 ns2:ErrorMessageName – Error message name
 ns2:ErrorMessage – Error message text
9.6.1 Receipt Confirmations for a Purchase Order
The following sample will create receipt confirmation for a Purchase order schedule and interface
these transactions in receiving. The quantities entered in the payload indicate that 5 Each will be
received, all received quantity is accepted and put away to inventory. Out of the 5 Each put away, 2
will be returned to supplier.
<soap:Body>
<ns1:processReceiptConfirmations
xmlns:ns1="http://xmlns.oracle.com/apps/scm/receiving/receiptsInterface/receiptConfirmat
ion/receiptConfirmationService/types/">
<ns1:ReceiptConfirmation
ion/receiptConfirmationService/">
<ns2:OrganizationCode>RCM1</ns2:OrganizationCode>
<ns2:StagedReceiptConfirmationLine>
<ns2:QuantityAccepted>5</ns2:QuantityAccepted>
<ns2:QuantityDelivered>5</ns2:QuantityDelivered>
<ns2:QuantityReturned>2</ns2:QuantityReturned>
</ns2:StagedReceiptConfirmationLine>
</ns1:ReceiptConfirmation>
</ns1:processReceiptConfirmations>
</soap:Body>
</soap:Envelope>
9.6.2 Receipt Confirmation for In-transit Shipment
The following sample will create receipt confirmation for an in-transit shipment line and interface
received, all received quantity is put away to inventory. The item is revision controlled, so the
revision being received has to be specified in receipt confirmation line. The lot and serial information
specified as a child of the receipt confirmation line and will be used in creating the DELIVER
transaction for this shipment line.
<soap:Body>
<ns2:SourceDocumentCode>INVENTORY</ns2:SourceDocumentCode>
<ns2:Subinventory>ABCSUB01</ns2:Subinventory>
<ns2:Location>ABC1.1.1</ns2:Location>
<ns2:StagedReceiptConfirmationLotAndSerial>
<ns2:LotNumber>INTSL-001</ns2:LotNumber>
<ns2:LotQuantity>5</ns2:LotQuantity>
<ns2:FmSerialNumber>INTSS-001</ns2:FmSerialNumber>
<ns2:ToSerialNumber>INTSS-005</ns2:ToSerialNumber>
<ns2:Subinventory></ns2:Subinventory>
<ns2:Location></ns2:Location>
</ns2:StagedReceiptConfirmationLotAndSerial>
</soap:Body>
</soap:Envelope>
9.6.3 Receipt Confirmation for a Transfer Order Shipment
The following sample will create receipt confirmation for a transfer order shipment and interface
these transactions in receiving. Document Number will correspond to the Transfer order shipment
that was interfaced to EP and not the transfer order. The quantities entered in the payload indicate
that 5 Each will be received, all received quantity is put away to inventory. The item is serial
controlled, and hence, serial information specified as a child of the receipt confirmation line and will
be used in creating the DELIVER transaction for this shipment line.
<soap:Body>
<ns2:FmSerialNumber>INTSS-101</ns2:FmSerialNumber>
<ns2:ToSerialNumber>INTSS-105</ns2:ToSerialNumber>
</soap:Body>
</soap:Envelope>
9.6.4 Receipt confirmation for RMA
The following sample will create receipt confirmation for a Purchase order schedule and interface
received, 2 of which are returned to customer and the remaining 3 are delivered to inventory. Since
the same RMA number can be created in fusion receiving from multiple source systems, you need to
specify RMALineId in the service payload to uniquely identify the particular RMA line that needs to
be used to create receiving transactions for.
<soap:Body>
<ns2:SourceDocumentCode>RMA</ns2:SourceDocumentCode>
<ns2:DocumentNumber>SRCSYS1_RMA_001</ns2:DocumentNumber>
<ns2:RMALineId>25909972</ns2:RMALineId>
<ns2:LotNumber>RCONFL-151</ns2:LotNumber>
<ns2:LotQuantity>5</ns2:LotQuantity>
</soap:Body>
</soap:Envelope>
9.6.5 Receipt Confirmation with all transactions interfaced from EP
This sample payload illustrates the use case where the EP communicates all the transactions
performed in a single invocation of the receive receipt confirmation service. Single invocation is
efficient compared to invoking the service multiple times for interfacing each individual transaction.
This payload comprises all item flavors supported (no inventory controls, lot controlled, serial
controlled, revision lot and serial controlled). Notice that lot and serials are being delivered to
inventory as well as returned from supplier. For such cases, there should be two separate receipt
confirmation lines for the DELIVER and return transactions, so that fusion receiving understands
what lot/serials have to be delivered and what lot/serials are to be returned. This payload also covers
the case where material is delivered to inventory and subsequently corrected by specifying which
lot/serials are to be recorded for corrections
<soap:Body>
<ns2:ItemRevision></ns2:ItemRevision>
<ns2:LotNumber>RCONF-L5</ns2:LotNumber>
<ns2:LotQuantity unitCode="Ea">3</ns2:LotQuantity>
<ns2:FmSerialNumber></ns2:FmSerialNumber>
<ns2:ToSerialNumber></ns2:ToSerialNumber>
<ns2:LotNumber>RCONF-L5</ns2:LotNumber>
<ns2:FmSerialNumber></ns2:FmSerialNumber>
<ns2:ToSerialNumber></ns2:ToSerialNumber>
<ns2:LotNumber></ns2:LotNumber>
<ns2:LotQuantity unitCode=""></ns2:LotQuantity>
<ns2:FmSerialNumber>RCONF-S013</ns2:FmSerialNumber>
<ns2:ToSerialNumber>RCONF-S015</ns2:ToSerialNumber>
<ns2:QuantityCorrected>-3</ns2:QuantityCorrected>
<ns2:LotNumber></ns2:LotNumber>
<ns2:LotQuantity unitCode=""></ns2:LotQuantity>
<ns2:FmSerialNumber>RCONF-S013</ns2:FmSerialNumber>
<ns2:ToSerialNumber>RCONF-S015</ns2:ToSerialNumber>
<ns2:ItemRevision>0</ns2:ItemRevision>
<ns2:LotNumber>RCONF-LS3</ns2:LotNumber>
<ns2:FmSerialNumber>RCONFLS-013</ns2:FmSerialNumber>
<ns2:ToSerialNumber>RCONFLS-015</ns2:ToSerialNumber>
<ns2:ItemRevision>0</ns2:ItemRevision>
<ns2:LotNumber>RCONF-LS3</ns2:LotNumber>
<ns2:FmSerialNumber>RCONFLS-013</ns2:FmSerialNumber>
<ns2:ToSerialNumber>RCONFLS-015</ns2:ToSerialNumber>
</soap:Body>
</soap:Envelope>
9.1 Sample Output Response of Receive Receipt Confirmation Service
9.1.1 Sample response when receipt confirmation is interfaced successfully
This sample payload comprises the situation where the receipt confirmation lines that were
transmitted through this service are successfully interfaced to fusion receiving open interface schema.
<ns0:processReceiptConfirmationsResponse xmlns=""
ion/receiptConfirmationService/types/" xmlns:wsa="http://www.w3.org/2005/08/addressing"
1.0.xsd">
<ns0:result
ion/receiptConfirmationService/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns1:ReceiptConfirmationResponse">
<ns1:Status>SUCCESS</ns1:Status>
</ns0:result>
</ns0:processReceiptConfirmationsResponse>

SCM RCV ExternalServices-Version 2

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SCM RCV ExternalServices-Version 2

Încărcat de

Drepturi de autor:

Formate disponibile

Fusion Receiving

External Web Services

1.1 List of External Services in Fusion Receiving ...........................................................................6

2. Receiving Open Interface Version 2 ...................................................................................................7

2.1 Functional Overview ..................................................................................................................8

2.4 Sample Input Payloads .............................................................................................................10

3. Receipt Advice Version 2...................................................................................................................25

3.1 Overview ..................................................................................................................................25

3.2 Service Operations ...................................................................................................................25

3.4 Information on ActionCode attribute (Receipt Advice header) ...............................................26

3.5 Sample Input Payloads .............................................................................................................26

4. Process Staged Receiving Transactions Group Version 2..............................................................29

4.1 Service Operation.....................................................................................................................29

4.3 Sample Input Payload ..............................................................................................................29

5. Receipt Details ....................................................................................................................................30

5.1 Overview ..................................................................................................................................30

5.2 Service Operations ...................................................................................................................30

5.4 Components of input payload ..................................................................................................31

5.5 Sample Input Payloads .............................................................................................................32

6. Receiving Transaction Details ..........................................................................................................38

6.1 Service Operations ...................................................................................................................38

6.3 Components of input payload ..................................................................................................38

6.4 Sample Input Payloads .............................................................................................................39

7. Inbound Shipment Details.................................................................................................................46

7.1 Overview ..................................................................................................................................46

7.2 Service Operations ...................................................................................................................46

7.4 Components of input payload ..................................................................................................46

7.5 Sample Input Payloads .............................................................................................................47

8. Send Receipt Advice ..........................................................................................................................54

8.1 Overview ..................................................................................................................................54

8.2 Service Operations ...................................................................................................................55

8.4 Components of Response Payload ...........................................................................................56

8.5 Sample Input Payloads .............................................................................................................58

9. Receive Receipt Confirmation ..........................................................................................................66

9.1 Overview ..................................................................................................................................66

9.2 Service Operations ...................................................................................................................66

9.4 Components of Input Payload ..................................................................................................66

9.5 Components of Response Payload ...........................................................................................68

9.6 Sample Input Payloads .............................................................................................................69

1.1 List of External Services in Fusion Receiving

 Receiving Open Interface Version 2

o A process to create, update, or cancel receipt advices, or to interface receipt advice

 Process Staged Receiving Transactions Group Version 2

o Processes pending or unprocessed receiving transactions for a given transaction

o Services that provides the information regarding a receiving receipt - receipt

 Receiving Transaction Details

 Inbound Shipment Details

o Service to get the inbound shipment details

 Send Receipt Advice

o Process to retrieve expected shipment lines that need to be interfaced

 Receive Receipt Confirmation

o Process to receive confirmations on expected shipment lines

Receiving Interface Supported Transactions

Transaction ASN-PO In-transit RMA TRANSFER ORDER

RECEIVE Yes Yes Yes Yes

TRANSFER Yes Yes Yes Yes

ACCEPT/REJECT Yes Yes Yes Yes

DELIVER to Yes Yes Yes Yes

Transaction ASN-PO In-transit RMA TRANSFER ORDER

The Receiving Open Interface does not support:

2.1 Functional Overview

2.1.1 Supported Transaction Features

 Serial Support: Multiple rows can exist in the inv_serial_numbers_interface for

2.2 Service Operations