After reading this request on the RDD… Report Data Definition - Support Table Aliasing - Relationships on Same Child Diff Parent - Feature Requests and Suggestions - Epicor User Help Forum
I’m wondering if RDDs are really needed anymore?
Since the improved capability of tools in E10, are there any existing RDD based reports that cannot be handled via BAQ?
Possible for Epicor now to eliminate RDD based reports altogether?
I think this is a good ask to improve the QoL of downstream development efforts, but I’ll bet there’s a lot invested in the legacy financial reports to run C# calculations between multiple datasources which would make it a significant refactoring effort to move these to tiered BAQs at high risk if a mistake is made. My guess is there’s a few dlls that were created by query first, make a calculation, use this as join criteria, etc. that isn’t directly translatable to just moving the queries to a BAQ. I could be wrong, and certainly it would be nice to have.
I agree @josephmoeller. Although, I wonder if Epicor could create some tables that could be linked into the BAQ at runtime to provide those calculated values. To Bruce’s point, not having to have to maintain the BAQ reporting AND RDD reporting could save a lot of development effort. I’m not sure if other Epicor products use the RDD concept but if they’re looking to a common reporting environment among packages, I would think that dynamic queries would be more flexible than RDDs. But I have no inside info… 
Mark W.
Yes, maybe not in the short term… for the developers.
But it should simplify things and open up new possibilities for end users too.
e.g. re-using BAQs in dashboards? I know I’ve spent (wasted) countless hours getting RDD report raw data into flat files for Excel users.
@bordway: don’t get me wrong… I completely agree that RDDs are absolutely terrible to deal with because of their inflexibility in customization. Over the years, I’ve had to make some bad performance concessions for reports to add additional datasets and re-join within the RDL files because I can’t get to or don’t want to touch some of the financial calculations certain reports are doing.
I’ve written a few reports with the SDK and have a general idea of why things are the way they are. My thoughts are because RDDs are inflexible, in order to reproduce we’d either need a major architecture change like this proposed or we’d need the DLL source in order to convert and customize. However, for Epicor my assumption is many of these calculations are IP just like much of their source code, which makes it difficult to run through the existing BAQ engine with the proper obfuscation.
@JeffLeBert if you ever do get tasked to cleanup as many reports with BAQ Reports… just saying IF…
Maybe you also get around to fixing… the RDLs so we don’t have to customize 200 reports because someone failed to test with normal/real data. There are so many where Part # doesnt fit, BIN, Whse… where Description doesnt grow etc
Can’t fit a proper serial number in
Let me tell you about your Adjustment Value:
So people end up with a bunch of CustomReports and no longer receive Upgrade benefits, since they are now Custom Reports. Just ask @Adam_Jones and @JohnB who made a career out of maintaining CustomReports 
Just a thought @Bart_Elia if you want to have a movie made about your team. 
And use tablixes (or is it tablii?), with one field per cell. So many reports have fields just strewn about. Even if it is acceptable looking as a print or PDF, it’s going to take major cleanup when exported to Excel
@hkeric.wci, luckily I don’t have the responsibility for any reports. My job was the reporting framework itself. Basically everything around the RDL. I would find a new job if I had to maintain reports. 
I’m not sure how to solve the problem of fitting all your data onto one line without shrinking the fonts so it is unreadable. Maybe your company has long serial numbers and short “Adj Value”. Maybe you have to opposite? Maybe you have both?
Back to the topic of the thread. I’m pushing hard to move us to using BAQs as our data sources for RDDs. As mentioned in the thread, it is a hard sell to replace an existing report that works, let alone the 100’s Epicor ships.
Maybe not a hard sell if we added up all the Support Calls around reports that “work”. 
Having a single report platform would have to save a lot of time and money. Less code, less support issue, streamlined process, …
I know, preaching to the 
Ha, reminds me of a guy I worked with who was adamant that report dev/maint was not part of his job description. A very talented programmer and easy to work with… as long as you didn’t discuss report requests.
@hkeric.wci I really don’t understand why Epicor doesn’t create an open source js / webassembly simple reporting system. They are using Ariba’s MetaUI to build their new Kinetic screens so they aren’t opposed to working with corporately sponsored open source projects.
Just call the new reporting system Kinetic Reporting!
If Epicor allows for a Part to be 40 characters… design the reports for that or remove the PartNum altogether 
Maybe make most of the Landscape or as an ERP Vendor… think long and hard, what should and shouldnt be on a form, or maybe dont allow PartNum to be 40. Point being its not just that… a bin of 5 characters breaks 20 reports
For example Serial Number, Epicor preaches they are good in Automotive… well a Vehicle VIN is a Serial Number and has 17 characters, Epicors Reports dont work well with that at all - so maybe sales needs to stop saying they are Automotive Kings.
I am just thinking in general, not picking on you your my Hero yesterday!
They don’t even consider that on UI forms…
I might be wrong, but the new ‘Compliance Engine’ is supposed to be a completely BAQ based reporting system with multiple options for output including XML and SSRS…
I have not looked into it thoroughly but it’s basis is to support the ever increasing need for electronic tax filing, digital AP Invoice delivery, and related tasks. We may need it for international regulations, so that’s the only reason I’ve even talked to Epicor about it.
The data generation SHOULD be a part of the standard product. The mapping to create files is the value-add for the Compliance product, which I would still like to get for our German requirements.
Yes, I’d agree with that - the data side of the equation SHOULD be part of base Epicor.
I’m guessing the old Crystal reports were run through some tool that purports to automatically convert them to SSRS reports. That might also explain why sections that ought to be tables are instead composed of dozens of individual text fields
To be fair, SSRS and Report Builder are some of the most wretched pieces of software I’ve ever encountered. Learning to work around their many bugs and quirks could easily be a full time job. In fact, the documentation for subreports suggests that Microsoft expects teams of people to be working on a single report.
