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!
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.
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.
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
@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…
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.
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).
The Capt COS/WIP process allows you to enter a cutoff date that effectively does that. But that is playing with fire. If someone forgot to set it correctly …
On the plus side, the WIP Recon Report will show you the summary of the GL transactions that will be created.
For example Running WIP Recon (Actually called “Inventory/WIP Reconciliation” ) with a date range of 4/1/2016 - 4/30/2019 (notice the start date is 3 years ago), and only unposted Transactions, shows about 10 pages (about 300 transactions), abd the summary of
So you’d only have to make 1 JE for the 15 accounts shown, to “undo” the effect of this one-time “catch-up” Cap COS/WIP processing. And a lot of those netted to zero (like the 5 of the bottom six. Accts 6150-00-01 thru 6303-17-01)
Wow that is risky. My finance guy will have a conniption when I share this with him.
Okay. I have a much better idea of what I’m in for, and plenty of time to stock up on Pepto.
Thanks a lot for the great information. it is truly appreciated!
As Mike pointed out, you want to make sure that ALL transactions are in before starting a count (and freezing the quantities) or you will be off by the unposted transactions. A clean cutoff for cycle or physical count is paramount!
Blank tags. If you don’t get a tag for something then it doesn’t freeze the inventory. When you complete the count, the frozen will show zero and you tag will show X. When you post, it will add X the current inventory (whatever it is) and you’ll see more than you should. This usually happens when people don’t create a tag for quantity zero but there are actually parts in stock. It’s just one of those weird gotcha’s to lookout for.
Mark, this is something I’m going to have to see in order to understand. @MikeGross got it immediately, but I haven’t started testing yet; I’m working strictly off concepts at the moment. But now that I’m aware, I can attempt to test this.
Freezing inventory activity is going to be a problem as that is a part of our current process. The physical counting will be an interesting challenge though.
We affix labels to everything that goes into our warehouses. Our current manual process involves opening a spreadsheet and scanning each and every one of those labels (for a particular part - if we’re only counting a part); An operator scans a code into cell A1, and Excel drops to the next line awaiting the next scan. After everything is done, I run a few macros that extract the various elements from the scan (partnum, qty, lotnum, etc.)
With that manual Excel based process in mind, and having not even seen a “tag” yet, does anything come to mind in terms of tying our scanning function to Epicor’s collection of tags?
Thanks for the April fool’s warning @ckrusen, I decided to run the recon last night. 25 thousand pages resulted! The last page (like your image of the G/L Account Recap) is the significant page, BUT… Epicor won’t attempt to post 25K pages worth of inventory adjustments to my GL, will it? The Rollup that you mentioned should trim that down significantly(??). Now I’m concerned! (Humor, and appreciation intended, Calvin!)
Andrew, the 2D barcodes presents an interesting challenge. In the usual/normal process, the tags and sheets can have barcodes and you can modify(like we have) those both to include additional information to make it easier for the guys taking the count. They get a stack of tickets, write in the visually verified qty and return them. The data entry folks scan the part# into Count Tag Entry and enter the qty on the tag. The system does the rest of course.
Now, we should also mention that there is an epicor handheld app that will do inventory counts electronically. Search for “Epicor Handheld” here and see the various discussions on hardware. I have not checked, but I think the handheld software can now be run on any IOS/Android device as it now available via Epicor Web Access. This might be key for you if you can get the 2D barcode support to work.
Otherwise, if 2D support isn’t possible, I think you should consider using DMT (the tool for doing mass uploads via an Excel or CSV file). I think you could continue to use your spreadsheet/macro/2D scanning method - adapt your macros a bit for the required data columns for DMT - then upload that XLSX using DMT and bada-bing!
Something to note about DMT and Count Tags: I’ve never had any luck using DMT to upload tags without DMT crashing (currently on 10.2.300.6). We ended up creating an updatable dashboard that lets us paste-insert the filled-out tag information and then save. This cut down our tag entry times from hours to minutes.
Very interesting, Mike. Thank you. We use the Handheld module - for picking orders.
I’ll have to investigate the inventory counting options that are available.
I really appreciate the breakdown of the physical process (both from your earlier posts [re ABC codes] and now) and your thoughts on possibilities for counting. This sortof head start is exactly what I was hoping for.
I aim to find a few days to test all this out next week and, armed with all this information, it’ll be a good workout! I’ll report anything interesting back onto this topic.
(can’t really find an emoticon for eyes glazed over).