Can anyone out there that is on E10 refresh my memory or enlighten me as to whether there is something that has to be done to RDD’s when converting from E9 to E10? I thought I saw or read somewhere that due to schema changes, existing RDD’s had to be modified / tweaked in E10.
Thanks for any all information!
Carol
Just a suggestion. Open both E9 and E10 RDL. Copy layout section from E9 to E10 and then tweak tweak tweak.
Yes, any RDDs that you added fields to for reports will probably need to be reviewed. I did it the hard way. You will want to do it the easier way by using the new RDDs and adding those fields into the new RDD. Don’t try to make the new RDD look like the old RDD, just add the extra fields you need.
First copy your E10 RDD. Add all required fields, pay attention to schema changes from E9 to E10. don’t forget to condiser linked fields, if you had used in E9 to new RDD.
I feel like your question was answered but wanted to add my 2 cents…
We are working on migrating from E9 to E10 and I’m starting to rebuild my RDDs in E10 for my existing Crystal Reports at this very moment. So I can speak a little on how to do this for existing E9 Crystal Reports.
I’m taking the base E10 RDD, duplicating it, and then opening up each of my Tables in the Crystal Reports Field Explorer and looking for all of the fields that are being used inside the report from each table (the fields will have a little green check mark next to them). Once I get all of those Fields added to the new E10 RDD, I set my Custom Report Style to my newly created E10 RDD and try to run the report. It will of course complain if you are missing any fields and you just add them and try again. But remember that you have to close out of the Crystal Report each time you go to run it or it will complain of the report being locked by another process. Such Silliness… 
Just an FYI, in one instance I was using a Linked Table (ShipHead-ShipToNum) in an E9 RDD that no longer exists in the E10 RDD. So after a long time of trying to add a Table and Relationship with no success (I’m still really concerned that I couldn’t get this to work but was able to find a “work-around” in this case), I thankfully managed to find some Calculated Fields that were very obscure and inconsistent in their naming convention. It was something like ShipHead.Calc_stFax (for a Ship To Fax), and also ShipHead.Calc_SEmailAddr (for a Ship To Email)…so just a heads-up in case you run into a similar situation. These were critical fields for us because they are being used by APM. I’m embarrassed to say but I’ve been beating my head against the wall on that one for FAR TOO long so this seemed worth mentioning to possibly save someone else some frustration…
Just look at and test those Calculated Fields VERY closely to see if they could be used to give you the data you need.
Heather …thank you so much for sharing.
We have quite a few Crystal reports that use a modified RDD. My work load will be heavy for quite some time 
Carol
Thank you all for the help and replies!!
Carol
Oh @cpelowski, I feel your pain… I’m already developing “twitchy eye” or as Doc McStuffins would call it (I have a 2 year old) Twitchy-eye-a-tosis! LOL
Good luck with your rebuilds…I don’t want to get your hopes up too much but I think there might have been one or two cases were I didn’t have to rebuild the RDD and the report just worked from the migrated E9 to E10 RDD…so it’s worth trying to run the reports first before you spend too much time rebuilding the RDD in E10. I hope you find that’s the case for some of your reports too.
Please let me know if you run into anything and need an extra set of eyes (okay, maybe one good non-twitchy eye) on it…I’d be happy to “TRY” (key word here) to help! 
One other aspect to note on any new report endeavor…
Everyone should look at the new BAQ Report functionality for doing hierarchies that shipped with 10.1.600 for electronic compliance. If your report is just minor tweaks to default reports then might not be an issue. If you are doing some serious changes, look at how these are built and put together as it is a much easier mechanism to support thru upgrades and easier to understand / build.
High level -
Build BAQs to represent the tables of data you want on the report.
Link the tables together in RDD.
Connect the report to those tables.
What this gives you are standard building blocks in BAQs that can be used by reports, dashboards, customizations, etc. It allows for easier reuse of your logic across the product and save you some time.
From a migration story, it’s much easier as all you need to do is add any new fields added to the shipping baqs and merge in the UI widgets.
We’ll be doing more in this area as it’s the most sane approach going forward from all perspectives.
Thank you @Bart_Elia!!! I am definitely going to look into this new BAQ Report functionality. I was just trying to get our Crystal Reports working as quickly as possible doing the only thing I was familiar with doing - rebuilding the RDDs associated with them. Thank you for the recommendation! After we go LIVE on E10 I hope we can also start converting our Crystal Reports over to SSRS reports building off of the base Epicor-supplied SSRS reports.
Pay close attention to what everyone here has said. I did it wrong the first time. Though it worked, when the next release came out, I had to redo all the RDDs again!! Painful *@#$!!!
Thanks to everyone for your input. It doesn’t sound like it is going to be much of a treat, but needs to be done. Your suggestions / advice will help.