I had to weigh in here. I’m sorry, but I just cannot understand how anyone can think that SSRS is good to work with, or is better than Crystal. I’d love it if they went back to Crystal, although I’m fully open to moving to something better and more modern than both as @josecgomez is advocating for.
I think I can sum up my opinion in a use case and a screenshot. Have you ever tried adding just a single new table or even field to a report with the SSRS tooling? When you get to the part where you have to open up this gigantic mess of a string that looks kind of like SQL and find just the right spot to add you magic string to inject the new table/columns, with just the right amount of plus signs (+) and double quote (") wrappers, I just felt so dirty. Like a really bad code smell. I’ve only had to do it once or twice (we’re still running a lot of Crystal), but I just knew: this is not scalable, this is going to be a nightmare to debug, and I’m never going to be able to train anyone without some serious programming chops on this. (Okay, to that last point, I’m strongly in the camp you still need software dev types to use most lo/no code tools, doesn’t matter how many widgets you wrap code in, Betty from accounting is never going to understand even where to begin with them.)
Give Betty more credit after all I guarantee she figured out how to use the Runtime Template Engine to make her Epicor look like a Unicorn Threw Up on it
Seriously Betty you can’t figure out how to do a cancellation invoice but you made the ERP look like a strawberry shortcake documentary?
Your example illustrates that the specific report is bad, not SSRS… There is nothing preventing you from properly formatting the query so that you can copy and paste it in a text editor and easily edit the query. It’s just that Epicor did not do that on their stock reports… It’s a SQL query formatted in a VB string.
Could it be better? Sure. It could have a query builder tool in there… Is it absolutely needed? No, definitely not…
I have to agree with @HLalumiere , every report I touch I go into the query and format it. The formatting stays so the next time you don’t have to. Should I have to do this? No, but it is a minor inconvenience that makes my job easier. I wish Epicor had done this up front.
I’m not really a huge fan of query builder tools anyhow, let me just write the SQL directly for sure, or point to the XML, whatever - but with something that gives me strongly typed results with error checking (Crystal / XML) or at least syntax highlighting and auto-completion, something modern. Even if the SSRS report design tools had such a thing, the whole “manually concatenate a GUID onto the end of each table name as a string” thing would probably break that. But sure, maybe if I took the time to fix formatting (as much as possible), copied it into VS Code to edit it, renamed all the T1, T2, T3 references, etc. - might make it a little less , I’ll give you that.
I don’t believe it’s not “supported”. It’s more of not maintained in the standard reports. I’ve said this since 10 was originally released, crystal will not go anywhere.
For reports designed to be printed on paper, Crystal designer was superior. However, SSRS is really good for making reports designed to be exported to Excel and NOT printed on paper. Crystal was more a struggle in that regard and we all know how much the accounting department loves their Excel.
That’s a very fair point. For us, we do the Excel based reports right in Excel for the most part using tools like Spreadsheet Server, but if you had constraints (like you were cloud hosted) I could see that maybe not working. So we tend to just be the paper-based “reports” (AR Invoice, Order Ack, SO Picklist, Packslips, etc.) out of Epicor. But that’s us.
It’s a dynamic SQL query. Which, yeah, SQL sucks at variable table names and having to make it a text string where you inject your variables into it is one of the great sins of technology IMO. That’s more of a general SQL issue.
For Epicor specifically, the whole Tn aliases are even more annoying. It obfuscates something that should be pretty clear: table names.
Speaking of abandoned outdated, poorly implemented products. Quick-Ship is anything but Quick. The fact they still stick with Crystal when Epicor dropped it, is proof enough. But they make soooooo much money on custom SSRS, why would they move to a better solution? lol
Add a QR Code to SSRS…good luck.
My 2 cents.
I am another of the ‘I don’t mind SSRS that much camp’. Not to say I would oppose replacing it but I have bigger issues with Epicor than SSRS.
I would also say that a lot of my frustration with SSRS, particularly in the early days of going from E9 > E10 were with how they write their DataSets and the use of aliases on table names.
My other big issue with Epicor reporting is hiding the calculated field calculations, I don’t know how many times I’ve had to tell people that I have no idea how Epicor is reaching their number because it is calculated in the code that I don’t see.
Neither of those things would necessarily be improved by replacing SSRS.
I also agree that Grow, Power, etc are not really replacements as far as I can see for the requirement of document production so if SSRS were to be replaced as the default I don’t think they would fit the bill.
