We use Lot FIFO.
@TomAlexander There is your problem. In your test system change that part to be Last or Average cost and run the report again. If it doesnât take a similar amount of time then I would definitely report it as a bug.
Lot FIFO has certainly caused its share of problems for us, but the majority of our parts are Lot FIFO and the SSR is not having any problems with them. I feel like there has to be some kind of bad/weird data in PartTran for this particular part, but I canât seem to find anything. Support has our database and is trying to figure it out as well.
@TomAlexander No, I donât think so. I think the issue is a bug with Lot Costing on Epicorâs side. In your test system run the stock status for a part with a high number of lots. In my case I ran if for a part with 80,623 lots. With Lot Average costing it took 25 minutes to run the stock status report with a single part. With Last Cost it ran in seconds.
âRUN THIS SCRIPT IN YOUR TEST SYSTEM
update erp.Part
set CostMethod=âLâ
where partnum=YOURPARTNUM
update erp.PartPlant
set CostMethod=âLâ
where partnum=YOURPARTNUM
Thanks for all your suggestions John. I think I might stand up a throwaway Test environment to try that; donât want to do it in my âgoodâ Test environment!
@TomAlexander I understand. I can report the bug to Epicor if you want but I really donât want to have to deal with them to get it accepted.
Calvin
Now I need to spend some time looking for these problems.
Do I go down this road if support just loaded my database for their testing?
Scott
Iâd make a BAQ (or use SQl if you can) to see how bad the problem of having partwhse records with warehousecode = "" and onhandqty = 0
Blank warehouse code is 7 items. All have 0 onhandqty.
Gives me something to do.
Scott
@scott , @John_Mitchell , @ckrusen , et al.
Not only did we narrow our problem down to a single Part, we narrowed it down to a single PartTran row.
We had been working with Support on this issue and after not getting anywhere for a while they recommended we try cleaning up various data oddities. Orphaned records on PartDtl, open allocations, etc. One of these items was future dated Part Transactions for our problem part (some user typoâd the date to be in the year 5,000). We decided to deploy a fix that changed the TranDate to 3/1/2021. As soon as we did that (a few days ago), the Stock Status issue went away. I can run it wide open now and it takes about 20 minutes.
Then I experimented a bit more with the date parameters on the Stock Status report. If I backdate it to include 3/1/2021 in the dataset, then the issue comes right back. It seems to be just one PartTran row thatâs throwing off everything.
We still donât know what it was about that row that caused the issue, but at this point we are just happy that we found a way around it.
A word of warning for any one thinking about using the Inventory WIP Recon report to find future trandates ⌠DONâT DO IT!!!
I entered an end date of 12/31/5999, and it continued to run for over a week, before I terminated it. And now I have an orphaned âactive taskâ. It shows on the Active tasks sheet of System Monitor (but isnât actually running).
1 Like
Lol, yep weâve done that a couple times in this whole ordeal. Best thing to do is just a simple SQL query or BAQ: select * from erp.parttran where trandate > â04/01/2021â (or whatever the date is)
We did the future date thing last week. This week it was Part. Dtl, Qty, and Whse for partnum being null.
Still not finding anything.
Yesterday support called to verify everything we have done before they moved this ticket up a level.
While we were talking and looking at report parameters, I just started the report. It ran in 30 seconds. Both with the default form as well as my custom.
Almost a month ago I ran the Regenerate Data Model. My notes donât say that I restarted IIS. We have restarted all servers each weekend. Some combination of actions solved this problem, as well as an issue with DMT not running when connected to one app server.
I still need to go back and look at data problems.
John
Back in March just before support escalated the ticket, it fixed itself. I hate saying that.
Either another regenerate data model worked better than the one I ran the previous month?
Or server restarts kicked something properly after the previous regenerate.
The report now runs in under a minute as expected. We went from 59 minutes to 1 minute.
A future dated transaction does not have an affect as we run it with current date. I know because I now have a transaction dated out to 2031. Something to look at after the season ends.
I have moved on to working on other items that could be slowing us down overall.
Itâs a mystery to me.
Scott