It’s been brought to my attention that there are some parts that show up in inventory but did not have a tag generated for it. As in, they are literally showing up in Part Tracker in a location… but did not get a tag. Why could this happen? What must I do to try to correct this? I know I can have a blank tag manually entered but it begs the question… how many other places is this happening?
It’s not a non-nettable thing. I have some parts from the same bin location that do get a tag… but it’s missing others.
Wild guesses but the only things I can think of - marked nonstock or run-out?
I started looking for something that would be a differentiator. No luck so far. I have 3 parts in the one bin location according to PartBin. All 3 are marked Runout. Nothing marked non-stock. Only 1 of the 3 has a tag. I am looking for anything that might make sense. But no luck so far. I checked the non-stock/qty-bearing flags at the site level also… everything looks in order.
One thing that seems to be a common denominator is that these bin locations have duplicate bins in other sites/warehouses with the same BinNum. Perhaps a bug that comes into play?
Maybe a frequency issue - ABC codes etc.?
(Bug? The heck you say.
)
Do you have any non-completed CCs?
Serial-tracked?
Serial tags are generated per serial number not per PartBin. So if there is a sync problem there, you will have issues. Been there.
@gpayne - This is our first cycle counts. Nothing is on a non-completed CC.
@JasonMcD - Mixture. There are some serial tracked in our list but majority are not.
I also double checked and I did include Non-Nettable bins when I generated the tags. It’s not that.
They all have costs. It’s not that.
When I look down the list of frozen parts that did not get a tag, it seems to be a mixture of several things.
- Many are in bins that exist with the same name in several warehouses/sites.
- The majority of what’s left after that is Non-Nettable bin locations.
- Then the majority of what’s left after that is actually bins locations that we’ve identified as being “non-existent” (but the system doesn’t know this).
- Then non-qty bearing parts.
- Then zero qty parts.
- Then serial tracked items (maybe a non-existing S/N to tie to it)
Timing is a thing, too.
If you have
- On Monday 10 EA of part 99999 in Bin A01
- Generate Tags on Monday (but you did not Start Count Sequence yet)
- On Tuesday a bin transfer of 99999 makes it 7 EA in A01 and 3 EA in bin B02
- On Wednesday do Start Count Sequence
Then for part 99999 you will get a tag for 7 EA in A01 and no tag for B02
So, was there any meaningful delay between Generate Tags and Start Count Sequence? (As in, enough time for people to transact in between.)
we just did our full physical and I noticed that if a part only lived in non-nettable bins and no other locations, even if you include non-nettable bins in the part selection, it wont generate a tag for that part. I assume this is a bug.
@NateS Is this a CC or a physical?
If CC
Did you run initialize Last Cycle Count Date?
I think you meant to tag someone else.
LOL, Not only that I did Jason first and then deleted it.
I was going to ask also. Title says PI but then
Not trying to be mean @dr_dan but “cycle counts” and “Physical Inventory” are, simultaneously, the exact same thing and completely different.
If that makes sense, you have drank the Epicor Kool-Aid.
But seriously, different rules apply depending on the situation.
We’re doing a PI. We’ve never used the Cycle Count module before this.
This could very well be a thing in our situation. Thank you for that!
No - we turned on a BPM that prevents part transactions from being created, generated tags, and started sequence all after hours Friday evening. Roughly took an hour to go through each site/warehouse and do all of it. But within each warehouse, the tags were generated and sequence started within a minute or two of each other.
If enough of us report it as a bug, it might get fixed in version 2029.2
They won’t care about me. We’re still on 2021.2. Haha
Anyone have any insight into how the real-time variances are generated in the variance report? I was looking to make a BAQ that joins all sites/warehouses together and the columns in the CCDtl table does not include populated values for the Frozen Qty and Value… I’m assuming it must use the CCTag table to generate that info on the fly when you run the report. Interesting that the dataset in the report is called CCDtl but it’s not actually getting it from that table.
Serious question here. If we have a serial number that is shown in inventory by the status, but it’s not really in inventory… we mark that sucker 0. But in our case we had 20 serial numbers when only 1 was supposed to truly be in inventory. So it wants us to adjust out 20 of this part that we only had 1 on hand. Bringing our total to -19. And artificially inflating the variance. Is there any way mid-count to correct this? If I had known then that that’s how it got it’s frozen quantity, I would’ve probably run some kind of report ahead of this and made sure the serial number statuses matched the qty on hand.