That's good! Then you probably encountered these, but just in case, here's a couple things that tripped me up: Running Part Selection too early doesn't net you very much, because it seems to look at the current date to determine what's due for counting, not the period date, and you can't undo or redo Part Selection. If you delete the period, you can't reuse its period number. Since this is sometimes labeled or displayed as the month, try to set them up so 1 = January, 2 = February, etc, and avoid having to delete and remake. Lastly, all your ABC codes should be created before you create your period schedules, or Part Selection won't pull them.
We don't use variance tolerances, because our inventory controller is pretty devoted to figuring out why the count is off. If she can't, she voids the part and tries again the next day. If we decide to go that route, though, my starting plan is to look at our past physical inventories and see what discrepancies we allowed for parts with different ABC codes. Maybe someone with experience using these can chime in with good starting parameters.
We use Repetitive selection. It calculates how many parts of each code you need to count each month to keep up with your count frequencies, which saves me the trouble of doing it, and gets us more consistent results. If you keep up with the counting, you should only find parts far overdue for counting if they were frequently at zero quantity during Part Selection (assuming you have zero qty turned off). I think Random would work best if you knew how many parts you wanted to count each month and then used the resulting data to determine the count frequency.
Those are roughly the values we started with for our codes. We customized our code calculation because most of our A's were finished goods. Finished goods are class F, which doesn't get counted, and we use a class D which only gets counted once a year (we haven't yet eliminated physical inventory). This left us with 750 As, Bs, and Cs for one person to count, though. We're a small company and she just doesn't have the time. We've started playing with the numbers to see what's doable. Currently we're trying this:
A, 75%, 30 days
B, 80%, 90 days
C, 90%, 180 days
D, 100%, 360 days
If she counts a part while issuing it, she'll add it to the day's cycle, whether that's moving it up from later in the month or adding it new. Fortunately, that's a very flexible part of the cycle count program. Depending on the size and type of your inventory and how many resources you have available for counting, you'll probably have to tweak it, too, to figure out what works.
I'll mention a couple bugs here, too. It's very possible they were fixed in 700, but they should be easy enough to test.
a) Initialize Last Cycle Count Date didn't work for us. I used Excel to calculate a date spread and pushed them in with a UBAQ.
b) Sometimes voiding a part or moving multiple parts via Cycle Count Part Selection Update removes the ABC code from the count detail. This doesn't really affect us, but it might throw off variance tolerance.
c) Try adjusting a selected part to zero before its count day and then return zero and non-zero counts. On two occasions, parts with a frozen qty of zero have demanded tolerance codes (which we don't require), but did not allow us to apply them in Count Discrepancy Reason. I had to UBAQ them to allow the parts to post. I would guess a divide-by-zero error, but it doesn't always happen.
Phew, sorry for the word dump. I hope something here was helpful.