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 
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
I went through some advanced SSRS training with Epicor. We did create a shared data source to a SQL view using an EXTREMELY limited access account. The problem was you have to remember this setup every time you upgrade, deploy to a different server. Now that we can use BAQs instead as a source, I would not recommend the workaround we used.
Jenn
1 Like
I’m not saying what Epicor has built is perfect, but I cannot think of a time when I have not been able to do what I wanted. Yes, the RDD, Report Style, SSRS environment is very clunky to work with; but it is also very powerful.
I did receive one on one training from Epicor almost 10 years ago. Wondering if other people have been trained on the Epicor environment?
1 Like
Honestly, SSRS reporting the correct way is easy enough, you just have to spend the time to understand what is happening.
The Report Data Definition generates all the source data needed to run the report. Think of it as your view. You add tables and relationships to it, includes the fields you need, and have access to extra goodies like Linked Tables (implicit relationships you can enable manually). When you run a report, the RDD is processed, and new tables are generated to hold that data in the Reports database (NOT in the main database!), with a _GUID suffix.
The Guid is then passed to the SSRS report as a parameter, and the report runs a SQL query on the shared datasource (that points to the Reports database), and the results of that query are mapped to SSRS fields in the report. From there you just bind fields in the report.
Now, if we are talking about editing existing basic Epicor reports, yes it can be a complete pain sometimes because of very questionable decisions that were taken when Epicor built the original report. Hidden fields referenced by other controls come to mind.
And then there is also the inherent limits of SSRS, but those are unavoidable…
Generally it’s very workable, and not worth abandoning safe practices to query the Epicor database directly through SQL. None of those custom views will work in Saas, and you are making migrations that much more difficult for yourself (or your successor) in the future.
1 Like
Hi hugo
You are right that on the surface of things there is nothing complex about the design of the reports in epicor but, You say “ and the results of that query are mapped to SSRS fields in the report. From there you just bind fields in the report.”
From what i have been shown, and the link i have in the original post, you still have to then edit the query and manually recreate the table joins etc, then manually add/map the new fields into the report?
And thats where we get mixed results. I would say it was just myself rushing things here, but i have also witnessed some really experienced people faff around with it, then sometimes it just works.
Mal
Right, but typically you do not need to redo the entire query if you start from a base report, you just modify the existing one, add some fields, or add a join, etc…