Our company is currently in the process of upgrading from Epicor 9 to Epicor 10.2, but it won’t be another two our so months until we have a test environment to work in due to us waiting for the new release that’s expected around then. Since we won’t be able to work much on testing our updated BPM’s and other customization until then, I was thinking I would at least start the process of recreating our reports in MS Report Builder 3.0. From what I can see, it looks like SSRS uses a dataset SQL database instead of creating XML files like Epicor 9’s report software does. In this case, does anyone know if it would be easy to update a MS Report Builder report from an XML datasource referencing E9 tables to the dataset SQL datasource with E10 tables? We are currently looking at several hundred Crystal Reports that need converted, so the sooner we can start this process the sooner. Any clarifications or corrections on assumptions I’ve made here would be greatly appreciated too!
I’ll limit my response to how things work in 10.2 to set your expectations correctly. I’ll defer to others on their experiences (I am curious too. Reports continue to get a lot of care and feeding each release).
The confusion for a lot of folks around reports is how ERP 10 does ‘asynchronous’ reporting:
- You request a report
- Request is entered into a ‘task queue’ in the db.
- The task is picked up by a Task Agent (a glorified, automated client) that grabs the task as a unit of work
- Task client calls ‘RunTask’ on the server for which task to work
The server report process is where things get interesting. Is it a ‘legacy’ report? A BAQ Report? Hierarchical BAQ Report?
I can cover each of those but the end result is the data is cached into a ‘reporting temp db’. Logically think of the XML / DataSet for the single report instance cached into a db table. e.g. - a db table named <some guid>.
THAT’s the data source for the E10 SSRS reports. The Reporting Framework fixes up that for you dynamically in the SSRS RDL at report genreation time. In Report builder, the data source points at that table and you design the report against the ‘report temp table’.
So if you are prototyping some reports, you can manually craft that data in a db table like the Report Framework does. Then when you get the real system, you will iterate thru your reports to point at the correct data source. The data shape should be the same, just where you are looking for data will change.
I would not convert them in E9 using the E9 SSRS Portal Stuff. The SSRS from 9 to 10 is vastly different in my opinion you’d be wasting your time.
As of now, the BAQ Reports are probably my main concern. This is mainly due to how many of them we currently have and it also allows me to start off with recreating simpler Crystal Reports until I have a better understanding of how MS Report Builder 3.0 works. One question as well to go along with this, can you clarify the roles/differences between SSRS and MS Report Builder 3.0? Specifically, is MS Report Builder 3.0 (this seems to be the current version, from what I’ve seen) a subsection of SSRS where the reports themselves are actually created and maintained?
Thank you for the response as well!
Report Builder is the … Report Building tool (ala Crystal Deloper Studio)
Do you think it would be worth it to at least try creating a few? One of my main concerns is that many of our Crystal Reports are very complex and I want to make sure that it is possible to recreate them in the new reporting software. I’ve heard that the MS Report Builder doesn’t provide as many tools as Crystal Reports, but I’m not sure how often that’s been a problem for Epicor users who have made the jump from Crystal and had to recreate reports.
Kevin,
In my experience of migrating from E9 to E10, most Crystal BAQ Reports move without many issues with the potential exception of schema changes that can cause issues with your BAQ and thus the BAQ Crystal Report, but they are usually easy to fix, depending on the complexity of your BAQ. While Epicor does not officially support Crystal, they didn’t really break the functionality. The main issue with Crystal Reports support is with the RDD of the standard reports, as any changes to the RDD is not tested against a Crystal Report.
I have a few clients that are still using their Crystal BAQ Reports. It is best to convert them, but it can be quite a load… the real question is, are they all still needed? Could many of them just be dashboards? A common issue is when someone asks for data they use the term ‘report’ when many times a dashboard will work fine.
Thankfully we’ve already gone through and narrowed down many of our reports to remove in the upgrade that ended up never being used or have become irrelevant over time due to various reasons. But, the new use of subqueries in E10 is something that will probably allow us to recreate some reports as dashboards which we can’t currently do in E9. So, I’ll have to look at some of our more utilized/complex reports with that in mind now that you’ve mentioned it!