I am just testing out 10.2.600.15. Coming from 10.2.300.6.
I have stock status reports taking entirely too long. Other issues with slowness seems to be almost acceptable, except I have not run a heavier testing routine.
One warehouse stock status run with no one on the system. 4,300 items in Partwhse. This takes 51 minutes to run in my testing environment. In live, this take 20 seconds. Run with parameter exclude part with zero quantities.
Other document output is not noticeably different than live. We have tested POs, pack slips, invoices, etc. All of our normal SSRS documents. I have tried the stock status with both my custom and default output. Same timing issue.
Correct.
OnPrem Production 10.2.300.6 takes less than a minute. OnPrem testing with 10.2.600.15 takes 51 minutes. I just tried another stock status from another company\warehouse. It took 85 minutes. I have tried different computers. Same results.
Stock Status works by taking the current QOH (from PartBin) and subtracting out any transactions between now and the SSRS date. Try running it for today’s date. That would be the least amount of PartTran records to walk through. Maybe also try running the Rebuild PartBin from Part Transactions process, and then SSR.
Did you confirm all the other Report options were the same? Specifically that the “Activity From Cutoff Date” is not selected.
And one last thing, try the built-in style. Just to make sure it’s not an issue with a custom RDD or RDL
So
The re-indexing (badly needed) was redone. The Refresh Part QOH was done.
I have been running with the same parameters across both systems. The “Activity from cutoff date” flag is never been selected.
And this is with both the standard SSRS and custom form.
After the above work, restarts on SQL and APP server redone.
The only thing different between the two systems is that with this testing environment, the SQL and the Report server are on the same machine.
My time to run a stock status dropped a few minutes. Run time is nothing close to the production 10.2.300.6.
Looking to get some tech support to look over the machine setup.
Scott
@gpayne When I looked at it the BO looped through each lot individually instead of doing any bulk loading. This meant our performance dramatically slowed as the number of lots went up and we have over 100k lots. We had the same issue with Cost Adjustments but were able to get Epicor to fix that as a bug.
@John_Mitchell Interesting. I guess we have just been used to it since we have always been lot fifo. I was curious and just ran our largest warehouse in production that is completely lot tracked and got 440 pages in 10 minutes in 10.2.400.15. We only have at most 20 lots on one part with most parts only having one active lot.
I am planning a 10.2.700 review in January and will add this to my list of issues to check.
I ran 1 – don’t have the page count yet. It is stuck at Activity 1 for 13 minutes before it shows it is Processing. Report popped out shortly after. 4 pages.
I ran a second right after – different site – 3 pages. This one came out in 1 minute as expected.
It seems that when we updated New Test Environment to use with the 10.2.600, we also updated the SQL. A compatibility setting in SQL was not updated during this process. Epicor consultant found the problem. Now my report is back to 2 minutes or less.
Scott
WELL, after go live on the upgrade to 10.2.600.18, the problem is back. In the haze of battle, consultant was questioning at what point did I see the problem fixed. Before during after customization uplifts. I could not answer the question. We spun up a test environment without the uplifts to verify it was not the uplift.
Consultant has run a log on the 1 hour long job to analyze. I was able to identify what I believe is an offending parameter in the stock status request. I remove the “exclude items with 0 qty” and my report pops out before I can get the system monitor up. I asked for it with the Zero checked… 1-2 hours. We have less than 6,000 parts. Going to support to see if we can get anywhere.
Scott