Beware: I may use the wrong terminology.
I have Production on 10.2.300 and Test on 10.2.500.
I deployed Test without SSRS because I was scared to. We only have one report server.
What happens if I reference it in the Application Server Configuration, in SSRS ReportServer Location, as shown below?
What I mean, is what happens to Production reporting? Will some reports not work?
If you select the same DB for the Report Database Name, both environments will share the same reports and storage area.
If you also have the “Import Reports” checked, it will write over any existing reports (other than what is in the \CustomReports folder).
In our 10.1.400 (production environment) our Prod and Test Apps both point to the same database.
I’d be concerned about a version change (from .300 to .500) having incompatible reports. If you do import the reports in your 10.2.500 App, they may break some of the the 10.2.300 reports. And if you don’t import them, some of the RDLs made for 10.2.300 might nor work with 10.2.500.
Technically speaking, you’re damned if you do, and damned if you don’t.
OK, so you are saying that Import Reports would very likely break Production. Don’t do that.
But Deploying SSRS without Import Reports might work OK? I mean, Production will be OK but Test might have some issues? If so, that’s worth a shot.
Otherwise, what? Make another report server? On the same SQL server?
You know, back when I tested 10.2.300 (and production was on 10.1.600), I bet I imported reports without even thinking about it. 
Making another DB for reports for your test environment is as simple as Entering a new name and checking:
The down side is that now you’ll need to copy all your custom reports to this new DB. Not too bad if you only added to the CustomReports folder, and didn’t change or add anything outside that. I can’t say that I was that lucky.
Hmm. OK, I have that already, but I could delete it and re-add if it’s easier.
This gets into that terminology that I am trying to wrap my brain around.
So the pieces of reporting are:
I know RDDs are maintained in the actual Epicor Application (in “Report Data Definition”).
RDLs can be maintained in Report Style in Epicor, or more directly from a browser like so:
http://[SERVER]/reports/browse/Production/reports/CustomReports
“Create DB” creates #4, right?
I believe 3 and 4 are the same thing. But maybe I am wrong.
Are you saying 2 and 4 are the same?
And then “Import Reports” imports them to where?
RDLs and the temp tables used by reports (like OrderHed_123456abcde4321) are stored in the DB specified by Report Database Name.
While RDLs appear to be files - based on the way they are specified in Report Style and the apparent “directory” structure you see while browsing them - they are actually stored as chunks of data in the DB.
No kidding. 
So it’s importing into the SQL DB (not the Epicor DB but the report DB). Well that is not what I thought at all. Yeah I really thought there were files in a tree somewhere.
OK so using a report database different than production is sufficient. Using the same report server is totally normal, right?
Then out of curiosity, SSRS ReportServer Location is what? The destination or where it pulls RDLs from? Or am I missing the point completely?
I would say this is okay ONLY when the two environements are the same version (not including the “patch” - the last number after the 3 digit segment)
If production is 10.2.500 and Test is 10.2.500 then yes, its okay.
BUt know that a change to a report in the test environment also (and immediately) affects the production. This is a double edged sword. If done properly, you never need to move your updated RDLs between environments
