In Finance, we have been using the stock status report for the finished goods quantities/valuations. It has been brought to my attention that this quantity does not match the number of PCID’s we have (by pulling the stock status with PCID’s and counting), and does not match our physical count.
Some of the parts have the same quantities (stock status, # PCID’s, and physical count), but 80% do not match, some are lower, some are higher.
I’m not sure where to start in figuring out where the discrepancy is. Does anyone have any experience with this? Thank you.
If memory serves, the Stock Status Report is always calculated. It adds and subtracts all inventory transactions from the dawn of time up through the specified As Of Date.
I have to admit that I have not attempted a PCID inventory reconciliation but I have also not yet had any complaints from the users on that (looking for wood to knock on).
One of a few things I could see being problematic would be the date used to run the stock status report. If I was running this for say last Friday, but looking at PCID info from today, those could be off by whatever transactions we did in between.
I’m not sure what your PCID process looks like but that can be Staged (not yet received) as well. These should not be on the Stock Status report as they are not yet received to inventory but would have valid PCID labels most likely.
I do not believe the Refresh Part Quantities utility would affect the Stock Status Report, but it could affect your PartBin and/or PartWhse tables.
If you know those are good, I’d build some queries to compare your Inventory to your PCID’s. PkgControlHead and PkgControlItem would be your PCID tables and PartBin should get you your current on hand inventory. In theory they should match if all inventory exists in a PCID or at least the ones that are PCID’d would match.
I have a new update after looking over the stock status report, PCID report, and physical count reports. It looks like there are quantities of inventory that are not coming out in Epicor that affect the stock status inventory. For example, we had qty 233 of TF25AB42 on 02/16, verified by physical count and stock status report. On 02/23, there were 204 listed on the stock status, but 176 by physical count. The stock status matches what the system has, started the week with 233, added 47 from production, subtracted 76 sold, equals 204, but the physical count is 178 and no one has any idea what the difference is from. This is a missing amount of 26 pallets.
We did a new physical count today and compared stock status, with number of PCID’s, with physical count, and everything matched for this week, except the missing 26 from last week. The system shows 26 more than we physically have. The stock status report bundle quantity is 252, but the number of PCID’s is 226, and the physical count is 226.
I don’t think there is a way to pull the PCID’s that were in stock on a certain date, if I could, I could compare and see what changed.
The other finished goods stock where physical/PCID count does not match the stock status quantity are unchanged in incorrect quantity. For example, TB31215W showed 9 more on stock status than physical count on 2/16, 2/23, and 3/2 (our week ending date).
That being said, I’m not sure if this is a stock status report issue or an issue with missing product, but no one knows why. I’m meeting with ops and logistics on Tuesday on-site to discuss this more.
I just wish there was a report that gave the PCID’s on a certain date. Maybe there’s a BAQ I can create for that.
Correct…and it’s making it extremely difficult to do any sort of reconciliation with the Stock Status Report against the G/L. From what I was told by Epicor Support, the SSR “onhand” at a given point in time is the sum of PartWhse.OnhandQty and PartWhse.NonNettableQty…plus/minus whatever happened with PartTran for the “as of” date.
Going to try a data capture on the first of the month that, in theory, should be at/close to the opening GL balance for the period…as there would be no inventory transactions on that first day when captured. Gotta start somewhere.
Note that PartWhse is based on the stocking UOM…unlike PartBin which is UOM-specific. The same part/site/whse/bin could have balances of 1 PL, 1 CT and 1 EA…so if you try to calculate an inventory value on PartBin, you’re likely to see variances (likely slight ones) to the PartWhse totals based on conversion/rounding.
This is an old document, but I would wager is still pretty accurate although it does predate the existence of PCID. KB0037298 Stock Status Report Notes
I feel like there used to be a more detailed version of that floating about but I can’t seem to find it at the moment. I think the last bit is important and might contradict what I said in the earlier post.
It sounds like it doesn’t calculate from the dawn of time, but starts with the Part Tracker On Hand Quantity and works forward or backward from there based on PartTran.
This makes it susceptible to the problem where PartWhse is just wrong but is theoretically fixable with the rebuild utilities now.
Well, if you can’t trust the Stock Status to do that, you might have to figure that out on your own. IF you have Archive PCID History enabled, they archived PCID’s will be in HXPkgControlHeader and HXPkgControlItem.
If not, the PCID field will be in PartTran. I would think that if you summarized the transactions on Part and PCID you could build a net total of what should be on hand for a given date cutoff? SysDate would be the day it really happened and TranDate would be the day they chose for the Apply Date. Might even be worth checking both.
If the link doesn’t work, you can search the KB article manually. It should come up searching KB0037298.
PartWhse is’t ALWAYS wrong, but it;s wrong often enough to be a significant hassle. I can tell you that I never use the quantities stored there in any of the BAQ’s/Reports/Dashboards that I build as a pre-emptive effort to save myself time and energy.
That is why the Refresh Part Quantities and Allocations utility exists. The good news is that this utility fixes that problem. The bad news is that there’s no way to know for how long it will stay fixed.
LOL…we haven’t noticed too many problems with our inventory balances being out of whack…cyclecounts have been minimal from what I recall. Even so, the spectre of potentially bad values is not one that I want to think about.
