Stock Status report shows incorrect cost

SSR is not showing the proper cost for a given date.
A cost adjustment was made to a part on 1/7/2017.
A Qty Adjust was made on 11/1 with a 10/31/2017 date.

image

Yet running the SSR for 10/31 (or any date before that) shows the old cost (prior to the 1/7 adjustment)

SSR for 10/31/17 (or any date prior)
image

SSR for 11/1/2017
image

and now the really weird thing…

  • The SSR run (and saved) at 12:01 AM on 11/1, with a 10/31 SSR date, and prior to the Qty Adj, shows the $152.43 price.

  • The SSR run with a 10/31 SSR date, and after the Qty Adj, shows the $102.83 price.

  • The SSR run with a 11/1 SSR date, and after the Qty Adj, shows the $152.43 price.

Hi Calvin,

I was always under the influence that the Stock Status Report only shows historical quantities but cost at the time the report runs (standard or average, not sure about Lot…)

Mark W.

Me too.
But it must also try to calculate the cost for a specific date. If I run the SSR right now, once for 10/31, and once for 11/1, I get two different costs.

The scheduled SSRS that I run on 12:01 AM on the first of the month uses “TODAY” as the SSR date. Maybe when TODAY is used, it knows it doesn’t have to back calc the QOH and cost, so it just uses the current ones. That could explain why those run correctly.

My thought is that the routine that calculates the QOH and cost for a specific date, uses the cost on the last date (prior to the SSR date selected) that there was a QOH change .

If you can figure out how Epicor calculates this please share. All of my research on AVG cost makes me think they are calculated more of a weighted average by default by taking a QOH of 10 and looking at the on hand quantity of 7 at $5 and 3 at $6 to get an average. This works fine, but understanding how they are managing to calculate that is hard. If you manage to figure out some details please share.

Josh

1 Like

I don’t think it’s possible to check what the calculated fields are doing in any of the default Epicor reports… I did hear that there was a module that allowed you to look at that information - but we don’t have it, so I can’t confirm or deny this.

I assume they use the cost (however calculated) of the last part tran record with a date <= the SSR date.

edit: added “last”

The average cost = ((current QOH * prevAvg cost) + (POUnitPrice * RecvQty)) / (currentQOH + RecvQty)

Where things go to hell is if your QOH goes negative, then it’s just the POUnitPrice * RecvQty. Timing is everything with Avg or Lot costing.

Mark W.

Stock Status can compute retroactive quantity but not costs. My agency got around this by creating a BAQ report that mimics the report and exports automatically each night at midnight.

So when you say “but not costs”, you really mean they aren’t accurate.

I used to think that only QOH was back calculated, and that the current cost was always applied. But the following shows that it “tries” to back calculate the cost, as two different costs are shown when using a SSR date prior to today.

The following is the built-in SSR report (original RDL file), with the built-in RDD for the StkStat report. Run with SSR date of 10/31 shows a unit cost of $102.83. Running it with a 11/1 SSR date shows the unit cost of $152.43. So it is definitely trying to back calc the Cost for the SSR date.

My problem is, that the cost of the part on 10/31 was $152.43, and had been that since 1/7/17. Yet it shows up on the SSR as the price from prior to 1/7/17.

My Agency Controller and I had some long talks with Epicor support (not even Mexican helpdesk, some higher up-type people) about this and the gist of what Epicor said was “it can’t retroactively compute costs but sometimes it gets it right”. Mind you we went live with E10 in January and the first time it didn’t accurately compute the retro-active costs with August. Even then it still got most of the costs correct but was incorrect for about 4-5 specific parts.

I built my own BAQ to replicate the SSR (but correctly). It uses a sub-queries to find the last PartTran prior to or on the SSR date.

It works better than Epicor’s, but accounting folks want to use the “built-in” version. Go figure.

I can post it if any one wants (I might have even posted it already)

2 Likes

Hey Calvin,

I would like to see what you’ve done if your willing to post it. This has
always been a problem spot for accounting.

Thanks,

Norman Hutchins
Systems Administrator
Howell Laboratories, Inc.

1 Like

The stock status Report has always been incorrect from a cost value standpoint when you run it using an as of date for any date other than the current date. I have not tested this yet in E10, but in Vantage and E9, regardless of costing method, you could run the report without changing the as of date and the numbers were correct. You could run the report using an as of date for the previous date and even though a part had not transactions for over a week, it would report a different cost value.
So here is what I recommend. You run the stock status report without changing the date. Then run the inventory/wip report for the associated inventory account (summary fashion), for the date range from the last capture cost wip to the current date. You need to include non-net bins on the stock status report. This will typically allow you to reconcile to the GL.
So, in general, I tell all my clients, to never change the date on the stock status report.

Rick, thanks so much for the insight. This has been a ongoing nightmare for the inventory accountant and I hope your response will help. Thanks so much…

Best regards

Mike Abell
IT Manager

Flexial Corporation
a company of BOA Group
1483 Gould Drive, Cookeville, TN 38506, USA

Phone: +1 931 432 8408
Fax: +1 931 432 1889
Mail: mabell@flexial.com
Website: http://www.flexial.comhttp://www.flexial.com/
http://www.boagroup.comhttp://www.boagroup.com/

FWIW, I’m seeing the same thing in 10.2.100.3, but for the first time, we’re getting a standard cost part showing up with zero costs if not run for the current date. We are wise to heed @Rick_Sexauer’s advice.

Separately, I’m going to post a Documentation feedback so the help file indicates this reality.

Mark W.

I don’t want to beat a dead horse, but we have also seen the same problems as @ckrusen and @jlstraight1985. Something seems to have changed in the recent 10.1.600.x updates that is causing this behavior.

Epicor Help says the “report total on this listing will show your inventory value based on costing method of the part and quantity available in inventory…it can show comparable information to your General Ledger as long as the capture process has been run and is current for the fiscal period.”

The “Stock Status As Of Date” report parameter clearly implies that the results returned should be accurate as of the date entered; otherwise, why is it there to begin with? This seems counterproductive.

We are suddenly seeing some standard cost parts randomly showing a zero unit cost on certain dates but not others (none of which are the current date). We never saw this occur before. This has to be a bug, right?

1 Like

Just went through this in 10.2. Basically, the word is that you really should only run the report for today. The As Of will give you quantities as of the date but the cost is non-determinate. It used to be the Costing Method of the report on the day you run it but we are seeing zeros as well.

I’ve submitted feedback to the Documentation team to make this clear. It might be smart to have two reports: Stock Status without the As of date with costs and then a different Historical Quantity report with the As of date and no costs. It would save several days a year in Support calls alone.

Others on this list have done BAQs that get fairly close I hear.

Mark W.

Thanks Mark, that makes a bit more sense. At least now I don’t feel like I’ve been taking crazy pills for the last month.

Cheers!

Hi @ckrusen,

We are on the same page and getting same problem. Could you please share this Stock Status baq?

We never officially deployed it, but I’ll see if I can dig up what I had done.

Note, that we use Average costing, which isn’t exactly the same as FIFO. Similar, but not the same.

I only had to find the newest transaction (of a type with cost) <= to the SSR date.

So for you to accurately determine the value of inventory on a certain date, you’d have to run ALL of the part trans (or at least as far back until you hit a time when the balance was zero).

See my post about emailing yourself the SSR report every day at 12:01 AM. This doesn’t account for trans after that date, that are back dated. But the report should be correct at the time it was run. If back dated trans exist, manually back them out.