Consolidate to shipment

The consolidate to shipment is a task queue based transaction in the order pipeline that corresponds to base transaction CONSOLIDATE_TO_SHIPMENT. This transaction finds a shipment into which a given order release can be included. If it finds an existing shipment, it calls changeShipment() API. Otherwise, it calls the createShipment() API.

To find the existing shipments it matches ShipNode, ShipTo Address, SellerOrganizationCode, Carrier, DocumentType and so forth, of the Order Release with that of existing shipments.

This transaction is applicable only to the shipments in one of the following Statuses:

  • Shipment Created
  • ESP Check Required
  • On ESP Hold
  • Released from ESP Hold
  • Released For Routing
  • Awaiting Routing
  • Shipment Routing
  • Sent To Node
Note: To successfully consolidate an Order Release to an existing shipment, the Add Line and related modification types on shipment in its current status should be allowed.
Note: This transaction is a part of the Order Fulfillment pipeline. In addition, it should be configured to work from the task queue.
Note: The GIFT_FLAG attribute is made editable in the release consolidation template. For two orderlines, if other attributes are same and the GIFT_FLAG attribute is different, then a single release or separate releases are created, based on whether the release consolidation template is excluded or included.

For more information, see the details provided under the createShipment(), changeShipment(), releaseOrder(), and consolidateToShipment() APIs in the IBM Sterling Order Management: Javadoc.

Attributes

The following are the attributes for this time-triggered transaction:

Table 1. Consolidate to shipment attributes
Attribute Value
Base Transaction ID CONSOLIDATE_TO_SHIPMENT
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called createShipment() and changeShipment()
User Exits
  • It calls beforeConsolidateToShipment in com.yantra.ydm.japi.ue.
  • YDMBeforeConsolidateToShipment for each release before it begins processing.
  • After it finds the shipments, it calls determineShipmentToConsolidateWith in com.yantra.ydm.japi.ue.
           YDMDetermineShipmentToConsolidateWith.
    For more information, see the IBM Sterling Order Management: Javadoc.

Criteria parameters

The following are the criteria parameters for this transaction:

Table 2. Consolidate to shipment criteria parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to Get, the only valid value.
Number of Records To Buffer Optional. Number of records to retrieve and process at one time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be suspended before it is considered for reprocessing. Defaults to 5 hours.
Task Queue Filter Criteria Optional. Determines the jobs to be retrieved by the agent. The value that is assigned to this parameter is matched against the value that is stored in the FILTER_CRITERIA column of the YFS_TASK_Q table while retrieving the jobs. The possible values for the parameter depend on the following two default segregation policies that are implemented for the release entity.
  • Release Line Size - Valid values for the release line size based segregation policy are VeryLarge, Large, and VOID.
  • Release Attribute - Valid values for the release attribute based segregation policy are the distinct values that can be assigned to the release attribute that is configured for segregation and VOID.
Note: VOID is a valid task queue filter criteria value irrespective of the segregation policy. It is used to match records with NULL value in the FILTER_CRITERIA column of YFS_TASK_Q table.

The parameter accepts multiple values so that the jobs that match the values can be retrieved or processed together. Use comma-separated enumerations when you assign multiple values to the parameter.

For more information, see Workload segregation for task queue agents.
ColonyID Required in a multischema deployment where a table may exist in multiple schemas. Runs the agent for the colony.

Statistics tracked

The following statistics are tracked for this transaction:

Table 3. Consolidate to shipment statistics
Statistic Name Description
NumOrderReleasesConsolidated Number of order releases consolidated.

Pending job count

For this transaction the pending job count is the number of records available to be processed by the transaction with the AVAILABLE_DATE value less than or equal to (<=) the current date value in the YFS_Task_Q table.

Events raised

The following events are raised by this time-triggered transaction:

Table 4. Events raised by the consolidate to shipment transaction
Transaction/Event Key Data Data Published Template Support?
ON_SUCCESS shipment_dbd.txt
YDM_CONSOLIDATE_TO
_SHIPMENT.ON_
SUCCESS.xml
 Yes

This transaction also raises events as specified under the createShipment() and changeShipment() APIs in the IBM Sterling Order Management: Javadoc.

However, note that the template name would read <TransactionId>.ON_SUCCESS.xml.