It doesnt matter about sites, since each location is a WH and bin, and UD records track the company
1 Like
What happens if for some reason you had the same warehouse code in multiple sites? Thankfully we don’t.
One more very important part… Make sure the count date is correct.
We had one scheduled for 11/30/17, but the person mistakenly set the count date to 11/3/17.
So all the adjustments created were to get the QOH to match our counts. But it was trying to get the QOH as it was on the 3rd, to match the counts done on the 30th.
For example,
- 11/3, the system QOH for a part was 100, actual qty was 99
- 11/15, 50 pieces issued, QOH -> 50, actual qty ->49
- 11/30, 49 are counted and entered into Count Entry
This creates a Qty-Adj of -51. Because it was expecting 100 (on the 3rd), and you told it that it was only 49. And it sets the date of this Qty-Adj to 11/3.
If you then check QOH after posting the count, it will be -1. Because those 50 issued on 11/15 are subtracted from the 49 that was the QOH after posting.
3 Likes
"What happens if for some reason you had the same warehouse code in multiple sites? "
I don’t think you can have the same warehouse namecode even if it is two different sites.
The PartBin table doesn’t have a field for the Plant (aka site). So the only way it could keep the inventory straight, is by having entirely unique warehse codes.
That’s good to know. I have inherited this implementation so a lot of this was setup prior. I have a lot to learn.
Appreciating everyone’s contributions.
Here’s a doc I recently sent our new controller. It’s the basic step-by-step instructions (and some notes) of doing a Phys Inv in E10
There are some specifics to our company (multi-site, and the references to a custom report styles we used for the tags and the Count Variance Calculation Report)
Hope it helps
E10 Phys Inv.pdf (338.3 KB)
Edit: That doc is just a cut and paste from an email I sen, and not intended to be a descriptive step-by-step for all variations. It’s just what works for us.
4 Likes
Brandon,
The doc provided the other day is really good. I might replace mine with that one! Here are two docs that we use as reference. The first one is our cheat sheet (technically it’s from E9, but it’s the same process). The second is one I picked up along the journey a while back. Not mine, so credit goes elsewhere. I’ve also attached our dashboard for you to look at and tweak as needed of course.
Regarding your questions starting with “200k” parts… Let me start with, I am not in accounting or material handling. Comments below are “to the best of my knowledge” and should be consumed appropriately.
The key will be how they are set up and which ABC code is applied. You can set up ABC codes and exclude codes from cycle counting. We exclude all of our “C” parts, many of which we do not stock because we purchase as needed. Non-stock and non-quantity bearing would also help you weed out a number of them. Even if they are stock/qty bearing, if there is zero on hand, you do not have to print those count tickets - but you should if you believe there might actually be qty on the floor. I’m not directly in the count/verification/audit end of the cycle counts, so I’m not exactly sure how they guys deal with all of ‘those’ parts, but they’ve never mentioned any problems.
Parts that are on the floor but not in the database are a problem. Accounting rules see those as assets and therefore must be included in the value of inventory unless they’ve been outright expensed upon receipt. We treat a number of items this way - mostly small stuff, but a number of consumables are done this way as well. If they have been expensed, then no worries as they do not qualify for a the physical count.
In order to properly count anything, you need a tag. Might be a combination of ABC groups with C = no count, B = small group of tags that you have qty, but the system shows none on hand (or some other strange situation), and A being the stuff you regularly count.
Tags do include bin locations, and will have multiple tags if the same part# has qty across bins (if I recall correctly). As for ‘finding’ inventory in other bins - we just mark the tags with the new bin location and the folks who enter the count tags can adjust during data entry, or make an inventory move transaction right after it’s all done.
The key is to minimize your variance report in the end. Depending on a lot of factors, your variance report and it’s $$ value could equal the “change in inventory” charge that will appear in the GL. A big one of those is never something the auditors want to see. It begs the question of overall inventory control/procedures and might equate to increased auditor requests for spot checking inventory during the physical count audit and possibly during the year. You didn’t mention auditors, but we have them so I added that bit just in case.
If this isn’t clear or you just want to shoot the breeze some more, PM me and we can swap digits for a chat.
AshCycleCountMonitor_wBAQs.dbd (782.9 KB)
Steps for cycle counting and full physical inventory in 9.doc (145.5 KB)
Cycle count process(EUG).docx (3.5 MB)
5 Likes
a dozen? That’s hilarious. We would probably need hundreds if it’s for parts not where they are supposed to be. Our location control is horrible, mostly due the fact that every single shelf, nook, and cranny has it’s own bin location. That’s what I’m most worried about, if we are way they hell off, is this process going to be manageable.
The instruction really help, and it makes it look a lot simpler than I was thinking. I’ll run a test in pilot and see if the process makes sense.
One question. There is the start date mentioned a bunch. If we were to take the count, can we start up again before the counts are entered and posted? It sounds like it will be able to make the change based on what it should have been at the time of the count, even if you have been running. Is this a correct assumption? That would be pretty useful if it is the case.
1 Like
As for running while counting - we do not. We take the day and have the guys on the floor do the counts since they know where everything is/supposed to be. Only takes about 4 hours, but we have like 8 crews counting and 6 auditors spot checking/etc behind them.
Now, I believe you could start running again, but I’m not sure how any sort of audit would work. We do the audit to make sure the counts are correct - you do not NEED to do this, it’s just part of OUR process. The process of marking it as a ‘full physical’ creates a table of frozen qty counts and then the variance reports uses this, plus the new counts, plus any PartTran entries to create the true variance - as far as I know. I would really like someone else to confirm this though.
2 Likes
I believe so. But don’t dare think about recounting once you’ve let people start taking inventory.
In a nutshell, the Count date is used to capture the expected QOH. And the posting process (after Count Entry), calculates the difference, and creates a Qty-Adj based on that diff.
So in Qty Adjust screen, you enter the change in Qty. Ex: entering -10, for part/bin that has a QOH of 100, reduces the QOH to 90.
In a Phys Inventory, you enter 90 as the count for a part/bin the expects to be 100, and it does the -10 Qty Adj to get the QOH to 90.
1 Like
Hmmm,
Currently it takes us 2 days with our current system. Normally occurs on a Friday so we only lose 1 day of production/shipping then on a Saturday to fix mistakes, manual reads where the scanners have flaked out, rechecks because you can’t read someones handwriting, or the hunch where the stock controller knows like heck we have more that that was reported, they go an do a double check.
Finally, thanks for posting that information it is very useful.
1 Like
This was really helpful. The “include physical inventory” was particularly helpful, since I couldn’t find that anywhere else. Unfortunately, printing tags resulted in a HUGE number because we serialize a lot of parts. Not sure how to deal with that.
1 Like
So… since this topic isn’t ‘quite closed’ yet…
We’ve been counting inventory entirely outside of Epicor… Excel spreadsheet containing a dump of Epicor quantities on hand starts the process, followed by scanned (into Excel) inputs of quantities counted in the warehouse. An analysis is performed and manual adjustments made.
I am only now starting to read up on how Epicor wants users to perform cycle counts and physicals. Fascinating topic 
(can’t really find an emoticon for eyes glazed over).
I’m wondering if, before I venture too far into this, I can get some feedback re: a few assumptions…
- Epicor’s programs do not ‘automatically’ update anything in the GL… Correct? So, the risk is very low for ‘screwing anything up’.
- The system maintains some sort of auditing mechanism that tracks all movement into and out of inventory - so that, at count time, an Epicor/Audited versus Counted comparison can be made?
- The tags are really just the mechanism by which Epicor obtains the “Counted” part of the comparison?
- Lot tracked parts wouldn’t really impact these assumptions? (complicates, for sure, but essentially the same process?)
If these assumptions are correct, I’ll proceed joyfully. If not… cautiously!
Update: If I’m totally off base, I’m happy to accept ‘dude, you’re totally off - go read the manuals’. But, a hint or two as to where I’m off will help me focus my studies!
1 Like
First, You’re pretty much correct in your assertions. But I will say that you need to play with this in your test Database (a lot) in order to get used to the process differences between periodic cycle counts and physical counts. Mostly because the ABC code part selections of Periodic Cycles is not necessarily what you expect, and how it schedules them is kind of weird. And folks generally have a love it or hate it attitude towards Epicor cycle count process…
To your assertions:
1 - correct, but at the end of a ‘count’ you do ‘Post’ the results which is inventory transactions. Subsequent processing then creates the GL entries. I’m a bit fuzzy on all of this part, so my advice is to really test it.
2 - We usually stop production for physical counts and periodic counts are handled quickly so we do not have intermediate transactions. However, my understanding is that the difference between ‘frozen’ (when you start a cycle) counts and cycle counts is what is ‘posted’ and causes Qty on Hand to change accordingly because the system is otherwise keeping up with QOH if you continue to transact during the count. I do also recall that there is a report (Variance Report?) that will show you any transactions that occurred between freezing and count entry.
3 - yes. They are simply to obtain the physically observed quantity on hand and you can do them as tickets or sheets equally as easily. You can do sheets for small parts/bins/etc and sheets for large items/areas.
4 - good question - but correct too. Lot’s don’t change these assertions, but you must count and enter the qty for each lot, as each lot becomes a separate ticket (or line on the sheets) when printed. The cycle count entry screen has a prompt for Lot#.
Since we do not do some of this, take this with some caution - and test it all.
2 Likes
- Not exactly true. Nearly all processes that affect the GL require posting.
- Part Transaction History Tracker is your friend for this. It can be daunting to decipher at first. But it shows every time a part move in or out of inventory. And some extra info like when Qty or Cost Adjustments are made
- Tags are the count records. Both physically, and as the data that is imput during the Physical Inv.
- Lot tracked parts must be counted by lot. Just as the count needs to know the bin the qty of a part is for, Lot controlled parts need counts for their lots and locations. Serial Controlled parts require a tag for each serial number.
2 Likes
Probably the biggest point with Phys Inv that is missed, is that the Phys Inventory is just a much more controlled method of doing Qty Adjustments.
Phys Inventory
- Count the qty of a part num in a specific bin. Enter that count, and the Phys Inv determines the amount to adjust inventory by (AdjQty = PhysInv count - PartBin.OnHandQty)
- You can run reports for the total variance prior to posting.
- You can change the counts after they are entered. So a recount would just be changing the one number.
Qty Adj
- Count the qty of a part num in a specific bin. You must then determine the the amount to adjust inventory by,and enter that amount. If you count 110, and the system shows 125, you enter -15.
- There is no direct posting process, The Qty Adj’s are rolled up when you do the Capture COS/WIP process
- A recount would require doing a new Qty Adj, using the diff between the latest count and what the system thinks is the QOH since the first Qty Adj
3 Likes
Wow, this is great feedback! Thanks.
@MikeGross, I absolutely will play with this in test. Believe it or not, the concepts are similar to what we are doing with Excel, except that all of our raw material and finished goods have 2-d barcodes affixed (which includes the qty). So I’m not sure how I’m going to work the tags into this, but that’s what testing is all about. (I mean, that’s how we obtain the count - by scanning those labels).
@ckrusen, you fill in some important blanks here… for instance, I am familiar with the part transaction history tracker (great utility), and I’m now guessing that THIS is the audit trail used in the overall process.
Also re: the Capture COS/WIP, I’m thinking this is the interface to the GL. At present, we manually update the GL with inventory totals after an end-of-year physical. We do not run Capture COS/WIP, although we plan to once we start seeing some close/accurate inventory counts.
Based on both comments, I suspect that “Posting” generates the Qty Adjustment transactions, which is fine, and does not update the GL on its own.
Thanks again gents, you’ve given me a lot more confidence going into this. Feel free to correct any of my takeaways…
1 Like
You are going to be in for a world of hurt …
Here’s the expected flow within E10, and how Inventory and GL are affected. We’ll use a nice simple PO for inventory. And by “Inventory” I’m referring to just the physical counts, not the value.
- PO is created. No effect on Inv or GL
- PO Receipt Entry occurs. Inv is increased by the Rcv’d Qty. A PUR-STK transaction is recorded. At this point the debit to Inventory GL is just “stagged”. Running the GL Report for the Inventory would show no difference from running it prior to the receipt. Running the WIP Recon report will show the transaction as Not posted.
- Run the COS/WIP rollup. No effect on Inv QOH. The “stagged” GL trans (including any other unposted PartTrans) are summarized together and create a single GL transaction which is then posted.
Run the WIP Recon report for All Time, with the “Not Posted” option selected. It may take several minutes to run. Jump to the end to see the net hits to the various GL accounts. If you run the Capture COS/WIP process thes GL trans would be created.
2 Likes
Ouch! Hopes dashed!
Let me start with the easy ouch - COS/WIP Rollup is the same as Capture COS/WIP? (I don’t see the rollup in the menu)
Painful ouch… does your first sentence suggest I shouldn’t interface my inventory activity with the G/L?
If that is your thinking, should I suspect (please correct me) that a good reason to keep inventory activity apart from the GL is because managing the financial side of things is easier if we don’t have to sort through tens of thousands of inventory-to-GL transactions at the end of a bad inventory count? Is this the source of the hurt?
Yes. My bad on the name. Think I called it that because it actually combines transactions - effectively rolling them up.
That’s up to you. But we learned the hard way that E10 wants to (and eventually does) do everything. When we’d miss a step, we’d do a Journal Entry to “correct” our GL. Eventually that missed step would happen, and do the very thing that our “correction” did. Then we’d have to do another JE to undo our correction.
The “Hurt” will come from the fact that E10 will make GL all the transactions that you were doing manually.
Assuming that you don’t have any fancy GL Controls (these are things that overried the normal flow into the GL), Because you’ve not run Capture COS/WIP, every unposted transaction (Purchae Receipt, Inventory to a Job, Job to Stock, shipment to a Customer, etc … and even Qty Adjustments), will hit the Inventory GL. You’ll then need to do a JE to get all the GL’s back to what they were prior to the Cap COS/WIP process.
But then in the future… you’d not have to do GL Entries to reconcile the Inv GL at the end of the month. All the part transactions will have done it for you (once the Cap COS/WIP is run).
1 Like