for Physical Inventory (vs Cycle Count), if you do not select zero qty parts, then thats ok… they will not be counted into stock UNLESS you print a blank tag and fill it in… A Blank tag is simply a “new” tag that has a zero starting balance.
Non-blank tags cannot be Voided because they have a starting qty on hand against them. They must be counted (even if the count is zero).
Blank tags CAN be voided because there is no starting quantity.
Also note that if you try to create a blank tag for a part/bin combination, and that part/bin already exists, your blank tag will be rejected because you can only have one tag per part/bin (Unless it is serialized, at which point, it is Part/Bin/Serial number.)
1 Like
And update-able part-number and bin fields.
Say the system thinks there are 100 EA of part XYZ-123 in bin Q1, and a tag is printed for that (say tag 00012345).
What happens if the counter sees the 100 EA, but misses another 50 EA that were on top of the rack (not a designated Bin). They enter 100 on tag 00012345, and turn the tag in. Then someone elses sees the other 50 and enters them on a blank tag filling in the PartNUm, and Bin, and Qty. The closest bin to where they physically are is Q1, so they use that as the bin.
Can a blank tag supplement the counts of a pre-printed tag, when they have the same P/N, and Bin?
One tag per Part/Warehouse/Bin/Lot or Serial Number combo.
So if it’s in the same “bin” for Epicor purposes the you would make that 150. But if it’s a different bin, then you can create a blank tag for the additional 50 in the new bin.
2 Likes
Yeah, the real issue is when the Part/Warehouse/bin/(lot or serial number) location is not frozen and it has a a quantity on it. When you update the quantity, Epicor compares the frozen quantity to the counted quantity to generate a delta. This is what is posted as an adjustment. So if you have 5 in a location record that wasn’t frozen then you count five, Epicor has no frozen record and assumes zero. It then adds the five to the existing record. 
It’s all it can do, right? Only locations with tags get frozen - that’s what you have to look out for.
So when can that happen?
-
Lack of a clean cut-off. There were five received but not yet recorded. The system doesn’t create a frozen record (omitted zeros). They receive the five. You count the five. You end up with ten.
-
Selective counts. You’re counting some warehouses/bins and not others. So you only freeze those locations. During the count, parts are moved from another location into the counted location. This corrects the new location but we didn’t count the old so those records remain. Count goes up by the amount moved.
It’s little insidious things like this that can burn you. I know we didn’t like printing many tags in earlier versions that were zero. There were so many. So we altered the “Crystal Report” to sort the zero vs non-zero tags so it was easier to distribute them to the floor. If one was missing, we could go to the “zero tag” bucket and send it to the floor.
1 Like
Thanks for everyone’s comments, much appreciated.
But if a blank tag was returned with same part number and bin? Would an error/warning be disayed during entry?
If not, would the posting process first summarize the count entry by part/bin/wrhs, and make a single ADJ-QTY transaction?
Worst case would be that it makes two adj’s, each of (frozen qty - tag count).
An error would display when you enter the Part and Bin in the blank tag. Something along the lines of “Tag #123456789.1 exists for part [PartNum] in Bin [BinNum]”. You would then have to return to the existing tag and decide if they should be added together or if one should be the actual count used. This works the same if a generated tag already exists or if someone else already made a blank tag for that part/bin combo and you’re trying to add a second blank tag for it.
3 Likes
so, to very clearly answer this question…
Part “ABC”, bin “A1” qty 10 System Generated tag #1001
Part “ABC”, bin “A1” qty 5 Blank Tag #3001 -
- above, tag 3001 will be disallowed no matter what order the two tags are entered into the system
Part “ABC”, bin “A1” qty 10 System Generated tag #1001
Part “ABC”, bin “A2” qty 5 Blank Tag #3001 -
Part “ABC”, bin “A2” qty 5 Blank Tag #3002 -
- above, either tag 3001 or 3002 will be disallowed… it depends on the sequence they are entered into the system. The first one entered will be accepted.
Part “ABC”, bin “A1” qty 10 System Generated tag #1001
Part “ABC”, bin “A2” qty 5 Blank Tag #3001 -
Part “ABC”, bin “A3” qty 5 Blank Tag #3002 -
- Above, ALL tags will be allowed.
3 Likes
Or even worse which I’ve just found out, you get a tag record, the part/bin/lot has a QOH, but the frozen qty is set to 0…
I’m really not sure how this could happen.
create a new part
adjust the qty in
run the physical inventory.
generate the tags.
start the count sequence.
frozen qty = the adjust qty in value, which is what you would expect.
Compare date/time of tag creation to the TransLog.
Quantity Bearing Flag?
Clearly been staring at this stuff for too long. Looks like a combination of problems. The non stock flag was checked on all site records for the part, (however part defaults was unchecked)users didn’t check non-stock on initialising physical inventory, then a blank tag was created and I didn’t notice the blank tag field…whew I was really staring to question what was going on…
1 Like
This is what I meant at the UG meeting. It seems so easy but little stuff like this creeps in!
1 Like
@Mark_Wonsil
So do you think that updating the activity quantity as the QOH is a solution? There appears to be only 3 parts affected.
I recall we did a Qty Adjustment after we posted using the same reason code as the Physical so it netted out.
Answered my own question here if you put in the qoh value on the blank tag it does indeed populate the inventory snapshot value in the variance report.
Just further to this post we found that our COS/WIP GL Control the Inventory Adjustment account was set the same as our Inventory account preventing default reason codes (where the reason code was grayed out in Count Discrepancy Reason entry) from showing on the Inventory WIP reconciliation report.
They need to be point to a different account apparently.
as @Mark_Wonsil said “It’s the little things that trip you up.”
Can anyone tell me where I can find the Cycle Count Tags Report or if another report has replaced it?
It’s referenced in a “Cycle Count Process” doc that Mike Gross Shared but it is not in my system…at least by that name. (10.2.400.21)
"Part transactions for the Part and Bin on the selected Tag that occurred after the count sequence start will show in the “Cycle Count Tags report” and Count Tag Entry screen. "
I know in 10.2.500 it can’t be printed outside of the Count Cycle Maintenance screen. Even then, if they have been printed before, then you cannot print them again. You can only re-print and it uses the same settings as the original printing.
Thanks Doug,
But it’s not the tags I’m looking for, this is a report. It supposedly show activity on a tag that occurs between the beginning of the cycle and the actual count of the tag.
Here is an example:
