Cycle Count Scheduling

Kinetic ERP
1

Hey All,

I’m working on setting up Cycle Counting for our plants that have been using Epicor a long time, and I’m encountering 2 issues while setting the schedules:

  1. Parts last cycle count date tends to be years in the past, which means Epicor pushes to have us count everything in the first available cycle period (e.g., if I have a list of “C” parts that are intended to be counted yearly, Epicor will put them all in any first available period, even if that period is only a quarter or a month). The Initialize Cycle Count Date application doesn’t seem to work for this since all of these parts have previous count dates from various physical inventories/unstructured sampling over the years.

  2. Parts are front-loaded in the schedule - basically to make it easier on our warehouse employees, I’d prefer they get an even number of parts to count every day, but the part selection process frontloads such that in the first few weeks they are counting 7 or so parts a day and by the end of the quarter it drops down to 4 parts a day.

Has anyone else encountered these issues, and if so, is there a good way to counter them? My only thought is to use the part/pcid selection module to manually select parts to count quarterly for this year, then they will effectively be “initialized” for next year and the system should work as intended, but that would be a little extra work.

Thanks for the input!

2

I was hoping somebody else was going to answer this but since they haven’t . . . yes have ran into the same problem and am working on a solution right now. Maybe there is a better way but I haven’t been able to find it. My solution is to pick the number of parts they want to count each week using a baq, and use a function to update the last cycle count date for those selected records, and then email them a report based on the last cc date.

I can imagine there is another solution where you creatively calculate and assign last cc dates to all the parts based on the math of when you want to next count them to distribute them out better, and then just use out of the box cycle count functionality. You could update them using DMT. But there are other reasons we don’t want to use the rest of the cycle count functionality either so I haven’t pursued that to come up with the logic of the date distribution that would be needed.