Execute
Count Program is a time-triggered transaction
that is called to create count requests.
Note: If
you run the Execute Count Program time-triggered
transaction more than once in a day, the system does not create additional
count requests. You can create additional count requests using the
Invoke Count Service screen in the Application Consoles. For more
information about invoking count service, see the Sterling Selling and Fulfillment Foundation:
Warehouse Management System User Guide.
Count Request Generation
You can create count requests at item level, location
level and item-classification level.
Cycle
count for classifications and
performing count at item level
This time-triggered
transaction uses the following logic (for each count program condition)
to determine the number of count requests that need to be generated
for items:
- The time-triggered transaction
creates a list of
all items that are applicable for the specified classifications. This
is filtered to list only those items that satisfy any one of the following
conditions:
- The items have inventory.
- The items belong to classifications whose count
strategy indicates that these items must be put on count even if there
is no inventory.
- The total number
of count requests to be generated
over the effective period of the count program is projected by multiplying
the number of items (ascertained above) with the "times to count"
value specified for the count program condition.
- The
number of count requests needed to be generated
on the day is calculated by dividing the total number of count requests
(as calculated above) by the total number of working days left in
the effective period of the count program.
- The
time-triggered transaction now creates count
requests for the required items from the above list of items, sorting
items by higher velocity but lesser number of open shipments on that
day, and by Item ID. The velocity of an item refers to the number
of closed shipments for the item in the last cycle. The time-triggered
transaction then picks items from the list that are not counted in
the current cycle.
Note: If you have configured to
count only a certain percentage of items in the count cycle, the system
randomly picks the specified percentage of items to count. When picking
the items to count, the system picks 80% of high velocity items and
20% of low velocity items. For example, if you configure to count
70% of total items in a count cycle, 56% of total items to count are
high velocity items and 14% are low velocity items.
For example, if you want to count 10 items in a three-day
cycle, the first 3 items are counted on the first day, the next 3
items on the second day and the remaining 4 items on the third day.
If you want to count only two items in a three-day
cycle, the first item are counted on the first day and the second
item on the third day. This count strategy is followed to evenly distribute
items that are counted in a cycle.
- If
the executeCountProgram agent is run during
the shift hours, the StartNoEarlierThan timestamp generated on the
count request is the same as the time when the agent was run. If the
agent is run before or after the shift hours, then the time is stamped
as Next Working Shift. The FinishNoLaterThan timestamp generated on
the count request is stamped as end of the current count program cycle.
Cycle count for classifications
and
performing count at classification level
When
a count program specifies that the count should be performed at the
classification level, the count request and count tasks are generated
for the classifications per se, and not for the items. Thus,
the count requests are usually not generated daily, but after an interval
of days.
While generating count requests, the
time-triggered transaction uses the following logic (for each count
program condition) to determine if the count request for the classification
should be generated on that day:
- The time-triggered
transaction verifies whether
at least one item for the classification exists in the inventory.
If no item is found in the inventory, the time-triggered transaction
does not create any count requests for that day, unless the classifications'
count strategy indicates that the classification should be put on
count even if there is no inventory for them.
- Where
at least one item exists in the inventory,
the interval between count request generation is projected by dividing
the total number of working days left in the effective period of the
count program by the number of times still to count (total to count
- already counted).
- The time-triggered transaction
then checks if the
number of working days since the last generation is more than the
calculated interval. If yes, it generates a count request for
the classification.
- If the executeCountProgram
agent is run during
the shift hours, the StartNoEarlierThan timestamp generated on the
count request is the same as the time when the agent was run. If the
agent is run before or after the shift hours, then the time is stamped
as Next Working Shift. The FinishNoLaterThan timestamp generated on
the count request is stamped as end of the current count program cycle.
Cycle count for classifications
and
performing count at location level
This time-triggered
transaction uses the following logic (for each count program condition)
to determine the number of count requests to be generated for locations:
- Based on the conditions configured in the count
program, the time-triggered transaction creates a list of all locations
that must be counted in the current cycle.
- The
system projects the total number of count requests
to be generated over the effective period of the count cycle by multiplying
the number of locations with the value of number of times to count,
which is defined in the count program condition.
- The
system calculates the number of count requests
that must be generated on a day by dividing the total number of count
requests by the total number of working days left in the effective
period of the count program.
- The time-triggered
transaction creates count requests
for locations specified in the list of locations to count. It then
picks up the locations from the list that are not counted in the current
cycle.
Note: If you have configured to count only
a certain percentage of locations in the count cycle, the system randomly
picks the specified percentage of locations to count.
For example, if you want to count 10 locations in a
three-day cycle, the first 3 locations are counted on the first day,
the next 3 locations are counted on the second day, and the remaining
4 locations on the third day. If you want to count only 2 locations
in a three-day cycle, the first 2 locations are counted on the first
day and the second location on the third day. This count strategy
is followed to evenly distribute locations that are counted in a cycle.
- If the executeCountProgram agent is run during
the shift hours, the StartNoEarlierThan timestamp generated on the
count request is the same as the time when the agent was run. If the
agent is run before or after the shift hours, the time is stamped
as Next Working Shift. The FinishNoLaterThan timestamp generated on
the count request is stamped as end of the current count program cycle.
Attributes
The
following are the attributes for this time-triggered transaction:
Table 1. Execute Count-Program AttributesAttribute |
Value |
Transaction Name |
Execute Count Program |
Transaction
ID |
EXECUTE_COUNT_PROGRAM |
Base Document Type |
Count |
Base Process Type |
Count Execution |
Abstract Transaction |
No |
APIs Called |
None |
User Exits Called |
None |
Criteria
Parameters
The following are the criteria
parameters for this
transaction:
Table 2. Execute Count Program
Criteria ParametersParameter |
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. |
AgentCriteriaGroup |
Optional.
Used to classify nodes. This value can be accepted
by WMS time-triggered transactions that only perform their tasks on
the nodes with a matching node transactional velocity value. Valid values are: LOW, HIGH, and any additional values
defined by the Hub from Sterling Application Platform >
System Administration > Agent Criteria Groups.
|
Node |
Optional. Node for which
the Execute Count Program needs to
be run. If not passed, all nodes are monitored. |
Enterprise Code |
Optional. Enterprise
for which the Execute Count Program needs
to be run. If not passed, all enterprises are monitored. |
CountProgramName |
Optional.
Count Program Name for which the Execute Count Program
needs to be run. If not passed, all count programs are monitored. |
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. Execute Count-Program
StatisticsStatistic
Name |
Description |
NumCountProgramsExecuted |
Number
of count programs executed. |
NumCountRequestsCreated |
Number of count requests created for the count program. |
Pending
Job Count
For
this transaction the pending job count is the number of count programs
for the node, whose EFFECTIVE_FROM_DATE value less than or equal to
(<=) and EFFECTIVE_TO_DATE value greater than or equal to (>=)
the current date value.
Events
Raised
The
following events are raised by this time-triggered transaction:
Table 4. Events Raised by the Execute Count-Program TransactionTransaction/Event |
Key Data |
Data Published |
Template
Support? |
NO_REQUESTS_CREATED |
count_dbd.txt |
WMS_EXECUTE_COUNT_PROGRAM.NO_REQUEST_CREATED.xml |
Yes |
ON_SUCCESS |
count_dbd.txt |
WMS_EXECUTE_COUNT_PROGRAM.ON_SUCCESS.xml |
Yes |