I wrote this up today for internal documentation and I thought it would be good to share. I have overseen cycle counting for 3 years and I still struggle with the lingo.
I’ll start with words, but this probably will not help.
A “period” is just a date range. It is conceptually the same idea as a fiscal period but there is absolutely no reason for them to be literally the same dates. You can even have two cycle-counting periods that overlap their dates.
Usually, a period is equal to one month. For a fully-functioning and stable cycle count program, a period is equal to (or shorter than) the (time) length of your A code. But if you are just starting, or fixing mistakes, make the period what you need it to be.
A schedule is a warehouse’s instance of a period. “Instance” is an object-oriented programming word. In English: if you have 5 warehouses, you could have anywhere from zero to five schedules that use that period (for its date range).
A production calendar determines available days for counting (or if you want to look at this a different way, you can set your blackout dates here, like holidays and weekends, or even “we never count on Mondays”). There is a place in the schedule to assign the calendar.
A cycle is a count day in a schedule. Epicor will generate one cycle for every non-non-workday in the period/schedule. I know – I’ll explain.
A count is… a cycle. Epicor uses the term “count” here and there (Count Tag Entry; Count Cycle Maintenance), but it’s a synonym for “cycle,” at least in the way they define a cycle. I think “count” is the more logical term.
Putting all this together:
Let’s make a period = Nov 21, 2022, to Dec 23, 2022
And imagine that the system decides to call this “period 12”
And two schedules for this period:
One for the MFG warehouse that uses the MfgCycle calendar (Mon-Thu, but we are off for Thanksgiving, Nov 24)
One for the FAB warehouse that uses the FabCycle calendar (Fridays only, but we are off for Black Friday, Nov 25)
(I chose to use those calendars on those cycles. If I wanted, I could have swapped them, though that would make no sense. Or I could use the same one for both.)
This will generate:
19 cycles (numbered 1-19) for the MFG schedule in period 12
4 cycles (numbered 1-4) for the FAB schedule in period 12
(So, notice there is more than one “cycle # 1” in period 12!)
Caveat on this. We have a lot of parts that go in and out of stock. They may only be in stock for like a week before shipping out, and they may not be back in stock until next quarter. So the parts list for each period has to be fresh to catch items while they’re on hand. We stick to short (2 weeks currently) periods just so our people have something to touch every day.
We started with longer periods, but found that the tail end would completely lack parts and have dialed it down until the work load was consistent.
At one place, they cycle-counted every single day all of the parts active on the previous workday and added it others to cover the slower-moving items. The great thing about it was memory was still fresh when the cycle count happened.
Well, that’s just customary. Your “ABC” program could be codes of Z, Q and E, where Z is one month, E is 4 months and Q is a year.
I struggled with how to phrase this. I mean, the “norm” as I understand it (which we are not either) is counting many days per week, and doing (let’s say) A parts monthly, B quarterly, and C yearly. It’s what we are trying to get to.
Basically I mean a program that is:
Routine
Covers all parts in one year (but probably to varying degrees of frequency)
Allows you to use the system to auto-pick parts rather than you maintaining your own algorithm
In essence, it runs on auto-pilot.
This, I will stand by, though as a rule (rules do get broken). Unassailable reason is that you can’t count a part twice in the same period.
Except that’s conflating two different things: how often you want to touch a part and how you want to organize your count periods. Even before we cut down to 2 week periods, we were tracking aggregate accuracy metrics by period, even though we weren’t necessarily touching the same part again in even consecutive periods.
The better maxim is “your periods should be no longer than the frequency of your A code”, because any longer and (as you said) your A parts will fall out of compliance. Shorter is perfectly fine, and even provides the advantage of being able to reset cleanly. If your counter is out sick for a week, you don’t have to manually move all of the missed parts to future cycles in the period. Just close out the period and let the system re-pull the parts for next time.
Sorry for reviving an old post, but I feel the reply can help future readers.
We have been defining periods by month. Our A’s are set to count once every 30 days. Our calendars are set M-F.
I want to get this setup correctly so I’m trying to comprehend the system logic as has been outlined somewhat in this post.
Since our period can be 31 days and our A’s are set to 30 days, is this an issue?
Should I set our A’s to 31 days if we desire to maintain periods defined within a month?
If our A’s are set to 31 and the period is only 28 days (February), how does the system not miss some A’s that month?
Thanks for the help in advance.
P.S. I assume that the system does not care about the calendar when performing part selection within a period as we would have less than 30 days scheduled.
A part isn’t going to be selected twice in a single period. So there is a possibility that something will then get counted every other cycle when the period is longer than the ABC code’s count frequency.
As I said above, your periods generally should not be longer than your shortest count frequency. However, this rule doesn’t exist in a vacuum. There is often some kind of outside standard you’re required to adhere to for your inventory. If you’re not required to touch a part more often than 90 days, it doesn’t strictly matter if a part gets counted 30 or 60 days if it missed a cutoff. It’s still going to get checked before the 90 day standard comes up.
I mean, unless you’re a 7 days a week operation doing counts every single workday day, your period will always have fewer days than a calendar month. Cycle Count Part Selection totals up the number of parts that it think needs to be counted within your period, and then it divides it among the days of the month. How, precisely, it determines which parts to count and when in the period to count them depends on your part and count (e.g. repetitive vs random) settings.
Background: I was part of a team that got us off full physicals. Part of that was having to break down and prove out our cycle count process for outside auditors.
