We’re migrating to Kinetic from another vendor and are currently in the testing phase. We’re on 2025.2.8. We are finding the SSRS reports are extremely slow.
For example, the Stock Status report takes 20 minutes to run and show up in the client and will have 360 pages. Another example is the Inventory/WIP Reconciliation report can take anywhere from 3-15 minutes to run, depending on how much data are there.
Where is the bottleneck? Where are the inefficiencies we can look into? Our Epicor SSRS trainer just shrugs their shoulders. Our implementation partner just says, “Wow.” What can we look into to get these reports to run in under a minute?
Did you make any network changes or upgrades to your servers (app or db) recently? I’m not an expert on that kind of stuff, but it might be worth looking into where everything is and what’s being going on on the bigger network side of things.
We are midst migration and almost every single time I have a problem with speed or functionality it’s because of “patch Tuesday” or “oh, yeah - we moved this from here to there and didn’t know it would impact Epicor.”
Good luck!
If you say those numbers are what you would expect, that’s kind of wild that Epicor hasn’t seriously tackled this issue. Unfortunate. We’re not that big of a company, but will admit we have a lot of active parts. I’ve written my own report for this in T-SQL that takes about four seconds. Now working on running it offline via Crystal Reports 2025. It’s gotta be the SSRS reporting engine.
Those other reports are pretty timely, all at or under 30 seconds.
Since we’re implementing now, there really aren’t any changes. Hence, the question about where we could look for inefficiencies that others may be aware of.
Since they are on-prem they could plug the SQL into a custom SSRS report and run it directly to see.
I’m not sure how much is SSRS induced time though, I have not looked at those reports but Epicor doesn’t normally do calculation in the RDL themselves from what I have traditionally seen, they do it further upstream and then present that data to the RDL.
I’d really be curious though if the results generated were always the same as what the Epicor version shows, I suspect that the SQL being written to replace what Epicor is doing in the RDD is not doing all the same calculations. My concern here would be that it may appear or be correct 90%+ of the time but given the importance of these reports having it be off even occasionally would not be accepted here.
Don’t get me wrong, if it was that would be great as it would mean there is hope Epicor could resolve the issue for everyone, I just don’t know. I am fairly certain from conversations I’ve had in the past with Epicor support that the Stock Status Report is known to be less than perfect, you can’t run it accurately back-dated and that it is not designed to be a sub-ledger (might be getting the term wrong, I’m not a finance person).
That sums it up well from my experience. Add to that: the occasional SSRS outright/random fails (PRB0304935) that seem to plague cloud customers…don’t think it extended to on-prems though.