Freezing parts during cycle count

Epicor ERP 10
1

When we schedule a cycle count, the parts freeze.
Per the Epicor User Guide, parts are supposed to ‘freeze’ when the count is started, unless I am misunderstanding.
We are not starting the count or generating tags. The status of the cycle count is at ‘scheduled’.
What is going on here? Anyone have any idea?

image

2

here is a KB to follow

https://epiccare.epicor.com/epiccare?id=epiccare_kb_article&sys_id=72333beedb755cd8d426576ed396191d&table=kb_knowledge&searchTerm=count%20cycle

3 Likes
3

So… no.

I fear that there is some confusion over the term “freeze.” I think Epicor bungles the term (not inaccurate, but not clear). The Epicor meaning is to fill in the CCTag.SnapshotQty field with a number from PartBin (at the Start Count Sequence action, like you said).

What freezing does not do is to block anything from happening.

Well OK - it prevents transactions for like the tenth of a second it takes to do the freeze on that part

image

The general idea of a cycle count is

  1. Make a period; usually a month - let’s go with that
    a. This does almost nothing
  2. Make a schedule. This is an instance of a period for that warehouse
    a. This creates cycles; in other words dates to count stuff
  3. In the schedule, either “Perform Part Selection” or add parts manually (in a separate screen)
    a. This locks in the part numbers you will count and creates rows in the CCDtl table
  4. In Count Cycle Maintenance, do the “Generate Tags” action
    a. This locks in the locations of the part numbers and creates rows in the CCTag table
  5. In Count Cycle Maintenance, do the “Start Count Sequence” action
    a. This locks in the expected quantities (snapshot) of the tags and populates the SnapshotQty in the CCTag table

I said “locks in” there. Meaning it commits that thing to that cycle. Again, this does not prevent anyone from doing anything.

Fun fact: If there is a long delay between 4 and 5, someone might create quantity of one of your parts in a bin that has no tag - and so you’ll miss that location.

Also there is a discussion to be had on trying to hit a moving target if people are transacting while you count (which is likely). This is why

  1. The “Activity before count” field exists
  2. If you have a busy place, you basically need to enter the counts electronically (Android or MES tablet) to have any hope of hitting that moving target.

But that’s a long explanation so I’ll stop there for now.

3 Likes
4

Thanks for the reply Jason!
As you mentioned, you said “locks” which does not prevent anyone from doing anything at step 4.
However, we are seeing parts freeze at step 3 requiring a manager/supervisor password. So I just have to confirm again, that’s normal?

5

the frozen count is what is used to determine the total variance between what was found on the shelf and what was frozen. This of course assumes that no transactions happened between when you froze and when you count. There is a warning when you enter a count on a part that has had transactions. Here is an illustration on what the system does.

image
image1226×301 10.8 KB

2 Likes
6

One thing to keep in mind regarding the activity during count, in my experience once you enter a count - but don’t post it - it will stop catching those transactions and editing the count, etc, will always only show the activity that happened up until a number was entered into count entry.

Cycle Counts are really so incredibly dependent on timing, if you have lags anywhere in the process you can end up with undesired results.

2 Likes
7

No, I’ve never seen this. This sounds like a BPM. Maybe you could share a screenshot?

1 Like
8

Yes.
So here you can see the cycle is only scheduled, tags have not been generated or anything, I had only performed part selection.
We only want our parts to not be transacted when the count has started, but still want to transact prior to the start of count. Is this ideal or not?

I added the part to a fake job and tried issuing it and the warning pops up -

image
image975×387 119 KB

image
image975×618 128 KB

9

Yes, that looks like a BPM is firing that is calling that up, it is not a normal part of the base program.

If you really do want to go down this route of actually blocking Mtl transactions like this then you would need to adjust your criteria in the BPM to look at something like the snapshot field to see if it is more than 0.

Unless your dealing with huge lag, exceptionally volatile qtys or extreme value parts I’m not sure I would recommend this though, while the freeze and activity during count has the oddity I mentioned it does work and typically you can work out what the proper variance is prior to posting. That is just my opinion though, if the business requires this level of lock down then as I said above, I would look at your BPM condition to fine tune that.

3 Likes
10

This is NOT base… put in by someone who may not understand that Epicor allows transactions during the count (something that other/older systems doesnt allow). Also, i would probably, at the very most, put a WARNING in and not a hard stop.
one more thing… what about backflushed parts? if you have those, then this password thing might be causing corruption because the backflush would fail and not keep inventory in sync.

2 Likes
11

FYI, Much of what is being discussed here will be covered soon at an upcoming FREE webinar on Cycle Counting and Physical Inventory that is being presented by yours truly on Wednesday June 11 at 11:00 Central time. Check it out: https://event.on24.com/wcc/r/4961326/4E3F73554A4C95A6860EF5710A92C79B

undefined
undefined1600×900 107 KB

12

Wonderful! I will join along with a few other members of our team. Thanks Tim!

1 Like