Frequently Asked Questions and Answers Regarding Cycle Count

By Jag - July 12, 2014
1.) Can the schedule order for the item be seen in the forms, or what table is that stored in ? (is it cycle count schedule id in schedule_requests ?)

The MTL_CYCLE_COUNT_ITEMS table stores information about all the items that are eligible for cycle counting within the scope of a cycle count name. Oracle Inventory uses this information to direct and validate the cycle count scheduling process when entering manual schedule requests. It includes specific information regarding the item, including its class-assignment and the date it was last scheduled to be counted by the cycle count.

SCHEDULE_ORDER column – shows the order in which items will be scheduled, relative to be schedule-order of other items within this cycle count. 


Related example query dealing with schedule order:
SELECT MAX (SCHEDULE_ORDER)
FROM MTL_CYCLE_COUNT_ITEMS
WHERE CYCLE_COUNT_HEADER_ID = 1
AND ABC_CLASS_ID = 64
AND ITEM_LAST_SCHEDULE_DATE = '&LastSchedDate'
having max(schedule_order) is not null
UNION
SELECT MIN(SCHEDULE_ORDER) - 1
FROM MTL_CYCLE_COUNT_ITEMS
WHERE CYCLE_COUNT_HEADER_ID = 1
AND ABC_CLASS_ID = 64
AND NOT EXISTS
( SELECT SCHEDULE_ORDER
FROM MTL_CYCLE_COUNT_ITEMS
WHERE CYCLE_COUNT_HEADER_ID = 1
AND ABC_CLASS_ID = 64
AND ITEM_LAST_SCHEDULE_DATE = '&LastSchedDate'
AND SCHEDULE_ORDER IS NOT NULL )
AND ITEM_LAST_SCHEDULE_DATE > '&LastSchedDate'
having min(schedule_order)-1 is not null
UNION
SELECT MAX(SCHEDULE_ORDER) + 1
FROM MTL_CYCLE_COUNT_ITEMS
WHERE CYCLE_COUNT_HEADER_ID = 1
AND ABC_CLASS_ID = 64
AND NOT EXISTS
( SELECT SCHEDULE_ORDER
FROM MTL_CYCLE_COUNT_ITEMS
WHERE CYCLE_COUNT_HEADER_ID = 1
AND ABC_CLASS_ID = 64
AND ITEM_LAST_SCHEDULE_DATE
>= '&LastSchedDate'
AND SCHEDULE_ORDER IS NOT NULL )
having max(schedule_order)+1 is not null
-- reference Bug 1148708


Comments: The MTL_CC_SCHEDULE_REQUESTS also table shows real time status and processing setup information.

MTL_CC_SCHEDULE_REQUESTS table stores cycle count schedule request. The SCHEDULE_STATUS column indicates whether the schedule request has been processed, completed, closed without coutn requests generated, or awaiting processing.

Cycle count schedule requests partially or fully specify the SKU (stock keeping unit) to cycle count. The cycle count generation process explodes each schedule request into count requests that fully specify the SKU against which count entries and adjustments are made.

Oracle Inventory uses this information to feed the count generation process and generate Cycle Count Requests that show up in the Count List Report.


MTL_CC_SCHEDULE_REQUESTS table
COUNT_REQUESTS_GENERATED_FLAG column – shows whether or not this schedule-request has been exploded into count-requests.
1 = Yes
2 = No

PROCESS_FLAG column – shows whether or not this row is ready to be exploded into count-requests.
1 = Yes
2 = No

REQUEST_SOURCE_TYPE (flag settings) column – shows source of request: auto or manual.
1 = Automatic
2= Manual

SCHEDULE_STATUS (flag settings) column – shows status of this schedule-request.
1 = Unscheduled
2 = Partially Scheduled
3 = Scheduled
4 = No count requests generated
5 = Complete

ZERO_COUNT_FLAG column – shows whether or not to count SKU’s with no system quantity.
1 = Yes
2 = No

SCHEDULE_DATE column - indicates the date that this count should be scheduled

COUNT_DUE_DATE column – shows date by which this count should be completed.

SCHEDULE_COMPLETION_DATE column – shows date when all the count requests generated out of this schedule.
-- All above: Oracle Inventory Technical Reference Manual Release 11i Volume 1
Examples of queries used with the MTL_CC_SCHEDULE_REQUESTS table: select inventory_item_id, subinventory, locator_id, cycle_count_header_id,
cycle_count_schedule_id, to_char(schedule_date, 'dd-mon-yyyy'),
to_char(count_due_date, 'dd-mon-yyyy'), schedule_status,
schedule_completion_date
from mtl_cc_schedule_requests
where cycle_count_header_id = &header_id
and inventory_item_id = &item_id;
-- Bug 815547

--------------------------------------------------------------------------------------------------------------
2.) When ABC compile is generated using QOH value, if there is no QOH - the item will not be in the compile, correct ?

Yes and No:

If you use the entire organization, Oracle Inventory includes all items defined for your current organization in the ABC compile, even those with zero cost or zero quantity.

For subinventories, you cannot compile an ABC analysis for a subinventory that is defined as a non-quantity tracked subinventory.


--------------------------------------------------------------------------------------------------------------
3.1) In table MTL_CC_SCHEDULE_REQUESTS.
We do counts by subinventory. Our items are lot controlled. There are no values for subinventory and lot # populated in table, or presented in scheduled requests. Why ?

The MTL_CC_SUBINVENTORIES table stores all the subinventories that are to be considered for cycle counting when the scope of the cycle count is at subinventory level. The table is not used if the cycle count is at organization level. Oracle Inventory uses this information in the automatic scheduling feature of cycle counting and for validation purpose when schedule requests are manually entered.

MTL_CC_SUBINVENTORIES table has a relationship with MTL_CYCLE_COUNT_HEADERS as follows:

FROM
MTL_CC_SUBINVENTORIES mcs, MTL_CYCLE_COUNT_HEADERS mch
WHERE
mcs.CYCLE_COUNT_HEADER_ID = mch.CYCLE_COUNT_HEADER_ID


--------------------------------------------------------------------------------------------------------------
3.2) In the table mtl_cycle_count_entries....why is the "count_due_date" blank for some records? We would like to know when this column would and would not be populated for manual counts?

Your assumption for the most part is correct - mtl_cycle_count_entries.count_due_date will be populated (not null) when:
A) a date is either scheduled (automatically populated by the Application for Scheduled Counts) or
B) a date has been manually set (see Note 113194.1 above).

By contrast, mtl_cycle_count_entries.count_due_date not will be populated (will be null) when:
C) by default for manual (i.e. unscheduled) counts.


--------------------------------------------------------------------------------------------------------------
4.) There are two columns:
SCHEDULE_DATE and COUNT_DUE_DATE
a.) Is the schedule date the day the automatic scheduler ran ?
Not exactly:
SCHEDULE_DATE column - indicates the date that this count should be scheduled
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1

b.) And count due date the day that the item will need to be counted ?
Correct:
COUNT_DUE_DATE column – shows date by which this count should be completed.
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1

c.) What is the COUNT_REQUESTS_GENERATED_FLAG ?
The values 1, 2
COUNT_REQUESTS_GENERATED_FLAG column – shows whether or not this schedule-request has been exploded into count-requests.
1 = Yes
2 = No
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1

d.) And SCHEDULE_STATUS ?
The values 3, 4
SCHEDULE_STATUS (flag settings) column – shows status of this schedule-request.
1 = Unscheduled
2 = Partially Scheduled
3 = Scheduled
4 = No count requests generated
5 = Complete
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1


--------------------------------------------------------------------------------------------------------------
5.) Once an Item is scheduled, will all lots for that item be in the cycle count request report. (that is all lots for the item will be counted) ?
Yes.
You can manually schedule specific items by entering values in different combinations of the item, revision, lot, serial number, subinventory, and locator fields. If you do not enter an item, you must enter a subinventory. Oracle Inventory schedules a count of all items stocked in this subinventory. If you enter an item and a subinventory, Oracle Inventory schedules the item to be counted only in this subinventory. This process takes the output of the automatic scheduler and yoru manual schedule entrie and generates a count request for each item number, revision, lot number, subinventory, and locator combination for which on-hand quantities exist.


--------------------------------------------------------------------------------------------------------------
6.) Each item that will get scheduled, a record is generated in MTL_CC_SCHEDULE_REQUESTS.
This will only occur each time the scheduler runs. So at the end of the year, I'm assuming we can look at the items and the number of times it has been scheduled (and has record in the table). At minimum, it should have the # of counts per class definition. Is this a correct assumption ?

Comments: I do not necessarily agree that this is a correct assumption. The MTL_CC_SCHEDULE_REQUESTS table shows real time status and processing setup information.

MTL_CC_SCHEDULE_REQUESTS table stores cycle count schedule request. The SCHEDULE_STATUS column indicates whether the schedule request has been processed, completed, closed without coutn requests generated, or awaiting processing. Cycle count schedule requests partially or fully specify the SKU (stock keeping unit) to cycle count. The cycle count generation process explodes each schedule request into count requests that fully specify the SKU against which count entries and adjustments are made. Oracle Inventory uses this information to feed the count generation process and generate Cycle Count Requests that show up in the Count List Report.
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1

Comments: Therefore The MTL_CC_SCHEDULE_REQUESTS table is geared more towards what should be and current processing status, not actual results.


A better measure is the MTL_CYCLE_COUNT_ENTRIES table:

MTL_CYCLE_COUNT_ENTRIES table stores the actual counts of a cycle count. A row in this table without a count is considered to be a count request. Oracle Inventory uses this information to determine and store cycle count adjustments, recounts, and approval requirements. When a cycle count adjustmetn is approved, the count status is set to completed and the adjustment amount field is populated. The Cycle Count Approval form then call a user exit to post an entry in the MTL_MATERIAL_TRANSACTIONS_TEMP table, from which the Oracle Inventory Transaction Processor picks it up and does the accounting, costing, and history update.
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1

Comments: the MTL_CYCLE_COUNT_ENTRIES table stores the actual counts of a cycle count by item, not by class. Therefore (see further below) a SQL statement would need to be written to show actual counts by class. 
MTL_CYCLE_COUNT_ENTRIES table ENTRY_STATUS_CODE column – shows current status of count entry.
1 = Uncounted
2 = Pending Approval
3 = Recount
4 = Rejected
5 = Completed

COUNT_DATE_FIRST column – shows date of first count.
COUNT_DATE_CURRENT column – shows date of current count.
COUNT_DATE_PRIOR column – shows date of count prior to current count.
NUMBER_OF_COUNTS column – shows number of counts that have been made on this entry.
ADJUSTMENT_DATE column – shows date adjustment transaction was posted.
COUNT_TYPE_CODE column – shows type of count performed.
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1

Users need to write a SQL statement with an equijoin between the MTL_CYCLE_COUNT_ENTRIES table and the MTL_CYCLE_COUNT_CLASSES table (and possibly other tables as well) to obtain the number of counts per class definition. I would envision the statement to appear something like this:

select mccc.ABC_CLASS_ID, mcce.NUMBER_OF_COUNTS,
from MTL_CYCLE_COUNT_ENTRIES mcce,
MTL_CYCLE_COUNT_CLASSES mccc
WHERE / HAVING / GROUP BY – need to find relationship between these tables which may involve also joining a another table like MTL_CYCLE_COUNT_ITEMS table INVENTORY_ITEM_ID and ABC_CLASS_ID columns.

Another table that might solve much of this is MTL_CC_SCHED_COUNT_XREFS
The MTL_CC_SCHED_COUNT_XREFS table The MTL_CC_SCHED_COUNT_XREFS table links cycle counts entered, to schedule request that generated it and vice versa. Oracle Inventory uses this information to determine when a schedule request had been completed and update its status.

The MTL_CC_SCHED_COUNT_XREFS table links in the Application code as follows:

FROM
MTL_CC_SCHEDULE_REQUESTS mcsr, MTL_CYCLE_COUNT_ENTRIES mcce
WHERE
mcsr.CYCLE_COUNT_SCHEDULE_ID = mcce. CYCLE_COUNT_SCHEDULE_ID
AND
mcsr.CYCLE_COUNT_ENTRY_ID = mcce. CYCLE_COUNT_ENTRY_ID


The MTL_CYCLE_COUNT_ITEMS table
The MTL_CYCLE_COUNT_ITEMS table stores information about all the items that are eligible for cycle counting within the scope of a cycle count name. Oracle Inventory uses this information to direct and validate the cycle count scheduling process when entering manual schedule requests. It includes specific information regarding the item, including its class-assignment and the date it was last scheduled to be counted by the cycle count.

SCHEDULE_ORDER column – shows the order in which items will be scheduled, relative to be schedule-order of other items within this cycle count.
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1


The MTL_CYCLE_COUNT_CLASSES table
Comments: The MTL_CYCLE_COUNT_CLASSES table stores the cycle count class definations and setup information. This is more specific for information about classes.

MTL_CYCLE_COUNT_CLASSES table stores information about cycle count classes such as associated cycle count name, approval tolerance limits, and minimum counting frequency. Oracle Inventory uses Cycle Count Classes as a unit for specifying and defaulting cycle count attributes. The cycle count scheduler uses counting frequency to determine if the class is eligible, and if so, how many and which items are eligible for scheduling. The count entry and approvals form uses tolerance limites to determine if an adjustment needs to be made.

NUM_COUNTS_PER_YEAR column – shows the number of times an item in this class should be counted per year.
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1


The MTL_CYCLE_COUNT_HEADERS table
MTL_CYCLE_COUNT_HEADERS table stores information about cycle count names. Oracle Inventory uses this information to keep track of all cycle count names defined, to indicate tolerance / approval limits, cycle count calendar and exception set, ABC initialization information, scheduling options, and recount options. A cycle count name is also a management entity, whose purpose is to be the repository of cycle count requirements for a specific application. A cycle count name is used in performance reports, accuracy reprots, and in grouping schedulnig requests, count request, count entries and approvals.
-- Oracle Inventory Technical Reference Manual Release 11i Volume 1


Summary of Cycle Count tables and their uses:
MTL_CYCLE_COUNT_ENTRIES - Current status of each item
MTL_CC_SCHED_COUNT_XREFS - Links count to the scheduled request
MTL_CC_SCHEDULE_REQUESTS - Process Status, Setup and scheduling table
MTL_CYCLE_COUNT_ITEMS - Setup and scheduling table
MTL_CYCLE_COUNT_CLASSES - Setup only table
MTL_CYCLE_COUNT_HEADERS - Setup only table
MTL_MATERIAL_TRANSACTIONS_TEMP – Transaction processing
Relationships between all of these tables: MTL_CYCLE_COUNT_ENTRIES: MTL_CYCLE_COUNT_HEADERS. CYCLE_COUNT_HEADER_ID
MTL_CYCLE_COUNT_ENTRIES.CYCLE_COUNT_HEADER_ID

MTL_CC_SCHED_COUNT_XREFS:
MTL_CC_SCHEDULE_REQUESTS.CYCLE_COUNT_SCHEDULE_ID
MTL_CC_SCHED_COUNT_XREFS.CYCLE_COUNT_SCHEDULE_ID
and
MTL_CYCLE_COUNT_ENTRIES.CYCLE_COUNT_ENTRY_ID
MTL_CC_SCHED_COUNT_XREFS.CYCLE_COUNT_ENTRY_ID 
MTL_CC_SCHEDULE_REQUESTS: MTL_CYCLE_COUNT_HEADERS.CYCLE_COUNT_HEADER_ID
MTL_CC_SCHEDULE_REQUESTS.CYCLE_COUNT_HEADER_ID
and
MTL_CYCLE_COUNT_ITEMS.CYCLE_COUNT_HEADER_ID
MTL_CC_SCHEDULE_REQUESTS.CYCLE_COUNT_HEADER_ID 
MTL_CYCLE_COUNT_ITEMS: MTL_CYCLE_COUNT_CLASSES.ABC_CLASS_ID
MTL_CYCLE_COUNT_ITEMS.ABC_CLASS_ID
and
MTL_CYCLE_COUNT_HEADERS.CYCLE_COUNT_HEADER_ID
MTL_CYCLE_COUNT_ITEMS.CYCLE_COUNT_HEADER_ID

MTL_CYCLE_COUNT_CLASSES:
MTL_CYCLE_COUNT_HEADERS.CYCLE_COUNT_HEADER_ID
MTL_CYCLE_COUNT_CLASSES.CYCLE_COUNT_HEADER_ID

MTL_CYCLE_COUNT_HEADERS:
MTL_CYCLE_COUNT_ENTRIES.CYCLE_COUNT_HEADER_ID
MTL_CYCLE_COUNT_HEADERS. CYCLE_COUNT_HEADER_ID
and
MTL_CC_SCHEDULE_REQUESTS.CYCLE_COUNT_HEADER_ID
MTL_CYCLE_COUNT_HEADERS.CYCLE_COUNT_HEADER_ID
and
MTL_CYCLE_COUNT_ITEMS.CYCLE_COUNT_HEADER_ID
MTL_CYCLE_COUNT_HEADERS.CYCLE_COUNT_HEADER_ID
and
MTL_CYCLE_COUNT_CLASSES.CYCLE_COUNT_HEADER_ID
MTL_CYCLE_COUNT_HEADERS.CYCLE_COUNT_HEADER_ID


--------------------------------------------------------------------------------------------------------------
7.) I am trying to rationalize why some "A" items did not have the minimum count per year. In 2006, users defined 3 counts per year for class A. The generated a new compile list each quarter and did a total re-initialize to cycle count each quarter. This was based on QOH value. Under this process:
- items could be reclassified (like A to B) each quarter.
- new items could be added each quarter (or removed)
- it also would generate a new schedule order
L-PTKNCB2-12-E16.-DB.711007452.0
Item has only one record in cc schedule requests. It was first introduced into our compile our 4th QTR (JUL, AUG, SEP). It has one record created, July 4 2006. Cycle Count attribute is enabled. I would have expected it to try to get 3 counts in for that part in that Quarter. Why only one record ? (Documentation didn't note that current QOH is considered for cc schedule requests at the time of scheduling, so I'm assuming that was not a factor). 
Bug 2163967 describes similar situation: Cycle count process are scheduled items a second time whereas others items in the same class have never been scheduled once. The setup has been defined with a daily workday calandar. One Class / One Group This is contradictory with the Note 76807.1 which states the following:

Compute the set of items belonging to the cycle count class that has the cycle count option enabled on organization level. Order them by schedule order. An item's schedule order is determined at the time of it's last scheduling and at that time it would get the number following the largest existing scheduling order number for that class. This makes sure that this item will not be scheduled until all items with smaller schedule order values have been scheduled (i.e., it will be scheduled again only after every other item has been scheduled)

At most max_items_to_schedule is scheduled from this set (or every item in the set if max_items >= number of items in the
set of eligible for scheduling items). Item with the lowest schedule order is scheduled first, and then it's schedule order id updated to the largest possible one. Then, we repeat that for the new smallest one and son on until we reach either the last item or exceed max items to schedule. For each exported item we create a request record in MTL_CC_SCHEDULE_REQUESTS.


Solution by Development for Bug 2163967 is:
The note is perfectly fine if you are not adding any items inbetween and incacs.opp( Cycle Count Auto Schedule) working according to the algorithm.

From the provided screen shots the items LGR_CLASS_A1,LGR_CLASS_A2,
LGR_CLASS_A3,LGR_CLASS_B1 were being scheduled and adjustments approved.

Later you were entered some 10 items into the schedular and updated the cycle count will insert the records into MTL_CYCLE_COUNT_ITEMS table. Now the schedular will pickup all the records from MTL_CYCLE_COUNT_ITEMS table and scheduling will happen.The four items which were already approved previously will also come for scheduling, So all the items will priortised according to the criteria.After all the items say (10+4) scheduled no item will get scheduled second time untill all the (10+4) items counting finishes. (From now onwards the note validation will work).i.e why all the items were scheduled on 21/DEC/2001. Also couldn't able to see the item which appearing second time between 17/DEC/2001 and 21/DEC/2001.

LGR_CLASS_A1 scheduled second time only after items LGR_CLASS_B2, and LGR_CLASS_C2 were scheduled because these two items were there with minimum schedule order when you scheduled first time.
This is not a bug this is how schedular functionality will work
Question:Going forward, the Business decided to do count frequency of A parts 2 times/year, B & C 1 time/year. They are still using daily schedule interval and running the scheduler daily. Their citeria is now historical useage value. Their intent with the QTR compiles was only to pull in newly created items that would meet compile criteria. There intent was not to re-classify new parts etc. So suggestion to users to not re-initialize when attaching to the cycle count, just update to add items. Because their interval is daily, they may still get scheduled requests for items beyond the count frequency of setup. If the item was picked up in the compile in 1st Quarter, it should stay in for all Quarter's, and I would expect to see the item scheduled at least 2 times if A. What I'm not sure is what occurs if the item is introduced in later QTRs. Goes back to question #7 above.

Answer:
As shown in example per Bug 2163967, when items are added or changes made, then these changes affect the algorithm how incacs.opp (Cycle Count Auto Schedule) performs processing.
Cycle Count Queries:These three queries will provide current status of Cycle Count scheduling and processing statuses:
SELECT CYCLE_COUNT_HEADER_ID COUNT_ID,CREATION_DATE,ENTRY_STATUS_CODE
STATUS_CODE,COUNT_TYPE_CODE TYPE_CODE, SUBINVENTORY SUBINV,
INVENTORY_ITEM_ID ITEM_ID
FROM MTL_CYCLE_COUNT_ENTRIES
WHERE ORGANIZATION_ID = &org_id
AND CYCLE_COUNT_HEADER_ID = &cch_id;

select * from mtl_cycle_count_headers
where cycle_count_header_name = '&Cycle_count_name';

select *
from mtl_cycle_count_entries
where cycle_count_header_id in (select CYCLE_COUNT_HEADER_id
from mtl_cycle_count_headers
where cycle_count_header_name = '&Cycle_count_name');

The four most important things to ensure that Perform Full Cycle Count produces items to count an a count listing: 1). All items that are to be included in the cycle count process need to have the Cycle Count Enabled flag checked ON.
Navigation : INV / Items / Master Items / Inventory tab

2). When attaching Classes to a Cycle count, make sure that you have entered an appropriate number (by class) for the number of times you want the items in that class counted.
Navigation: INV / Counting / cycle counting / cycle counts / query cycle count / click on classes

3). Make sure you re-initialize when you make changes to the cycle count definition.
Navigation: INV / Counting / cycle counting / cycle counts / query cycle count / Adjustments and ABC tab / ABC Initializaiton / Option select Re(initialize)

4). When launching Perform Full Cycle Count remember to click the SAVE OUTPUT box for the cycle count listing

Here is the formula to compute the number of items to schedule.
Max items to schedule = [(Total items in class * Nworkdays) / (ClasscountInterval) ] + 1
ClasscountInterval = Number of working days in a year / Number of counts / year for that class.

However there is no linkage of ABC compile criteria (current on hand quantity) with the items which are scheduled. It strictly orders by the schedule order of the cycle count items rather than the sequence number of the ABC compile. Currently there is no link between the sequence number of the ABC compile with the schedule order in the cycle count items. (It always generates new schedule order numbers when it initializes the items in the cycle count from the ABC compile).

Auto-scheduling for cycle count logic works like this:
Within a given class - the system first tries to find out how many items needs to be scheduled for count. (Cycle count Scheduler) Formula to compute the number of items to schedule within a given class is as follows:

Max items to schedule = [(Total items in class * Nworkdays) / (ClasscountInterval) ] + 1
where ClasscountInterval = Number of working days in a year / (Number of counts / year for that class).

Next when you auto-generate cycle count requests based upon the number of items to be scheduled within a given class - the program tries to find the item with the lowest schedule order within that class. (see the respective table). Suppose there are two items so the program will pick the items with the lowest schedule order ( in a series of 1,2,3,4,5 the system will schedule items with schedule order 1 and 2).

Once the counting is done - it will update the schedule order to 6 , 7 respectively. So next time you count - the system does not schedule the same items but picks up items with lowest schedule number again within that class (in the second case the series available is 3,4,5,6,7 so it will pick items with schedule order 3,4). 



Clarifying common misconceptions and misunderstandings about Cycle Counting:


Counts Per Year Logic:
----------------------
The number of counts per year is the MINIMUM number of times that the item will be counted. It is possible that the item may come up for a count MORE than expected. COUNTS PER YEAR is the "Minimum" number of counts that the Application will perform on the item, not the precise exact or maximum. It is frequently lost on clients that the number of counts is the MINIMUM number of counts. It is possible for an item to be counted more than the number of counts in the setup.

1. The counts per year for a class ensures that all items in that class are scheduled at least that many items in a year.That is, if the counts per year for a class is 10 and the class has 100 items, then each of the 100 items in the class are scheduled at least 10 times.

2. In cases where you have very few items in the class and have high count frequency (say Daily), there are chances that it will be counted more number of times, then specified in its class. However, in those cases you would ideally like to reduce the count frequency (say, from 'daily' to 'weekly').

3. The counts per year for a class can be changed by the user at a later point in time. Cycle counting does not take into account the number of counts that have already been done before the change of value for 'counts per year'. It now takes into account the new value of 'counts per year' for all the items in the class.



Scheduling:
-----------
To understand and determine how the Cycle Count process determines which items are due for Cycle Counting is best explained in Note 76807.1 and 296855.1. The intent of Cycle Counting is for no one in the business to be able to predict the items coming up for a count. It is understandable to be concerned if an item comes up enough for a count, but it begins to enter into the realm of consulting to take the process to the granular level of trying to predict which items are coming up for a count and evaluating sequence numbers.

Below will explain how the scheduling works:

1) Automatic cycle count scheduling allows only the items which have 'Cycle Count Enabled' item attribute to Yes.

The following query lists the items that are not cycle count enabled for a specific cycle count.

SELECT segment1, inventory_item_id
FROM mtl_system_items_b WHERE inventory_item_id IN ( SELECT
inventory_item_id
FROM mtl_cycle_count_items WHERE cycle_count_header_id IN
(SELECT cycle_count_header_id FROM mtl_cycle_count_headers WHERE
cycle_count_header_name='&cyc_count_name'))
AND cycle_count_enabled_flag = 'N'
AND organization_id = &org_id;
-- Takes org id , cycle count name as input.

2) If for a cycle count, the serial control option is 'Not Allowed', then this setup excludes the serial items in the corresponding
subinventory.

The following query lists the items that are serial controlled for a specific cycle count:-

SELECT segment1, inventory_item_id
FROM mtl_system_items_b WHERE inventory_item_id IN ( SELECT
inventory_item_id
FROM mtl_cycle_count_items WHERE cycle_count_header_id IN
(SELECT cycle_count_header_id FROM mtl_cycle_count_headers WHERE
cycle_count_header_name='&cyc_count_name'))
AND serial_number_control_code != 1
AND organization_id = &org_id;
-- Takes org id , cycle count name as input.

If user has specified the counts per year as equivalent to the number of working days of the year(as per calendar) for the class A and auto schedule frequency set to 'Daily' in their cycle count setup, it means that all the items assigned to the class A are eligible for the current schedule and appears in the cycle count listing report. They need to make entries for the todays entries and they should complete the adjustments if any as per todays schedule. Now the next schedule date is set to next working day as per their setup in the cycle count header. When they run the 'Generate automatic schedule requests' and followed by 'Generate cycle count requests' in the next date, cycle count entries are made as per that days schedule and all the items which are assigned to class A are visible in the
cycle count listing report.

If your schedule interval is days, then Inventory only schedules those items that are due for counting on the current date. If they would have made their cycle count setup in such way that all the items are eligible for the each schedule, then they will see all the items which are eligible for the current schedule in the cycle count listing report.

Each time the auto scheduler runs, it schedules counts only for the schedule interval you defined for the cycle count header. So if your schedule interval is weeks, Inventory schedules all items that need to be counted on all of the workdays in the current week. If your schedule interval is days, then Inventory only schedules those items that are due for counting on the current date.

If any pending cycle count entries exists for a previous schedule, then for the current auto-schedule, cycle count entries will not be
created for the item, which has pending cycle count entries in the previous schedule.



Auto-scheduling for cycle count logic works like this:

Within a given class - the system first tries to find out how many items needs to be scheduled for count. (Cycle count Scheduler)
Formula to compute the number of items to schedule within a given class is as follows:
------------------------------------------------------------------------------------------------------------------------------------------
Max items to schedule = [(Total items in class * Nworkdays) / (ClasscountInterval) ] + 1
--------------------------------------------------------------------------------------------------------------------------------------------
where ClasscountInterval = Number of working days in a year / (Number of counts / year for that class).

Next when you auto-generate cycle count requests based upon the number of items to be scheduled within a given class - the program tries to find the item with the lowest schedule order within that class. (see the respective table). Suppose there are two items so the program will pick the items with the lowest schedule order ( in a series of 1,2,3,4,5 the system will schedule items with schedule order 1 and 2)

Once the counting is done - it will update the schedule order to 6 , 7 respectively. So next time you count - the system does not schedule the same items but picks up items with lowest schedule number again within that class (in the second case the series available is 3,4,5,6,7 so it will pick items with schedule order 3,4).



There are two possible reasons for item to not be included in the cycle count schedule.

1) - Not all the Items defined under the ABC group are enabled for a cycle count.
In Oracle Inventory, while ABC compile is used for the cycle count process, Cycle count items table would not populated with the items with an item attribute 'cycle_count_enabled_flag' value set to 'N' in the organization items form. This can be confirmed by running the following:

select a.inventory_item_id,a.abc_class_id,msi.cycle_count_enabled_flag
from mtl_abc_assignments a, mtl_system_items msi
where a.assignment_group_id = &assignement_group_id
and msi.organization_id =&organization_id
and msi.inventory_item_id = a.inventory_item_id;

2) Another possible reason is that you have used the Historical usage value criteria in your ABC Compile. You may have items with no value due to (quantity * cost). Since the value for these items would be Zero, they may not be eligible for counting.



Workday Calendar:
-----------------
While not hard-coded into any Cycle Counting logic, in general there is a working assumption that a workday calendar consists of 260 days in the year.

NWorkDays" represents the difference between the last schedule run and the next schedule run. So, if a user skips a day of running the schedule, then one could roughly expect to see twice the number of items that would be scheduled when user ran the scheduler after that skipped day.


The calendar defined in the "counts per year" starts with the count is reinitialized, not when the calendar year or fiscal year ends. Therefore, if items are added, Cycle Counting functionality does not increase to get those items counted before calendar year or fiscal year end.

Full year:
Maximum Items to schedule = ((120*12*6)/312)+1 = 28
where number of items = 120
number of counts = 12
number of work days in a week = 6
number of workdays in a year = 312

1/2 year
Maximum Items to schedule = ((120*6*6)/156)+1 = 28
where number of items = 120
number of counts = 6
number of work days in a week = 6
number of remaining workdays in the year = 156



Reinitialize versus Update:
----------------------------
Do not reinitialize everyday as this is the incorrect usage of the application. Re-initialize deletes all and re-loads. Update will update the items. Re-initialize is not the way to add new items, end users should be using update instead. Everytime re-(initialization) is run on the cycle count, all historical counts are erased and the system assumes it has the total number of counts to perform. This could cause an increase of items selected for count on any given day.



Handling items which are not to be counted - zero counts for items (regardless of quantity):
--------------------------------------------------------------------------------------------
If the objective is for certain items in a subinventory to not be counted (i.e., items with nominal value) then those items should not be cycle-count enabled. At the item level, the items which should not get picked up need to be set to not be cycle-count enabled. It is Not accepted functionality to create a class of items which are not to be counted and set the number of counts to year to zero. The idea of zero counts per year defies normal functionality of Cycle Counting, it is like dividing a number by zero, you get undefined. This can produce unusual results.

This is a different scenario than ITEMS that posses zero QUANTITY (which is different than the COUNTS of an item, regardless of quantity) to be counted zero times per year. The former deals with number of COUNT per year being zero, not the item itself having a QUANTITY of zero.


Items with Zero Quantity (determining if to be counted):
--------------------------------------------------------
Excluding Zero Quantity means that if the item is listed in the system as having zero quantity, then the item is excluded from on-the-floor counting during a Physical Inventory. Anotherwords, you cannot count something that does not exist, out of thin air. In my office, there might be three coffee cups, four computers, and 168 Oracle Users Guides and Manuals - however there are zero soccer balls, hairdryers, wood burning stoves or airplanes in my office. Therefore, those items are not counted, as the quantity on the system is already showing zero. You cannot count something that is not there, or it becomes an absurd exercise in abstracts.

Including Zero Quantity means that even if the item in the system as having zero quantity, then the item is still included for on-the-floor counting during a Physical Inventory. If I were a diamond importer, and I had diamonds from every part of the world separate in bins, I still would want to double check to make sure that I did not make a mistake and discover a high-dollar diamond (or two) in a bin even if the system stated zero. It might be possible that a mistake was made, so since this item is most likely a high dollar item, that also has a great propensity to be confused with other semi-homogenous items, then as there is a remotely reasonable possibility that such a diamond could exist in a bin in which the system states zero items exist, out of good measure, I am going to count it anyway.

An item has zero quantity when there is no more of that item in its counted location(s), often from depletion in which either reorders were not initiated or fulfilled.
  • Share:

You Might Also Like

0 comments