Can someone please point me to the Epicor Advanced Financial Reporting User Guide?
I’m under the impression that we should be able to schedule and distribute reports. This is a common requirement with financial reporting, and it should be available with any SSRS-based solution.
I was reading thru some training material (“Advanced Report Designing for AFR Course”) and saw a notation that says “Additional AFR components include the ability to import and export report definitions, as well as schedule and distribute reports”
We’d like to be able to deliver weekly financial reports, but haven’t found a way to make that happen.
Any report can be run on a schedule. Great the schedule in System Agent Maintenance and it will then be available in Report dialog. Change the drop down tnat says “Now” (or it might be “Immediate”) to the one you just created. Check the “recurring” box and it will be scheduled to keep running on that schedule.
If you’re setup to send emails, click the email button and fill in the fields. These will be used for this and future scheduled runs. As soon as you click ok it is passed to the schedule.
Big important note! When filling in the email info, if you hit the Enter key while typing the message body, it will think you clicked the OK button and send the email to the scheduler before you’re done composing.
@MikeGross Thanks for the pointer to epic web. I found the doc that you were pointing me to and it was somewhat helpful. The one I found was named “AdvFinancialReporting_UserGuide_100600” from May 2014. The AFR product looks quite different today than in 2014… so the docs seem to be in need of an update (ie. Microsoft SSRS has had a major facelift since then).
One thing that seems clear is that report scheduling and distribution is an additional feature that needs to be purchased as an add-in. It appears that we currently lack the add-in.
@ckrusen Is your comment related to Epicor-SSRS reports in general, or to AFR in particular? I wonder if the same comment applies to AFR, since it appears to be separate purchase with a separate license, and add-in for scheduled reporting.
It appears like I will have to get the ball rolling in order to purchase the “report scheduling” add-in.
Being new to AFR (still) I’m having trouble wrapping wrapping my head around the web portal. The docs say that
The AFR Report Server, part of the AFR installation pack, creates a web application which acts as an interface between the AFR application and SQL Server Reporting Services (SSRS). …
The so-called AFR web application is running on port 8000 (rather than 80) and it looks almost exactly like the normal SSRS report manager, but seems to remove functionality and introduces a separate AFR-related concerns (presumably for AFR-related licensing and security purposes). By making it look virtually identical to the SSRS report manager, I think it introduces confusion. I was just about ready to open a support ticket with Microsoft to ask them why this report manager is misconfigured and appears to be misbehaving. I’m a bit surprised that the AFR “web application” is allowed to imitate the SSRS U/I, and the SQL Server branding!
Moreover when I try to bypass port 8000 and use port 80 (the real SSRS report manager), I run into a lot of problems. So it appears that AFR is trying to discourage the use of the real report manager. I just wanted to communicate these findings in case any other users with SSRS experience attempt to use the AFR web application. You may find that it works differently than SSRS, because it is different than SSRS (but it impersonates the look of SSRS).
@dbeavon - I’ve got a copy of the 10.2.1 AFR User guide, and Chapter 8, page 324, starts the section on subscribing to reports via SSRS. So it sounds possible even though I have not done it.
Where did you see about the additional module/license for scheduling and distribution?
@MikeGross I will go look for the 10.2.1 guide. You had pointed me to the 10.0 folder and all I found was very old documentation.
There is a section in the docs like so: License Requester
Before you can use Epicor Advanced Financial Reporting, you must receive a license for the toolset from Epicor.
Within that is a screenshot of a form to help request new AFR licenses. There is a checkbox in the form to enable “report scheduling”.
Also, in the AFR report designer application, we can use help->about to review our current license. It indicates that “report scheduling” wasn’t included.
@MikeGross The first thing you will notice is that the U/I looks nothing like what is shown in the docs. SSRS is now uses modern webapp standards and runs on Chrome/Edge.
Also, the “AFR web application” on port 8000 is not an ssrs report manager, even though it has that resemblance. I suspect AFR will attempt to recreate the same subscription experience that we have in the real ssrs report manager.
I’m trying to get the ball rolling on my end to see if we can purchase this feature for AFR. It doesn’t seem like we can use the out-of-the-box ssrs features for report scheduling and delivery, since AFR seems to suppress those features of the underlying ssrs instance.
So I found out a bit more… same PDf I mentioned earlier, but starting on page 319, section called ‘Batch report Schedule’. The images are still on the older version, and the instructions do not match up perfectly either.
Now, the whole process is using the standard SSRS report delivery, so I’m not sure you even need the new license file but I haven’t gotten that far yet… the steps outlined are clearly the same for regular SSRS subscriptions (we do a lot of these for custom reports) with no difference.
But it did mention in an earlier sections that the ‘web app’ living on the AFR Web server has hooks back to the AFR Logon server/Authentication mechanism.
I did however get to a stopping point because we do not store the credentials at either the report or data source level, and SSRS sees that as an impasse when trying to set up a subscription, so I’m not sure how to proceed. I don’t know if I want to specify credentials on the data source and what that means to our AFR security (basically SSO with AD groups as the AFR security objects)… Or do I make a copy of the report & data source for those reports needing a subscription??
Thanks for all this investigation. You are way ahead of me. We are finding out from our salesrep what it will cost to get the “scheduling” piece.
On my end there are no menus to get to the scheduling/subscriptions sections of the “report manager” (or the port-8000-afr-web-app equivalent of that). I don’t think the menus become available until the license file is in place.
I will probably have the same issues you have when I get to security. One thing we’ve done in the past is assign a “report execution account” into the SSRS server configuration tool (we normally use a service account on the domain). If no credentials are specified in the data source, then it defers to use the SSRS report execution account. But I’m not sure if this will be applicable to AFR since it is a different beast than a regular instance of SSRS.
Couple more things…
First, I’m not sure which URL you are using but I’m using the following and when I right-click on a report there is an options for subscriptions. And with right-click->Manage, I can see Subscriptions.
https://[afrserver].[mydomain].com/Reports/browse/
Second, Subscriptions can only be created if the data source has stored credentials (maybe those at the SSRS Config Manger will work), so I created a copy of the datasource and fixed it with credentials. Then I made a copy of the RDL and changed the datasource to the new one. This then allowed me to create the subscription.
I have not proven that it all works, as I did just enough to get the subscription setup to work. I still need to explore the security aspect because stored credentials basically allows anyone to run any report that uses that datasource and we would need to make a copy of a lot of reports to make this work. And THAT is a management headache.
@MikeGross Thanks again Mike. I’m hopeful that we aren’t the only ones using “subscriptions”. I don’t want to be the guinea pig.
On another note, I don’t think your URL is right. I would guess that subscriptions need to be created via the “AFR web app” which is not on the default port for HTTP. The default port (80) is being used by SSRS. On the other hand the “AFR web app” lives on port 8000 so the full URL to it would be http://[afrserver].[mydomain].com:8000/Reports/browse/
As I’ve mentioned before, it would be really nice if the so-called “AFR web app” had a U/I that was more distinctive so people like wouldn’t mistake it for a real instance of the SSRS report manager. It seems presumptuous for the “AFR web app” to steal the exact same appearance and even the branding that we see in the SSRS report manager.
FYI, we are still waiting on a sales quote for the “subscription” feature in AFR. It might not be a very common request from customers.
Hmmm… Nothing answers at 8000 when added to my URL, yet my reports all run fine from the standard port 80. And I just did this install fresh last month to get to 10.2.1. Even the shortcut the installation process creates (and drops in the install directory) is just port 80.
What do the Web Service and Web Portal URLs look like in the SSRS Config Manager?
All I show are single entries for each, both at port 80.
@MikeGross Our SSRS sits on port 80 too. But with AFR there are actually two totally different web applications involved. You are describing one of them - the instance of SSRS itself. I’m surprised that you are able to run AFR reports in there. When we try to do that it says we must use the “AFR web application” instead.
… the AFR web application is the one that is configured (for us) on port 8000, on the same server. Unfortunately the appearance is almost exactly the same as the SSRS report manager but there are a number of clues that would indicate that it is not the actual SSRS. The upshot of using the “AFR web application” on port 8000 is that AFR reports will run successfully from this port, and won’t generate an error message.
You can find installation steps for the “AFR web application” on epic web.
13. On the AFR Server Component Configuration dialog
…
13. c. In the Web Service Port field, specify the port number to connect to the AFR Web Service.
…
13. e. In the Web Application Port, port specify the address line to connect to the report portal
I didn’t perform the installation myself, but I wanted to show you the installation steps that clearly state that an additional web application is used for AFR.
I’m extremely surprised that you are able to run AFR reports directly within the SSRS report manager. We use a different version of Epicor (10.1.2) so that may explain the difference but, even so, it seems like this is a fairly drastic change from one version to the next.
Hmmm… now I am super curious that maybe I did something wrong. I certainly went back and looked at the PDF (same as I used for installation) and as I recall, these refer to the URL/ports in the SSRS Configuration manager that you must establish before starting the AFR Installation…
I’m thinking now that your port 8000 was just arbitrary/default if you didn’t establish the web site/service URLs as HTTPS, and that it equates to my 444. (Installation guide, page 8, section 2.5)
More specifically - see page 12, #11 - lines b and d. This explains that whatever is in your SSRS config Manager is what URL you will use to view/publish reports. And in section 4.3 you test using that same SSRS Config Manager URL that the guide references as the “AFR Report Server URL”.
And just to make sure…
I checked the IIS manager on the server and I have two applications under my default website.
AFR Service uses the HTTPS binding on port 444 with a proper SSL Cert
AFR Web Site uses the HTTPS binding on port 443 with a proper SSL Cert
Nothing is listening on Port 8000 (Cmd Prompt, run the “nbstat -an” command)
HTTPS bindings by default listen on port 80 as well.
We use Windows Auth for SSRS/AFR security
I can connect using 443/80 to the AFR Web Site and run reports. And I see the ‘Subscribe’ option on my right-click context menus.
I cannot connect to the AFR Service on 444 - I get a “this application doesn’t do that” kind of message.
When I look at the web.config files in “C:\Program Files\Epicor Software\AFR[Site] or [Service]” it looks like it shows the application handlers pointing back to the AFR Web Service for processing - which would explain how my port 443/80 page works and can run reports.
At this point, we either have to look at each other’s system, or you need to reach out to who installed yours. Maybe there’s just something a tiny bit off. But as I re-read all of this, as long as you are connecting to the SSRS Config manager’s “Web Portal URL”, AFR should work and you should be able to subscribe…
It sounds like your port 443 is analogous to my 8000.
But you speak about 443/80 like they are the same thing!? My 8000/80 are entirely different animals. One is the AFR web application and the other one is the SSRS report manager. I suspect yours are different too. To distinguish the “actual” SSRS from the epicor-afr-doppleganger, you can append the following path after the hostname and port number:
/reportserver/reportexecution2005.asmx
… only the real SSRS instance will give access to this soap endpoint.
Another thing you can do is inspect the HTML (page source) in the home screen and that should also make it clear that the two of these are very different, despite having a similar appearance.
As far as viewing reports is concerned, only the “AFR web application” allows reports to be viewed successfully. Internally that application is passing along the requests to the real SSRS instance, but our users cannot successfully bypass the AFR web application, or the reports will fail to be rendered.
As a side note, does your port 443 ever prompt the users for credentials to use the AFR web application? Or does it pick up your integrated windows authentication credentials automatically? Ours appears to be prompting users for a user name and password, and I think that it might be misconfigured.
Oi! Now I see what you are saying. Sorry for the confusion, I think we were saying the same thing, but I was missing the direction you were ‘pointing’.3
If it helps, I run this quick test for credentials - Specifying no port number, closing an opening IE11 between each attempt, not running a report:
http://[Host FQDN]/reports - no credentials asked for, windows creds used automatically, automatically redirected to /browse
http://[Host FQDN]/reports/browse - no credentials asked for, windows creds used automatically
https://[Host FQDN]/reports - error returned (400) Bad Request
https://[Host FQDN]/reports/browse - no credentials asked for, windows creds used automatically
https://[Host FQDN]/reportserver/reportexecution2005.asmx - returns XML schema for SSRS
http://[Host FQDN]/reportserver/reportexecution2005.asmx - returns XML schema for SSRS
Since I’m not specifying port numbers, then http is going to 80 and https is going to 443, by default - which is the SSRS Web Portal URL and the AFS Web Site URL respectively. I have no other IIS binding established for any other port other than 443 and 444. Inside the SSRS Config manager we are binding port 80 with no SSL. So the only way this works is that the AFR Website at 443 (and web config handler to send auth/processing off to AFR Web service at 444) are ‘fronting’ for the SSRS Web Portal at port 80. (I guess that is where it sounded like I am saying they are the same thing… )
I can see where you question whether the reports work at port 80 as they should when I hit port 443 - and I incorrectly specified that in my last post. They do NOT work at port 80 (SSRS Web Portal) but do work at port 443 (AFS Web Site). Which then leads me to believe I was not careful enough to watch my connections when I was working on the schedule/subscription question to begin with.
I’ll take another look at this, and take the blame for extending this conversation so far. It has, however, clued me in to the finer points of the AFR setup and I thank you for that.
Thanks for taking things this far. I’m glad I’m not the only one scratching my head about how AFR is configured.
I think Microsoft should review AFR and inspect all the SSRS branding that Epicor has included in their “AFR web application”. In the very least Epicor should add their own branding to their own AFR web application. Then certain things would start making a little more sense.
Thanks for checking out the behavior of integrated windows authentication for me. It gives me hope that we will also be able to avoid the prompting for user credentials. That seems totally unnecessary , and probably indicates that we have something misconfigured.
