REASSIGN_ORDER_RELEASE.0001

This is an asynchronous service, modeled as an Externally Triggered Transaction. This transaction shares the JMS queue with the RequestForReassignOrderRelease service synchronous service, which accepts the reassign order release request from a user and writes a message to the queue. When such a message reaches the queue, this transaction is triggered and the user request becomes the criteria.

How does the transaction work?

The REASSIGN_ORDER_RELEASE.0001 transaction performs two operations: Get and Execute.

In the Get operation, the transaction reads the message added to the queue by the RequestForReassignOrderRelease service, identifies the matching order release(s) or shipment(s) and creates messages for the execute operation. When more than one OrderRelease is identified from the request, it iterates over the order releases and creates a message with the OrderReleaseKey (Primary Key of the OrderRelease) for each of OrderRelease and writes them to the same queue. Similarly, if multiple shipments are in the request, it iterates over each shipment and creates a message with the ShipmentKey (Primary Key of the Shipment) for each of the shipment and writes those messages to the queue. Each of these messages have the necessary specifications to backorder the OrderRelease or Shipment. Additionally, it adds a short-term inventory control specification in every message so that the item(s) being backordered are not assigned to the same node on reschedule.
A sample execute message to backorder a release is as follows:
```
<OrderRelease Action="BACKORDER" PutInventoryOnHoldOnBackorder="Y" OrderReleaseKey="Key1"/>
```
Similarly, a sample execute message to cancel the shipment and backorder the corresponding release is as follows:
```
<Shipment Action="Cancel" BackOrderRemovedQuantity="Y" PutInventoryOnHoldOnBackOrderRemovedQuantity="Y" ShipmentKey="Key2"/>
```
In the Execute operation, the transaction processes each of the messages independently in a multi-threaded fashion and backorders the corresponding OrderRelease. It adds a short-term inventory control (self-expiring) and the previous node is not suggested if re-scheduling occurs before it's expiry. If a Shipment is passed in the reassign request, it is cancelled first, and the corresponding releases are backordered with the short-term inventory control. Once an order or order line is backordered, it is processed by the regular Schedule and Release agents on the next trigger and the order line is scheduled and released to another node.

Notes:

By default, the duration of the short-term inventory control is derived from the default value of the "Inventory Will Be On Hold For A Minimum Of <number of hours> Hours" and "Daily Inventory Synchronization Time" rules. The default values of these rules are 0 and 00:00 hours respectively. This ensures that an item is not sourced from the same node for a reassign request until the end of the day.

If you enable the "Put Inventory On Hold For Sourcing On Backorder From Node" rule, then you must configure the "Inventory Will Be On Hold For A Minimum Of <number of hours> Hours" and "Daily Inventory Synchronization Time" values based on when you want a node to be available for sourcing items backordered from the node.

To calculate the time until which a node is unavailable for sourcing, refer the following example:
Consider Put Inventory On Hold For Sourcing On Backorder From Node = 3 and Daily Inventory Synchronization Time = 17:00:00. When the reassign request is made at 02/02/2019 13:00:00, the node will be unavailable for sourcing until 02/02/2019 17:00:00.
Similarly, when the reassign request is made at 02/02/2019 15:00:00, the node will be unavailable for sourcing items backordered from the node until 02/03/2019 17:00:00.

Note: By default, the Put Inventory On Hold For Sourcing On Backorder From Node rule is not enabled. However, if you enable the rule, you must set appropriate values for the Put Inventory On Hold For Sourcing On Backorder From Node and

Daily
Inventory Synchronization Time

. These values would be considered by the application to determine the time when a node should be made available for sourcing.

Warning:

Once you enable the Put Inventory On Hold For Sourcing On Backorder From Node rule, disabling the rule causes an item to be sourced from the same node from which it was backordered earlier.

For more information about the inventory rules, see Defining additional inventory rules

Configuration

To reassign order releases, configure the following order modification rules:

Allow the Backorder modification type at the Release and Release Line level for the Released and Awaiting Shipment Consolidation statuses.

To reassign shipments, configure the following shipment modification rules:

Allow the Delete Shipment modification type at the Shipment level for the Shipment Created status.
Allow the Remove Line modification type at the Shipment level for the Shipment Created status.

For more information about setting up status modification rules, see Defining modification rules.

Note: If your Enterprise does not inherit from DEFAULT, then you must manually set these rules for your Enterprise in the Applications Manager. If your Enterprise inherits from DEFAULT, check whether the rules are allowed. If not, you must manually set the rules.

The Backordered order lines are picked up for rescheduling based on the "Retry Intervals" rule set in Scheduling Rules:

If Product is Backordered, retry scheduling after this time (Hours): Enter the appropriate value for this rule. For more information, see Creating a scheduling rule.

If you have enabled the

Put Inventory On Hold For Sourcing On Backorder From
Node

rule, then set the following values appropriately for the optimal use of the node from where order lines are backordered.

Inventory Will Be On Hold For A Minimum Of <number of hours> Hours
Daily Inventory Synchronization Time

Warning:

Once you enable the Put Inventory On Hold For Sourcing On Backorder From Node rule, disabling the rule causes an item to be sourced from the same node from which it was backordered earlier.

For more information, see Defining additional inventory rules.

Events raised

This transaction raises an ON_FAILURE event in case of any failure in the asynchronous processing. The maximum data that can be published by this event is as follows:


<ReassignOrderRelease DocumentType="" EnterpriseCode="" ErrorCode="" ErrorDescription="" EventId="" ModificationLevel="" 
ModificationType="" OrderHeaderKey="" OrderLineKey="" OrderNo="" OrderReleaseKey="" PrimeLineNo="" ProcessType="" 
Reason="" ReferenceName="" ReferenceValue="" ReleaseNo="" RequestedByUser="" SellerOrganizationCode="" ShipNode="" 
ShipNodeKey="" ShipmentKey="" ShipmentNo="" Status="" SubLineNo="" TransactionId="">
<!--<StackTrace/> -->
</ReassignOrderRelease>

This XML is populated with the various exceptions from the transaction and it is template controlled. An exception will have information about the current error and only those attributes are present in the event output. The StackTrace element is commented out in the application-provided template but can be customized to include it. There is no ON_SUCCESS event for this transaction. The existing events ORDER_RELEASE_CHANGE.ON_BACKORDER and


ORDER_RELEASE_CHANGE.ON_SUCCESS

can be utilized to handle the success operation.

Handling exceptions

The order releases or shipments which have failed reassignment will continue to be associated with the Node and appear in the BUC Node details console. But the user may not know the reason for the failure. In case of exceptions, the REASSIGN_ORDER_RELEASE.0001 transaction logs them into the YFS_INBOX table with ExceptionType=REASSIGN_FAILURE. Additionally, another exception is logged by the agent framework with ExceptionType=AGENTEXCEPTION. This is a consolidated exception that shows the count of each type of error where as the REASSIGN_FAILURE exception is logged for each failure.
For example, consider that the reassign request for OrderReleaseKey=Key1 is attempted twice by a user and both attempts failed with the same error. It results in one AGENTEXCEPTION exception with Raised Count=2 and two REASSIGN_FAILURE exceptions, one for each attempt.
The exceptions raised by the REASSIGN_ORDER_RELEASE.0001 transaction are not re-processible (ErrorType=NONREPROCESS). These exceptions have a default expiration time (7 days). All the exceptions are recorded against the original user (Createuserid/Modifyuserid) who requested the reassignment. The reason for failure (errorCode) is recorded against the Error_Reason column of the YFS_INBOX table.
The input to the getExceptionList API to get exceptions of the AGENTEXCEPTION type is as follows:
```
<Inbox ExceptionType="AGENTEXCEPTION" ApiName="REASSIGN_ORDER_RELEASE.0001" Createuserid="<actual user id>">
   <OrderBy>
     <Attribute Name="InboxKey"/> 
   </OrderBy>
</Inbox>
```
The input to the getExceptionList API to get the exceptions of the REASSIGN_FAILURE type is as follows:
```
<Inbox ExceptionType="REASSIGN_FAILURE" ApiName="REASSIGN_ORDER_RELEASE.0001" Createuserid="<actual user id>">
   <OrderBy>
     <Attribute Name="InboxKey"/>
   </OrderBy>
</Inbox>
```
The input to match exception for an Order, OrderLine, OrderRelease, or Shipment is as follows:
```
<Inbox ExceptionType="REASSIGN_FAILURE">
   <InboxReferencesList>
     <InboxReferences Name="" Value=""/>
   </InboxReferencesList>
   <OrderBy>
     <Attribute Name="InboxKey"/>
   </OrderBy>
</Inbox>
```
Here, the Name attribute in the InboxReferences could be OrderReleaseKey, ShipmentKey, OrderHeaderKey, OrderLineKey, OrderNo or ShipmentNo and Value is the value of these attributes. If multiple attributes must be queried, then pass <InboxReferencesList ConsiderAllChildCriteria="Y"> and add <InboxReferences Name="" Value=""/> for each of the query attribute.

In addition to logging exception details to the Sterling™ Order Management System Software database, an event is also raised to publish the exception to ODX, if integration with ODX is enabled. For more information, see exception event.