SSRS report design: Really?

Question
am i the only one who finds standard SSRS report design a complete pain?
the standard approach seems to be as per below link,

SSRS Report In Epicor®: How to Modify an Out of the Box Report | Datix (datixinc.com)

but i a gave up ages ago with that approach and now just take the parameter to the report eg PO Number and pass that to a sub report where i have a sql view as the datasource - and i have total control on what i show with zero faffing around.

but I am circling back now, as i dont want that to become the approach i show the rest of the team - surely now in Kinetic there is a simpler method of pointing to an epicor data source and tables/fields that are available can simply be selected?

how do you guys approach this?

Mal

Not securely. This would mean that the SQL service principal has access to the entire Epicor Data source overriding all Kinetic application security. If the SQL service principal were accidentally given write access due to a misconfiguration, any report designer could have full ownership of the database.

The current method extracts the data that the user has access to and creates the temp tables which are reported against which uses least privilege access, allows rerunning of the report, and deletes the data after a given time period.

However, there is room for improvement.

4 Likes

Yeah…fold the dataset stuff it all into the vastly superior BAQ designer. Report Data Definition is godawful. I’ve never had to restart a BAQ because it decided to eat itself.

There a Epicor Idea on that? I might make one.

1 Like

You can already make RDD’s based on BAQs and its much faster / nicer than the regular ones. :slight_smile:

What they should do is move all reports to use use that.

13 Likes

The BAQ Report Designer should also be collapsed into BAQ Designer and/or Report Style. One place to build your datasets. One place for building reports. No intermediary apps.

I’d settle for them simply moving everything over though. RDD needs to be buried.

4 Likes

Yes!

thanks for input folks,
i get the security concern, but end of the day a badly configured odbc link in a spreadsheet is as much a security risk, and when the functionality is as is, people find work arounds - thats when security risks can get stretched even further.

so are we saying that, i could create a new RDD for the Sub con pack list, and base the RDD data on a BAQ that i have created? which ultimately would give me exactly what i want! is that correct?

1 Like

Yes you can do that and even use multiple BAQs

2 Likes

sounds much better! see i knew there had to be a better way of doing all this :smile:
thanks jose

mal

1 Like

so i can see that this is exactly what i am after - if i just get it working
i have a baq and its added to report definition, which is part of my new sub con pack list report style
i can down load the ssrs report and it has my baq fields available!

nearly there, but how do i handle the parameter that epicor would pass to the report - TableGuid ?
do i do that at the BAQ? how do i know what exactly is being passed here? i assume its pack number, but maybe its other details!?

mal

Check out this thread… I’ve used it to walk me through a couple of these “Advanced BAQ Reports”:

For the most part, I think the step you’re on is building a “Criteria Set” in your RDD. So when a user runs the report, they will be prompted to fill in the required parameters that then get passed on.

1 Like

I have a service account for DataReader only, but I understand what you’re saying.
BAQ Reports are a pain but will be supported. Generally I try to do those first.

Most of the standard reports are so complicated they might as well be written in a different language. Financial reports I usually outsource.

hi dcamlin
this is a standard erp system report, so the user cant be putting in the criteria again, they have the sub con pack open that they want to print, much like a sales order pack, or invoice - epicor passes the criteria/value to the report automatically
mal

One thing not mentioned is the “magic” that happens in some of the built-in RDD’s, that may be very difficult (if not impossible) to reproduce with BAQs.

If you need that magic,then modifying a built-in report is the only way to go.

4 Likes

ah so i feared
so really all a waste of time, its only the built in reports i am interested in - simple baq dashboards are fine for adhoc reports

pity, thought i was onto a winner. maybe its just me but, the built in reports are horrible to use - guess i just persist with sub reports for now!

I wish you could add a BAQ data source to a copy of a system report data definition. It would be the best of both worlds. I feel like somebody already wrote an idea on that but can’t put my finger on it.

3 Likes

As someone who has started working with SSRS since the mid-2000s in a non-Epicor shop. The SSRS reports in Epicor are a pain for the most part.

I see why some things are they way they are, but for the most part the RDD structure is not the most friendly to work with. It would be nice if it can just be BAQ driven in those POForm type reports/forms.

One issue I found with making your own RDD based on a BAQ is that the report is now an Ice.UIRpt.DynamicCriteriaReport.dll, as shown in menu maintenance. This is different than the BAQ report which is a Ice.UIRpt.BAQReport.dll. Currently you can add BAQ reports to MES but you can’t add Dynamic Criteria Reports to MES. I did add an idea to the portal, Allow Dynamic Criteria Report to be | Epicor Kinetic Ideas Portal (aha.io)

1 Like

Joel, did you try deploying it as a kinetic app first?

No, I did not. I will have to look into that. Still on 10.2.500 and we haven’t done anything with kinetic apps.

1 Like