Hello, Does anyone know if the default “Slow Moving Stock” report is flawed in E10? We have ours setup with a handful of transactions (STK-MTL, STK-CUS, KIT-CUS, etc) considered as Slow move transaction type under the Stock Provision Report Format under Inventory management > Setup.
I did a sanity check and and caught a few parts that had those transactions mention above with later dates than the “LastUseDate” from the report.
For example, i have one part that says the “LastUseDate” was 12/31/2015. But if i check the part transaction history, i could see the last transaction date under same tranType, wareshouse and lot number for the same part was 12/31/2017.
Is the report Site specific? In other words, does it only look at transactions in warehouses connected to the site that the report was launched from? Like how Stock Status needs to be run for each site. (obviously a moot point if you have single site)
Can you explain what the fields in the Stock Provision Report Format do? I’ve experimented with them but they’re not making sense. And no big surprise that the Epicor help is useless.
If I’m using a Time Modifier of Days, are the start and end values the number of days from date selected in the Slow Moving report?
Yes, It’s plant specific. We have 3 plants and i need to run them for each plant.
The “Stock Provision Report Format” dictates what transaction types to include in the slow move report along with the months since last used and % to value slow move. For example,
0-24 Months
25-36 Months
37-48 Months
Greater than 49 Months
0%
50%
75%
100%
So if the “Last Usage date” falls with in say, 25-36 Months, then it takes the total inventory value for that part per warehouse and then multiply by the % to give us how much inventory is considered slow moving. If a part has not been used for a while, then we usually write of the inventory based on this % value given. But if the “Last Used Date” is not accurate to begin with, then the calculation could be wrong.
The date selected on the report itself is a cut off date. But the actual calculations is based on the Days or Months specified on the “Stock Provision Report Format” and multiplied by the % next to the days or months given to show amount of inventory for each part is considered slow move/obsolete.
To sanity check, i ran a BAQ from PartTran table with PartNumber, Warehouse, Lot Number grouped to give me Max(trandate) for each part for a list of transaction types that we have in Stock Provision Report format. This is where i caught some parts that had different Last usage date compared to the BAQ i ran. The part transaction history for each part agrees with the BAQ rather than the last usage date from the Slow Move report.
I know it’s been some time since this thread was active but I thought I’d let you know that you should check the case of the Bin and WarehouseCode on the PartTran records. For example, this transaction breaks the report for us. You’ll see the Warehouse Code is “MAIN” but it should be “Main” like the rest of them.
This is still an active part and we continue to issue it to Jobs but the report will always say the last transaction date is 8/8/2012.
The SMS Report is case sensitive which causes it to populate incorrect data when the case is different than the foreign key. I have an active case open with Epicor but I’m not gaining any traction trying to convince them that the case sensitivity is the problem. You can request a SQL fix to correct anything in the past but the UI programs that create PartTran records are inconsistent when populating those fields and the BO’s do not correct the case prior to submitting the record to the DB. So any future transaction may exhibit the problem. It is still broken as of 10.2.300.10.
The Stock Status report had the same issue but that has been resolved. Not sure why they didn’t cross check other reports for the same issue as these reports report financial cost. Apparently that’s not enough of reason to dig deeper.
If you decompile the SMS code, you’ll find they like to use a method “KeyEquals” to compare strings, which honors case and that’s where it goes wrong.
In the Stock Status code you’ll notice that they use “Compare” method and specify not to honor case.
It’s been a frustrating battle with support with this issue. This is my second go around to get development to look at it. They have our database and can clearly reproduce the issue. They just throw the SQL fix at you and call it day.
