Oracle Shipping Execution enables the communication of information
to external sources outside of Oracle E-Business Suite and internal
sources outside of Oracle Shipping Execution through the use of XML
(Extensible Markup Language).
Oracle XML Gateway must be installed and configured before using XML with Shipping Execution. See: Oracle XML Gateway User's Guide.
Oracle Shipping Execution uses XML transactions in many shipping
processes, including DSNO (Departure Ship Notice Outbound) and carrier
manifesting (shipment request and shipment advice).
An overview of the process is :
XML Transactions with Carrier Manifesting Systems
XML transactions are used to transmit delivery details to a carrier
manifesting system. Once the carrier manifesting system has processed
the delivery, the shipping details are transmitted back to Oracle
Shipping Execution using an XML shipment response transaction. The exact same mechanism is also used to communicate with the Agile Elite shipping software.
The XML transactions used for carrier manifesting are ShowShipment
Request and ShowShipment Advice. Both are modified versions of the Open
Applications Group (OAG) document type definition (DTD)
show_shipment_005 and contain data such as:
Customer
Delivery number
Ship to Address
Weight
Carrier
Setting Up XML Transactions with Carrier Manifesting Systems
You can send an outbound message to a carrier manifesting system,
including data pertinent to the delivery, that will allow the
manifesting system to calculate the total weight, calculate the total
freight costs, and produce the required shipping labels and paperwork
for shipment. The XML transaction, Shipment Request, extracts data from
the delivery tables. After the carrier manifesting system has performed
its functions, Oracle Shipping Execution will receive shipment
information from the manifesting system in the form an XML Shipment
Response transaction. The data transmitted will have the information
required to complete the shipment, including designated carrier, vehicle
information, freight costs, and other information.
Note: You can use the Action
View Message History at the delivery level to view the history of XML
messages that have been exchanged. This Action is only available if you
have the appropriate privilege assigned to your role.
To enable XML Transactions for carrier manifesting, you must do the following:
Enable Carrier Manifesting Organization in Oracle Shipping
Execution. (In the Organization Parameters window, ATP, Pick, Item
Sourcing tabbed region, select Carrier Manifesting Organization.)
Select Enable Manifesting for the carrierin Shipping Execution. (In the Carrier window, query the specific carrier and select Enable Manifesting.)
Grant the user privilege Send Outbound XML Messages.
You can setup a concurrent request that will automatically send the
Shipment Request to the manifest partner for eligible delivery lines.
To set up automated carrier manifesting:
Navigate to the Shipping Interfaces window.
Enter Automated Carrier Manifesting in Name field.
Define the parameters.
A concurrent request will be launched in the background that will
automatically manifest deliveries that meet the criteria (ship from
organization, carrier, customer, scheduled from/to dates, etc.) This
concurrent request can be scheduled to run periodically so that the
process is automated.
To manually initiate an XML transaction for a single delivery within the Shipping Transactions form
Navigate to the Shipping Transactions form.
Find your delivery.
Select the action Send Outbound Message.
A pop up window displays. You can select from the following transactions that send the corresponding XML transactions:
Send Shipment Request: Shipment must be pick released and packed.
Oracle Shipping Execution will extract shipment information and send it
to the carrier manifesting system using an XML transaction (Request
Shipment).
When a shipment request is sent, the delivery is locked to prevent
updates while it waits for feedback from the carrier manifesting system.
To update the delivery details, you can unlock the delivery by using
the Send Shipment Cancellation. You must then send another Shipment
Request if you expect a response.
Note: Manual ship confirm is disabled for a delivery if the organization and carrier are manifest enabled.
Send Shipment Advice: Not currently used.
Send Shipment Cancellation: Transmits a message to the carrier's manifesting system to cancel the shipment request
Send Outbound Message Window
Once this Send Shipment Request is initiated it does the following:
1. Raises the workflow event : oracle.apps.wsh.sup.ssro
2. This workflow event has a subscription defined as: the workflow : WSHSUPI / Supplier Instance Workflow
The supplier instance workflow does the necessary processing and sends the document to the concerned party through Send Document which in turn calls ECX_STANDARD.SEND to send the document using xml gateway.
You can track all these outbound messages using the query:
1. Each time you send an outbound message a new record is created in the table wsh_transactions_history with the status IP(In Process). This
SELECT *
FROM apps.wsh_transactions_history
WHERE transaction_status = 'IP';
The other possible statuses of records in this table are:
IP (In Process)
ER (Error)
SC ( Successfully Completed)
ST (Sent)
2. Moreover there are records in the outbound queue as well. The status of these messages can be checked using the query:
--Query ECX Outbound messages along with the payload
SELECT out.document_id,
out.transaction_type,
out.transaction_subtype,
out.party_id,
out.generation_timestamp,
out.generation_status,
out.generation_message,
out.generation_logfile,
out.delivery_timestamp,
out.delivery_status,
out.delivery_message,
out.retry_timestamp,
out.retry_status,
out.retry_message,
out.trigger_id,
out.out_msgid,
out.party_type,
decode(wf1.display_name,
NULL,
'N/A',
wf1.display_name) AS tp_name,
wf1.orig_system_id,
wf1.orig_system,
out.party_site_id,
out.protocol_address,
decode(wf2.display_name,
NULL,
'N/A',
wf2.display_name) AS site_name,
wf2.orig_system_id AS site_orig_system_id,
wf2.orig_system AS site_orig_system,
msglog.payload
FROM apps.ecx_out_process_vl OUT,
apps.wf_roles wf1,
apps.wf_roles wf2,
apps.ecx_doclogs msglog
WHERE out.transaction_type = 'FTE'
AND out.out_msgid = msglog.msgid
AND out.party_id = to_char(wf1.orig_system_id(+))
AND wf1.orig_system(+) = decode(out.party_type,
'C',
'HZ_PARTIES',
'Customer',
'HZ_PARTIES',
'E',
'HZ_PARTIES',
'EXCHANGE',
'HZ_PARTIES',
'CARRIER',
'HZ_PARTIES',
'S',
'PO_VENDORS',
'Supplier',
'PO_VENDORS',
'I',
'HR_LOCATIONS',
'Internal',
'HR_LOCATIONS',
'B',
'CE_BANK_BRANCHES_V',
'Bank',
'CE_BANK_BRANCHES_V')
AND wf1.name(+) =
decode(out.party_type,
'C',
'HZ_PARTIES',
'Customer',
'HZ_PARTIES',
'E',
'HZ_PARTIES',
'EXCHANGE',
'HZ_PARTIES',
'CARRIER',
'HZ_PARTIES',
'S',
'PO_VENDORS',
'Supplier',
'PO_VENDORS',
'I',
'HR_LOCATIONS',
'Internal',
'HR_LOCATIONS',
'B',
'CE_BANK_BRANCHES_V',
'Bank',
'CE_BANK_BRANCHES_V') || ':' || out.party_id
AND out.party_site_id = to_char(wf2.orig_system_id(+))
