RequestForReassignOrderRelease service
This is a synchronous service, which can be called from an external UI. The service is
the trigger for the REASSIGN_ORDER_RELEASE.0001
transaction.
This service accepts the reassign request from the user and verifies the list of shipments,
order releases, order line, order, or node. The service accepts inputs in the following
format:
The input from the user request in read with the following order of precedence:
<ReassignOrderRelease OrderLineKey="" OrderHeaderKey="" PrimeLineNo="" SubLineNo=""
EnterpriseCode="" DocumentType="" OrderNo=""ReassignFromNode="">
<OrderReleases>
<OrderRelease OrderReleaseKey="" OrderHeaderKey="" ReleaseNo=""/>
</OrderReleases>
<Shipments>
<Shipment ShipmentKey="" ShipNode="" SellerOrganizationCode="" ShipmentNo=""/>
</Shipments>
<PassthroughParams/>
</ReassignOrderRelease>
SL# | User Request | Input format |
---|---|---|
1 | To reassign a selected list of order releases | or
|
2 | To reassign a selected list of shipments | or
|
3 | To reassign all the order releases released to a node for an order line | or
Note: When
a release is formed by two or more order lines, this user request backorders all the order lines
specific to the release.
|
4 | To reassign all the order releases released to a node for an order | or
|
5 | To reassign all the order releases, released to a Node |
|
6 | To reassign all the order releases for an order line | or
Note: When
a release is formed by two or more order lines, this user request backorders all the order lines
specific to the release.
|
7 | To reassign all the order releases for an order | or
|
- Order releases in the input
- If not, Shipments in the input
- If not, Order Line in the input
- If not, Order in the input
- If not, Ship Node in the input
OrderRelease
and OrderLine
are passed in the input, the
OrderLine
is ignored. Similarly, if OrderLine
and
Order
are passed, the Order
is ignored. This service does not do any business validation other than checking whether the values passed in the input exist in system or not. For example, if the reassign request involves 10 order releases, of which only 9 exist in OMS but one does not, the services returns and appropriate error and the user must rectify it before requesting for reassign again.
After the necessary validations are done, the service
adds a message to a JMS queue for the reassign request in the following
format:
For
a user request of pattern 3 mentioned in
Table 1, the message format is as
follows:
<Message FlowName="REASSIGN_ORDER_RELEASE.0001" TransactionKey="REASSIGN_ORD_REL.0001">
<AgentDetails>
<MessageXml Action="Get" GenerateMessages="Y">
<!-- validated user request -->
</MessageXml>
</AgentDetails>
</Message>
<Message FlowName="REASSIGN_ORDER_RELEASE.0001" TransactionKey="REASSIGN_ORD_REL.0001">
<AgentDetails>
<MessageXml Action="Get" GenerateMessages="Y" ReassignFromNode="" OrderLineKey=""/>
</AgentDetails>
</Message>
For
a user request of pattern 5 mentioned in
Table 1, the message format is as
follows:
<Message FlowName="REASSIGN_ORDER_RELEASE.0001" TransactionKey="REASSIGN_ORD_REL.0001">
<AgentDetails>
<MessageXml Action="Get" GenerateMessages="Y" ReassignFromNode=""/>
</AgentDetails>
</Message>
For
a user request of pattern 7 mentioned in
Table 1, the message format is as
follows:
<Message FlowName="REASSIGN_ORDER_RELEASE.0001" TransactionKey="REASSIGN_ORD_REL.0001">
<AgentDetails>
<MessageXml Action="Get" GenerateMessages="Y" OrderHeaderKey=""/>
</AgentDetails>
</Message>